During the Ignite session titled “Run Microsoft Exchange Hybrid for the long haul”, Microsoft has hinted at potential solutions to the problem that many customers face after migrating to Exchange Online.
One of the frustrating discoveries for a lot of customers is that moving your email to Office 365 doesn’t necessarily mean you can say goodbye to your on-premises Exchange servers. Even if you’ve used a hybrid configuration to get through the migration, and then removed the hybrid config at the end, you’ll still need to maintain an Exchange server on-premises for management purposes if you continue to use directory synchronization (which many customers do).
To be clear, it’s not the hybrid that creates the dependency of an on-premises server, it’s directory synchronization. Directory sync makes your on-premises Active Directory the source of authority for your directory information (users, groups, etc). It’s super convenient, providing same sign-on or single sign-on access to Office 365 services. But the catch is, you need to manage the user attributes (including email attributes) on-premises. And the only supported way to manage email attributes is using the Exchange management tools, which means you need an Exchange server.
There are some benefits to keeping an on-premises server though. Using it as a local SMTP service is handy, and if you leave the hybrid configuration in place it also provides you with the flexibility to off-board from Exchange Online in future if the need arises.
Still, customers who want to reduce their on-premises server footprint will always want the option to ditch Exchange. I’ve often thought that a lightweight “management appliance” might be able to do the job, something that can co-exist on the same server running the directory synchronization service as well. How feasible that idea is, I don’t know, but its encouraging to see that Microsoft is actively pursuing a solution to such a regular complaint.
h/t to Jetze Mellema for tweeting this info from the session
Update: at Ignite 2017 Microsoft revealed they are working on a hybrid connect to solve this problem.
Hello, Quadrotech. I have been searching the site, looking for an update on this subject. Is there any new news on Microsoft’s plans to simplify the requirements for on-premise requirements when managing an ExchOnline/Office365/Azure environment?
Hi Paul
We have several customers that are effective startups or migrated to O365 other than hybrid.
So it is not a case of keeping the Exchange server but having to deploy a new one and this doesn’t seem logical.
Do you have any official articles from Microsoft that state that it is not supported unless you have an Exchange server?
thanks
https://www.practical365.com/exchange-server/removing-premises-exchange-servers-migrating-office-365/
Hi Paul,
Any new guidance from Microsoft on this?
thanks.
No. I wouldn’t expect anything before Ignite either.
Microsoft Ignite 2018 has come and passed. I can’t find any reference to announcements on this topic, did they go quiet or am I missing it?
Hey Paul, great article… I suspect I might get away with completely removing exchange on-prem and hybrid as we are already managing all those attributes via our Identity Management Tool (Omada). We set all the email attributes and sync new users using Dirsync and license them via powershell… so although we have migrated all our mailboxes, new users are never created or managed via exchange… all is done via Omada into AD and then synced to cloud.
I just want to make sure my assumption is correct and also want to ask the following two questions:
1. Which attributes exactly should I continue managing via Omada ?
2. How can I decom exchange without clearing existing attributes ?
Thx
Q
1. This isn’t documented, because it’s not a supported scenario.
2. This isn’t documented, because it’s not a supported scenario.
I know that is annoying to read, but that’s the truth. Microsoft doesn’t document unsupported scenarios like this.
I _really_ hope that Microsoft will announce a solution for this stupid problem on up-coming Ignite 2017… They now (soon) have had a year since last Ignite, where they indicated their knowledge of the issue.
Hi Paul
I understand not having on-prem exchange is not supported by MS. In a scenario with 100% mailboxes migrated to O365 with Azure AD synch and on-prem exchange decommissioned, how can attributes such as Send As, Send on Behalf, Full Mailbox Access & Shared Mailbox can be managed using local AD or can they be managed in EOL (if EOL let this happen) or the only way around is to have exchange on-prem. Thanks so much.
Permissions such as those you mention are configured in Exchange Online.
We migrated all mail functions to O365 and are using AD Sync. I have 2 (idle) onsite Exchange 2010 servers (CAS/Storage) left in place because of the Exchange Schema/attributes management requirement.
I would like to drop down to single Exchange server with minimal role(s) installed but
I cannot seem to find posted anywhere what Exchange role(s) are required to be kept installed onsite for those 4 attributes.
Any suggestions or know where to find those particular requirements?
I haven’t seen anything specific from Microsoft on that. You just install a single multi-role server if you only want to run a single server.
Paul, do you know if Microsoft has anything new regarding the decommission of the on premise Exchange servers?
Thanks,
Markus
Situation hasn’t changed.
Hello, we have a somewhat unique situation where 100% of mailboxes, distribution lists, public folders, etc. have been migrated to O365, so that there is nothing remaining in the on-prem 2010 exchange servers. We have a hybrid server and a separate DirSync server running AADConnect. To complicate matters, we are also doing a domain migration to a new forest. Whilst 100% of mailboxes have been migrated to O365, only 50% of the users have been migrated to the new domain. The legacy exchange & hybrid servers are in the old domain. My customer wants the old exchange servers & hybrid removed (but is happy to leave the DirSync server). A new Exchange 2013 server was installed into the new forest, but this does not know about the old forest or O365 mailboxes. Therefore, my concern is that if I remove the legacy exchange + hybrid servers, I will not be able to manage half of the mailboxes because the 2013 exchange server is in the other forest. Would I need to install a 2013 exchange server in both forests?
For a complex scenario like this I recommend you engage a consultant who can look at your requirements and provide accurate advice.
Atilla,
I have a similar scenario, although it is a little more complicated.
Would you mind sharing what you ended up doing?
Specifically, were you able to decommission all the Exchange and Hybrid servers in the old domain and then use the Exchange server in the new domain to manage O365?
If so, was there any difficulty getting the new Exchange server to manage O365?
Regards,
David
Attila,
I am in very similar situation.
All mailboxes have been migrated to cloud and started migrating users to new forest with Azure AD connect enabled.
I would like to know if you found a solution to your problem or if any other readers have?
Regards,
John
Are there any updates on the work that Microsoft is doing on this? Thanks much!!
Haven’t seen anything else announced, sorry.
I have an Exchange 2010 environment with 2 Exchange 2013 servers for a Hybrid setup, using AD Connect for directory synchronization. I would like to remove just the Exchange 2010 servers since our on-prem mailboxes are migrated to 365. My understanding is I need to keep the 2 Exchange 2013 servers. Guessing the ebook goes over the decommission process for those 2010 servers in our scenario?
Whether you need 1 or 2 Exchange 2013 servers is more a question of availability. If 100% of your mailboxes are in the cloud, mail routing goes directly to the cloud, and Autodiscover resolves to the cloud, then the main role that the on-prem server is providing is as a management/admin interface. So it depends how available you need that to be for your IT teams. Some customers get by just fine with 1 on-prem server in long-term Hybrid scenarios.
If you’re adding or removing servers in a Hybrid scenario, and those servers are involved in some Hybrid functionality (e.g. mail flow, MRSproxy for mailbox moves, etc) a general rule is to re-run the HCW afterwards to adjust the config for the changed environment.
What is the guidance for an exchange 2007 that did a staged migration and wants to keep dirsync with passwords?
To remain supported with directory sync you’ll need to keep an on-premises server.
OK, so i need to get rid of my exchange 2007. do I follow the normal on premise upgrade path to 2013?
do I need to make it hybrid? what about EWS, do i point them to microsoft? and do i need a real certificate?
i have been searching for guidance, but have come up empty…
Thanks
Paul
Hybrid is optional. EWS configuration and certificate requirements depend on whether you create a hybrid or not.
There’s detailed coverage of identity and hybrid considerations in our book:
https://www.practical365.com/ebooks/office-365-for-it-pros/
You know we did exactly that, migrated mail to O365 with DirSync, the Exchange server on prem, i shut the Exchange server down at the end if the migration on purpose to prove that i could survive with it out. We just used a mix of AD users and computers MMC and PowerShell to edit the mail based user attributes in which the Exchange tools modify anyway. After all, all the information stored in the ‘directory’ in which you have full access to using AD or PowerShell.
What’s possible and what’s supported are two different things.
Paul,
Using third party tools such as bititan and skykick , specifically cutover migrations leaves you with an unsupported Microsoft environment. My question is “what is the recommended way to create a supported environment after a cutover migration?” The 3rd party providers don’t have a solution and Microsoft wont help with an unsupported configuration. Leaves us holding the bag. There seems to be no easy way to decommission the Old On-premise server and create a supported environment. In some scenarios the old on-premise server needs to be decommissioned.
John
If you’ve done a cutover migration, there’s no directory sync in place, therefore you can remove Exchange on-prem because you are managing cloud objects directly.
We do have Azure Connect tool in the Environment and are using SSO(same sign on).
Then that’s been added after the migration I suspect, as Microsoft’s cutover migration method doesn’t work with directory sync in place.
Yes, if you want directory sync, you need to retain the on-premises Exchange server to remain supported. That requirement should be identified early in the project planning.
I have done over 100 office 365 implementations for companies using dirsync and now ad connect installed before the cutover and migration. Just leave the msexchmailboxguid attribute out of the sync, migrate the mailboxes and do the cutover. Remove all traces of onprem autodiscover and later remove the exchange servers from AD manually (adsi edit). Its no problem at all, and in my opinion gives a faster, clean cutover. Outlook profile can easily be managed just by deploying a registry GPO “hack” to force a new profile creation on outlook startup. All attributes can easily be managed using ADUC.
I am going to test reinstalling exchange to the same AD to get the management tools, should not be too much hassle i guess.
As I replied to another comment, what’s possible and what’s supported are two different things.
Hello Paul,
Having a lightweight tool to manage these four attributes or something which can coexist with directory synchronisation server will certainly be an attractive option for customers. Microsoft certainly thinking in the right direction.