windows-xp/Source/XPSP1/NT/mergedcomponents/releasenotes/amd64/datactr4.txt

**********************************************************************

              Upgrading and Installing on Cluster Nodes
                    Release Notes, Part 4 of 4
                              Beta 2

**********************************************************************

         (c) 2001 Microsoft Corporation. All rights reserved.


These notes support a preliminary release of a software program that
bears the project code name Whistler.

With Whistler Datacenter Server, you can use clustering to ensure
that users have constant access to important server-based resources.
With clustering, you create several cluster nodes that appear to 
users as one server. If one of the nodes in the cluster fails, another 
node begins to provide service (a process known as failover). 
Mission critical applications and resources remain continuously 
available.

Sections to read if you are upgrading:
1.0     Upgrading or Installing Clustering
1.2     Options for Upgrading or Installing Clustering
2.0     Upgrading a Cluster from Windows 2000 to Whistler
2.1     How Rolling Upgrades Work
2.2     Restrictions on Rolling Upgrades
2.3     Resource Behavior During Rolling Upgrades
2.4     Alternatives to Rolling Upgrades from Windows 2000

Sections to read if you are performing a new installation:
1.0     Upgrading or Installing Clustering
1.2     Options for Upgrading or Installing Clustering
3.0     Installation on Cluster Nodes

======================================================================
1.0   Upgrading or Installing Clustering
======================================================================

Before installing or upgrading clustering, you should familiarize 
yourself with the basic preparations needed and the options available 
for upgrading and installing. The following sections provide 
information on these topics.

1.1   Preparing for Upgrading or Installing Clustering
======================================================================

To prepare for installing or upgrading clustering, review the
sections earlier in this text file series. As described in those
sections, check the Hardware Compatibility List to ensure that all
your hardware (including your cluster storage) is compatible with
Whistler Datacenter Server. In addition, check with the manufacturer
of your cluster storage hardware to be sure you have the drivers you
need in order to use the hardware with Whistler Datacenter Server.

1.2   Options for Upgrading or Installing Clustering
======================================================================

When installing or upgrading clustering, you can choose among several options. You can:

 * Upgrade a cluster that is running Windows 2000, possibly
   through a rolling upgrade. For more information, see "How
   Rolling Upgrades Work" and "Restrictions on Rolling Upgrades"
   later in this text file.

 * Perform a new installation of Whistler Datacenter Server and
   install Cluster service at the same time. For important
   information about preparing for cluster installation,
   see "Installation on Cluster Nodes" later in this text file.

Note: For cluster disks, you must use the NTFS file system and 
configure the disks as basic disks. You cannot configure cluster disks 
as dynamic disks, and you cannot use features of dynamic disks such as 
spanned volumes (volume sets). For more information about the 
limitations of server clusters, see Whistler Help and Support 
Services. To open Help and Support Services, after completing Setup, 
click Start, and then click Help.

For more information about reinstalling clustering on one of the 
cluster nodes, see Whistler Help and Support Services.


======================================================================
2.0   Upgrading a Cluster from Windows 2000 to Whistler
======================================================================

If you are upgrading from Windows 2000 to Whistler on cluster nodes,
you might be able to perform a rolling upgrade of the operating
system. In a rolling upgrade, you sequentially upgrade the operating
system on each node, making sure that one node is always available to
handle client requests. When you upgrade the operating system, the
Cluster service is automatically upgraded also. A rolling upgrade
maximizes availability of clustered services and minimizes
administrative complexity. For more information, see the following 
section, "How Rolling Upgrades Work."

To determine whether you can perform a rolling upgrade and understand 
the effect that a rolling upgrade might have on your clustered 
resources, see "Restrictions on Rolling Upgrades" later in this text 
file series. For information about ways to upgrade your cluster nodes 
if you cannot perform a rolling upgrade, see "Alternatives to Rolling 
Upgrades from Windows 2000" later in this text file series.

2.1   How Rolling Upgrades Work
======================================================================

