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.

Microsoft Azure vs. Amazon Elastic Cloud Compute (EC2)

In our increasingly cloud-based world, it can be difficult to work with more traditional client- or server-side tools to do what we need. At Interlock IT, we're well-equipped with nothing more advanced than a web browser and a laptop for day-to-day work, but sometimes we just need that little bit of extra horsepower.

So, what to do? Well, we could spend thousands of dollars building our own workstations and servers, but why not leverage the cloud once again? A couple of years ago, we started using Amazon's Elastic Cloud Compute (EC2) service; a central part of their Amazon Web Services infrastructure. AWS powers a host of websites, services, and more that you probably use every day—including, notably, Netflix.

EC2 allows you to get servers up and running in an Amazon datacentre fairly quickly and relatively painlessly. But even Amazon, for all their consumer-friendliness, hasn't managed to make it quite easy enough just yet. Setting up a new server takes many steps, including opening ports, setting security groups, assigning storage blocks (and choosing which type you'd like), and more. It's a lot of initial setup work, but once you're up and running, it just works.

Microsoft, on the other hand, has been steadily building out it's own Azure cloud platform since it launched in 2010. While Microsoft's service is a little younger (Amazon had a four-year head start with EC2), it meant that Microsoft could take a look at what Amazon was doing and set up their service a little bit differently.

Instead of having to wade through fifteen menus to get a new server up and running on Azure, there's five simple screens that ask you for a bit of information to set up your server, and then Azure does the rest.

I've done this repeatedly over the course of the last few months since we started using Azure and can get a new server up, running, and connected in less than five minutes. It's great!

To make things even better still, if you pre-pay your Azure account, the system can track your daily usage and forecast what your bill will be at the end of the month. No more worrying if you're going to be stuck with a huge bill at the end of the month.

We've switched most of our Windows cloud server needs to Azure because we find it a more powerful, easier-to-use option than Amazon's venerated EC2.