Managing Single Copy Clusters

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

In addition to the tasks for day-to-day management and administration of an Exchange organization, there are tasks that are specific to a single copy cluster (SCC).

The administrative tasks for an SCC are:

• Managing disk resources.

• Managing storage groups and databases.

• Viewing SCC and clustered mailbox server (CMS) status and configuration settings.

• Managing the cluster or CMS, such as stopped and starting the CMS, and performing maintenance on the cluster.

Unlike previous versions of Microsoft Exchange Server, in which Cluster Administrator was used for many administrative tasks, many of the management tasks for an SCC involve using the Exchange Management Console or the Exchange Management Shell. There are, however, some management tasks that require Cluster Administrator or the Cluster.exe command-line management interface.

Managing Disk Resources

An SCC uses shared storage to host all storage group data. Shared storage must be available to all servers that are configured to host the CMS and be properly integrated into the CMS resource model. In some cases, you may need to add new storage to an existing configuration. In other cases, the storage that will be used was previously used by another CMS. The topic How to Add a Physical Disk Resource to a Single Copy Cluster provides a procedure for how to add a new disk resource into a CMS resource model.

After any configuration change, you are advised to verify that the proper dependencies and configuration settings are in place. The topic How to Configure Disk Dependencies for a Single Copy Cluster on Windows Server 2003 describes this procedure.

If it is necessary to manage disk volumes in an SCC, the databases in the storage group should be dismounted. For detailed steps about how to dismount a database, see "Mounting and Dismounting Databases" later in this topic.

Managing Storage Groups and Databases

There are a variety of administrative tasks that you may perform that are related to the storage groups and databases on the CMS in your SCC. These tasks include creating and removing databases and storage groups, mounting and dismounting databases, and relocating storage group data by moving log files, system files, or database files to a new location. In an SCC, several of these tasks require that the shared disk configuration be changed or that the CMS resource model be updated.

Creating and Removing Databases

The process for both creating and removing databases in an SCC is identical to the process used in a stand-alone configuration, except that physical disks may need to be added to or deleted from the CMS resource model.

For detailed steps about how to create a new public folder database, see How to Create a New Public Folder Database. For detailed steps about how to update the cluster resource model, see How to Configure Disk Dependencies for a Single Copy Cluster on Windows Server 2003.

To remove a mailbox database, all mailboxes must first be disabled or removed from the database. To remove a public folder database, all content must first be removed from the database. For detailed steps about how to remove a public folder database, see How to Remove a Public Folder Database.

If the physical disk for the database will not be immediately reused by the CMS, it should be removed from the CMS resource model. This can be accomplished by following the steps in How to Remove a Physical Disk Resource from a Clustered Mailbox Server. For detailed steps about how to update the cluster resource model, see How to Configure Disk Dependencies for a Single Copy Cluster on Windows Server 2003.

Creating and Removing Storage Groups

The process for both creating and removing storage groups in an SCC is identical to the process used in a stand-alone configuration, except that physical disks may need to be added to or deleted from the CMS resource model. For detailed steps about how to create a new storage group, see How to Create a New Storage Group. For detailed steps about how to remove a storage group, see How to Remove a Storage Group. For detailed steps about how to update the cluster resource model, see How to Configure Disk Dependencies for a Single Copy Cluster on Windows Server 2003.

Mounting and Dismounting Databases

It may occasionally be necessary to mount or dismount databases in an SCC environment. The process for mounting and dismounting databases in an SCC environment is identical to the process for mounting and dismounting databases on any computer running Exchange 2007. For detailed steps about how to mount a database, see How to Mount a Database. For detailed steps about how to dismount a database, see How to Dismount a Database.

Moving the Location of a Storage Group or Database

It may be necessary to move the location of storage group files or the location of a database in an SCC. The time to move the file locations depends on the size of the database being moved, the number of transaction log files being moved, and the rate of transfer for the disk operations. During any move, the database is dismounted. In an SCC, relocating a storage group may require that the shared disk configuration be changed or that the CMS resource model be updated.

For detailed steps about how to change the location of storage group log files or system files, see How to Move a Storage Group in a Single Copy Cluster. For detailed steps about how to change the location of a database, see How to Move a Database in a Single Copy Cluster.

Viewing Status and Configuration Settings

After an SCC configuration is deployed, you can use the Exchange Management Console and the Exchange Management Shell to view the configuration settings for storage groups and databases on the server. Configuration information includes the locations for the storage group and database files. For detailed steps about how to view SCC storage group configuration information, see How to View Storage Group Configuration in a Single Copy Cluster.

For detailed steps about how to view SCC database configuration information, see How to View Database Configuration in a Single Copy Cluster.

For detailed steps about how to view and change SCC physical disk dependencies and configuration settings, see How to Configure Disk Dependencies for a Single Copy Cluster on Windows Server 2003.

