I was recently working with a customer who were performing an organization led de-merger, for the purposes of this blog entry lets refer to them as ‘CompanyA’ and ‘CompanyB’.  Prior to the de-merger CompanyA hosted an on premise Exchange 2013 environment that both CompanyA and CompanyB utilized for the purposes of mailbox/public folder hosting. At the point of the de-merger, CompanyA were going to retain their existing Exchange environment and CompanyB were planning to move to O365.

Due to the size and complexity of CompanyB, Exchange Hybrid was used as a mechanism to facilitate the migration of CompanyBs mailboxes and public folders to Office 365.  Following on from the migration there was obviously a desire to remove the Exchange hybrid configuration to sever ties between both organisations.

When faced with this challenge, it became apparently that there wasn’t a great deal of information available around how to smoothly remove an hybrid configuration from an Exchange organisation, whilst MS walk through the process in the following technet blog entry the order in which MS suggest performing the steps required wasn’t actually possible and resulted in a number of errors.  I therefore wanted to provide some clarity around the process/ordering.  This process covers hybrid configurations in both Exchange 2010 and Exchange 2013.

Firstly I assume the following activities have already been completed;

  • All required mailboxes have been migrated off of the on-premise environment across to Office 365
  • If necessary all public folder content has been migrated across to Office 365, either to shared mailboxes or traditional public folders.
  • All Exchange related DNS entries (autodiscover,OWA etc) have been re-pointed to O365
  • All MX records for SMTP domains that are being managed by O365 have been re-pointed to O365

Once these activities have been completed we can start on the steps required to remove the hybrid config;

  1. Remove the organizational relationship from the on-premise environment as follows; ‘Remove-OrganizationalRelationship -identity “name_of_org_relationship”.  The identity of the organizational relationship can be obtained by using the ‘Get-OrganizationalRelationship’ if required.
  2. Remove the organizational relationship from the O365 tenant as follows; ‘Remove-OrganizationalRelationship -identity “name of_org_relationship”, Again the identity of the organizational relationship can be obtained by using the ‘Get-OrganizationalRelationship’ if required.
  3. Remove the federated domain(s) from the on-premise environment as follows; ‘Remove-FederatedDomain -domainname name_of_domain
  4. Remove the Email Address Policy/Policies associated with those SMTP domains that have been moved to O365.  This can simply be performed from on the on-premise Exchange admin console
  5. Remove the Accepted Domain entries from the on-premise Exchange admin console for those SMTP domains that have been moved to O365.  Again this can simply be performed from on the on-premise Exchange admin console.
  6. Remove the federation trust from the on-premise Exchange environment as follows; ‘Remove-FederationTrust -Identity “Microsoft Federation Gateway” By default the hybrid configuration wizard in Exchange 2010/2013 names the federation trust “Microsoft Federation Gateway”.
  7. Remove the remote domain associated with the Exchange hybrid configuration using the on-premise Exchange Admin Console.  This will be named something like “Hybrid Domain – tenant_name.mail.onmicrosoft.com”
  8. Remove the SMTP send connector from the on-premise environment as follows; ‘Remove-SendConnector “Connector_Name”‘
  9. Remove the inbound and outbound SMTP connectors that were created by the hybrid configuration wizard in the Exchange Online Protection Administration Console
  10. Finally remove the HybridConfiguration object from within Active Directory.  This isn’t supported in Exchange 2010 and its perfectly fine to leave the object in AD without any adverse effects.  If however Exchange 2013 is being used in the hybrid configuration, the following PS command can be used to remove the HybridConfiguration object;  Remove-HybridConfiguration

 

Once those steps are complete, all references to the previous hybrid configuration are removed leaving two separate and distinct Exchange environments, CompanyA on-premise and CompanyB in O365.

Category:
Exchange, Office 365

Join the conversation! 7 Comments

  1. That’s a nice summary. So, after all hybrid configuration is removed and we want to create a new mailbox in O365, from my understanding you have to create the user in local AD and then user EMS to do New-RemoteMailbox. However, what do you need to perform this. Let’s say the Hybrid server is decommissioned and all that is left is the DirSync (Azure AD Connect) server. Is it just a matter of installing the Exchange 2013 management tools on the DirSync server and connecting to Exchange online through powershell to do the new-remotemailbox cmdlet?

  2. Hi,

    If I may ask, does this apply in the following scenario:

    We have 2 existing 2010 exchange servers which host mailboxes and public folders in 2 different sites, same forest/organization.

    We install 2 different hybrid servers 2013 for site 1 and site 2. None of the hybrid servers have mailboxes, they are only used for transport.

    Then we want to decomission the 2013 hybrid and 2010 exch server from site 1.

    The 2010 and 2013 for site 2 must remain up and running.

    Thank you,

    P.S. sorry if this turns into a double post…

  3. I think there are some fine points missing here.

    What about identity? I assume Directory Sync was in use before the company split. Did you turn off Directory Sync and move to pure Cloud IDs and Admin Portal user management? …

    If you stayed on Directory Sync, there was probably some other infrastructure work needed to split the companies and then reconfigure DirSync/AAD Connect. And if you leave DirSync on, you need an on-prem Exchange box to manage the synced users. aka.ms/hybridkey is the site where you can get a free key to set up a virtual Exchange box just for the purposes of managing DirSynced users when you don’t have a full Exchange box on prem anymore.

  4. I really had issues following this, were using Exchange 2016 cu10, the following cmdlet do not exist:
    – Get-OrganizationalRelationship
    – Remove-OrganizationalRelationship

    Possible to advise

  5. The following cmdlets do exist in Exchange 2016 CU13:

    – Get-OrganizationalRelationship
    – Remove-OrganizationalRelationship

  6. The cmdlets changed a little but also exist in Exchange 2019 CU2

    Get-OrganizationRelationship
    Remove-OrganizationRelationship

    Often a quick way to find cmdlet changes is to just “Get-” the first couple letters of the command and then press tab to cycle through. If the cmdlet does not appear then it has been removed or completely changed. In this case “Organizational” was change to “Organization”

Comments are closed.