Migrating a standalone Office 365 tenant to Exchange 2010 (Part 8)

by [Published on 2 May 2013 / Last Updated on 2 May 2013]

The final part of this series finishes things off by ripping out the Hybrid configuration, leaving us with an empty Office 365 tenant and a standalone Exchange organization.

If you would like to read the other parts in this article series please go to

Introduction

In this penultimate part of this series all our work to put the pieces in place for a migration from Office 365 to Exchange on-premises came to fruition - we configured mail routing, then moved mailboxes from the cloud to on-premises. The final part of this series finishes things off by ripping out the Hybrid configuration, leaving us with an empty Office 365 tenant and a standalone Exchange organization.

Decommissioning your Office 365 tenant

Are you staying with Office 365 for other services?

If you are still using Lync Online, SharePoint, Yammer or other Office 365 and Azure Active Directory-integrated services you probably won't want to make any further changes, apart from perhaps changes to inbound mail routing.

If you do go ahead and remove accounts from Office 365 and you've still got data in other services, you risk losing access to that data, so spend some time making sure your users aren't using these services. If you have previously licenced the desktop version of Office via Office 365 E3 or higher plans, then you'll also need to make sure you've properly re-licenced using traditional licensing.

If you're using one of the Exchange Online only plans for your users, then you're more than likely safe to proceed as these plans do not include any services apart from Exchange.

Are you considering staying with Microsoft for Exchange Online Protection?

If you aren't planning on using Office 365 at all, your first consideration when choosing to decommission your Office 365 tenant is inbound anti-spam and anti-malware filtering. If you haven't implemented an on-premises solution, then you might find that Exchange Online Protection fits the bill.

If so then you may want to investigate this solution before taking any further steps. If you're wondering why - that's because Exchange Online Protection uses the same underlying platform as Exchange Online, meaning you may only need to make changes to licensing features within your Office 365 tenant along with a few small changes to your on-premise Exchange environment.

Verify Mailboxes are migrated

While obvious, it pays to double check you've definitely migrated all mailboxes to on-premises. We can do this by navigating to the Office 365 tenant in the Exchange Management Console and checking within Recipient Configuration>Mailbox to see that only the Tenant Administrator account remains:

Image
Figure 1:
Verification all Mailboxes are moved from Office 365 to on-premises Exchange

Changing Mail Exchanger (MX) Records

If you're looking at delivering mail to an alternative solution, or directly to on-premises, then the first step we'll need to take is to adjust the inbound MX record to direct mail away from Office 365.

We'll take the simple solution of delivering mail directly to our on-premises environment in a scenario where we've implemented a simple Edge Server to handle inbound and outbound mail:

Image
Figure 2:
An example of our intended inbound Mail Flow

We won't deal with the specifics of the setting up of an Edge Server here, but for any solution we choose we'll need to ensure we set up the following:

  • An external DNS entry for the Edge Server or equivalent. This DNS entry should have a matching forward and reverse entry, for example:
    • An A record of the IP 1.2.3.4 set as smtp.exchangelabs.co.uk
    • A PTR record for the IP address 1.2.3.4 also set to smtp.exchangelabs.co.uk
    • Firewall settings to allow inbound and outbound SMTP on port 25/TCP from any host on the internet to the Edge Server, or equivalent.

After configuring those settings and testing they work correctly, for example by attempting to connect to the Edge Server via telnet to port 25 from an internet host, and verifying the DNS settings, we'll configure the MX record for our domain:

Image
Figure 3:
Editing the inbound MX record via GoDaddy's DNS manager

While we're at it - it's certainly not going to hurt to change the SPF record for the domain also, which can simply have the include:spf.protection.outlook.com text removed and the ip4 record set to ensure it's our Edge Server, or equivalent:

Image
Figure 4:
Editing the SPF record to exclude the Office 365 mail servers.

After waiting for DNS changes to propagate, ensure you re-test inbound and outbound mail flow to ensure your changes haven't affected mail flow. If you've made any errors you can still revert back to using Office 365 for inbound mail delivery at this point and correct any mistakes.

