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.

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.

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.

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.

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.

Note:
Moving a CMS between nodes results in a brief interruption in service. In addition, any backups of any storage groups on the CMS are canceled.

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.

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.

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.

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.