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

Thanks Dominik. That article is very enlightening. But it brings me back to my original question. If I create email addresses for new accounts, add aliases, hide email addresses, do all email management in the cloud, what is the purpose of the on-prem Exchange server, other that to be in a "supported" configuration? In my opinion, at this point, the on-prem is totally useless since NO email management is done on-prem through AD or Exchange.

 

I create a new account in on-prem AD, AAD Connect syncs it to Azure AD, I go to the O365 cloud console, add a license to the new user account, and it's done. Nothing done on-prem. This is why I don't understand why Microsoft is trying to force me to keep an on-prem Exchange server, "free" or not.

Just to give you some examples about what you may not be able to configure with Azure AD Connect in place without Exchange on-premises, try the following over Exchange Admin Center in O365 :

 

  1. Hide a mailbox from the address book 
  2. Update mailbox alias
  3. Add or edit an SMTP address
  4. Change mailbox delegation settings

 

Please share with us the results of those actions, I would also be glad to have your thoughts regarding the results. 

 

Thank you

 

Kind regards

Spikar

I will have to lab this to find out considering my on-prem is still in active hybrid mode.

 

I can currently do all of those in the O365 Exchange Admin Console, so I will have to see what I'd lose, if anything, by decommissioning a hybrid on-prem Exchange.

Brian you dont have to remove anything to check those four points, just try to update a mailbox that is in Office 365 but the user is synced from on-premises AD over Office 365 Exchange Admin center and let us know the result.

Thank you
Spikar

In that case, I've been doing that since we completed the migration and moved all of the DNS entries to the cloud. As previously mentioned, we do ALL email maintenance in the cloud, on-prem is never touched anymore. The only thing our on-prem is currently doing is an SMTP relay for a service that is about to be decommissioned in the next 4-6 weeks.

 

I'm not trying to beat a dead horse, just wanting total clarity and justification for decommissioning my hybrid mode without negative effect, other than Microsoft not supporting us. We use a 3rd party for Office 365 support, not Microsoft.

I think what Spiros is trying to find out is how exactly are you doing things now, because if you try to set some attributes directly in Office 365 it often will show an error that your attributes should come from local AD/Exchange as you sync your users and attributes from local AD via AD Connect. So, you could just give an example. Say last name of a user changes and you need to add an alias with a new name. Describe step by step how you do it.

 

On my last job we had on-prem Exchange (which was actually outsourced to local cloud provider, but it was in our network), then we had setup hybrid and migrated mailboxes and settings to Office 365. All mail related DNS, MX records now point to Exchange Online. Then we have uninstalled on-prem Exchange (but Exchange schema is already in our AD). And then we did everything like described in the article Dominik shared. We create new user with email UPN and correct SMTP value in local AD, it then gets synced with AD Connect to Office 365, then assign a license and then mailbox gets created in a few minutes. If new alias is needed, we go to AD, edit ProxyAddresses attribute, add new smtp:.. value, it gets synced to Office 365 and new alias works. If i tried to edit/add alias via Office 365 EAC it would fail with error that i need to do this on my local AD/Exchange. Although some things still work via Office 365 panel, like creating shared/room mailboxes (it still shows an error, but mailbox is created and functions), adding delegates, full access. Maybe it is possible to do everything in Office 365 by having AD writeback enabled in AD Connect, but as it required Azure AD Premium license we didn't try it (and i would be wary to let AD Connect to alter local AD).

To test your request:

  1. Created O365 Test UPN:o365.test@emaildomain.com, in on-prem AD, not on-prem Exchange
  2. Synced changes to Azure AD
  3. Found new user account in O365 admin portal, assigned license
  4. Waited for mailbox creation
  5. Sent email to test account, responded back
  6. Changed on-prem AD user from O365 User UPN:o365.user@emaildomain.com
  7. Synced changes to Azure AD
  8. Confirmed username change in O365 admin portal
  9. User email address still shows as o365.test@emaildomain.com
  10. O365 ECP shows primary email address as o365.user@emaildomain.com, no o365.test@emaildomian.com as an alias
  11. Attempted to add o365.test@emaildomian.com as an alias and received the message that it was unable to to so

Ok, so this is a scenario we have not run into before and exactly why I was digging deeper. I looked in my on-prem ECP and didn't see the new test user so I could modify the alias. Should I be creating the accounts in on-prem ECP so that Exchange attributes will be added to the account?

You also have to change email address in General tab in AD profile and then go to Attributes tab (don't remember the exact name now, and it only shows if Advanced setting is enabled in AD console) and change ProxyAddresses>SMTP value (delete old, create new). Usually we change SMTP to a new value and then create smtp with an old address, so customers can still send emails to the old address. It can take some time for everything to sync and start working. New alias usually works right away for receiving emails, but sometimes can take hours or a day until it is being used as a sending address.

It's your call to whether create users from ECP or from AD (if you uninstall Exchange). When you create users in AD, they still have Exchange attributes as AD schema is already altered and has them.

Hi Brian, apologies if this has been answered, but i think the below is microsoft's stance on it. I use directory sync without an exchange server because for small business's it doesn't make sense to keep an exchange server running, were resources are finite. 

 

"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."

 

taken from: 

 

https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange

 

 

This is something new i learnt today :) https://www.itpromentor.com/remove-hybrid-keep-sync/

