With the December 2006 release of Exchange Server 2007, organizations worldwide are reassessing their messaging infrastructure and planning for the future. Because Exchange 2007 in a production environment is supported only on 64-bit hardware platforms, many of those plans today involve staying on Exchange Server 2003 until sites are ready to upgrade their hardware to support the new version. Or, as with a recent client still running Exchange Server 5.5, planning for the future involves an interim move from its legacy mail platform to Exchange 2003 Service Pack 2 (SP2) in preparation for a possible migration to Exchange 2007.
Microsoft ended extended life-cycle technical support for Exchange 5.5 last year and doesn't offer a direct migration path from Exchange 5.5 to Exchange 2007. So if you want to get from Exchange 5.5 to Exchange 2007, moving to Exchange 2003 first is unavoidable—unless you deploy a third-party solution such as Quest Software's Quest Exchange Migration Wizard. Exchange 2003 SP2 is a reliable, secure messaging platform that will serve organizations well until they have the time to assess Exchange 2007's features and their business needs and budget.
For an overview of the steps involved in migrating from Exchange 5.5 to Exchange 2003, you can read "Migrating from Exchange 5.5 to Exchange 2003," October 2003. In this article, I share the upgrade processes and real-world lessons from a client's recent intra-organization, side-by-side migration from Exchange 5.5 to Exchange 2003—lessons that can apply to any small or medium-size organization considering the same type of migration strategy.
Setting the Stage
My client's mail platform was based on an Exchange 5.5, Standard Edition SP4 mailbox server and an Exchange 5.5 Outlook Web Access (OWA) server. The Exchange mailbox server uses DAS, with RAID 1 mirroring for the OS and RAID 5 for mailbox databases. The infrastructure was based on a single-forest, single-domain Active Directory (AD) design built on Windows Server 2003 SP1, and the Exchange 5.5 servers were members of the domain. In addition, the company supported Microsoft Outlook 2002, Outlook 97, and OWA clients and ran BlackBerry Enterprise Server 3.6. For email backup, the organization used an HP StorageWorks Linear Tape-Open 1 (LTO-1) drive with VERITAS Backup Exec 8.6 and the Backup Exec agent for Exchange Server.
Originally, the company's Exchange 5.5 mailbox server was installed on a Windows NT Server 4.0 member server in a domain containing about 2,000 users. The Exchange Server database file (priv.edb) was about 80GB on a single mailbox store on one storage group (SG), containing roughly 3,000 mailboxes. When the organization experienced a disaster in late 2005, it couldn't repair the damaged server parts, and replacements were no longer available. The alternative was to install Exchange on a newer server that didn't come with NT 4.0 drivers.
Although we could have implemented NT 4.0 on the new server by using virtualization, we chose a simpler and faster solution: We rebuilt the box by using Windows 2000 Server SP4, installed Exchange 5.5, and restored from our last working backup set of the mailbox store onto the target Compaq ProLiant DL380 server. We also rebuilt the Exchange 5.5 OWA server on Win2K Server SP4. We joined both servers as member servers in the AD domain and restricted them to internal use only behind the corporate firewall.
Like many companies with an Exchange 5.5 messaging infrastructure, my client's organization was still clinging to its NT 4.0 domains simply because they worked. However, given that email was now an essential business application, the company recognized that it couldn't ignore email's strategic importance in the overall IT infrastructure. In addition, Exchange 5.5 uses its own directory service, which doesn't integrate with AD and Exchange 2003. So the first step in moving from Exchange 5.5 on an NT 4.0 domain to Exchange 2003 was to build a stable and functional AD infrastructure.
Rather than starting from scratch and setting up a pristine AD environment, we performed an in-place upgrade of the company's NT 4.0 domain and adopted the aeronet.local DNS namespace. By performing an in-place upgrade, we ensured that all computer and user accounts retained their SIDs and automatically maintained access to all relevant domain resources. This strategy also freed us from having to deal with the Active Directory Migration Tool (ADMT) to populate AD with user and group account information from the NT 4.0 domain, which is typically the first step in migrating both NT 4.0 security principals and Exchange 5.5 mailbox ACLs. Note that with this approach, any misconfiguration or security weakness on existing servers can carry over to the new configuration, preventing you from starting from a clean, known state. Your organization must conduct the necessary risk assessments to determine what's best for your environment.
The company upgraded its two NT 4.0 domain controllers (DCs), AERODC01 and AERODC02, to Windows 2003 SP1 and set them up as DNS servers. The Windows DNS Server service is integrated with AD, with dynamic update enabled. With only one domain in the forest, all DCs were configured as Global Catalog (GC) servers (as recommended in the Microsoft article "FSMO placement and optimization on Active Directory domain controllers" at http://support.microsoft.com/?kbid=223346). We added another DC (AERODC03), and to minimize GC and DC traffic contention with regular client workstations, we assigned this DC to its own AD site on a specific Virtual LAN (VLAN) IP subnet dedicated to Exchange 2003. We then raised the AD domain and forest functional level to Windows 2003 native mode. This gave us immediate access to features such as universal security groups and nested groups, which helped simplify the overall administration of the Exchange infrastructure.
Preparing for the Upgrade
As you know, beginning with Exchange Server 2000, Exchange no longer maintains its own directory-information store. This Information Store (IS) is now part of the AD database repository. Before installing Exchange 2003, you must extend the AD repository schema to support Exchange 2003 by running setup.exe with the /forestprep switch from the Exchange 2003 CD. We did this on AERODC01, which holds the schema master role. We then executed the command
setup.exe /domainprep
to prepare the domain to receive Exchange 2003. Because all three of the company's DCs are in the same physical location, replicating the changes didn't take long.
After careful consideration, we chose the intra-organization migration approach, in which you install Exchange 2003 into an existing Exchange 5.5 environment. Using this approach was important for several reasons. First, we needed to keep the Exchange organization name and took the opportunity to consolidate the existing mailbox store onto a new Windows cluster back end. This migration method also let us use the much-improved Move Mailbox wizard without having to resort to tools such as the Exchange Profile Update Tool (exprofre.exe) or the Microsoft Exchange Server Mailbox Merge Wizard (ExMerge) utility, which are rather tedious and time-consuming to operate. In addition, the intra-organization strategy lets you automatically migrate Microsoft Office Outlook 2003 user profiles as long as you relocate the mailboxes to an Exchange server within the same administrative group, which is where we added the new Exchange 2003 servers.
After deciding on our migration approach, we spent a lot of time planning and designing the Exchange SG allocations, mailbox sizes, and database-file placement. Our goal was to achieve the best possible performance and reliability from the shared, clustered storage provided by a new EMC Symmetrix DMX-3 SAN with Fibre Channel switches. We also needed an optimized, manageable Exchange backup and recovery window.
The ADC Challenge
To support Exchange 2003 and Exchange 5.5 coexistence while minimizing downtime and user disruption during the migration, we deployed the Exchange 2003 Active Directory Connector (ADC), which maintains synchronization of directory information between Exchange 5.5 and AD. ADC synchronizes current mailbox, custom-recipient, public-folder, and distribution list (DL) information from the Exchange 5.5 directory to the AD equivalents, and vice versa, so that you don't have to re-enter this data in AD. Table 1 shows how the Exchange 5.5 information maps to Exchange 2003 address lists, as seen from the Global Access List (GAL) using Outlook 2003. ADC has undergone many revisions since its inception, so make sure you use the latest version from Exchange 2003 SP2 (not the one from Windows).
Although ADC is a valuable tool, we learned the hard way that it doesn't always work as the documentation says. We first installed ADC on AEROFS01, then launched the ADC Tools Wizard to deploy the required connection agreements (CAs) with no visible results. Windows 2003 kept reporting a hardware problem but didn't pinpoint the exact cause. Eventually, we found that a CPU in the dual-CPU system was overheated (because of a broken fan), and a machine reboot resulted in an unrecoverable blue screen of death.
We went ahead and installed ADC on a spare server (AEROFS20), but when we launched the Microsoft Management Console (MMC) ADC snap-in, we encountered the following error message:
The Active Directory Connector snap-in failed to initialize. The Default ADC Policy object could not be located in the Active Directory. Please ensure that the directory object has not been deleted and that sufficient permissions have been granted to your account. ID no: c103aa81, Microsoft Active Directory Connector Management.
Fortunately, this is a known problem, and a fix was available. (For information about this fix, see the Microsoft article "XADM: 'C103AA81' Error Message Occurs When You Initialize the ADC Snap-In" at http://support.microsoft.com/?kbid=282763.) We simply delegated the appropriate permissions to the ADC object on AEROFS20 so that we could retrieve the previously saved AD settings. We then changed the server name to AEROFS20 on the General tab of the Recipient CA properties box and ensured that the ADC service account was a member of both the local Administrators and Domain Administrators groups in aeronet.local for the MMC snap-in to work correctly.
Because we added OWA as the first Exchange 2003 server to the existing Exchange 5.5 organization, ADC automatically generated a two-way Configuration CA between Exchange 5.5 and AD. The CA works with the Site Replication Service (SRS) that's installed by default on OWA to facilitate synchronization between Exchange 5.5 directory services and AD. Note that this default automatic generation of the Configuration CA on the first Exchange server is the exception: You must create all other CAs manually.
The company's Exchange 5.5 setup used recipient containers with different subcontainers, including hidden recipients. To make sure this configuration was properly replicated to AD and vice versa, we ran the ADC Tools' Connection Agreement Wizard to create a two-way Recipient CA. Table 2 shows the settings we configured in the Recipient CA's properties box through the Connection Agreement Wizard.
Contrary to common belief, you don't need a one-to-one mapping from each Exchange 5.5 recipient container to an organizational unit (OU), although you can implement such a configuration if you want more granular control of the CAs. ADC-generated accounts (disabled by default) are also placed in the corresponding OUs under OU=EX55,DC=Aeronet,DC=local. In my client's environment, AD stores the most updated user information. Therefore, on the Advanced tab of the Recipient CA Properties box, you must set the Initial replication direction for two-way Connection Agreements option to From Windows to prevent any information loss.
Most of the company's users had just one mailbox each, and about 100 accounts had more than one mailbox. The configuration also included generic mailboxes with rights delegated to either an AD security group or DL. Because Exchange 200x in AD allows only one mailbox per user-account relationship, we used the ADC Tools' Resource Mailbox Wizard to associate each user account with a primary mailbox and mark the rest as resource mailboxes. Unfortunately, the wizard's descriptive text made it difficult to clearly distinguish accounts that had multiple mailboxes, so we still had some mismatched accounts that required manual account and mailbox cleanup. To learn how to manually clean up the User account and mailboxes, see the Microsoft article "How to connect mismatched accounts after Active Directory Connector replication in Exchange 2000 Server" (http://support.microsoft.com/?kbid=256862).
SRS and RUS
In an Exchange mixed-mode environment, you must maintain constant directory- and configuration-information replication between Exchange 5.5 and AD. SRS, which is automatically installed on the first Exchange 2003 server, performs this replication by using LDAP over port 379. However, we discovered that SRS isn't supported in a Windows 2003 cluster environment, which is how we implemented the two Exchange 2003 mailbox servers. Because we had just one other server available and it was already assigned the front-end server role (OWA), we had to join it as the first Exchange 2003 server to the existing Exchange 5.5 organization, as noted earlier.
After we successfully migrated all the data to Exchange 2003 and the messaging environment stabilized, we removed SRS from the Exchange 2003 OWA server. And as soon as ADC replicated the Exchange information across AD, the Configuration CA was automatically removed from ADC. We then manually deleted the remaining CAs before uninstalling ADC from AEROFS20.
An Exchange 2003 installation also requires the Recipient Update Service (RUS), an Exchange System Attendant service component that's also automatically installed on the first Exchange 2003 server (in our case, the OWA server). RUS creates and maintains Exchange-specific attributes, such as email addresses and address lists in AD. You must allow this information to fully replicate throughout AD before new mailbox-enabled users can gain access to their mailboxes. Otherwise, you'll get the error message Cannot start Microsoft Office Outlook: Unable to open the Outlook window. The set of folders could not be opened.
Although you can install RUS on a Windows 2003 cluster, it's not designed to run on a front-end server. This rule applies to the Offline Address Book (OAB) service as well. Thus, we had to move these two services to the back-end cluster (AEROEC01) when we were ready to configure the front-end server as OWA.
OWA and the User Experience
How users experience OWA depends on which front-end server they connect to as well as where their mailboxes are located. In Exchange 2003, all mailbox-enabled user accounts are OWA enabled by default.
Figure 1 shows OWA access paths depending on the various permutations of front-end server and mailbox location. The only scenario that doesn't work is when a user connects to an Exchange 2003 OWA front-end server while his or her mailbox is on an Exchange 5.5 back-end server (path C). Otherwise, the corresponding OWA interface will display correctly, with no special configuration required on the back end, front end, or client side.
By default, Integrated Windows authentication is enabled on the HTTP Exchange Virtual Server. You can configure Integrated Windows authentication on the back-end server by using the menu options Access, Authentication. This authentication mode grants users currently logged in to the domain transparent access to their mailbox by using the URL http://owa.aeronet.local/exchange. Because the company uses shared workstations, however, we chose to leave the Integrated Windows authentication option unselected. We also discouraged users from selecting the browser's Remember my password option. These measures force users to always supply their credentials to gain access to the correct mailbox through OWA, thereby protecting individuals' data and privacy.
Note that we found many instances in which Microsoft Internet Explorer (IE) 6.0 browser clients couldn't correctly render the OWA interface until we upgraded the front-end server to Exchange 2003 SP2. Microsoft recommends you upgrade all front-end servers to SP2 before applying the same service-pack level to the back-end servers.
Viewing Custom Address Lists
We quickly found that users whose mailboxes were successfully moved to Exchange 2003 could no longer view the various Exchange 5.5 custom recipient lists through the Outlook 2003 Messaging API (MAPI) client. All the custom recipient lists instead were consolidated under the categories listed in the GAL below All Address Lists, as Figure 2 shows. Users were suddenly disoriented and didn't know where to find address information for, say, John Doe in the Engineering department. Alas, our training schedule couldn't accommodate the huge user demand, which didn't help appease the user base.
Unlike in Exchange 5.5, custom address lists in Exchange 2003 contain a dynamic listing of objects in the Exchange organization based on user-defined filters. Initially, we thought we could create a custom address list by building an LDAP query-based filter against an AD OU. But after some investigation, we found this wouldn't work, as explained in the Microsoft article "Cannot use an organizational unit or the location of an account for recipient policy" (http://support.microsoft.com/?kbid=296112).
In the end, we decided to standardize a number of AD attributes on the different object types found under each AD OU. To do so, in Exchange System Manager (ESM), we expanded the Exchange server's Recipients, All Address Lists and selected the New right-click menu option. We then built a customized Exchange address list by specifying, for example, a value such as Engineering for the Department attribute as part of an LDAP query-based filter. Figure 3 shows a sample LDAP query-based filter to create a custom address list. We exploited this feature to provide a pseudo map of the dozen or so old Exchange 5.5 address lists under All Address Lists to ease user transition and simplify administration. (To learn how to use address lists to group users, see the Microsoft article "How To Use Address Lists To Organize Recipients in Exchange 2003" at http://support.microsoft.com/?kbid=319213.)
Planning for Success
Except for the few snags I've described, the migration from Exchange 5.5 to Exchange 2003 went smoothly. The company ended up with two Exchange 2003, Enterprise Edition SP2 mailbox servers running on a Windows 2003 SP1 two-node active/passive cluster as well as one Exchange 2003 OWA server. We switched the Exchange organization to native mode in anticipation of a future transition to Exchange 2007. Outlook 2003 is the standard client on new workstations, although the organization continues to support legacy clients. The company also migrated to BlackBerry Enterprise Solution 4.1 to support mobile users in the new environment and, after evaluating other backup options, has decided to use LTO-2 technology to back up its new Exchange 2003 infrastructure.
Through this upgrade process, my colleagues and I learned that a successful migration depends on three key elements: thoroughly planning ahead for the migration, performing rigorous migration testing, and learning from the experience of other IT pros. In preparing for the many facets of a real-life move to Exchange 2003, those who've experienced a similar migration first hand can help you better understand, plan, and anticipate pitfalls that aren't obvious or clearly documented. I hope this article's real-world lessons help you perform a successful migration to Exchange 2003.