This section describes rolling upgrades on server clusters. For
information about methods, restrictions, and alternatives to rolling
upgrades, see the following sections.

There are two major advantages to a rolling upgrade. First, there is
a minimal interruption of service to clients. (However, server
response time might decrease during the phases in which one node 
handles the work of the entire cluster.) Second, you do not have to 
recreate your cluster configuration. The configuration remains intact 
during the upgrade process.

A rolling upgrade starts with two cluster nodes that are running
Windows 2000. In this example, they are named Node 1 and Node 2.

Phase 1: Preliminary
Each node runs Windows 2000 Datacenter Server with the following
hardware and software:

 * A cluster storage unit using Fibre Channel, not SCSI. Fibre
   Channel is the only type of cluster storage on the Hardware
   Compatibility List for Datacenter Server. (Note that SCSI can be
   used for a two-node cluster with Advanced Server, not Datacenter
   Server.) 

 * The Cluster service component (one of the optional components of
   Windows 2000 Datacenter Server).

 * Applications that support a rolling upgrade. For more information,
   see the product documentation and "Resource Behavior During
   Rolling Upgrades" later in this text file.

At this point, your cluster is configured so that each node handles
client requests (an active/active configuration).

Phase 2: Upgrade Node 1
Node 1 is paused, and Node 2 handles all cluster resource groups while
you upgrade the operating system of Node 1 to Whistler Datacenter
Server.

Phase 3: Upgrade Node 2 
Node 1 rejoins the cluster. Node 2 is paused and Node 1 handles all
cluster resource groups while you upgrade the operating system on 
Node 2.

Phase 4: Final 
Node 2 rejoins the cluster, and you redistribute the resource groups
back to the active/active cluster configuration.

Important: For cluster disks, you must use the NTFS file system and 
configure the disks as basic disks. You cannot configure cluster disks 
as dynamic disks, and you cannot use features of dynamic disks such as 
spanned volumes (volume sets).

2.1.1   Performing a Rolling Upgrade
----------------------------------------------------------------------

For an outline of the rolling upgrade process, see the preceding
section, "How Rolling Upgrades Work."

Important: For information about what resources are supported during 
rolling upgrades, see "Restrictions on Rolling Upgrades" and "Resource 
Behavior During Rolling Upgrades" later in this text file series.

>>> To perform a rolling upgrade: 

1. In Cluster Administrator, click the node that you want to upgrade
   first.

2. On the File menu, click Pause Node.

3. In the right pane, double-click Active Groups.

4. In the right pane, click a group, and then on the File menu, click
   Move Group. Repeat this step for each group listed.

   The services will be interrupted during the time they are being
   moved and restarted on another node. After the groups are moved,
   one node is idle, and the other nodes handle all client
   requests.

5. Use Whistler Datacenter Server Setup to upgrade the paused node
   from Windows 2000. For information about running Setup, see
   sections earlier in this text file series.

   Setup detects the earlier version of clustering on the paused node
   and automatically installs clustering for Whistler Datacenter
   Server. The node automatically rejoins the cluster at the end of
   the upgrade process, but is still paused and does not handle any
   cluster-related work.

6. To verify that the node that was upgraded is fully functional,
   perform validation tests on it.

7. In Cluster Administrator, click the node that was paused, and then
   on the file menu, click Resume Node.

8. Repeat the preceding steps for any remaining node or nodes.

2.2   Restrictions on Rolling Upgrades
======================================================================

There are several basic restrictions to the rolling-upgrade process.
They involve the beginning of Phase 3, in which you operate a mixed-version cluster: a cluster in which the nodes run different versions
of the operating system. For a mixed-version cluster to work, the
different versions of the software running on each node must be
prepared to communicate with one another. This requirement leads to
several basic restrictions on the rolling-upgrade process.

 * For a successful rolling upgrade, every resource that the cluster
   manages must be capable of a rolling upgrade. For more
   information, see "Resource Behavior During Rolling Upgrades"
   later in this text file.

 * During the mixed-version phase of a rolling upgrade, when the
   cluster nodes are running different versions of the operating
   system, do not change the settings of resources (for example, do
   not change the settings of a printer resource).