The Windows Server Essentials Experience Role is something i havent fiddled around with.. but really cool for end customers who want to throw out as much possible from on-premise :)

Need to urgently fiddle with this in my lab now..

Great share @DominikWagner ..

Hello,

 

Hope these links below add some value to this discussion.

 

How & When to De-commission Hybrid: https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange

 

 

can't manage the attribute msExchHideFromAddressLists  from Office Admin Panel.: https://social.technet.microsoft.com/Forums/office/en-US/89b424a2-85fa-4b6b-b3b2-71eae2455556/msexch...

 

Hide from Address List in Dirsynced environment: https://www.tachytelic.net/2017/11/office-365-hide-a-user-from-gal-ad-sync/amp/

 

The only reason why Microsoft recommends to keep 1 CAS server/Exchange Hybrid (Free version) is to keep MSexch attributes intact. Once you de-commission Exchange, it removes those attributes from AD as well. However since you have AD Connect sync running the source of authority for the synced objects is on-premise & without those attributes it becomes hard to manage objects at times. Not everyone is a pro when it comes to modifying objects using ADSIedit or PS.

 

 

 

Depends what attributes you are talking about. Most can be done via regular AD console >Attributes editor (no ADSI or PS needed).

@Deleted wrote:

 

The only reason why Microsoft recommends to keep 1 CAS server/Exchange Hybrid (Free version) is to keep MSexch attributes intact. Once you de-commission Exchange, it removes those attributes from AD as well. However since you have AD Connect sync running the source of authority for the synced objects is on-premise & without those attributes it becomes hard to manage objects at times. Not everyone is a pro when it comes to modifying objects using ADSIedit or PS.


My question to this is: what makes it any different than if I never had Exchange on-prem and started using Office 365? The Exchange attributes wouldn't be attached to the user objects anyway. If all maintenance is to be handled in the cloud, why are the on-prem Exchange attributes needed?

@BrianSmith if you only create users in Office 365 (not syncing from local AD) then such requirement is not applied. But i guess there can be a scenario, that you use AD, never used Exchange and want to sync your AD users instead of creating them in Azure AD. I guess in that case you would have to install Exchange on-premise for such hybrid setup.

2019-03-05 12_43_30-Reply to Message - Microsoft Tech Community.jpg

@Deleted :  Decommissioning the last exchange server should not revert the Schema and the msExchange Attributes are still available to be used. The only difference is that you wont have any Exchange Console to do that modification process and also to ensure that the Uniqueness of the SMTP is maintained as mentioned by somebody else earlier in this post.

@Dominik Wagner I agree completely with the idea that moving to the cloud and decommissioning the on-premise Exchange server regardless of whether or not Azure AD sync is enabled or being used should be a supported scenario. I mean my lord MS has done nothing but shove moving to the cloud down our throats so why not create a scenario where we can succumb to this methodology once and for all and get rid of our on-premise servers completely? Makes no sense. I think, in the future, we will see this very thing they're just ignoring the obvious for now as they figure it out. Also, for the record, I like Azure AD sync for one reason and one reason only: single sign-on for our users with their new O365 licenses and applications for all their devices. We setup Azure AD sync immediately and then start buying subscriptions and pushing out the applications to the users. We can say "use your normal email address and password to activate" and the users can manage this without a support ticket being created. This is the REAL benefit of Azure AD sync. Sure, all my clients have on-premise Exchange currently and I'm trying to figure out the best method for upgrading to the cloud and all of this seems WAYYY to f****** complicated for what should be a simple process. They want the recurring monthly revenue model, yet still make it a pain in the a** to migrate!

 

I have several Exchange servers in Hybrid configuration and I now believe this was a mistake. I should have simply created the cloud account(s), added the subscriptions, created the mailboxes and configured their Outlooks (after updating DNS records). Then I could just import their PST files. I did this exact scenario last week for a two user client and it worked perfectly. So for a 25 user or less client this is the method I would choose moving forward. However, now I have several Exchange servers that I'm scared to death to uninstall the Hybrid Config or decommission because I followed (blindly) the MS migration instructions and did as they said. STUPID and I should have known better. My way worked much better and faster. I guess I could manually cleanup Azure AD and delete all the accounts and start completely over with the clients I've already setup under Hybrid after removing Azure AD Connect and Hybrid Exchange, but seriously?? Has anybody tried to back out of this configuration yet and just start over? Something tells me THAT is definitely not supported. ha!  

Well, if you don't need local AD for anything, you can move to using only Azure AD after using Hybrid. Decommission Exchange, remove AD connect, decommision local AD, start creating users in Azure AD. You might first also Azure AD join all PCs. SSO should work also without local AD for Office 365 apps. I haven't tried this practically, but i think this should work. Hybrid is only forced to have something to edit Exchange settings of synced users.
Since you already have Azure AD Connect server, just upgrade it to 4vCPU, 8 GB RAM and 60 GB HDD and install exchange 2016 and Run HCW, just to license this server (https://practical365.com/exchange-server/how-to-licence-exchange-hybrid-servers/)
Now after updating MX,CNAME and TXT record you can remove the hybrid config (https://www.agileit.com/news/remove-hybrid-configuration-exchange-server-2010/) and decomm your server.