Exchange has come a long way & is capable of "self healing" to an extend and it does it by runnning tasks like restarting the service, moving the database to a different copy etc. It is a good thing that Exchange fails over a database if it finds an issue with it, say for example a disk latency which is more than the threshold.
More...
As an administrator, you want exchange to perform the remedial action to an extend. You don't want to be called up at night just because SCOM alerts a disk latency on one of the LUNs. As an exchange admin, you are happy that Exchange does what it is supposed to do by failing over the database to another healthy copy & letting you sleep ;)
But how do we keep track of the database failovers? Exchange won't failover databases for no reason and this tracking exercise becomes important when you are trying to troubleshoot an issue, say a disk latency. You need the time when the database failover, info on which database moved, which server it was on etc. Yes, you can go through the Windows logs and the Exchange crimson channel & manually do it, but it is very time consuming.
Luckily the Exchange team has a script for making this reporting easier and it is in the Exchange binaries folder. Head over to the Scripts folder and the script that we need is called CollectOverMetrics.ps1.
The script reads event logs of all DAG members to report information on database mounts, moves and failovers over a period of time & the outputs the info into a csv file to the scripts directory by default. The script takes number of paramters to tweak the report the way you want. Below are the commonly used ones.
Parameter | What it does |
|---|---|
DatabaseAvailabiltyGroup | Specifies the DAG to target, comes in handy if you have more than one DAG. |
Database | This paramater can be used to target a single database or a group of them. Wildcard is allowed, for example -Database "MDB*" |
StartTime | The time from which you want the script to start fetching the logs. The script defaults to 24 hours if a start or end time is not specified. |
Endtime | The time till you want the script to analyze the logs |
GenerateHTMReport | Specifies that the script generates an HTML report by grouping the data by operation type |
ShowHTMLReport | Specifies that the html report that was generated be shown in a browser once the script finishes. |
ReportPath | Use this parameter if you want the csv & html file (if you have specified for one) to be stored in a location of your choice |
[clickToTweet tweet="How to keep track of #MSExchange 2013 database failovers?" quote="Keep track of Exchange 2013 database failovers the easy way !" theme="style3"]
Let's see it in action, shall we? Navigate to the scripts directory & run .\CollectOverMetrics.ps1. You can also copy the script to a different location and run it from there as well.
It shows an html file with lot of information once the script is finished.
But the beauty is in the csv file which will list the following and more - database which had the issue, the server from & to which the database moved, date and time of the failover, the PAM that was involved, was the move/mount successful etc.
One thing to note is that the script parameters StartTime & EndTime only takes US date format by default, which is mm/dd/yy. You can edit the script easily to use the date format of your server (Get-Date) if you want.
Have you tried this script before? It is in Exchange 2010 as well.
Cloud Architect & Blogger with interests in Office 365, Enterprise Mobility & Security and Azure. I am active on Experts Exchange & TechNet forums and I am a technical author for SearchExchange. Follow me on Twitter, LinkedIn, Facebook or Google+ for the latest updates. For consultancy opportunities, drop me a line.
Hi Rajith,
How to automate this script in Exchange 2010? It will be very helpful if you provide complete steps.
Hi Mahadeer,
You can configure the script to run as a scheduled task. The script is available in the \Scripts folder in Exchange 2010 as well.
Check https://blogs.technet.microsoft.com/heyscriptingguy/2012/08/11/weekend-scripter-use-the-windows-task-scheduler-to-run-a-windows-powershell-script/ for exact steps.
Thanks
Thanks for the info. It’s great to see how far Exchange has come and the direction it’s going.
Thanks for dropping by Ben.
Yes, Exchange is more cloud focused and has lot of monitoring to aid the vast Office 365 deployment.