If preceding restrictions cannot be met, do not perform a rolling
upgrade. For more information, see "Alternatives to Rolling Upgrades
from Windows 2000" later in this text file.

2.2.1   Operation of New Resource Types in Mixed-Version Clusters
----------------------------------------------------------------------

If a resource type that you add to the cluster is supported in one 
version of the operating system but not in the other, the operation of 
a mixed-version cluster is complicated. For example, Cluster service
in Whistler (part of the Advanced Server and Datacenter Server
products) supports the Generic Script resource type. However, older
versions of Cluster service do not support it. A mixed-version
cluster can run a Generic Script resource on a node running Whistler
but not on a node running Windows 2000.

Cluster service transparently sets the possible owners of new resource 
types to prevent these resources from failing over to a Windows 2000 
node of a mixed-version cluster. In other words, when you view the 
possible owners of a new resource type, a Windows 2000 node will not 
be in the list, and you will not be able to add this node to the list. 
If you create such a resource during the mixed-version phase of a 
rolling upgrade, the resource groups containing those resources will 
not fail over to a Windows 2000 node.

2.3   Resource Behavior During Rolling Upgrades
======================================================================

Although Cluster service supports rolling upgrades, not all
applications have seamless rolling-upgrade behavior. The following
table describes which resources will be supported during a rolling
upgrade. If you have a resource that is not fully supported during
rolling upgrades, see "Alternatives to Rolling Upgrades from 
Windows 2000" later in this text file.

RESOURCE           ROLLING UPGRADE NOTES
--------------     ------------------------------------------------
DHCP               Supported during rolling upgrades.
File Share         Supported during rolling upgrades.
IP Address         Supported during rolling upgrades.
Network Name       Supported during rolling upgrades.
NNTP               Supported during rolling upgrades.
Physical Disk      Supported during rolling upgrades
Time Service       Supported during rolling upgrades.
SMTP               Supported during rolling upgrades.
WINS               Supported during rolling upgrades.
Print Spooler      The only Print Spooler resources supported
                   during a rolling upgrade are those on LPR ports
                   or standard monitor ports. See the following
                   section, "Upgrades that Include a Print Spooler
                   Resource."
IIS                Internet Information Server (IIS) 6.0 is not
                   supported during rolling upgrades. For more
                   information, see "Upgrades the include an IIS
                   resource" later in this text file.
MS DTC             Microsoft Distributed Transaction
                   Coordinator is not supported during a rolling
                   upgrade. However, you can perform a process
                   similar to rolling upgrades. See "Upgrades that
                   Include an MS DTC Resource" later in this text file.
MSMQ               Microsoft Message Queuing is not supported
                   during a rolling upgrade. To upgrade a cluster
                   which includes MSMQ, see "Upgrades that Include
                   an MSMQ Resource" later in this text file.
Other resource     See Readme.doc in the root
types              directory of the Whistler Datacenter Server CD.
                   Also see the product documentation that comes
                   with the application or resource.

2.3.1   Upgrades that Include a Print Spooler Resource
----------------------------------------------------------------------

If you want to perform a rolling upgrade of a cluster that has a
Print Spooler resource, you must consider two issues.

First, the Print Spooler resource only supports upgrades (including
rolling upgrades or any other kind of upgrade) on printers on 
cluster-supported ports (LPR or Standard Monitor ports). For 
information about what to do if your printer is not supported, see 
"Alternatives to Rolling Upgrades from Windows 2000" later in this 
text file series.

