Installing Microsoft Exchange 2000 on a Windows 2000 Cluster: Step-by-Step Guide

Article
02/20/2014

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: November 1, 2000 | Updated : June 14, 2001

By Rick Varvel, Microsoft Consulting Services, PacWest

This step-by-step guide provides instructions for installing Microsoft® Exchange 2000 Server on a Microsoft Windows® 2000 two-node cluster. The guide describes the process of installing Exchange 2000 on a cluster, setting up an Exchange virtual server (EVS), creating the necessary resources for each EVS, and verifying failover capability. Before you begin the Exchange 2000 cluster installation, you must have a functional Windows 2000 cluster.

Overview

It is important to have a firm understanding of the Microsoft Windows 2000 Cluster Service because it works directly with Exchange 2000. There are many documents in the MSDN® Library that discuss the Windows 2000 Cluster Service. The rest of this paper assumes that you are familiar with Windows clustering. For additional resource information on Windows clustering, including the "Step-by-Step Guide to Installing Cluster Service" white paper, see the appendix. Listed below are the major topics that this white paper will address:

Cluster terminology review
Software and hardware requirements for installing Exchange 2000 on a cluster
Step-by-step Exchange 2000 cluster installation instructions
Failover capability verification

The main features of the Windows 2000 Cluster Service, with respect to Exchange 2000, are:

Shared nothing architecture - Because the Windows 2000 Cluster Service does not allow dynamic load balancing, neither does Exchange 2000. Although all nodes in the cluster can access the shared data, the nodes cannot access the data at the same time. For example, if three physical disk resources are assigned to node 1 of a cluster, those three drives will not be accessible by node 2 unless node 1 is taken offline or fails, or the disk resources are moved to another node manually. Failover times are greatly dependant on hardware and load. However, on current hardware and light load, failover times are normally less than a minute. No one can access the shared data during that time.
Resource DLL - The Windows 2000 operating system communicates with resources in a cluster through a resource dynamic-link library (DLL). Exchange 2000 provides its own custom resource DLL, named Exres.dll. Communication between the Windows 2000 Cluster Service and Exchange 2000 has been enhanced and customized to provide all Cluster Service functionality.
Exchange virtual servers (also known as Cluster groups) - Exchange 2000 uses the cluster groups as Exchange virtual servers. Understanding how Windows 2000 uses cluster groups and their properties will help the user understand how Exchange 2000 works in a clustered environment.
Resources - When Exchange 2000 is installed on a cluster, it adds its own resources, such as the System Attendant, for use in clustering. Exchange 2000 also uses some resources provided by Windows 2000, such as the Internet Protocol (IP) address, the network name, and the physical disk resource.

Cluster Terminology Review

If you are familiar with clustering terminology as it applies to both Windows 2000 clusters and Exchange 2000 running on Windows 2000 clusters, you can go to the "Software and Hardware Requirements for Installing Exchange 2000 on a Cluster" section.

Windows Clustering

A server cluster is a group of independent computer systems, known as nodes, working together as a single system to ensure that mission-critical applications and resources remain available to clients. Each node has one or more physical disks used for storing the operating system, the swap file, non-shared applications (such as Exchange 2000 binary files), and so on that only they have access to. At the same time, every node is attached to one or more shared cluster storage devices (such as a Storage Area Network) that contain the cluster quorum drive and Exchange 2000 shared resources (such as log files, public stores and message stores). Clustering allows users and administrators to access and manage the nodes as a single system rather than as separate computers.

A server cluster node is a system that has a working installation of Microsoft Windows 2000 Advanced Server or Windows 2000 Datacenter Server and the Cluster Service. By definition, a node is always a member of a server cluster.

Nodes have the following characteristics:

Every node is attached to one or more shared cluster storage devices. Each cluster storage device attaches one or more disks. The disks store all of the cluster's configuration and resource data. Each disk can be owned by only one node at any point in time, but ownership can be transferred between nodes. The result is that each node has access to all cluster configuration data.
Every node communicates with the other nodes in the cluster through one or more physically independent networks. In the "Step-by-Step Guide to Installing Cluster Service" white paper, this network is referred to as the private cluster (or heartbeat) network.
Network adapters, also called network interfaces, attach nodes to networks.
Every node in the cluster can detect another system joining or leaving the cluster.
Every node in the cluster can detect the resources that are running locally and the resources that are running on the other cluster nodes.
All nodes in the cluster are grouped under a common name - the cluster name - which is used when accessing and managing the cluster.

Windows 2000 Cluster Groups

A cluster group is a collection of cluster resources with the following characteristics:

Groups define the units of failover. That is, when one resource in a group fails and it is necessary to move the resource to an alternate node, all of the resources in the group are moved to the alternate node and brought back online.
A group is always owned by one node at any point in time. Likewise, a resource is always owned by a single group. These relationships ensure that all of a group's members reside on the same node.

To fully exploit the processing power of a cluster, administrators should establish at least as many groups as there are nodes in the cluster so that when all nodes are online, each node can own at least one group.

