DNS: The key to a successful Office 365 migration
By Emily Coates
Emily Coates is a Premier Field Engineer at Microsoft UK. She specialises in Messaging and Business Productivity, and is the proprietor of MissTech, a tech blog for all things cloud.
Whether you are migrating your email system to Office 365 using a Cutover, Staged or Hybrid migration, having the correct DNS configuration is key to performing a successful migration. Once you’ve taken the plunge, migrated your users and are using Office 365 in anger, DNS remains vital to having a quality user experience. For these reasons it is worth outlining some options and good practice guidelines for different configuration types, along with some post-migration hints.
Before we delve into any specific detail, a quick word on TTLs (time to live) and DNS propagation. Every DNS record has a specific TTL, which is the length of time before the record expires and is renewed by a client. If you are aware that you will be making DNS changes in the near future then it is a good idea to lower the TTL of the DNS records which will be changed. Do this a few days in advance, and when you make the changes, they should propagate in a more timely fashion. This is particularly relevant for MX record changes, as it ensures a smooth transition when migrating mail flow.
By convention, and often by default, DNS records are configured with a TTL of 86400 (24 hours) however they can take up to 72 hours to propagate fully. Normally this happens much quicker (1-2 hours) within the UK, but if your business is worldwide, you should expect delays in DNS propagation. Microsoft recommends a TTL value of 60 minutes or lower during your migration.
Cutover Migrations
A Cutover Migration is the ‘big bang’ approach and for that reason, involves changing/adding all your DNS records at once. One important thing to remember here is the timing of your MX record change; it should be done prior to performing a final sync of your mailboxes. This ensures that no mail is lost by being sent to your On Premise environment after you have completed the mailbox migration.
Once your mailboxes have been migrated and you are about to ‘go live’, it is important to do three things.
- Configure a Group Policy to stop Outlook clients looking up SCP records in Active Directory. This ensures that when you or your users attempt to configure a new Outlook profile on your ‘go live’ day, the client will look up your autodiscover DNS record, and not discover your On Premise Exchange Server. This could potentially be done a day or two in advance of your ‘go live’ day to give the GPO time to be processed by all clients. If you need to setup an On Premise Outlook profile once this change has been made, you can perform a manual setup in Outlook.
- Change your MX record to point to Office 365, and wait for it to propagate. Once it has propagated and you have confirmed that mail is flowing to Office 365, you can complete your migration batch and change your firewall configuration to block incoming traffic on port 25. This ensures that no mail can reach your Exchange Server via any alternative routing which may be configured.
- Once you are satisfied with the completed migration, remove Exchange from your environment. This needs to be done in the correct manner to make sure all references to Exchange are cleanly removed during the uninstallation process. The process in this TechNet article is for Exchange 2010 but is also relevant for admins removing Exchange 2007/2003 after migrating to Office 365.
Hybrid Exchange
In order for a Hybrid Exchange deployment to be successful, you need to make sure autodiscover is working correctly On Premise and is pointed at your Hybrid server. This is because your Hybrid server is able to redirect autodiscover requests for cloud users to your Office 365 tenant, however Office 365 cannot perform autodiscover redirection to your Hybrid server.
As for MX records, these can be pointing to Office 365 or your On Premise Exchange environment, depending on your needs. As long as the Hybrid Configuration Wizard worked correctly, mail flow should be seamless between the two systems.
IMAP Migration
If you are migrating your mail services away from a non-Exchange environment (such as Google Mail), or from an exchange 5.5 or 2000 environment, then you will likely be performing an IMAP migration. Using this method you pre-stage your mailboxes in Office 365, and synchronise mail between the two systems. Once your mail is synchronised and you want to make the switch, you change MX records to point towards Office 365. Wait a while for this change to propagate and then stop the synchronisation. If you are migrating mailboxes using the IMAP method, then you can create all of your DNS records at the same time that your MX record change is made. There is a great guide of IMAP migrations here.
Staged Migration
This is the least common migration method, and is designed for customers who are running Exchange 2003 or 2007 and don’t want a ‘big bang’ approach to migration. As with a Hybrid Configuration, your autodiscover record (if running Exchange 2007) should point to your On Premise server for the purposes of redirection. If you are going from 2003, you should not configure any autodiscover DNS record, and will need to manually configure Office 365 Outlook profiles until you have completed your migration. At this point you can configure autodiscover to point at Office 365. Your MX record must also point to the On Premise environment for the duration of your coexistence. See below for additional post migration information.
Lync DNS & SRV Records
So far we have just covered Exchange specific DNS records, such as Autodiscover and MX records. If you want to be able to login to Lync, there are another set of DNS records which must be created. This is so Lync clients can discover their Lync server. The DNS configuration for this consists of 2 x CNAME records and 2 x SRV records. Once these records have been created and propagated, your licensed users should be able to login to Lync. Remember, if you are using a split brain DNS infrastructure, you will need to create these records internally and externally.
SRV creation can be rather fiddly due to its complicated structure, but don’t let that put you off. If your DNS providers web interface does not have the same input boxes as you expect, the least complicated way of getting around this is to simply contact the provider and request that they enter the details for you. Otherwise, the correct syntax for SRV records is as follows (and is shown to you on the Office 365 domain management page):
_service._protocol.name. TTL class SRV priority weight port target.
So for example your Lync records, might be something like this:
_sip._tls.misstech.co.uk 100 1 443 sipdir.online.lync.com
_sipfederationtls._tcp.misstech.co.uk 100 1 5061 sipfed.online.lync.com
Post Migration
It is possible that while your Exchange environment was On Premise, you were using a public name for your Exchange Server internally (due to recent changes in the issuance of 3rdparty certificates). This means that you would have been using a split brain DNS configuration. Once you are migrated, you may be able to remove your public DNS zone from your internal DNS environment, which will help simplify administration for you. You may however have other reasons to keep a split brain DNS configuration, in which case you can simply modify the internal DNS records to point to Office 365.
If your deployment involved a Staged migration, you will need to change/add your Autodiscover and MX records to point to Office 365 once your migration batches are complete.
If went down the Hybrid route, you need to make sure you switch your autodiscover records over to point to autodiscover.outlook.com at the end of your migration. This bypasses your Hybrid server and sends your autodiscover traffic directly to Office 365, which reduces connection latency. In addition to this, having autodiscover requests routing through your Hybrid server creates a single point of failure in both your Hybrid server’s internet connection, and the Hybrid server itself. The same applies to your MX records if you haven’t already migrated these to point to Office 365.
Essentially you should migrate your DNS records to point directly at Office 365, and then trim down your Exchange environment to simply provide management services. Remember not to remove your Exchange Server completely as this makes management of mailbox properties in Office 365 quite cumbersome. See here for more details on this.
Geolocation
Geo location of your DNS settings is a very important factor in connection speed to Office 365 servers. I’ve seen customers in the UK using, for example, DNS servers in the USA as forwarders on their internal DNS servers. This will cause very high latency and will result in a poor user experience. This is because DNS servers will return the CNAME aliases of their local Microsoft datacentres. If you are in the UK and point your DNS forwarders at a DNS server in the USA, you will actually be resolving to the US Microsoft Datacentre IP addresses and thus your connection to the UK Datacentre will be routed through the US Datacentre. This transatlantic connection is unnecessary and will damage your user experience quite significantly.
Let’s take a look at this in practice. The best way to test out where you are resolving to is to run the following command in CMD:
Nslookup outlook.office365.com
You can see by the below result that this is resolving to outlook-emeawest.office365.com. This is the datacentre in Western Europe, which also happens to be where my Office 365 data is located. I know this because whichever location you enter when you first setup your Office 365 account maps to your datacentre region, and your data will never move out of this geographic region. If you are unsure as to which location you entered, then log into the Office 365 admin portal at https://portal.office.com, and click on the Company Profile option on the left hand navigation pane. You will notice that the ‘Country or Region’ option is fixed and cannot be changed. This denotes in which region you are located.
If I change my DNS settings to point to 8.8.8.8 (Googles DNS servers) run ipconfig /flushdns, then Nslookup outlook.office365.com, I get a very different result:
I am now resolving to outlook-emeacenter.office365.com. My Office 365 traffic is now being routed through a different datacentre in Central Europe and then forwarded on to Western Europe, where my data is located.
If I then change my DNS settings to point to 75.149.59.34 (a Comcast DNS Server), run ipconfig /flushdns, then Nslookup outlook.office365.com, you can see that I get a different result again:
I am now resolving to outlook.namnorthwest.office365.com. This is a datacentre in North West North America, and means that my traffic is going an awfully long way just to connect to my Office 365 datacentre in Dublin or Amsterdam.
The most common configuration for DNS forwarders, and generally the best method, is to configure your DNS environment to forward requests to your ISPs DNS servers. These are the closest publically available DNS servers to you and thus will generally provide the fastest name resolution possible.
More information on how Outlook clients connect to Office 365 tenants can be found in this TechNet article.
DNS Checking
Office 365 will perform a number of checks of your external DNS infrastructure to ensure that your records are correct, however it is very possible that you will receive an alert on the Office 365 admin portal, warnings such as this under the Domains tab:
There are a few reasons why you may see this:
- You have not yet configured all DNS records required. When you first add the domain, you need to select the domain purpose. In the example above, I chose Exchange Online and Lync Online, however I haven’t configured my Lync DNS records yet. Luckily the portal is very good at telling you which records are missing or incorrect. If you click Fix Issues it will perform a check and tell you exactly which records are missing.
- You have not configured an SPF record. SPF (Sender Policy Framework) testing is becoming more and more commonplace and is it highly recommended that you configure an SPF record in your external DNS portal to ensure that email to your domain does not get bounced. The DNS Checker will tell you exactly what your SPF record should look like, although this may need to be slightly modified if your mail passes through any other systems for hygiene purposes.
- It’s possible that the DNS is incorrect by design. A couple of examples of this are:
- Hybrid Configuration. In this setup your autodiscover record will point to your internal Exchange server which will generate an error. The same could apply to your MX record.
- Cutover migration. If you have not gone live yet, all your DNS records will show as incorrect.
- Mail Hygiene solutions. If you are using a 3rdparty mail hygiene solution, you will very likely have your MX records pointed towards their systems. This will generate an error.
If a, b or c are true for you and you know that your DNS configuration is correct, you can remove this error. And if you are anything like me, you will hate to see red X’s when I know that nothing is wrong! To disable DNS checks, click Fix Issues, and on the resulting page, tick the box in the top right, as shown below:
This disables DNS checking. You can always turn DNS checking back on once you are confident that your migration is complete and your DNS records are as Microsoft would expect.
Conclusion
Office 365 relies heavily on DNS for client connectivity, mail flow and geolocation. A successful migration depends on it, as does the quality of your ongoing service. Hopefully this blog post can assist you and put you on the road to a successful Office 365 deployment!
