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.

I have a half-written blog post about Microsoft Azure Active Directory (AAD) Connect – the latest incarnation of the directory synchronisation engine used to populate a cloud directory for Office 365 and other online services. That post will stay half-written for a while longer as it needs a bit more work but, yesterday, I was working with a customer whose AAD sync was missing some users. I’d set it up a couple of months previously and it had been working well, but clearly something had gone awry.

Microsoft knowledge base article 2643629 describes why one or more objects don’t sync when using the Azure Active Directory Sync tool but my problem turned out to be a lot more fundamental.

I checked the Synchronisation Service Manager (miisclient.exe) and found that there hadn’t been a sync for over three weeks. Then I looked in the Task Scheduler on the AAD Sync server; the Scheduled Task was still there and it had last run a couple of hours previously. Digging a little deeper and looking at the history though, showed that the task had been failing for a few weeks (every 3 hours), because a previous task was still running.

So, I restarted the server (to clear out long-running processes) and ran the sync, then watched in the Synchronisation Service Manager to check that it started logging the synchronisation events again. Once the sync was completed (with lots of changes, as expected), I changed the timeout on the scheduled task to 2 hours so it should always end before the next begins.

A delta sync sorted most of the issues, but I did need to force a full sync to get all of the missing users up to the cloud, by running directorysyncclientcmd.exe initial.

Incidentally, we’re all used to running idfix.exe before implementing directory synchronisation but occasionally admins create problem objects afterwards too… somehow an account had crept into scope that had a space in the username and no UPN. Predictably, AAD sync didn’t like that and my customer was being emailed after each sync with a notification that AAD Sync was:

Unable to update this object in Azure Active Directory, because the attribute [Username], is not valid. Update the value in your local directory services.

As Joran Markx explains, you can control who the identity synchronisation error reports are sent to by editing the technical contact for the tenant.

Resources

• Troubleshoot directory synchronisation.
• Directory Synchronisation Troubleshooter tool.