Second, when you operate a mixed-version cluster including a Print
Spooler resource, note the following:

 * Do not change printer settings in a mixed-version cluster with a
   Print Spooler resource.

 * If you add a new printer, when you install the drivers for that
   printer, be sure to install both the driver for Windows 2000 and
   the driver for Whistler on all nodes. 

 * If printing preferences or defaults are important, be sure to
   check them. Printing preferences in Whistler won't necessarily
   correspond to document defaults for the same printer in Windows
   2000. This can be affected by differences in the drivers for the
   two operating systems.

When the rolling upgrade is complete and both cluster nodes are
running the updated operating system, you can make any modifications
you choose to your printer configuration.

2.4   Alternatives to Rolling Upgrades from Windows 2000
======================================================================

Certain resources are not supported during rolling upgrades,
including: 

   * Internet Information Server (IIS)

   * Microsoft Data Transaction Coordinator (MS DTC)

   * Microsoft Message Queuing (MSMQ)

Special procedures, described below, must be followed when performing
an upgrade of a cluster that contains these resources. In addition to
the three resource types above, you might also have other resources that are not supported during rolling upgrades. Be sure to read 
Readme.doc in the root directory of the Whistler CD, as well as the 
product documentation that comes with the application or resource.

2.4.1   Upgrades that Include an IIS Resource
----------------------------------------------------------------------

IIS 6.0 is not supported during rolling upgrades. With earlier
versions of IIS, you could configure an individual Web site to fail
over as a cluster resource. However with IIS 6.0, the entire IIS
service must fail over, not individual Web sites. If you have
individual Web sites or the IIS service configured as a cluster
resource, you must use the following procedure to upgrade to Whistler.

>>> To upgrade from Windows 2000 on a cluster that includes an IIS 
resource:

1. Remove any individual Web sites that you have configured as
   cluster resources from their cluster group. You can no longer
   designate a single site as a cluster resource.  

2. If you have the IIS service configured as a cluster resource, take
   this resource offline. To take the resource offline, follow the
   procedures described in "Upgrades for Other Non-Supported
   Resources" later in this text file.

3. Perform a rolling upgrade, as described in the procedure "To 
   perform a rolling upgrade" earlier in this text file. 

4. Once you have completed the upgrade, you can bring the IIS service
   back online.

Important: With IIS 6.0, you can only configure the IIS service as a 
cluster resource. You cannot configure individual Web sites as cluster 
resources.

2.4.2   Upgrades that Include an MS DTC Resource
----------------------------------------------------------------------

Microsoft Distributed Transaction Coordinator (MS DTC) is not 
Supported during rolling upgrades. However, you can perform a process 
similar to a rolling upgrade.

>>> To upgrade from Windows 2000 on a cluster that includes an MS DTC 
resource:

1. Take the MS DTC resource offline by using the Cluster Administrator 
   and clicking the Resources folder. In the details pane, click the 
   MS DTC resource, then on the File menu, click Take Offline. 

   Caution: Taking a resource offline causes all resources that depend 
   on that resource to be taken offline.

2. Configure the MS DTC resource so that the only allowable owner
   is the node it is currently on by using the Cluster
   Administrator and clicking the Resource folder. In the details
   pane, click the MS DTC resource. On the File menu, click
   Properties. On the General tab, next to Possible owners, click
   Modify. Specify Node 2 as an Available node, and if necessary,
   remove Node 1 from the Available nodes list.

3. Upgrade a node that does not contain the MS DTC resource from 
   Windows 2000 to Whistler. For general information about Setup, 
   review the sections earlier in this text file series.

4. Move the MS DTC resource to the upgraded nodes, following the
   procedures as described in step 1.

5. Configure the MS DTC resource so that the only allowable owner
   is the upgraded node, following the procedures as described in
   step 2.

6. Upgrade the remaining nodes from Windows 2000 to Whistler.  

7. Configure the allowable owners for the MS DTC resource as 
   appropriate for your configuration.

8. Manually restart all dependent services, and then bring the MS DTC
   resource back online by using the Cluster Administrator
   and clicking the Resources folder. In the details pane, click
   the MS DTC resource, and then on the File menu, click Bring Online.

