Question for those that have migrated to O365. Now that I’m done migrating mailboxes and public folders from our on prem Exchange 2013 to O365 I started to look up instructions on decommissioning the on prem Exchange. I then found many articles that recommended keeping it and even applying for a hybrid Exchange Server key that is no cost (per the one blog) to allow for an on prem extension to remain local. At this point we aren’t looking at moving to Azure for AD and I plan to leave it local but that could change down the road. For those that made the jump, what did you do?
I’m interested in this same topic.
There is a conversation on this topic on the CITRT Slack channel.
It depends on how you’ve set up your 365 tenant.
For example, if you are using AD Connect to sync users and passwords, you should just leave exchange in place and shut it off. Properly decommissioning exchange removes all of the email attributes from your AD (which would then get synced to o365 and breaks everything). In this scenario, you are provisioning and editing users in local AD, then AD Connect syncs to the cloud. Some user manipulations will need to be done in ADSI Edit.
If your 365 tenant is standalone and not syncing with local AD, you can decommission exchange. In this scenario, you are provisioning local AD user accounts locally. You are separately managing users/mailboxes in the o365 tenant.This scenario can confuse users since they are 2 fully separate accounts that have similar attributes…
You can also do a federated or hybrid exchange environment, where your local exchange server is still active and that’s what you use to manage mailboxes.
For what it’s worth, most of our clients are using option 1.
James Vavra
We did a cutover migration and decommissioned Exchange as James mentioned in his post.
It did “break” a few things.
We basically used ‘Option 1’ from James’ post.
The biggest pain points for us in our migration to 0365 were with meeting invites and some distribution groups.
In particular, recurring meetings (some with no end dates) could not be cancelled properly, or at least the meeting cancellation updates could not be sent to meeting participants.
The meeting would be deleted from the organizer’s calendar, but the participants never would receive the cancellation.
I would highly advise if you are going to do a cut-over migration and use option 1, to make sure all your recurring meetings have end dates, and make sure organizers make a note of all meetings prior to migration, delete them, and be prepared to recreate and send new invites.