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)
- Click Start, click Run, type regedit, and then click OK.
- Locate the following registry subkey, and then click it:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters - 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. - To enable NetDMA, type 1 in the Value data box, and then click OK.
- To disable NetDMA, type 0 in the Value data box, and then click OK.
- 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.
Hope it helps.