Share via

Exchange 2010:- DAG member evicted from cluster

  • Article

As an Exchange Admin, the last thing you want is a DAG that is not functioning correctly. A client recently experienced a problem whereby they were trying to add another copy to a DAG and after a short period of time the following events were logged in the System Log before the seeding of the Exchange database crashes and the VM stops network comms:

  • Event ID 1135 - FailoverClustering
  • Event ID 1126 - FailoverClustering
  • Event ID 1129 - FailoverClustering

Here are some screenshots of the errors:



What caught my attention was Event ID 1135.

To "fix" the issue, the following changes were done on the Servers:

  • Disable TCP Chimney
  • Disable NetDMA
  • Set the timeout value for the cluster
  • Set the threshold value for the cluster

Let's take a look at the cluster settings, to set this you can run the 2x commands from PowerShell or CMD, remember to start them elevated:

  • cluster /prop SameSubnetDelay=2000
  • cluster /prop SameSubnetThreshold=10

The next step is to disable TCP Chimney on Server 2008 R2, to do so you can run the following command:

  • netsh int tcp set global chimney=disabled

To validate that it is indeed disabled, you can run the following command on the same Elevated prompt you opened earlier:

  • netsh int tcp show global

Lastly, you can now disable NetDMA, these steps were taken from Microsoft's site: (URL)

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate the following registry subkey, and then click it:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  3. Double-click the EnableTCPA registry entry.
    Note If this registry entry does not exist, right-click Parameters, point to New, click DWORD Value, type EnableTCPA, and then press ENTER.
  4. To enable NetDMA, type 1 in the Value data box, and then click OK.
  5. To disable NetDMA, type 0 in the Value data box, and then click OK.
  6. If the EnableTCPA registry entry does not exist, enable the NetDMA functionality.

After all the above was complete, the server was given a reboot and the Reseed started again. The system logs on both servers were clean, none of the above events were logging again.