Installing the Windows NT Option Pack on MS Cluster Server (MSCS)

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: October 27, 1999

By Robert J. Hensing and John White

Microsoft® Windows NT® 4.0 Option Pack

Microsoft Product Support Services White Paper

Abstract

This white paper outlines the steps necessary to set up a new cluster for use with the Windows NT Option Pack (NTOP). The white paper also provides you with instructions on how to install the Windows NT Option Pack on your cluster. Failure to install the programs in the order described in this white paper may cause the Windows NT Option Pack to fail upon installation.

Additionally, the white paper details co-existence strategies between the Windows NT Option Pack and Microsoft SQL Server. More information on overcoming issues the Windows NT Option Pack experiences with certain versions of the Microsoft Distributed Transaction Coordinator (MSDTC) service are provided in the Appendix.

On This Page

How to Install the Windows NT Option Pack on Microsoft Cluster Server (MSCS)
Installing the Windows NT Option Pack on a Microsoft Cluster
Appendix: Installing Windows NT Option Pack on a Cluster
For More Information

How to Install the Windows NT Option Pack on Microsoft Cluster Server (MSCS)

What You Will Learn

  • How to install the Windows NT Option Pack on a cluster

  • What availability models are available for Windows NT Option Pack on Microsoft Cluster Server (MSCS)

  • Required installation order for a successful installation of the Windows NT Option Pack

  • Common problems that prevent a successful installation of the Windows NT Option Pack on a cluster

  • How to create and configure a clustered Web site

  • Best practices for Internet Information Server (IIS) administration on a cluster

Related Topics Covered in this Document

  • SQL Server planning considerations

  • Impact of Windows NT and SQL Server service packs

  • How to manage and replicate your Web content

Recommended Reading

  • 191138 - How to Install Windows NT Option Pack on Microsoft Cluster Server (in Microsoft TechNet)

  • 223258 - How to Install the Windows NT Option Pack on MSCS 1.0 with SQL Server 6.5 or 7.0 (in Microsoft TechNet)

  • 223259 - How To Install FTP from the NTOP on Microsoft Cluster Server 1.0 (in Microsoft TechNet)

  • 218922 - Installing NTOP on Cluster Server with SP4 Causes Event IDs 1009 and 1058 (in Microsoft TechNet)

  • 223397 - Event Log Error 3221229574 from Service Control Manager (in Microsoft TechNet)

  • MS Cluster Server manual

Required Installation Order for Proper Installation of the Windows NT Option Pack

Use the following steps to ensure the proper installation of the Windows NT Option Pack:

  1. Windows NT 4.0 Enterprise Edition.

    Do not install Internet Information Server (IIS) 3.0 during the Windows NT Setup. The remainder of this white paper assumes that IIS 3.0 was not installed prior to running the Windows NT Option Pack setup.

  2. Windows NT 4.0 Service Pack 3 or later.

  3. Microsoft Cluster Server (MSCS).

  4. Microsoft Internet Explorer 4.01 or later.

  5. Windows NT 4.0 Option Pack.

  6. Windows NT Service Pack 4 or later.

If you are running SQL Server 6.5 Service Pack 5a or SQL Server 7.0 on your cluster or if you have applied Windows NT Service Pack 4 or later to any of your cluster nodes, and if you have a Microsoft Distributed Transaction Coordinator (MSDTC) service listed under Services in Control Panel, refer to the following article in the Microsoft Knowledge Base for installation instructions:

223258 - How to Install the NTOP on MSCS 1.0 with SQL Server 6.5 or 7.0 (in Microsoft TechNet)

Conflicting Services

Make sure all of the following services are stopped on the computer before installing the Windows NT Option Pack:

  • Any third-party disk quota software

  • Disk Keeper

  • ARCServe, Backup Exec, or any other backup service

  • Any third party anti-virus software

  • Compaq Insight Manager / Agent

  • Performance Monitor

Installing the Windows NT Option Pack on a Microsoft Cluster

This section discusses the installation of the Windows NT Option Pack on a cluster.

Availability Models

Before you install the Windows NT Option Pack on a cluster, it is important to think about what you are trying to accomplish by installing the Windows NT Option Pack on a cluster.

Microsoft Cluster Server has many availability models that applications can use for different availability scenarios.

  • Model A: High-availability solution with static load balancing (active/active)

  • Model B: Hot spare solution with maximum availability (active/passive)

  • Model C: Partial cluster server solution

  • Model D: Virtual-server-only solution (no failover)

  • Model E: Hybrid solution

The Windows NT Option Pack is only supported on Model B. If you are trying to use Model A, consider the Windows Load Balancing Service (WLBS). This is a free download for customers who hold a Windows NT Enterprise Edition License. WLBS can load balance up to 32 IIS nodes in a cluster and is ideal for dynamic load balancing of Internet information services. More information on this product can be found at:

https://www.microsoft.com/technet/archive/winntas/maintain/wlbswp.mspx or Microsoft TechNet.

Please note that many additional components in the Option pack that function properly in a single server IIS 4.0 installation will not function properly in a clustered IIS environment. Index Server, Certificate Server, FrontPage ®, Search Bots, Outlook ® Web Access, Site Server 3.0, and Commerce Server are a few examples of Internet products that will not operate properly if they are installed onto an IIS/MSCS server.

Third-party products should also be checked for MSCS compatibility prior to installation as well.

Model B: Hot Spare Solution with Maximum Availability (Active/Passive)