Exchange 2000 Virtual Servers

To access a network application or resource in a nonclustered environment, network clients must connect to a physical server (that is, a specific computer on the network identified by a unique network name and IP address). If that server fails, access to the application or resource is impossible.

Windows 2000 cluster groups are called virtual servers in Exchange 2000. Unlike a physical server, a virtual server is not associated with a specific computer and can be failed over like a group. If the node hosting the virtual server fails, clients can still access its resources using the same server name.

An Exchange virtual server is a cluster group that requires, at a minimum, the following four resources.

A static IP address for the EVS.
A network name resource for the EVS.
One or more physical disks on the shared storage, which, in most cases, is either a SCSI drive or a Storage Area Network. The important thing to note is that it is disk space that is shared between all nodes in the cluster, as opposed to the locally attached storage that each node holds.
An Exchange 2000 System Attendant resource, which, in turn, installs all the other required Exchange resources.

Clients connect to the EVS just as they do to a stand-alone server. The IP address, network name, and disk resources associated with the EVS are Windows 2000 cluster resources and are available as soon as the Cluster Service is installed. The System Attendant resource is only available after Exchange 2000 is installed on each node. After the System Attendant resource is added to an Exchange virtual server, the remaining resources such as the HTTP virtual server, IMAP4 virtual server, and Information Store instances (see figure 1) are added as dependent resources automatically. The right pane in Figure 1 shows the minimum resources required for a virtual server. If you want your Exchange front-end servers to communicate with the virtual server, you will need to configure additional HTTP virtual server resources as outlined in the "Step 6: Configure Front-end Server Support (Optional)" section.

Figure 1: Example of Exchange Virtual Server Resources

If the storage groups for the EVS are configured so that logs are on one set of drives and databases are on another, all drives used must be in the EVS. This data must go on the shared storage so that, if an EVS is moved to another node, the EVS can still access the data. Clients connect to the EVS using the network name or IP address of the virtual server (not the network name or IP address of the physical member server).

Each cluster node has its own storage that is not visible to other nodes. In addition, there is shared storage, which, under normal operation, is partly visible to each node. In a failover condition where one node is offline, the entire shared storage is visible to the remaining node or nodes.

Because an EVS is a cluster group, all properties such as preferred owner, failover, and failback policies are set on the EVS. The EVS is the basic unit of failover. If a resource fails in the EVS, the Cluster Service tries to restart the resource. If the resource fails multiple times, the Cluster Service moves the entire EVS to another node. The same is true for a planned failover; the finest granularity of failover is the entire EVS.

IP Addresses and Network Names

A two-node cluster configured with two Exchange 2000 virtual servers has, at a minimum, seven IP addresses and five NetBIOS names associated with it. For example:

Each node of the two-node Windows 2000 cluster has two IP address each (the public and private network connection IP address of each physical member server) and one NetBIOS name.
Both Exchange virtual servers have an IP address and a NetBIOS name.
The cluster, as a unit, has an IP address and a NetBIOS name.

The NetBIOS name and the network name are similar concepts. The former refers to the Windows 2000 cluster node itself (for example, GOAEX01), and the latter refers to the Exchange virtual server (for example, GOAEVS01). When you create an Exchange virtual server, you provide a network name with which Exchange clients contact it.

If you are accessing the cluster node directly (for example, mapping a drive to it), use the NetBIOS name. However, if you are accessing the Exchange virtual server that is running on the cluster node (for example, using the Microsoft Outlook® 2000 messaging and collaboration client to read e-mail), use the network name.

When you see NetBIOS in this document, assume it refers to a Windows 2000 cluster node, and when you see network name, assume it refers to the Exchange virtual server running on the cluster node.

Exres.dll

Exres.dll is the Exchange-specific resource DLL. The Cluster Service communicates through a resource monitor to Exres.dll, which, in turn, communicates with the proper Exchange components. Exres.dll performs actions such as bringing resources online and offline, checking resources with IsAlive calls, and reporting failures.

In a cluster, the Cluster Service is responsible for starting and stopping services through Exres.dll. The administrator should not stop a service from the command line, because, in that case, the IsAlive call fails and the Cluster Service attempts to bring the service back online.

A stand-alone server cannot have more than four storage groups mounted and active at one time; therefore, you have to monitor the number of storage groups in a cluster. The same limitation of four storage groups applies to a single node of the cluster. No matter how many Exchange virtual servers are failed over to a single node, Store.exe cannot mount more than four storage groups. Stated another way, the combined number of storage groups in a two-node cluster cannot exceed four; for example, if node 1 contains three storage groups, node 2 can have only one.

Failover

Failover is the process of moving a group of resources from one node to another. For example:

When a resource in a group fails and cannot be restarted, that group would failover (move to another node).
When a node encounters a problem, the Cluster Service sees this and moves all groups sitting on that node to another node.

Active/Passive

In an active/passive cluster configuration, only one node of the cluster is active at any given time. All resource groups reside on that node. If that computer fails or is taken offline, the other node will gracefully take over all resource groups. The problem with this configuration is that one node is always idle.

