Introduction

A migration to Office 365, especially for a larger organization has a lot of moving parts – configuring coexistence where required, synchronizing directories, enabling access to new services and of course making sure mail continues to flow. After moving mailboxes to Exchange Online, you’ll deserve a pat on the back. But what comes next?

You’ve migrated – now what?

Often the final part of your project to move email to the cloud is decommissioning what remains of your on-premises Exchange infrastructure. It’s here where you need to be very clear about what the end-goal for your project is:

· Are you looking to completely remove any email-related infrastructure?

· Or, do you want to keep some minimal infrastructure around for management and relay purposes.

Either option has it’s challenges but first ensuring you have an idea of what the end goal is will help you decide what the steps are in between finishing the migration and moving on to the next project.

To remove Exchange, or not to remove Exchange

If all your mailboxes have been moved to Exchange Online, your goal should be to, at a minimum reduce the footprint of your on-premises Exchange infrastructure to a bare minimum, or better still – remove it entirely.

Obvious initial candidates for immediate removal include legacy Exchange servers – versions older than Exchange 2010 that no longer participate in client or email communications, and Exchange Mailbox Servers that no-longer host mailboxes.

When it comes to removing the final remaining parts of Exchange – those that fall under the “Hybrid” roles, such as mailbox management, client access and mail delivery, we need to tread a little more carefully. After migration to Exchange Online, these components may still be a critical part of your infrastructure.

Inbound and Outbound Mail Delivery

If you have no reason to keep mail flowing through on-premises Exchange (for example, you don’t have a compliance solution capturing messages as they flow inbound and outbound) then first on your list should be changing mail flow to arrive directly in Office 365.

If mail delivery only flows inbound through on-premises Exchange, and already flows outbound from Office 365 directly to the internet, then you don’t have a lot of work to do. You can consider switching your DNS Mail Exchanger (MX) records to point directly to Office 365.

Figure 1: Example MX records for delivering mail direct to Office 365

If you currently used “Centralized Transport”, where all inbound and outbound mail from Office 365 flows through your on-premises Exchange infrastructure, then you will want to make an additional change first. You’ll need to re-run the Hybrid Configuration Wizard and ensure that you change the Mail Flow Path to Deliver Internet-bound messages directly using the external recipient’s DNS settings.

Figure 2: Updating the Hybrid Config in Exchange 2010 to disable Centralized Transport

After re-applying the Hybrid Configuration, changes will be made to Exchange Online Protection to ensure that the Outbound Connector for on-premises mail flow’s scope no longer includes all domains:

Figure 3: Exchange Online Outbound Connector to On-Premises, with only the accepted domain remaining in-scope

AutoDiscover Services

During a Hybrid Migration, clients discover where their mailbox is located – whether that’s on-premises or in Office 365 – using the AutoDiscover service.

After migration to Office 365, clients like Outlook will still regularly contact your on-premises Exchange servers to re-discover 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 the methods mentioned below.

· Non-domain joined clients will use DNS records, looking at the domain name first, then an AutoDiscover A/CNAME record within the domain before trying 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

This now leaves the AutoDiscover DNS records. If you’re currently using a SRV record, then you should use this opportunity to discontinue it’s use and; and for others using the standard domain-based AutoDiscover record it’s time to update that to point at Office 365, as shown below:

Figure 4: Example of the AutoDiscover record within the Office 365 portal

After making these changes you should not see negative effects, as your clients will have already ended up being redirected by AutoDiscover on-premises to the same place. What this will do is remove an on-premises dependency and simplify any troubleshooting required.

URLs used to access OWA

Now all users have moved to using Office 365, you might want to consider moving your old Outlook Web App address over to point directly to Office 365. This is an easy job that just involves updating a DNS record.

Typically when running Exchange on-premises, you’ll have published OWA to the outside world using a DNS name such as webmail.your-domain.com which points at an SSL-secured website users need to login to.

In Office 365, your default URL for accessing OWA is slightly different. Users can either login to on-premises OWA and get a redirection link to Office 365; or access https://outlook.com/owa/your-domain.com directly.

If you’d like to allow your users to be able to use your original webmail.your-domain.com style address, then simply change the DNS entry so that it is now a CNAME record that points at outlook.com.

Figure 5: Accessing Office 365’s OWA using a custom URL

End users will then be automatically directed to the correct sign-in page for your domain; whether that is logging in against Office 365 directly or via an AD FS server.

Ongoing Mailbox Management with DirSync

If you’re using Windows Azure Active Directory Sync as many organizations are, then you probably won’t want to switch this off after your email is in Office 365. DirSync will continue to ensure that new accounts in Active Directory are provisioned, updated when changes are made and with the latest updates, may also be managing password synchronization.

Users that are synchronized on-premises are “mastered” on-premises. This means that you can’t manage mailboxes for users in Office 365, and instead need to set the required Active Directory attributes on-premises. If you’re not sure what I mean think about this common scenario – a person has a secondary email address added. 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 that just by installing the management tools on their own you will be able to perform these tasks. Although there are some hacks to get round it – there isn’t a supported way to do that. The Exchange Management Console (for Exchange 2010) and Exchange Management Shell both use Remote PowerShell and need to connect to an Exchange Server.

Figure 6: Managing Cloud Mailboxes from the Exchange 2010 Management Console

What you could do, however is use free Hybrid Licensing available from Microsoft Support to retain a non-critical Exchange Server used for Mailbox management. Whilst this will participate in a basic Hybrid configuration, with Mail Flow and Client Access all directed at Office 365 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, like Outlook and Mobile Devices now send email direct through Office 365, it’s likely that you’ll have a few other devices hanging around that need to send mail.

These typically fall into a few categories:

· Application systems, like CRM or financial systems that email reports.

· Monitoring alerts, like network switches, storage systems or service desk systems.

· Office devices like Multi-Function Copiers and Scanners that send mail via SMTP.

All of these systems can present challenges in reconfiguration, as by default Office 365 will expect these systems to support authenticated TLS or SSL to send SMTP. It’s also highly unlikely that you’ll already be allowing network devices to send mail directly on port 25 to the Internet.

You do however have a few options. The first, and simplest is to create Inbound Connectors for on-premises relay within Office 365’s Exchange Admin Center. This will allow you to specify the domains that devices can send to, the accepted domains they can send from, whether traffic must be secured by TLS and what external IP addresses to relay mail from.

Figure 7: An Anonymous Relay connector configured in the Exchange Admin Center

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

If you’d prefer to have a point on-premises that devices relay though then you could look at using Internet Information Services (IIS)’s built-in SMTP server. This will allow you to have a simple drop-in replacement for the Exchange servers previously used, which might even enable you to avoid reconfiguring any devices.

Figure 8: Configuring SMTP via the IIS 6.0 Manager to enable mail relay

You can pair up IIS’s SMTP relay with the aforementioned Inbound Connectors to ensure that all relayed mail from your organization flows out through Office 365 and gain the best of both options.

The final option is worth considering if you do decide to retain a Hybrid Server on-premises for Mailbox Management. Give this a second purpose of fulfilling 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.

Summary

In this article we’ve looked at what steps you need to consider next after moving to Office 365 – what you need to consider when planning the decommission of your on-premises Exchange infrastructure and some solutions to common scenarios.