In addition, you can also review CMS status by using the Exchange Management Shell. For detailed steps about how to view the current status of a CMS in an SCC, see How to View the Status of a Clustered Mailbox Server in a Single Copy Cluster.

Managing Clustered Mailbox Servers

In addition to configuring disk resources and dependencies for storage groups and databases, the three other primary administrative tasks for managing a CMS in an SCC are bringing a CMS online, taking it offline, and moving a CMS between nodes in the cluster. Managing a CMS can also involve shutting down or restarting one of the nodes in the cluster as part of update management or other maintenance operations.

Moving a Clustered Mailbox Server Between Nodes

Manually moving a CMS between nodes is called a handoff or scheduled outage. When performing a handoff of a CMS in an SCC, we recommend that you use the Move-ClusteredMailboxServer cmdlet instead of the Failover Cluster Management tool (Windows Server 2008), Cluster Administrator (Windows Server 2003), or Cluster.exe in either operating system, because the cmdlet enables you to specify a reason for the handoff. In Exchange 2007 SP1, you can also use the Manage Clustered Mailbox Server wizard in the Exchange Management Console to perform a handoff of a CMS.

When moving a CMS in a failover cluster in which there is network latency between the nodes, we recommend performing the move operation from the passive node.

Starting and Stopping Clustered Mailbox Servers

The Failover Cluster Management tool (Windows Server 2008), Cluster Administrator (Windows Server 2003), and the Cluster.exe command-line tool have the ability to bring resources online and take resources offline. Taking a CMS offline is called stopping and bringing a CMS online is called starting.

The recommended way to start a CMS is to use the Start-ClusteredMailboxServer cmdlet. The recommended way to stop a CMS is to use the Stop-ClusteredMailboxServer cmdlet. In Exchange 2007 SP1, you can also use the Manage Clustered Mailbox Server wizard in the Exchange Management Console to start or stop a CMS.

For detailed steps about how to bring a CMS in an SCC online, see How to Start a Clustered Mailbox Server in a Single Copy Cluster. For detailed steps about how to take a CMS in an SCC offline, see How to Stop a Clustered Mailbox Server in a Single Copy Cluster.

Performing Maintenance on the Cluster

Maintenance should always be performed on the passive node in the cluster. Updates, hotfixes, and other applications generally should not be installed on the active node (a node that currently owns a CMS). For detailed steps about how to install Exchange update rollups in an SCC, see Applying Exchange 2007 Update Rollups to Clustered Mailbox Servers.

If maintenance needs to be performed on the active node, the CMS should first be moved to a passive node using the Move-ClusteredMailboxServer cmdlet. After moving the CMS, the previously active node becomes the passive node, and the previously passive node is now the active node. Maintenance can then be performed, and a handoff can be performed that moves the CMS in the opposite direction.

An SCC allows you to schedule a system outage of a specific node without an outage of the CMS. In a two-node SCC, only one node can be taken offline at a time if you need to maintain service and data availability. Taking both nodes offline will result in an interruption in service.

A scheduled outage is initiated via the Exchange Management Shell Move-ClusteredMailboxServer cmdlet. The topic How to Move a Clustered Mailbox Server in a Single Copy Cluster provides a procedure to perform a scheduled outage.

Before shutting down or restarting any node in an SCC, we recommend that you verify which node is currently hosting the CMS. This information can be obtained by using the Get-ClusteredMailboxServerStatus cmdlet.

Shutting Down Nodes in the Cluster

If all of the nodes in the cluster need to be shut down, including all active nodes, you must first stop the CMS. The Windows shutdown process is not Exchange-aware. Therefore, we recommend that you only shut down passive nodes. If an active node needs to be shut down or restarted, we recommend that you move the CMS to another available node. For detailed steps that explain how to move a CMS to another node, see How to Move a Clustered Mailbox Server in a Single Copy Cluster.

If the CMS cannot be moved to the passive node (perhaps because the passive node has already been shut down), we recommend that you stop it (take it offline) prior to shutting down the active node. For detailed steps about how to take a CMS in an SCC offline, see How to Stop a Clustered Mailbox Server in a Single Copy Cluster.

If you need to restart or shut down the active node and you cannot move the CMS to the passive node, we recommend that you use Group Policy to make sure that the CMS is stopped before restarting or shutting down an active node. Windows Server provides a set of policy-driven computer shutdown scripts that you can manage by using the Group Policy snap-in. The Group Policy snap-in includes extensions that enable you to specify a script that runs when you shut down the computer. These scripts run under the Local System account. For example, you can create a shutdown script that runs the Move-ClusteredMailboxServer cmdlet or the Stop-ClusteredMailboxServer cmdlet, with the appropriate parameters. We also recommend using a shutdown script because it minimizes the chance that the system will be shut down or restarted by an administrator who is not aware of the need to move or stop the CMS before shutting down the active node.