Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1
Topic Last Modified: 2007-08-13
Use the Clustered Mailbox Server tab to view details and state information for a clustered mailbox server. This tab can also be used to configure database mount behavior for clustered mailbox servers in a cluster continuous replication (CCR) environment. This tab has two primary areas: Details and Failover Availability.
The Details area displays read-only information that provides the following basic details for a clustered mailbox server:
- Redundant machines Provides a list of
nodes in the failover cluster that are possible owners of the
clustered mailbox server.
- Storage type Indicates whether the
cluster is using shared storage or storage that is not shared.
Single copy clusters (SCC) use shared storage. CCR environments use
storage that is not shared (for example, storage that is directly
connected to each node and not managed by the Cluster service).
- State Indicates the current online or
offline state of the clustered mailbox server. Possible state
- Online The clustered mailbox server and
all storage groups and databases are online and mounted.
- Partial Online One or more resources in
the group containing the clustered mailbox server are in an offline
or failed state.
- Offline The clustered mailbox server
and all storage groups and databases are offline.
- Online The clustered mailbox server and all storage groups and databases are online and mounted.
- Operational machines Lists all of the
current nodes in the failover cluster, including nodes that may or
may not be possible owners of the clustered mailbox server. This
list also identifies which nodes are active nodes, and which node
currently owns the cluster quorum resource.
|Detailed information about a clustered mailbox server, including continuous replication-related information that is not visible in the Exchange Management Console, can also be viewed using the Get-ClusteredMailboxServerStatus cmdlet in the Exchange Management Shell. For more information about this cmdlet, see Get-ClusteredMailboxServerStatus.|
The Failover Availability area allows you to view and configure database mount behavior for clustered mailbox servers in a CCR environment. The behavior is controlled by a setting called Auto database mount dial. Possible settings for this dial include:
- Lossless When the attribute is set to
Lossless, under most circumstances the system waits for the failed
node to come back online before databases are mounted. Even then
the failed system must return with all logs accessible and not
corrupted. After the failure, the passive node is made active, and
the Microsoft Exchange Information Store service is
brought online. It checks to see if the databases can be mounted
without any data loss. If they can, the databases are mounted. If
not, the system periodically attempts to copy the logs. If the
server returns with its logs intact, this attempt will eventually
succeed, and the databases will mount. If the server returns
without its logs intact, the remaining logs will not be available,
and the affected databases will not mount.
Note: At any time after the failover is complete, an administrator can intercede and decide to mount using the databases and logs available on the previously passive node. This task is done using a simple two-step process. Presumably, the administrator making the decision to intercede bases the decision on an analysis of the amount of time required to get the original server operational. The consistency of the replication between the two nodes at the time of the failure, and the urgency of the clients to gain access to their server, are some factors that are part of this analysis.
- Good availability Good availability
provides fully automatic recovery when replication is operating
normally and replicating logs at the rate they are being
- Best availability Best availability,
which is the default setting, operates similarly to Good
availability, but it allows automatic recovery when the replication
experiences slightly more latency. Thus, the new active node might
be slightly farther behind the state of the old active node after
the failover, thereby increasing the likelihood that database
divergence occurs, which requires a full reseed to correct.
|The Auto database mount dial setting can also be viewed and configured using the Set-MailboxServer cmdlet in the Exchange Management Shell. For more information about this cmdlet, see Set-MailboxServer. For detailed steps about how to view and configure the Auto database mount dial setting using the Exchange Management Shell, see How to Tune Failover and Mount Settings for Cluster Continuous Replication.|