As you might expect, I run an Exchange server at home for my family and a few friends. This gives me a relatively safe place to experiment with configuration changes, settings, and technologies without inflicting them on more-critical servers. A couple of weeks ago, I decided to migrate my home server to Exchange Server 2007. I did so in full recognition of the fact that Microsoft doesn't recommend, or support, using Exchange 2007 in production; I backed up my Exchange databases before creating a new forest and domain to host the new server, just in case I needed to fall back to the old domain.
What have I learned in the past two weeks? Plenty!
First, the setup process itself was mostly straightforward; I've installed Exchange 2007 in enough virtual machines to be thoroughly familiar with both the command-line and GUI installers. It's a bit of a hassle to chase down the various hotfixes and components needed to install the Unified Messaging server role on an x64 system; having a live link to missing components in the setup window is a nice touch, but I'd prefer to see the setup utility attempt to fetch any components it detects are missing, then prompt the user to install them when needed.
After installation was complete, it was simple to set up email exchange with the Internet. I don't know whether Microsoft is changing this in later builds, but as of Exchange 2007 Beta 2 you still have some extra work to do:
- You have to allow anonymous traffic to your default Receive connector if you want to receive Internet email.
- If you're not using an Edge Transport server, you'll need to manually install the Exchange antispam agents on your Hub Transport server by using the Install-AntiSpamAgents script from C:\Program Files\Microsoft\Exchange Server\Scripts. Note that Install-AntiSpamAgents isn't a Windows PowerShell cmdlet; it's a script that you have to execute from within the Exchange Management Shell.
After verifying that I could exchange mail with the Internet, I moved my users' mailbox data to the new server. I'd already exported the data with Microsoft Exchange Server Mailbox Merge Wizard (ExMerge); this step was necessary because I'd created a new forest with the same Active Directory and DNS names as the old one. If I had used a unique forest name, I could have set up a cross-forest trust and used Exchange 2007's support for moving mailboxes between Exchange organizations.
Exchange 2007 automatically generates its own Secure Sockets Layer certificates (as I explained in "Certificates and Exchange, Part 2," September 14, 2006, InstantDoc ID 93517), so Microsoft Outlook Web Access 2007 was immediately available. However, I wanted to issue a certificate that would be usable with Exchange ActiveSync because several of my users depend on this protocol. I set up the Windows Certificate Authorities (CAs) and used the New-ExchangeCertificate cmdlet to generate a certificate request; after I obtained the certificate from the CA, I enabled it with Enable-ExchangeCertificate.
Installing the new certificate seemed to work well, except that none of my mobile devices would accept it! At first I thought I needed to install my CA root certificate on the devices, but that didn't work either. After a moderate amount of troubleshooting and hair-pulling, I found out about an annoying bug that sometimes makes Enable-ExchangeCertificate decide to ignore your request to tie a certificate to a service. As a result, Exchange ActiveSync was using the default, self-issued Exchange certificate, which my Windows Mobile devices didn't like. Rerunning Enable-ExchangeCertificate fixed my problem. This bug has been fixed in post–Beta 2 builds.
I also needed to set up public folders for the email addresses I use for my columns. This was simple to do using the New-PublicFolder cmdlet; in a typical environment with existing Exchange 2003 servers, I could also have used Microsoft Outlook or the Exchange System Manager.
I still have some work to do in the antispam area. I was using Vamsoft's excellent ORF Enterprise Edition on my old server, and it did a great job. The Exchange 2007 spam filters don't use Realtime Blackhole Lists (RBLs); they can, but none are included by default. I'll let you know which RBLs I use and how well they work in a future column.