There are counters there about the number of logs waiting to be replicated between DBs, latency in transfer etc.
These could be used to 'assume' there is a problem as the replication would effectively halt and queues would form.
it would cause false positives, and may not provide a very quick alert that the DAG had an issue, so I do not feel this would be suitable for monitoring purposes.
Powershell scripts running on the DAG health directly would be much more accurate and quicker.
Looks like you actually would have to run these scripts each time you want to check the DAG status. I would like to have something to alert me automatically when the DAG shows offline in the MS Failover Cluster manager. There are several Exchange performance counters that are available, I just don't know which (if any) of them will alert me when the DAG is offline.
You could run a Powershell script (via a scheduled task) on a server to ping the DAG IP address, and then if it's unavailable, send an email notification. Best to run the script on a server outside of the Exchange DAG, and send the email notification via an outside SMTP server and to an external email address, so that the mail will get through with the DAG down.
0
ei00004Network AdministratorAuthor Commented:
Chriskelk - Yes I probably could run a Powershell script (via a scheduled task) on a server to ping the DAG IP address. This would need to pinging the server several times a minute to be accurate and possibly creating unnecessary network traffic. Surely there is a way to do this by using the Performance counters that are already installed with Exchange.
0
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
There may be a dirty way of doing it using performance, but it's not going to be very accurate.
see the link below for example. This shows various performance counters for Exchange.
http://technet.microsoft.com/en-us/library/ff367871(v=exchg.141).aspx
There are counters there about the number of logs waiting to be replicated between DBs, latency in transfer etc.
These could be used to 'assume' there is a problem as the replication would effectively halt and queues would form.
it would cause false positives, and may not provide a very quick alert that the DAG had an issue, so I do not feel this would be suitable for monitoring purposes.
Powershell scripts running on the DAG health directly would be much more accurate and quicker.