Fixing conflicts and errors with Active Directory synchronization to Office 365 and Azure

Sometimes user accounts (or objects) that have been deleted and then recreated on your Active Directory will become out of sync with Office 365 meaning changes to passwords and other attributes won't sync properly. Another cause is a change in the configuration of your Azure Active Director Sync utility, such as changing the SourceAnchor attribute.

DirSync is more common in the Office 365 user base because its replacement, Azure Active Directory Sync was recently released in September of 2014. For a comparison of the two tools visit Microsoft's Directory Integration Tools page.

If you have objects out of sync or conflicting you might receive an error message email every few hours when the AAD Sync utility is run.

You should also see the errors in the Event Viewer and Application Logs on the Windows Server running the utility.

In some cases, the Microsoft's own Office 365 IdFix tool can't find the problem, and thus can't fix it.

By reviewing the contents of userdetails.csv output by the PowerShell command:

get-msoluser | export-csv userdetails.csv

we were able to see that the ImmutableID was set incorrectly due to a prior sync configuration or that the on-premises Object ID shown in the error message above was already connected to another user.

Somewhere along the line, Microsoft removed the ability change or clear the ImmutableID attribute without first disabling Directory Sync for the organization so most internet postings we found while looking for a solution are no longer valid. Some postings showed that back in 2012 you could set the ImmutableID from PowerShell. Today you can only clear it to null if Directory Sync is deactivated.

Deleting (setting to null) the ImmutableID attribute on Office 365/Azure Active Directory solved the sync problem for us. You can no longer change it to match but the directory sync utility will re-populate it for you. Here's how to do it.

Start by disabling the Azure AD Sync Scheduler task in Task Scheduler on the Windows Server that runs AAD Sync:

Next Deactivate Directory Sync on your Office 365 Admin console:

In our experience, it actually takes a couple of hours during business weekdays and about 10 minutes on a Saturday night to deactivate, but it could theoretically take up to 72 hours to complete.

Copy the commands below into a new text file and save it as eraseimmutableid.ps1, change the $upn value accordingly and run it:

set-executionpolicy RemoteSigned
Import-Module MSOnline
Connect-MsolService
$upn = "sampleuser@domain.com”
$oid = (Get-MsolUser -UserPrincipalName $upn).ObjectID
Write-Output "Before:"
Get-MsolUser -UserPrincipalName $upn | select userprincipalname,ImmutableID,ObjectID
Write-Output "`n`nAfter:"
set-msolUser -ObjectID $oid -immutableID "$null"
Get-MsolUser -UserPrincipalName $upn | select userprincipalname,ImmutableID,ObjectID

Now re-enable the sync service in Task Scheduler and run it manually.

If you still see errors keep looking at the results of userdetails.csv mentioned above. Search for the email addresses and Object IDs shown in the error message email.

Feel free to reach out to InterlockIT.com for assistance with your Office 365 Directory Synchronization configuration and fine tuning.

Google Apps Directory Sync: Tips for Microsoft Active Directory

The Google Apps Directory Sync tool really should be installed at any mid to large corporation using a Microsoft Windows Server (or any LDAP compatible directory server).  It eliminates the need to add, change, or delete users in two different places.

LDAP Directory Sync is definitely complex with a steep learning curve.  You need a good understanding of how to create LDAP queries as there are only limited examples in the provided documentation.  However, once it's configured there should be little reason to change it.

It's our experience that in most installations you'll need one configuration file for synchronizing Users, Profiles, and Contacts and another configuration file for Groups.

If you're migrating in batches from an email server such as Exchange Server to Google Apps it's best to synchronize only users that are a member of a Security Group such as "Google Apps Users".  That way the user is created in Google Apps only after they've been made a member of the security group.

Here's a sample LDAP user query: 

(memberOf=CN=Google Apps Users,OU=Security Groups,DC=domainname,DC=local)

Replace OU=Security Groups,... with the appropriate location in your Active directory tree of the security group.

And note that Google Postini has the same ability to synchronize to Microsoft Active Directory or your LDAP directory server.

Or give us a call at Interlockit.com.  We're happy to configure it for you.