Directory Synchronization with Office 365 is a solution almost all enterprises take advantage of to make their journey to the cloud a slightly less bumpy one. It simplifies the admin and end user experience by ensuring a user’s groups and information are identical in the cloud as it in in your on premises Active Directory. User lifecycles can be controlled by existing tools.
However, with any great power (or tool), comes great responsibility. In order to ensure a successful directory synchronization, it is important that the on premises Active Directory is in tip-top shape. Legacy habits such as putting email addresses in service accounts or groups or using special characters to help things sort a certain way when searching can cause nothing but problems when synchronizing to Office 365. Thankfully, Microsoft has provided tools such as the IDFix DirSync Error Remediation Tool to help catch these items before they become an issue. Inevitably things will fall through the cracks and you’ll have to clean some items up after.
One of the most problematic issues comes when you either have an on premises account that links to the wrong account in the cloud or you need to perform a change on an account on premises that involved removing and recreating the account. This is because Office 365 Directory sync is anchored around the concept of immutable ID’s. An immutable ID, just like the name describes, is a value that does not change for the entire life of the object. This is based upon the on premises accounts GUID which is something that will exist and stay the same no matter where in the active directory domain you move it. No matter what you do to that account, it is ‘stuck’ to its associated account in the cloud.
So what happens if you have an account that has either matched with the wrong on premises account or you need to make a major change on premises that will involve deleting the on premises account. Traditionally you would have had to backup all of the cloud account data, delete it and then fully recreate it. This was a time consuming process and one that if done incorrectly could lead to data loss.
A colleague of mine, Everett Simpson, had recently come up with a slightly more elegant solution that leverages the built in provisioning and de-provisioning workflow of AAD Sync/Connect. The steps are as follows:
- Move your problem account into an OU in Active Directory that does not synchronize
- Run a synchronization pass or wait for synchronization to run
- Using the following script from TechNet (GUIDtoImmutableID), capture the immutable ID of the account you need.
- Connect to Azure AD PowerShell and run the following commands:
- $DelUser = Get-MsolUser -UserPrincipalName firstname.lastname@example.org -ReturnDeletedUsers
- Restore-MsolUser -ObjectId $DelUser.ObjectId
- Set-MsolUserPrincipalName -NewUserPrincipalName email@example.com -UserPrincipalName firstname.lastname@example.org
- Set-MsolUser -UserPrincipalName email@example.com -ImmutableId (put correct immutableID here)
- Set-MsolUserPrincipalName -UserPrincipalName firstname.lastname@example.org -NewUserPrincipalName email@example.com
- Place the account back into a synchronized OU
- Run another synchronization pass or wait for the task to automatically run
Office 365 will perform a ‘hard match’ and sync the two accounts together. The user’s mailbox and one drive data will be restored back to their account.
Hopefully this quick tip helps someone out next time they run into a problem synchronized account.