Friday, February 12th, 2010 by Simon Hackett
Internode has just moved its staff email environment from an Open Source based IMAP service to Microsoft Exchange 2007.
For an organisation with a long history of preference for Open Source/Unix based systems, and something less than unconditional love for Microsoft, its an interesting decision.
I’ve decided to explain why we have done this
Internode is very much a cross-platform organisation. We have significant populations of Windows, MacOS and Linux systems on staff desktops. And so any solution that provides company wide integrated mail, calendar and contacts has to cross all those operating system boundaries without significant compromise in any of them.
We’ve been trying to get a working, open source based, cross platform calendaring system happening at Internode for years and years.
And we’ve never managed it.
I’ve also been using an iPhone with Apple’s MobileMe service ever since it was possible to do that, and I absolutely love the over-the-air synchronisation of email, calendaring and contacts that it provides. Except thats a home service, not a corporate one. Even if we did it, buying 450 copies of MobileMe doesn’t actually solve our corporate requirements, because MobileMe has no concept of ‘groups’, only of individual users.
But what MobileMe it does show is just how useful over the air synchronisation can be with an iPhone.
For the longest time, in terms of the overall task of moving from simple IMAP email to fully integrated contacts, calendar and email, the piece that didn’t ‘click’ was the MacOS piece. Exchange has been arguably the best way to do this in a corporate setting for a long time, providing you are prepared to be a 100% Windows house (and we most definitely are not!).
In addition, current versions of the iPhone OS include support for Exchange so that it becomes a mechanism to bring ‘MobileMe’ levels of real time ‘push’ email, calendar and contacts to the iPhone for our corporate needs – across the whole organisation (and we have a lot of iPhones, with more turning up every month).
So what changed?
Snow Leopard was the key.
Prior to Snow Leopard being released, Exchange integration involved the prospect of running Entourage.
This was a prospect that was, quite simply, too horrible to contemplate. I used to run Entourage. I understand exactly how well it handles a very large mailbox (mine). Thats why I don’t run it any more.
In the meantime, Apple Mail has moved over the years, from starting as a pretty rudimentary mail tool, through to becoming an excellent mail client. I’ve been relying upon it for my own email needs for some time.
Then the good news turned up:
Apple delivered a huge corporate software upgrade in Snow Leopard, by tightly integrating Exchange client functionality into the operating system – in Apple Mail, iCal, and Contacts.
Indeed, its fair to say that the result is one where a MacOS Snow Leopard system has a better Exchange client environment than Microsoft provide on Windows (and its included at no extra cost with the operating system to boot). No separate clients to run, the built in stuff ‘just works’.
We did extensive internal testing of Snow Leopard against Exchange, and to a very deep level, and with surprisingly few wrinkles, ‘it just worked’ – and worked really well.
That was the clincher. We now had all the pieces of the puzzle at last: Exchange Server 2007, Windows Exchange clients, Snow Leopard for exchange integration on MacOS, and easy over the air synchronisation of everything to our iPhone fleet.
All we had to do was decide that it wasn’t illegal, immoral or fattening to trust our email system to Microsoft.
We took that leap (given our history, with some trepidation) and I’ve got to say that its working better than I’d dared hope.
Finally, we have the stuff we always wanted, and in the cross-platform manner we’ve always demanded.
What we have gained
Real time, push, over-the-air synchronisation of staff email, calendar and contacts with iPhones
Its spooky to watch quite how well this works in practice.
A decent webmail implementation that comes with Exchange.
Although its worth noting that only the ‘light’ version of the webmail service will work for ‘not Internet Explorer’ browsers at this point.
Support for the ‘full’ webmail version for other browsers included in Microsoft Exchange 2010 (which was released to market in the middle of our migration).
We’re intending to move quickly to Exchange 2010 for that and other reasons (including improved scaleability of the back end mail store).
Automatic failover for the mail service in a clean manner
At the application level, data is replicated a secondary system (identical configuration to the primary system) in another one of our data centres, with automatic failover to the secondary system if the primary system fails.
Many other software systems know how to ‘speak Exchange’ and are now able to be better integrated into our IT environment.
This includes our phone queueing system, our national Cisco Telepresence suite network and other software packages that can reach out and touch the Exchange email, contacts and calendaring system directly.
We still support secure IMAP in addition to the Outlook specific protocol for mail access (OWA) in Exchange.
This means our Linux desktop users are able to keep running their weapon of choice (generally Thunderbird) for email access at home and at work after the migration.
The Macintosh integration is wonderfully easy for an end user to configure and use.
Its a one minute job to plug a Snow Leopard mac into Exchange.
Enter your email address and password into Apple Mail, and the configuration for Apple Mail, iCal and Calendar is automatically performed and it really ‘just works’.
Our full staff contacts database, and our enterprise wide calendaring all turn up as ‘layers’ in the Apple Contacts and iCal applications, alongside existing data in both tools, in a totally clean manner.
This is how enterprise email, calendar and contacts integration is supposed to be!
Server side mail filtering everyone can access
Although I have to say that the configuration interface for it is far from ideal.
For non-Windows clients, configuration is via an RDC session into a Windows machine where the ‘full’ version of Outlook Webmail access can be run. From that interface, the mail filtering rule configurations are user maintainable and (once you get your head around how to do it) relatively straightforward to do.
I do also wish there was some form of ‘debugging’ mode or user-accessible logging of the decisions the server side filtering makes, however, to avoid some head scratching when a mail filtering rule doesn’t initially do what you had expected.
This is slated to improve in Exchange 2010, and in real terms, you’ve only got to get these things set up and running once. I personally couldn’t live in email without extensive server side mail filtering, so this is an area I was very strong on evaluating before I’d accept our move to this solution in general.
And the hard stuff – the actual filtering – does work here – and it works well.
Until now, on the old mail system, I’ve been using procmail under Unix.
While that works, its also an extremely fiddly process that is alien to anyone not familiar with Unix (and which places your email at some danger of being seriously messed up if you get even a single character in the configuration file out of place).
Deeper, the numerical majority of our staff are not Unix gurus, meaning a lot of our staff have suffered from not being able to have server side mail filtering at all. Thats really not good enough (I can’t survive my email box without it!).
By comparison, while a tad idiosyncratic to configure, the Exchange server-side filtering does work, and finally it becomes an accessible thing for all of our staff, not just those who are Unix savvy. Accessibility is the key here.
Easy Integration with our Ironport Anti-Spam Appliances
We also benefit from having an existing large scale deployment of Ironport anti-spam anti-virus appliances already, at Internode.
And for spam detection, they are still just the best in the business.
False positives (mail that isn’t spam, but gets tagged as if it is) are the scourge of spam filtering systems. They’re much much worse than false negatives (spam that didn’t get trapped as being spam).
I tried migrating my email to Exchange and allowing the Outlook junk filters to run – and they wrongly classified about 700 of my email messages in my mail store as spam, including many for which I simply can’t explain why it’d think they were spam in the first place. Unacceptable.
So – we’ve turned the Microsoft spam classification stuff off. I appreciate Microsoft feels a need to have ‘something’ in terms of this function, but its really not very good compared to the Ironports.
We simply let the Ironport cluster tag incoming email spam, and then our staff can use a very simple simple server side filtering rule in Exchange to move those spam messages to their Trash.
The lack of false positives with the Ironports means you can ‘just trash’ what they tag as spam with confidence.
They really are that good, and in many years of trying other systems, nothing else comes close.
After more than a decade of Microsoft Exchange being available, the bottom line is that Exchange combined with iPhones and Snow Leopard, plus the use of our Ironports for reliable spam detection, creates a powerful, cross platform, integrated corporate messaging environment that all of our staff can use.
Finally, we have the features, cross platform availability, and the deep integration levels we’ve always wanted, but that we have never managed to achieve in the past, from our previous collection of Open Source tools and tricks.
The obvious question
If its so good for our staff, why not deploy Microsoft Exchange for our Internet access customer mail service too?
The answer to that is that our customer mail server is an entirely different problem space, with a different set of scaling requirements and needs.
Its also not a space where we are offering calendar and contacts integration, and we don’t currently intend to try to do so.
One reason for this is simple – in a world with Google Mail in it, if a customer wants cloud based contacts/calendar/email integration for single user and/or family use, they’re quite likely to use that anyway – and for that role, its brilliant. So why fight it?
(Conversely, it has shortcomings that, in our view, mean it doesn’t work nearly as well as Exchange for our internal staff needs)
What we run for our customer mailbox support is a commercial mail server solution that is optimised for that role, with scaling and efficiency at the level we require (which is almost three orders of magnitude more mailboxes than our staff mail server has to cope with). Its a much more streamlined solution for a much more streamlined problem space.
For our internal corporate mail environment at Internode (where internally stored, tightly integrated contacts, email and calendaring are needed, with rich integration possibilities to other software and systems that we run), I have to say that Exchange has exceeded my expectations.
Is it perfect? Of course not.
But its dramatically better than how we used to live, and we think it’ll just get better from here.