Spend Less Time Looking for Logs
Here's Greg's short list of some key extended Active Directory log reports.
- By Greg Shields
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
[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
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
Version\AdminDebug\dcpromoui. Then, set the DWORD value for LogFlags to the hex value of FF0003.
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_
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.
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_
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!
|NTDS Diagnostics Logging
|Set DWORD value for
each between 0 and 5
|Directory Services event log
|0 = min logging.
5 = max logging.
|Extended DCPROMO logging
|Set DWORD value
for LogFlags to the
hex value of FF0003
|Set the DWORD value
for DBFlag to the hex
value of 2080FFFF
|Restart the NETLOGON service
|Set the DWORD
LogLevel to 1
|System event log
|USERENV debug logging
|Set the DWORD
|Ensure no other users are logging into the system while monitoring
|GPO Client logging
|Set the DWORD value for
GroupPolicy to 1.
|Application event log
|Restart the system
|DNS Server logging
|DNS Server console, Debug Logging tab
|WINS Server logging
|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.
|Can also be enabled via WINS admin console
Greg Shields is Author Evangelist with PluralSight, and is a globally-recognized expert on systems management, virtualization, and cloud technologies. A multiple-year recipient of the Microsoft MVP, VMware vExpert, and Citrix CTP awards, Greg is a contributing editor for Redmond Magazine and Virtualization Review Magazine, and is a frequent speaker at IT conferences worldwide. Reach him on Twitter at @concentratedgreg.