| Introduction In Part 1 of this article series, I discussed a server migration method that involved creating a network load balancing cluster between the old server and the new server, synchronizing the servers, and then breaking the cluster. Unfortunately, that method may be difficult, if not impossible, for some people to use because of hardware and software limitations. In this article, I'll show you other methods for migrating IIS to a new server. The Methods There are really two basic methods other than clustering that you can use to migrate your server. However, both of these methods tend to be a little messy. If you can use the clustering method, then you should do so. The alternative to building a cluster is to either use the backup/restore method or the ghosting method to move the IIS services and the corresponding Web sites. Unfortunately, there are some serious issues involved in using either method. In the sections that follow, I'll show you the basic tasks involved in using both of these methods and then go on to discuss some of the various problems that you may encounter when doing so.
The Backup/Restore Method As the name implies, the Backup/Restore method involves backing up the old server, and then restoring the configuration to the new server. There are as many ways to accomplish this task as there are backup programs. For the purposes of this article, I'll show you an overview of the process using the Windows 2000 Backup program. The first step in the process is to back up the old server. Begin by opening the Backup program that's found on the Start | Programs | Accessories | System Tools menu. When the Backup program starts, select the Backup tab, and then select all local disk partitions that contain any system files or anything related to IIS. You must also back up the System State. As you can see in Figure A, the System State contains several components. The actual components contained within the System State will vary depending on Server Configuration, but the System State usually contains elements that IIS is dependant on. 
Figure A
Once you've selected the elements which should be backed up, select the backup destination and click the Start Backup button. Be sure to use a storage media that's supported by the new server as well as the old server. One option is to back up the server to a file on the network. Before you'll be able to restore the backup to the new server, you'll have to load a minimal installation of Windows 2000 onto the new server. Otherwise, you won't be able to access the Backup program. Once you've backed up the server, you can restore the backup by opening the Backup program on the new server and selecting the Restore tab. Select the backup media that you just created, select the option to restore the files to their original location, and then click the Start Restore button.
The Ghost Method The other method to backup and restore the server configuration is Ghost. Ghost is a utility that comes with Symantec's Norton System Works. If you can get away with using Ghost, then doing so is often easier than using the Backup program. Ghost may be easier because you aren't required to install an operating system on the new server prior to restoring the ghosted image. This saves a lot of time. As you can see in Figure B, using Ghost is very simple. Ghost exists on a bootable floppy disk. Boot the disk to access the menu. Next, just tell Ghost whether you're ghosting a hard disk or a partition, or if you're restoring a disk or a partition from a ghosted image. 
Figure B
Although Ghost offers full NTFS support, there are a couple of reasons why you may not be able to use it. First, the old server must have a supported backup media. Generally, Ghost prefers to backup to CD. Unfortunately, many servers rely on SCSI based CD drives, which are unsupported by Ghost. Likewise, Ghost must be able to access data partitions on both the old and the new server. If these partitions exist on RAID arrays, then Ghost will be unable to access them. Generally speaking, GHOST works well if your server uses IDE hard drives and has an IDE CD-RW drive.
Issues That You May Encounter So far I've explained that the general procedure involves backing up (or ghosting) your old server and then restoring the backup or ghost image to the new server. While this sounds like a very simple procedure, there are some very serious issues that you may have to contend with while doing so. In the sections that follow, I'll discuss some of these issues with you.
Hardware Limitations One problem that you'll almost always encounter is that of different hardware. When you restore a full system backup or a ghosted image of a different server, you're restoring everything, including hardware drivers. Therefore, after the restore procedure, you're new server will think that it has the same hardware as your old server. Having incorrect drivers for things like video adapters, modems, network cards, sound cards, etc. can cause the server not to boot, or to crash shortly after boot. Even if the server doesn't crash, you may run into a situation in which an incompatible video driver prevents you from being able to read the screen. Enter Safe Mode. If you have these sort of problems after restoring the backup, then reboot your server into Safe Mode by pressing the F8 key repeatedly during the early phases of the reboot process until you see the boot menu. When the boot menu appears, select the Safe Mode command. When Windows boots into Safe Mode, it will be running in a special mode that uses a minimal set of Device Drivers. This is your chance to remove the old device drivers. Open the Control Panel and double click on the System icon. You'll see the System Properties sheet. Select the Hardware tab and click the Device Manager button. There should be a list of all of the hardware in the system. To change a device driver, right click on a hardware device and select the Properties command from the resulting context menu Now you'll see the device's properties sheet. Use the Uninstall or the Update Driver button on the properties sheet's Driver tab to make the necessary changes. When you're done, reboot the system and it should start normally.
IP Address Problems You'll also likely run into a whole set of problems related to IP addresses. After restoring a backup or a ghosted image, your new server now has the same IP address as your old server. As you're no doubt aware, you can't have two servers on the same network with identical IP addresses. Your first instinct may be to change the IP address of either the new server or of the old server. Eventually, you may decide to do that, but for the time being, changing either IP address would be a bad decision. Remember that your DNS server is directing Web traffic to the server's specific IP address. You don't want to change the IP address of your old server because it's still hosting Web traffic. You can't change the IP address of your new server because if you do, then the Web traffic will never be able to reach it. The best way to solve this problem is to make sure that the new server is disconnected from the network before booting it for the first time after the restore operation. Once the new server boots, verify that it does indeed have the same computer name and IP address as the old server. You may encounter some errors during boot up because the server can't contact any domain controllers. Ignore these errors for now; they should go away when the server is reconnected to the network. Once the server has booted, and isn't connected to the network, it's time to test IIS. The best way of doing this is to use the local copy of Internet Explorer to try to access your Web site. Remember that you won't be able to access the Web site by URL because you won't be able to contact the DNS server. Therefore, you'll have to access the site by computer name. If you enter the server's computer name into Internet Explorer, you should get Internet Explorer's default Web site. It could be, though, that your Web site isn't the default Web site. Therefore, you may have to specify a Web site name after the computer name. For example, in Figure C, you can see that I've got a Web site named test on a server named Bart. 
Figure 3
If I enter http://bart/test into Internet Explorer, I can access the site, as shown in Figure D. 
Figure D
If you have trouble accessing your Web site, verify that the Internet Information Services are running, and that Internet Explorer isn't configured to use a Proxy server. You might also try replacing the computer name with the computer's IP address in Internet Explorer (although the computer name usually works best). Only after you've thoroughly tested your Web site in this manner should you consider taking your old server offline and replacing it with your new server.
User Account Problems Most of the time, you shouldn't have too many problems with computer accounts. Normally, a Web server is simply a member server within a domain, and therefore gets its account information from elsewhere in the organization. This may throw some kinks into your testing though. Remember that the new server is disconnected from the network. This means that if it relies on account information from a domain controller that all authentications will fail (other than anonymous access) because the domain controller is inaccessible.
Age Of The Backup One last potential problem that you need to be aware of is the age of your backup. Even if your Web site is completely static, your backup's age is a bigger factor than you might realize. One reason that the age is important is that if the server that you backed up happens to be a Windows 2000 domain controller, then the System State portion of the backup is considered invalid after 60 days. You probably aren't going to make a backup and then wait 60 days to restore it. However, there are other time factors involved. In Windows 2000, each computer uses an account name and a password to authenticate into the system. This account name and password is different from the user name and password used by users and is completely transparent to users. The computer account's password automatically changes from time to time (although I have been able to find no documentation telling how often). If the computer password changes between the time that you make the backup and the time that you connect the new computer to the network, then the new server will be unable to authenticate into the Active Directory. If this happens to you, then you'll have to use the NETDOM utility to reset the computer account's password. The procedure for this is to long to print here, but you can get the procedure from the Microsoft knowledge base by searching on NETDOM. You can access the Knowledge Base at http://support.microsoft.com. As you can see, migrating an IIS Server to new hardware is a lot of work. If you can use the clustering method that I showed you in Part 1, then the process will likely be considerably easier.
About the Author Brien Posey is the executive vice president of research at Relevant Technologies, Inc. Brien is an MCSE and a renowned technology journalist. He was recently voted the most popular server author on CNET's TechProGuild portal. Brien can be reached at brien@brienposey.com. Due to the high volume of messages that he receives, it's impossible for him to respond to all of them, although Brien does read them all.
|