Model B: Provides maximum availability and performance, but both nodes are never fully used. One node of the cluster makes all the resources available, while the other node is idle and waiting in case of a failover.

In this model, the idle node is a dedicated "hot spare", ready to be used if a failover occurs. If the node making the resources available fails, the hot spare node causes the resources to fail over to it, and then makes the resources available with a performance level comparable to that of the original node. The performance level depends on whether or not the hot spare node has the same specifications, such as CPU speed, as the original node.

ntopcl01

When using the model as illustrated here, the following network names and Internet Protocol (IP) addresses will be in use:

  • A computer name and IP address for Node A

  • A computer name and IP address for Node B

  • A network name and IP address for the cluster

  • A network name and IP address for the Web Services group

Considerations for Choosing This Model

This model is best suited for the most critical applications and resources. For example, an organization that has a server on the World Wide Web where customers place orders may want to use this model. The expense of a second idle server can be justified by guaranteeing continuous high performance access to the organization's store on the Web.

Server Availability

Very high.

Suggested Failover Policy

The failover policy for this model depends on node capacity. If the hot spare node has the same specifications and can provide identical performance, a failover policy does not have to be configured. If one node provides higher performance, the failover policy should be configured to fail back to the higher performance node.

Why Is only Model B (Active/Passive) Supported with NTOP?

The Windows NT Option Pack cannot be installed in an Active/Active configuration. Unlike some other BackOffice products, multiple copies of the IIS Admin, World Wide Web Publishing, and FTP services cannot be configured to run simultaneously on the same node at the same time. For example, SQL Server 6.5 can be configured in an Active/Active configuration (Model A) such that multiple copies of the SQL Executive service and SQL Server services exist in the Services Manager on each node "SQL Executive 1" service, "SQL Executive 2" service, and so forth), with each copy of the service pointing to its own installation of SQL Server on different drives or in different directories on the same drive. With the Windows NT Option Pack, this is not possible. SQL Server stores the majority of its configuration information in a database, which is stored in the SQL installation directory and can be configured by the user during SQL Server Setup. IIS stores its configuration information in a file named Metabase.bin, which is stored in the %Windir%\System32\Inetsrv directory. This location is not configurable. Because IIS stores all of its configuration information in one file and there can be only one copy of that file per node, IIS cannot have multiple independent service instances configured to run on each node pointing to different copies of Metabase.bin, and thus cannot be made to work in a truly Active/Active configuration in a Microsoft Cluster environment.

When Web sites, virtual directories and applications are created in IIS, these settings are stored both in the local copy of the Metabase.bin and in the local registry on each node.

Because IIS settings, sites, and virtual directories are all maintained locally on both nodes of the cluster in two different local copies of Metabase.bin and in the local registries, rather than being shared between the two nodes on the shared drive, it is necessary to have a utility that can synchronize the two disparate copies of Metabase.bin and the registries with each other on both nodes so that all IIS Web sites and virtual directories are identical on both nodes. The utility provided with the Windows NT Option Pack that can synchronize the metabase and Microsoft Transaction Server (MTS) registry settings on both nodes is named IISsync.exe, and it will be discussed in detail later in this white paper.

MSDTC Version Conflicts with Windows NT Option Pack Setup

Microsoft Distributed Transaction Coordinator (MSDTC) is required for Microsoft Transaction Server (MTS) to function properly. MTS is required for IIS 4.0 to function properly, and IIS will not function properly unless both of these components (MSDTC and MTS) are functioning properly. Certain Microsoft products update older copies of MSDTC when they are installed automatically. For example, Windows NT 4.0 Service Pack 4 or later, SQL 6.5 Service Pack 5a, and SQL 7.0 will all upgrade existing MSDTC 1.0 components to newer MSDTC 2.0 versions. Between versions 1.0 and 2.0 of MSDTC, the command-line syntax for MSDTC.exe changed. The Windows NT Option Pack setup expects only MSDTC 1.0 components to be installed on the hard disk drive and, as a result uses MSDTC 1.0 syntax, which is no longer valid syntax for MSDTC 2.0. This condition causes the MSDTC JOIN command to fail on the second node if the newer MSDTC files are not removed prior to setup. This failure causes numerous errors during setup and the eventual failure of the Windows NT Option Pack setup to complete successfully.

The Windows NT Option Pack setup for a cluster requires that setup is run on both of the nodes in the cluster. Setup must first complete on one node before setup on the second node begins. The first node on which setup is run, for the purposes of this white paper, will be called Node A. The second node of the cluster on which setup is run will be called Node B. The designation of Node A and Node B is arbitrary as long as they are used consistently throughout this white paper.

To successfully install the Windows NT Option Pack on both nodes of your cluster, check for the version of MSDTC using the following steps:

On the node that is chosen to be Node B (the last node on which you run the Option Pack Setup program) check the version of the following two files:

  1. %windir%\system32\msdtc.exe

  2. %windir%\system32\msdtc.dll

  1. If the version is 1997.11.532.0 you can proceed with the installation sequence described in the next section, which is also documented in the following Microsoft Knowledge Base article:

    191138 - How to Install Windows NT Option Pack on Microsoft Cluster Server (in Microsoft TechNet)

If the version of either of these two files is newer than version 1997.11.532.0, you need to use a new installation sequence, which is documented in the Appendix.

Beginning the Windows NT Option Pack Installation on Node A

After following the steps listed in the previous section, "MSDTC Version Conflicts with Windows NT Option Pack Setup", to ensure that MSDTC does not cause the Windows NT Option Pack setup to fail, you are ready to begin installation of the Windows NT Option Pack on Node A. Before beginning the installation on Node A, move all existing resource groups to Node A using the Cluster Administrator (right-click the resource group and click Move Group).

