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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

Read Next

Author

Steve Goodman

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Latest Podcast

Recommended

Follow Us

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

TECHGENIX

TechGenix reaches millions of IT Professionals every month, and has set the standard for providing free technical content through its growing family of websites, empowering them with the answers and tools that are needed to set up, configure, maintain and enhance their networks.