2.4.3   Upgrades That Include an MSMQ Resource
----------------------------------------------------------------------

Microsoft Message Queuing (MSMQ) does not support rolling upgrades. 
The MSMQ resource is dependent on the MS DTC resource, so be sure to
follow the steps outlined in the preceding section "Upgrades that
Include an MS DTC Resource." 

>>> To upgrade from Windows 2000 on a cluster that includes an MSMQ 
resource:

1. Upgrade the operating system of the nodes to Whistler.  

2. Click Start, point to Programs, point to Administrative Tools, and
   then click Configure Your Server.

3. In Configure Your Server, click Finish Setup, and then click
   Configure Message Queuing Cluster Resources.

4. Follow the instructions that appear in the Configure Message
   Queuing Cluster Resources Wizard.

2.4.4   Upgrades for Other Non-Supported Resources 
----------------------------------------------------------------------

If you have other resources on your cluster that are not supported
during a rolling upgrade, but are not described above, take those
resources offline prior to performing the rolling upgrade. 

>>> To take a resource offline and perform a rolling upgrade:

1. Confirm that your systems are running Windows 2000.

2. Using the information in "Resource Behavior During Rolling
   Upgrades" earlier in this text files, list the resources
   in your cluster that are not supported during rolling upgrades.

3. In Cluster Administrator, click the Resources folder.

4. In the right pane, click the resource you want.

5. On the File menu, click Take Offline.

6. Repeat the preceding steps until you have taken offline all
   resources that do not support rolling upgrades.

7. Perform a rolling upgrade, as described in the procedure "To 
   perform a rolling upgrade" earlier in this text file series.

8. For each resource that you listed in step 2, follow the
   product's instructions for installing or reconfiguring the
   application so that it will run with Whistler.


======================================================================
3.0   Installation on Cluster Nodes
======================================================================

The following sections provide important information about how to
prepare for cluster installation, begin hardware installation for a
cluster, and start Setup on the first cluster node.

3.1   Planning and Preparing for Cluster Installation
======================================================================

Before carrying out cluster installation, you will need to plan 
hardware and network details.

Caution: Make sure that Datacenter Server and Cluster service are 
installed and running on one node before starting the operating system 
on another node. If the operating system is started on multiple nodes 
before Cluster service is running on one node, the cluster storage 
could be corrupted. Once Cluster service is  running properly on one 
node, the other nodes can be installed and configured simultaneously. 
Each node of your cluster must be running Datacenter Server. 

In your planning, review the following items:

* Cluster hardware and drivers.

  Check that your hardware, including your cluster storage and 
  other cluster hardware, is compatible with Whistler Datacenter 
  Server. To check this, see the Hardware Compatibility List (HCL) on 
  The Whistler CD, in the Support folder, in Hcl.txt. For the most 
  up-to-date list of supported hardware, see the Hardware 
  Compatibility List by visiting the Microsoft Web site at: 

  http://www.microsoft.com/

  You must have a separate PCI storage host adapter (SCSI or Fiber
  Channel) for the shared disks. This is in addition to the bootdisk 
  adapter.

  Also check that you have the drivers you need in order to use the
  cluster storage hardware with Whistler Datacenter Server. (Drivers 
  are available from your hardware manufacturer.)

  Review the manufacturer's instructions carefully before you begin
  installing cluster hardware. Otherwise, the cluster storage could 
  be corrupted. 

  To simplify configuration and eliminate potential compatibility
  problems, consider using identical hardware for all nodes.

* Network adapters on the cluster nodes.

  In your planning, decide what kind of communication each network
  adapter will carry.

  Note: To reduce the risks with having a single point of failure, 
  plan on having two or more network adapters in each cluster node, 
  and connecting each adapter to a physically separate network. The 
  adapters on a given node must connect to networks using different 
  subnet masks.

The following table shows recommended ways of connecting network
adapters:

ADAPTERS   
PER NODE   RECOMMENDED USE
--------   --------------------------------------------------------
2          One private network (node-to-node only), plus
           one mixed network (node-to-node plus client-to-cluster).
