Share via

Installing a Single Copy Cluster on Windows Server 2008

  • 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 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

Installation of a single copy cluster (SCC) on Windows Server 2008 occurs in several different phases. Although the process for deploying an SCC on Windows Server 2008 is similar to deploying an SCC on Windows Server 2003, there are some significant differences. 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

Exchange Server 2007 is not supported on computers that are running Microsoft Windows Server 2008 R2. For more information about the operating systems that are supported for use with Exchange 2007, see Exchange 2007 System Requirements.

Note

For information about how to install an SCC on Windows Server 2003, see Installing a Single Copy Cluster on Windows Server 2003.

The process of deploying an SCC on Windows Server 2008 occurs in several distinct phases:

  • Storage formation and configuration

  • Network formation and configuration

  • Forming the cluster, beginning with the first node and adding one or more subsequent nodes

  • Configuring the cluster networks

  • Configuring the cluster quorum

  • Validating the failover cluster

  • Installing and configuring a clustered mailbox server

  • Verifying handoff of the clustered mailbox server

Before you perform any of the following referenced procedures, you must first make sure that the intended computers have the required operating system components for Windows Server 2008 installed. For more information about how to install Exchange prerequisites on Windows Server 2008, see How to Install Exchange 2007 SP1 and SP2 Prerequisites on Windows Server 2008 or Windows Vista.

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 a clustered mailbox server's storage groups and databases. Although SCCs are supported using Node Majority with File Share Witness Quorum, we recommend that you use a Node Majority with Disk Witness Quorum for SCCs. Because SCCs use shared storage, all storage should be configured prior to cluster formation on each node that will be part of the cluster. For cluster configurations that use an odd number of nodes, we recommend that you use Node Majority. For cluster configurations that use an even number of nodes, we recommend that you use Node and Disk Majority.

Note

Storage for a specific clustered mailbox server must be accessible from all nodes that can host the clustered mailbox server. Storage for the quorum resource for a cluster must be accessible from all nodes in the cluster.

In an SCC, the correct order for installing and configuring storage resources is as follows:

  • The storage solution must be properly connected and configured at the hardware level before forming the failover 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 dependencies must be manually configured by an administrator after a clustered mailbox server has been added to the cluster.

Network Formation and Configuration

You must have a sufficient number of IP addresses available when you create clustered mailbox servers in an SCC on Windows Server 2008. Windows Server 2008 failover clustering introduces new networking capabilities that are a major shift away from the way things have been done in legacy clusters. For example, Windows Server 2008 failover clusters introduce support for multiple subnets, support for Dynamic Host Configuration Protocol (DHCP) Internet Protocol version 4 (IPv4), and IPv6. When running in a Windows Server 2008 failover cluster, Exchange 2007 Service Pack 1 (SP1) includes support for geographically dispersed clusters for failover across two subnets. This support includes both SCCs, as well as Mailbox servers in a cluster continuous replication (CCR) environment.

Note

Although DHCP IPv4 is supported in Windows Server 2008 failover clusters, we recommend using static IP addresses in production environments. If DHCP IPv4 is used in a failover cluster, we recommend that you configure the DHCP servers to grant leases of unlimited length.

Beginning with Windows Server 2008 failover clustering, individual cluster nodes can now be located on separate, routed networks. This requires that resources that depend on IP Address resources (for example, Network Name resources), implement an OR logic because it is unlikely that every cluster node will have a direct local connection to every network that the cluster knows about. This facilitates IP Address and Network Name resources coming online when services or applications fail over to remote nodes.

All IP addresses associated with a Network Name resource are dynamically registered in Domain Name System (DNS) (if configured for dynamic updates) with the list ordered such that those IP Address resources that are online are returned first to the clients. Because cluster nodes can be placed on different, routed networks, and the communication mechanisms have been changed to use reliable session protocols implemented over User Datagram Protocol (UDP) (unicast), the networking requirements for geographically dispersed clusters are no longer applicable. As a result, organizations can deploy a failover cluster across two physical datacenters without having to use virtual LAN (VLAN) technology to span the cluster subnets across the two locations.

When a move or a failover occurs for a clustered mailbox server deployed in a geographically dispersed, multiple subnet failover cluster, the name of the clustered mailbox server is maintained, but the IP address assigned to that name is not maintained. The availability of this server to clients and other servers depends on propagation of the new IP address throughout DNS. It may take some time for DNS propagation to occur. For this reason, we recommend configuring a Time to Live (TTL) value for the clustered mailbox server DNS host record to a value of 10 minutes.

Although internal Microsoft Office Outlook clients do not need new or reconfigured profiles to connect using the new IP address, they must wait for their local DNS cache to be cleared so that name resolution of the clustered mailbox server's name will move from its old IP address to its new IP address. After the IP address has been propagated to the appropriate DNS servers, the DNS cache on the Outlook clients can be cleared by using the following command at the command prompt on the client:

ipconfig /flushdns

