Ok, so this seems to be a not-so-unique unique scenario…

In short we were conducting a pretty standard on-premise Exchange 2010 to Office 365 migration for around 30 users. This is a really simple process and for the user count the cut-over migration method is what Microsoft generally recommend (see here for the actual process or here for the other migration options available). Once the cut-over migration was complete we wanted to make use of the Azure AD Connect tool to have the users local Active Directory passwords synced over to Office 365.

This is where the headache came in, the cut-over was done, email was working happily in 365, DirSync was now enabled and user passwords mirroring over successfully….but we were stuck. We couldn’t remove Exchange 2010 to decommission the old SBS2011 server without it stripping the Active Directory attributes now linked to the Office 365 accounts.

We wanted to confirm the process via support channels although both our CSP provider and Microsoft Office 365 support were clueless on the issue – either telling us it was unsupported (it may well be but I’ve not seen anything to confirm this in their documentation) or that it was an AD/Exchange team issue so nothing to do with Office 365 team /facepalm. After several days over email running through the issue we gave up on their often incorrect advice and had to crack it ourselves.

Thankfully it was as simple as we’d hoped so the below is what worked for us –

  1. We performed and completed the cut-over migration from an on-premise Exchange 2010 server (running on SBS 2011) to Office 365.
  2. We then installed and configured Azure AD Connect to synchronise passwords (one way only, not using write-back).
  3. With the above process in place for a week or two without issue it was then time to decommission Exchange 2010. The key attributes that we need to protect are mail, mailNickname, ProxyAddresses and ArchiveGUID (if you had any archive mailboxes).
  4. To begin the removal of Exchange make sure you pause Azure AD Connect so it doesn’t sync during the process (just open the GUI as it will suspend the service).
  5. Using AD Snapshots (here) we created a snapshot and confirmed we could mount/view the backup copy.
  6. With the snapshot now in place we could happily remove Exchange 2010 from the environment.
  7. Once removed we added back the stripped attributes that look to be the core requirements (mail, mailNickname, ProxyAddresses and ArchiveGUID). We didn’t have any Archive’s so we didn’t need this particular one restored.
  8. Using the below commands in a Powershell window we mounted the backup AD Snapshot and restored the attributes for all users:

    . .\AD_Snapshot_Functions.ps1

    Mount-ADDatabase -Last -LDAPPort 33389

    Get-ADUser -Filter * -Server localhost | Repair-ADAttribute -Property mail,mailNickname,ProxyAddresses -LDAPPort 33389

  9. Once done we checked a few of the AD users to confirm the attributes were back in place and then resumed the Azure AD Connect sync.
  10. For good measure we ran a full Sync via the Powershell command –

    Start-ADSyncSyncCycle -PolicyType Initial (here for some more info)

That’s it. Mail flow looked good, all the 365 accounts were still linked with their relevant email details so we can now finally bin off the old SBS server.


  1. 05/02/2019 at 4:47 PM Richie Knight

    Very useful guide. Thanks Martyn.

  2. 19/04/2019 at 10:46 PM Nick

    Are the attributes there when a new user is created after this process?