In-Depth
10 Exchange Migration Tips
Use these helpful tips to ensure your move to Exchange 2003 goes smoothly.
Migrating to Exchange 2003 can be a daunting task. During almost every migration there will be at least one or two bumps in the road, but as long as you're prepared, your migration will be a smooth one. While planning your migration to Exchange 2003, there are several tips you can follow to help make your transition a bit easier. But before I start, let's get a few preliminaries out of the way.
Have good backups. Not enough can be said about having good backups prior to any upgrade or migration. Hopefully you have good backups even if you're not upgrading or have already completed your upgrade to Exchange 2003. I want to make one thing perfectly clear: Having good backups is different than having a good backup plan. There are stages in the migration that will be irreversible (or difficult to reverse). So, although backups are important you don't want to rely on them entirely. Using backups for a failed migration is usually a last resort, but it can be crucial in a complete disaster. And, don't forget to make sure you've actually tested your backups! In the worst case you can always review Microsoft Knowledge Base Article (KBA) 839356, "How to roll back a failed migration from Exchange Server 5.5 to Exchange 2000 Server or to Exchange Server 2003," should you feel the need to back out of the migration entirely.
Run the latest Service Packs. You should be running the latest Service Packs and patches whenever0 possible. There are some circumstances where you might not be running the latest Service Pack (third-party application compatibility, for example). However, an upgrade to Exchange 2003 will have very specific requirements. As a general rule, when possible make sure all your Exchange servers and Domain Controllers are upgraded to the latest service packs possible. For more information on specific requirements see KBA 822942, "Considerations when you upgrade to Exchange Server 2003."
Know your strategy. You should know what your overall migration plan and strategy will be and stick with it (kind of). Whether you will be using a third-party tool, using the mailbox move method, or generating PST files (hopefully not!), make sure you know the benefits and drawbacks of your chosen migration method and are prepared to deal with the consequences of your choice. A description of some of the readily available migration methods can be found in KBA 327928, "A comparison of the migration methods for migrating from Exchange Server 5.5 to Exchange Server 2003 or to Exchange 2000 Server."
Now that I've covered the basics, here are 10 tips that can help you smooth out your migration.
Tip No. 1: Check Your Health
Before you make any changes to your environment, you should first make sure it is healthy. Besides making sure your systems are running the required Service Packs, it is important that you run DCDIAG and NETDIAG to confirm that your environment is healthy. Running these tools can help identify problems that can prevent you from having a successful migration.
The state of your name resolution, and more specifically the health of your DNS, is crucial. Make sure that DNS is functioning normally and that your Exchange servers have registered "A" records in DNS. DNSDIAG, which is included in the Windows Server 2003 Resource Kit, is specifically designed to help you identify and troubleshoot DNS problems that can affect Exchange. If you're migrating from Exchange 5.5 and using WINS, you should make sure WINS replication is working properly as well. The basic rule of thumb is you want all Exchange servers to be able to resolve one another—they do need to deliver mail, right? It is a good idea to make sure your servers are resolvable both by NETBIOS and FQDN (fully qualified domain name). If all of your Exchange servers can "find" each other, that's a good thing.
Tip No. 2: Take it Slow
Before you jump into migrating your Exchange servers to 2003, step away from the keyboard, take a deep breath, and stay calm. Don't rush into any part of the migration. Although it is tempting to try and migrate your entire Exchange ORG over the weekend to impress your boss with how quickly and easily things went, it is much less impressive to explain to him or her why half the users can't log into their mailboxes come Monday morning. You should plan on staging your Exchange migration into separate parts so you can manage the entire process and ensure each stage of the migration goes well.
This means that instead of installing your first Exchange server by simply running setup, you should use the /forestprep and /domainprep options to prepare the Forest and Domain prior to adding any Exchange 2003 servers to the ORG. Microsoft put these options there for a reason. They realize that smart administrators want to mitigate the risk of any changes to production and being able to separate out these tasks will provide for better tracking of issues that may occur. In addition, in larger organizations it is a good idea to wait until your entire infrastructure has replicated the new schema and domain changes before installing any new servers into the ORG.
After you've successfully prepared your forest and domain, you might wait a day or two to be sure everything is settled. You can use the OrgPrepCheck utility to make sure your ForestPrep and DomainPrep operations were successful. See KBA 274737, "How to Verify That ForestPrep and DomainPrep Completed Successfully in Exchange 2000 Server or Exchange Server 2003." If things look healthy, you then should proceed with other parts of the migration, such as upgrading front-end servers first, followed by bridgeheads, then the public folder and backend servers. That being said, you might not want to pull the trigger just yet, even if you have a single server environment.
Tip No. 3: Know Your Options
So you've chosen your migration method. You're going to do a swing upgrade with mailbox moves, which requires that you purchase some new hardware. It's definitely a good thing as you'll be starting with all fresh, new Exchange installations. What happens if something goes wrong? What happens if one of the mailboxes won't move? What are your options?
Before you dive right into any migration method, you should examine your options and have a secondary strategy should the migration fail. Although you know the advantages of the migration technique you chose, it is equally (if not more) important to know the disadvantages and especially pitfalls of that choice. Mailbox moves can fail for a variety of reasons from permissions to missing attributes to corrupted data. The important thing to remember is that if a mailbox move fails, you should be prepared to handle it, whether this means correcting an attribute, resetting permissions or, as a last resort, extracting the mailbox to a PST. Of course you don't want to rely on your backup plan too often, but knowing you have one can help you move forward with confidence throughout the migration.
Examine all parts of your migration and see what sort of options you'll have along each step of the way. Create "what if" scenarios to help you decide how you might deal with problems at each stage of the migration. Doing so will help you remain cool and collected if you do encounter problems.
Tip No. 4: Know Who's Who
Both before you migrate to Exchange 2003 and after, it's important to know what roles your Exchange servers hold in the ORG. But I'm not referring to roles such as front-end or bridgehead. Actually, I'm referring to Exchange-specific "master" roles that could be important to keep track of as you tear down and bring up new servers. Exchange is by no means a "multi-master" design—neither is Active Directory. We all know by now that when Microsoft compared Active Directory to NT, the claim that "all domain controllers are equal" was only somewhat true. We have FSMO master roles to keep track of. Exchange is no different. With Exchange 2003 there will be master roles you'll need to keep track of and ensure these servers are healthy.
Since Exchange 5.5, the first server in the site has been extremely important. If you decide to remove this server for any reason, you should be prepared to take special measures. Exchange 5.5 servers had a master role for things such as system folders (Free/Busy, OAB), routing calculation, and site folders. Objects such as connectors (SMTP, X.400, and so on) should also be given special attention. To identify the first Exchange 5.5 server, read KBA 235396, "How to Determine the First Exchange Server Computer in the Site." As you migrate and are ready to remove your last Exchange 5.5 server, you'll want to follow KBA 822450, "How to remove the last Exchange Server 5.5 computer from an Exchange Server 2003 administrative group."
If you are migrating from Exchange 2000 and will be removing the first Exchange 2000 server, you'll want to be concerned about some additional roles the server might hold. Exchange 2000 master roles are similar to those found in 5.5, though you now have some additional "master" roles; the Recipient Update Service (RUS) master and the Routing Group Master. Removal of an Exchange 2000 server is explained in KBA 307917, "How to remove the first Exchange 2000 Server computer from the site."
Tip No. 5: ADC Design
The Active Directory Connector (ADC) design can be critical, especially in larger organizations. A properly configured ADC will allow for synchronization of object attributes between the Exchange 5.5 directory and Active Directory. Many people tend to ignore or pay little attention to the ADC, but when properly configured it can play a powerful role in ensuring a smooth coexistence period with Exchange 5.5 and 2003.
When setting up your ADC, always make sure to use the latest version included with the most recent Exchange service pack, not the one included with Windows. In addition, configure connection agreements for every Exchange 5.5 site that meets your needs. When properly configured, your ADC will be able to add, modify, or remove objects in either directory and provide end users with seamless communication for both users on the legacy Exchange 5.5 ORG and those migrated to Exchange 2003.
Tip No. 6: Avoid Known Issues
Make sure you have reviewed Exchange 2003 documentation so you can avoid common problems and mistakes. The infamous "mangled attribute" problem can be avoided easily if you plan for it in advance. KBA 314649, "Windows Server 2003 adprep /forestprep Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers," discusses how to identify and deal with this problem depending on how far into your migration you've gone. Be sure to review "Common Mistakes When Upgrading Exchange 5.5/2000 to Exchange 2003," found in KBA 555262.
Tip No. 7: A Server by a New Name
Exchange has the ability to direct users to the proper mailbox server, even if their mailbox is not on the server that the user attempts to connect to. This is known as profile redirection—make sure you take advantage of this. Plan for remote users and late comers, so don't change that server name just yet! This means if you decide to go with new hardware and a new Exchange server name, you should leave the old server up as long as possible. Of course, you can choose to keep the old server name on the same hardware, but this requires using an undesirable in-place upgrade or doing something like what is in described in KBA 822945, "How to move Exchange 2003 to new hardware and keep the same server name," which results in downtime.
No matter which migration method you choose, be sure to enable your users to take advantage of profile redirection. Clients will be able to connect using the old server name and have their Outlook profile updated automatically if needed. Use the Exchange System Manager to take a look at the account logons and the last time the mailbox was accessed to help you determine who still hasn't logged into the server. This way you know when everyone has had a chance to access the new server and have their Outlook profiles updated before you decommission the old server.
Tip No. 8: Clean House
There are some things that won't come with you into the new Exchange 2003 environment. Some of these things won't come because they are no longer supported. Instant Messaging, Exchange Chat, the Key Management Service, Microsoft Exchange Connector, and Microsoft Mail Connector are some that should immediately come to mind. In addition to removing these legacy connectors and services, you'll want to take your migration as an opportunity to identify other components within your organization that can be cleaned up.
Identifying unused mailboxes in particular will be extremely easy once you've migrated using the mailbox move method. When this method is used, the "last logon" for each mailbox is changed to the account that performed the migration. You can then begin to identify mailboxes that no longer seem to be in use (or at least are not logged into).
Often Exchange migrations are a great opportunity for consolidation as well. Be sure to take advantage of your ability to store additional mailboxes on the same server and the availability of multiple storage groups and databases (if you came from Exchange 5.5) for management of your user mailboxes.
Tip No. 9: Pilot Your Way to Success
If possible, try to set up a pilot before you deploy your migration to all users. This sounds like a simple thing—and it is. If you choose the right people, you can get support for the migration that might become invaluable. Some organizations prefer to first do an "all IT pilot." This is certainly a great idea because people in the IT department will likely be more able to deal with any small issues that arise as a result of the migration. I also recommend, however, that shortly after you're comfortable with the initial pilot, a second pilot be done with some "key" individuals. This could include your company CEO, vice president, or other executives. Doing so will get you not only the technical feedback you require about the new environment, but if done correctly you can get "buy in" on the process from some of the people at the top of the organization.
Tip No. 10: Document Everything
Finally, document everything. No migration would be complete without the proper documentation. Try your best to document both your existing environment and your proposed Exchange 2003 environment. When you've finished your migration, you should then do a review to ensure that you've met all of the requirements that you defined in your initial documentation. This not only helps you keep your focus, but it can serve as a valuable communication tool you can use to report progress to your manager. Proper documentation also will serve you well should you encounter any issues after the migration is complete.
Wrapping Up
Migration to Exchange 2003 doesn't have to be difficult. If done correctly, the transition should be seamless to your end users. Hopefully you'll find a few of these tips useful in your migration strategy, whether you're just getting started or are well on your way.