Share via

Installing a Single Copy Cluster on Windows Server 2003

  • Article

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

Installation of a single copy cluster (SCC) on Windows Server 2003 occurs in multiple phases. Before deploying an SCC, we recommend that you thoroughly review Single Copy Clusters. In addition, you must make sure that you meet all of the requirements specified in Planning for Single Copy Clusters.

Note

For information about installing an SCC on Windows Server 2008, see Installing a Single Copy Cluster on Windows Server 2008.

Deploying an SCC on Windows Server 2003 is a process that occurs in several distinct phases:

  • Storage formation and configuration

  • Network formation and configuration

  • Forming the cluster, beginning with the first node and continuing on to the second and any subsequent nodes

  • Configuring physical disk resources inside the cluster

  • Configuring the cluster networks

  • Installing and configuring a clustered mailbox server

  • Configuring clustered mailbox server storage dependencies

  • Verifying handoff of the clustered mailbox server

We recommend that you complete each phase before you start the next phase. After you complete all phases, we recommend that you verify the SCC solution before putting it into production. The following sections explain each of the installation phases in more detail.

Storage Formation and Configuration

An SCC uses shared storage for the clustered mailbox server (storage groups and databases). An SCC can also use shared storage for the quorum resource; however, this is not required. All shared storage should be configured at the hardware level on all intended nodes prior to forming the cluster.

When using a shared disk quorum, it is mandatory that the quorum disk be configured and available to all nodes in the cluster prior to cluster formation. The cluster formation will revert to a local quorum, or fail completely, if the quorum shared disk is not available.

Note

Storage for a specific clustered mailbox server must be accessible from all nodes that can host the clustered mailbox server. Shared storage used for a quorum resource must be accessible from all nodes in the cluster, regardless of whether they can or will host a clustered mailbox server.

It is critical that storage be configured correctly in an SCC prior to putting the SCC into production. During the phases of installation and configuration for the SCC, there are tasks that must be performed for storage to be configured correctly for an SCC:

  • Storage must be properly configured at the hardware level before forming the cluster. For detailed steps about how to connect and configure the storage solution to the failover cluster, consult the instructions that came with the storage solution or consult with your hardware vendor.

  • One or more physical disk resources for the clustered mailbox server must exist in the failover cluster before installing Microsoft Exchange Server 2007. You cannot use the quorum disk resource for hosting storage groups and databases. Exchange 2007 Setup will not continue if shared storage is not detected in the cluster.

  • Physical disk resource settings and dependencies must be configured using Cluster Administrator or Cluster.exe after the clustered mailbox server is installed in the failover cluster.

We also recommend that you use the Diskpart tool (Diskpart.exe) to verify that your disk tracks are sector aligned. By using Diskpart to create aligned partitions (as compared with non-aligned partitions that are created by using the Disk Management tool), you can increase disk performance by 20 percent. For detailed steps, see How to Align Exchange I/O with Storage Track Boundaries.

Network Formation and Configuration

You must have a sufficient number of static IP addresses available when you create clustered mailbox servers in an SCC configuration. You must have one network that is dedicated to internal cluster communications and one network that is capable of both internal cluster communications and external client communications (for example, a mixed network).

IP addresses are required for both the public and private networks, all IP addresses for each cluster network must be on the same subnet, and each cluster network must be on a different subnet. (For example, the private network is on one subnet, and the public network is on a different subnet.) In addition, an IP address and network name are required for the clustered mailbox server. The following are recommendations for private and public IP addresses:

  • Private addresses   Each node requires one static IP address for each network adapter that is used for the cluster private network. You must use static IP addresses that are not on the same subnet or network as one of the public networks. We recommend that you use 10.10.10.x with a subnet mask of 255.255.255.0 as the private IP address subnet for the private network.

  • Public addresses   Each node requires one static IP address for each network adapter that is used for the cluster public network. Additionally, static IP addresses are required for the failover cluster and for the clustered mailbox server so that they can be accessed by clients and administrators. You must use static IP addresses that are not on the same subnet or network as one of the private networks.

Network Best Practices for Clustered Mailbox Servers

