Remove On Premises exchange Hybrid and go fully Online

Highlighted
Occasional Contributor

Hello,

 

I currently have a scenario where there is a Hybrid Exchange environment with 1 server. All my mailboxes have been migrated online.

 

I would like to completely remove dependency on local AD and I do not care about AD synchronization.

 

How do I "tell" the O365 tenant not function on it's own so that I can manage 100% from 365 Administration?

 

I do understand that my MX and other DNS records will need to be changed.

 

Are there any solid guides out there on decommissioning the on premise exchange server. I want to do this with the least impact on users.

 

Thanks,

 

Keith

120 Replies
Highlighted
I've just done some research and it looks like I need to run

Set-MsolDirSyncEnabled –EnableDirSync $false

Apparently this will change all my Mailboxes to "In Cloud" instead of "Synced with Active Directory"

At this stage I assume I will be able to manage mailboxes from the Office 365 Tenant.

Am I correct in saying that my next step would be to change my DNS to point mailflow to 365, or is the something else that needs to be done to take the on-premises "hybrid" server out of the equation?

Thanks!
Highlighted

Everything you need to know right here ..

 

https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx

 

If you have removed Azure AD Connect then you can remove on-premise Exchange. It's the presence of this component that would necessitate keeping an on-premise Exchange Server for mailbox management

Highlighted

Sorry Ian, but that is incorrect.  We ourselves, as well as the majority of our clients, run Azure AD Connect WITHOUT an on premise exchange server.

 

I use AD to create users inside my Active Directory for old LAN drives (shares) and local printers.  I set their password there -

 

I then use Office 365 to provision and maintain their mailboxes without issue. 

 

Under what scenario/functionality are you thinking a local Exchange Server is required?

Highlighted

Well, the main scenario that springs to mind is that removing the last Exchange server puts you in an unsupported environment ..

 

https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx

 

Of course you can use tools such as adsiedit etc to modify Exchange attributes of your local accounts prior to sync - but again, unsupported.

 

If you are still using Azure AD Connect to sync your accounts to the cloud then the only supported way to manage recipients is with a local Exchange Server. That may change but to my knowledge that hasn't happened - yet.

 

 

 

 

I'm sorry - still not seeing it.  It says "not recommended" - can you explain the part where it is actually "required"? 

 

Or more importantly - are you saying that I cannot change the email address for a user from Active Directory console or add an alias (which I can)?  Or update their manager, or address, or title? (Which I can)

 

I'm trying to find someone from @microsoft.com that says it's not supported.  But everything I read, its a MVP or someone not from the company saying it's a requirement.  Should be easy to find in official documents no?   Alas - there is nothing about it in AD Connect pre-requisites, and Microsoft only says its required "during hybrid" but I have yet to see an actual document state its required even after your hybrid deployment is complete.

 

Happy to be wrong - I just haven't seen it yet - 

Highlighted

"The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. 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. If you decide to use third-party management tools, it would be at your own risk. Third-party management tools often work fine, but Microsoft does not validate these tools.."

 

Seems pretty clear to me. YMMV

Highlighted

Hey Joe,

 

Question of whether it is supported or not aside, I was wondering how you are managing things like adding an alias, etc?  I have always done this through the EAC in our environment.  The last time I think I saw the ability to modify Exchange attributes through AD Users and Computers was back with Exchange 2003.  Am I missing something, or are you using ADSIEdit?  Thanks!

Highlighted

Hello Steve,

 

you can modify Exchange attributes / settings over Active Directory Users and Computers (ADUC) console. Open ADUC, hit View, Advanced Features, select a user and change to Attributes tab. Here you could change the mail alias by changing the mailNickname attribute.

 

For the changes to be reflected in your O365 Tenant please wait or force the next Azure AD Connect sync.

 

Kind regards

Spiros

Highlighted
As Spiros says - we simply use AD Users and Computers to edit our Exchange properties for O365
Highlighted

Hi Keith,

 

