So, you decided to migrate from Exchange 5.5 to Exchange 2000, but during the process, something went horribly wrong. According to countless articles on the Web, the migration procedure is plagued with problems. In this Daily Drill Down, I’ll help you to figure out what happened.
Preparing for the migration
If you’ve already begun the migration process, you can skip this section. However, if you’re contemplating a migration and are just reading this article to see what could go wrong, then read this section carefully.
As I mentioned, the Exchange 2000 migration process is prone to failure, and a lot can go wrong. Unfortunately, what actually does go wrong depends on your own individual Exchange 5.5 configuration. There’s no way for me to be able to tell you specifically what will go wrong in your organization. The only way to get a clue is to set up a test server.
I recommend installing Exchange 5.5 on a spare computer and configuring it to use a copy of your production databases (make sure this server isn’t connected to the network). By doing so, you can attempt a migration without putting your real server at risk. Through this test migration, you can get a feel for what, if anything, you may have problems with when you do the real migration. You can get the kinks worked out before migrating the real server. Of course, there’s a chance that nothing will go wrong. I’ve personally migrated several Exchange 5.5 servers to Exchange 2000 without any major problems. However, I’ve heard all kinds of migration horror stories from my peers. The point is that you never know how a migration will work until you actually do it.
Things to watch for
Right now, your biggest question may be: What types of problems should I anticipate? From everything that I’ve seen and read, the migration process itself is fairly smooth. However, the Exchange 2000 Migration wizard tends to be really picky. There are a million housekeeping chores that you must complete before the Migration wizard will even allow you to migrate the server.
During the migration, you can just sit back and relax. The process takes a while, and I haven’t heard any reports of the Migration wizard crashing half way through a migration. The problems usually start after the migration is complete. Most of these problems will be subtle. Don’t get me wrong; they can be big problems, but they are things that you may not initially notice. This is why it’s so important to thoroughly test Exchange 2000 on a test server before rolling it out to your entire organization.
Running test migrations
During the test migration, be sure to take lots of notes. You’ll want to make notes of all of the things that you had to do to prepare for the migration and the steps that you followed through the Migration wizard. Just as important, but often overlooked, you need to keep track of how much time that the various phases of the migration process take. By doing so, you can make a schedule for the night of the real migration.
By knowing how long the migration process will take, you know how much time you’ll have for testing and repairs. When the test migration is complete, be sure to take note of any problems that you encountered and the steps you took to correct them. When it’s time for the real migration, you can save time by testing the items that you previously found to be problems before testing anything else. It’s easy to say, “Make sure to test the server thoroughly.” However, Exchange is a complicated product. It’s easy to miss something during the testing.
The real migration
When it comes time to do the real migration, you should already have a good idea of what to expect. There are a few things that you should plan for, though. First, remember that the migration process permanently alters your Exchange server’s databases. Therefore, no matter how well the test migration might have gone, it’s extremely important to make a full system backup of each Exchange server before attempting an upgrade. If something goes wrong, restoring a backup is often the only way to return your server to a functional state.
Another tip that I’ve learned over the years is that Exchange migrations can be slow, but the process of repairing a failed migration can be even slower. Therefore, you’ll need to make the best possible use of your time when doing the migration. I did most of my Exchange-related work for the U.S. Army. Obviously, the Army operates 24 hours a day, seven days a week. This meant that I had to schedule upgrades ahead of time. Usually, I was granted permission to do the upgrade on a weeknight and had from 5:00 P.M. to 6:00 A.M. to get the job done. In such a situation, if everything goes well, you might be able to go home by 10:00 P.M., but don’t count on it.
Remember that in the situation that I just described, there will be people showing up for work in 13 hours. Those people will expect the Exchange server to be functioning when they arrive. Therefore, to make the best possible use of your time, I recommend running the full system backup during the workday. If you end up having to restore this backup, you might lose a few messages that were sent later in the day, but the backup will still be newer than the one made the night before. With the backup complete, you can start the upgrade promptly at the scheduled time.
When the upgrade is complete, you can begin testing the Exchange 2000 server and try to correct anything that isn’t quite right. You need to set a deadline for testing, though. For example, if the backup takes four hours to restore and everyone shows up for work at 6:00 A.M., then you need to make a decision as to whether the Exchange 2000 server is getting the job done, or you need to restore your backup no later than 1:30 A.M. That way, you can have a functional Exchange server online when everyone shows up for work. It’s a terrible feeling to have to restore your backup in the middle of the night and lose all of the hard work that you’ve put into the upgrade. However, it’s an even worse feeling to get yelled at because something doesn’t work after having been up all night.
Problems you may encounter
In the sections that follow, I’ve compiled some information about a few of the more frequent problems with Exchange 2000 migrations. The list is by no means exhaustive, but it should be enough to get you thinking about things to look for.
One of the biggest problems with Exchange 2000 migrations is typically with connectors. For example, the Internet Mail Connector (or SMTP Connector as it’s called in Exchange 2000) may not work after the migration. Once the migration completes, you’ll need to make sure that the migrated server can still communicate with all other Exchange servers in the organization, including those at different sites. It’s also important to make sure that Internet mail traffic still flows. If you find a problem with any of the types of communications that I’ve just described, the easiest way to fix the problem is usually to delete the connector and reestablish it.
Be sure to write down the settings from the old connector before deleting it, though. You should also keep in mind that some types of connectors require a connector on both of the servers that they service. Therefore, if you’re dealing with a connector type that has to work in pairs, be sure both connectors are present and functioning.
The second biggest issue you might face is that of distribution lists. Exchange 2000 doesn’t use distribution lists. Instead, it uses mail-enabled groups. A mail-enabled group is nothing more than a Windows 2000 group that’s been associated with an e-mail account.
When you migrate from Exchange 5.5 to Exchange 2000, the distribution lists aren’t migrated. The reason for this is many organizations already have Windows 2000 groups that parallel the Exchange distribution lists. Therefore, all you’ll have to do is mail-enable these groups or create new groups that mirror your distribution lists. Fortunately, if you do have to create new groups, you can do so before the migration ever takes place. You just won’t be able to mail-enable the groups until after Exchange 2000 is installed.
To mail-enable a group, open Active Directory Users And Computers and navigate through the console tree to the Users container. Select the group that you want to mail-enable and right-click it. Next, select the Exchange Tasks command from the resulting context menu. When you do, Windows will launch the Exchange Tasks wizard. Work your way through the wizard and establish an e-mail address for the group.
Another potential problem is that of public folders. Although not common, I’ve heard horror stories about public folders becoming rehomed or losing their security permissions during a replication. If you have a really large collection of public folders, it can be difficult—if not impossible—to check all of them in one night. Therefore, I recommend performing a spot check.
Begin by glancing over the list of public folders to make sure that all of the folders still exist. Next, pick some folders at random. With these folders, make sure that their contents still exist, that they are still homed on the correct server, and that the security permissions appear to be correct. If all of this checks out, the next step is to test public folder replication. Select a public folder that is replicated to another server and post a test message. Wait a few minutes and make sure the test message eventually shows up on the other server.
If replication doesn’t appear to be working, then the obvious starting point is to double-check your connectors and the replication schedule. If these things check out, then check the date, time, and time zone on all of your Exchange servers. If any of these values are too far off, replication won’t work.
One last thing that needs to be checked is custom applications. Many organizations develop custom applications based on Exchange messaging, the Exchange address books, calendars, etc. Because of differences in the way Exchange 5.5 and Exchange 2000 function at the system level, it’s possible that custom applications may not run under Exchange 2000. If this is the case, you will need to give your development staff time to code the application for Exchange 2000 before migrating the real server.
If you do experience problems with a custom application, don’t immediately assume that the application won’t run under Exchange 2000. Check any permissions that might apply to the application, especially if the application relies on the Exchange service account.
To sum it up, plan for the Exchange 2000 migration by working out the kinks on a test server. When it comes time for the real migration, make sure that you have a backup of your entire server and a contingency plan. In other words, hope for the best, but plan for the worst. When it comes to migrating Exchange 5.5 to Exchange 2000, there’s a lot that can go wrong. Knowing what can go wrong and how to recover from it can save you lots of headaches if and when problems occur. I hope I have helped you to figure out some things that might have gone wrong in your migration.