My Exchange Server 2007 migration is done. Whew! The whole thing took exactly 24 hours (9:00 p.m. to 9:00 p.m., Friday through Saturday). I moved from my old hardware—front-end and back-end Exchange Server 2003 systems, both Dell PowerEdge 2550, dual Pentium III 1.4GHz boxes—to the new single Exchange 2007 box, a Dell PowerEdge 2850, 2.8GHz Intel dual-core Xeon, with 8GB RAM and triple RAID 1 arrays. Overall the upgrade went very smoothly, and I had no major glitches but did encounter a few speed bumps along the way.
A couple of notes about my setup: We work with multiple SMTP domains, so everything is based on user principal name (UPN) logons. The default GAL is locked down, and instead we have multiple Exchange address lists and offline address lists with specific NTFS permissions for each separate domain. As you’ll see, our GAL and address-list setup has ramifications for the state of the address lists after Exchange 2007 is installed. I also opted not to install Microsoft Internet Security and Acceleration (ISA) Server 2006—you can read more about that decision in the sidebar “ISA Server 2006—or Not?”
Step 1: Run Exchange 2007 Setup
I began by cutting off SMTP at the firewall and uninstalling Exchange 2003 from my front-end server. I then started Exchange 2007 Setup on the new box (having already loaded the prerequisites that Setup identified and offered for installation). My Exchange 2007 setup comprised the following phases, most of which proceeded smoothly—until I tried installing the Mailbox server role.
- Organization prep: This took just under 6 minutes.
- Copying files: 2.5 minutes
- Installing the Hub Transport server role: 11 minutes
- Installing the Client Access server role: 2.5 minutes
- Installing the Mailbox server role: This failed after 7 minutes!
Step 2: Install the Mailbox Server Role
The Mailbox server-role failure got my heart pumping a bit. If you’ve done some customization of your address lists or recipient policies, you might be in for a surprise when you attempt to install the Mailbox role. I ran into some problems during the actual Exchange 2007 migration that hadn’t come up when I migrated my test box with supposedly the same tweaks applied to my lists and policies. Therefore, I highly recommend that you document your configurations for both address lists and recipient policies before installing the Mailbox role.
To figure out the Mailbox server-role problem, I did a Google search and found two helpful posts: “Unable to install Mailbox Role,” which explained that you need to delete the custom Exchange 2003 recipient policies, and “Mailbox Role failed to install,” which discussed using ADSI Edit to grant full control of Recipient Update Service (RUS) to the Exchange domain and non-domain Exchange servers.
I attempted to make the changes via ADSI Edit first, with no luck. Then I deleted all my custom Exchange 2003 recipient policies and address lists and reset permissions in ADSI Edit on all address-list containers. I retried installing the Mailbox role within the Setup program, and this time the Mailbox role was installed in about 37 seconds.
Step 3: Migrate Mailboxes
I created my Exchange 2007 databases, and no matter what I did, a few refused to mount until after I restarted my box. Exchange mounted the databases fine after that. I then started migrating mailboxes, which went very smoothly: I didn’t run into a single glitch in 325 mailbox moves. I used a combination of the Exchange 2007 Move Mailbox wizardand a number of Exchange Management Shell Move-Mailbox cmdlet windows. (For more information about using the Move-Mailbox cmdlet, see “Exchange 2007: Life Without ExMerge?”)
During the mailbox moves, I started recreating my recipient policies and address lists. I found myself frustrated with Microsoft’s decision to remove certain capabilities from the GUI. Exchange administrators have always relied on using the Microsoft Management Console (MMC) Active Directory Users and Computers (ADUC) snap-in to make Exchange account-creation tasks easy. Now we have to get used to bouncing between ADUC, Exchange Management Console, PowerShell, and sometimes even ADSI Edit to achieve what used to be done with a simple user copy in the Exchange-aware ADUC. Anything to do with managing Global Address Lists (GALs) has to happen in the command-line interface (CLI)—that is, PowerShell, and the Microsoft documentation for using PowerShell to update the GALs is rather poor.
To figure out the GAL problem, I ended up building up a new native Exchange 2007 installation in my VMware Server lab while I worked so that I could see what a native Exchange 2007 default GAL is supposed to look like, because the update-globaladdresslist cmdlet, which is supposed to update your old GALs to the new OPATH filter syntax, didn’t work. I had to copy the syntax from another “clean” Exchange 2007 server. After I used the GAL for my lab Exchange 2007 server as a baseline, I was able to use a combination of PowerShell and ADSI Edit to get all my GALs, address lists, and Offline Address Books (OABs) set up properly.
Step 4: Configure Outlook Anywhere
Setting up Exchange 2007’s Outlook Anywhere (formerly RPC over HTTP) feature for our remote Exchange users was one of the easier parts of the migration. When I enabled Outlook Anywhere, my previously configured RPC over HTTP Microsoft Office Outlook 2003 clients connected right up and didn't miss a beat.
Step 5: Configure Exchange and Outlook for the Firewall
I used the procedure described in the Microsoft article “Exchange Server static port mappings” to hard-code static TCP/IP ports on the Exchange server to enable Exchange and Outlook communication through our firewall. Although the article is geared toward Exchange 2003 and Exchange 2000 Server, the procedure in it worked exactly the same for Exchange 2007. After rebooting the server, I didn't have to touch my firewall configuration: Exchange 2007 and Microsoft Office Outlook 2007 picked right up where the 2003 versions left off.
Working Through the Glitches
The migration went smoothly for the most part, but as you might expect, there were a few hiccups. They involved public folder migration, Autodiscover configuration, and a few others.
Public folder migration. I worked with a Microsoft Product Support Services (PSS) tech, who helped me move my Exchange 2003 public folder hierarchy over to Exchange 2007. Since I had already uninstalled the Exchange 2003 server, to move the public folder hierarchy I needed to reinstall only the Exchange 2003 management tools, then use the tools to move the public folder hierarchy from the old Administrative group to the new one.
Autodiscover service. My main outstanding issue concerns OABs and an error that’s generated whenever an Outlook Anywhere client (Outlook 2007 or Outlook 2003) tries to force-download the OAB. The same root issue also prevents anyone from triggering the Outlook Out of Office Assistant. I knew the problem was related to public folders, which, as I mentioned earlier, I successfully migrated from Exchange 2003 to Exchange 2007. At this point, public folders were working and Outlook 2003 clients were able to use the Out of Office Assistant and perform OAB downloads. However, Outlook 2007 still couldn't do so. At this point, I realized that Outlook 2007 doesn’t try to use Exchange Web Services (one of the services that has its configuration pushed out via Autodiscover), then switch over to public folders, as I had expected. If you’re on Exchange 2007, it uses the Web services, period. Thus, correctly configuring the Autodiscover service is essential to getting a native Exchange 2007 environment working.
I needed to update the service connection point (SCP) object in Active Directory (AD) to point internal Outlook 2007 clients to the Autodiscover URL. I also enabled Autodisover for the external clients; they access the Autodiscover service via DNS-related hard-coded URLs based on the user's SMTP address. The Autodiscover service requires three URLs: the OOF (Out of Office) URL, the OAB URL, and the A vailability Service URL (used for free/busy access).
The easy part was configuring the OAB URL, which is easily done through the Client Access server portion of the Exchange 2007 GUI console (Exchange Management Console). However the OOF URL and Availability service URL were still coded to my internal server’s Fully Qualified Domain Name (FQDN), so that external clients couldn’t access these services at all. I discovered that to configure the OOF and Availability URLs, you must use the Set-WebServicesVirtualDirectory cmdlet; you can find out more about this cmdlet at http://technet.microsoft.com/en-us/library/aa997233.aspx. After you’ve configured the Autodiscover URLs, you can use the Autodiscover test tool in Outlook 2007 to see the various URLs and whether or not connections to them were successful, as Figure 1 shows.
EAS glitch. I also got a couple of errors on my Palm Treo 700w when I first tried synchronizing the Treo with Exchange 2007 (0x8600050D A critical error has occurred). Exchange ActiveSync (EAS) can recover from this error, but the next time you synchronize, you might lose changes made since your last successful synchronization. (Any changes that were made to synced information on the device since the last successful sync will be lost the next time you sync the device. However, the synchronization itself should succeed.) After a few tries, though, the Treo started syncing with no reconfiguration. (My clients with 700w devices experienced this same problem.)
Allowing attachments in OWA. My final problem was figuring out how to configure Microsoft Outlook Web Access (OWA) to allow access to attachments (other than through the View as a web page option). With help from a member of Mark Minasi’s Reader Forum, I enabled this feature by using the following PowerShell commands:
set-owavirtualdirectory -identity "servername\owa (default web site)" - directfileaccessonpubliccomputersenabled $true
and
set-owavirtualdirectory -identity "servername\owa (default web site)" - directfileaccessonprivatecomputersenabled $true
Up and Running
After the migration was done, the only thing my users noticed (other than getting used to the new Office 2007 ribbon in Outlook!) was the Out of Office Assistant not functioning. Once we got that up and running again, things worked great. On the administration side, we’ve adjusted as best as we can to the extra steps involved in creating new accounts. We have a migration coming up where we could really use the ExMerge functionality in Exchange 2003, but alas, Exchange 2007 has no such thing. A cmdlet to let you perform mass import/export to and from PST files is coming in Exchange 2007 SP1, which will be helpful for large migrations. On the plus side, I’ve got the first migration under my belt, and I’ll use what I’ve learned to make the next one smoother.
