Windows Azure Active Directory Sync (DirSync) has become synonymous with Office 365 in recent years and while DirSync isn’t a requirement, I haven’t seen any organisations consuming Office 365 services without it. In simple terms, DirSync can be used to synchronise local Active Directory objects to a Windows Azure Active Directory instance which is in turn leveraged by Office 365. After an initial synchronisation, DirSync runs on a schedule (typically, every three hours) to synchronise changes from the on-premises directory to the cloud instance.
The recent addition of password synchronisation to DirSync has made it even more useful and has been one of the many improvements to the tool (initially 32bit only!) which was released a few years ago. Unfortunately, DirSync still has some limitations especially when it comes to multi-forest scenarios. To help address the complexities associated with multi-forest environments, Microsoft recently announced Azure Active Directory Sync Services (AADSync) which is currently in preview. AADSync is intended to significantly simplify the configuration required to synchronise multi-forest environments.
I thought I’d take AADSync for a test drive and see what it is all about. At this point I should also mention that it is currently a preview (CTP) release and is not supported in production environments. There preview also has a few limitations:
- AADSync preview can only use SQL Express LocalDB.
- PasswordSync and password write-back are not currently supported.
- Hybrid Exchange configuration is not currently supported.
The pre-requisites are really simple, you will need the following installed on Windows Server 2008, 2008 R2, 2012 or 2012 R2:
- .NET 3.5 and .NET 4.5.
- PowerShell 3.0.
The installer will automatically install the Microsoft Online Services Sign-In Assistant (msoidcli_64) which is really convenient as you can now be confident you will have the correct version installed.
As previously mentioned, this is a preview release and therefore the installation wizard is not yet strongly signed. It is therefore important that strong name signing is turned off on the server. The AADSync tool will NOT run if you do not perform this step, instead you will receive the following “DirectorySyncTool has stopped working” error with “Problem Event Name: APPCRASH”
To turn off strong name signing, simply use the included “sn.exe” utility and issue the following command:
[shell]sn -Vr *[/shell]
For more information about strong name signing and the sn.exe utility, see the following links:
The installation process is pretty simple as one would expect, before starting the process it is helpful to have the following information to hand:
- Service account in AD (default read permissions will be sufficient)
- An Azure Active Directory tenant (Office 365 for example)
- Service account in your Azure AD (Global Administrator role required)
You will notice the option to add multiple forests. For more information about the multi-forest scenarios supported, see AADSync Scenario Overview. If you configure AADSync to join multiple forests, the default configuration will assume the following:
- A user will have only one enabled user account and login information is taken from this forest.
- A user will have only one Exchange mailbox.
- The data quality for a user is best in the forest where Exchange is located.
- If an Exchange mailbox is found, common user attributes are taken from this forest.
You can configure join rules which map to the supported scenarios mentioned above. In a single forest scenario, the default selection will create all users as individual objects in Azure AD and objects will not join in the metaverse. You also have the option to select the immutable attribute. It is important to note that the attribute selected must not change during the lifetime of the object, even if the object is moved between domains in a forest or between forests. If you are unsure, you are probably better off not changing the default selection.
Once completed, it successfully synchronised the 3000 accounts in my lab AD in about 25mins. The “DirSyncConfigShell.psc1” shell is not longer available and seems to have been replaced by “DirectorySyncClientCmd.exe”. I noticed a new PowerShell module which is great.
[powershell]Get-Command -Module PowerShellConfig[/powershell]
[powershell]Get-SynchronizationRule | Select Name, Direction[/powershell]
I also noticed a new “Synchronization Rules Editor”
Many of these configuration options are probably best left at their defaults unless you have a specific requirement or scenario. I expect to see more documentation become available closer to or at release, but in the meantime you can find the current official documentation here.