If you have not already created a resource group for your Web Site(s), now is a good time to create it. Although it is not required that you create a separate resource group for your cluster enabled Web sites, it is encouraged. You can have a 1:1 ratio of resource groups to Web sites or you can host all of your Web sites in a single resource group. If you decide to create a new resource group for your Web sites, it should contain the following resources:

  • A disk resource. This disk resource is where your Web site content should be stored and maps to a physical drive letter on the shared SCSI drive/array.

  • A new IP address for every Web site you will be clustering. This is the IP address to which you will map a unique network name.

  • A network name resource for each Web site to be created. This network name will be mapped to an IP address, which in turn will be associated with a particular IIS Server Instance resource, which in turn maps to a physical Web site on each node.

If SQL Server is not already installed on the cluster and you are planning on installing SQL Server on the cluster in the future, you should decide whether it will be placed into its own dedicated disk group or whether it will share a disk group with IIS. If SQL Server will be placed in its own disk group, select the disk group that will be used for SQL Server and ensure that a disk resource, an IP address resource and a network name resource have been created in this resource group if you haven't already created these resource types. A network name and IP address resource type are required for the Windows NT Option Pack setup to recognize a disk group. During setup of the Windows NT Option Pack, you should install the MSDTC resource into the SQL Server resource group rather than installing it into your Web Server resource group (because there can be only one MSDTC resource per cluster). If you are going to be sharing the same disk resource group between SQL Server and the Windows NT Option Pack, you can place the Windows NT Option Pack MSDTC resource in this shared resource group.

Note: If you have IIS 3.0 installed, run the Internet Information Server Setup from the Microsoft Internet Server (Common) Group, and then select Remove All to remove IIS 3.0.

After ensuring that the preceding requirements are in place, you are ready to begin installing the Windows NT Option Pack on Node A.

  1. Start the Windows NT Option Pack installation on Node A and click Next. (NOTE: If you have Service Pack 4.0 or later installed, you will receive a prompt.) Press OK after reading the warning to continue.

    Cc767904.ntopcl02(en-us,TechNet.10).gif

  2. Read and accept the End User License Agreement (EULA), and then click Next.

    Cc767904.ntopcl03(en-us,TechNet.10).gif

  3. Click Custom, and then click Next in the following dialog box:

    Cc767904.ntopcl04(en-us,TechNet.10).gif

    If this screen does not appear, IIS is already installed and should be removed from both nodes prior to re-installing the Windows NT Option Pack.

    Clear the following components from the following dialog box:

    • FrontPage 98 Server Extensions (newer versions are available on the www.microsoft.com Web site)

    • Microsoft Index Server

    • Select the Internet Information Server (IIS) component and click Show subcomponents. On the New menu, clear the Simple Mail Transport Protocol (SMTP) service.

    Leave all other settings at their default values and click Next.

    Cc767904.ntopcl05(en-us,TechNet.10).gif

  4. On the following dialog box leave the WWW Service, FTP Service and Application Installation Point folder locations at their default values. Do not select the shared drive for these paths.

    Click Next.

    Cc767904.ntopcl06(en-us,TechNet.10).gif

  5. In the Microsoft Transaction Server setup dialog box, accept the default location, and then click Next.

    Cc767904.ntopcl07(en-us,TechNet.10).gif

  6. This portion of Setup has detected the presence of the cluster and will place the MSDTC log folder (used by the MSDTC resource) in the first resource group that contains a valid Network Name resource. In the Virtual Server list, click the NetBIOS name that corresponds to the resource group in which you placed your IIS server instances (if it is not already selected). In the DTC Log Folder dialog box, change the drive letter to match the drive letter of the disk resource for that resource group. If you have SQL Server installed and clustered, or if you plan on clustering SQL Server in the future, select the virtual server NetBIOS name corresponding to the SQL Server resource group and change the drive letter for the DTC log folder to point to the drive letter in that group.

    Click Next.

    Cc767904.ntopcl08(en-us,TechNet.10).gif

  7. Under Configure Administrative Account, click Remote. Specify an account with Administrator rights from the domain. (If the server is not a member of a domain, specify a local account with administrative rights.)

    Cc767904.ntopcl09(en-us,TechNet.10).gif

    Click Next. The file copy portion of setup begins.

    Cc767904.ntopcl10(en-us,TechNet.10).gif

  8. To complete setup on this node, click Finish.

    Cc767904.ntopcl11(en-us,TechNet.10).gif

    The following dialog box appears:

    Cc767904.ntopcl12(en-us,TechNet.10).gif

    Note: Do not click OK to continue on Node A until after you have installed the Option Pack on Node B.

  9. Begin the installation of the Windows NT Option Pack on Node B. Use the exact same settings that were used during the setup of Node A.

    Note: For IIS to function properly, it is important that the exact same components chosen during the installation on Node A be chosen during the installation on Node B. Failure to do so can result in failure to properly synchronize the nodes when using the IISSYNC command.

    You will not be prompted with all of the setup dialog boxes on Node B that you saw on Node A. This is normal. Node B's setup detects that setup is being run on the second node of a cluster and will connect to Node A to gather certain configuration information. You will, however, still need to perform a Custom install and manually clear the following components on Node B:

    • FrontPage 98 Server Extensions

    • Microsoft Index Server

    Highlight the Internet Information Server (IIS) group and click Show subcomponents. In the New menu, clear SMTP Service.

  10. After setup has completed on Node B, click Finish to complete the Windows NT Option Pack setup.

    Cc767904.ntopcl13(en-us,TechNet.10).gif

  11. Do not click Yes in the Systems Settings Change dialog box yet. Leave this dialog box on Node B for now and switch back to Node A.

    Cc767904.ntopcl14(en-us,TechNet.10).gif

  12. On Node A, click OK in the Microsoft Transaction Server Setup dialog box to finish the Windows NT Option Pack setup on Node A.

    Cc767904.ntopcl15(en-us,TechNet.10).gif

  13. Switch back to Node B and click Yes on the Systems Settings Change dialog box to restart Node B.

    Cc767904.ntopcl16(en-us,TechNet.10).gif

  14. After Node B has restarted, if you have Windows NT Service Pack 4 or later installed, reapply the service pack to Node B and restart Node B again.

  15. After Node B is back online, click Yes in the Systems Settings Change dialog box on Node A to restart Node A. If you have Windows NT Service Pack 4 or later installed, please reapply the service pack to Node A and restart Node A again.

    Cc767904.ntopcl17(en-us,TechNet.10).gif

