Managing Exchange Server 2007 Log Files (Part 1)

If you like to read the other parts in this article series please go to:

• Managing Exchange Server 2007 Log Files (Part 2)
• Managing Exchange Server 2007 Log Files (Part 3)

Managing debug levels in Exchange Server 2007

If you have ever done some troubleshooting on Exchange Server 2003 you would remember the Diagnostic Loggings tab in Exchange Server 2003, as shown in Figure 01. That tab was really useful because you could see the main components on the left side and for each component you could have one or more categories where you could set different levels of logging for components and its sub-categories.

Figure 01

Each event generated by Exchange Server has a logging level value, based on these values the log information will be displayed in the Application log in Event Viewer. The following table explains the Logging level and the number associated to it:

Table 01

Based on the changes of the Logging Level in Exchange System Manager, a registry setting will receive a numerical value associated to the logging level, all Exchange Components are located in the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Component Name>\Diagnostics

They also have a common directory named Diagnostics and underneath that key all categories of that specific service are listed and the values shown in the table above can be configured.

The registry path and Diagnostics key are shown in Figure 02, this path can be used in both Exchange Server 2003 and Exchange Server 2007.

Figure 02

As you should know, the debug should be used only during troubleshooting. If you are not dealing with any issue you can set the level to the minimum value to increase your Exchange Server performance.

Unfortunately we do not have a graphical user interface to manage the Diagnostics logging level in Exchange Server 2007 however we can manage it using Exchange Management Shell using two cmdlets: Get-EventLogLevel and Set-EventLogLevel.

Get-EventLogLevel lists all components and their correspondent categories logging level configuration. The Get-EventLogLevel output is shown in Figure 03.

Figure 03

By default, the Get-EventLogLevel cmdlet will run against the local server, later on in this article we are going to use it to retrieve information from remote servers.

Getting Debug information through Exchange Management Shell

We have seen how to view the current Event Level of all components in Exchange Server 2007, now we are going to use some PowerShell functionalities to improve the admin experience in order to get the Debug Level of determined components.

We can get debug level information from a specific component by just using the Identity column that was shown in Figure 03. Let’s say we can validate the debug level for the category MSExchange Cluster and the component Move, we can use this cmdlet:

Get-EventLogLevel “MSExchange Cluster\Move”

Another possible way is by using only the component name or using a wildcard to narrow down the result. In order to use a component name, we just need to specify the string before the first backslash (\). Let’s say that we want to check the debug level for the Active Directory Access and all its components, the following cmdlet can be used:

Get-EventLogLevel “MSExchange ADAccess”

A second option that brings the same result is using wildcard as shown in Figure 04.

Figure 04

Now that we are aware of wildcard use with Get-EventLogLevel cmdlet, we can use it to filter the result in a different way. We can search all categories based in a string, or we can also use the category and wildcard to narrow down the result easily. In Figure 05, we have a couple of examples using a wildcard character, in the first one we will search the string “Transport” in all categories of the current server and in the second one we have only the components that start with the letter “C” under the MSExchange ADAccess component.

Figure 05

We have been filtering using only the first column which is Identity but we can also use EventLevel. Let’s say we want to validate all components that have EventLevel equal medium, in this case the following cmdlet can be used:

Get-EventLogLevel | where { $_.EventLevel -eq “Medium” }

Because we know that Medium corresponds to number 3 in the registry and this command will retrieve this information, we can also list all categories that have Medium or higher values, as follows:

Get-EventLogLevel | where { $_.EventLevel –ge 3 }

Configuring Debug Levels

Now that we already know how to list the Categories and their Event levels, we can start managing them using Set-EventLogLevel. In order to change the Logging level we can use the following syntax, in this example we are going to change the Topology subcomponent of Microsoft Exchange Active Directory Access (MSExchange ADAccess), as follows:

Set-EventLogLevel “MSExchange ADAccess\General” –Level Expert

The level parameter can be any of the options listed in Table 1 (Exchange 2007 column), we can use the same principle used in the previous cmdlet to define a medium level for more than one component using a wildcard, as example:

Get-EventLogLevel “MSExchange ADAccess\* | Set-EventLogLevel –Level:Medium

Viewing the Debug information

As we said earlier we can view the debug information using Event Viewer (Figure 06) or using Exchange Management Shell.

Figure 06

We can use Exchange Management Shell to retrieve information from Event Viewer Application section, using the following cmdlet:

Get-EventLog Application

It will show all information stored in the Application section, however we can use the same concept used before to filter the results. Let’s say we want to list only information related to MSExchangeFDS we can use this cmdlet:

Get-EventLog application  | where { $_.Source -eq “MSExchangeFDS” }

The result will show only entries that have MSExchangeFDS as source, if you want to read the information of the events, you should consider the use of “ | FL” at the end of the previous cmdlet where it will bring details for each entry of the Application log.

More Examples…

We saw how to manage the debug information however there is a lot more that we can do to manage debug configuration in Exchange Server 2007. These are the most common questions that I have received or worked on in some TechNet Forums:

1. How can I see the debug information from a remote server?
   By default, Get-EventLogLevel gets information from the local server, but you can use –Server switch or Identity to specify a different server, as follows:
   Get-EventLogLevel –Server <Remote-Server-Name>
   Get-EventLogLevel “<Remote-Server-Name>\MSExchange ADAccess”
2. How can I list the debug levels of all components from all Exchange servers of my organization?
   You need to use an extra command to get such information, but it is not a big deal. Here is the syntax:
   Get-ExchangeServer | ForEach { Get-EventLogLevel -Server $_.Name }
3. How Can I list all components which have a value greater than 3 in all servers?
   Using the same principle of the last question, as follows:
   Get-ExchangeServer | ForEach { Get-EventLogLevel -Server $_.Name | where { $_.EventLevel -ge 3} }
4. How can I change the debug level of the categories that have a determined level?
   You just need to make sure that you query is getting the proper results and then add a pipe (“|”) and a Set-EventLogLevel at the end using the new value that you want. In this example all categories with Debug Level Medium were changed to Low.
   Get-EventLogLevel |  where-object { $_.EventLevel -eq 3}  | Set-EventLogLevel -Level 1
5. Can I do the same of the previous questions for all servers of my network in a single step?
   Yes, it is possible. In this example we are looking for all categories that have Debug level more than 3 and they will be configured as Low (value 1), here is the cmdlet.
   Get-ExchangeServer | ForEach { Get-EventLogLevel -Server $_.Name | where { $_.EventLevel -ge 3} } | Set-EventLogLevel -Level 1

Conclusion

In this article we have seen how to manage debug level configuration in Exchange Server 2007, we also went over some examples where you can manage more than one server at the same time using a single command line.