Data Networking Blog
Blog for Admins

The case of ImmutableId (Office 365 / Azure AD)


Recently did a job for a client where the AD Accounts from his directory server were no longer synchronizing back to Office 365 with errors about duplicate proxyAddresses. AD Connect synchronization service manager UI displayed the following errors:

The Problem

What happened was that he had the users sync’d with Office 365 and everything working properly, till for some reason he created a new AD server and re-created user accounts. This is where the break happened and synchronization stopped with above mentioned errors. This is something some of you may have encountered before but for me it was a good challenge and I learnt something new along the way.

Office 365 / Azure AD creates an Immutable ID for user accounts synchronized through AD by taking the GUID and encoding it as a base 64 value. Since the user accounts were re-created and the GUID had changed, AD Connect was complaining that the proxyAddresses (SMTP/Email address) were already in use by another user account.

The Fix

There are multiple ways to fix this problem but this is how I dealt with it. First, I disable the sync with Office 365 with the following command.

This took a while before the Active Users in Office 365 portal removed the column that showed sync status for an account and  accounts became Cloud managed. Then, I had to run another command to clear off the ImmutableID and set it to a null value.

A gotcha here is that my accounts did not get deleted because of the ImmutableId mismatch, it is possible that accounts correctly synchronising may get deleted and put in the recycle bin or in some cases, the user accounts become unlicensed. If user accounts become unlicensed then you can simply assign the license back to users. In case user accounts get deleted then it is possible to recover them from the recycle bin as these are not permanently deleted for 30 days.

Luckily, there were not many users so this was an easy approach and something that could be done in a short time without the need for a script. Once I set ImmutableId to null for all users, it was time to enable the AD Connect sync again and run a Initial sync through powershell. This is known as a hard match and I was hoping it would work straight away.

But it did not and I got the same error messages in the synchronization service manager UI. But this time it was due to some old accounts which were deleted and kept in the recycle bin after I had stopped the directory sync. So, I deleted these accounts permanently from recycle bin and I manually set the ImmutableId to the correct GUID by using the following method.

1. Export user accounts to a text file using the LDIFDE utility. This gives the GUID in the correct format, ready to be applied to ImmutableId. Example, 3WyOMyLejk2wiReWLQSGw==

2. Set the Office 365 / Azure AD user’s ImmutableId to this GUID

3. Initiated a sync again

I had no errors in the UI this time so that was a good sign. I changed the password for a user and did a delta sync then logged into Office 365 with this new password and it worked straight away. This was a new problem for me which I had not come across before so like most such things, I thought I would create a blog post and keep it safe for future.







June 12, 2018 Cloud Jd
Font Size
Decrease Size Default Size Increase Size
Select Skin
Select Underlay Background
Select Overlay Background
Scheme Switcher Toggle