A typical decision for an organization at technology refresh time involves what to do with on-premise email. While a conventional choice might be an in place upgrade to the current release of your messaging application, it’s also an opportunity to change your messaging service to another application, or to move some or all of the messaging components to a hosting provider in the cloud. For a small organization, especially one under 25 users, there can be strong economic, risk-mitigation, and feature-use scenarios that make a cloud migration quite attractive.
In a previous article, I covered some fundamental decisions an organization faces when looking to upgrade to the latest version of Microsoft Exchange server. In this article, we’ll walk through some real-world experiences of users and administrators of networks that migrated from on-premise Exchange server to Microsoft’s hosted collaboration environment, Office 365. There are hybrid options for the larger organization that needs long-term co-existence with on-premise email systems. In the scenario that follows, we’re looking at a smaller company that wants to migrate completely to a hosted model.
Prepare public DNS records for migration
Once you sign up for Office 365, Microsoft will send you instructions on how to modify the Mail Exchanger (MX) record in your organization’s public DNS zone so that inbound email is delivered to the Office 365 cloud. After sending a test message, you flip your inbound mail path, from whatever it was, to point to Office 365. After that, all mail for your organization will arrive at the Office 365 cloud. Initially (before you migrate any user mailboxes), all email flows transparently through the cloud and continues to arrive in your on-premise email system.
In addition to moving the MX record, you can optionally add these other DNS records:
- The Autodiscover record helps Microsoft Office Outlook locate the Office 365 servers when users check Free/Busy information or use the Out Of Office Assistant.
- The Sender Policy Framework (SPF) record helps prevent others from using your domain name to send spam or other malicious e-mail.
Microsoft makes available a handy cloud-based connectivity analyzer tool to test that your DNS records are correctly published (be sure and select tests from the tool’s Office 365 tab).
Move mailboxes to the cloud
Microsoft makes this part easy for customers with previous versions of Exchange. There is a server-side utility called the Microsoft Online Migration Console that you install on a server in your environment. This console shows you each of your current Exchange mailboxes and whether they reside on-premise or in the cloud, allowing you to granularly move users individually or in small groups. When it comes time to migrate a particular user to the cloud, follow this procedure:
- Let the user know there will be a brief interruption in their ability to use email. Close all instances of Outlook for that user and advise them to avoid using their Active-Sync device(s).
- Migrate the user’s mailbox to the cloud using the Online Migration Console.
- Install and run the client-side Microsoft Online Services Sign In utility on the user’s PC. (See Figure A.)
- Select all the Options in the Sign In Preferences section for the most transparent operation.
- After successfully signing in, a wizard will launch that automatically configures the PC’s Office 365 applications such as Outlook to work with the cloud.
- The user’s Active-Sync devices such as iPhone, iPad, Android, or Windows Phone are configured by selecting to create a new Email account. If your autodiscover record is available in your public DNS, this is an automatic procedure. Microsoft also provides Office 365 customers with instructions to manually configure Active-Sync devices with a server name if you don’t have an autodiscover DNS record.
The Microsoft Online Services Sign In utility configures the user’s Office 365 applications.
Enable email for network devices
Many offices have a few network devices, such as scanners or telephony equipment, which use SMTP email to deliver documents or alerts. When you have an on-premise email server, it’s a simple matter usually to point that device to the local server’s SMTP service for outbound email delivery. However, if you tried to send SMTP email to Internet destinations from an on-premise SMTP post office, after moving your email to Office 365, this would probably result in most of your outbound emails being intercepted as spam.
When there is no longer an on-premise Internet email gateway, you need to use SMTP servers in the Office 365 cloud. Microsoft, like most cloud email service providers, does not allow direct SMTP (TCP port 25) connection from customers. They do make available a secure SMTP receiver on TCP port 587 specifically to support the requirement for email-enabled devices in your office. If your device allows SMTP to be set up with a non-standard port, SSL/TLS encryption, and apply a username and password, you can point the device directly to the cloud.
If your device only supports SMTP on port 25, or can’t support SSL/TLS encryption and/or secure login, then a tip is to provision a server-level SMTP postoffice on-premise for relaying to the cloud. Any Windows 2003, Windows 2008, or Windows 2008 R2 server can host an SMTP postoffice that is configured to relay messages to the Office 365 cloud. You can point your on-premise SMTP devices to the on-premise SMTP relay postoffice, which in turn sends everything to the Office 365 cloud for onward delivery.
Figure B shows the detailed Delivery settings in a Windows server SMTP post office to enable this capability. Remember that the username and password entered must belong to an active Office 365 mailbox account, and the password will require changing here every few months when the Office 365 user’s password is changed.