Overview

I’ve just covered my experience with Azure AD Connect Preview 1, but here’s the new preview already. Some highlights:

• In-place DirSync upgrade is supported.
• Group-based filtering, in addition to OU-based filtering I’ve demonstrated with Preview 1.
• Syncing of on-premises custom attributes by extending the Azure AD schema.
• A lot of writeback stuff like user, group and device writeback. These require extending the on-premises schema though, and given that this is just a preview, I wouldn’t rely on it. I’m pretty sure the next iteration of Windows Server (2016, they say) will have these built-in anyway.

There’s a lot more info, just head to the Azure AD Connect downloads. There’s and installer and some well-detailed documentation with it. Obviously I can’t cover the upgrade from DirSync since I’ve already re-done this from scratch with Preview 1, but let’s see what it’s like to upgrade that to Preview 2.

Upgrade

The bad news is that upgrading from Preview 1 actually isn’t supported so you need to uninstall Preview 1 first. So I uninstalled Microsoft Azure Active Directory Connect Tool (Preview), but it still left a few components intact. Then I started the MSI installer again. Now it seemed to be fine.

Azure AD Connect will be upgraded. Synchronization will be stopped during upgrade and will not occur until the Azure AD Connect wizard is finished.

Cool, let’s just do it. It progresses for a while, then errors out.

An error occurred while upgrading from Azure AD Sync. Unable to upgrade the Synchronization Service. Please see the event log for additional details.

Okay, let’s see the logs.

Error installing msi package ‘Synchronization Service.msi’. Please look at log ‘C:\Users\administrator.AD\AppData\Local\AADConnect\Synchronization Service_Install.log’ for more details

Duh, just give me the reason, man. So there’s the file but it’s like 9 million lines long. But after some searching I found this particular line:

MSI (s) (50!F0) [01:22:40:980]: Product: Microsoft Azure Active Directory Connect synchronization services – Error 25009.The Microsoft Azure Active Directory Connect synchronization services setup wizard cannot configure the specified database. There is already an object named ‘mms_cs_object_log’ in the database.

But then I notice the Upgrade button is still active, so I try to do it again. Then I get another error in the event log.

Product: Microsoft Azure Active Directory Connect synchronization services – Microsoft Azure Active Directory Connect synchronization services requires a running instance of Microsoft SQL Server 2008 SP1 or better. Install the correct SQL Server version and make sure the service is running before installing Microsoft Azure Active Directory Connect synchronization services.

Wonderful. So at this point I just gave up on upgrading any part of this mess. I really need to nuke this whole thing from the STS. There was an entry in the program list called Microsoft Azure Active Directory Connect, which – thank God – removed everything else that belongs to it.

After that I also restarted the STS comp altogether, you can never know. Then I restarted the installer, which still failed and complained.

The sync engine data directory C:\Program Files\Microsoft Azure AD Sync\Data contains existing files. This directory must be empty before installation can continue.

At this point I declared AD Connect a problem child. I removed the folder, then it finally installed successfully. Then came the precious Sync Filtering screen. Cool. Well, I’d prefer OU filtering instead of Group filtering, but hey, it’s better than nothing.

Then it also offers some nifty preview features.

And that’s there’s to my seamless (ha-ha) install experience. Let’s see how sync works with this new filtering mechanism.

Sync Filtering

So I go ahead and perform the initial sync. Guess what, the AD connector finds like 120 new items even though we have about 40 users that belong to the specified Office 365 group. WTF. Okay, who cares, that’s fine as long as it’s not trying to push all that crap to Azure. But actually, it does just that. Well, at least parts of it. Here’s one of the few random entries that shouldn’t be part of the Azure connector’s entries:

Seriously, DNS Administrators? That’s not even a user. Then I check out the event viewer and there’s random crap like this:

The following password changes failed to synchronized and have scheduled for retry. DN = CN=krbtgt,CN=Users,DC=ad,DC=foobar,DC=net DN = CN=Administrator,CN=Users,DC=ad,DC=foobar,DC=net

What. The. Fuck. No thanks. No more group based filtering. Just forget about it. So I re-apply my OU filter via SSM, then I get the usual warning about delta vs full sync:

The management agent “ad.foobar.net” completed run profile “Delta Synchronization” with a delta import or delta synchronization step type. The rules configuration has changed since the last full synchronization. To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.

So I run a full import, then a full sync, too, and all is well, it finds like a hundred objects to be deleted (including Administrator).

Do I recommend group filtering? Most definitely not. Just give us OU filtering like I asked (please cast your vote, too!).

Insight

Just for curiosity’s sake I wanted to find out how I could change this setting about the group filter. I grepped pretty much the whole hard drive but nothing was found. Then I did the same with the Registry, with the same result. So where else could it be? Hmm… ah, the installer complained about some MDF files, so this thing might store it in that database. So I tried to copy those files, namely:

• c:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf
• c:\Program Files\Microsoft Azure AD Sync\Data\ADSync_log.LDF

But of course it wouldn’t let me. I checked the file permissions, it required ADSyncAdmins group membership. I checked, it already had the AD admin but it was most likely created during setup and my security token only updates during login. So I logged out and logged back in, but still permission denied error. So I figured, I have to stop the ADSync service because it put a lock on it. Then I could finally copy those files and open them in Management Studio.

Aaand my assumption was right. There’s an mms_management_agent table that has 2 rows, each for a connector. The interesting part is the private_configuration_xml column of the AD connector:

ad.foobar.netADadministrator100ad.foobar.netADadministrator1000Office 365CN=Office 365,OU=Groups,OU=Foobar,DC=ad,DC=foobar,DC=net1{BDA9AD0B-C2EE-4F79-83F3-BD7A98DBF3B5}

Bingo. Connector.GroupFilteringGroupName and Connector.GroupFilteringGroupDn are the responsible ones. Still, I don’t recommend changing these manually. Of course, the only other option is to re-run the configuration wizard, which basically means you start from scratch. So even if group filtering worked, it’d be a pain in the ass to administer.

I’m also totally puzzled as to what kind of sense does storing XML configuration in SQL make, but that’s another story… I wouldn’t mind as long as it worked.

TL;DR please, give us an option to set up OU filtering during the configuration wizard!