We also recommend that you follow these best practices for your cluster network:

  • Use meaningful names   Building a cluster gives you many opportunities to use meaningful names for cluster nodes, cluster network interfaces, the cluster name, and clustered mailbox server names. For example, the network used to communicate with other Exchange servers and clients can be called Public. The network used to communicate between the cluster nodes can be called Private. Use names that can be related to each other without having to review a topology map. Another useful convention is to relate the nodes of a cluster to the name of the clustered mailbox server. For example, use mbx01, mbx01-node1, and mbx01-node2 for the clustered mailbox server and the two nodes, respectively.

  • Use private IP addresses for the private network interfaces   Use the following table of address ranges and subnet masks for the private network interfaces.

    Network IP address range Subnet mask

    Private 1

    10.10.10.10-255

    255.255.255.0

    Private 2

    10.10.10.11-255

    255.255.255.0

Note the following:

  • If your public network uses a 10.x.x.x network and 255.255.255.0 subnet mask, we recommend that you use alternate private network IP addresses and subnet mask.

  • We do not recommend the use of any type of fault-tolerant adapter or teaming for the private network. If you require redundancy for your private network, use multiple network adapters set to Internal Communication Only and define their network priority in the cluster configuration. It is important to verify that your firmware and driver are at the most current revision if you use this technology. Contact your network adapter manufacturer for information about compatibility on a server cluster. For more information about network adapter teaming in server cluster deployments, see Microsoft Knowledge Base article 254101, Network adapter teaming and server clustering.

To configure the networks in the cluster for use with an SCC solution, configure the public and private networks by following the steps that are described in How to Configure Network Connections for a Single Copy Cluster.

Forming the Cluster

A failover cluster is formed when the first node is added to the cluster. This process gives the cluster a unique network name and a unique network IP address. The network name and IP address, which collectively are the cluster's network identity, move between nodes in the cluster as nodes go online and offline. Generally, the cluster's network identity is rarely used in the administration of a clustered mailbox server.

If you are familiar with deploying failover clusters or Exchange clusters from previous versions, you will find deployment of a cluster for an SCC solution to be quite different. If you are new to cluster solutions, you will find deployment to be much less complex than typical cluster configurations.

You can build a new cluster using the instructions in How to Create a Windows Server 2003 Failover Cluster for a Single Copy Cluster.

Adding Additional Nodes

After you install the Cluster service on the first node, you will find that it takes less time to install it on subsequent nodes. This is because the Setup program uses the network configuration settings configured on the first node as a basis for configuring the network settings on subsequent nodes. For detailed steps about how to add additional nodes to the cluster, see How to Create a Windows Server 2003 Failover Cluster for a Single Copy Cluster.

Before you add and configure additional nodes, you should validate the cluster configuration. You can verify that the Cluster service is running and the cluster is operational by running cluster group from a command prompt. It should produce output similar to the following:

C:\>cluster group

Listing status for all available resource groups:

Group                    Node                  Status

----------------     ---------------     ------

Cluster Group      <NodeName>        Online

We also recommend that you review the event logs for errors and warnings that might require attention before proceeding.

Configuring the Cluster Networks

After all nodes have been added to the cluster, the cluster networking components must be configured. Specifically, the cluster networks, cluster network priority, and tolerance settings for missed cluster heartbeats need to be configured. The following table details the available options for configuring cluster networks for the cluster heartbeat.

Options for configuring cluster networks

Option Description

Client access only (public network)

Select this option if you want the Cluster service to use this network adapter only for external communication with other clients. No inter-node cluster communication traffic will take place on this network adapter.

Internal cluster communications only (private network)

Select this option if you want the Cluster service to use this network only for the cluster heartbeat.

All communications (mixed network)

Select this option if you want the Cluster service to use the network adapter for inter-node cluster communication traffic and for communication with external clients. This option is selected by default for all networks.

Clustered mailbox servers deployed in an SCC require at least two network cards in each node to be supported. In an SCC, we recommend configuring one network as a private network and configuring the other network as a mixed network. If one network is configured as a private network and the other network is configured as a public network, the private network represents a single point of failure for the clustered mailbox server.

For detailed steps about how to configure the cluster networking components, see How to Configure Cluster Networking Components and Priority.

