Readers who follow me on Twitter (@markwilsonit) may have noticed that I was in a mild state of panic last night when I managed to destroy the DNS for markwilson.co.uk.  They might also have seen this website disappear for a few hours until I managed to get things up and running again. So, what was I doing?

I’ve been using Google Apps for a couple of years now but I’ve never really liked it – Docs lacks functionality that I have become used to in Microsoft Office and Mail, though powerful, has a pretty poor user interface (a subjective view of course – I know some people love it).  When Microsoft announced Office 365 I was keen to get on the beta, and I was fortunate enough to be accepted early in the programme.  Unfortunately, at that time, the small business (P1) plan didn’t allow the use of “vanity domains” (what exactly is vain about having your own domain name? I call it professionalism!) so I waited until I was accepted onto the enterprise (E3) beta. Then I realised that moving my mail to another platform was not a trivial exercise and, by the time I got around to it several weeks had gone by and it is now possible to have vanity domains on a small business plan!

Anyway, I digress: migrating to Office 365, how was it? Well, first up, I should highlight that the DNS issues I had were nothing to do with Microsoft – and, without those issues, everything would have been pretty simple actually.

Microsoft provides a portal to administer Office 365 accounts and this also allows access to the Exchange Online, Lync Online and SharePoint Online components.  In that regard, it’s not dissimilar to Google Apps – just a lot more pleasant to use. So far, I’ve concentrated on the Exchange Online and Outlook Web App components – I’ll probably blog about some of the other Office 365 components as I start to use them.

The e-mail address that Microsoft gave me for my initial mailbox is in the form of user@subdomain.onmicrosoft.com. That’s not much use to me, so I needed to add a domain to the account which involves adding the domain, verifying it (by placing a CNAME record in the DNS for the appropriate domain – using a code provided by Microsoft, resolving to ps.microsoftonline.com.) and then, once verified, configuring the appropriate DNS records. In my case that’s:

markwilson.co.uk. 3600 IN MX 0 markwilson-co-uk.mail.eo.outlook.com.
autodiscover 3600 IN CNAME autodiscover.outlook.com.
markwilson.co.uk. 3600 IN TXT “v=spf1 include:outlook.com ~all”

These are for Exchange – there are some additional records for Lync but they show how external domain names are represented inside Office 365.

[Update 17 June 2011: The DNS entries for Lync are shown below]

SRV _sip _tls 443 1 100 sipdir.online.lync.com. markwilson.co.uk 3600
SRV _sipfederationtls _tcp 5061 1 100 sipfed.online.lync.com. markwilson.co.uk 3600

The . on the end of the names and the quotes on the TXT record are important – without the . the name resolution will not work correctly and I think it was a lack of " " that messed up my DNS when I added the record using the cPanel WebHost Manager (WHM), although I haven’t confirmed that.

With the domain configured, additional email addresses may be added to user accounts and, once DNS propagation has taken place, mail should start to flow.

Before I sign off, there are a few pieces of advice to highlight:

• After I got everything working on the Office 365 Enterprise (E3) plan, I realised that I’d be better off using the Small Business (P1) plan. This wasn’t a simple subscription choice (I hope it will be in the final product – at the time of writing Office 365 is still in beta) and it involved me removing my “vanity” domains from all user objects, distribution groups, contacts and aliases, then removing the domain from Office 365, and finally going through the process of adding it using a different Microsoft Online account.
• Before making DNS changes, it’s worthwhile tuning DNS settings to reduce the time to live (TTL) to speed up the DNS propagation process by reducing the time that records are stored in others’ DNS caches.
• Microsoft TechNet has some useful advice for checking DNS MX record configurations with nslookup.exe but Simon Bisson pointed me in the direction of the Microsoft Exchange Remote Connectivity Analyzer, which is a great resource for checking Exchange ActiveSync, Exchange Web Services and Office Outlook connectivity as well as inbound and outbound SMTP email.
• Microsoft seems to have decided that, whilst enterprises can host their DNS externally, small businesses need to host their DNS on Microsoft’s name servers (and use a rather basic web interface to manage it).  I’m hoping that decision will change (and I’m led to believe that it’s still possible to host the DNS elsewhere, as long as the appropriate entries are added, although that is an unsupported scenario) – I’m trying that approach with another domain that I own and I may return to the topic in a future blog post.

Now I have my new mailbox up and running, I just need to work out how to shift 3GB of email from Google Apps to Exchange Online!