This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.
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
Unfortunately, without these settings in place, Office 365 will continue to alert that there are issues with domains that may cause “possible service issues”. To prevent this, navigate to the domains section of the Office 365 Admin Center and click fix issues next to one of the domains that is reporting problems. Then, on the right-hand side of the page, click the checkbox next to “Don’t check this domain for incorrect DNS records”. Once this is set, Office 365 should stop alerting for domain issues.
I use Office 365 at work and I expect I could have asked to use that on a home PC (it covers me for up to 5 devices) but then I found 
