I’ve been having considerable fun with the latest virtualisation tools recently. My particular chosen poison in this arena is VMware’s Fusion running on OS X, but I’m also using VMware Workstation running on Windows – and, of course, VMware’s server products too. Microsoft isn’t left out in the cold: my primary core test servers are in the process of migrating from VMware to Hyper-V in preparation for Server 2012. And let’s not forget that a Hyper-V client is lurking away inside the Windows 8 build, which promises to make for an interesting year ahead...
I’ve taken the plunge and moved my daily workload into Office 365, Microsoft’s online productivity suite. Having recently moved into a new bricks-and-mortar office, I decided now would be a great time to rationalise my email, domain names and phone numbers to match. Ditching my old domains jonhoneyball.com and the one I’ve used specifically for my company (which is called Woodleyside IT Ltd) for a single new work domain of woodleyside.com afforded a rare opportunity to perform a green-field, scorched-earth, mixed-metaphor clean out, and if you ever get the opportunity to do the same, it’s worth planning how best to do it.
I thought long and hard about my mail options. I could have stayed with my ISP’s hosted IMAP/SMTP/web interface, which I adopted prior to my previous office move two years ago (because it let me dump the Exchange server I was hosting at my old office and ensured continuity during the move). Why didn’t I stay with this ISP solution? Because I was unhappy with it: the web interface tended to lose my login information and required me to log in manually time after time. I could have installed a new local Exchange server, but I prefer to reserve my local server farm for local R&D tasks, to avoid the temptation to run test software on a line-of-business hosting server (thus breaking the separation of church and state that underlies any well-designed IT infrastructure).
Had I plumped for a local Exchange server I probably would have migrated to the shared on-site/off-site model that Office 365 supports. You host your own Exchange server and it communicates with the cloud server in such a way that all internal messages go to the local server, external ones to the external. It’s a great solution if you want to manage your migration to a pure cloud environment, letting you progressively move mailboxes from the internal server to the external one. But remember, I had a green-field site to play with, and assuming my main machines all had copies of the archived emails, I really could start from an empty server – it made more sense to leap straight into a fully cloud-hosted Office 365 environment.
Of course, no-one with any sense would perform such a leap onto an unproven solution (by which I mean “unproven to me”). Having the new domain name helped, since I could point a 30-day trial of Office 365 at that, and then kick its tyres hard for several weeks before deciding whether to go ahead. My first impressions are that it’s a good-quality product: it behaves just like a local Exchange server without the noise, power consumption and rack space, and setting it up is fairly straightforward, with a couple of caveats.
Choosing your cloud
First, you’ll need to decide which version of the product to buy: a P plan or an E plan. P plans are for small businesses, while E plans are for enterprise users. For example, the P plan costs only $7.90 per user per month, for which you get an Exchange Server account with 25GB of mailbox storage and a 25MB attachment limit. You can work online using the Office Web Apps and keep a SharePoint Online database, plus you get Forefront Server antivirus and spam filtering for the Exchange server, and all the Lync Server telecoms capabilities. It’s aimed at businesses with up to 50 seats, but it has two major limitations: no serious technical support (online community only) and you can’t migrate from plan P to plan E. That’s fine if you’re small and plan to stay small, and eight bucks per seat per month is cheaper than chips.
Move up to the E plans and you’ll find a range of extra options: E1 starts at $15.70 per user per month and offers Exchange Server, SharePoint, Lync and Forefront, along with licences to run local on-premises deployments of those servers (CALs in old-speak); E2 at $25.10 per user per month adds the Office Web Apps; E3 at $40.10 brings a rolling licence for Office Professional Plus for each desktop, more advanced SharePoint Server capabilities and archiving, unlimited storage and hosted voicemail on Exchange Server; and E4 tops the bill with enterprise-grade voice PBX abilities via an on-premises Lync Server. For me, the E3 bundle was the sweet-spot, offering sufficiently rich enterprise services without delving too deep into PBX mysteries (which I’d already decided to provide via the excellent 3CX).
Buying the service was easy, requiring only the waving of a credit card; buying additional seats is simple, too, as is bolting on extra storage for SharePoint Server. To actually get everything up and running requires some DNS work, however, and changing over your DNS is a process involving several steps.
First there’s the matter of which registrar holds the registration record for your domain – these will hold pointers to DNS servers that will hold your actual DNS records. These records can point anywhere, so you could be in the situation of using Registrar A, which points to DNS servers at ISP B, whose DNS records point to servers at Microsoft. Personally, I think it would be a nice upgrade for Microsoft to offer to take over the DNS record-hosting role for Office 365 domains, which would provide a solution that’s both simpler and more robust. A couple of bucks per month per domain would be a reasonable fee for such an extra service.
It might look simple, but there is a great deal of complexity hiding behind this facade.
So first you need to find where your domain registrar is, and get into its registration records for your domain so you can be sure where the appropriate DNS servers are located. Then you need to either make the changes Microsoft requires to these DNS servers yourself, or else get someone in to do this for you. Obviously, this is an ideal job for a Microsoft Partner, and perhaps it can help with the data migration too. One part of the required DNS changes involves putting in a TXT (text) record that tells Microsoft you are who you say you are; once this is done, and provided everything is set up correctly, your emails start flowing into the Microsoft server.
Microsoft Office 365 - the new Cloud Nine?
So how does the Office 365 service look now? Well, the online Outlook web client is superb, a huge improvement over the clunky thing that haunted those of us who grew up on Exchange 2000/2003. Indeed, for many users it might well be all the email client they ever need. However, if you want offline access to emails too, then you’ll need to set up a local email client. Outlook is the preferred choice since it connects via the Exchange communication channel rather than IMAP/SMTP. Getting this up and running is simple: just tell Outlook to create a new connection, choose Exchange Server, provide your login details, and it uses those DNS records to find the hosted Exchange server automatically.
So is everything sweetness and light with Office 365? I must confess I haven’t had time to seriously poke the SharePoint Server or Lync components so far, but there’s no doubting that the combination of Outlook 2010 and Office 365’s Exchange Server is a compelling one. But there are a few issues to consider. Although configuring these services is simple using a web interface into the administrator pages, once you scratch the surface you can end up in a very weird place indeed. The UI feels unfinished, and it’s often far from obvious where to look for a particular setting. You get a feeling this is a thin veneer hiding a heavily automated back-end services infrastructure (if, for example, you venture into the Forefront Server settings, you fall down a wormhole into another universe). Or take setting up a default email signature/ disclaimer, where you have to dig deep into the UI to discover where it sits.
For the power-minded, there’s a set of PowerShell widgets for managing the server side of Office 365, and while this can reveal what goes on behind the scenes on the remote server, it’s the sort of power you really don’t want in the hands of over-eager fiddlers. Worse still, much of the documentation is generic and poorly worded, so you’re never sure whether what you see on the screen actually applies to your particular installation or version – Microsoft needs to do something about this because it’s a considerable limitation on deploying the product as it stands. As an example, my setup is a cloud-hosted solution, so I shouldn’t see anything that covers mixed on-site/off-site solutions unless I’m starting down a migration route to that mode. Maybe most implementations will be mixed mode, but mine isn’t and I don’t need the confusion.
Microsoft might argue back, with some justification, that Office 365 is something you ought to buy through one of its Partners, but if that’s so then why sell it directly? Even my deep knowledge of the underlying technologies doesn’t help much in working out what’s going on, and most small to medium businesses won’t have my advantage of starting out from scratch. Most of them will need to cope with either a split on-site/off-site solution, with all the extra complications this involves, or else need to do a mass migration in a hurry, accompanied by other monumental headaches. The truth is that, unless you settle for a basic P account or have the luxury of a green-field start-up, a Microsoft Partner’s highly qualified expertise may well prove necessary, and depending on how this is to be funded, it could skew your cost/benefit calculations towards abstinence.