Active/Active

In an active/active cluster configuration, each node of the cluster will own a group (for example, an Exchange virtual server) so all nodes are working all the time. With this approach, no nodes are idle.

All the restrictions and recommendations that apply to Windows 2000 clusters also apply to Exchange 2000 when running on a Windows 2000 cluster. These restrictions and recommendations include hardware compatibility and deployment guides.

Quorum Resource

The most important disk in the Storage Area Network is the quorum disk, which is a disk in the system designated as the quorum resource - a disk that provides persistent physical storage across system failures. The cluster configuration is kept on this disk, and all nodes in the cluster must be able to communicate with the node that owns it. It is possible (but not recommended) for one disk to store cluster application or service data and also to be the quorum disk.

When a cluster is created or when network communication between nodes in a cluster temporarily fails, the quorum resource is used to prevent the nodes from forming multiple clusters. To form a cluster, a node must arbitrate for and gain ownership of the quorum resource. For example, if a node cannot detect a cluster during the discovery process, the node will attempt to form its own cluster by taking control of the quorum resource. However, if the node does not succeed in taking control of the quorum resource, it cannot form a cluster.

The quorum resource stores the most current version of the cluster configuration database in the form of recovery logs and registry checkpoint files that contain node-independent storage of cluster configuration and state data. When a node joins or forms a cluster, the Cluster Service updates the node's private copy of the configuration database. When a node joins an existing cluster, the Cluster Service can retrieve the data from the other active nodes. The Cluster Service uses the quorum resource's recovery logs to:

Guarantee that only one set of active, communicating nodes is allowed to operate as a cluster.
Enable a node to form a cluster only if it can gain control of the quorum resource.
Allow a node to join or remain in an existing cluster only if it can communicate with the node that controls the quorum resource.

A simple cluster arrangement showing ownership of the quorum disk is shown in Figure 2.

Figure 2: Simple cluster configuration

In this figure, two nodes are connected to one Storage Area Network, but there are multiple volumes (in this case, two) on the Storage Area Network.

Node A is providing a virtual server, which means it is providing the network name, IP address, service, or application, and has exclusive access to the application or service data associated with that virtual server. Node B has no activity related to providing this virtual server to clients.

Node B has ownership of the quorum disk, illustrating that the node providing the virtual server does not have to be the node that also has control of the quorum resource. Node A could have ownership of the quorum disk in this cluster. As a best practice, it is recommended that you do not store data for a virtual server on the disk in the Storage Area Network serving as the quorum disk to prevent the quorum from becoming corrupted. If the quorum is damage, the entire cluster can be lost.

You specify an initial quorum resource when you install the first node of a cluster. You can use Cluster Administrator to change the quorum resource so that it points to a different drive.

If the quorum resource fails or becomes corrupted, or if the quorum log becomes corrupt, the Cluster Service cannot start. To correct this situation, you must modify the Cluster Service to start with a different quorum resource or no quorum resource at all using the fixquorum option. For complete instructions on recovering from a corrupted quorum resource, see the Microsoft Knowledge Base article 266274: "How to Troubleshoot Cluster Service Startup Issues," available at https://support.microsoft.com/default.aspx?scid=kb;en-us;266274&sd=tech.

For more information about changing the quorum resource location, see the Cluster Administrator online Help.

Software and Shared Disk Requirements for Installing Exchange 2000 on a Cluster

Use this checklist to prepare for installing Exchange 2000 on a cluster. Step-by-step instructions begin after the checklist. It is assumed that the Windows 2000 Cluster Service is running on a two-node cluster (two member servers) that is part of an Active Directory™ domain.

Software Requirements

The following software requirements are the minimum requirements needed to successfully install Exchange 2000 in a cluster.

Microsoft Windows 2000 Advanced Server or Windows 2000 Datacenter Server installed on all computers in the cluster.
A name resolution method such as Domain Naming System (DNS), Windows Internet Naming System (WINS), HOSTS, and so forth.
Terminal Services to allow remote cluster administration is recommended.

Shared Disk Requirements

The following shared disk requirements are the minimum requirements needed to successfully install Exchange 2000 in a cluster.

Make sure all shared disks, including the quorum disk, are physically attached to a shared bus.
Verify that disks attached to the shared bus can be seen from all nodes. This can be checked at the host adapter setup level. Please refer to the manufacturer's documentation for adapter-specific instructions.
Configure all shared disks as basic (not dynamic).
Format all partitions on the disks as NTFS.
Do not use multiple partitions on a single RAID drive; multiple partitions are not supported.

Although not required, the use of fault-tolerant RAID configurations is strongly recommended for all disks. The key concept here is fault-tolerant RAID configurations - not stripe sets without parity.

In the "Step-by-Step Exchange 2000 Cluster Installation Instructions" section, you will start with a working two-node cluster containing two member servers (for example, GOAEX01 and GOAEX02). Figure 3.1 shows the disk configuration for GOAEX01 as viewed from the Disk Management window of Disk Administrator. Figure 3.2 shows the comparable disk configuration for GOAEX02.