Once you are happy that all inbound and outbound mail flow is working correctly, we can now begin to remove the configuration for the Hybrid Configuration.

Removing DirSync

First, we'll remove DirSync from the on-premises organization, and in the process remove unnecessary accounts from our Office 365 tenant.

If you followed the steps in the previous articles in this series where we performed setup of DirSync, you'll remember we used DirSync Filtering to limit the scope of DirSync to a single on-premise Active Directory OU, Office365:

Image
Figure 5:
Viewing the Organizational Unit chosen for DirSync Filtering

Although we've moved these users to on-premises Exchange, we'll still see they are within Office 365 as mail enabled users. You'll see them within the Exchange Management Console when connected to our Office 365 tenant within Recipient Configuration > Mail Contact, or in the case of Distribution Groups, within Recipient Configuration > Distribution Group:

You'll also see these users within the Office 365 portal at http://portal.microsoftonline.com:

Image
Figure 6:
Viewing users synchronized via the DirSync tool in the Office 365 portal

If you're using DirSync filtering, we can let DirSync cleanly remove these objects simply by moving them out of scope to another OU - though naturally if you are moving objects consider other implications, like Group Policies in place:

Image
Figure 7:
Moving migrated users out of scope of DirSync

After DirSync processes these changes, you'll find that all the on-premises users that were synchronized to Office 365 are now removed from the tenant, and we can choose to Deactivate Directory Synchronization:

Image
Figure 8:
Examining the results of DirSync and disabling Directory Sync

If you aren't using DirSync Filtering, then you'll also want to Deactivate Directory Synchronization via the portal at this point too as you will need to remove the orphaned accounts manually later on when we remove the shared accepted domain from Office 365.

With DirSync no longer synchronizing objects to the cloud, we can remove DirSync from the server it's installed on via Uninstall Programs and choosing to Uninstall Microsoft Online Services Directory Synchronization:

Image
Figure 9:
Uninstalling DirSync from the server

The uninstallation process should cleanly remove associated components, such as Forefront Identity Manager and Microsoft SQL Server 2008 R2 components. However, the SQL Server Native Client and, if you've installed it, the Microsoft Online Services Module for PowerShell must be uninstalled separately.

After the uninstallation, remove the account and group associated with DirSync, the MSOL_AD_Sync user and MSOL_AD_Sync_RichCoexistence group from Active Directory:

Image
Figure 10:
Removing the DirSync user accounts

Removing Exchange Hybrid Settings

We'll come back to removing settings from our Office 365 tenant in a few moments (as deactivation of Directory Synchronization takes some time) and remove the settings within our on-premise Exchange environment that were put in place by the Hybrid Configuration Wizard.

We won't be able to remove everything, as the actual Hybrid Configuration object itself cannot be removed from Exchange once implemented via supported methods; and we'll also leave the Federation Trust in place as it serves for other purposes than just for Office 365. The areas we will remove configuration for are as follows:

  • Disconnect our Office 365 session from the Exchange Management Console.
  • Remove our tenant.mail.onmicrosoft.com domain from Email Address Policies.
  • Clear the stored configuration for the Hybrid Configuration.
  • Remove the Organization Relationship to Office 365.
  • Remove remote Domains configuration for Office 365 accepted domains.
  • Remove Accepted domains exclusive to the Office 365 tenant - i.e. the onmicrosoft.com domains.
  • Remove Send connectors for outbound mail to Office 365.
  • Remove Receive connectors for inbound mail from Office 365.
  • Disable the MRS Proxy component of Exchange Web Services.
  • Remove the Availability Address Space configuration for the Office 365 tenant.

Disconnecting our Office 365 session from the EMC isn't a complicated task - and not strictly necessary to remove our Hybrid Configuration. The configuration is per-user profile therefore by removing it you are simply cleaning up your administrative view. Simply right click the Office 365 node, and choose Remove:

Image
Figure 11:
Removing the Office 365 tenant from the EMC

Next, we'll examine each email address policy by navigating to Organization Configuration>Hub Transport and selecting the E-Mail Address Policies tab. Chose each policy in turn and choose Edit:

Image
Figure 12:
Editing E-Mail Address Policies

Select the service domain email address ending in onmicrosoft.com and choose the delete it from the selected policy:

Image
Figure 13:
Removing our tenant service domain from a policy

Finally, apply the email address policy changes:

Image
Figure 14:
Application of policy changes

The rest of the clean up can be performed using the Exchange Management Shell. First, we'll clear the Hybrid Configuration:

Set-HybridConfiguration -ClientAccessServers $null -Domains $null -ExternalIPAddresses $null -Features $null -OnPremisesSmartHost $null -SecureMailCertificateThumbprint $null -TransportServers $null 

Then, we'll remove the Office 365 organization relationship:

Remove-OrganizationRelationShip -Identity "On Premises to Exchange Online Organization Relationship"

Our next bit of cleanup is to use the Get-RemoteDomain cmdlet to search for our domains labelled "Hybrid Domain " and then use Remove-RemoteDomain to delete them:

Get-RemoteDomain "Hybrid Domain - *" | Remove-RemoteDomain

We'll then remove the accepted domains. Before running this step, you'll need to make sure you've correctly updated your Email Address Policies otherwise this will fail.  We'll simply search for domains ending in onmicrosoft.com, then remove them:

Get-AcceptedDomain "*.onmicrosoft.com" | Remove-AcceptedDomain

To disable inbound and outbound mail to our Office 365 tenant via the Hybrid connectors, we'll remove them by discarding the Send and Receive connectors configured by the Hybrid Config Wizard:

Remove-SendConnector -Identity "Outbound to Office 365"

Get-ReceiveConnector "* Office 365" | Remove-ReceiveConnector

Our penultimate step is to disable remote moves. We can do this against each Client Access Server individual, or simply as we've done below, search for enabled instances of the MRSProxy and disable it:

Get-WebServicesVirtualDirectory | Where {$_.MRSProxyEnabled -eq $True} | Set-WebServicesVirtualDirectory -MRSProxyEnabled $False

Finally, we'll search for and remove the Availability Address Space configuration:

Get-AvailabilityAddressSpace "*.onmicrosoft.com" | Remove-AvailabilityAddressSpace

When you clear the config for the Hybrid object you won't receive confirmation, however for the remaining configuration changes you'll see both the results of the searches along with confirmation you wish to remove each:

Image
Figure 15:
Exchange Management Shell output from Hybrid clean up tasks

After completing these steps, your Exchange on-premises organization is exactly that, on-premises.

Removing Accepted Domains from your Office 365 tenant

To finish off our move to on-premise, we'll remove the shared domain from Office 365. By this point, we shouldn't have any users left within Office 365 that use the shared domain. We'll log in to our tenant and check by visiting the Office 365 portal, http://portal.microsoftonline.com and navigating to Management>Users:

Image
Figure 16:
Ensuring Directory Synchronization is disabled for the tenant and verification of remaining accounts

After examining the remaining users - which will typically be just the Tenant Administrator, we'll navigate to the Domains section and find our shared domain - in our case exchangelabs.co.uk and choose Remove:

Image
Figure 17:
Removing the shared domain from the Office 365 tenant

Assuming all goes well, the domain should remove cleanly. If not, examine Security Groups for any groups that haven’t been removed cleanly and the remaining admin accounts to double check they do not have an additional email address using our Shared Domain.

It's now down to you what you do with the empty tenant - keep it to one side with at least one licence within it in case you wish to use some of the great Office 365 services again, or let it expire and re-sign up at a later date; either way the choice is yours because you will be able to re-create a Hybrid relationship with a different tenant in the future, or with this one again should you wish.

Summary

In this series we've went through the full set off steps necessary to first migrate a couple of mailboxes across from an unrelated Office 365 tenant to an on-premises Exchange organization; and then we've went into a full reverse-Hybrid offboarding operation - putting in place all the apparatus to connect a new standalone Exchange environment to an Office 365 and move mailboxes across, then clean up afterwards.

If you would like to read the other parts in this article series please go to

Featured Links