Autodiscover!

OR: How to successfully migrate from POP to an Office365 mailbox, when your hoster doesn’t support you!

Yes, @katharinakanns was right, when she recently said, I’d bother with Office365 to get all our IT stuff migrated onto it. Sounds ridiculous, maybe, but it’s 2 domains, 2 mailboxes, a bunch of subdomains, aliases used all around the net, etc. etc. etc. … and we’d like to merge that all into one place.

Before you read on, this one here is – since long – something more down to earth again, so get ready for some bits and bytes 🙂

What’s this about?

These days I started to setup our Office365 tenant to serve both our single-person businesses as well as become the place for joint collaboration (and maybe more lateron). One thing in this that bothered me indeed a bit beyond normal was OneDrive – but that’s a different story to come … Another pretty interesting process was the domain migration. And even though umpteenth blogposts already tell the way to take from different angles, we ran into one bit that wasn’t just to solve by a click. I’ll share a few straight forward steps with domain migration here; but I’ll also share some hints beyond.

1. Know your hoster/provider

The domain you want to migrate into Office365 will most probably be managed by some ISP (like e.g. “1und1.de” or any other hoster; one whom you trust, maybe). Out of our experience, I’d suggest you get in touch with the support hotline of your hoster first and make sure

• (a) whether editing DNS records for your domain is possible for you yourself (e.g. by some web interface) and (!) to which extent
• (b) how accurately the hotline reacts in case of problems
• (c) whether they can help in case of any failure over the weekend (one would want to have a business mailbox up and running on Monday morning, I guess)

I had to migrate 2 domains, one of which was with a hoster not allowing editing DNS myself but reacting swiftly to support requests and executing them just perfectly. The other one allowed editing the DNS by me but only let me enter TXT and MX records (no CNAME records – at least not for the primary domain). Or to be precise: The self-service web interface would let me do that but clearly stated that any existing records for this domain would become invalid by this step – and I wasn’t too sure whether this might run us into troubles with our business website …

Note: The second was "1und1.de" and they do not offer any possibility of doing anything else in terms of DNS than what is provided for self service. I tried really hard with their support guys. No(!) way(!).

2. How migration works when your ISP cooperates

To begin with, it would of course be possible to simply move DNS management from the ISP to Office365. In that case, all the ISP would have to do is changing the addresses of the name servers managing the respective domain. We didn’t want that for several reasons, hence went for the domain migration option, which is actually pretty straight forward.

The Office365 domain management admin console is totally self-explanatory in this, and there’s umpteenth educational how-to-posts. The keyword is – surprise(!) – “Domains” and you just follow step 1-2-3 as suggested.

One can either start at the “Email address” section here (if there’s not yet any custom domain managed within the tenant) or by “Domains” further below:

1. Office365 wants to know whether the domain is yours. Therefore Office365 shows you a TXT DNS record in the first step, which you have to forward to your hoster to be entered as part of “your” DNS. If you’re able to enter that yourself this step is accomplished in no time. Otherwise it depends simply on the response time of the support line. BTW: DNS propagation in general may take up to 72 hours as we know – however, in reality I didn’t experience any delay after having received the confirmation that the TXT has been entered. I could forward to step 2 instantly.
2. With step (2) Office365 changes any user’s name that you want to make part of the then migrated domain. Essentially that’s a no-brainer, but an Office365 user currently can only send eMails being identified with exactly this username. Receiving goes by multiple aliases which can be configured separately in the user management console; but sending always binds to the username (there’s ways around this as well – but that’s again a different story). Hence, it is worth some consideration which users you click in this step.
3. Proceeding to the next step equals stepping into the crucial part; after this change is completed your eMail, Lync and – if chosen – website URL will be redirected to Office365. Admittedly, in both cases I only chose “eMail and Lync” for migration, which means that the website remained with the ISP – for now … As the penultimate step after having chosen the services that you want to switch over, Office365 gives you a list of records that need to be entered as DNS records with your domain.

Let’s have a brief look into those DNS records as they are the ones that eventually bring your migration to life:

• MX records: This is, normally, one record that identifies where the eMails with the domain in question shall be routed to (to: name@yourdomain.tld). No rocket science here and getting that into your DNS shouldn’t be a bummer, really.
• CNAME records: The most important of these is the “autodiscover” record. I’d argue this to be the “most compulsory” one. Not having “autodiscover” set into the DNS of your domain means that any eMail client will not be able to discover the server for the respective user automatically, i.e. users will “pull their hair out” over trying to configure their mail clients for their Office365 Exchange account. In all honesty, I actually was not able to find a possibility to figure out the correct mail server string for outlook for our users as it contains the mailboxID (being a GUID@domainname.tld; if anyone of you out there knows one, can you please drop your solution as a comment). So, without the “autodiscover” record, you’ll be pretty lost, I think – at least with mobiles and stuff … The other CNAME records are for Lync and Office365 authentication services. Here‘s a pretty good technet article listing them all.
• The SPF TXT record helps preventing your domain being used for spam mailing
• And finally, 2 SRV records are for the Lync information flow and enabling SIP federation

[update] Here’s some hints on how we got Lync to work for our accounts, but for eMail, of all the records above the MX would be fully sufficient; I’d just once more emphasize “autodiscover”, as this caused us some headache, because …

3. What do you do, if your ISP does not add “autodiscover”?

As explained above, one’s in bad shape, if an ISP refuses to add the “autodiscover” CNAME record demanded by Office365 for a custom domain. In the case of “1und1” this was exactly what ran us into troubles. However, there’s a pretty simple solution to it, but to begin with – here’s some things that don’t work (i.e.: you don’t need to dig for them):

• Enter CNAME records into the respective PCs hosts file: Normally a hosts file can be used locally to replicate a DNS – but only for resolving names to IPs, not for CNAMEs.
• Install a local DNS server: Might work, but seemed like some more work. I didn’t want to dive into this for one little DNS record.
• Find out the mailbox server for manual configuration: Well – as said above: I didn’t succeed in due course.

Finally @katharinakanns found the – utterly simple – solution by just asking the world for “autodiscover 1und1“. So here’s what probably works with any petulant ISP:

• create a subdomain named “autodiscover.yourdomain.tld” with your ISP (normally, every ISP allows creation of unlimited subdomains)
• create a CNAME record for this new subdomain and enter “autodiscover.outlook.com” as its value/address portion

Done. This is it. Mailclients discovered the correct mailserver automatically and configuration instantly became a matter of seconds 🙂

[update] 1und1 has updated there domain dashboard, hence config is easier now – find hints here!

{feature image from Ken Stone’s site http://masterstrack.com/ – I hope, he don’t mind me using it here}