Here I ran into a permissions issue when trying to migrate a customer Azure AD Connect install to a new Server. This is what I did to fix it 🔨
A number of our new customers have been asking us to assist with migrating some services from Server 2008 R2 and Server 2012 R2 platforms to Server 2019. One migration that I was working on with a customer the other day was to migrate Azure AD Connect to a new Server 2019 VM.
When we document an existing Azure AD Connect installation, we tend to find that 99% of customers go with the express install and then select specific OU’s to synchronise specific users from on-premises AD to Azure AD.
It is worth noting that the latest version of AD Connect (1.5.42 at the time of writing this blog post!) has some subtle changes. Some of these changes are good, and some might trip you up!
One good (and long-awaited!) update is that there is now an export and import facility for the configuration. As long as the source and destination server are on a newer AD Connect version, the export option is not present on older versions (as the time of writing the feature is in Preview). Secondly, newer versions of AD Sync now use a new source anchor of ms-DS-ConsistencyGuid.
Migration to a New Server 🚀
I recently started an Azure AD Connect migration from Server 2008 to Server 2019. I grabbed the existing configuration details and followed the standard installation, setting accounts as required. The customer used a custom on-premises AD account for the AD side. Install went smoothly and appeared to be fine.
At the first full export stage there were some permissions errors, lots of them, all the other steps had been successful, and the errors were standard across accounts/groups and were pointing to the fact the permissions were not present to update the attribute: ms-DS-ConsistencyGuid.
I immediately checked the account permissions, and it appeared they matched the automatically generated account used on the old server, except the new attribute couldn’t be written to by the user.
Looking into this there are ways to amend the Active Directory OU ACL permissions, but to be honest, that looked like it could have potential to cause problems. I did see a post highlighting the objectGUID was no longer standard and had been replaced by ms-DS-ConsistencyGuid, and double-checked the old server. Indeed the anchor was objectGUID. The post suggested a re-install of AD Connect.
Fix ☝
The customer was not keen on fixing the security issues, due to the implications of modifying the ACL on the required OU’s which could present a potential security issue and could mess up some of the OU security inheritance.
So to workaround this issue, I suspended the synchronisation and then uninstalled and re-installed Azure AD Connect using the original anchor of objectGUID.
This time the synchronisation stages all went through without errors, I left the console open for 30 minutes to ensure the rolling schedule was clear, and it was.
Moral of this post: Check the original config when updating AD Connect, the information is easily viewed by running the AD Connect tool, selecting Configure -> View Current Config and stick to the information/settings present.
