For Exchange administrators, an ideal Exchange Server 2007 transition would include a pristine environment with the latest hardware, updated messaging systems, no concerns about loss of data or functionality, and plenty of time to test and deploy the new installation. More typically, Exchange administrators must swiftly transition their current messaging solutions to Exchange 2007 over a weekend or slowly through a coexistence period. Exchange 2007's new server roles and confusing terminology might leave you wondering how and when to begin the transition process. You can kick off your transition to Exchange 2007 and help ensure that it’s an orderly process by performing certain checks prior to the transition, preparing Active Directory (AD), and installing Exchange 2007’s server roles in the optimum order. Additionally, by setting up an environment in which your legacy Exchange servers and Exchange 2007 server coexist while you move mailboxes and transition public folders, you can make the change-over easier for IT and end users.
Clarifying Terms
Before I explain how to conduct these Exchange 2007 transition steps, I'll clarify some of the terms I’ll use. I use the words upgrade and transition interchangeably within this article, but there are subtle differences between the two terms.
When I refer to the overall process of moving from a legacy messaging system to Exchange 2007, I call it an upgrade. But I’m not referring to the traditional in-place upgrade we perform with most software. Because Exchange 2007 must be installed on a 64-bit system with a 64-bit OS (a requirement that we didn’t have with previous Exchange versions), there’s no way to “upgrade” a pre-existing server. A transition is the process of moving from Exchange Server 2003 or Exchange 2000 Server to Exchange 2007. The process isn't an upgrade because you can't simply install Exchange 2007 over Exchange 2003 or Exchange 2000. The entire transition includes a messaging-system upgrade and a new-hardware installation, which will work together during the new and legacy Exchange environments’ coexistence period. Note that I didn’t mention Exchange Server 5.5 in this transition discussion. That’s because Exchange 5.5 is so architecturally different that it’s actually considered a messaging system that you “migrate” from (much like Lotus Domino or Novell GroupWise) as opposed to transition from.
You might want to integrate Exchange 2007, move all mailbox and configuration data, and start the legacy-system decommission immediately. Or you might prefer a slower transition pace. In either case, you’ll have a coexistence period while you perform the transition. I'll leave the timeframe determination up to you and next show you how to begin preparing for your transition to Exchange 2007.
Make Your Checks
You can start preparing for your Exchange 2007 transition by performing the following checks, to ensure the best possible transition environment:
- Confirm there are no Exchange 5.5 servers operating within your organization.
- Make sure you've removed any Exchange 5.5 server connectors.
- Make certain your Exchange organization is running in native mode. (If you run Microsoft Exchange Best Practices Analyzer—ExBPA—before the transition, ExBPA should tell you this information. Otherwise, you can check the mode via the Exchange organization’s properties.)
- Ensure that the relevant Exchange service packs were correctly applied in a timely way. You should have Exchange 2003 SP2 and Exchange 2000 SP3 installed.
- Make sure that the domain controller (DC) that holds the schema master role is running Windows 2003 SP1 or later.
- Verify that your Global Catalog (GC) servers are running Windows 2003 SP1 or later.
- Change the domain functional level (DFL) to operate in native mode.
Next, use ExBPA to detect any changes necessary to make your AD and Exchange organization transition ready. ExBPA scans your environment and either reports that you're transition ready or points out needed changes. Figure 1 shows the ExBPA console with tabs for critical issues, all issues, and informational items. You can download ExBPA here (check for the latest version). For more information about ExBPA, see the ExBPA articles in the Learning Path box.
A common error that ExBPA might flag is Link state suppression is not enabled, which you can see on the All Issues tab in Figure 1. You need to correct this error and enable link-state suppression if you plan to create multiple connectors to the dedicated Exchange 2007 routing group, to prevent routing loops. For more information about this error and how to fix it, see the sidebar “How to Fix the Link-State Suppression Error." After you've made any ExBPA–recommended changes, the next step is to prepare AD for the transition.
Prepare AD
After having ExBPA lay out the necessary organization changes for you, manually prepping AD might seem more daunting. But the Exchange 2007 setup program provides four AD transition-prep switches that make it fairly easy to get AD ready. You can manually install the switches if you need extensive process control, such as if your AD topology is quite large and change replication might create a ton of replication traffic throughout your domains, or if your company's policies dictate the need to prepare AD before deployment. If you don’t require that much control, you can simply start the Exchange 2007 installation and the switches will automatically run. In either case, the process is straightforward.
You might have to decide beforehand on which platforms the switches will run. Exchange 2007 is designed for 64-bit platforms, and your Exchange transition might occur before the new 64-bit server is up and running. In that case, you can use the 32-bit Exchange test version to kick off the AD prep switches from your existing 32-bit servers. (For more information about using the 32-bit test version of Exchange in this way, see the Windows Server Clustering & PCNews blog.) Keep in mind that before you can use the switches, you'll need to install Microsoft .NET Framework 2.0 and Windows PowerShell on the server you want to run the switches from.
Here are the four Exchange 2007 AD prep switches:
- /PrepareLegacyExchangePermissions—Microsoft recommends you run this switch in the forest root domain and on the Exchange 2007 server. This switch ensures that Recipient Update Service (RUS) correctly functions after you update the schema for Exchange 2007. (You can learn more about the /PrepareLegacyExchangePermissions switch at technet.microsoft.com/en-us/library/aa997914(EXCHG.80).aspx.)
- /PrepareSchema—As you might guess, the /PrepareSchema switch makes changes to the schema. It will either automatically connect to the schema master role, or you can manually run it on the schema master role. (For more information about the schema changes the /PrepareSchema switch makes, see technet.microsoft.com/en-us/library/aa997467.aspx.)
- /PrepareAD—This switch makes a number of helpful AD changes, such as creating both root and existing domain Universal Security Groups (USGs), Exchange Administrative Group (FYDIBOHF23SPDLT), and Exchange Routing Group (DWBGZMFD01QNBJR). You can't see the groups though Exchange 2007’s Exchange Management Console (EMC); you can view the new groups only through Exchange System Manager (ESM) in Exchange 2003 or Exchange 2000. You can make changes (i.e., creating new routing-group connectors) by using Exchange Management Shell (EMS) cmdlets on the Exchange 2007 server. (To learn more about creating Exchange 2007-to-Exchange 2003 routing-group connectors, see technet.microsoft.com/en-us/library/aa997292(EXCHG.80).aspx.) Note: If you run the /PrepareAD switch before the /PrepareSchema and /PrepareLegacyExchangePermissions switches, the /PrepareAD program will detect this and will automatically run the schema and permissions switches.
- /PrepareDomain and /PrepareAllDomains—You run these switches in the domain or domains that will house Exchange 2007 servers. These switches configure an Exchange server’s domain-container permissions for Organization Administrators, Authenticated Users, and Mailbox Administrators. The /PrepareDomain and /PrepareAllDomains switches also create the System Objects container, establish proper permissions on that container, configure a new domain global group called Exchange Install Domain Servers, and add that group to the USG.
When AD is transition ready, your next step is to decide the order in which you’ll install Exchange 2007's server roles.
Server Roles
The order of Exchange 2007 server-role installation depends partly on the size of your existing organization. You might have a large organization with front-end servers handling your Outlook Web Access (OWA), back-end servers handling your mailboxes, and bridgehead servers keeping the entire structure together.
The Client Access server role is the first role you should install. Exchange 2003 and Exchange 2000 front-end servers can't access Exchange 2007 mailbox servers. But Exchange 2007 servers with the Client Access server role installed can access your legacy Exchange systems, so the first step is to replace the legacy front-end servers with the Exchange 2007 servers.
Next, install the Hub Transport server role. An Exchange 2007 mailbox server can't send or receive mail without the Hub Transport server role installed. Thus, as a best practice, Microsoft recommends you first install the Client Access server role, then install the Hub Transport server role, then establish the infrastructure upgrade, and only then deploy the Mailbox server role. However, if you aren't transitioning a large organization, you can deploy an Exchange 2007 server and install the Client Access, Hub Transport, and Mailbox server roles all at once.
After you’ve installed all the server roles, you’ll need to use the Edge Transport server role or the Hub Transport server role to ensure that your SMTP mail goes directly to the Exchange 2007 server. The server role you use to enable SMTP connectivity will determine to which server you point DNS.
To use the Edge Transport server role, you must know how to configure the subscription between the Edge Transport server role and the Hub Transport server role. If you use the Hub Transport server role, you must make sure anonymous users can connect to the Exchange 2007 Hub Transport server; otherwise, you can't receive Internet email. You’ll also need to configure the Send connector information in the Hub Transport server role. In general, unless your Exchange organization is very small. it’s preferable to use the Edge Transport server role to handle incoming and outgoing Internet mail, rather than configure the Hub Transport role for this purpose, since the Edge Transport role provides a buffer between the Internet and the rest of your Exchange organization. (For more information about deploying the Hub Transport and Edge Transport server roles, see technet.microsoft.com/en-us/library/aa997610%28EXCHG.80%29.aspx.) Once your environment is transition ready and the server roles are installed, you can start moving mailboxes.
Moving Mailboxes
Exchange version coexistence is usually a forward-moving process of elimination. As mailboxes are moved to the new environment and legacy services become unnecessary, you decommission your Exchange 2003 and Exchange 2000 servers to reach a pure Exchange 2007 environment. The mailbox-moving process is an important transition step. If you need to determine which mailboxes are residing on legacy systems and which ones are residing already on your Exchange 2007 MB servers, before moving mailboxes, look in the EMC Recipient Configuration container to find all recipients in your organization, as Figure 2 shows.
To transition mailboxes within the same forest, you can use either the EMC Move Mailbox wizard or the EMS Move-Mailbox cmdlet. To use the Move Mailbox wizard, open the EMC Recipient Configuration node and select the mailboxes you want to move, as Figure 3 shows. Next select Move Mailbox from the Actions pane to start the wizard. In the wizard, you can select a new mailbox location and establish a schedule for when you want the move to occur, as Figure 4 shows.
A word of warning: You can't move mailboxes using ESM in Exchange 2003 or Exchange 2000. ESM will begin the process and select the new server, storage group (SG), and database, but then the process will fail and you’ll get the error The requesting program is an incompatible version… because ESM won't recognize the process as a valid mailbox-moving step. Also note that you also can't use EMC to move mailboxes from one forest to another. To transition mailboxes between forests, you must use the Move-Mailbox cmdlet.
Moving mailboxes via the command line using EMS is a bit more complicated. You can use the Move-Mailbox cmdlet to move a single mailbox, a small group of mailboxes, or perform a bulk mailbox move. For example, to move a large number of mailboxes at one time, use the following Move-Mailbox command:
Move-Mailbox PrimaTech\Bill -TargetDatabase "Second Storage Group\MB Database"
This command moves all mailboxes named Bill in forest PrimaTech to the Second Storage Group on the Exchange 2007 server into mailbox database MB. (You can learn more about moving mailboxes via both the EMC Move Mailbox wizard and the EMS Move-Mailbox cmdlet at technet.microsoft.com/en-us/library/bb124797(EXCHG.80).aspx and this article’s Learning Path box. To learn more about using PowerShell to manage Exchange 2007, check out the articles listed in the Learning Path.)
Transitioning Public Folders
Mailboxes aren’t your only worry when transitioning to Exchange 2007. If you have a public folder structure, it's important to determine whether you’ll continue using Microsoft Office Outlook 2003 or will upgrade to Microsoft Office Outlook 2007 before decommissioning your last Exchange 2003 or Exchange 2000 server. Unlike every previous Outlook version, Outlook 2007 doesn’t require public folders to function. So, you could eliminate the need for public folders by upgrading to Outlook 2007. However, if you already have an extensive public folder structure, you might want to keep those public folders around for a bit. You might also consider eventually moving to Windows SharePoint Services (WSS), especially because Microsoft is de-emphasizing public folders in future Exchange releases. (To learn more about Microsoft's public folder plans, visit the Microsoft Exchange Team Blog.)
Another concern is the Schedule+ Free/Busy folder, which stores users’ availability information. If you use Exchange 2007 and Outlook 2007 clients, the folder isn't necessary because Exchange 2007 and Outlook 2007 use a new and more efficient Availability service. However, if you plan to keep legacy Outlook clients in your environment, you'll continue to need public folder information.
To keep the public folder structure, but remove Exchange 2003, you must install a public folder database on the Exchange 2007 server, then set up a public folder replica on the Exchange 2007 server using Exchange 2003 ESM or through EMS. The original Exchange 2007 release didn’t let you manage public folders via EMC; instead, you had to use EMS to do so. Exchange 2007 SP1 lets you manage public folders using EMC, so you can set up new replicas through EMC in SP1 rather than reverting back to Exchange 2003 to do so. Make sure you replicate a copy of each public folder onto your Exchange 2007 servers so that you don’t lose any public folder data. If you're using Exchange 2003 ESM to transition public folders, you can use the Manage Public Folders Settings Wizard to add servers to the replica list.
If you have a huge Exchange environment with many public folders, you're better off using the MoveAllReplicas.ps1 replica script, which is located in the %SystemDrive%\Program Files\Microsoft\Exchange Server\Scripts folder. As with all new scripts, make sure you test and adjust it before using it in your environment. The Schedule+ Free/Busy folders and the Offline Address Book (OAB) folders will automatically replicate when you deploy your Exchange 2007 server into your organization.
Once the folders are replicated, you can start removing legacy servers from the replica lists. After ensuring that all the data is removed, delete the database. You can't delete the Exchange 2003 server's databases unless the folders are empty. The Exchange 2000 deletion process isn't as intuitive in that you can delete the databases prior to the folders being empty, so you should be extra cautious when performing each replication and removal step.
Additional Transition Concerns
After you’ve migrated mailboxes and transitioned your public folders from your legacy Exchange server, there are other issues you need to prepare for, such as ensuring that your OWA and Outlook Anywhere users can access their email. You might also have firewall concerns, network issues, and DNS configuration changes to make sure everything is pointing in the right direction.
Decommission
The amount of time your legacy and Exchange 2007 servers coexist is up to you. Determining the coexistence timeframe should be part of your design process to determine ways of moving forward in a timely and organized manner. But eventually you’ll want to delete the routing group connector that was created when you ran the setup switches for your installation of Exchange 2007. Then use Add/Remove Programs to remove legacy Exchange servers. Remember that before you uninstall legacy Exchange data, use ESM to assign RUS to Exchange 2007. Exchange 2007 doesn’t use RUS, but you need to be concerned about it anyway because the Exchange 2003 server won’t allow itself to be uninstalled unless it knows RUS is in the hands of another server. Microsoft is supposedly preparing a hotfix that prevents you from assigning RUS to Exchange 2007; if this comes to pass, use ADSI Edit to delete RUS from the configuration, along with the legacy ESM. Congratulations, you've finished the transition!
The Road to Transition
The Exchange developers have made the transition to Exchange 2007 an intuitive and reasonable process. You can use ExBPA to help you prepare your Exchange organization for the transition, then simply follow the steps I’ve described. Email me and tell me about your Exchange 2007 transition successes and challenges.