I discussed how to enable administrator audit logging and access the resulting audit entries in Exchange 2010 as long ago as April 2011. Apart from enabling administrator auditing by default in newly-deployed organizations, not much has really changed since that time. In fact, apart from migrating the auditing options on the compliance management tab from the Exchange 2010 Control Panel (ECP) to the new Exchange 2013 Administration Center (EAC), not much really happened in this neck of the management woods.
Perhaps it was because no one really cared about administrator auditing. Or perhaps because everyone promptly forgot about auditing once it was enabled to check a box for some random regulatory requirement. Or maybe it’s because we are all so good at PowerShell that running the Search-AdminAuditLog cmdlet multiple times to make sense of the audit entries. Or that we simply waited for Microsoft to make everything better by providing a useful option in EAC.
Well, it turns out that they did just that in Exchange 2013 CU3. You probably didn’t notice the change because the auditing section of EAC can be a pretty lonely place that doesn’t receive too many visits, but if you go there you’ll see a new “View the Administrator Audit Log” option all bright and ready to go.
Clicking the option causes EAC to open a new window to display the administrator audit entries from the last two weeks. You can change the date range if you like, but for now let’s concentrate on what you actually see as you browse through the audit entries.
As it turns out, you can unearth some pretty interesting entries that help solve the eternal question of “who did what to Exchange.” Of course, if you’re the only administrator, that debate is pretty uninteresting as the same answer keeps on appearing, but if a team is responsible for running Exchange, you might not always know who did what when.
Take the example shown in the screen shot shown below. It shows an audit entry for 16 January 2014 when an administrator (someone logged in to the Administrator account) ran the Set-MailboxServer cmdlet to set the database activation policy on the ExServer2 server to be “blocked.” The effect of this command would be to stop Active Manager performing an automatic failover to database copies on ExServer2 and it’s not something that you would do without good reason. In this case, database activation on the server was blocked to allow installation of a cumulative update, which is the kind of thing you’d do if you follow best practice for installing updates onto DAG member servers (see this script for a good starting point if you want to automate the process).
Being able to view administrator audit entries through a simple search and browse mechanism is a reasonable step forward. However, it won’t really help those who operate within large organizations because of the sheer number of audit entries that are likely created daily. In these circumstances, you are probably still going to run Search-AdminAuditLog on a regular basis to scan for and report unusual occurrences such as databases being dismounted or the creation of new transport rules. Hopefully you’ll automate these searches through some simple scripting.
It’s good to see that the Exchange developers have finally put some effort into making the audit pieces of EAC more approachable and useful. It’s a start, but there’s still more to do before the audit log viewer becomes a really valuable tool.
Follow Tony @12Knocksinna