Been through the comments in your thread and reminded me of my previous project where the customer stated to go fully online after moving the last mailbox to the cloud since they were using a hosted mailbox solution and had to continue paying if they wanted the hybrid to remain.

 

We did the following

1. Remove the hybrid relationship between the hosted exchange and the Office 365

2. Change DNS records to fully go O365 based ( autodiscover, SPF, DKIM, MX )

3. Update the  AAD connect to only use the the current primary AD Forest for sync.

 

The customer's team had no issues in updating required attributes using AD. But Microsoft FastTrack came back stating that if we do the O365 with only an AAD Connect in place and no exchange server then it puts us in an Un-Supported platform when you call Microsoft for any help.


What they suggested is that you need to have Exchange installed atleast to make sure that your Schema supports the right attributes and that the exchange server should be used to provision the mail enabled accounts so that the right attributes are synced to the cloud.

 

I do have an email from FTC, but unfortunately cannot share it in public as the information contains customer sensitive information in it.

 

To end the story with that customer, we ended up installing a minimal exchange server and back to hybrid configuration to make sure that the configuration is still supported.

 

Not sure what you would gain by removing that exchange server unless its a high dependency on some resources, costs etc, i would suggest to leave the hybrid ON. It can also be used as an email relay within the organization. You can trim down the hardware and give just the bare necessary requirements in it.

 

Hope my previous situation and its outcome helps you.


Regards,

Prashant

Highlighted

Gentlemen,

Thank you for this valuable info first of all. Secondly, I am with the school of thought that you can keep managing attributes in AD especially the mail ones like proxyAddress and targetAddress attributes. Having your last Exchange server around is unnecessary to me personally as the simple process of create accounts and syncing attributes is simple enough to provision mailboxes in Exch Online.

However, I can assume why Microsoft has given us a blanket answer for keeping ONE last Exch server around. The answer being that while MS goes around updating exchange server versions behind the scenes for all the client tenants. They may introduce new attributes (perhaps?) that only Active Directory may not house. I am talking about msExch attributes which is a big deal. Having a gap say between customers decommissioning from an Exchange 2013 hybrid while Exch Online will be running 2019 for a customer tenant. This is a dangerous gap to have... wouldn't you all agree? With having one exch server around, the onus will be on the customer to eventually upgrade the AD schema and employ such newer attributes to take advantage of features in Exch online. I hope I make sense in my assumption. What are your thoughts?

Highlighted

Everything you say makes sense, but it all comes down to running an environment supported by Microsoft. This may or may not matter in some scenarios but for me anyway I'd rather be managing a supported setup.

 

I'd highly recommend having a look for Hybrid related sessions coming out of Ignite 2018 as the story may have changed somewhat.

 

Ian

Highlighted

I am just now looking into doing a O365 migration and when you look at the MS documentation they really push the Hybrid path for any site over 150 users, but it doesn't talk in the migration planing guides about the issues with decommissioning.  Only because I am doing a lab setup and I am getting to the decommissioning faze with that, that I running across this.  

 

It seems like if this is the migration scenario they are going to push they need to do some more work on getting it so you can really do a clean cut at the end.

Highlighted

Hi Prashant.

 

In the scenario you described and concluded by asking "Not sure what you would gain by removing that exchange server" I would like to in turn ask what do you gain or lose by removing that server?

 

We want to remove as much of our On-Prem as possible and my task is to decommission our On-Prem Exchange altogether and rely solely on the cloud. 

 

Thanks,

Carlos

Highlighted

Hi Carlos,

 

Like you have mentioned, the only gain is to have 1 / 2 less server (s) to manage.

 

Downsides : - have seen them happen with customers

1. When we remove the server, then the SD or L1 guys who were used to provisioning mailbox/remote-mailbox or mail user with the exchange console will have to resort to manually populating the attributes (ADSIEDIT), which can be bothersome and some SD agents who are really beginners may not be comfortable doing that.

 