Figure 3.1: GOAEX01 Disk Configuration

Figure 3.2: GOAEX02 Disk Configuration

In the configuration used in this white paper, the Windows 2000 cluster started with eight logical drives labeled T through Z and Q. Drive Q was used for the cluster quorum drive; drives T through V were assigned to GOAEX01; and drives W through Z were assigned to GOAEX02. Drive Z was not used, but it was configured so it could be available if needed.

Note: All drives initially came up as Dynamic and had to be set back to Basic before starting the Exchange 2000 installation. To reset a drive from Dynamic to Basic, click Start, point to Programs, point to Administrative Tools, and then click Computer Management. Double-click Storage, and then click the Disk Management folder. In the right pane, right-click the dynamic disk you want to change back to a basic disk (for example Disk 4 in Figure 3.2), and then click Revert to Basic Disk. Each member server had a local drive C, and that is where the Windows 2000 operating system and Exchange 2000 binary files were installed.

Step-by-Step Exchange 2000 Cluster Installation Instructions

Installation Overview

Setting up an active/active cluster configuration means that you are setting up a cluster with at least two Exchange virtual servers. You will also need to create at least two groups in the cluster; each group will need a static IP address, a unique network name, a shared physical disk drive, and an Exchange System Attendant as resources. As seen in Figure 1, GOAVS01 and GOAVS02 are the Exchange virtual servers that correspond to the physical member servers in the cluster (GOAEX01 and GOAEX02). When clients connect to the cluster resources they use the name of the Exchange virtual server, not the name of the cluster member server.

You can have more than two Exchange virtual servers in a cluster. The number of virtual servers you can have depends on the number of static IP addresses, network names, and shared disk drives you have. These step-by-step instructions cover only a two-node configuration (each with a single EVS).

This step-by-step guide assumes that Exchange 2000 is not already installed in your organization and that you will be installing Exchange 2000 on to the Windows 2000 cluster using the existing Cluster Service account (called SvcCluster in this guide).

There are five basic steps and one optional step involved in configuring Exchange 2000 to run on a cluster.

Determine which account to use to install Exchange 2000. You will be installing the Exchange 2000 binary files on the Windows 2000 cluster.
Prepare Active Directory for Exchange 2000. You will be running the Exchange Setup program with the /ForestPrep and /DomainPrep command-line switches.
Install the Exchange 2000 binary files. You will be installing them on each node of the cluster.
Create an Exchange virtual server. You will be creating the EVS on each node.
Assign resources to each Exchange virtual server. You will be assigning the IP address, network name, physical disk, and Exchange System Attendant resources.
Configure front-end server support (optional). You will configure each Exchange virtual server to support to Exchange 2000 front-end servers.

Step 1: Determine Which Account to Use to Install Exchange 2000

Exchange 2000 must be installed on the Windows 2000 cluster using the same account that was used to create the cluster or you will encounter the following error related to permissions when trying to configure the Exchange System Attendant later in the setup process:

An unknown error has occurred

Facility: Win32 ID no: c0075000
Microsoft Exchange Cluster Administrator Extension.

Using the Cluster Service account to install Exchange 2000 is not a problem if ForestPrep has not been run yet. However, if you already have run ForestPrep and specified an account other than the Cluster Service account (for example, if Exchange 2000 already was running on nonclustered servers in your organization), then you will need to run the Exchange Administration Delegation Wizard, assign Exchange Full Administrator rights to the Cluster Service account, and then go to "Step 2: Prepare Active Directory for Exchange 2000."

Note: If you designated a group when you ran ForestPrep originally, you can add the Cluster Service account to the group instead.

Assign necessary rights to the Cluster Service account:

Click Start, point to Programs, point to Administrative Tools, and then open Windows 2000 Users and Computers.
Right-click the SvcCluster account, and then click Properties.
Click the Members of tab and add SvcCluster to the Schema Admins and Enterprise Admins groups.

Note: After running ForestPrep, DomainPrep, and Setup to copy the binary files to each cluster node, you can remove SvcCluster from the Schema Admins and Enterprise Admins groups.

On each member server in the cluster:

Log on to GOAEX01 as either a local administrator or domain administrator.
Click Start, point to Programs, point to Administrative Tools, and then open Computer Management.
Click the + to expand the Local Users and Groups folder.
Select the Groups folder.
In the right pane, right-click the Administrators group, and then click Properties.
Click Add, and then in the Look In list box, select the entire directory to find the SvcCluster account.
Click SvcCluster, click Add, and then click OK.

Step 2: Prepare Active Directory for Exchange 2000

Log on to the root domain as SvcCluster, preferably from a computer in the root domain.
Click Start, click Run, enter the path to Exchange 2000 Setup program with the /ForestPrep switch (for example f:\setup\1386\setup.exe /ForestPrep), and then click OK to modify the Active Directory schema to support Exchange 2000.

