Many larger businesses synchronize their local AD with Azure AD. Microsoft provides tooling for that, called Azure AD Connect. This is software that runs on a server in your on-premise environment that syncs your specified local AD objects (users, groups, and computers) to the Azure AD that is connected to your Office 365 environment.
How does it work
The way this works is that the Azure AD Connect software retrieves the objects from a local Domain Controller and from your Azure AD. It will then look for differences and it will perform activities like:
- Create a new account in Azure AD that was created in the local domain
- Delete an account that is no longer available in the local domain
- Update properties of the user, both ways
- Update group membership, both ways
- It can also sync passwords, but this is highly dependant on your setup
- and more …
The way it keeps track of what object in your local AD matches the object in your Azure AD is done by means of the ObjectGuid. This is a unique identifier for each object in your local AD and it is then stored in the corresponding object in Azure AD. As this object in Azure AD has its own ObjectGuid, this is stored in a different field: ImmutableId. It is stored in a different format, but it can easily be converted both ways without problems.
Hard match vs Soft match
The AD Connect software is also able to link existing objects that are not yet linked to each other. For example, you have created a Cloud account in your Azure AD and created the same account in your local AD. The configuration in the AD Connect software can link these accounts if, for example, the email address is the same on both sides. This is called a soft match. You can use any other field to set up these initial links, but in the end, the link is made permanent by having the ObjectGuid stored in the ImmutableId field. The link between these fields is called a hard match.
The problem
There are many examples of what could be the cause, but let’s pick one. You permanently deleted a local AD account. The AD Connect synchronized and now also your cloud account is gone. The employee no longer has access to e-mail or anything else in Azure or O365. You have meanwhile created a new account for the user in the local AD, but it will try to create a new O365 account for this user. The original mailbox, onedrive, sharepoint, teams … all that data is not accessible by this new user object and the user complains his mailbox is empty.
The solution: change O365 account owner
You need the change the owner of the old O365 account to the new account in your local AD. You do this by setting the ImmutableId manually.
The assumption is that you have a deleted O365 account that holds the data of the employee. You also have a new local AD account. This account must not have a corresponding Azure AD account. A way to accomplish this is to move the new local AD account to a location outside of the sync scope, so it will no longer sync and be deleted in Azure AD. From inside Azure AD (not O365) perform a permanent delete of that NEW account. Be very careful to not delete the old account that holds all the data!
Next, you need to get the GUID for the new account and convert it to a ImmutableId format: (replace <username>)
Import-Module ActiveDirectory
$guid = (get-Aduser <username>).ObjectGuid
$immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
Now, restore the old account in Azure AD from the deleted users pane. It will be restored as a cloud account, but it still has the old ImmutableId. You need to change that. Make sure you have stored the ImmutableId from the above Powershell snippet first. Execute the following: (replace <UPN>)
Connect-MsolService
Get-MsolUser -UserPrincipalName <UPN> | Set-MsolUser -debug -ImmutableId $immutableIdNow move the local account back in scope of the sync. This will restore the hard-match in AD Connect during the next run of the AD Connect. After that first sync has completed it may take ANOTHER sync for the system to process the changes so the user can actually logon.
If there is a situation you want to use the soft match feature (for example, you have a lot of deleted accounts and can’t be bothered to carefully calculate the ImmutableId for each of them), you can also clear the ImmutableId field and let AD Connect do a new soft match. How successful this is, depends on how well the matching goes.
Get-MsolUser -UserPrincipalName <UPN> | Set-MsolUser -debug -ImmutableId $null I suggest, for a single account, to just do a hard match so you will not link the wrong accounts.