After the failover cluster has been created, and before the Mailbox server role is installed on any node in the cluster, we recommend you verify that the failover cluster is operational. For detailed steps about how to verify the failover cluster, see How to Verify that a Failover Cluster Is Operational.

Clustered Mailbox Server Installation and Configuration

You can install the Mailbox server role on a cluster by performing a few steps on each node. After the cluster has been formed and validated, you should install the Mailbox server role on the active node. When installing the Mailbox server role in an SCC, you must make sure that the path for the Exchange database file is located on a shared disk in the cluster. If you do not select a drive and path that is a shared disk in the cluster, Setup will fail with an error message. For detailed steps about how to install the Mailbox server role on the active node, see How to Install the Active Clustered Mailbox Role in a Single Copy Cluster on Windows Server 2003.

After you have installed the Mailbox server role and a clustered mailbox server on the active node and verified the first storage group's configuration, you should install the Mailbox server role on the passive node by following the steps in How to Install the Passive Clustered Mailbox Role in a Single Copy Cluster on Windows Server 2003.

Clustered Mailbox Server Storage Dependencies

After the clustered mailbox server has been installed, and before it is put into production, you must configure physical disk resources for the databases using Cluster Administrator or Cluster.exe. If this step is not performed and the proper cluster resource dependencies are not established, the databases will not mount after a failover or handoff has occurred. For detailed steps about how to configure the appropriate physical disk resource dependencies in an SCC running on Windows Server 2003, see How to Configure Disk Dependencies for a Single Copy Cluster on Windows Server 2003.

Installing Multiple Clustered Mailbox Servers

An SCC is only supported in an active/passive configuration or in a single-node active configuration. However, there can be multiple active and multiple passive nodes in the same SCC. In active/passive clusters, the cluster includes at least one (or more) active nodes and at least one (or more) passive nodes, for example, two active nodes and a passive node. In active/passive failover clusters, the number of clustered mailbox server instances is always less than the number of physical nodes in the cluster.

A Windows failover cluster can contain up to eight physical nodes. Therefore, the maximum number of clustered mailbox servers that can exist in one SCC is seven. A passive node may serve one or more active nodes, but we recommend that you deploy at least one passive node for every active node in the cluster.

The process for installing additional active and passive nodes is no different from the process for installing the first active and passive nodes. The requirement is that each active node that you install must have a corresponding passive node to be supported. A single passive node can be designated as the passive node for multiple active nodes. However, doing so may compromise availability because at any specific time, each node can only host one clustered mailbox server. In the case of two active nodes and one passive node, for example, the SCC does not have sufficient passive nodes to accommodate the simultaneous failure of both active nodes.

Note

In an SCC that contains multiple clustered mailbox servers, there is a known issue where you might not be able to create new mailboxes on the second and any subsequent clustered mailbox server that was installed in the failover cluster. When this issue occurs, attempts to create a new mailbox on the second or subsequent clustered mailbox server in the cluster will fail with the following error message: "A proxy generator DLL on server FQDN.serverName could not be found or failed to initialize. Proxy addresses for the current recipient cannot be calculated. Please ensure that all proxy address generator DLLs have been installed on the target server." You can resolve this issue by creating the new mailbox on another Mailbox server, and then moving that mailbox to the second or subsequent clustered mailbox server in the cluster. You can also resolve this issue by creating a Microsoft MTA object in Active Directory for the clustered mailbox server. For detailed steps, see How to Enable Mailbox Creation on the Second or Successive Clustered Mailbox Server of an Exchange 2007 Single Copy Cluster.

Verifying a Single Copy Cluster

After you complete the installation of an SCC solution, or after you make significant configuration changes, we recommend that you verify that both nodes are correctly configured to support the clustered mailbox server by performing a handoff of the clustered mailbox server between all nodes.

The recommended way to verify that both nodes are able to bring the clustered mailbox server online is to use the Move-ClusteredMailboxServer cmdlet to move the clustered mailbox server to each node. The Move-ClusteredMailboxServer cmdlet is available in the Exchange Management Shell.

For detailed steps about how to verify the SCC solution, see How to Verify Handoff in a Single Copy Cluster.