Note: During the ForestPrep setup procedure, be sure to enter SvcCluster when prompted for the Exchange Service Account as this is the account that will be granted Exchange Full Administrator rights, which are required for installing the Exchange binary files on each node of the cluster.
If the cluster is in a domain other than the root domain, log on as SvcCluster to the domain containing the cluster; otherwise, go to Step 3: Install the Exchange 2000 Binary Files.
Click Start, click Run, enter the path to Exchange 2000 Setup program with the /DomainPrep switch (for example, f:\setup\1386\setup.exe /DomainPrep), and then click OK to create the necessary groups and assign rights to them.

Step 3: Install the Exchange 2000 Binary Files

Run Exchange 2000 Setup

Log on to node 1 of the cluster (GOAEX01) as SvcCluster.

Note: If you do not use an account with Exchange Full Administrator rights (by default, the account specified when you ran setup /ForestPrep), you will see the following error message.
If NNTP is not already installed, click Start, point to Settings, click Control Panel, click Add/Remove Programs, click Add/Remove Windows Components, double-click Internet Information Services, and then click Details. Click to select the NNTP check box, and then click OK.
Run Setup from the Exchange 2000 compact disc. Use the default of Typical.
Be sure the path points to a local drive on the member server (recommend c:\exchsrvr) and accept the rest of the defaults. Click OK to finish Setup.

Note: the Exchange binary files must go on the same local drive for all nodes, which is a change from Exchange 5.5. For example, don't use c:\exchsrvr on one node and d:\exchsrvr on the other.
The Microsoft Exchange 2000 Installation Wizard displays the following dialog box to inform the user that Exchange 2000 is being installed on a cluster. Click OK to continue.
When prompted to restart your computer, click OK.

Note: Exchange Setup creates the Exchange-specific cluster resource types (System Attendant, IMAP, Information Store, SMTP, and so forth).
Repeat steps 1 through 6 for node 2 in the cluster (GOAEX02).

Step 4: Create an Exchange Virtual Server

Log on to the domain containing the cluster as SvcCluster.
Click Start, point to Programs, point to Adminstrative Tools, and then click Cluster Administrator.
If this is the first time you've connected to the cluster with Cluster Administrator, you will be prompted with the Open Connection to Cluster dialog box. Type "." (without the quotation marks) in the cluster name field and then click Open. If you've previously connected to a cluster, you will be taken to that cluster when you click Cluster Administrator.
In the left pane, click the + next to Groups and you will see the existing groups in your cluster.

Note: The Cluster Group, which holds the quorum drive, is already a virtual server (it has a static IP address, network name, and a physical disk). If you have more than one disk drive, you should also see groups such as Disk Group 1, Disk Group 2, Disk Group 3, and so forth.
To create a new group, right-click Groups in the left pane, click New, click Group, and then click OK.
Type the name of the group (GOAVS01), and then click Next.
Select the name of the member server you are configuring the Exchange virtual server on; this server will be the preferred node (for example, GOAEX01).

Note: A preferred node is the node that would "own" the group by default. The group could also be failed over or moved to the other node, but it would "prefer" to sit on the node with the highest preference.
Click Finish.
Repeat steps 4 through 8 for virtual server GOAVS02.

Step 5: Assign Resources to Each Exchange 2000 Virtual Server

Create an IP Address Resource

Right-click the newly created group, click New, and then click Resource.
In the Name field, enter the resource name (for example, GOAVS01 IP Address).
In the Description field, enter the resource description (for example, GOAVS01 IP Address), and then click Next.
In the Resource type list box, select IP Address, and then click Next.
In the Possible owners field, make sure all nodes are listed as possible owners (which is the default), and then click Next.
On the Dependencies tab, make sure the Resource dependencies field is empty, and then click Next.
On the Parameters tab, enter the IP address and corresponding subnet mask for the Exchange 2000 virtual server. (This IP address must be different from the IP address of the cluster node or the "virtual" IP address of the cluster itself, both of which you defined when setting up the Windows 2000 cluster.)

Note: If you have more than one network adapter, in the Network field, make sure you specify the network that is used for the public network access (for example, Public Cluster Connection in the figure below), and then click Finish.

Create a Network Name Resource

Right-click the newly created group, click New, and then click Resource.
In the Name field, enter the resource name (for example, GOAVS01 Network Name).
In the Description field, enter the resource description (for example, Exchange 2000 Virtual Server 01), and then click Next.
In the Resource type list box, select Network Name, and then click Next.
In the Possible owners field, make sure all nodes are listed as possible owners (which is the default), and then click Next.
From the list of available resources, select the IP address resource you previously created, add it to Resource dependencies, and then click Next.
In the Name field on the Parameters tab, enter the network name for your virtual server, and then click Finish.

Create Physical Disk Resources

When the Windows 2000 cluster was set up, six drives were configured. During the process to create physical disk resources, three physical disk resources will be assigned to each Exchange virtual server: two for log files (SG1 and SG2) and one for data. Physical disk resources originally assigned to Disk Group 1 through Disk Group 6 when the cluster was first configured were reassigned as follows:

