The transition to web-based management in Exchange 2013 removed the three PowerShell learning features included in Exchange 2010's management console. Here's how you can use Exchange's administrator auditing feature to discover just what commands EAC executes when it completes tasks.
If, like me, you regret the loss of the three PowerShell “learning features” in the transition from Exchange 2010’s management console (EMC) to the new Exchange Administration Center (EAC) as used in , your pain might be relieved a little by the realization that administration auditing can reveal some of the same PowerShell detail that can be seen through EMC.
It’s important to emphasize that PowerShell provides the underpinnings for all of Exchange’s management tools. Thus, if you don’t know PowerShell – or at least have a passing acquaintance with the set of cmdlets and their parameters implemented for Exchange – you will have problems managing an Exchange server.
EMC has some acknowledged problems (for instance, it is slow at dealing with more than a few hundred objects), but is delightful in the way that it cheerfully reveals the PowerShell code that is executes to perform common actions such as creating new mailboxes. EAC stays dumb on this point because Microsoft has not yet provided equivalent functionality. Perhaps it is more difficult to spit out code from browser-based consoles. More likely it’s due to a simple omission, probably based on prioritization of other work within EAC. And given that EAC suffered some fit-and-finish issues in the RTM release, now much improved in subsequent updates, that prioritization is understandable.
Administrator auditing tracks actions performed by administrators in EAC and the Exchange Management Shell (EMS) and stores them as items in a system mailbox. This only happens if you enable auditing, which is an organization-wide setting. Do this by running this EMS command:
Being its normal cautious self, EMS tells you that the command might not be effective for up to 60 minutes. This takes account of potential delays in Active Directory replication, which should be minimal in most well-run deployments.
So good so far, but we haven’t done enough to capture all of the information that we might want. As you can imagine, a lot of administrative events might occur on a daily basis within an organization, so Exchange allows you to filter the events that you capture. To do this, you run Set-AdminAuditLogConfig again to declare a set of “interesting” cmdlets or the ones that you want Exchange to record information about each time any of the cmdlets is run. For example, if you’re interested only in the Set-Mailbox and New-Mailbox cmdlets, you run this command:
Alternatively, to capture anything to do with mailboxes, you might use this command, which will capture events for cmdlets such as Enable-Mailbox or Disable-Mailbox as well:
Or, if you want to capture everything, run this command:
We can also specify the cmdlet parameters that are captured. To make sure we get everything, we run the command
You can check the current configuration with Get-AdminAuditLogConfig.
Now that Exchange is busily recording data, we can see what might be captured and figure out if anything can be learned from the data. Open EAC and perform whatever administrative action you want (deleting the CEO’s mailbox is probably not a good example of what I mean). Once you’re done, go back to EMS to use the Search-AdminAuditLog cmdlet to discover what has been recorded. Because of the volume of data that auditing might throw up, it’s best to be reasonably precise about the period used to retrieve data.
Hmmm… Interesting. After the admin audit log configuration was updated, we can see a set of four cmdlets run at the same time. One of these is recognizable by the user (me) because I created a new mailbox. This accounts for the New-Mailbox entry. The other three cmdlets were run by a system process rather than a user, which might puzzle the reader until I let you know that my Exchange organization uses a cmdlet extension agent to finalize language and regional settings for new mailboxes. Exchange invokes the cmdlet extension agent when it is finished processing New-Mailbox. The fact that the three cmdlets executed by the agent are shown before New-Mailbox is accounted for by sorting to the second rather than millisecond.
The other entries show that a new public folder was created and that an eDiscovery mailbox search was started and illustrate the kind of day-to-day operational activity that is captured in the administrator logs.
If we look at an audit entry in more detail, we can see the parameters that were used (I usually dump items out to a text file for this kind of examination). For example:
Administration auditing was not built to replace the massively useful PowerShell learning tools that are integrated into EMC. As such, it’s a poor replacement. However, it’s surprising how often knowing how to get some information out of the bowels of Exchange is useful. For instance, if I hadn’t told you about the cmdlet extension agent and you were a new administrator for my organization, how would you discover what’s happening behind the placid but uninformative face of EAC?
I hear that some change might be on the horizon and that Microsoft could be working on doing something to make EAC more informative about its use of cmdlets. That's certainly something to look forward to, if indeed it comes to pass. In the interim, you can look behind the scenes and get an idea. Not perfect by any means, but at least it's a start.
Follow Tony @12Knocksinna