By default, an Exchange 2003 server monitors the MTA service. In a cluster environment, MTA runs only on one of the physical nodes (computers). As a result, the monitoring process will report that any nodes not running the MTA service are in an error state. This, in turn, can cause problems if Exchange 2003 is installed in a cluster with two or more Exchange Virtual Servers.

To prevent the monitoring process from incorrectly reporting that Exchange Virtual Servers that are not running the MTA service are in an error state, you should disable MTA monitoring on the second Exchange Virtual Server (and if applicable, any other additional Exchange Virtual Servers) of a cluster. For detailed steps, see How to Disable MTA Monitoring on an Exchange Virtual Server.

Note:
You do not need to disable MTA monitoring on the first Exchange Virtual Server of a cluster.

IIS SMTP protocol virtual servers create and populate log files that are used to gather statistical data on server usage. SMTP logging is not enabled by default, because it reduces Exchange performance. When enabled, IIS creates log files on the system drive of the local computer (such as C:\Windows\System32\Logfiles, where C is the drive letter for your system drive).

To reliably configure IIS SMTP logging, you must specify a folder on a shared disk. For detailed instructions, see How to Enable SMTP Logging and Log the Files to a Shared Disk.

One of the limitations of Windows 2000-based server clusters is that they have no mechanism for a conditional failover. For example, you cannot configure an Exchange Virtual Server to move to one node when one failure occurs and to a different node when another failure occurs. Nor can you configure an Exchange Virtual Server to fail over to a second node in the event that the first node is too busy. In Windows Server 2003 clusters, this limitation is addressed with a new cluster group property named AntiAffinityClassNames. The value for this property is any arbitrary string. However, this string is often program-specific. For example, Exchange 2003 sets this value to Microsoft Exchange Virtual Server.

AntiAffinityClassNames are used to designate a node as a possible owner for a particular resource group in a cluster containing three or more nodes. In a Windows Server 2003 cluster, if a resource failure occurs that affects the resource group, Failover Manager checks the value for AntiAffinityClassNames. For example, when an Exchange Virtual Server resource fails, the cluster failover manager determines if resource groups on any one of the other nodes, designated as possible owners of the Exchange Virtual Server, have Microsoft Exchange Virtual Server set as the value for the AntiAffinityClassNames property. Only nodes that currently contain an Exchange Virtual Server have this value set. Therefore, a node without this value is the best possible destination for the group with the failed resource.

The following scenarios demonstrate how the AntiAffinityClassNames property can be used:

• The property can be used in an N+1 Exchange server cluster. In this case, Exchange should set up each group that supports a partition with the AntiAffinityClassNames property set to an Exchange-specific value (the same value for each group). If there is a failure, the failover manager can attempt to keep the partitions apart by selecting nodes that do not contain groups with the same AntiAffinityClassNames value of Exchange Virtual Server.
  
• The property can be used in a server consolidation in which there are multiple programs that should be kept apart. In these cases, the groups that represent the various programs should be manually modified with the same value in the AntiAffinityClassNames property.
  

This property can only be configured using the CLUSTER.EXE command-line tool. An example of the proper syntax for the example that is listed in the first preceding scenario is:

cluster group "Name of Group" /prop AntiAffinityClassNames="Microsoft Exchange Virtual Server"

This command creates the following registry key:

After this property is set, failover and failback policies are configured using the Best Possible option in Cluster Administrator, instead of specifying specific nodes for a policy. For more information, see Microsoft Knowledge Base article 299631, "Failover Behavior on Clusters of Three or More Nodes."

Prior to Service Pack 1, Exchange 2003 clusters can only accommodate one public MAPI information store, also referred to as a public folder database, per cluster. This design prevents problems if the cluster fails over to another server in an active/active cluster. Because Exchange 2003 must run in an active/passive configuration whenever there are more than two nodes present in the cluster, you cannot encounter a scenario in which a single Store.exe process must cope with multiple public MAPI information stores from the same TLH. Therefore, with Exchange 2003 Service Pack 1, the existing public MAPI information store limitation in the cluster is removed. Installations running SP1 or later are restricted to one public MAPI information store per Exchange Virtual Server (the same restriction that is imposed on stand-alone Exchange 2003 servers).

You must give special consideration when you run the Eseutil database integrity utility with the /CC switch. This switch is used to perform a hard recovery of an Exchange information store. Hard recovery is the process through which you apply transaction logs and database patch files to a database that has been restored from online backup. For more information, see Microsoft Knowledge Base article 266689, "XADM: The 'ESEUTIL /CC' Command Does Not Work on Cluster Server."

Before installing any updates on your Exchange cluster nodes, read the README file that is included with the service pack, hotfix, or update. In most cases, the passive node of the cluster is updated first. Exchange Virtual Servers are then moved to the passive node, and then the other node is updated. You should never install any update on more than one node at a time.