Disk Group 1 through Disk Group 3 (drives T, U, and V) were reassigned to GOAVS01.
Disk Group 4 through Disk Group 6 (drives W, X, and Y) were reassigned to GOAVS02.

Move Disk Group 1 Resources

To reassign physical disk resources from one group to another, perform the following steps:

In the left pane of Cluster Administrator, click the Disk Group 1 group (or the disk group number that corresponds with the drive or drives you want to add to your Exchange virtual server).
Drag the physical disk resource (disk T) in Disk Group 1 to GOAVS01.

Note: Make sure the disk group you want to reassign a drive from is on the same node as the virtual server (GOAVS01) you just created. If it is not, right-click Disk Group n and select Move Group to move the group to the correct node. For example, by default Disk Group 1 through Disk Group 6 were all on node 1 (GOAEX01); Disk Group 4 through Disk Group 6 had to be moved to node 2 (GOAEX02) before physical disk resources were added to GOAVS02.
In the Cluster Administrator dialog box, click Yes, and then in the Move Resources dialog box, click Yes.
Right-click the disk resource you just moved (for example, drive T), select Properties. In the Name field, change the name to something more descriptive (for example, GOAVS01 SG1 Logs (T:)) and then click OK.

Note: Drive T will store the log files from the first storage group (SG1) on GOAVS01.

Move Disk Group 2 Resources

In the left pane of Cluster Administrator, click the Disk Group 2 group (or the disk group number that corresponds with the drive or drives you want to add to your Exchange virtual server).
Drag the physical disk resource (disk U) in Disk Group 2 to GOAVS01.
In the Cluster Administrator dialog box, click Yes, and then in the Move Resources dialog box, click Yes.
Right click on the disk resource you just moved (for example, drive U), select Properties. In the Name field, change the name to something more descriptive (for example, GOAVS01 SG2 Logs (U:)) and then click OK.

Note: Drive U will store the log files from the second storage group (SG2) on GOAVS01.

Move Disk Group 3 Resources

In the left pane of Cluster Administrator, click the Disk Group 3 group (or the disk group number that corresponds with the drive or drives you want to add to your Exchange virtual server).
Drag the physical disk resource (disk V) in Disk Group 2 to GOAVS01.
In the Cluster Administrator dialog box, click Yes, and then in the Move Resources dialog box, click Yes.
Right-click on the disk resource you just moved (for example, drive V), select Properties. In the Name field, change the name to something more descriptive (for example,GOAVS01 Data (V:)) and then click OK.

Note: All public and mailbox store database files (.edb and .stm) from both Exchange 2000 storage groups will be stored on Drive V.
In the left pane of Cluster Administrator, right-click GOAVS01, and then click Bring Online.

Create an Exchange System Attendant Resource

In the left pane of Cluster Administrator, click GOAVS01
Right-click in the right pane, click New, and then click Resource.
In the Name field, enter the resource name (for example, GOAVS01 SA).
In the Description field, enter the description (for example, Exchange 2000 System Attendant).
In the Resource Type list box, select Microsoft Exchange System Attendant.
In the Possible owners field, make sure both GOAEX01 and GOAEX02 are listed of possible owners.
On the Dependencies tab, in the Resource dependencies field, select the cluster name and the three physical disk resources for disks T, U, and V, click Add, and then click Next. The cluster IP address is an optional dependency.

Note: At this point, you will be prompted for the path to the Exchange 2000 Data Directory. Exchange 2000 Setup places both the log files and the default public and private database files (pub1.edb, pub1.stm, priv1.edb, and priv1.stm) on the drive you select in answer to this message. For the configuration discussed in this white paper, the files were put on drive V, which was where all the Exchange database files for GOAEX01 were to be kept. After the Exchange files are installed on each node and the Exchange virtual servers are configured, you can use Exchange System Manager to move or relocate the log files.
In the left pane of Cluster Administrator, right-click GOAVS01, and then click Bring Online. This will start the Exchange System Attendant and the remaining resources.
Repeat all of step 5: "Assign Resources to Each Exchange 2000 Virtual Server" for GOAVS02.

Note: When you create the Exchange virtual server GOAVS02 physical disk resources, substitute Disk Groups 1 through 3 with Disk Groups 4 through 6, and physical disk resources Disk T through U with Disk V through W. If you've used different drive letters for your environment or you have a different number of drives, you will need to make the appropriate adjustments.

After you successfully add a System Attendant resource, your Exchange virtual server might resemble the configuration in the Cluster Administrator window below. After both GOAVS01 and GOAVS02 are online, it is recommended that you verify the cluster failover capability. The "Failover Capability Verification" section outlines a simple process for testing your Exchange 2000 cluster.

Step 6: Configure Front-End Server Support (Optional)

If you have any Exchange 2000 servers in your organization configured as front-end servers, it is necessary to modify settings using both Cluster Administrator and Exchange System Manager.

