EMS command logging reappears in Exchange 2013 SP1

In January, I wrote about how you can use administrator auditing to gain some insight into the internal workings of the Exchange Administration Center (EAC). This is a somewhat unnatural replacement for the three methods available in the Exchange 2010 EMC to see the Exchange Management Shell (EMS) commands that the console executes to get work done. Regretfully, the three methods (command logging, wizard display, and property updates) were lost in the transition from the MMC-based EMC to the browser-based EAC. Such is the way of technology updates – some useful bits are often dropped.

The good news is that command logging has been restored to EAC in Exchange 2013 SP1. The bad news is that the other methods have not. This is probably due to the fact that EAC executes its own dialect of EMS when it communicates with Exchange, a revelation that I learned at the MEC 2012 conference in Orlando when some of the Exchange developers decided not to beat me up with rubber truncheons due to my long and lasting complaints on the topic. Instead, they kindly sat down with me over lunch and explained the technical difficulties of making EAC cough up what it does in a form that PowerShell neophytes could comprehend. Getting these kind of off-the-record but intensely valuable briefings from engineers is one of the very good reasons why conferences like MEC are so valuable (the Exchange developers also come to Exchange Connections as well, so do come along to Las Vegas in September to meet them there).

In any case, command logging is only available if you log-onto EAC with an administrator account. In other words, you need to be a member of an RBAC group such as Organization Management or Recipient Management and not use an account that only has user rights. Equipped with a satisfactory account, EAC reveals the “Show Command Logging” option in the far-right drop-down menu beside the name of the account which you use to log-in.

Once invoked, command logging displays the cmdlets executed by EAC in a separate window (the logging viewer). Logging continues until you close the window and no command executed before the window is opened is captured. It would be nice if EAC had an option to allow you to determine that the command logging window was opened automatically when EAC starts, but for now you have to remember to open the window manually before you do anything interesting.

Up to 500 entries can be displayed (you can clear the current batch at any time) and after the limit is reached, EAC will discard older entries to display newer ones. A useful search facility is provided to allow you to find a particular command and cut and paste (including multiple select) is supported to allow you to take commands and export them into your own scripts.

Generally, I like command logging a lot with just one small caveat. EAC just loves to output code that includes GUIDs to reference objects such as servers and mailboxes. Now I accord GUIDs the respect that they are due because there’s no more exact way to reference an Exchange object, which is the reason why EAC so happily outputs them in its code. However, GUIDs are not part of the normal vocabulary used by administrators. At least, I have never met an Exchange administrator who is fluent in GUID-speak and happy to converse with a server on that basis. Mostly the appearance of a GUID in some output is the cause for concern as the GUID has to be laboriously translated into something that makes sense, such as the actual name of a server. You're unlikely to want to include code based on GUID identities in scripts because this would make the code harder to read and less maintainable, so the wholesale use of GUIDs takes removes of the goodness of command logging. 

It would be nice if EAC did this heavy lifting for the humans who use command logging. After all, if it’s translating its own patois into human-consumable code, it should be easy enough to resolve the GUIDs too. Interestingly, as you can see from the screen shot of the logging viewer, sometimes the resolution occurs and human-friendly output appears.

I welcome the return of command logging to EAC. At the risk of the reappearance of rubber truncheons at MEC 2014, it should never have been removed in the first place.

Follow Tony @12Knocksinna