Migrating from Legacy Exchange
- Pre-Migration Operational Evaluations
- Exchange Migration Roadma
- Prerequisites and Precautions
- Active Directory Connector Operation
- Forest and Domain Preparation
- ADC Installation
- Connection Agreement Properties
- Initial Exchange 2003 Server Installation
- Connection Agreement Testing
- Site Replication Service Configuration
- Completing the Migration
- Shift to Exchange Native Mode
- Looking Forward
Up to this point in the book, you've worked with a pristine installation of Exchange 2003 in either a Windows Server 2003 or Windows 2000 forest. But while you've worked through the examples and studied the process descriptions and configured your lab, you've probably been wondering how you're going to put this information to use in a production environment that already contains legacy Exchange servers.
Throughout this chapter, the term "legacy Exchange server" refers to servers running Exchange 5.5 or earlier. Features and options that apply solely to Exchange 2000 servers are called out separately.
Before taking on the complex task of migrating your Exchange organization, I invite you to relax and take a few moments to consider the broad expanse of history before computers and digital communications and e-mail, before even the advent of the printed word itself. Back to a simpler time when common folk such as ourselves found inspiration in tales of great heroes who battled mighty foes in pursuit of lofty goals.
One ancient character embodied the very definition of heroism itself, the Greek warrior Heracles. Overcome by madness in his early life, Heracles killed his wife and children. When he sought purification for this act, he was given 12 deadly labors, which he undertook while prepared to die. Instead, he overcame the odds and bested all his opponents. In his maturity, Heracles went on to avenge many evils and eventually had his own action figure and a slot in the AWWF (Ancient World Wrestling Federation).
The story of Heracles puts me in mind of an Exchange 2003 migration because one of the 12 deadly labors involved in defeating the many-headed Hydra. The Hydra posed a special challenge for Heracles.
Not only was each individual head of the monster especially ferocious, but if he lopped off one of the heads, two more would grow back in its place. Every apparent success put him closer to defeat, a perfect metaphor for e-mail administration, regardless of the messaging platform you use.
When you get in the middle of your Exchange migration and you face problems that seem to multiply geometrically like the heads of the Hydra, you might want to take a hint from the way Heracles solved the problem. He didn't try to do the job himself. He sought help from his nephew, who cauterized each neck as Heracles swooped off the head, preventing a new head from growing. Thus they were able to bring down the monster and move on to the next labor.
I'm not telling you to hire your nephew for your Exchange 2003 migration. What I'm advising is this: Approach the migration with all due respect and work with your colleagues to prepare for unexpected calamities. Set reasonable expectations for your management and users. Don't promise a completely transparent and problem-free transition, although that might very well happen. Instead, promise that you'll do your best to stand between your users and any monsters as you make the transition. When everything goes smoothly, your users might not declare you a hero like Heracles, but they'll be happy enough with the experience to continue bringing you cookies and chocolate cake when they want you to do something special with their e-mail. What more could an Exchange administrator want?
Pre-Migration Operational Evaluations
At some point early in your migration planning, you're going to need to sit down with a clean sheet of paper (or a blank computer screen) and figure out what you're going to do. You should test all your actions in a lab first before rolling them out into production. You might also want to arrange for a pilot program where selected users are placed in a separate forest where you perform the entire migration in an environment that more closely matches the production configurations than might be possible in a lab.
It's also important to document your current configurations. You would be surprised how often you'll need to know where a user's mailbox used to be, or what server used to be located in Sheboygan, or what information is available only on old backup tapes buried in a mountain somewhere.
Here is a list of items that you should include in your pre-migration planning. You'll also find a prerequisite list later on in the chapter along with a roadmap for the major steps in the migration.
Active Directory Domains
Evaluate your current domain configuration with an eye toward making sure that it will support Exchange 2003 operations. The deployment tools that come with Exchange 2003 help you to test for these conditions, but it's a good idea to get familiar with the requirements in advance. Here are some items to consider:
-
Domain controller location. You'll need at least one domain controller in each office that has an Exchange 2003 server.
-
Global Catalog server location. You'll need at least one Global Catalog server in each office that has an Exchange 2003 server. This can also act as the local domain controller. The simplest way to accomplish this is to make all branch office DCs into GCs. Microsoft recommends a minimum of one Global Catalog server for every four Exchange processors, not servers.
-
DNS configuration. Make certain that DNSLint shows no errors. See Chapter 1, "Installing an Exchange 2003 Server," for details.
-
Active Directory Native Mode. The Active Directory domain containing the Exchange servers must be in Native Mode so that you can use Universal Security Groups for e-mail distribution.
-
Replication or authentication problems. Verify by a sweep of the event logs that you have no errors from directory service replication, KCC topology calculations, or authentication errors originating from domain controller accounts. You can use the EventCombMT utility, a free download from Microsoft, to perform this sweep. EventCombMT is part of the Account Lockout and Management and Lockout, available at http://snipurl.com/5z37.
If you're willing to spend a few dollars and a couple of weekends learning the configuration, you'll find that Microsoft Operations Manager (MOM) or a third-party product will do a better job of monitoring your event logs.
Current Exchange Organization
Evaluate your current production Exchange organization to make sure that you don't have any outstanding issues that might cause a problem during the transition to Exchange 2003.
The ExMap utility from the Exchange Resource Kit and the ExInfo utility (a free downloadsee Microsoft Knowledge-Base article 305816) can assist in this information-gathering phase. Here are some key points:
-
Exchange server version. You'll need at least one Exchange 5.5 server with SP3 or higher in each site.
-
Site configuration. Verify that you have an active Exchange server in each site. If you have sites that are no longer used, remove them from the legacy Exchange directory service prior to commencing the Exchange 2003 deployment. It is extraordinarily difficult to remove a site from the Link State Table once it has been placed there.
-
Site connectors and Directory Replication connectors. Make sure that you get proper message routing and directory service updates through your existing connectors. Resolve any problems prior to commencing the Exchange 2003 deployment.
-
Internet connectors. Identify the servers that are acting as Internet Messaging Service (IMS) bridgeheads. You'll want to plan on replacing these servers with Exchange 2003 servers early in your deployment.
-
Unsupported connectors. If you have connectors to third-party messaging systems that do not have Exchange 2003 connectors, such as PROFS and SNADS, you'll need to find another way to connect the systems or plan on installing at least one Exchange 2000 server to act as the gateway.
-
Key Management Services. If you are using digital certificates issued by an Exchange Key Management Service to encrypt and digitally sign e-mail, then you'll need to deploy a Windows Server 2003 PKI and migrate the KMS database to a Windows Server 2003 Configuration Authority. This procedure falls outside the scope of this book. Microsoft has an excellent white paper on migrating a legacy KMS.
-
Compatible backup. Make sure the backup software you're using supports Exchange 2003 and that you have the most current backup agents installed on the Exchange 2003 servers. You can use NTBackup that comes with Windows Server 2003 until your vendor gets a compatible agent. See Chapter 13, "Service Continuity," for details.
-
Antivirus and antispam software. Make sure that your centrally managed antivirus and antispam solutions have agents for both legacy Exchange and Exchange 2003. Make sure that any new servers are included in signature distribution. If your antispam solution runs at a smart host in the perimeter, make sure that any tagging done by the application is compatible with the Exchange 2003 antispam API. See Chapter 13 for more information.
-
E-mail dependent applications. If you use third-party applications that depend on Exchange, such as fax, telephony, or collaboration services, make sure that the application has a version that runs on Exchange 2003. Check their product databases for special configuration requirements and any known problems.
-
Exchange 2000 instant messaging. Must be isolated from Exchange 2000 mailbox/public folder servers that are going to be upgraded to 2003.
Network Infrastructure
Evaluate your WAN connections and network routing topology to make sure that you have sufficient capacity for Exchange 2003 and to give you an idea where to create Routing groups. Here are some important considerations:
-
Traffic patterns. If your WAN infrastructure handles the current Exchange message traffic with no problems or errors, you should not experience problems with Exchange 2003. However, keep in mind that the combination of Outlook 2003 in cached mode and Exchange 2003 can result in a significant amount of traffic on Monday mornings when users refresh their local message cache with e-mails received over the weekend. Warn your network services colleagues and check the Microsoft white paper titled "Client Network Traffic with Microsoft Exchange Server 2003." Download it from www.microsoft.com/exchange/techinfo/outlook/CliNetTraf.asp.
-
Outages. Have you experienced any significant outages in the last six months that might recur and impact your deployment? Instabilities in WAN connections can also cause message routing issues as you make the transition from legacy Exchange routing based on the Gateway Address Routing Table and the Link State Table used by Exchange 2003.
-
Remote users. If remote Outlook users currently connect to the Exchange system via a VPN or dial-up to get their e-mail, you might want to consider deploying RPC over HTTP to support remote e-mail access, especially if e-mail is the only reason that users need a VPN. See Chapter 11, "Deploying a Distibuted Architecture," for more information.
-
Routing groups. Use your Active Directory site map to help define your routing group topology. You don't need to follow them slavishly, though. SMTP works fine over high-latency connections that might cause a problem for Active Directory. Consider consolidating existing sites into a single Routing group based on the traffic volume you see after the deployment. For example, you might have several campuses in the same city connected by fractional T1s in a frame relay cloud. You might have defined separate legacy sites to control bandwidth, but with Exchange 2003, you can use a single Routing group for the entire city. This simplifies mail routing and makes it simpler to manage public folder access.
Costs
Deploying Exchange 2003 requires money, time, and people.
-
Server software. Exchange 2003 Standard Edition lists for $699. Enterprise Edition lists for $3,999. You'll need to purchase Exchange 2003 Enterprise Edition if you want to set up shared-disk clusters or if you need multiple mailbox stores with virtually an unlimited database size. (Standard Edition allows only one mailbox store and limits it to 16GB.)
-
Client Access Licenses (CALs). You do not need to deploy a new client, but you will need to pay for and upgrade your CALs. Each CAL lists at $67 with substantial discounts for upgrade licenses and volume purchases. If you deploy Exchange in several business units, it's theoretically possible to delay the upgrade for a particular business unit until they have the money for the CALs. But in practical terms, you should purchase your licenses up front before you begin deployment.
-
Additional personnel. When estimating the personnel component of your deployment costs, don't forget to factor in a consultant or two who can help you streamline the deployment as well as budgeting for support calls to Microsoft Product Support Services (PSS) if something doesn't go well.
-
Training. Budget for in-depth training for the Exchange administrators and high-level summary training for the Windows system administrators, since they interact with Active Directory objects that affect Exchange operation. End-user training is important, too, if you are going to roll out new clients.
-
Client software. When deciding whether to deploy a new client in conjunction with the Exchange 2003 deployment, keep in mind that you get the full range of features, including cached message handling, if you roll out Office System 2003 or Outlook 2003. (The standalone version of Outlook 2003 can be used for no additional change once you pay for the Exchange 2003 Client Access License.)
When deciding how to size your servers, take a look at the Microsoft white paper titled "Server Consolidation Using Exchange Server 2003." This paper takes a fair look at the factors that affect server sizing and gives you a good baseline to start your testing.
Additional Considerations
Categorize and define the potential problems and challenges you might face during the upgrade. Here are some of the more important items to consider:
-
Directory service connection failures. If you have underlying DNS issues, either with client configuration or the DNS server itself, you can find yourself in situations where the Exchange servers can't locate domain controllers and Global Catalog servers. This results in a variety of errors. See Appendix A, "Building a Stable Exchange 2003 Deployment Infrastructure," for more information about DNS configuration and troubleshooting.
-
Inability to access public folders. If public folder permission mapping fails for some reason, such as invalid permission list entries, then users might lose access to their public folders. See Appendix B, "Legacy Exchange Operation," for more details about permission mapping.
-
Inability to replicate public folders with legacy Exchange. Before you can decommission your legacy Exchange servers, you must move all public folder content to the new Exchange 2003 servers. This includes system folders that contain critical calendaring and offline address book information. It sometimes happens that this replication fails, so part of your testing should monitor for correct content of all folders prior to removing a legacy server from operation.
-
Incompatible historical backups. If you deploy Exchange 2003 and decommission all your legacy servers, and then need to restore a mailbox from a date preceding the deployment, you won't be able to restore the legacy Exchange mailbox database onto an Exchange 2003 server. Leave the Exchange organization in Exchange Native mode until you're sure that you won't need the old backups.
-
Hardware failures. You're going to be deploying new servers running Exchange 2003. There's always the likelihood that you'll find incompatibilities in the new hardware or component drivers. Be prepared to get quick help in the event of a failure, and make sure all hardware is listed in the Windows Server Catalog (which used to be the Hardware Compatibility List).
-
Software compatibility failures. You could find that your selection of backup, antivirus, and antispam tools or other server utilities causes the server to become unstable. If you encounter problems keeping the server operating, one of your first steps should be to deactivate all third-party software, just to see if that makes the problem go away.
Goals
-
No service interruptions. In today's IT environment, messaging is supposed to be as pervasive and available as a dial tone. The major contributors to downtime during a typical Exchange migration are incorrectly configured DNS settings, unstable Active Directory replication, improper hardware, improperly configured Routing groups, and lack of coordination between the Exchange administrators and the other IT staff.
-
Single mailbox-enabled account for each user. In your existing Exchange environment, you might have many legacy mailboxes owned by a single user. Or you might have mailboxes that have no owner. During the migration to Exchange 2003, you will normalize your mailbox ownership so that each legacy mailbox has one and only one valid user. This is done as part of the ADC deployment.
-
Retain existing mailbox and public folder permissions. Exchange maps legacy Exchange MAPI permissions to the ACL-based security descriptors in Exchange 2003. It's important that this mapping work correctly. Be cautious and do lots of testing before making any large-scale changes to permissions.
-
Fastest possible introduction of new features. To take full advantage of the new features in Exchange 2003, you need to complete the Exchange migration and decommission all legacy Exchange servers. Don't let weeks turn into months turn into years. Until you shift to Native mode, you won't be able to take full advantage of the features you paid for.
-
Maximize existing hardware. It's one thing to pay for the Exchange 2003 server software and CALs. It's quite another to pay for a new fleet of servers to run Exchange. Be sure to inventory your server hardware with an eye toward adding RAM, faster disks, more storage, and possibly an updated network adapter that can offload SSL and TCP/IP services.