Note on Reapplying Service Pack 4 or Later Service Packs on Both Nodes

If you have Windows NT Service Pack 4 or later installed, when the nodes come back online for the first time after the restart you may see that the Cluster Administrator fails to connect to the cluster, and that the cluster service does not start on either node. Additionally, you may get errors in the Event Log from the cluster service and also receive errors in the Cluster Administrator when connecting to the cluster.

This is normal behavior. Reapply Service Pack 4 or later on both nodes and restart the nodes once more to complete the installation of the Windows NT Option Pack. For more information, see the following article in the Microsoft Knowledge Base:

218922 - Installing NTOP on Cluster Server with SP4 Causes Event IDs 1009 (in Microsoft TechNet)

Creating a Clustered Web Site

After the Windows NT Option Pack has been successfully installed on both nodes of the cluster you can create a clustered IIS server instance in Cluster Administrator. Using the default Web site or administration Web site as your only clustered Web site is not recommended because of their IP address assignments (Any Unassigned). The location of content (C:\Inetpub\WWWRoot), and localized application settings. It is better to create a new Web site to use as your clustered Web site and to stop the default and administration Web sites in the Microsoft Management Console (MMC). The following is a high level overview of how to create a new clustered Web site:

  1. Pick one of the nodes in the cluster and designate it as the primary node at which all future Web sites will be created, configured, and administered. Web sites from this point on should always be created through the local MMC on the chosen node (rather than remotely administered from a remote workstation or server with the MMC installed). We will call this node, "Node A" throughout the rest of this white paper.

  2. Open Cluster Administrator and select the resource group in which you would like to place your IIS server instance (your clustered Web site). Create a new IP address resource and network name resource in this group that you will use for your WWW server (if you have not done so already). This IP address and network name are the IP address and NetBIOS name that you would like your Web clients to use to browse your clustered Web site. If your organization uses DNS, you should register the IP address you created with whatever hostname you would like your clients to use to access the server. For example, 10.5.5.5 may be the IP address you wish to use for your new Web site and you may want to call it www.example.microsoft.com.

    You would then register 10.5.5.5 with www.example.microsoft.com on your internal DNS servers so that clients do not have to type 10.5.5.5 to access the clustered WWW server.

    Cc767904.ntopcl18(en-us,TechNet.10).gif

  3. Open the MMC on Node A. In the left pane, right-click Node A's computer name, point to New, and then click Web Site.

  4. When the New Web Site Wizard dialog box prompts for the IP address, manually type in the IP address you configured in step 2.

    Cc767904.ntopcl19(en-us,TechNet.10).gif

  5. When the New Web Site Wizard dialog box prompts you for the location of the content, select a directory on the shared drive. You can copy the C:\Inetpub directory to the shared drive so that there is some content that can serve as a template and to test the Web site. In the following example, F:\Inetpub\WWWRoot is the home directory for the new Web site.

    Cc767904.ntopcl20(en-us,TechNet.10).gif

    When you are finished with the New Web Site Wizard, you will see a new Web site listed in MMC that is stopped. You can start the Web site to test it and verify that it will start, but the Web site should be stopped before proceeding to the next step.

    Cc767904.ntopcl21(en-us,TechNet.10).gif

  6. After creating the Web site using MMC, you must create an IIS Server Instance resource in your WWW resource group that maps to this physical Web site. This can only be done locally on Node A and cannot be done remotely due to limitations of the cluster resource .dll files. To create the IIS server instance resource, open the Cluster Administrator, right-click the IIS resource group, and then click New Resource. Select the IIS Server Instance resource type. The first screen prompts you for a name and a description for the resource. You can specify any name and description; this is the name and description for the resource you will see in Cluster Administrator and has nothing to do with the name clients will use to access the Web site.

    Click Next.

    Cc767904.ntopcl22(en-us,TechNet.10).gif

  7. In the Possible Owners dialog box, you will be prompted for which nodes should be possible owners of the new resource. Verify that both nodes are selected, and then click Next.

  8. You will be prompted for any resource dependencies your new resource type should have. Resource dependencies are other resources that should be brought online before attempting to bring the resource you are configuring online. IIS requires that the IP address for the Web site be brought online before the IIS server instance(s). To configure this dependency, select the Virtual IP address resource that matches the IP address for this IIS server instance from the Available Resources list in the left window and click the Add button to move it to the Resource Dependencies list in the right window. Click Next.

  9. You will be prompted to select whether you want to create a new FTP or WWW server instance. Select WWW and then select the Web site you created in MMC in step 3.

    Cc767904.ntopcl23(en-us,TechNet.10).gif

    Note: If you try to create the IIS server instance using Cluster Administrator installed on a remote workstation, you will not see this dialog box and you will be unable to create the resource. Although you cannot create a Web or FTP site remotely, you can stop, start and move IIS clustered resources through Cluster Administrator from a remote workstation or server.

  10. Click Finish to continue.

  11. Right-click the IIS Server Instance resource and then click Bring Online.

    Cc767904.ntopcl24(en-us,TechNet.10).gif

    Cluster Administrator is now used for starting and stopping the Web site (bringing the Web site online and offline) on this node, and you will no longer be able to use the MMC to start and stop the Web site. This change in behavior is accomplished through a metabase setting, which can only be changed manually as needed.

    You should now be able to browse the Web site by specifying its IP address its NetBIOS name, or its DNS name (if you have configured your DNS servers), in your Web Browser; however, the Web site is not ready to be failed over yet, and if you try to move the resource it will fail. This new Web site exists in the metabase on only one of the physical nodes. These metabase settings need to be synchronized between both nodes before the Web site will failover and move between the nodes.

    Synchronizing the two nodes in the cluster involves exporting metabase and MTS configuration settings from one node, copying them across the network to the other node and then applying these settings on the other node. Although it is possible to copy settings from Node A to Node B and vice versa, for the purposes of this white paper, we will only be pushing changes from Node A to Node B and will not be synchronizing in the other direction to minimize the chances of losing configuration information on our primary node.

    To configure MTS to allow synchronization perform the following steps:

    1. Open the Microsoft Transaction Server Explorer MMC by selecting Start, point to Windows NT 4.0 Option Pack, point to Microsoft Transaction Server, and then click Transaction Server Explorer.

    2. In the left pane, expand the Microsoft Transaction Server Snap-in, expand the Computers folder, and then right-click My Computer.

    3. Click Properties, and then click the Options tab.

    4. Under Replication, type in the NetBIOS name of the cluster in the Remote server name field (for example, if you named your cluster "IIS-Cluster" during the cluster server setup, you would type IIS-Cluster). If you do not remember the name of your cluster, it is shown in the title bar in upper Cluster Administrator title bar. Click OK.

    To configure the replication share (which will be used by IISSYNC later), specify an administrative share that will be used to transfer the MTS packages (that is C$, or D$) in the replication share field. This share must exist and be the same on both nodes, and administrators must have full control permissions on the share. Repeat these steps on Node B using the same information.

    Note: If these steps are not performed properly, irreparable damage may be done to MTS on one or both nodes when running the IISSYNC utility, resulting in the need to reinstall the Windows NT Option Pack to restore required MTS packages.

    Cc767904.ntopcl25(en-us,TechNet.10).gif

  12. Run the IISSYNC utility to synchronize both nodes of the cluster.

    Note: Before running this utility for the first time, there are some considerations that are discussed in the section "IIS Synchronization And Security Considerations In A Clustered Environment" later in this document that you need to review before proceeding with this step. After you have read through that section and made the appropriate changes you are ready to proceed with this step.

  13. First, try browsing the share from Node A by clicking Start, and then click Run. Type \\Node_B\c$ where Node_B is the NetBIOS name of Node B and c$ is the administrative share discussed in the previous step (for example, c$, d$ and so forth). This should open a new Explorer window that lists the contents of Node B's drive system drive. If this works, open a command prompt on Node A and switch to the %systemroot%\System32\Inetsrv directory.

    Type the following: iissync node_b where node_b is the NetBIOS name of Node B.

    You should see some local drive activity. You may observe a few minimized command shell windows appearing and disappearing and then you should get a status code of 0 (zero). If you do then the synchronization was successful.

    If you did not receive a status code of 0, refer to the following Microsoft Knowledge Base article for a listing of some of the common IISSYNC status codes:

    224801 – Deciphering IISSYNC Status Codes (in Microsoft TechNet)

    If IISSYNC does not return a code of 0, stop now, and re-check all of your settings.

  14. After you have synchronized the nodes you should be able to move your WWW resource group to Node B to simulate a failover.

