Over the last few months, I’ve had the opportunity to work with a number of directories that are synchronised from on-premises Active Directory (AD) to Azure AD (AAD) – the directory service behind Office 365, Azure, Dynamics, Intune and other business-focused Microsoft online services.

I’ve learned a few things along the way (like that AAD synchronisation servers are disposable and shouldn’t be re-configured to sync with a different directory, as well as some steps for troubleshooting missing objects) but I thought I’d group a few more points together in this post.

DirSync -> AAD Sync -> AAD Connect

There have been various versions of what’s essentially the same tool (a customised implementation of Microsoft Identity Manager, previously known as Forefront Identity Manager and Microsoft Identity Integration Server – indeed the Synchronisation Manager is still named miisclient.exe) and Paul Wooldridge does a great job of summarising the current situation in his blog post for risual.

These days, there are very few reasons not to be using the latest version – Azure AD Connect – which massively simplifies the process of configuring the underlying Azure AD Synchronisation Services as well as including a number of optional preview features for new functionality. The one caveat is that it needs Windows Server 2012 or later.

Hardware, software and service accounts

Whilst there’s no reason a physical machine couldn’t be used, all of the Azure AD synchronisation servers I’ve worked on have been virtual.  The machine will require the following specification:

• Windows Server 2008 or later (standalone or domain joined).
• Microsoft .Net framework version 4.5.1.
• PowerShell (v3 or later).
• Local administrator privileges to install the software.
• Unauthenticated Internet access (over port 443) to the Office 365 servers.
• A regular user account to connect to AD and read the attributes for objects to be synchronised. This must be able to log on as a service and it will also need to be granted the following permissions in order to write back password hashes (for same sign on):
  • Replicating Directory Changes.
  • Replicating Directory Changes All.

Older versions of the tool allowed the administrator to define an account in the cloud whereas AAD Connect asks for credentials and creates its own service account (with a display name of On-Premises Directory Synchronization Service Account and an user name of Sync_syncservername_identifier@tenantname.onmicrosoft.com). Also, unlike previous versions the account is set with a password that will not expire (the PasswordNeverExpires and PasswordResetNotRequiredDuringActivate attributes are both set to $true).

Tools and commands

Azure AD Connect is based on the Azure AD Synchronization Services framework which itself is evolved from Microsoft Identity Manager (formerly Forefront Identity Manager, Microsoft Identity Lifecycle Manager, Microsoft Identity Integration Server, Microsoft Metadirectory Server and Zoomit Via before that!). Not surprisingly, the underlying tools are the same ones used for these products!

• The main tool is the Synchronization Service Manager (miisclient.exe), which is used to monitor synchronisation as well as to adjust the scope of synchronisation (more on that in a moment)
• There’s also a Rules Editor (which I leave alone – indeed, directly editing the rules is not supported for AAD Connect)
• A scheduled task is also created that runs the synchronisation process every 3 hours by default (you may want to reduce the timeout on this to avoid issues with long-running syncs too).
• It’s possible to force a synchronisation from the command line. This can also be done from the Synchronization Service Manager or from Task Scheduler but the command line is easy! Simply run directorysyncclientcmd.exe delta (from an PowerShell session running as Administrator) or directorysyncclientcmd.exe initial to force a full synchronisation.

As for Powershell cmdlets, the documentation on the ADSync PowerShell module is pretty poor. I managed to extract a list of commands and their syntax but there’s no meaningful help text (at least not that I’ve found). I’ve also seen that the DirSync information on the synced attributes is better than the AAD Sync information (which warns it will be archived soon) and I haven’t found the equivalent AAD Connect information!

What gets synchronised?

For many organisations, not all of the directory needs to be synchronised. It’s possible to filter synchronisation by domain, organizational unit (OU), group membership, or directory attribute. Of these, group membership is generally only used in test (it quickly becomes tiresome to add users to a group to ensure that they are synced to the cloud) and OU filtering is the most common form I’ve seen. It’s also worth noting that the group membership option is new with Azure AD Connect and previous versions of the tool didn’t allow this.

Also note that, if the scope of synchronisation is changed, a full synchronisation is required as a delta will not pick up the new filtering arrangements.

Further reading

• MSDN: Microsoft Azure directory integration tools.
• Alex Simons’ post on Azure AD Connect: one simple, fast, lightweight tool to connect Active Directory and Azure Active Directory.
• Alex Simons/Samuel Devasahayam: Azure AD Connect and Connect Health is GA.
• Bill Mathers’ documentation on custom installation of Azure AD Connect.
• Ryan Sizemore’s post on AAD Connect: identity sync for the layperson.
• TechNet: verify directory synchronisation.
• Dave Stork’s series of dirteam posts on directory synchronisation:
  • Introduction, part 1.
  • Introduction, part 2.
  • Filtering, part 1.
  • Filtering, part 2.
  • Object matching.
• Some older information that’s still relevant:
  • MSDN: Azure Active Directory Sync.
  • MSDN: implement password synchronization with Azure Active Directory Sync
  • Alex Simons: password write-back in Azure AD Sync.