After an Exchange Online migration, what comes next?

You deserve a pat on the back after moving your mailboxes to Office 365, but your work isn't done until you finalize the project's end goal.

An Office 365 migration has many moving parts -- configuring coexistence, synchronizing directories, enabling access...

to new services and making sure mail continues to flow. After moving mailboxes to Exchange Online, you deserve a pat on the back. But what comes next?

The final part of moving email to the cloud often requires decommissioning what remains of your on-premises Exchange infrastructure. You need to be clear about the desired result of the project. Are you looking to completely remove email-related infrastructure? Or do you want to keep minimal infrastructure around for management and relay purposes?

Each option has its challenges, but knowing the end goal will help you decide what the steps are between finishing the Exchange Online migration and moving to the next project.

Decide whether to remove Exchange

Because your mailboxes moved to Exchange Online, your goal should be reducing the footprint of your on-premises Exchange infrastructure to a bare minimum or removing it entirely.

Initial candidates for immediate removal should include legacy Exchange servers. This involves versions older than Exchange 2010 that no longer participate in client or email communications as well as Exchange Mailbox Servers that no longer host mailboxes.

When it comes to removing the remaining parts of Exchange -- which includes those falling under hybrid roles, such as mailbox management, client access and mail delivery -- tread carefully. These components may still be a critical part of your infrastructure after your Exchange Online migration.

Inbound and outbound mail delivery

If you have no reason to keep mail flowing through on-premises Exchange after your Exchange Online migration -- for example, you don't have a compliance option that captures messages flowing inbound and outbound -- the first task should be changing mail flow to arrive directly in Office 365.

If mail delivery flows inbound through on-premises Exchange and flows outbound from Office 365 directly to the Internet, you don't have much work to do. You can consider switching your DNS Mail Exchanger (MX) records to point directly to Office 365.

Manage Hybrid Configuration
Figure 1.

If you currently used centralized transport with all inbound and outbound mail from Office 365 flowing through your on-premises Exchange infrastructure, you'll want to make an additional change. You'll need to run the Hybrid Configuration Wizard and ensure you change the Mail Flow Path to Deliver Internet-bound messages directly using the external recipient's DNS settings (Figure 1).

After applying the hybrid configuration, changes to Exchange Online Protection will ensure the outbound connector for the scope of on-premises mail flow no longer includes all domains.

AutoDiscover services

During an Exchange Online migration, clients discover if their mailbox is located (on-premises or in Office 365) using the AutoDiscover service.

After an Online 365 migration, clients such as Outlook will still contact your on-premises Exchange servers to rediscover information. This works differently for domain-joined and non-domain-joined clients. Domain-joined clients will initially look at Active Directory to discover a service connection point before trying other methods. Non-domain-joined clients will use DNS records, looking at the domain name first looking at an AutoDiscover A/CNAME record in the domain and finishing with DNS Service Records (SRV).

The service connection point is configured against each Client Access Server and can be cleared using the following PowerShell syntax:

Set-ClientAccessServer <ServerName> -AutoDiscoverServiceInternalUri:$null

DNS records
Figure 2.

This leaves the AutoDiscover DNS records. If you currently use a SRV record, use this opportunity to discontinue its use. For others using the standard domain-based AutoDiscover record, update it to point at Office 365 (Figure 2).

You should not see negative effects after making these changes, since AutoDiscover redirects your on-premises clients to the same place. What these changes will do is remove an on-premises dependency and simplify any required troubleshooting.

Point URLs to OWA after Exchange Online migration

Now that all users are using Office 365, consider moving your old Outlook Web App (OWA) address to point directly to Office 365. This is an easy job that involves a DNS record update.

When running Exchange on-premises, you'll typically publish OWA to the outside world using a DNS name pointing at an SSL-secured website users need to log in. In Office 365, your default URL for accessing OWA is slightly different. Users can log in to on-premises OWA and get a redirection link to Office 365, or they can directly access https://outlook.com/owa/your-domain.com.

If you want to allow users to use your original webmail.your-domain.com style address, simply change the DNS entry so it's a CNAME record that points at outlook.com. End users will be automatically directed to the correct sign-in page for your domain, whether that's logging in directly against Office 365 or via an Active Directory Federation Services server.

Continuing mailbox management with DirSync

If you use Windows Azure Active Directory Sync (DirSync), you probably won't want to switch this off after your email is in Office 365. DirSync will continue to ensure new accounts in Active Directory are provisioned, updated when changes are made and can also manage password synchronization.

Users who are synchronized on-premises are mastered on-premises. This means you can't manage mailboxes for Office 365 users and need to set the required Active Directory attributes on-premises. If you're not sure what this means, think about the common scenario involving a person with a secondary email address. With DirSync in place, that change must be made on the local Active Directory, typically on an Exchange Server by managing their remote mailbox.

You might also assume you'll be able to perform these tasks just by installing the management tools on their own. There are some hacks to get around it, but there isn't an officially supported way to do so. The Exchange Management Console for Exchange 2010 and the Exchange Management Shell both use PowerShell and need to connect to an Exchange Server.

What you could do is use free hybrid licensing from Microsoft Support to retain a non-critical Exchange Server for mailbox management. This will participate in a basic hybrid configuration with Mail Flow and Client Access directed at Office 365, but it's not a part of your infrastructure accessed by end users.

Mail relay for devices and application servers

Although you've moved mailboxes to the cloud and your standard clients send email directly through Office 365, you'll likely have a few other devices that need to send mail. These typically fall into a few categories:

  • Application systems, including CRM and financial systems that email reports;
  • Monitoring alerts, including network switches, storage systems and service desk systems; and
  • Office devices, including multifunction copiers and scanners that send mail via SMTP.

All of these systems present reconfiguration challenges, since Office 365 automatically expects these systems to support authenticated TLS or SSL to send SMTP. It's also highly unlikely that you'll already allow network devices to send mail directly on port 25 to the Internet.

Exchange admin center
Figure 3.

You do have a few options. The first and simplest option is to create inbound connectors for on-premises relay in Office 365's Exchange Admin Center (Figure 3). This will allow you to specify the domains that devices can send to, accepted domains they can send from, whether traffic must be secured by TLS and what external IP addresses to relay mail from.

This flexible option requires you to allow these internal devices to access Office 365 on port 25 for SMTP and requires device reconfiguration to relay mail through the Office 365 Mail Exchanger (MX) record address, commonly in the form your-domain-com.mail.protection.outlook.com.

IIS 6.0 Manager
Figure 4.

If you prefer having an on-premises point that devices relay though, consider using the Internet Information Server (IIS) built-in SMTP server (Figure 4). This will allow you to have a simple drop-in replacement for the Exchange servers previously used, which could enable you to avoid reconfiguring devices.

You can pair up IIS's SMTP relay with the aforementioned inbound connectors to ensure all relayed mail from your organization flows through Office 365.

The final option is worth considering if you decide to retain a hybrid server on-premises for mailbox management, which you could also use to fulfill your relay requirements. You'll be able to use your existing configuration from your old Exchange Servers and relay the mail out through Office 365.

About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.

Dig Deeper on Exchange Online administration and implementation