2. have had a detailed email from the FTC (fast track center) {we had planned and executed this for one customer like that} that removing the last server may be technically feasible, but MS PSS does not support when a customer has removed the last exchange server in hybrid and they "informed" in the email that to be supported by MS PSS we would have to re-install the hybrid server again.

 

Personally, if you ask me i would retain 1 single machine (which these days can be a high end laptop/desktop) to be in supported model rather than have nasty surprises when calling MS when you are in deep trouble with EMAIL system for something else.

 

Regards,

Prashant D

Highlighted

I have found this thread very interesting. We are in a situation where our on prem server is so old it's no longer supported. Therefore, we've been looking at decommissioning it. So we're partly not supported anyway!

 

Regards 

Pete

Highlighted

Hello Carlos,

 

it is pretty clear at the moment that maintaining one last Exchange server just for management purposes is the supported way to go when you like to synchronize your active directory users and their attributes to Azure AD. 

 

Sure many guys are going to say that you can use ADSI, third-party tools or even nothing to manage your Exchange users in Office 365 BUT the question is, is it really bothering you to keep a last virtual machine with 2 CPUs and 4 GB RAM to be in a supported scenario for your business critical application like mailing ? It will be also more comfortable for your exchange administrators or even just system administrators to manage your exchange objects, even those are in the cloud, Office 365, or on-premises like function mailboxes. Keep in mind that for that purpose the Microsoft provides an Exchange hybrid key to license your on-premises Exchange server. That on-premises server could also be used as SMTP server for on-premises devices like FAX or printers or even on-premises applications that need an SMTP server to send e-mails, think about your NAS System, your firewall etc. 

 

If on the other hand, you would like to go FULL Cloud there is also an option for "small" companies called Microsoft 365 Business. With that license you can join your devices to Azure AD, your mailboxes are hosted in the cloud, you don't have to synchronize anything and you can manage your computers and devices through Microsoft Intune. Almost no server at all on-premises, but again, it depends on your environment, the use case and what are you trying to achieve. 

 

If you don't mind to provide me few more information around your environment, even in a personal message, and I would be glad to share with you my experience and talk about what were the best options for your environment. 

 

Kind regards

Spiros

Highlighted

I'm in the last steps of our migration from on-premise Exchange Server 2016 to Office 365.

 

I am honestly very surprised that demoting your on-prem Exchange server after moving all content to the cloud is an unsupported scenario.

For me at least, reducing our on-premise Windows and Exchange server footprint was one of the major reasons for migrating to the cloud in the first place.

 

Keeping a resource hog and patch management nightmare like Exchange server around in order to manage my cloud email accounts seems to defeat the entire purpose of moving to the cloud in the first place.

 

I'll go the unsupported path, decommission the on-prem Exchange and simply manage my user accounts using the attribute editor from Active Directory Users and Computers.

 

The handful of instances where I had to rely on Microsoft's paid support were really not worth the bother, so nothing ventured, nothing gained, I guess? 

Highlighted

Hello @Dominik Wagner,

 

it is not exactly that way. Unsupported is only the scenario where you have Azure AD Connect tool synchronizing your on-premises Active Directory objects to Azure AD and also those objects are mail-enabled objects. If you don't synchronize your on-premises AD objects, for password sync etc, then you can just remove the last Exchange Server. 

 

If on the other hand, you are on the need of synchronizing your on-premises AD objects and those are also mail-enabled objects then you should keep at least one hybrid Exchange Server on-premises. That Exchange Server, could be also a brand new Exchange 2016 with a hybrid key that you obtain from Microsoft at no cost, is not going to be any nightmare as you describe because you are not going to have any productive e-mail objects, like mailboxes, on that server. Either the cumulative updates should not be installed so often like in a production server because that server is there only for management purposes and does not host any critical e-mails objects. Either if that server gets destroyed or doesn't boot after a failed configuration-update it does not matter. Just install a new one and we are back in the game. 

 

Please allow me to answer all your considerations if more exist. 

 

Have a nice day mate

 

Kind regards,

Spikar