IP addresses are required for both the private and public networks. Requirements related to private and public addresses are as follows:

  • Private addresses   Each node requires one IP address for each network adapter that is used for the cluster private network. You can use a static IPv4 address or a dynamically assigned IPv6 address. You must use 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.10 and 10.10.10.11 with a subnet mask of 255.255.255.0 as the private IP addresses for the nodes.

  • Public addresses   Each node requires one IP address for each network adapter that is used for the cluster public network, sometimes referred to as a mixed network. Additionally, 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 IP addresses that are not on the same subnet or network as one of the private networks. You can use static IPv4 addresses, DHCP IPv4 addresses, or static IPv6 addresses.

    Important

    All network adapters for a cluster network must use the same version of TCP/IP, that is, they must all use IPv4, all use IPv6, or all use both IPv4 and IPv6.

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. As an 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   For an example address range and subnet mask for the private network interfaces on a two-node failover cluster, see the following table.

    Address ranges and subnet masks for private network interfaces

    Network / Node IP address range Subnet mask

    Private / NODE1

    10.10.10.10-255

    255.255.255.0

    Private / NODE2

    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 a 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 configured only for cluster use. For more information about this configuration, see the section "Configuring the Cluster Networks" later in this topic.

  • 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.

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 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 failover cluster for an SCC using the instructions in How to Create a Windows Server 2008 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. Before you add 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. For detailed steps about how to add a second and subsequent node to the cluster, see How to Create a Windows Server 2008 Failover Cluster for a Single Copy Cluster.

Configuring the Cluster Networks

After all nodes have been added to the cluster, the cluster networking components must be configured. Specifically, you must configure networks for cluster and client access, and you must configure tolerance settings for missed cluster heartbeats. We also recommend that you rename the cluster networks with more meaningful names.

The following table details the available options for configuring cluster networks.

Options for configuring cluster networks

Option Description

Allow the cluster to use this network (private network)

Select only this option if you want the Cluster service to use exclusively this network for inter-node cluster communication traffic. Clients will not be able to connect to the clustered mailbox server using this network.

Allow the cluster to use this network and allow clients to connect through this network (mixed network)

Select both of these options if you want the Cluster service to use the network adapter for the cluster heartbeat and for communication with external clients. The Cluster service will use this network for inter-node cluster communication, and clients will be able to connect to the clustered mailbox server using this network.

Do not allow the cluster to use this network (unmanaged network)

Select only this option if you do not want to use the network in the cluster, or have the Cluster service manage the network. The Cluster service will not be able to use this network for inter-node cluster communication, and clients will not be able to connect to the clustered mailbox server using this network.

Note

One option for configuring cluster networks is to create a preliminary network configuration and then run the Validate a Configuration wizard in the Failover Cluster Management tool with only the Network tests selected (for example, skip the Inventory, Storage, and System Configuration tests). When only the Network tests are run, the process does not take a long time. Using the validation report, you can make any corrections still needed in the network configuration. After the entire cluster has been configured, we recommend that you rerun the Validate a Configuration wizard and select all tests.

Clustered mailbox servers deployed in an SCC require at least two network cards in each node to be supported. In an SCC, you must configure one network as a private network and the other network as a mixed network.

Configuring Tolerance Settings for Missed Cluster Heartbeats

After cluster communications and network priority have been configured, we recommend that you configure specific tolerance settings for missed cluster heartbeats. Doing so configures the Cluster service monitoring of network connectivity between cluster nodes to be tolerant of minor interruptions. This prevents failovers in some cases where the network outage is brief. We recommend that you configure private and mixed cluster networks on all nodes to account for 10 missed heartbeats. This setting level corresponds to approximately 12 seconds.

For detailed steps about how to configure the cluster networking components, see How to Configure the Cluster Networks for a Single Copy Cluster.

Configuring the Cluster Quorum

After the cluster networks have been configured, the next step is to configure the failover cluster to use a Node Majority with Disk Witness Quorum resource. For detailed steps about how to configure a failover cluster to use the Node Majority with Disk Witness Quorum model, see How to Configure the Node and Disk Majority Quorum.

Validating the Failover Cluster

Windows Server 2008 includes a new wizard called the Validate a Configuration wizard that can be used to verify the health and configuration of a failover cluster. We recommend running this wizard prior to installing Exchange 2007 in the cluster. By running this wizard before you install Exchange 2007, you can identify and address configuration problems within the cluster that might prevent Exchange Setup from running correctly.

The Validate a Configuration wizard includes four groups of tests that are designed to verify that the cluster meets the requirements necessary to be supported by Microsoft. These are requirements that are in addition to the requirement that the cluster solution carry the "Designed for Windows Server 2008" compatibility logo.

The four groups of tests are: Inventory, Network, Storage, and System Configuration. For detailed steps about how to validate the failover cluster, see How to Validate a Failover Cluster Configuration for a Single Copy Cluster.

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, and after the cluster has been configured to use the Node and Disk Majority Quorum resource, you should first install the Mailbox server role on the active node. 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 2008.

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. For detailed steps about how to install the Mailbox server role on the passive node, see How to Install the Passive Clustered Mailbox Role in a Single Copy Cluster on Windows Server 2008.

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.

An SCC 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 make sure 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.

Post-Setup Tasks

After the Mailbox server role has been installed on both nodes, and a clustered mailbox server has been created, you should perform some post-setup tasks. These tasks include verifying the ability to move a clustered mailbox server between the nodes in the 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 the health and status of the clustered mailbox server, and that all nodes are correctly configured to support the clustered mailbox server.

The recommended way to verify the health and status of the clustered mailbox server is to run the Get-ClusteredMailboxServerStatus cmdlet. The Get-ClusteredMailboxServerStatus cmdlet provides basic operational status for the clustered mailbox server. For detailed steps about how to obtain basic operational status for a clustered mailbox server, see How to View the Status of a Clustered Mailbox Server.

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. In Exchange 2007 SP1, you can also use the Manage Clustered Mailbox Server wizard in the Exchange Management Console to move a clustered mailbox server between nodes to verify that both nodes can bring the clustered mailbox server online.