Basically, you will map each front-end server to both nodes of your cluster so that either node can accept proxy requests from any front-end server in your organization. Proxy requests are requests for messaging services from client computers running Outlook Web Access, POP3, or IMAP that are sent to the cluster through the front-end servers. For this optional section, server names have been changed but the steps outlined still apply.

Create HTTP Virtual Server and Virtual Directories Using System Manager

On one of the cluster nodes (for example GOAEX01), click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
If Administrative Groups are not visible in the left pane of System Manager, right-click your organization name (for example ADTest (Exchange)), click Properties, click to select the Display Administrative Groups check box, and then click OK. In the Exchange System Manager dialog box, click OK.

Note: The Exchange System Manager dialog box that appears after performing this step states that you have to reboot for changes to take affect, but it is not actually necessary.
Double-click Adminstrative Groups, double-click First Administrative Group, double-click Servers, double-click your server name (for example GOAVS01).

Note: The servers are listed by virtual server name, not node name.
Double-click Protocols, and then double-click HTTP.
Right click the HTTP folder, point to New, and then click HTTP Virtual Server.
In the Name field, type in the name of your front-end server (for example GOAEW01).
Click Advanced, and then, in the Advanced dialog box, click Add.
The Identification dialog box is now displayed. In the Host name field, enter the same front-end server you provided in step 6 above (for example, GOAEW01), and then click OK three times to create the HTTP Virtual Server.
Right-click the HTTP Virtual Server you created in step 8, point to New, and then click Virtual Directory. You will create two virtual directories for each virtual server you create.
In the Name field, enter Exchange, and then click OK to create the first virtual directory.
Right-click the HTTP Virtual Server you created in step 8, point to New, and then click Virtual Directory.
In the Name field, enter Public, click the Public folder radio button, and then click Modify.
The Public Folder Selection dialog box appears. Double-click Public Folders, wait approximately 5 seconds for the public folder server name to be resolved, and then click OK to close the Public Folder Selection dialog box. Your screen should look similar the one below. You can tell that the public folder server name has been resolved when the machine name is appended to the Public Folders tree (for example, Public Folders(GOAVS01)). Click OK again to create the second virtual directory.
Right-click the HTTP virtual server you created in step 8, and then press F5 on your keyboard to start the HTTP virtual server.

Note: In some cases the server will not start immediately by pressing the F5 key in which case it is necessary to wait a few minutes until the icon for the HTTP virtual server (for example GOAEW02 Virtual Server (GOAVS01)) contains a red circle with an X in it. Once the red circle appears, right click the HTTP virtual server you created in step 8, and then click Start (see below).
Repeat steps 9 through 14 for each HTTP virtual server you create.

Note: You will need to create an HTTP virtual server to correspond with every front-end server that will connect to your cluster, and each HTTP virtual server will need two virtual directories.
After you have configured one node of your cluster with all the necessary HTTP virtual servers and firtual directories, repeat steps 1 through 15 on the other node. When complete, your HTTP virtual servers will look something like the following:

Create HTTP Cluster Resource Using Cluster Administrator

On one of the cluster nodes (for example GOAEX21), click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
If this is the first time you've connected to the cluster with Cluster Administrator you will be prompted with the Open Connection to Cluster dialog box. Type "." (without the quotation marks) in the cluster name field, and then click Open. If you've previously connected to a cluster, you will be taken back to that cluster when you click Cluster Administrator.
In the left pane, right-click one of the Exchange virtual server groups (for example, GOAVS01), point to New, and then click Resource.
In the Name field, enter the resource name (for example, GOAVS01 HTTP Virtual Server).
In the Description field, enter the resource description (for example, Front End VS for GOAEW01 (GOAVS01)), and then click Next.
In the Resource type list box, select Microsoft Exchange HTTP Server, and then click Next.
In the Possible owners field, make sure both GOAEX01 and GOAEX02 are listed of possible owners.
On the Dependencies tab, in the Resource dependencies field, select Exchange Information Store Instance, click Add, and then click Next.
From the Virtual Server Instance list box, select the virtual server that you created (in steps 1 through 15 in the previous section), and then click Finish. In the Cluster Administrator dialog box stating that the cluster resource was created successfully, click OK.
In the right pane, right-click the HTTP server instance you just created, and then click Bring Online.
Repeat steps 1 through 10 for each additional front-end server you have. Your configuration should look similar to the following:

Note: If a user tries to access the cluster through the front-end server after the virtual server has been created in the Exchange System Manager but before an HTTP server instance has been created in Cluster Administrator, the user will receive an HTTP 500 error. This error will continue after creation of the HTTP server instance in Cluster Administrator. If this happens, the W3SVC service must be restarted on each node of the server cluster before it will be accessible through the front-end server.

Failover Capability Verification

To test functionality, four storage groups (two on GOAVS01 and two on GOAVS02) were created. A single database in each storage group was also initially created. Four users were then created in Active Directory and each one was assigned a mailbox on a different database. Finally, four Outlook Web Access sessions were started, one for each of the four mailboxes, and a message was sent to each of the four user accounts.

