The ability to set diagnostics at different levels for the various components that function on an Exchange server has always existed. From Exchange 4.0 to Exchange 2003 you set diagnostic levels through the management console by selecting the component (for example, ActiveSync) and the level that you wanted to apply. Once a new level is set, Exchange complies by outputting more or less detail about its operations as events written into the Application Event Log. This mechanism worked well until Exchange 2007 appeared and administrators discovered that the new Exchange 2007 management console included no GUI to deal with diagnostics, meaning that they had to set diagnostic levels through EMS.

Microsoft addressed the problem in Exchange 2007 SP2 when they included the ability for EMC to set server diagnostics as properties of a server in addition to manipulation through PowerShell. The same behavior exists in Exchange 2010 but the transition from the old MMC-based console architecture to the browser-based Exchange Administration Center (EAC) in Exchange 2013 has resulted in the disappearance of the UI to manipulate server diagnostic levels. Or, possibly more correctly, the developers who created the new browser-based administration console simply ran out of time to include what might be considered to be a “nice to have” rather than “essential” feature. Frustratingly, this omission has not been addressed in any cumulative update since.

Another development for event logging in Exchange 2013 arose from work such as the rewrite of the Store into managed code and the introduction of modern public folders. A side effect of these projects is that a large number of previously well-known event logging categories have been either removed from Exchange 2013, replaced with a new logging category, or subsumed into yet another category. The upshot is that administrators who have created diagnostic scripts that depend on event logging categories to help them debug a problematic Exchange server have some work to do to review their code and potentially adjust calls to work with Exchange 2013.

The lack of UI to set server diagnostics means that we have returned to manipulating diagnostic levels through EMS. For example, to set the logging level to “High” for the operations performed through EAC (which still uses the old Control Panel name for diagnostic purposes), you type:

Set-EventLogLevel –Identity “MSExchange Control Panel\General” –Level High

Microsoft’s documentation on the available event logging categories is sparse to non-existent. However, there’s an easy way to retrieve a full set of current event logging categories by interrogating a server. To do this, use the Get-EventLogLevel cmdlet to return a list of the current diagnostic levels for a server. The list can also be used to verify that the correct settings are in place for each category. The cmdlet doesn’t support a filter function to allow you to specify that you only want details of event categories for the Store or transport, but as we want a full list, we can simply capture the output into a text file for easier examination. For example:

Get-EventLogLevel –Server ExServer1 > C:\Temp\EventLevels.txt

The list of event categories is roughly organized into areas of functionality such as Autodiscover, RBAC, replication, and so on. A little trial and error is therefore necessary to figure out exactly what is the best event category for which you should increase logging level when debugging a particular area of functionality.

As shown in the table below,  Exchange supports UK dedicated servers and five levels of diagnostic logging based on the level assigned to events recorded by the application. Critical events and those assigned a level of zero are always written into the event log. Events with a higher level are captured if an elevated diagnostic level is chosen.

Be careful about setting diagnostic levels to Medium or higher. Exchange is quite happy to provide a vast amount of diagnostic information by writing events into the Application Event Log, but you run the risk that you won’t be able to see the forest for the trees and some essential piece of information will be overlooked simply because so much data are available. To prevent the Application Event Log from being clogged up with an excessive number of events, make sure that you reset the diagnostic level to Lowest when you’ve completed troubleshooting the problem that caused you to elevate the level.

Change is wonderful (usually). I am sure that EAC will fill the gap over time. But for now, the more that I work with EAC, the more gaps I find. It’s a bit like Exchange 2000 all over again…

Follow Tony @12Knocksinna