IIS Synchronization and Security Considerations in a Clustered Environment

When installing Microsoft Cluster Server you have a couple of options for how to configure the Windows NT Server role of the nodes. For example Node A could be a primary domain controller (PDC) and Node B a backup domain controller (BDC), both nodes could be BDCs or both nodes could be member servers in a resource domain. The problem with member servers is that when installing the Windows NT Option Pack on a cluster, IIS continues to use the local IUSR_MACHINENAME account for anonymous access to the Web site(s). Most people create clustered Web sites with the intention of letting un-authenticated anonymous users browse the Web site. If the content is on the shared drive, then the IUSR_NODE A, IWAM_NODE A and IUSR_NODE B, IWAM_NODE B accounts would both have to be given permissions to the same content (by moving the shared drive back and forth between the nodes and assigning NTFS permissions) so that if the WWW Server is running on Node A, Node A's anonymous users have access to the content and vice versa. Optionally the Everyone special group can be given appropriate permissions to the shared content.

It is strongly recommended that a common IUSR and IWAM account be created in the Accounts domain (a domain trusted by both nodes) and IIS should be re-configured on each node to use these domain-based accounts (IUSR is the anonymous In-Process account and IWAM is the anonymous Out of Process account).

Important: If domain based accounts are not configured on both nodes of the cluster, prior to running IISSync to synchronize Node A to Node B (that is to push Node A's settings to Node B), then after running IISSync Node B will be configured with Node A's local, computer-specific, IUSR and IWAM accounts thus causing Anonymous access to fail on Node B (because Node B has no way of authenticating against Node A's local accounts database). After running IISSync from Node A to Node B, you have to either manually re-configure Node B's IUSR and IWAM accounts (which would now be IUSR_NODEA and IWAM_NODEA) to point to the appropriate local accounts on Node B (IUSR_NODEB and IWAM_NODEB) or configure both nodes for a common set of accounts (that is IUSR_DOMAIN, IWAM_DOMAIN) so that synchronizing the nodes does not change the account entries in the metabase to computer specific values.

Re-configuring IIS to use Domain-Based Anonymous Access accounts

The following example assumes that an IUSR_CLUSTER and IWAM_CLUSTER account have been created in the domain. When creating these accounts make the password sufficiently obscure so that it cannot be easily guessed (that is do not leave it blank). Write the passwords down if you need to, they will be needed later.

To configure IIS to use shared domain based accounts for anonymous access do the following:

Configuring IIS's Anonymous Access Account Through MMC on both nodes

  1. An anonymous account (IUSR_CLUSTER) and a Windows Access Method account (IWAM_CLUSTER) need to be created as domain accounts on the domain that these computers are members of or a trusted domain. These accounts need logon locally and access this computer from the network user rights on both nodes of the cluster. It is recommended that these accounts also be set to "cannot change their password" and "password never expires."

  2. In the MMC, expand the Internet Information Server tree, and then right-click the entry for the computer name.

  3. Click Properties. On the Internet Information Server tab, select WWW Service in the Master Properties drop-down list.

  4. Click Edit, and then click the Directory Security tab. Click the top Edit button associated with Anonymous Access and Authentication Control.

  5. In the Authentication Methods dialog box, select the Edit button to the right of Account used for Anonymous Access. This dialog box allows you to select the anonymous user domain account that you created (the IUSR_CLUSTER account).

  6. Select the IUSR_CLUSTER account, and then click OK until you are back to the MMC main screen.

    Note: Since we are using a domain based account instead of a local account, you cannot use Enable Automatic Password Synchronization. You must clear the Automatic Password Synchronization check box and type the password for the IUSR_CLUSTER account manually.

  7. Repeat these steps for the FTP service Master Properties. Click the Security Accounts tab, and then set the anonymous user account to the IUSR_CLUSTER account.

  8. Click Apply to save your changes, and then click OK until you return to the MMC main screen.

Setting the IWAM and IUSR Accounts in the IIS Metabase on both nodes

  1. The IWAM_CLUSTER account only needs to be set if you are using the WWW service and "Out of process" applications (applications configured to run in their own isolated memory space).

    Note: To set the IWAM account, make sure you have installed Windows Script Host from the Windows NT Option Pack. If the Script Host is not installed, you can install it by running Add/Remove Programs from Control Panel, and then choose Windows NT 4.0 Option Pack.

  2. Start a command prompt, and then go to the following folder:

c:\winnt\system32\inetsrv\adminsamples

  1. Type the following command, and then press ENTER:

adsutil.vbs enum w3svc

  1. If this is the first time you have run this script, or if your script interpreter is set to wscript, you will be prompted to associate this script with cscript. Click OK to associate the script with cscript and run the command again after returning to a command prompt.

  2. The correct output from this command should be the contents of the IIS 4.0 computer's metabase scrolling past in the command prompt window. If this is working properly, you must re-configure IWAM account information in the metabase. To do so, type the following:

adsutil set W3SVC/WAMUserName DOMAIN\IWAM_CLUSTER

Where *DOMAIN* is the name of the domain in which the user account IWAM\_CLUSTER exists. This sets the account to use the correct domain in order to authenticate the account.
  1. Type the following:

adsutil set W3SVC/WAMUserPass IWAM_Password

Where IWAM\_*Password* is the password for the IWAM\_CLUSTER account created earlier. This should correctly set this account for use by IIS 4.0.

Note that the IUSR\_CLUSTER account is only used for anonymous access, and the IWAM\_CLUSTER account is only used by the WWW service for Out of Process Web Applications.

After you have created these domain-based accounts, they should immediately be given **Log on Locally** rights on both nodes of the cluster. Also, the IUSR and IWAM accounts should be added to the local **Guests** group and the IWAM account should be added to the local **MTS Trusted Impersonators** and **MTS Impersonators** group on each node (**NOTE:** You will only have the **MTS Impersonators** group if you have Windows NT Service Pack 4 or later installed, which addressed an issue outlined in the following article in the Microsoft Knowledge Base article:

181775 - FIX: BUG: MTS Trusted Impersonators Group Name Is Too Long (in Microsoft TechNet)

Configuring DCOM

After you have updated the IUSR and IWAM accounts on both nodes you will need to update each node's DCOM configuration so that these accounts have the right launch and access permissions registered with DCOM.

To do this, follow these steps:

  1. Go to the Start button and select Run.

  2. Type dcomcnfg, and then press ENTER.

  3. On the Default Security tab, click Edit Default under Default Access Permissions.

  4. Remove the old IUSR and IWAM accounts and replace them with the new IUSR and IWAM accounts making sure the new accounts have Allow Access permissions.

  5. On the Default Security tab, click Edit Default under the Default Launch Permissions.

  6. Remove the old IUSR and IWAM accounts and replace them with the new IUSR and IWAM accounts making sure that the new accounts have Allow Launch permissions.

  7. Repeat steps 1 through 6 on both nodes of the cluster.

After configuring both nodes of the cluster to use the same IUSR_CLUSTER and IWAM_CLUSTER user accounts for anonymous WWW access, you can then assign this account permissions to your shared content on the shared drive.

Managing Clustered Web Sites

The following are some best practices for managing clustered Web sites:

Always log on locally on Node A and create any new Web sites or make changes with the MMC on Node A with the IIS Snap-in pointing to Node A's NetBIOS name. After you are finished making the changes to Node A's metabase, push Node A's changes to Node B using IISSync (discussed in step 13 of the "Creating a Clustered Web site" section of this white paper). While it is technically possible to connect to the Virtual Server NetBIOS Name resource running on the cluster with the MMC's IIS Snap-in, this is not advised for the following reason:

  • The IIS Snap-in for the MMC uses a NetBIOS name to connect to and manage IIS servers. The Virtual Server NetBIOS name is a clustered resource that can be running on either of the physical nodes. When using the MMC to remotely administer a computer, it is possible to connect to the virtual servers NetBIOS name, rather than the physical nodes NetBIOS name but it is impossible to tell from which MMC physical node the Virtual Server NetBIOS name is actually running. For example, if the TestWeb IIS server instance Web site was running on Node B, and you connect remotely through the MMC to the TestWeb NetBIOS name resource (which would also be running on Node B), then any changes you make to the TestWeb Web site through MMC get updated in Node B's metabase because that node owned the resources at the time you made your changes. Later if Node A is synchronized to Node B, those changes would be lost.

Place the Web servers content on the shared drive. Placing the Web content on the shared drive eliminates the need for having to use some sort of content replication scheme between the local copies of the content on the two nodes.

  • Placing the Web content on a shared drive poses an interesting problem with respect to NTFS permissions. Refer to the next section IIS Synchronization And Security Considerations In A Clustered Environment for details.
  1. Always log on locally on Node A when creating new IIS Server Instances in your WWW resource group. The Option Pack Resource DLL (Iisclex4.dll) file does not support creating WWW or FTP server instances from Cluster Administrator sessions running on remote workstations or servers.

  2. Any time a new virtual directory or Web site or Web application is desired, log on locally to Node A, make the changes in Node A's MMC (which is connected to Node A's NetBIOS name), and then use IISSync to push the changes to Node B. Any time an IIS Server Instance fails to come online on one of the nodes is a good indication that the nodes are not synchronized.

  3. By default, all new resources created in a resource group have the property Affect the group enabled (right-click the resource, click Properties, and then click the Advanced tab). This means that if, for any reason, that resource fails to come online that it should affect the group and attempt to move the group to the other node immediately. For example, if you try to move a resource group to the other node, and any of the resources in that group with this setting enabled fail to come online, the entire group will immediately bounce back to the originating node. If the resource fails to come online on the originating node as well, the resource group will bounce back and forth between the two nodes until the threshold is reached (by default it is 3) at which point the entire group will remain offline. This behavior may be undesirable and some people would rather just have that individual resource fail to come online without causing the entire group to bounce between nodes. Clear the Affect the group check box to change this default behavior.

Appendix: Installing Windows NT Option Pack on a Cluster

If the newer MSDTC files are on the hard disk drive, during the Windows NT Option Pack setup on the second node, you will receive the following errors during setup:

Cc767904.ntopcl26(en-us,TechNet.10).gif

This error means that the Distributed Transaction Coordinator failed to install properly on Node B. This error will be followed by other errors.

For example, this error occurs next:

Cc767904.ntopcl27(en-us,TechNet.10).gif

Because MSDTC failed to install properly, MTS fails to install properly and you will receive the following error eight or more times as MTS fails to create the required IIS packages on the second node:

Cc767904.ntopcl28(en-us,TechNet.10).gif

If you receive any of the preceding errors during the Option Pack setup, the installation of the Windows NT Option pack has failed and you will need to use the steps (that follow) to install the Option Pack setup properly.

To ensure that the Windows NT Option pack gets properly installed, use the instructions that follow.

Note: Windows NT must reside in the same location on both Node A and Node B. For example, if you install Windows NT to C:\Winnt on Node A, then you need to have Windows NT installed to C:\Winnt on Node B as well. If the Windows NT %SystemRoot% folder is not identical on both Node A and Node B, you will not be able to perform failover of IIS.

Note: Remove any failed Windows NT Option Pack installations using Add/Remove Programs prior to following these steps.

  1. Move all cluster resource groups to Node A.

  2. Start the Windows NT Option Pack installation on Node A. On the Microsoft Internet Information Server setup dialog box, accept the default location for the WWW, FTP, and the Application Installation Point settings. During the installation of Transaction Server, on the Microsoft Transaction Server 2.0 dialog box, the Windows NT Option Pack Setup program attempts to locate the MSDTC transaction log on a cluster disk resource in any resource groups currently owned by that node. The MSDTC Resource should reside in the resource group in which SQL Server is currently located. When you are prompted for which resource group to install the MSDTC log to and the location for the MSDTC log file, choose the SQL Server resource group network name you have created from the drop-down list and place the MSDTC Log directory on the Disk Resource that belongs to that SQL Server resource group. For example, if your SQL Server resource group network name is SQLGroup and the disk resource assigned to that group is drive letter S:, you would specify SQLGroup in the Virtual Server drop-down list, and S:\MSDTCLog as the path to the MSDTC Log directory.

    Note: DO NOT INSTALL ANYTHING INTO THE DEFAULT CLUSTER GROUP.

  3. At the end of the Windows NT Option Pack installation, a dialog box displays that instructs you to start the installation on Node B and to click OK when the setup is complete. Disregard this message and click OK on this dialog box to continue running setup.

  4. When you are prompted to reboot on Node A, choose No. Do not restart Node A at this point.

  5. Do not move the resource groups from Node A to Node B. Leave the resource groups running on Node A.

  6. Switch to Node B and stop the Microsoft Cluster Service by opening a command prompt and typing the following:

     net stop clussvc
    
  1. Start the Windows NT Option Pack installation on Node B. On the Microsoft Internet Information Server setup dialog box, accept the default location for the WWW, FTP, and the Application Installation Point settings. This installation does not prompt for the transaction log location. When this installation is complete, restart Node B.

  2. If Windows NT Service Pack 4 is installed on Node B, then the Cluster Server service will not start after the NTOP is installed and the computer is restarted. This is a known issue. For more information, see the following article in the Microsoft Knowledge Base for details:

    218922 - Installing NTOP on Cluster Server with SP4 Causes Event IDs 1009 and 1058 (in Microsoft TechNet)

    You must re-apply Service Pack 4 or later on Node B and restart the computer again before the Microsoft Cluster Server service will start.

  3. Move the resource groups from Node A to Node B.

  4. Restart Node A.

  5. If Windows NT Service Pack 4 is installed on Node A, then the cluster service will not start after the NTOP is installed. This is a known issue. Refer to the following article in the Microsoft Knowledge Base for details:

    218922 - Installing NTOP on Cluster Server with SP4 Causes Event IDs 1009 and 1058 (in Microsoft TechNet)

You must re-apply service pack 4 or later on Node A and restart the computer again before the Microsoft Cluster Server service will start.

The following seven steps are used to ensure that MSDTC is configured properly for use on a clustered system.

  1. Move the resource groups from Node B to Node A. Leave the resource groups running on Node A.

  2. At a command prompt on Node A, type the following:

     msdtc -remove
    
  1. At a command prompt on Node B, type the following:

     msdtc -remove
    
  1. If there is an MSDTC resource in any of the Cluster Server Resource Groups, delete this resource from the group that it is in. It can be in only one resource group if it is installed. If there is no MSDTC resource in any resource groups, this is ok.

  2. At a command prompt on Node A, type the following:

msdtc -install -d %windir%\system32 -l DTC_logfile_loc -v SQL_servername

**Note:** Make sure that the directory you specify for the DTC log file exists on the shared disk drive. For example, if you entered S:\\MSDTCLog for the -1 variable, check to make sure an MSDTCLog directory exists on the root of the S drive. If it does not exist, create the directory before running the above command (for example, for SQLGroup, you would type ***msdtc - install -d %windir%\\system32 –l S:\\MSDTCLog -v SQLGroup*** ).
  1. From a command prompt on Node B, type the following:

     msdtc -join %windir%\system32
    
At this point, MSDTC will be properly installed on the Cluster and an MSDTC Resource will now exist in the SQL Server Resource Group in Cluster Administrator. For fail-over of the SQL Server group to function properly, make sure to perform step 18. Failure to perform step 18 may cause SQL Server Group fail-over to take up to five minutes to move from one node to the other.
  1. In the Cluster Administrator, highlight the MSDTC Resource in the SQL Server resource group you specified, right-click it and then click Properties. Click Dependencies, and then click Modify. In the left frame of the Modify Dependencies Window, highlight and double-click the SQL Server Virtual Server Network Name. This should move the Virtual Server Name from the left frame to the right frame and list it as a dependency. Click OK, click Apply, and then click OK.

  2. At this point, the Web or FTP failover sites need to be created. Internet Information Server (IIS) virtual servers in this configuration require a resource group with an IP address at minimum; however, it is recommended that you also have a disk resource to store the Web pages on as well.

    Note: DO NOT USE THE DEFAULT CLUSTER GROUP.

  3. Move the resource group that you intend on creating the IIS Instance in to Node A, if it is not already running on Node A. If you have not created a resource group for your World Wide Web sites, create one now and give it a disk resource and IP address resource that your WWW site will use (for example, if your resource group for your Web sites is called WWWGroup, move the WWWGroup to Node A).

  4. In the Microsoft Management Console (MMC) on Node A, expand the Internet Information Server tree, right-click the computer name, and create a new Web (or FTP) site.

  5. In the properties for this new site, set the IP address of the site to be the same as the IP address resource for the resource group in which this Web site will reside (for example, if you have an IP address resource in your WWWGroup, and it is configured as 10.5.5.5, to configure the new Web site to use this address in the MMC).

  6. Select the directory, Universal Naming Convention (UNC) connection, or redirection that the site should use as the home directory. If you are selecting a drive, it should be a disk resource that is in the same resource group as the IP address.

  7. Repeat Steps 21 through 23 for each WWW of FTP site to which you want to provide failover capabilities.

Now, you can refer back to Creating a clustered Web site earlier in this document.

For More Information

For the latest information about the Windows NT Option Pack, see the following resources:

© 1999 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, BackOffice, the BackOffice logo, FrontPage, Outlook, and Windows NT are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

1099

The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.