As your organization grows, it’s only a matter of time before you outgrow some of your servers. When the time comes, the Million Dollar question is, “What’s the best way to migrate everything off of the old server and onto a new server?” I’ve been working with Windows NT and Windows 2000 for a long time, and I’ve yet to see a single migration go perfectly. It’s amazing the problems that can occur when migrating servers. I’ve seen everything from problems with long file names not being copied correctly to permissions problems to servers that won’t even boot. In this Daily Drill Down, I’ll discuss some of the issues that you’ll face when preparing for such a migration. I’ll then go on to explain two time-tested migration techniques.
Preparing for the migration
The key to making a migration go smoothly is thorough planning. If you take the time to closely examine the system that you’re migrating and to anticipate any possible problems, then your chances of having a smooth migration are much better. In the sections below are several pre-migration techniques that I’ve adopted over the years. You’ll need to deal with the following major components of your server:
- Hard drive partitions
- Computer identification
- Hardware issues
- Virtual memory
- Domain preparation
Hard drive partitions
Begin the process by looking at the current size of each of your old machine’s partitions and how much data exists on each partition. You’ll need to know this because you’ll have to create a similar partition structure on your new machine. If a partition on your old machine was close to full, you can make a partition substantially larger on the new machine, as long as you have enough hard disk space.
As you’re planning your new machine’s partition structure, be sure to make a note of what file system your old machine uses. You can change file systems later, but initially you must use the same file system as the old machine.
The next step is to see which applications are loaded on the server. Don’t just look at the Start menu options or desktop icons because they might not accurately reflect what’s actually on the machine. The best way to figure out what applications are installed is to look through the hard disk. Pay especially close attention to the Program Files folder. As you locate applications, I recommend testing them to see if they work. Believe me, it’s very frustrating to migrate an application that wasn’t working to begin with and then think that the application is failing as a result of a migration problem.
As you compile a list of functional applications, I recommend locating the installation media and any service packs for the applications. Depending on which installation method you use, you may have to manually reinstall the applications later on. It’s no fun to be at the end of a long migration and realize that a malfunctioning application is the only thing standing between you and getting to go home, and you can’t find the application CD.
After you’ve checked the application software on the server, make note of the computer’s identification. Record things like the computer’s name, what domain the computer is attached to, and its IP address (if you use static addresses). If the server contains multiple NICs, remember that there may be multiple IP addresses, and it’s important to take note of all of them.
Next, you should check the old computer’s hardware. Most of the time a hardware check is irrelevant because you’ll be replacing the hardware. However, sometimes you’ll find that the old computer has some special hardware installed that an application simply can’t work without. For example, maybe the old server has a modem and the new one doesn’t.
I’ve also seen situations in which a legacy application required a hardware component such as a dongle or a security card, and the old hardware was completely incompatible with the new server. These are the kinds of things that you really need to know about before you get too far into a migration.
Disable virtual memory
Now that you’re done playing detective, the next step is to disable the machine’s virtual memory. During the course of normal operations, the virtual memory should always be enabled. However, enabling the virtual memory creates a swap file on the hard disk that can be hundreds of megabytes in size. Disabling the virtual memory can greatly expedite the copy process.
The technique for disabling the virtual memory differs among operating systems. In Windows 2000, you can disable the virtual memory by opening the Control Panel and double-clicking the System icon. When the System Properties sheet appears, select the Advanced tab and click the Performance Options button, followed by the Change button. Now, select the drive that presently contains the paging file and set both the minimum and maximum file size to zero. Next, click the Set button, followed by the OK button.
When Windows asks you to reboot the computer, do so. When Windows boots, erase the PAGEFILE.SYS file from the root directory. The technique for disabling a Windows NT pagefile is very similar and also involves using the Control Panel’s System icon.
After disabling the server’s virtual memory, what you do next depends on the operating system. If you’re running Windows 2000 or a copy of Windows NT with Diskeeper, I recommend performing a full defragmentation. This will help to optimize the migration process and will also help you to spot any hard disk problems before beginning the migration.
If the server that you’re removing happens to be the only domain controller in the entire domain, you can save yourself a lot of trouble by installing Windows 2000 Server or Windows NT Server on an old PC and making it a domain controller for the domain that’s being worked on.
Once you’ve done this, promote the spare machine to Primary Domain Controller (PDC) prior to removing your other computer from the domain, and be sure to give the SAM or the Active Directory time to replicate. While you’re switching PCs, the temporary PDC will maintain the SAM. When the operation is over with, you can always make the new machine a domain controller by using the DCPROMO command. You may then remove the temporary domain controller from the domain.
Migrating to the new hardware
After you’ve finished the preparations, you’re ready to begin the move. There are two different methods that I commonly use. Both methods work, but depending on the actual environment that you’re working in, one method usually works out better than the other. As I show you the two methods, I’ll guide you as to when each method is appropriate.
Migration method number one: Back up and restore
The first method involves backing up all of the data on the server. Once you’ve backed up all of the data, shut down the server. Now, from a different server, use either the Windows NT Server Manager tool or the Windows 2000 Active Directory Users and Computers tool to remove the server from the domain.
After the change has had time to replicate, install Windows NT or Windows 2000 onto the new server (whichever operating system the old server used). Assign the new server the same IP address and computer name that your old server had. The server will be assigned a new GUID, but it will have no problem using the old server name and IP address since you’ve removed the old server from the network. Once Windows is up and running, use the DCPROMO command to make the server a domain controller (if your old server was a domain controller).
Now it’s time to recreate the old server’s partition structure and restore your backup. The backup files will normally have security that’s based on domain users rather than local users, so restoring the files and keeping the permissions shouldn’t be a problem. All that’s left is reinstalling any applications and fixing any minor access problems that might have occurred.
This technique works well in situations in which the old server isn’t very complicated, such as would be the case with a file or print server. One of the best things about using this technique is that it involves a completely fresh installation of Windows and of your applications. Therefore, you don’t have all of the junk files that are commonly associated with old servers taking up space on your new hardware.
As long as you heed my warnings regarding domain controllers in the section above, this technique will work in single domain controller environments. However, if the server that you’re moving is not the only domain controller in the domain, then I strongly recommend using the technique below if at all possible.
Migration method number two: Parallel migration
The second migration technique is a bit more complex, but it works well in single domain controller environments as well as more complex servers, such as application servers (Exchange, SQL, etc.) or database servers. This technique is more time consuming and doesn’t clean up the new server the way that my other technique does, but it results in fewer problems for complex environments.
This technique has two advantages over the previous method. First, your old server remains untouched. This means that if something goes wrong during the upgrade, you still have the original machine to fall back on until you have time to try the upgrade again. Second, the new machine will inherit the old machine’s GUID, so there are no complexities involved because of a GUID change.
For this technique, begin by installing Windows NT 4.0 Server or Windows 2000 Server on the new server. Don’t worry about Service Packs or applications—just install the basic operating system. I also recommend that you use a temporary computer name and a temporary IP address.
Once you’ve installed Windows, create a partition scheme so that there’s a partition that corresponds to each partition on your old server. Each partition must be at least as large as its counterpart on the old server. After you’ve created the partition structure, format each partition with the same file system that was in use on the old server. Then use a utility such as Symantec’s Ghost or Winternals Software’s Remote Recover to copy all of the files from the old system to the new system. As you copy the files, you should direct files to the partition that matches the partition on which the files were previously installed.
During the restore process, you should overwrite all files. Remember that the files that are presently on your new server are old system files without any service pack. Therefore, the files on the old server are newer than the files presently on the new server.
Once all of the files have been copied, the new server will likely be unbootable because of differences in the hardware abstraction layer (HAL) between the two machines. To fix this problem, you must install Windows NT or Windows 2000 from the CD on top of the existing copy. When doing so, Setup will detect the new system’s hardware and replace the current HAL with one that matches the new system’s hardware, while preserving everything else.
The thing that you must keep in mind is that prior to reinstalling the operating system, the unbootable server has the latest service pack installed on it. This means that when you reinstall Windows, you’ll be presented with countless cases in which a newer file is about to be overwritten by an older file. If you’re installing Windows 2000, I recommend not overwriting the newer files. Windows should boot correctly after the installation (even if only in Safe Mode). You can then reinstall the appropriate service pack, and the server should become functional.
If you’re working with Windows NT, I recommend overwriting all newer files with old files. If you don’t overwrite the newer files—including drivers—then there’s a really good chance that your server will become unbootable. After the installation, Windows NT will be running an old service pack or no service pack at all, depending on your installation media. Therefore, you must install the latest service pack to get the system up to par.
After the migration
Regardless of which method you use, be sure that you only upgrade one server at a time. There are issues that will be unique to your environment that I can’t possibly predict. You can make the upgrade process much easier if you do one server first and use that as a learning experience before upgrading other servers. Besides, doing more than one server at a time can cause serious consistency problems with your domain controllers.
After you’ve migrated, I also recommend verifying that virtual memory is enabled on the new machine. You should also spot-check the system for potential security problems before opening the machine up to users.