3          Two private networks (node-to-node), plus
           one public network (client-to-cluster).
           With this configuration, the adapters using the private
           network must use static IP addresses (not DHCP).
           or
           One private network (node-to-node), plus
           one public network (client-to-cluster), plus
           one mixed network (node-to-node plus client-to-cluster).

The following list provides more details about the types of
communication that an adapter can carry:

 * Only node-to-node communication (private network).

   This implies that the server has one or more additional adapters to 
   carry other communication.

   For node-to-node communication, you will connect the network
   adapter to a private network used exclusively within the
   cluster. Note that if the private network uses a single hub or
   network switch, that piece of equipment becomes a potential
   point of failure in your cluster.

   The nodes of a cluster must be on the same subnet, but you can use
   virtual LAN (VLAN) switches on the interconnects between two
   nodes. If you use a VLAN, the point-to-point, round-trip latency
   must be less than 1/2 second and the link between two nodes must
   appear as a single point-to-point connection from the perspective 
   of the operating system. To avoid single points of failure, use 
   independent VLAN hardware for the different paths between the 
   nodes.

   If your nodes use multiple private (node-to-node) networks, the
   adapters for those networks must use static IP addresses (not
   DHCP).

 * Only client-to-cluster communication (public network).

   This implies that the server has one or more additional adapters to 
   carry other communication.

 * Both node-to-node and client-to-cluster communication (mixed
   network).

   If you have only one network adapter per node, it must
   carry both these kinds of communication. If you have multiple
   network adapters per node, a network adapter that carries both
   kinds of communication can provide backup for other network
   adapters.

 * Communication unrelated to the cluster.

   If a clustered node also provides services unrelated to the 
   cluster, and there are enough adapters in the cluster node, you 
   might want to use one adapter for carrying communication unrelated 
   to the cluster.

Consider choosing a name for each connection that describes its 
purpose. The name will make it easier to identify the connection 
whenever you are configuring the server.

* Cluster IP address.

  Obtain a static IP address for the cluster itself. You cannot use
  DHCP for this address.

* IP addressing for cluster nodes.

  Determine how to handle the IP addressing for the cluster nodes. 
  Each network adapter on each node will need IP addressing. You can 
  provide IP addressing through DHCP, or you can assign each network 
  adapter a static IP address. If you use static IP addresses, the 
  addresses for each linked pair of network adapters (linked 
  node-to-node) should be on the same subnet.

  Note: If you use DHCP for the cluster nodes, it can act as a
  single point of failure. That is, if you set up your cluster nodes 
  so that they depend on a DHCP server for their IP addresses, 
  temporary failure of the DHCP server can mean temporary 
  unavailability of the cluster nodes. When deciding whether to use 
  DHCP, evaluate ways to ensure availability of DHCP services, and 
  consider the possibility of using long leases for the cluster nodes. 
  This will help ensure that they always have a valid IP address.

* Cluster name.

  Determine or obtain an appropriate name for the cluster. This is 
  the name administrators will use for connections to the cluster. 
  (The actual applications running on the cluster will typically have
  different network names.) The cluster name must be different from 
  the domain name, from all computer names on the domain, and from 
  other cluster names on the domain.

* Computer accounts and domain assignment for cluster nodes.

  Make sure that the cluster nodes all have computer accounts in the
  same domain. Cluster nodes cannot be in a workgroup.

* Operator user account for installing and configuring the Cluster
  service.

  To install and configure Cluster service, you must log on to 
  each node with an account that has administrative privileges on 
  those nodes.

