Sunday, February 19, 2017

Solving Some Azure Active Directory User Synchronisation Issues on Office 365

We started moving over to Office 365 quite a while before we decided to ditch Notes mail and move to Outlook. It was also my plan to get rid of our internal active directory server and rely solely on the cloud for authentication. 

As it turned out, management wanted to keep the AD server a little longer, so we've had to synchronise our onsite accounts with the Office 365 ones. The synchronisation processes immediately created duplicates (and sometimes triplicates) of users. 

The journey to resolve this issue was time consuming and data destructive, so I thought I'd let everyone know how to fast-track it.


What Causes the Problems

Microsoft's Office 365 users have unique ID's much like the objects in the Active Directory. When you create a user from scratch on Office 365, you create them with a unique ID. While there are tools that will let you change these unique IDs, we've found that they generally do more damage than good.

Deleted people are another part of the problem, If you delete someone and then let the system recreate them, it will happily recreate them but won't set their ID properly. This is because their ID isn't unique. It's still in the person "recycle bin". To truly delete someone, you need to use the PowerShell command line.

Backing Up First

Before I jump into the whole process, you need to make sure that you back up things. Deleting users is fairly data-destructive.


  1. If your users have anything on OneDrive, take a local copy of it all.
  2. If your users have data in Sharepoint or Yammer, backup what you can.
  3. Transfer Ownership of Groups in Yammer and Sharepoint very carefully - don't delete all the Admins at once because you may have trouble getting them back. 
  4. Backup any Outlook mail they may have to a PST file (they'll lose mail)
  5. Make a note of any licences they have. 
  6. Do whatever you need to about OneNote 

Getting into Microsoft Azure Active Directory

You have to have Microsoft Azure Active Directory Module for Windows PowerShell installed.
Note that this is different from PowerShell and it's different from the AD Module for Powershell. It's hard to find the right version of the right software - at the time of writing, you need version 2.

In case you're interested in other Azure AD commands, here's a handy reference.

The first command is to connect to the Azure AD;

Connect-MsolService

You'll be prompted to login (so hopefully you'll use a user who has Global Administrator access).


Next, you will want look at the records of users...

get-msoluser -UserPrincipalName jsmith@mycompany.com |fl

This command line will show you jsmith's record.  Things to look for in the text include;

ProxyAddresses        : {SMTP:jsmith@mycompany.com
ImmutableId           : Pjo+HQRGtXm9GsUXzYYRqQ==
DisplayName           : John Smith
SignInName            : jsmith@mycompany.com
UserPrincipalName     : jsmith@mycompany.com

We found that our Proxy Addresses didn't start with SMTP: and that our Immutable IDs often had people's names (eg: jsmith) in them, instead of the ID.

The SMTP thing can be fixed but if your immutable ID is wrong, you really need to look at destroying the profile record and recreating. We've found that all of the records we destroyed have recreated properly but that the ones where we've just changed the proxy still have some glitches. I'd personally recommend removing everything.

Deleting People from the AD

You'll find that you simply can't delete a person in the Office 365 AD, particularly if they're synched from a local server. The GUI just won't work. You need to delete via command line.

Make sure that you check which licences they have been assigned because you'll want to reallocate them back.

remove-msoluser -UserPrincipalName jsmith@mycompany.com

Deleting a user is not enough though. You have to knock them out of the trash, otherwise they'll reside there for 60 days and prevent recreation via the AD synch process.

Even if your user wasn't having issues with their immutableID, they could still be having problems with Synch and email because of similarly named deleted people.

Before you delete, make sure that you've backed everything up. Emptying the trash is permanent and there's no recovery.The empty trash command is more or less the same as the delete command but with an extra switch (-RemoveFromRecycleBin)

remove-msoluser -UserPrincipalName jsmith@mycompany.com -RemoveFromRecycleBin

Wait for AD Synchronisation

In our case, AD synchronisation is set to 30 minutes. You can check via the front page of the admin centre. You might have to click More and then Refresh to get things to display properly because Office 365 doesn't always automatically refresh person lists or time displayed on the screen.

Once the next synchronisation has run, you should see the record appearing.

Some Fixes on the Local AD Record

We also had to do a couple of fixes on our local AD record, particularly making sure that the ProxyAddresses start with SMTP.

To do this;

  1. Go to your local Active Directory Server.
  2. Open users and Groups and get to our users.
  3. Edit the User Record.
  4. Go to the Attribute Editor Tab
  5. Find ProxyAddresses and double-click on it.
  6. If the address is something like: jsmith@mycompany.com then click on it and click REMOVE
  7. Then type  SMTP:jsmith@mycompany.com and click Add.
  8. If you need two, you might also want to type smtp:jsmith@mycompany.onmicrosoft.com
  9. (note the first/main SMTP is capitalised and the second is lowercase ... yes, seriously).


Reassigning Licensing and Finishing Up

Back in the Office 365 GUI, you'll want to go back into the person's user record when they appear.
Reselect their country
Re-add their licences.

You'll probably want to re-check their outlook settings but you can't because you have to wait for it to be finished being setup.

Repeat the process for all other users. Note that there are options for wildcard deletions and mass trash emptying. I haven't covered them here because the command line was fast enough for me and I don't really want to be responsible for someone trashing their entire Azure AD.

A big thanks to the amazing Microsoft support team in Shanghai who figured out some of the more technical parts of this process and walked me through them. 

No comments: