Adjusting Exchange DAG Heartbeat Settings

On a high latency network, it may be necessary to adjust the heartbeat settings of the DAG cluster. This is likely the case if your DAG spans multiple sites.

There are four cluster properties that we need to be aware of in the case of a DAG running on a high latency network.


The *SubnetDelay property is how often the cluster heartbeats are sent between DAG nodes. The default setting here for both same subnet and cross subnet is 1000ms. The max for same subnet is 2000ms while the max for cross subnet is 4000ms.

The *SubnetThreshold property is how many of the heartbeats can be missed before the node is considered failed and a DAG failover is initiated. The default settings for both same and cross subnet is 5. and the max setting for both is 120.

So the default settings allow a 5 second delay before the DAG failover will be initiated. (1×5). So for our example, if we want to increase that value to 40 seconds because our DAG spans multiple sites across several subnets, then we would set the properties as follows:

SubnetThreshold=20      (2×20 = 40)

There are two ways to change these settings. Using cluster.exe or using the PowerShell commandlet Get-Cluster. In my example I used powershell as cluster.exe is depreciated as of Server 2008 R2. However, I have still provide the cluster.exe syntax.

To list the current settings, run one of the following.

C:\>Cluster /cluster:clustername /prop


[PS] C:\>Get-Cluster | fl *
To change the property settings you can run the following commands.
C:\>Cluster /Cluster:clustername /prop CrossSubnetDelay=2000
C:\>Cluster /Cluster:clustername /prop CrossSubnetThreshold=20


[PS] C:\>(get-cluster).CrossSubnetDelay=2000
[PS] C:\>(get-cluster).CrossSubnetThreshold=20

Once you have changed the properties as desired, you can run the following command to verify the settings.

[PS] C:\> Get-Cluster | *subnet*

These settings are replicated instantly across the DAG members and there is no need to reboot. Remember to make smaller changes and test to ensure you don’t put yourself in a bad situation when it comes to a DAG failover.