DirSync is DirSync, right?
Well, no, actually.
When I originally set up our Office 365 hybrid deployment DirSync wasn’t supported on a Domain Controller, so we stood up ADFS, and DirSync on separate boxes.
This is something I’ve meant to come back to for a while, so I took the opportunity when things were quiet to take them apart and put them back together again.
So, let’s start with a clean slate, I’ve deactivated Active Directory synchronisation in the Office 365 Admin Portal, and cleaned out all but two cloud users that I have licensed for Office 365 Enterprise E1.
For reference, once the users have been deleted in the portal they have to be purged from Azure AD PowerShell using something like
Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser –RemoveFromRecycleBin
In the portal, I’ve selected the option to Set up Active Directory synchronisation.
This takes me to a page with a series of numbered steps, and some downloads.
In particular here I’m interested in IdFix and DirSync.
I’ve downloaded both IdFix and DirSync onto my DC, because I want to remove the dedicated DirSync server.
IdFix is quite useful, but the first thing that jumps out at me is the number of AD objects that exist in the background for various purposes, MS Exchange Health mailboxes and the like.
I don’t need all of these in the cloud.
When I try to run the DirSync.exe download I get a prompt about .NET 3.5 SP1 and .NET 4.5 so I put both of these on my DC.
I then install DirSync and run through the configuration wizard.
The configuration wizard is somewhat simple.
There is no option to filter objects, apps or attributes.
When the sync has run, I have every object from my on-prem AD in the cloud.
The lack of an option to exclude attributes is a bigger potential problem, because now I’m flowing msEchangeMailboxGuid into Azure, which means I can’t use third party products to do the mail migration.
I did some work over a year ago on mail migration to Office 365 using third party products, and the difficulties that MSExchMailboxGuid causes.
I have had numerous opportunities to use third party products with Office 365 where DirSync is in place and Exchange exists on prem but hybrid isn’t an option.
In this scenario msExchangeMailboxGuid is a show stopper.
So, DirSync isn’t what I wanted in the end!
Now I could modify the flow under the hood, because DirSync is essentially FIM 2010 R2, so I could open:
C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell
and run miisclient.exe
Instead what I will do is remove DirSync and replace it with Azure AD Connect.
I removed DirSync from the server, and downloaded AzureADConnect.msi from here.
I took .NET 3.5 off the DC while I was here.
I did notice it’s now called AzureADConnect.msi, where the last time I played with it, it was called AzureADConnectionTool.exe
The properties of the previous version I played with still showed it as “DirectorySync Tool”, or the “Microsoft Azure AD Sync”
The new version is less obvious
When I choose the “Customize” option during installation, I get options for “Password Synchronisation” or “Federation with AD FS“, where DirSync only offered me password sync.
I have selected “Do not configure“, because I already have SSO and AFDS in place
AD Connect gives me the option to sync members of a particular group, which in my case contains every user I want in the cloud.
I then have the option to filter apps and attributes, as well as configure Exchange hybrid deployment.
I now have the option to filter msExchangeMailboxGuid
Although in my case I don’t actually filter this, it’s just nice to know I have the option for when I need it.
When I finish the wizard and run the sync, I now only have the users in the cloud that I want, and I have the option to filter attributes if I need to.
All in all Azure AD Connect is a better tool for this job in my opinion than DirSync, so it would be a better option to make available in the Admin portal.