My Exchange conversion

Exchange Server 2010 heals 2007 release trauma

Sysadmin blog Recently I had the opportunity to walk through complete installs of Exchange Server 2003 and Exchange Server 2010. Although I have used Exchange Server 2007 for the past two years, as with Vista, I prefer to pretend it never happened.

Installing Exchange 2003 on my personal server was like spending time with an old friend: you can’t remember why you like each other, but you’ve spent so much time together that it doesn’t matter anymore. Exchange 2010 and I are newly acquainted, but there are some sleek features that make my life easier. I have a feeling we’re going to get along just fine. Unlike the previous iteration, which I am politely ignoring, Exchange 2010 is a polished product.

The meat of Exchange 2010 is in Unified Communications integration and web/mobile access. Exchange’s Unified Communications enhancements work with OCS and your IP-enabled PBX so your voice, text and mobile communications are in one hub.

The enhancements made to web and mobile email access are more mundane, but more broadly useful. To make full use of Exchange’s web and mobile features, Exchange 2010 requires you have several domain names, depending on which services you wish to make available. At minimum, if you want to use Outlook Web Access and Outlook Anywhere, you need a certificate such as exchange.company.com. This gets messier if you want to use autodiscovery, or if you use a separate domain name internally than externally - for example: company.local internally versus company.com externally.

Exchange 2010 is all about autodiscovery. Whether you are using Outlook Anywhere, OWA, Activesync, or any of the mobile and web-enabled bits of Exchange, the client elements are designed to seek out autodiscover.company.com, where they expect to find a web server hosting a file called autodiscover.xml. Generally, this webserver is an instance of IIS running on one of your corporate exchange servers; Exchange will automatically update the important files locally.

Autodiscover.xml contains all the key domain bits of configuration that your client software needs to find and talk to Exchange, preferably over nothing more than an SSL link. Exchange and its clients expect you to have SSL certificates for exchange.company.com and autodiscover.company.com. If your internal domain is different from the external, they will expect you to have a certificate for that too. The fun part: this must all be one certificate. Exchange asks for a proper Unified Communications – Single Alternate Name (UC/SAN) SSL certificate, capable of supporting multiple external domains (without using *.company.com) as well as containing your internal domain.

Do this and everything works quite well out of the box. You will have a painless experience installing and maintaining the connectivity elements. If you try to make Exchange’s mobile and web components work without a UC/SAN cert, be prepared to abandon autodiscover entirely. You will also be in for a session of PowerShell tinkering.

Thanks to the joys of having a very small budget, I tend to focus a lot on how to accomplish my goals with as little cash outlay as possible. Under no circumstances should you cheap out on the SSL certificate for Exchange. UC/SAN SLL certificates cost more than a bog-standard single-name SSL cert, but it is simply not worth the hassle of trying to get Exchange to work any other way.

Microsoft’s previous generation of software had extensive growing pains, but making the jump from Exchange 2003 to Exchange 2010, it’s remarkable how far we’ve come. Finally, Microsoft has reliable and easy-to-configure non-VPN remote access for Outlook. With autodiscover properly set up, all users need to know is their e-mail address. ®