{"id":13842,"date":"2015-04-10T13:50:39","date_gmt":"2015-04-10T13:50:39","guid":{"rendered":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/?p=13842"},"modified":"2022-06-28T12:58:11","modified_gmt":"2022-06-28T11:58:11","slug":"dns-the-key-to-a-successful-office-365-migration","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/technetuk\/2015\/04\/10\/dns-the-key-to-a-successful-office-365-migration\/","title":{"rendered":"DNS: The key to a successful Office 365 migration"},"content":{"rendered":"
<\/p>\n
By\u00a0Emily Coates<\/a><\/em><\/p>\n Emily Coates is a Premier Field Engineer at Microsoft UK.\u00a0She specialises in Messaging and Business Productivity, and is the proprietor of\u00a0MissTech<\/a>, a tech blog for all things cloud.<\/span><\/em><\/p>\n 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\u2019ve 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n A Cutover Migration is the \u2018big bang\u2019 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.<\/p>\n Once your mailboxes have been migrated and you are about to \u2018go live\u2019, it is important to do three things.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/a>. This is the least common migration method, and is designed for customers who are running Exchange 2003 or 2007 and don\u2019t want a \u2018big bang\u2019 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.<\/p>\n 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.<\/p>\n SRV creation can be rather fiddly due to its complicated structure, but don\u2019t 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):<\/p>\n _service._protocol.name. TTL class SRV priority weight port target.<\/p>\n So for example your Lync records, might be something like this:<\/p>\n _sip._tls.misstech.co.uk 100 1 443 sipdir.online.lync.com<\/p>\n _sipfederationtls._tcp.misstech.co.uk 100 1 5061 sipfed.online.lync.com<\/p>\n 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 3rd<\/sup>party 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.<\/p>\n 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.<\/p>\n 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\u2019s internet connection, and the Hybrid server itself. The same applies to your MX records if you haven\u2019t already migrated these to point to Office 365.<\/p>\n 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<\/a>.<\/p>\n Geo location of your DNS settings is a very important factor in connection speed to Office 365 servers. I\u2019ve 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.<\/p>\n Let\u2019s 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:<\/p>\n Nslookup outlook.office365.com<\/p>\n You can see by the below result that this is resolving to outlook-emeawest<\/b>.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<\/a>, and click on the Company Profile option on the left hand navigation pane. You will notice that the \u2018Country or Region\u2019 option is fixed and cannot be changed. This denotes in which region you are located.<\/p>\n <\/a><\/p>\n 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:<\/p>\n <\/a><\/p>\n I am now resolving to outlook-emeacenter<\/b>.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.<\/p>\n 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:<\/p>\n <\/a><\/p>\n 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.<\/p>\n 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.<\/p>\n More information on how Outlook clients connect to Office 365 tenants can be found in this TechNet article<\/a>.<\/p>\n 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:<\/p>\nCutover Migrations<\/h2>\n
\n
\n<\/a><\/li>\nHybrid Exchange<\/h3>\n
IMAP Migration<\/h3>\n
\n<\/a><\/p>\nStaged Migration<\/h2>\n
Lync DNS & SRV Records<\/h2>\n
Post Migration<\/h2>\n
Geolocation<\/h2>\n
DNS Checking<\/h2>\n