Let's say that you’ve just assigned a new software installation Group Policy Object (GPO) to a select group of machines in your office. You're hoping that you will no longer have to send around weekly e-mails with links to software updates and antivirus files—which many workers ignore anyway. The only problem is that you notice two of the eight machines in your test group are not applying the GPO as you expected, and you need to find out why. Naturally, you consult the Event Viewer logs, but you find only the most basic level of detail being logged. The information doesn't help you figure out why the GPO is not being applied.
Unfortunately, this is a fairly common scenario because detailed logging of GPOs is not turned on by default. To help you in your GPO troubleshooting efforts, I'm going to show you to turn on detailed GPO logging and what the results look like once you do. I'll also show you an alternative way to examine GPO problems.
The GPO logging issue
The default logging levels of GPO processing events under Windows 2000 are minimal. In particular, applications don’t usually log all the changes they make to the registry in the Event Viewer. GPO processing does log some high-level events in the Event Viewer, but they’re not a great deal of use if you run into problems and need some nitty-gritty details on why GPO processing failed.
To improve GPO logging, we need to fiddle with the Windows registry. Of course, you probably know that unless you take reasonable precautions while dealing with the registry, GPO logging could turn out to be the least of your worries. Before fiddling, make a backup of the registry. The easiest way to do this is to make an emergency repair disk and select the Backup Local Registry check box.
Now that we're through with the dire warnings, let's look at the registry keys we need to work with. There are several options you can use together or separately (as your needs dictate) that will help you fine-tune your troubleshooting process. All these registry tweaks need to be made at the location shown in Listing A. If you can’t find the Diagnostics key there, you’ll have to add it, but if the machine is processing some GPOs, it will most likely be there.
Making the registry changes
Now let's take a look at the registry values you can manipulate. The first is RunDiagnosticLoggingGroupPolicy. Adding this value and setting it as a REG_DWORD with value 1 will affect the logging of GPO processing by turning it on in verbose mode. After you make that change and restart the system, you will see a lot more information reported, especially during errors. In many cases, this will be enough to get the information you need.
You can manipulate some other values as well. One of these is RunDiagnosticLoggingApplicationDeployment. Adding this value as a REG_DWORD with value 1 will turn on verbose logging specifically for GPO application deployments. In the case of an administrator who is trying to deploy antivirus files via GPO, this key would definitely be helpful in improving logging.
Another useful value is RunDiagnosticLoggingGlobal, which, when added as REG_DWORD with value 1, will turn on verbose logging for all GPO processing events, including those listed above. It’s basically a catch-all value, but the downside is that it may confuse you when you examine the logs because it will log lots of events that may not have anything to do with your specific problem. Think carefully before turning this one on—it could increase your workload.
Be aware that when you switch on verbose logging modes with these values, your Event Viewer logs will fill up quickly. You’ll need to review the settings for the Event Viewer logs to ensure that everything you need is being logged and that you don’t lose or overwrite any part of the logs you may need to keep for reference, security, and/or legal reasons. This may require increasing some of the settings to allow for a greater number of entries.
An alternative solution
In the specific case of application deployment problems, you can use another approach to examine, in detail, what a particular .MSI package is doing to a given system. Msiexec is a tool that can be run in interactive mode at a command line with switches. Below is an example of how you can use this tool to log the installation process as governed by an .MSI installer package:
msiexec /I myprogram.msi /L *v c:\installerlogs\myprogram-app.log
This command tells the Msiexec program to install the application package myprogram.msi and to log the results in verbose mode in c:\installerlogs\myprogram-app.log. The logging feature includes a number of options you can specify to pinpoint what is logged. Table A shows some of the most useful options.
|Option||What it logs|
|/le <log filename>||Report all error messages|
|/la <log filename>||Summary of actions only|
|/lr <log filename>||Action-specific records only (standard or custom actions performed)|
|/lm <log filename>||Out-of Memory errors|
|/lo <log filename>||Out-of-Disk-Space errors|
|/l+ <log filename>||Append to existing log file|
|/lp <log filename>||Summary information about target system and application directory paths|
|/l* <log filename>||Log all information (/l *v logs all information in verbose mode)|
Note that the /l *v option logs everything that the Installer and the MSI package do to a system, so the log files can get quite large. For instance, something like Office may generate a log file between 1 and 10 MB, depending on the options you choose to install. But if you need to track everything that an MSI package is doing to a system, /l *v is a great option.
Logging problematic GPO processes is not detailed enough in Windows 2000’s default logging configuration. For this reason, adding various values to Windows Registry subkeys to switch on verbose logging of GPO processes can help you determine what the problems might be. Verbose logging increases the size of Event Viewer logs (sometimes dramatically), so Event Viewer parameters may need to be adjusted accordingly. Remember that a complete registry backup should precede any changes to the registry so that a system may be recovered if there is a failure after fiddling with the registry.