After the message transfer was complete, one of the nodes was failed over and another message was sent to each of the four accounts successfully. It took approximately 40 seconds for the node to fail over, and there was no impact to either the Outlook client or the Outlook Web Access client other than the expected "Network Problems are preventing connection…" error messages. The failover did not require the client to be closed and restarted, nor did it cause the client to stop responding.

Set Up Validation Testing

Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
Double-click Adminstrative Groups, double-click First Administrative Group, double-click Servers, and then double-click your server name (for example GOAEX01).
Right-click First Storage Group, click New, and then click Mailbox Store.
In the Name field, enter DB1, and then click OK. If successful, you will see a message saying, "The new store was created successfully. Do you want to mount it now." Click Yes, and then click OK in response to the message saying, "The store was successfully mounted."
Right-click your server name (for example GOAEX01), click New, and then click Storage Group.
In the Name field, enter SG1. In the Transaction log location field, enter the path to where you are storing your log files (for example U:\Program Files\Exchsrvr\mdbdata). In the System path location field, enter the path to where you want to store temporary and recovered files (for example, U:\Program Files\Exchsrvr\mdbdata). Click OK.
Right-click the storage group (SG1) you created in the previous step, click New, and then click Mailbox Store.
In the Name field, enter DB1 and click OK. If successful, you will see a message saying, "The new store was created successfully. Do you want to mount it now." Click Yes, and then click OK in response to the message saying, "The store was successfully mounted."
Repeat steps 1 through 8 for the other server in your cluster (for example, GOAEX02).
Click Start, point to Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.
In the left pane, double-click your domain, right-click the Users organization unit, click New, and then click User.
In the First Name field, enter User1; in the User logon name field, enter User1; click Next; leave the password blank; click to select the Password never expires check box; and then click Next.
If it is not already selected, click to select the Create an Exchange mailbox check box, verify that the Server field contains the correct organization/administrative group/server combination (for example, yourOrgName/First_Adminstrative_Group/GOAEX01).
Verify that the Mailbox Store field contains the correct storage group/database combination (for example, First_Storage_Group/DB1), and then click Next. Click Finish.
Repeat steps 10 through 14 to create three additional user accounts, one on each of the remaining databases created in steps 1 through 8.
Click Start, click Run, and then open an Outlook Web Access session for each user account (that you created in steps 10 through 14) using the syntax shown in the Run dialog box below. Substitute the correct mailbox name for username.
In the Enter Network Password dialog box, type in your username, password, and domain, and then click OK to log on to each account.
In Outlook Web Access, send a message from one user to the other three users; copy the first user to guarantee that all users can receive mail.

Force GOAVS02 to Fail Over

Click Start, point to Programs, point to Adminstrative Tools, and then click Cluster Administrator.
If this is the first time you've connected to the cluster with Cluster Administrator you will be prompted with the Open Connection to Cluster dialog box. Type "." (without the quotation marks) in the cluster name field, and then click Open. If you've previously connected to a cluster, you will be taken to that cluster when you click Cluster Administrator.
In the left pane of Cluster Administrator, click the + to expand Groups; you will see the existing groups in your cluster.
Right-click GOAVS02, and then click Take Offline.

Note: At this point, the GOAVS02 resources are offline and anyone with a mailbox on GOAVS02 will not have access to his or her messages until ownership of GOAVS02 resources is moved from GOAEX02 to GOAEX01.
Right-click GOAVS02, and then click Move Group.

Note: Because there is only one active node to fail over to, it is not necessary to specify a server to move the resources to. At this point, note that all resources for Exchange virtual server GOAVS02 are running on (or owned by) GOAEX01. The following view of Cluster Administrator shows that the GOAVS02 resources have failed over to GOAEX01.
If failover has been successful, Cluster Administrator will display available resources similar to the following window.

Conclusion

By following the steps in this white paper, you will complete the installation of Exchange 2000 on a Windows 2000 two-node cluster. It may help to keep in mind that all interaction between Exchange 2000 servers or from an Outlook client to an Exchange 2000 server used the virtual name of the System Attendant (for example, GOAVS01 and GOAVS02) and not the physical member servers (GOAEX01 and GOAEX02).

Appendix

Additional Resources

The following resources have additional information that will help you in your setup and configuration of Windows Clustering.

Step-by-Step Guide to Installing Cluster Service: a white paper.

Troubleshooting: a chapter in the Microsoft Cluster Server Administrator's Guide.

Microsoft Exchange 2000 Clustering: a white paper.

Backing Up and Restoring the Cluster Configuration: an MSDN article.

Planning for Network Load Balancing: a Windows Advanced Help article.

The Microsoft Exchange Server Web site at https://www.microsoft.com/exchange/.

Microsoft Knowledge Base Articles

The following Microsoft Knowledge Base articles contain information about the Cluster service. Additional articles can be found by searching the Microsoft Knowledge Base at https://support.microsoft.com/.

280353: How to Change Quorum Disk Designation

172951: How to Recover from a Corrupted Quorum Log

266274: How to Troubleshoot Cluster Service Startup Issues