|
Introduction
If your company's Web site is growing in popularity, you may soon find that your existing server hardware is inadequate to handle the demand. When this happens, you've got a choice to make -- either upgrade the server, migrate the Web site to completely new hardware, or cluster the server. In this article, I'll take a look at the process of moving IIS to a completely different server.
An Overview of the Process
Before I get started with a hands-on approach to the problem, I'd like to take a moment and look at what's going to be involved in the process. First of all, obviously the Web site must be moved to the new hardware. This means more than just copying the files that make up the Web site, though. Consider things like file permissions, and more.
Also, consider your user accounts. Unless the Web site relies totally on anonymous user access, make sure all of the user accounts are accessible to the new server after the move and that they have retained their permissions.
There are two basic approaches that to accomplish this task. One involves backing the server up and restoring the backup to the new server. The other method involves creating a cluster. The cluster would consist of the old server and the new server. Once you've replicated the Web site to the new server, you'd remove the old server and be done with the job.
Using the cluster method is the preferred technique since the Web server won't have to be down for an extended period of time. However, no matter which method is used, I recommend reading this article in its entirety first because there are many different variables that can cause one method or the other not to work properly.
A Word about Domain Controllers
Regardless of which migration method is used, the first step is to check to see if your present IIS server is a domain controller. If the server is a domain controller, then check to see which domain it belongs to and if there are other domain controllers in the domain.
Having an IIS server acting as a domain controller adds an unnecessary level of complexity to the task of moving the server. If the server is a domain controller and other domain controllers exist in the domain, then use the DCPROMO command to demote the server to a member server before beginning the move process. If you really need the server to function as a domain controller, you can always promote the new server to domain controller status at a later time.
If the server is the only domain controller in the domain, then try loading Windows 2000 Server onto a spare PC and promoting the spare PC to domain controller status. After the two domain controllers have had time to replicate with each other, you may demote the IIS server to a member server using the DCPROMO command. After moving IIS to the new box, you can use the DCPROMO command to restore it to its domain controller status. You'd then use DCPROMO to demote your temporary domain controller to member server status and then remove the temporary server from the domain.
The Clustering Method
Again, the clustering method is the preferred method since it doesn't require you to take the IIS server offline for any extended period of time. It also doesn't involve any complex backup/restore issues, and most importantly, it gives you a chance to test the new server before permanently shutting down the old server.
The clustering method doesn't involve creating a cluster in the sense that two servers are sharing a common hard disk. Instead, this method relies on network load balancing. The network load-balancing model involves setting up two or more servers to host a common Web site. After you're sure that the Web site is being hosted correctly by both servers, you can remove your original server from the cluster. This accomplishes two tasks. First, it allows you to move the Web site without making it unavailable. Second, it lays the groundwork for future growth. If down the roadthe new server is inadequate for the traffic that your Web site is receiving, you can add more servers to the already existing cluster to distribute the workload. With that said, let's take a look at the setup procedure.
Begin the process by installing another network card into both your old and new server. These new network cards will be used to carry load-balancing-related traffic. The two machines should be connected to each other through the new network cards via a crossover cable or a dedicated hub.
Next, start the configuration process by performing the following steps on your existing IIS server. (It's extremely important that the steps are performed in the exact order that I've listed here. Otherwise, you could cause some rather serious problems.) Start by opening the Control Panel and double clicking on the Network and Dial Up Connections icon. When the Network and Dial Up Connections window opens, right click on the network connection that network load balancing will be applied to and select the Properties command from the resulting context menu. When you do, you'll see the connection's properties sheet. The connection's properties sheet contains a list of the components that are installed. Network Load Balancing appears on the list, but does not contain a check mark in its check box. This indicates that the feature is installed but is inactive.
At this point, select the Network Load Balancing check box and the click the Properties button to access the Network Load Balancing properties sheet. On the Network Load Balancing properties sheet, enter the Primary IP address in the space provided. The Primary IP address is a virtual IP address that will be used by each server in the cluster. After filling in the primary IP address, the subnet mask should be filled in automatically.
Figure A
Next, enter the full Internet name in the space provided. The full Internet name should correspond to the DNS name for your server's Web site. If you use multiple Web sites on the server, then enter the full Internet name of the default Web site. The full Internet name is a name that will be shared by all servers in the cluster and is used as a way of addressing the cluster as a whole.
Because you are using two network cards, go ahead and select the Enabled check box in the multicast support section. While you're at it, select the Enabled check box under the Remote Control section, and then enter and confirm a remote control password.
Once you've completed this step, the Cluster Parameters tab should resemble the one that's shown in Figure A. Everything on this tab should be identical for both your old and your new server, so go ahead and update your new server to reflect the entries just made on the old server.
Now, it's time to move on to the Host Parameters tab (see Figure B). The first thing on this tab is the Priority (Unique host ID). This option tells Windows how likely the server should be to pick up the slack if another server in the cluster goes down. For the purposes of this article, just set your old server to a priority of 1 and the new server to a priority of 2.
Figure B
The next parameter to configure is the Initial Cluster State. By default, the initial cluster state is set to Active, meaning that the cluster will become active as soon as the server boots. Leave this value set to Active.
Finally, you must enter the dedicated IP address. This value must be a static IP address that you can use to address the new network card. You can't use an address that's been assigned by a DHCP server. This address must be unique for each server in the cluster and must not be equal to the cluster's primary IP address or to any IP address that might be assigned to the server's other network card. Once you've filled in the Host Parameters tab on your old server, go ahead and fill it in on the new server.
Normally, at this point, you'd configure the Port Rules tab to establish how much priority is given to each host in the cluster. However, this is irrelevant since we're using the cluster as a migration tool.
At this point, switch back to your old server and click OK twice to return to the Network and Dial Up Connections window. Now, right click on the connection that you've just configured network load balancing on and select the Properties command from the resulting context menu, to reopen the connection's properties sheet. Select Internet Protocol (TCP/IP) from the list of components and click the Properties button. When you do, you'll see the Internet Protocol (TCP/IP) Properties sheet. Select the Use The Following IP Address radio button, and then fill in the server's unique IP address for that network card. Next, click the Advanced button to access the Advanced TCP/IP Settings properties sheet. Click the Add button to access the TCP/IP Address dialog box. Enter the cluster's IP address and subnet mask, and click the Add button. Click OK three times to close the various dialog boxes. If you receive an error message stating that you haven't specified a Windows Internet Naming Service (WINS) server, just ignore it. Now, repeat this process for the other server.
Synchronizing the Two Servers
Now that the cluster is all set up, it's time to synchronize the new server with the old server. To do so, you'll have to use the IISSYNC command. Before you can use this command, you must do a little prep work.
The first thing to do is to verify which user accounts that IIS is configured to use as a system account. Hopefully, neither server is a domain controller, but both are members of a common domain. To verify which IIS accounts are in use, open the Internet Service Manager on both servers. Next, select the default Web site (or the site being migrated), right click on the Web site, and then select the Properties command from the resulting context menu to reveal the Web site's properties sheet. When the Web site's properties sheet opens, select the Directory Security tab.
On the Directory Security tab, click the Edit button in the Anonymous Access and Authentication Control section. If anonymous access isn't already enabled, enable it and then click the Edit button. Hopefully, a user account named IUSR_servername exists. If such an account exists, select it and enter the account's password in the space provided. If the account doesn't exist, then create an account with such a name, along with an account named IWAM_servername. For example, if your server is named BART, then the user names would be IUSR_BART and IWAM_BART. Make sure that both accounts are domain users and have the Log On Locally permission.
Now, open a command prompt window on your old machine and enter the following commands:
C: (Where C: is the drive letter containing Windows 2000)
CD\INETPUB\ADMINSCRIPTS
CSCRIPT ADSUTIL.VBS SET W3SVC/WAMUserName domain\IWAM_servername
CSCRIPT ADSUTIL.VBS SET WS3SVC/WAMUserPass "password"
You can see a sample of these commands being issued in Figure C.
Figure C
Finally, on the old computer, enter the following commands at the command prompt:
C:
CD\WINNT\SYSTEM32\INETSRV
IISSYNC new_server_name
What Went Wrong?
Hopefully, IISSYNC was successful. If so, it will return an error code 0. Upon completion, the metabase of both servers will be synchronized. If you find that the synchronization has failed, then check out article number Q224801 in the Microsoft Knowledge Base. It provides the meanings to the various error codes that you might encounter.
When I attempted this procedure in my lab, I received an undocumented error. The error number was 2147803151. The message indicated that COM+ was able to talk to the distributed transaction coordinator. If you receive this error, you can fix the problem by navigating to the %SystemRoot%\System32 folder on both machines and running the DTCSETUP.EXE program. If either server is running an older version of SQL Server, check to make sure that the file is art least version 1999.9.3422.24 or newer. There's a problem with older versions of this file, and if you have an older version, you'll need to copy the file from another Windows 2000 Server or off of the installation CD before running it. After the file completes, start the Distributed Transaction Coordinator service on both machines and then try synchronizing the machines again.
Conclusion
Now that you know how to build and synchronize a cluster, it's time to configure your new server to service your company's Web site on its own. I'll discuss how you can do this in Part 2. I'll also show you an alternative method of migrating servers.
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.
|
