Oct 2016

How you CAN remove the last Exchange server after migrating to Office 365!

In a previous post I talked through some of the reasons you should retain one Exchange server after migrating to Office 365.

What’s going on, I hear you say.  Why am I now suggesting ways you CAN get rid of the last server?

For those who’ve decided they’d do just about anything to kill the last server, here are a few methods successfully trialed in the Exchange community.

Firstly, you’ll need to reduce the dependencies of your Exchange server.  You’ll need to

Create remote mailbox without on-premises Exchange

In a 2015 article, Microsoft stated, “The Exchange Management Console, the Exchange Administration Center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects”.

Luckily, Nuno Mota explained how to use AD powershell to create a remote mailbox without Exchange Server (remember the disclaimer above).

Set-ADUser cloud.only –Replace @{msExchRecipientDisplayType = “-2147483642”}
Set-ADUser cloud.only –Replace @{msExchRecipientTypeDetails = “2147483648”}
Set-ADUser cloud.only –Replace @{msExchRemoteRecipientType = “4”}
Set-ADUser cloud.only –Replace @{targetAddress = `

Divorce your shared mailbox

It’s easy to “divorce” shared mailboxes in the following these steps:

  1. Disable directory synchronisation from Office 365 and stop AADConnect Schedule sync
  2. Delete the shared mailbox user object in on-premises AD
  3. Nullify the immutable ID from shared mailbox’s msol user
  4. Enable directory synchronisation from Office 365 and resume AADConnect Schedule sync

After that, shared mailbox object can be deleted from On-premise and you can manage shared mailbox directly from cloud.

Migrate Dynamic Distribution Group

AADconnect does not synchronize Dynamic Distribution Lists. Nuno Mota recommends creating a mail contact on Office 365 and targeting it back to the on-premises dynamic distribution list.

Joe Palarchio has produced a Recreate-DDG script to create a mail contacts in Office 365.

Assuming you have done the above, you need to do the following:

  1. Delete the mail contact on Office 365
  2. Backup on-premises Dynamic Distribution Groups configuration
  3. Re-create DDG on Office 365
  4. Delete the on-premises Dynamic Distribution groups

Divorce your Distribution Group and mail contact

Distribution groups and mail contacts do not use immutable ID so you cannot use the above method. If you have been careful, you will notice that distribution groups and mail contacts have an attribute called isDirsynced.

Before you proceed, check which Distribution group has been dirsynced by running the command

Get-DistributionGroup | ? {$_.isdirsynced -like "true"}

For Mail contact, the command is

Get-Mailcontact | ? {$_.isdirsynced -like "true"}

Tino Hernandez from Catapult Systems has documented a process to migrate distribution groups from Exchange On-Premise to Exchange Online. By changing the script, you could also do the same on migrating contact object.  However, the process involves a lot of administrative changes. Tino’s method involves backing up your current distribution groups and creating a new distribution groups.

Last year, Microsoft introduced Office 365 Groups. I call it “Microsoft Exchange distribution list v2”.  Instead of converting from on-premises groups to cloud only groups , you can easily convert from Distribution list to Office 365 Group. Office 365 has created a guide for to assist with the migration.  Of course, this requires even more change control and user communication/training to make it work.

At Ensyst, we’ve been thinking about a “smarter” way to divorce your distribution groups.

The steps are as follows:-

  1. Disable directory synchronisation from Office 365 and stop AADConnect Schedule sync
  2. Delete the on-premises distribution group / mail contact
  3. Uninstall AADConnect (and all the component – especially SQL localDB)
  4. Restart the server and reinstall AADConnect
  5. Configure the AADConnect accordingly and enable staging mode (just in case)
  6. Full sync and confirm you notice some “Disconnectors”. It should be equal the object you deleted
  7. Disable staging mode to perform delta sync

We’ve confirmed the above method in a test lab and this should allow you to easily reborn the distribution group and mail contact to cloud.

So after this point, your dependency on Exchange server is minimal.

Of course, using the above “divorce” method, all the relevant objects will no longer exist On-premises AD. Some organisations might not ready for that, especially as there are some work flow processes that will require those groups to be in synced.

Use a 3rd party identity provider

A 3rd party identity provider might be a good choice. This is not a paid advertisement, but Okta and Onelogin both have a free Office 365 version that provides unlimited users to close this gap.

The procedure would be:

  1. Sign up to the service from an identity provider
  2. Download and install an agent on a member server (or domain controller). The agent will require an outbound connectivity to the identity provider
  3. Configure the identity provider correctly to sync up active directory. Depending on the situation, allow identity provider to auto provision, and update Office 365
  4. Deactivate directory synchronization and password synchronization. Turn off AADConnect permanently
  5. Configure Office 365 to federate with the identity provider. This will change the Office 365 authentication from password hash to the federation. At the backend, the password will be sent to the identity provider and then pass to on-premise AD via the agent you install

With directory synchronization turned off, you can now manage all object from the cloud (along with the identity provider you have chosen) and the agent will synchronise your object on-premises to Office 365 (and vice versa).

But as I always say, to solve a problem differently, you might just swap one problem with another.  All these 3rd party IdPs have their differences, so they might tell you what is supported and what is not supported, if your environment is complex enough. But please don’t get scared away, if you think it will solve your problem/business requirement.

Of course, Office 365 continues to evolve, and if one day, IdPs fall behind in their development, you could have a fun time. Depending on your business requirement, you might need to choose a relatively supported method.

In conclusion

After reading this article, you will see it is possible to get rid of all Exchange servers after migrating to Office 365.
If you follow the methods outlined above, including the 3rd party IdPs option, you will able to remove your last Exchange server (and AADConnect as well).

However, should you want to use Microsoft technologies only, I’d still recommend you keep your last Exchange server for management and mail relay purposes. It’s up to you!

Leave a Reply