Exch Cluster Checklist Note

Exchange Server 2003 Cluster Configuration
Checklist
Note on IT
Published: June 2004
The Microsoft IT group regularly interacts with enterprise customers in sharing its
experiences and best practices for the deployment and operations of products such
as Microsoft® Exchange Server 2003. In many of these customer contacts, Microsoft
IT personnel have noted a number of configuration issues that repeatedly appear,
especially with running Exchange on clustered servers. This Note is intended to help
enterprise organizations that are running clustered Exchange servers avoid the most
common problems, thereby improving the reliability and efficiency of their Exchange
environments.
Document Definition
A Note on IT is a short, technically deep
drilldown on a specific topic related to
Microsoft IT and is usually associated with
Introduction
an existing IT Showcase document. A Note The Microsoft IT group uses Microsoft Windows Server™ 2003–based clustered servers in
might illustrate how Microsoft IT performs a its Exchange Server 2003 environment. The use of clustered Exchange servers is discussed
specific operational task step by step or
configures a hardware device or software at a high level in the IT Showcase white paper Exchange 2003 Design and Architecture at
application. It might also relate details of a Microsoft, available at
best practice or contain key information http://www.microsoft.com/technet/itsolutions/msit/deploy/ex03atwp.mspx.
about Microsoft IT’s operations that is
regularly requested by customers. This document consists of best-practice configuration settings—in checklist form—that
Intended Audience support the clustered Exchange environment at Microsoft. The configuration settings
Microsoft Exchange Server 2003 described in this document are specific to the Microsoft environment. However, customers
administrators, system architects, and that are using Exchange on clustered servers are likely to find ideas and scenarios in this
messaging support personnel. document that are similar to their own environments and may benefit from adopting some
Products & Technologies form of these best practices.
• Microsoft Windows Server 2003 This document assumes that readers are either Exchange architects or technical
• Clustered servers
implementers and are already familiar with Exchange Server 2003 and Windows Server 2003
• Exchange Server 2003
clusters.
Note: For security reasons, any sample names of forests, domains, internal resources,
organizations, and internally developed applications and files used in this document do not
represent actual names used within Microsoft and are for illustration purposes only. In
addition, the contents of this document describe how Microsoft IT runs its enterprise data
center. The procedures and processes included in this document are not intended to be
prescriptive guidance on how to run a generic data center and may not be supported by
Microsoft Customer Service and Support.
With the exception of one remotely located mailbox server that supports approximately 500
users, Microsoft IT has deployed all of its corporate mailboxes on clustered Exchange
servers by using a multinode configuration that runs Windows Server 2003 and Exchange
Server 2003. The largest of these multinode clusters is based on a seven-node design that
supports 16,000 200-megabyte (MB) mailboxes across four Exchange virtual server
instances. These Exchange virtual instances each run on a designated active (A) node and
share a single dedicated primary passive (P) node as a target for failover. The clusters
maintain additional lower-end servers that act as alternate passive (p) nodes. The seven-
node cluster is abbreviated as AAAAPpp.
The alternate passive nodes support two functions. The primary function is to offload backup
content to tape as part of a two-stage backup process. The secondary function is to serve as
potential, albeit lower-priority, failover targets for the Exchange virtual instances in the
cluster.
Note: For more information about how Microsoft IT backs up its Exchange servers, see the
IT Showcase technical case study “Messaging Backup and Restore at Microsoft,” available
at http://www.microsoft.com/technet/itsolutions/msit/operations/msgbrtcs.mspx and the IT
Showcase technical note on IT “Backup Process Used with Clustered Exchange Server 2003
Servers at Microsoft,” available at http://www.microsoft.com/downloads/details.aspx?
FamilyId=63FA9270-563F-4627-A0A0-8A07E02CF9BF&displaylang=en.
Cluster Naming Convention

The naming convention for server clusters in the Exchange Server 2003 environment at
Microsoft includes three specific parts: xxx-yyyy-n. This convention allows for easy
recognition of locations, roles, and iterations in a cluster. In this naming convention:
• The xxx part represents the geographic location of the server or Exchange virtual
instance.
• The yyyy part identifies the default role of the server or Exchange virtual instance in the
cluster.
• The n part is the numeric representation of the server or Exchange virtual instance in the
cluster.
The cluster component names in Table 1 represent the server roles and functions referenced
in this document.
Table 1. Cluster Component Names
Name Description
RED-ACTV-0 Active node—supports first Exchange virtual instance *
RED-ACTV-1 Active node—supports second Exchange virtual instance *
RED-ACTV-2 Active node—supports third Exchange virtual instance *
RED-ACTV-3 Active node—supports fourth Exchange virtual instance *
RED-PASS-0 Primary passive node—primary target for failover of Exchange virtual instance *
RED-PASS-1 Alternate passive node—secondary target for failover of Exchange virtual instance *
RED-PASS-2 Alternate passive node—tertiary target for failover of Exchange virtual instance *
Exchange Server 2003 Cluster Configuration Checklist Page 2

Name Description
RED-MAIL-0 Resource group for first Exchange virtual instance **
RED-MAIL-1 Resource group for second Exchange virtual instance **
RED-MAIL-2 Resource group for third Exchange virtual instance **
RED-MAIL-3 Resource group for fourth Exchange virtual instance **
RED-BACK-0 Backup resource group for first Exchange virtual instance **
RED-BACK-1 Backup resource group for second Exchange virtual instance **
RED-BACK-2 Backup resource group for third Exchange virtual instance **
RED-BACK-3 Backup resource group for fourth Exchange virtual instance **
RED-MGMT-0 Resource group for cluster quorum management **
* Denotes a physical server.
** Denotes a cluster resource group.
Configuration Processes
The key configurations discussed in this document can be accessed through either a
standard Microsoft Windows® command prompt or a Windows user interface (UI) dialog box.
This document provides commands and relevant command switches that display current
configuration data. When possible, this document provides sample screenshots of dialog
boxes to illustrate a point or clarify readers’ understanding of configuration change
procedures.
Item 1: Disable Cluster Event Log Replication

Microsoft IT uses Microsoft Operations Manager (MOM) 2000 to support its worldwide server
monitoring requirements. This solution provides event-based monitoring, performance
trending, and a threshold mechanism to assist with proactive and reactive notification for
potential Exchange Server 2003 problems.
Clustering, by default, uses event log replication, which replicates all event occurrences from
one server node in a cluster to all other nodes in the same cluster. Event log replication could
result in excessive alert chatter to any event monitoring system whereby a single replicated
event could generate an alert from every server within the cluster.
To determine whether event log replication is currently enabled, start a command prompt
session on any node in the cluster, and then type the following command:
Cluster.exe /prop
In the case of Microsoft IT, the following data appears:
Name Value
--------------------------------------- -----------------------
AdminExtensions {FFFFFFFF-0000-FFFF-0000-FFFFFFFFFFFF}
DefaultNetworkRole 2 (0x2)
Description
Security 01 00 14 80 ... (148 bytes)
Security Descriptor 01 00 14 80 ... (148 bytes)

Groups\AdminExtensions {FFFFFFFF-0000-BBBB-1111-FFFFFFFFFFFF}
Networks\AdminExtensions
NetworkInterfaces\AdminExtensions
Nodes\AdminExtensions
Resources\AdminExtensions
ResourceTypes\AdminExtensions
EnableEventLogReplication 0 (0x0)
QuorumArbitrationTimeMax 60 (0x3c)
QuorumArbitrationTimeMin 7 (0x7)
DisableGroupPreferredOwnerRandomization 0 (0x0)
EnableEventDeltaGeneration 1 (0x1)
EnableResourceDllDeadlockDetection 0 (0x0)
ResourceDllDeadlockTimeout 240 (0xf0)
ResourceDllDeadlockThreshold 3 (0x3)
ResourceDllDeadlockPeriod 1800 (0x708)
ClusSvcHeartbeatTimeout 60 (0x3c)
HangRecoveryAction 2 (0x2)
The current status of EnableEventLogReplication appears approximately halfway down the

list. The associated value of the property name provides the status:
• 0 (0x0) indicates it is disabled

• 1 (0x1) indicates it is enabled.
Note: Extraneous data in the preceding sample list was removed to have the remainder
better fit within the page width.
The EnableEventLogReplication line in the sample list was intentionally made bold and
italic to help readers locate the data.
To disable event log replication in the cluster, start a command prompt session, and then
type the following command:
Cluster.exe /prop EnableEventLogReplication = 0
After changing the setting, retype the Cluster.exe /prop command to confirm that the
setting has been changed. This setting change is dynamic; no restart is required.
Item 2: Establish Rules for Properly Managing Failovers

At its headquarters data center, Microsoft IT uses a seven-node cluster configuration that
supports multiple active Exchange virtual instances. Microsoft IT configured each Exchange
virtual instance to support four Exchange storage groups, with each storage group supporting
five mailbox stores.
Each Exchange virtual instance runs on a preferred node in accordance with the following
sample naming convention:
• RED-MAIL-0 (Exchange virtual instance) runs on RED-ACTV-0 (cluster node).


Establishing a List of Preferred Owners

Each Exchange virtual instance has a list of preferred owners that defines its active cluster
node and its preferred failover targets, in order, within the cluster. For example, the list of
preferred owners for RED-MAIL-0 is defined as follows:
1. RED-ACTV-0 (cluster active node)
2. RED-PASS-0 (cluster passive node 0)
To display the currently configured list of preferred owners for an Exchange virtual instance,
start a command prompt session, and then type the following command:
Cluster.exe group <instance name> /listowners
In the case of Microsoft IT, the following data appears for resource group RED-MAIL-0:
Preferred Owner Nodes

---------------------
RED-ACTV-0
RED-PASS-0
RED-PASS-1
RED-PASS-2
To set the list of preferred owners for an Exchange virtual instance:
1. Start Cluster Administrator.
2. Right-click the relevant cluster resource group, and then click Properties.
3. On the General tab, click Modify.
4. In the Modify Preferred Owners dialog box, as shown in Figure 1, select a node and
click the Right arrow to move the node into the list of preferred owners to define failover
priority. Click the Up and Down arrows to change the order of preferred owners as
necessary.

Figure 1. Modify Preferred Owners dialog box
Establishing a List of Possible Owners

Microsoft IT prevents Exchange virtual server resources from failing over to non-preferred
active nodes by establishing a list of possible owners on the Exchange System Attendant
resource in each Exchange resource group. The list of possible owners ensures that the
relevant Exchange virtual server can become active only on its preferred active node and
relevant passive nodes.
To display the list of possible owners, start a command prompt session, and then type the
following command:
Cluster.exe res <resource group name> /listowners
In the case of Microsoft IT, the following data appears for resource group RM - System
Attendant:
Possible Owner Nodes

--------------------
RED-MAIL-0
RED-PASS-0
RED-PASS-1
RED-PASS-2
To set the list of possible owners for an Exchange resource:
2. Click to expand the resource group that has the relevant System Attendant resource that
you want to adjust.
3. Right-click the System Attendant resource, and then click Properties.
4. On the General tab, click Modify.
5. In the Modify Possible Owners dialog box, as shown in Figure 2, select a node and
click the Right arrow to move the node into the list of possible owners to define possible
failover targets. Click the Up and Down arrows to change the order of preferred owners
as necessary.

Figure 2. Modify Possible Owners dialog box
Verifying Exchange Cluster Group Affinity

Windows Server 2003 supports a new cluster group property called
AntiAffinityClassNames, which is useful in multinode cluster configurations. This setting
prevents an Exchange virtual instance from attempting to fail over to the same primary
passive node that another Exchange virtual instance is already using. Instead, the next
available passive node in the list of preferred owners is checked for an affinity conflict. If that
node does not have a conflict (that is, the node is not in use by another Exchange virtual
instance), it will be used for the failover.
The following sample scenario events demonstrate the benefit of cluster group affinity:
1. Exchange virtual instance RED-MAIL-0 has become active on node RED-PASS-0 due to
a fault condition that occurred on its preferred active node, RED-ACTV-0.
2. RED-ACTV-1 encounters a fault condition, which forces RED-MAIL-1 to move to a

passive target as assigned by the list of preferred owners.
3. The cluster detects an affinity conflict and prevents RED-MAIL-1 from attempting to
move to RED-PASS-0.
4. RED-MAIL-1 fails over to its next available target, RED-PASS-1.
To list the current affinity settings in the cluster, start a command prompt session, and then
Cluster.exe group <instance name> /prop
In the case of Microsoft IT, the following data appears for resource group RED-MAIL-0:
Resource Group Name Value

--------------- ----------------- -------------------
RED-MAIL-0 Name RED-MAIL-0
RED-MAIL-0 Description
RED-MAIL-0 PersistentState 0 (0x0)
RED-MAIL-0 FailoverThreshold 10 (0xa)
RED-MAIL-0 FailoverPeriod 6 (0x6)
RED-MAIL-0 AutoFailbackType 0 (0x0)

RED-MAIL-0 FailbackWindowStart 1111111111 (0xffffffff)
RED-MAIL-0 FailbackWindowEnd 1111111111 (0xffffffff)
RED-MAIL-0 LoadBalState 1 (0x1)
RED-MAIL-0 AntiAffinityClassNames Microsoft Exchange Virtual Server
Note: Extraneous data in the preceding sample list was removed to have the remainder
better fit within the page width.
The AntiAffinityClassNames line in the sample list has been intentionally made bold and
Item 3: Configure Cluster Network Properties

Properly configuring the cluster network properties is extremely important, because incorrect
settings can cause instability and performance degradation in the cluster. Microsoft IT
recommends checking that the network properties in the cluster are set to the following
configurations:
• Check that each network is set to support the correct role.

• Check that the network assigned to support private cluster communications has the
highest priority for the function.
Identifying the Status of All Available Networks

To identify the properties of all available networks, start a command prompt session, and
then type the following command:
Cluster.exe net
Network Status
-------------- ---------
Private Up
Private+Public Up
Identifying the Properties of All Available Networks

To identify the current properties of networks, start a command prompt session, and then
Cluster.exe net /prop
T Network Name Value

-- ------------------- ------------------ -----------------------
SR Private Name Private
SR Private Address 10.0.0.0
SR Private AddressMask 255.255.255.0
S Private Description
D Private Role 1 (0x1)
SR Private+Public Name Private+Public
SR Private+Public Address 192.168.1.10

SR Private+Public AddressMask 255.255.255.0
S Private+Public Description
D Private+Public Role 3 (0x3)
Notes: In the list of current properties, roles are identified by one of three values. Role 1 is a
dedicated private network used by the cluster only for private cluster communications. Role 2
is a public network used by end users only for client access. Role 3 is a mixed network used
for all communications, including node-to-node communications within a cluster as well as
client access.
The lines identifying the network role in the sample list has been intentionally made bold and
To set the properties for the networks:
2. Right-click the root of the cluster to be edited, and then click Properties.
3. From the cluster priorities dialog box, click the Network Priority tab. Right-click the
network to be edited (run this procedure for each network in the cluster). As an example,
the network properties dialog box for the private network appears, as shown in Figure 3.

Figure 3. Dialog box used for setting network properties of the Private network
4. For the Private network, click Internal cluster communications only (private
network). For the Private+Public network, click All communications (mixed network).
5. Click OK to close.
Setting the Priority Order of the Private Network

The cluster’s Private network supports the heartbeat mechanism that keeps the cluster
functioning correctly and efficiently. As such, the Private network should be assigned a higher
level of priority than the Private+Public network to manage the internal cluster
communications.
To assign the highest priority to the Private network communications for private cluster
communications, start a command prompt session, and then type the following command:
Cluster.exe /listnetpri
In the case of Microsoft IT, the following data appears, listing the priorities of all networks:
Priority Network Name

--------- --------------
1 Private
2 Private+Public

To configure the priorities for the networks that the cluster uses:
2. Right-click the root of the cluster to be edited, and then click Properties.
3. Click the Network Priority tab.
A properties dialog box for the Private network appears, as shown in Figure 4.
Figure 4. Dialog box used for setting network priority of the Private network
4. Click Private network, click Move Up to give it the highest priority, and then click OK.
Item 4: Set Network Bindings

It is important to set the network bindings on a cluster to ensure that the public-facing
network is bound to the top of the network stack.
Caution: Failure to implement this configuration setting may cause problems later when
Exchange is upgraded.
The following steps detail how to check the status of a network connection and, if necessary,
change the position of a network connection:

1. Start Network Connections.
2. Click the Advanced menu, and then click Advanced Setting. The Adapters and
Bindings tab indicates the priority status of the current network connections.
3. The Private+Public adapter, which supports all communications, should be bound to the
top of the stack, as shown in Figure 5. If it is not, click Private+Public, and then click the
upward arrow to the right of the list to promote it to the top of the stack. When you finish
this step, the Private adapter is bound at a lower priority than Private+Public.
Figure 5. Properly prioritized network connections
Item 5: Configure Network Adapter Settings

Microsoft IT forces the link type negotiation to 100 MB Full Duplex on all public-facing
network adapters (represented by the Private+Public network referenced earlier in this
document).
Microsoft IT highly recommends disabling “auto negotiation” on all public-facing networks to

prevent the potential for page pool depletion, which can result in system instability. The
adapters should be connected to a network switch configured to use the same negotiation
type on its ports.

Cluster communication problems can cause significant instability and are commonly the
result of network adapter configuration errors. If system event logs contain large numbers of
Error 1123 and Error 1122 events, link-type negotiation configuration problems are often the
culprit. These error event messages include similar data as shown in the following samples:
Error 1123:
Event Type: Warning

Event Source: ClusSvc
Event Category: Node Mgr
Event ID: 1123
Date: 9/3/2003
Time: 12:18:16 PM
User: N/A
Computer: RED-ACTV-1
Description: The node lost communication with cluster node 'RED-PASS-2'
on network 'Internal'.
Error 1122:
Event Type: Warning

Event Source: ClusSvc
Event Category: Node Mgr
Event ID: 1122
Date: 9/3/2003
Time: 12:18:19 PM
User: N/A
Computer: RED-ACTV-1
Description: The node (re)established communication with cluster node
'RED-PASS-2' on network 'Internal'.
When encountered, these errors are usually associated with poor network communications
caused by the Private or Private+Public network adapter not negotiating correctly.
Item 6: Define Which Resources Are Maintained in the Cluster

Quorum Resource Group
Microsoft IT recommends dedicating the cluster quorum resource group (in the case of
Microsoft IT, RED-MGMT-0) to support the following cluster management resources:
• The quorum resource

• A single physical quorum disk
• A dedicated Internet Protocol (IP) address
• The network name
• The Microsoft Distributed Transaction Coordinator (MS DTC) resource
The MS DTC resource is required for Exchange Server setup and subsequent updates in a
clustered environment.

Item 7: Establish Cluster Resource Restart Parameters
The default advanced behavior for all clustered resources is to restart if they enter a failed
state. If a resource fails more than three times within a period of 15 minutes, all resources in
the affected resource group will be forced to move to another node in the cluster.
Microsoft IT disabled this default advanced behavior to eliminate potential cluster instability
that may occur as a result of different types of resource failures. Figure 6 illustrates how to
configure the properties of a cluster resource to change this behavior.
Figure 6. Properties dialog box of a clustered resource
Mitigating Cluster Resource Instability

When non-critical resources, such as the “Exchange MS Search Instance,” enter a failed
state due to service instability, a repeated failed state could cause the associated Exchange
virtual instance to be taken offline. The failure of a non-critical resource is not essential for
typical Exchange operations. However, such a failure causes the entire Exchange virtual
instance to fail over to another node, thereby affecting users’ access to their mailboxes.
Another example of instability is when a physical disk resource fails due to spindle failure or
signature mismatch, resulting in all resources being taken offline and failing over to another
node in the cluster. The physical disk resource may fail to come back online after failover,

resulting in the potential for a cyclical bounce of the resource group between nodes in the
cluster.
To mitigate the potential for uncontrolled movement of a resource group between cluster
nodes, Microsoft IT clears the Affect the group option, as seen in Figure 6, on all resources.
This change will prevent any uncontrolled movement of a resource group between nodes as
a result of resource failures. However, it will not prevent the movement of a resource group to
an available node if an active node fails.
Microsoft IT also suggests reducing the number of restart Threshold settings to 1 on the
Exchange System Attendant and the information store resources. Microsoft IT bases this
suggestion on a conclusion that if either service fails to recover after the first attempt, it will
most likely also fail to recover after three attempts.
The implementation of these suggested changes requires the deployment of a reliable server
monitoring solution to ensure detection of individual resource problems, thereby enabling a
quick response to potential failures. Microsoft IT uses MOM 2000 to detect these conditions
and, when necessary, send an alert notification to Exchange administrators regarding
changes in the service state (such as stopped or pending offline) of a resource.
A predefined script, Service Verification Check Service script, is available in the MOM 2000
Exchange 2003 Management Pack under the Server Availability/Verify Exchange Services
processing rule group. This script can be adjusted to detect a status change on any service in
the cluster. The use of this script should be considered a basic requirement before the
implementation of any changes to the resource’s advanced parameters.
Warning: If an IT organization chooses to modify the advanced resource restart parameters

as described previously, the failed resource will not automatically fail over to another node in
the event of a failure. The resource will remain in a failed state and not resume service until
the problem is manually resolved. The ability to effectively react to issues as they occur,
thereby minimizing service outages, requires the implementation of server monitoring tools
with operator alert notification features and a support staff trained to use those tools.
Item 8: Set Cluster Resource Dependencies

Microsoft IT determined that the default cluster resource dependencies are adequate for
production clusters once consideration is given to ensuring a clean shutdown to the
Exchange Information Store.
Defining the dependency model helps eliminate the potential for database corruption as a
result of the Exchange Data and Log physical disk resources from entering an offline state
before the Exchange Information Store had cleanly shutdown.
The arrows in Figure 7 represent how the various resource dependencies are set against the
Exchange System Attendant resource.

Exchange
Multiple Protocol
Information Store
Resources
Resource
Exchange System
Attendant
Resource
Physical Disk Physical Disk

Network Name Resource Resource
Resource Storage Group 1 Storage Group 2
Log (mount point) Log (mount point)
Physical Disk Physical Disk

IP Address Resource Resource
Resource Storage Group 1 Storage Group 2
Data Data
Figure 7. Cluster resource dependency flow
Note: Microsoft IT uses volume mount points for their log drives in the Exchange clusters.
Each mount point is configured as a separate resource that is dependent on its parent
physical disk resource. For more information about how Microsoft IT uses volume mount
points with Exchange Server 2003 clusters, see the IT Showcase technical white paper
Exchange 2003 Design and Architecture, available at
http://www.microsoft.com/technet/itsolutions/msit/deploy/ex03atwp.mspx.
To list resource dependencies on the Exchange System Attendant resource, start a

command prompt session, and then type the following command:
Cluster.exe res "Exchange System Attendant" /listdep
In the case of Microsoft IT, the following data appears, listing all the cluster resource
dependencies on the Exchange System Attendant:
Resource Group Node Status

------------------------ ------------------- --------------- ------
Network Name RED-MAIL-0 RED-ACTV-0 Online
Storage Group 1 Log RED-MAIL-0 RED-ACTV-0 Online
Storage Group 1 Data RED-MAIL-0 RED-ACTV-0 Online
Storage Group 2 Log RED-MAIL-0 RED-ACTV-0 Online
Storage Group 2 Data RED-MAIL-0 RED-ACTV-0 Online
Note: This list is a shortened sample of the data typically provided by this command.

For More Information
For more information about Microsoft products or services, call the Microsoft Sales
Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information
Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your
local Microsoft subsidiary. To access information through the World Wide Web, go to:
http://www.microsoft.com
http://www.microsoft.com/itshowcase
http://www.microsoft.com/technet/itshowcase
For any questions, comments, or suggestions on this document, or to obtain additional

information about Microsoft IT Showcase, please send e-mail to:
showcase@microsoft.com
The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it
should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to
reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses,
logos, people, places and events depicted herein are fictitious, and no association with any real company,
organization, product, domain name, email address, logo, person, place or event is intended or should be
inferred.
© 2004 Microsoft Corporation. All rights reserved.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR
IMPLIED, IN THIS SUMMARY. Microsoft, Windows, and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual
companies and products mentioned herein may be the trademarks of their respective owners.

Exch Cluster Checklist Note

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Exch Cluster Checklist Note

Hochgeladen von

Copyright:

Verfügbare Formate

Exchange Server 2003 Cluster Configuration

Cluster Naming Convention

Table 1. Cluster Component Names

RED-ACTV-0 Active node—supports first Exchange virtual instance *

RED-ACTV-1 Active node—supports second Exchange virtual instance *

RED-ACTV-2 Active node—supports third Exchange virtual instance *

RED-ACTV-3 Active node—supports fourth Exchange virtual instance *

Exchange Server 2003 Cluster Configuration Checklist Page 2

RED-MAIL-0 Resource group for first Exchange virtual instance **

RED-MAIL-1 Resource group for second Exchange virtual instance **

RED-MAIL-2 Resource group for third Exchange virtual instance **

RED-MAIL-3 Resource group for fourth Exchange virtual instance **

RED-BACK-0 Backup resource group for first Exchange virtual instance **

RED-BACK-1 Backup resource group for second Exchange virtual instance **

RED-BACK-2 Backup resource group for third Exchange virtual instance **

RED-BACK-3 Backup resource group for fourth Exchange virtual instance **

RED-MGMT-0 Resource group for cluster quorum management **

* Denotes a physical server.

** Denotes a cluster resource group.

Item 1: Disable Cluster Event Log Replication

In the case of Microsoft IT, the following data appears:

Exchange Server 2003 Cluster Configuration Checklist Page 3

The current status of EnableEventLogReplication appears approximately halfway down the

• 0 (0x0) indicates it is disabled

Cluster.exe /prop EnableEventLogReplication = 0

Item 2: Establish Rules for Properly Managing Failovers

• RED-MAIL-0 (Exchange virtual instance) runs on RED-ACTV-0 (cluster node).

Exchange Server 2003 Cluster Configuration Checklist Page 4

Establishing a List of Preferred Owners

1. RED-ACTV-0 (cluster active node)

2. RED-PASS-0 (cluster passive node 0)

3. RED-PASS-1 (cluster passive node 1)

4. RED-PASS-2 (cluster passive node 2)

Cluster.exe group <instance name> /listowners

Preferred Owner Nodes

To set the list of preferred owners for an Exchange virtual instance:

1. Start Cluster Administrator.

3. On the General tab, click Modify.

Exchange Server 2003 Cluster Configuration Checklist Page 5

Establishing a List of Possible Owners

Cluster.exe res <resource group name> /listowners

Possible Owner Nodes

To set the list of possible owners for an Exchange resource:

1. Start Cluster Administrator.

3. Right-click the System Attendant resource, and then click Properties.

4. On the General tab, click Modify.

Exchange Server 2003 Cluster Configuration Checklist Page 6

Verifying Exchange Cluster Group Affinity

2. RED-ACTV-1 encounters a fault condition, which forces RED-MAIL-1 to move to a

4. RED-MAIL-1 fails over to its next available target, RED-PASS-1.

Cluster.exe group <instance name> /prop

Resource Group Name Value

Exchange Server 2003 Cluster Configuration Checklist Page 7

Item 3: Configure Cluster Network Properties

• Check that each network is set to support the correct role.

Identifying the Status of All Available Networks

In the case of Microsoft IT, the following data appears:

Identifying the Properties of All Available Networks

Cluster.exe net /prop

In the case of Microsoft IT, the following data appears:

T Network Name Value

Exchange Server 2003 Cluster Configuration Checklist Page 8