When I wrote about how Exchange 2013's Exchange Administration Center (EAC) simplifies the management of Database Availability Groups (DAGs), Scott Schnoll, that well-known and much-travelled evangelist of Exchange high availability, pointed out quite correctly that none of Exchange’s management tools include any business logic whatsoever as all depend on calling whatever Exchange Management Shell (EMS) cmdlet is appropriate to manipulate information an object. This has been the case since Exchange 2007 embraced PowerShell and launched Exchange on the path that it has since followed.
Not being picky at all, my sources within the EAC team tell me that they run EMS in a slightly different manner than an administrator does through an EMS window. It’s all to do with the way that browsers send commands to servers. At least, that’s what I remember from a lunch-time conversation at MEC in Orlando. Or maybe I was too concerned with eating to remember accurately. In any case, Scott’s point is well made.
In this instance, the point under discussion revolved around how EAC reported replication activity within a DAG compared to EMC. My view is that EAC is better because it doesn’t display the replay queue length and copy queue length for database copies in quite the same “up front” manner as EMC does. It’s good and interesting to see values for these queues shown by EMC and, at first glance or if you’re not familiar with the way that EMC fetches data about database copies, it’s easy to assume that EMC is presenting a form of replication dashboard for the DAG.
However, the problem (to me) is that you can easily forget that the values for replication queue lengths shown by EMC begin to lose value immediately they are derived by running the Get-MailboxDatabaseCopyStatus cmdlet. Turn away for a coffee and you’re looking at what could be very stale data the next time that you glance at EMC. The fault is not with EMC as it merely displays data that is accurate at the time it was fetched. For EMC to be in any way at all accurate, it would have to act like a Duracell bunny on steroids and constantly run Get-MailboxDatabaseCopyStatus, something that would stop the console doing anything else and probably impractical for anything but a small DAG.
I therefore hold to my view that EAC does a better job by displaying some information for the selected database copy in the details pane but doesn’t attempt to provide a snapshot of replication activity across the DAG. EAC is happy to show more information about replication if you view the properties of a database copy, but the data is still stale.
So what should you do if you want to retrieve up to date information to monitor replication activity. The answer lies in Performance Monitor. Exchange 2013 boasts a comprehensive set of counters that can be interrogated at the level of a database copy, including the copy and replay queues. And because Performance Monitor’s task is to monitor what’s happening on Windows servers, it does an excellent job of providing up-to-date and constantly refreshed information about replication activity. Performance Monitor allows you to save the data, establish thresholds for measurement, alerts, and so on. The data can be fed into other monitoring tools such as SCOM, or you can do your own analysis using the many tips covered elsewhere (for example, this interesting blog).
TechNet documents the set of performance monitor counters for Exchange 2010 mailbox servers but a similar level of detail isn’t currently available for Exchange 2013. Or at least, I can’t find them using either Bing or Google (I know, “user error”). Oh well…
Follow Tony @12Knocksinna
