Remove On Premises exchange Hybrid and go fully Online

Copper 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

123 Replies

This question rises every now and then. For short: you don't NEED an exchange server, attributes can be edited in ADUC as described in this message thread. After all, there are organizations which have never had an Exchange server and are running Office 365 (as I do).

 

AFAIK only thing you'll loose is email policies

You should be able to use policy’s as usual!
As said, the caveat is when you use adconnect to sync objects - making it more troublesome to change attributes and settings related to mail, without an on premises exchange server

Email policies (automatically assign addresses) is a feature only available in on-prem Exchange. I would like to see this feature also in EOL - at least for pure-cloud environment. Anyways, if you remove on-prem Exchange server, you will loose the email policies feature.

Alright, was thinking about overal policy’s you can use

@Nestori Syynimaa if you never had Exchange on-premises is something different because your AD objects don't have the exchange attributes and your AD doesn't have the exchange Schema. 

 

If you had Exchange Server in your on-premises AD then your AD objects have exchange attributes. That means that you are going to have conflicts if you don't follow the best practices regarding a hybrid exchange environment. 

 

 

Sure @Spiros Karampinis, it is a bit different but in practice that is irrelevant. Basically all you need is proxyAddresses attribute, which is included "normal" AD schema.

 

Again, you do not NEED an on-prem Exchange server - although this is not "supported" by Microsoft.

@Nestori Syynimaa thank you for your reply.

 

How can you guarantee that the additional proxyAddress doesn't already exist,

or if the mailNickname that you set isn't occupied by another user?

 

Worth for you the whole pre-check workload the time and your energy to avoid having one more virtual machine with 2 vCPU and 4GB vRAM and an Exchange instance installed?

Good point @Spiros Karampinis.

 

In Office 365/Azure AD all email addresses are unique. If you add an email address in on-prem AD already used by someone in Azure AD, you'll have a synchronization error and you can fix it. So, if you have a clear policy how you form your email addresses (firstname.lastname, etc.) this really isn't an issue.

 

@Keith Caines do you still have any considerations/questions regarding Exchange hybrid ?

Hi Spikar,

 

thanks for your clarification.

 

Regardless, I've since removed the on-prem Exchange last Friday and haven't yet experienced any issues.

 

I'll keep using the AD attribute editor to modify email addresses. Since we're talking about 28 mailboxes in total, I should be able to handle it without creating any conflicts.

 

Should I encounter any insurmountable problems, I guess I can always simply add an Exchange server back to our domain.

 

Regards,

Dominik

@Dominik Wagner exactly! 

 

I don't think you are going to face any problems/issues/difficulties if you know what are you doing, which I think so :) 

 

But you are definitely right, if you encounter any insurmountable problems you can easily install an Exchange Server an check the problems from Exchange sight. 

 

Just keep in mind after the installation of an Exchange server the Active Directory SCP is going to be updated/created and the outlook clients on domain-joined computers will try to connect to the on-premises Exchange server in the autodiscovery process to locate the mailbox of the user. After the installation set the Service Connection Point to $null 

 

Get-ClientAccessServer -Identity $NAME$ | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $null

 

Have a nice day

Hi Guys,

 

Did you ever consider finishing the hybrid installation off. 

 

Uninstalling exchange.

 

Uninstalling the adsync tool , stopping the sync at cloud level. Then just reset the password sync tool up using smtp matching?

 

This method would then be supported? As your not continueing with a hybrid.

I have a scenario somewhat similar. All mailboxes, DL's, and contacts are in the cloud. I'm using AADSync to sync passwords to Azure AD. All email management is done in the cloud, nothing in on-prem Exchange. What's the need to keep the on-prem Exchange other than Microsoft's "Because I said so"?

 

Some replies say that it's minimal, but it's more than that. It's an OS license, it's patch management, it's still uses resources, still needs to be backed up. There is still a lot of maintaining there. I want the on-prem gone since it's not being used.

 

Also, we don't use AD FS and all DNS records, MX, autodiscover, cname, etc, have been pointed to O365.

Basically, it’s for easier attribute creation and management and keep it a supported configuration according to Microsoft

We don't edit any of the attributes. And all management is done in the cloud. All I need AADSync for password sync so I don't have to manage another password system.

 

I'm trying to grasp why in my environment I still need Exchange outside of Microsoft saying I do. If AADSync handles the password sync to Azure AD, no attributes are modified, and all management is done in the cloud, I see no further use for the on-prem Exchange.

You still add mail addresses through either AD or exchange if users are synchronized! You can manage this without exchange via attribute editor or adsi edit if the attributes are there since a prior exchange installation though!
AFAIK MS still requires an exchange server in this scenario for it to be supported! I belive MS gives a free license for this as well, as long there’s no mailboxes on premises

After creating an AD user, we wait until the account has synced to the cloud, then add the email address in the cloud. We don't add the email address using ADU&C or on-prem Exchange ECP. In fact, we don't even use the on-prem Exchange ECP anymore. This is where the difficulty in grasping the concept if keeping the on-prem Exchange is coming in. AS previously mentioned, ALL email management is now done in the cloud, nothing is done on-prem.

@BrianSmith as ae mentioned before the Exchange on-premises is required to be on supported from Microsoft track. However you can still uninstall the last Exchange Server and manage your users on the cloud and keep the AAD sync active, please update to AAD Connect if you still use AAD Sync. The reason of keeping one Exchange on-premises is to keep the same AD attribute update/changes that are happening after Microsoft update/upgrade the Exchange Servers in O365. If you miss th Exchange on-premises you will miss any changes that will come in the future and that may lead to problems. Is your environment, so your call. :)

@BrianSmith wrote:

I have a scenario somewhat similar. All mailboxes, DL's, and contacts are in the cloud. I'm using AADSync to sync passwords to Azure AD. All email management is done in the cloud, nothing in on-prem Exchange. What's the need to keep the on-prem Exchange other than Microsoft's "Because I said so"?

 

Some replies say that it's minimal, but it's more than that. It's an OS license, it's patch management, it's still uses resources, still needs to be backed up. There is still a lot of maintaining there. I want the on-prem gone since it's not being used.

 

Also, we don't use AD FS and all DNS records, MX, autodiscover, cname, etc, have been pointed to O365.


I can only say that, so far, about 2 months into the transition I don't miss the on-premise Exchange server at all.

 

I've gotten used to simply managing our AD accounts using the attribute editor and syncing everything using AAD.

 

Of course, I don't know how things might eventually evolve over those next few years..maybe there'll be indeed a server-side change on Microsoft's part which would eventually require an on-premise Exchange server for necessary AD schema additions..but I'll cross that bridge when I come to it.

 

Like you said, keeping an on-premise Exchange around, even if just for management purposes, is just too much of a hassle and completely negates the primary motivation of moving everything to the cloud in the first place.

 

I really hope Microsoft corrects their stance on this particular issue, it really is quite bewildering. 

Being that I still have an on-prem Exchange server, I have not had the need to edit any attributes. Without the on-prem, what attributes are needing to be edited?