* Cluster service user account.

  Create or obtain Cluster service user account. This is the 
  name and password under which Cluster service will run. You 
  will need to supply this user name and password during cluster 
  installation.

  The Cluster service user account should be a new account. The
  account must be a domain account; it cannot be a local account. The
  account also must have local administrative privileges on all of the
  cluster nodes. Be sure to keep the password from expiring on the
  account (follow your organization's policies for password renewal).

* Volume for important cluster configuration information (checkpoint 
  and log files).

  You need to plan to set aside a volume on your cluster storage
  for holding important cluster configuration information. This
  information makes up the quorum resource of the cluster, needed 
  when a cluster node stops functioning. The quorum resource provides 
  node-independent storage of crucial data needed by the cluster.

  The recommended minimum size for the volume is 500 MB. You should 
  use a different volume for the quorum resource than you use for user 
  data.

* List of storage devices or disks attached to the first server on 
  which you will install clustering.

  Unless the first server on which you will install clustering has 
  relatively few storage devices or disks attached to it, you should 
  make a list that identifies the ones intended for cluster storage. 
  This makes it easy to choose storage devices or disks correctly 
  during cluster configuration.

  Note: When planning and carrying out disk configuration for the 
  cluster disks, configure them as basic disks with all partitions 
  formatted as NTFS. Do not configure them as dynamic disks, and do 
  not use Encrypting File System, volume mount points, spanned volumes 
  (volume sets), or Remote Storage on the cluster disks.

The following section describes the physical installation of the
cluster storage.

3.2   Beginning the Installation of the Cluster Hardware
======================================================================

The steps you carry out when first physically connecting and
installing the cluster hardware are crucial. Be sure to follow the
hardware manufacturer's instructions for these initial steps.

Important: Carefully review your network cables after connecting them. 
Make sure no cables are crossed by mistake (for example, private 
network connected to public).

Caution: When you first attach your cluster hardware (the shared bus 
and cluster storage), be sure to work only from the firmware 
configuration screens on the cluster nodes (a node is a server in a 
cluster). On a 32-bit computer, use the BIOS configuration screens. On 
a 64-bit computer, use the Extensible Firmware Interface (EFI) 
configuration screens. The instructions from your manufacturer will 
describe whether these configuration screens are displayed 
automatically or whether you must, after turning on the computer, 
press specific keys to open them. Follow the manufacturer's 
instructions for completing the BIOS or EFI configuration process. 
Remain in the BIOS or EFI, and do not allow the operating system to 
start during this initial installation phase.

3.3   Completing the Installation
======================================================================

After the BIOS or EFI configuration is completed, start the operating
system on one cluster node only and carry out the installation of 
Cluster service. Before starting the operating system on another node, 
make sure that Whistler Datacenter Server and Cluster service are 
installed and running on that node. If the operating system is started 
on multiple nodes before Cluster service is running on one node, the 
cluster storage could be corrupted.

While remaining in the BIOS or EFI configuration screens, ensure that
you can scan the bus and see the drives from all cluster nodes.

3.4   Installation on the First Cluster Node
======================================================================

It is important that you work on one node (never two nodes) when you
exit the BIOS or EFI configuration screens and allow the operating
system to start for the first time.

Caution: Make sure that Whistler Datacenter Server and Cluster service 
are installed and running on one node before starting the operating 
system on another node. If the operating system is started on multiple 
nodes before Cluster service is running on one node, the cluster 
storage could be corrupted.

3.4.1   Completing the Installation on the First Cluster Node
----------------------------------------------------------------------

If you have not already installed Whistler Datacenter Server on the
first cluster node, install it now. For information about decisions
you must make, such as decisions about licensing and about the
components to install, see the sections earlier in this text file
series.

When Whistler Datacenter Server is installed, use the following
procedure to obtain specific information about how to complete the
installation of the cluster.

>>> To obtain additional information about how to install and 
configure Cluster service:

1. With Whistler Datacenter Server running on one cluster node, click
   Start, and then click Help and Support.

2. Click Enterprise Technologies, and then click Windows Clustering.

3. Click Server Clusters.

4. Click Checklists: Creating Server Clusters, and then click 
Checklist: Creating a server cluster.

5. Use the checklist to guide you through the process of completing
   the installation of your server cluster.