Windows Insider

Spend Less Time Looking for Logs

Here's Greg's short list of some key extended Active Directory log reports.

• By Greg Shields
• 09/01/2006

Ever sit frustrated in front of a broken domain controller and think, "Man, is it me or does the event log just suck?" Well, here's a hint: it's not you.

Unfortunately, this is a bad news/worse news situation. The bad news is Active Directory's default logging level to the Windows event log is hardly designed to tell you everything about what's going on under the hood. The worse news is that this problem is endemic to event logs of any type.

Many Windows processes can enable debug logging at a level far too detailed to read during normal operations. Active Directory and the components it relies on can drown you in notifications to the point where logging itself impacts a server's performance. The consequence of this is detailed debug logging by default is disabled.

But sitting in front of that broken Windows Server 2003 DC makes you wish for just a little more data to help you determine what's wrong. I had just this problem not long ago and thought, "Wouldn't it be nice to compile all the extended and optional AD logging capability in one place just in case I needed it?"

Below is a short list of extended logs. Some report to the event log and others report to a specific file.

NTDS Diagnostics Logging
By default, AD only records critical and error events to the Directory Service log. This is alright to do during normal operations, but sometimes additional logging is necessary.

To enable this additional logging, navigate to HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Once there, check out the 24 logging options available there as shown in Figure 1.

[Click on image for larger view.]

Figure 1: NTDS diagnostics logging provides 24 separate options for additional logging.

For these logging options, you can set each one's DWORD value to a number between zero and five. At level zero, which is the default level, you can only log critical and error events. At level five all events are logged, including debug strings and configuration changes. All logs are saved to the Directory Services event log.

But be aware that setting higher logging levels significantly increases the number of entries recorded in the event log, even to the point where it becomes impossible to parse. Typically, setting log levels above three negatively impacts server performance.

Extended DCPROMO Logging
When the DCPROMO process is run on a Windows Server 2003-based machine, two log files are created, called dcpromo.log and dcpromoui.log. Both log files, which are stored in %systemroot%\debug, provide information about the success or failure of the domain controller creation process.

It is, however, possible to increase the logging level for the dcpromoui.log file. This is useful when you're experiencing problems during a promotion or demotion event and the default logging level doesn't provide enough information to indicate the nature of the problem.

To increase the logging level for this file to the maximum, navigate to HKEY_LOCAL_MACHINE\Soft ware\Microsoft\Windows\Current Version\AdminDebug\dcpromoui. Then, set the DWORD value for LogFlags to the hex value of FF0003.

NETLOGON Logging
If you're having issues with client log-ins, repeatedly locked out accounts or seeing problems with log-in activity across forest trusts, you can increase the logging level on the NETLOGON service to hunt down these problems.

To enable NETLOGON logging, navigate to HKEY_LOCAL_ MACHINE\SYSTEM\Current ControlSet\Services\NetlogonParameters and set the DWORD value for DBFlag to the hex value of 2080FFFF. Then, you can restart the NETLOGON service.

When enabled, this will log the authenticating domain controller, the client's site, account password expiration and lockout information, and Kerberos failures. The log is also stored in %systemroot%\debug.

The netlogon.log file can get very large, making it difficult to parse using Notepad or another text editor. But using a Microsoft tool called nlparse, you can filter the contents of the netlogon.log file for easier reading. The nlparse tool is part of the "Account Lockout and Management Tools" that can be downloaded from Microsoft's Web site.

Kerberos Logging
If you're seeing problems with authentication or Kerberos in the event log, then you try raising the logging level on the Kerberos subsystem. Problems with disabled or expired accounts, missing usernames, and clock synchronization often show up with Kerberos failure codes.

To enable Kerberos logging navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Then set the DWORD value for LogLevel to one. Making this change logs the events to the System event log.

USERENV Debug Logging
Not directly related to AD, but still a critical component of the logon process, USERENV logs are handy for troubleshooting log-in issues. Many problems associated with Group Policy applications and user profile loading and unloading can be debugged by enabling USERENV debug logging. This is particularly handy in Terminal Services environments where slow log-ins and log-offs can be a problem.

To enable USERENV debug logging at the highest level, navigate to HKEY_ LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Win logon and set the DWORD value for UserEnvDebugLevel to 0x00030002. Then, watch the log in %Systemroot%\Debug\UserMode\Userenv.log.

If you're using this log for locating the cause of extended log-ins or log-offs, watch the timing of the log-on/log-off event and look for areas of delay and the activity on either side of that delay. Using this type of logging on Terminal Servers ensures that regular users are disabled from logging into the Terminal Server during its logging process. Otherwise, the multiple log-in events can make parsing the log very difficult.

When using this log for GPO-related problems, the log will describe the applied GPOs and the parts of the GPOs that are not being processed.

GPO Client Logging
Another way to troubleshoot the application of GPOs is to enable GPO client logging. This logging is used to troubleshoot problems with client GPO processing, enumeration of applied GPOs and errors encountered during that processing.

To enable GPO client logging, navigate to HKEY_LOCAL_MACHINESoftware\Microsoft\WindowsCurrentVersion\Diagnostics. Set the DWORD value for RunDiagnostic LoggingGroupPolicy to one, and then reboot the system. Making this change adds to the Application event log an event log entry for each step in the GPO processing cycle.

DNS and WINS Server Debug Logging
DNS and, to a much lesser extent, WINS are important components of Active Directory as well as a system's ability to connect to network resources.

As AD relies on DNS for storage of its resource records, a functioning DNS server is critical for AD operations. If your DNS server is experiencing problems, then you can enable DNS server debug logging from within the DNS server console. Once inside the DNS server console, right-click on the server in question, select the Debug Logging tab, and select the options you want to log and click OK. The events will be logged to the file %systemroot%system32\dns\dns.log.

Enabling verbose logging for WINS requires a change to the registry. To enable logging, navigate to HKEY_ LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\WinsParameters. Next, set the DWORD value for LogDetailedEvents and LoggingOn to 1. You'll also need to set the REG_SZ value for LogFilePath to the location where you want the log files stored. These can also be enabled from the WINS administration console.

It's worth restating a caution about enabling any form of debug logging on your domain controller. Just the process of logging all that data to the event log or a log file can inhibit server performance. Log files have the tendency to gobble up generous amounts of space on a server's disk drive, so make sure you disable logging once the troubleshooting analysis is complete.

All this being said, the extended logging capabilities of Active Directory's various components gives you excellent insight into the inner workings of your domain controller. So, go find your log!