The information logged with Group Policy events is fairly terse. If you want more detail, there are several registry keys you can modify:

Use the Registry Editor to add one or more of these values or modify the values if they already exist. By making these changes to the registry, you enable full logging for Group Policy and you can get more detail during the Group Policy processing cycle. However, full logging results in a much larger number of events being sent to the Application event log, so you should enable it only during periods when you need to troubleshoot core Group Policy processing.

When you enable full logging, each step of the Group Policy processing cycle is sent to the application event log, including details of what happens along the way. There will be events marking the beginning and ending of Group Policy processing. In between, you can view what is happening as each GPO that must be processed for a given computer and user is enumerated and then the CSEs are called to process policy.

You access event logs on a local or remote machine by completing the following steps:

Table 16-1 lists the main event sources reported by Group Policy. Within each event source are common event IDs that refer to problems with that particular area of Group Policy processing.

Table 16-2 lists the most common event IDs for each event source. These event IDs are taken from the Group Policy Management Pack for Microsoft Operations Manager. These event IDs typically indicate some kind of problem related to that Group Policy processing area. However, in some cases they simply indicate that Group Policy processing was completed successfully.

As with the application logs, the Userenv information logged is fairly terse. If you want more detail, you can increase the verbosity of the logging to see all Group Policy–related events. To do so, you must modify the UserEnvDebugLevel registry value under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon.

You use the Registry Editor to add the UserEnvDebugLevel registry value or to modify it if the value already exists. UserEnvDebugLevel can have the following values:

You can disable all Userenv logging by setting the value to 0x00000000. The default logging mode is normal with log filing, so the value is 0x00010001. If you want verbose logging with a log file, you can combine the verbose value (0x00000002) with the log file value (0x00010000) to get 0x00010002.

Note

Userenv logging provides both detailed Group Policy and user profile logging, so you must be prepared to parse through events that aren’t relevant to Group Policy to get real value out of the log.

You must have some understanding of the structure and format of Userenv.log to benefit from it. Each line of the file represents an event within the Group Policy processing cycle. For example, the following line is usually the first event you see when Group Policy processing begins. (In this case, it’s a background refresh of Group Policy.)

USERENV(2c0.13c) 21:07:48:573 ProcessGPOs: Starting user Group Policy (Background)
processing...

You will notice that every line in the file begins with USERENV. The number in parentheses, in this case 2c0.13c, indicates the process and thread IDs that are running that step of the processing cycle. Most often, the process ID corresponds to the Winlogon process, under which Group Policy processing runs. The number 21:07:48:573 indicates the time of day when that event was logged. The ProcessGPOs tag of the event usually indicates the name of the API being called. This is usually followed by a description of the event; in this case, it indicates that user-specific background processing is occurring.

Tip

A date stamp is not included in Userenv.log file events, but newer events are appended to the end of the file. During a background processing event, especially one triggered by gpupdate, user and computer processing happens in parallel, and you might see the same starting message shown above for background computer processing, right after the user processing message appears. You can identify which subsequent processing step belongs to computer or user processing by viewing the thread ID—user and computer processing will have different thread IDs for the same process.

Normally, the first reported events, after the message indicating the beginning of Group Policy processing, constitute a slow-link test. During the test, three pairs of pings are sent to determine the speed of the link between the computer processing Group Policy and its domain controller. This test, as it appears in Userenv.log, will look similar to the following:

USERENV(4c0.378) 16:23:50:792 PingComputer: Adapter speed 11000000 bps
USERENV(4c0.378) 16:23:50:962 PingComputer:  First time:  129
USERENV(4c0.378) 16:23:51:122 PingComputer:  Second time:   141
USERENV(4c0.378) 16:23:51:302 PingComputer:  First time:  175
USERENV(4c0.378) 16:23:51:443 PingComputer:  Second time:    131
USERENV(4c0.378) 16:23:51:443 PingComputer:  Second time  less  than first  time.
USERENV(4c0.378) 16:23:51:543 PingComputer:  First time:  96
USERENV(4c0.378) 16:23:51:683 PingComputer:  Second time:    135
USERENV(4c0.378) 16:23:51:683 PingComputer:  Transfer  rate:    1280  Kbps
Loop count:  2

The transfer rate shown here is the calculated link speed, which is compared to the slow-link threshold. If a slow link is found, this changes the behavior of certain CSEs.

After the slow-link test, the next task is to locate the GPOs that apply to this user or computer, by querying Active Directory. These events typically appear as follows:

USERENV(2c0.13c) 21:07:52:372 SearchDSObject: Searching <DC=cpandl,DC=com>
USERENV(2c0.13c) 21:07:52:372 SearchDSObject: Found GPO(s):    <[LDAP://CN={31B2F340-
016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cpandl,DC=com;0]>

The first event in this listing shows that the domain (as opposed to a site or an OU) is being searched. The next event shows that a link to a GPO has been located on the domain—and the path to the GPC is returned.

Once all linked GPOs have been found, Group Policy processing determines whether the computer and user have access to the GPO (for example, whether the GPO is filtered using security groups to prevent processing). This step typically looks like the following:

USERENV(2c0.13c) 21:07:52:452 ProcessGPO: Searching <CN={31B2F340-016D-11D2-945F-
00C04FB984F9},CN=Policies,CN=System,DC=cpandl,DC=com>
USERENV(2c0.13c) 21:07:52:452 ProcessGPO: User has access to this GPO.
USERENV(2c0.13c) 21:07:52:452 ProcessGPO: GPO passes the filter check.

When all GPOs are searched like this, the GPC for each GPO is examined to determine the GPO’s friendly name, its version number, any flags that might be set (for example, the GPO is disabled or part of the GPO is disabled), and what CSEs have been implemented for that GPO. This is shown in the following lines:

USERENV(2c0.13c) 21:07:52:622 ProcessGPO: Found common name of:
<{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(2c0.13c) 21:07:52:622 ProcessGPO:    Found display name of:
<Default Domain Policy>
USERENV(2c0.13c) 21:07:52:622 ProcessGPO:    Found user version of:
GPC is 7, GPT is 7
USERENV(2c0.13c) 21:07:52:622 ProcessGPO:    Found flags of:    0
USERENV(2c0.13c) 21:07:52:622 ProcessGPO:    Found extensions:  [{3060E8D0-7020-11D2-
842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}][{C6DC5466-785A-11D2-84D0-
00C04FB169F7}{BACF5C8A-A3C7-11D1-A760-00C04FB9603F}]

The Found extensions statement lists the GUIDs of the CSEs that are used within this GPO. This information is used to tell Group Policy processing which CSEs need to be called during this processing cycle. Next, each CSE runs and processes its policies. The following line shows the Administrative Templates (Registry) CSE running:

USERENV(2c0.13c) 21:07:52:783 ProcessGPOs: Processing extension Registry

The first thing the registry CSE does after starting up is to delete any existing policy values so that it can reapply them from scratch. This delete operation is captured in the following lines:

USERENV(2c0.13c) 21:07:52:813 DeleteRegistryValue: Deleted SoftwarePolicies
MicrosoftConferencingUse AutoConfig
USERENV(2c0.13c) 21:07:52:823 DeleteRegistryValue: Deleted SoftwarePolicies
MicrosoftConferencingConfigFile

In this case, only two policies have been set for this user, so only two need to be deleted. After the existing policies are deleted, any registry policy from any GPOs that apply are processed, as shown in the following lines:

USERENV(2c0.13c) 21:07:52:823 ParseRegistryFile: Entering with<C:WINDOWSSystem32
GroupPolicyUser
egistry.pol>.
USERENV(2c0.13c) 21:07:52:823 SetRegistryValue:  Use AutoConfig => 1    [OK]
USERENV(2c0.13c) 21:07:52:823 SetRegistryValue:  ConfigFile =>      [OK]
USERENV(2c0.13c) 21:07:52:823 ParseRegistryFile:  Leaving.

The first line indicates that the registry CSE is reading from the local GPO’s Registry.pol file to obtain registry policy settings. The two SetRegistryValue lines show the registry values that are being applied from the Registry.pol, although they don’t indicate the full path to the registry setting being applied. The final line indicates that registry policy processing has been completed. After the registry CSE does its work, each subsequent CSE is processed in turn and shows events in the Userenv.log file. When a CSE runs, if it finds that the GPO it is processing hasn’t changed since the last processing cycle and if no GPOs have been deleted, it simply passes on to the next CSE, as shown in the following lines:

SERENV(2c0.13c) 21:07:52:953 ProcessGPOs: Processing extension Scripts
USERENV(2c0.13c) 21:07:52:953  CompareGPOLists:    The lists are the same.
USERENV(2c0.13c) 21:07:52:953  CheckGPOs: No GPO changes but couldn't read extension
Scripts's status or policy time.
USERENV(2c0.13c) 21:07:52:953  ProcessGPOs: Extension Scripts skipped because both
deleted and changed GPO lists are empty.

In this listing, the Scripts CSE has run, but as the last line shows, no changed or deleted GPOs have been found, so Scripts processing is skipped.

Each CSE lists what it is doing in detail, although some CSEs are more detailed than others in terms of how much useful information they write to the Userenv.log. In the next section, we’ll look at how to enable some CSE-specific logging when the information found in Userenv.log is not sufficient. When Group Policy processing has completed, the following lines appear:

USERENV(2c0.13c) 21:07:53:053 ProcessGPOs: User Group Policy has been applied.
USERENV(2c0.13c) 21:07:53:053 ProcessGPOs: Leaving with 1.
USERENV(2c0.13c) 21:07:53:053 GPOThread:  Next refresh will happen in 107 minutes

This listing shows that the user Group Policy processing cycle has completed and that the next background refresh will happen in 107 minutes.

You can enable detailed debugging logging for Windows Installer policy by modifying the AppmgmtDebugLevel registry value under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDiagnostics. Use the Registry Editor to add the AppmgmtDebugLevel registry value or modify it if the value already exists. Set the value to 0x0000004b.

After you add this registry value, a new log file is created under %windir%debugusermode called Appmgmt.log. This log file captures all events related to software installation policy. For example, the following lines capture errors related to the attempted deployment of Microsoft Visio^® Professional 2003:

Assigning application Microsoft Office Visio Professional 2003 from policy Visio
Deployment.
Application Microsoft Office Visio Professional 2003 from policy Visio Deployment is
 configured to remove any unmanaged install before being assigned.
Calling the Windows Installer to advertise application Microsoft Office Visio
Professional 2003 from script C:WINDOWSsystem32appmgmtS-1-5-21-817735531-
4269160403-1409475253-1107{32cb86da-f34c-4074-9855-d86a2c689d64}.aas with flags 61.
The assignment of application Microsoft Office Visio Professional 2003 from policy
Visio Deployment succeeded. Calling the Windows Installer to install application
Microsoft Office Visio Professional 2003 from policy Visio Deployment.
The install of application Microsoft Office Visio Professional 2003 from policy
Visio Deployment failed. The error was : %1612

Removing application Microsoft Office Visio Professional 2003 from the software
installation database.
Calling Windows Installer to remove application advertisement for application
Microsoft Office Visio Professional 2003 from script C:WINDOWSsystem32appmgmt
S-1-5-21-817735531-4269160403-1409475253-1107{32cb86da-f34c-4074-9855-d86a2c689d64}.aas.
The removal of the assignment of application Microsoft Office Visio Professional
2003 from policy Visio Deployment succeeded.

Policy Logging for Software Management is attempting to log application Microsoft
Office Visio Professional 2003 from policy Visio Deployment.
Failed to apply changes to software installation settings. Software changes could
not be applied. A previous log entry with details should exist. The error was :
%1612

Software installation extension returning with final error code 1612.

As this listing shows, Windows Installer attempts to deploy Visio via assignment, but it first checks to make sure that no unmanaged versions of Visio need to be unin-stalled. Windows Installer then calls the Application Assignment Script (.aas file) that was cached in the folder C:WINDOWSsystem32appmgmtS-1-5-21-817735531-4269160403-1409475253-1107. The SID name at the end of this folder indicates that this is a per-user installation.

The application assignment script execution succeeds, but when Windows Installer runs the actual installation of Visio, the installation fails with an error 1612. This Windows Installer error indicates that the source .msi file is either not available or not accessible (for example, the user might not have permission to read the file from the share where it’s stored). Windows Installer then removes the application assignments that it made using the .aas file and then returns the final 1612 error code.

The Appmgmt.log file can be useful in pointing out obvious errors, such as the error just mentioned, where the user might not have appropriate permission to view the package. In other cases, you might not get enough detail from the Appmgmt.log file to successfully troubleshoot the problem. In that case, the best approach is to use Windows Installer logging to view the steps that Windows Installer took during the attempted installation.

Windows Installer logging is enabled by default, but you can increase the verbosity of logging by modifying the Logging policy under Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Installer. You can choose from a number of logging levels. To enable full logging, specify iweaprucmvo as the logging option (Figure 16-12).

Figure 16-12. Enabling verbose Windows Installer logging through Administrative Template policy

When Windows Installer logging is enabled, log files are written to the temporary folder on the computer. By default, this folder is located at %Windir% emp. The log file that is created is named with a sequential file name starting with MSI (for example, MSI1a77f.log). The following listing shows an example of the kind of verbosity you get from the Windows Installer log. Every step of the installation process is logged, as shown here:

=== Verbose logging started: 1/30/2005   8:40:05
Build type: SHIP UNICODE 3.00.3790.2180   Calling process:
??C:WINDOWSsystem32winlogon.exe  ===
MSI  (c)  (BC:74) [08:40:05:338]: User policy value 'DisableRollback' is 0
MSI  (c)  (BC:74) [08:40:05:338]: Machine policy value 'DisableRollback' is 0
MSI  (c)  (BC:74) [08:40:05:348]: Executing op: Header(Signature=1397708873,
Version=301,Timestamp=842940553,LangId=1033,Platform=0,ScriptType=3,
ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=0)
MSI  (c)    (BC:74) [08:40:05:348]: Executing op: ProductInfo(ProductKey={90510409-6000-
11D3-8CFE-0150048383C9},
ProductName=Microsoft Office Visio Professional 2003,PackageName=VISPRO.MSI,
Language=1033,Version=184552592,Assignment=1,ObsoleteArg=0,ProductIcon=misc.exe,6,
PackageMediaPath=ENGLISHOFFICE_SYSTEMVISIO2003,PackageCode={0C7A8254-2463-495B-
BA6A-AD74E3A5FEF1},,,InstanceType=0,LUASetting=0)
MSI  (c)  (BC:74) [08:40:05:348]: SHELL32::SHGetFolderPath returned: C:Documents  and
SettingsdebbiecApplication  Data
MSI  (c)  (BC:74) [08:40:05:348]: Executing op: DialogInfo(Type=0,Argument=1033)
MSI  (c)  (BC:74) [08:40:05:348]: Executing op: DialogInfo(Type=1,Argument=Microsoft
Office Visio Professional  2003)
MSI  (c)    (BC:74) [08:40:05:348]: Executing op: RollbackInfo(,RollbackAction=Rollback,
RollbackDescription=Rolling back  installation,RollbackTemplate=[1],CleanupAction=
RollbackCleanup,CleanupDescription=Removing  backup  files,CleanupTemplate=File: [1])
MSI  (c)    (BC:74) [08:40:05:358]: Executing op: ActionStart(Name=MsiPublishAssemblies,
Description=Publishing  assembly information,Template=Application Context:[1],
Assembly Name:[2])
MSI  (c)  (BC:74) [08:40:05:358]: Executing op: AssemblyPublish(Feature=Forms_PIA,
Component={835AC3CE-E36B-4D65-B50F-
2863A682ABEE},AssemblyType=1,,AssemblyName=Microsoft.Vbe.Interop.Forms,Version="11.0
.0.0000",Culture="neutral",PublicKeyToken="71e9bce111e9429c",FileVersion="11.0.5530.
0",)

If you are familiar with the installation package and you can follow the log, this level of detail can be useful in troubleshooting installation problems. To prevent too much detail from being generated, you can modify the Administrative Templates policy for Windows Installer logging.

You can enable detailed debugging logging for Folder Redirection policy by modifying the FdeployDebugLevel registry value under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDiagnostics. Use the Registry Editor to add the FdeployDebugLevel registry value or modify it if the value already exists. Set the value to 0x0000000F to enable logging. To disable logging, set the value to 0x00000000.

When the FdeployDebugLevel registry value is set for logging, log events related to Folder Redirection policy are written to the file %windir%DebugUserModefdeploy.log whenever Folder Redirection policy is subsequently processed. You get a log file that looks similar to the listing here:

09:25:21:984 Entering folder redirection extension
09:25:21:984 Flags = 0x0
09:25:22:024 Group Policy Object name = {0E35E0ECFD6D-4CEF-9267-6EDB00694026}
09:25:22:024 File system path = \cpandl.comSysVolcpandl.comPolicies{0E35E0EC-
FD6D-4CEF-9267-6EDB00694026}User
09:25:22:024 Directory path = LDAP://CN=User,cn={0E35E0EC-FD6D-4CEF-9267-
6EDB00694026},cn=policies,cn=system,DC=cpandl,DC=com
09:25:22:024 Display name =  Marketing Folder Redirection Policy
09:25:22:044 Found folder redirection settings for policy Marketing Folder
Redirection Policy.
09:25:22:084 The  user was found  to  be a member of  the group  s-1-1-0.
The corresponding path was \%HOMESHARE%%HOMEPATH%.
09:25:22:084 Successfully obtained redirection data for My Documents, (Flags: 0x31).
09:25:22:084 Successfully obtained redirection data for My Pictures, (Flags: 0x2).
09:25:22:084 Querying the DS for user debbiec's home directory.
09:25:22:334 Obtained home directory : \corpsvr01homedebbiec.
09:25:22:344 Homedir redirection path %HOMESHARE%%HOMEPATH% expanded to \corpsvr01
homedebbiec.
09:25:22:344 Successfully gathered folder redirection settings for policy Marketing
Folder Redirection Policy.
09:25:22:344 Homedir redirection path %HOMESHARE%%HOMEPATH% expanded to \corpsvr01
homedebbiec.
09:25:22:344 Redirecting folder My Documents to \%HOMESHARE%%HOMEPATH%.
09:25:42:453 Previous folder path C:Documents and SettingsdebbiecMy Documents
expanded to C:Documents and SettingsdebbiecMy Documents.
09:25:42:453 New folder path \%HOMESHARE%%HOMEPATH% expanded to \corpsvr01home
debbiec.
09:25:42:513 Contents of redirected folder My Documents will be copied to the new
location.
09:25:43:304 Homedir redirection path %HOMESHARE%%HOMEPATH%My Pictures expanded to
\corpsvr01homedebbiecMy Pictures.
09:25:43:304 Redirecting folder My Pictures to \%HOMESHARE%%HOMEPATH%My Pictures.
09:25:43:415 Previous folder path C:Documents and SettingsdebbiecMy DocumentsMy
Pictures expanded to C:Documents and SettingsdebbiecMy DocumentsMy Pictures.
09:25:43:415 New folder path \%HOMESHARE%%HOMEPATH%My Pictures expanded to
\corpsvr01homedebbiecMy Pictures.
09:25:43:595 Contents of redirected folder My Pictures will be copied to the new
location.
09:25:44:025 Previous contents of folder My Pictures at C:Documents and Settings
debbiecMy DocumentsMy Pictures will be deleted.
09:25:44:086 Successfully redirected folder My Pictures.
The folder was redirected from <C:Documents and SettingsdebbiecMy Documents
My Pictures>to<\corpsvr01homedebbiecMy Pictures>.

09:25:44:086 Previous contents of folder My Documents at C:Documents and Settings
debbiecMy Documents will be deleted.
09:25:44:236 Successfully redirected folder My Documents.
The folder was redirected from <C:Documents and SettingsdebbiecMy Documents> to
<\corpsvr01homedebbiec>.

09:25:44:236 Disabling permission for user redirection of My Documents.
09:25:44:336 Successfully updated the shortcut to My Pictures in <\corpsvr01home
debbiec>.

As the listing shows, Folder Redirection policy processing is tracked from beginning to end. In this example, the user debbiec has logged on to her computer for the first time and is getting her My Documents and My Pictures folder redirected to her home share. The Folder Redirection CSE starts off by enumerating the GPC and GPT paths for the GPO that will provide the policy. It then determines that the user is a member of the Everyone group (SID S-1-1-0) and needs to be redirected to %HOMESHARE% %HOMEPATH%. It then queries Active Directory for the user’s home path location and then redirects the user’s My Documents and My Pictures folders from the local user profile to the server share.

In another example of failed Folder Redirection policy, you can use the Fdeploy.log file to track down the cause. The following listing shows a failed redirection for the user joew.

09:38:44:609 Entering folder redirection extension
09:38:44:609 Flags = 0x0
09:38:44:649 Group Policy Object name = {0E35E0ECFD6D-4CEF-9267-6EDB00694026}
09:38:44:659 File system path = \cpandl.comSysVolcpandl.comPolicies{0E35E0EC-
FD6D-4CEF-9267-6EDB00694026}User
09:38:44:659 Directory path = LDAP://CN=User,cn={0E35E0EC-FD6D-4CEF-9267-
6EDB00694026},cn=policies,cn=system,DC=cpandl,DC=com
09:38:44:659 Display name = Marketing Folder Redirection Policy
09:38:44:679 Found folder redirection settings for policy Marketing Folder
Redirection Policy.
09:38:44:769 The user was found to be a member of the group s-1-1-0. The
corresponding path was \%HOMESHARE%%HOMEPATH%.
09:38:44:769 Successfully obtained redirection data for My Documents, (Flags:  0x31).
09:38:44:769 Successfully obtained redirection data for My Pictures, (Flags: 0x2).
09:38:44:769 Querying the DS for user joew's home  directory.
09:38:45:019 Obtained home directory : .
09:38:45:019 Homedir redirection path %HOMESHARE%%HOMEPATH% expanded to.
09:38:45:019 Successfully gathered folder redirection settings for policy Marketing
Folder Redirection Policy.
09:38:45:029 Homedir redirection path %HOMESHARE%%HOMEPATH% expanded to.
09:38:45:029 Redirecting folder My Documents to \%HOMESHARE%%HOMEPATH%.
09:38:45:039 Failed to perform redirection of folder My Documents.
The full source path was <C:Documents and SettingsjoewMy Documents>.
The full destination path was<>.
At least one of the shares on which these paths is currently offline.

As you can see, this listing indicates that Folder Redirection policy is unable to properly redirect his My Documents folder. This is a relatively straightforward problem, but without this log file or the application event log, you would not get any outward evidence of what caused the problem.

The Security Policy CSE plays an important role in the management of your Windows-based computers—it’s responsible for ensuring that critical security configurations are always applied as expected. When security policy processing fails, you need to know about it. The Application event log is the first place to look to help locate the problem, but when you need more detailed logging, you can enable an additional log file for Security policy called Winlogon.log.

You do this by modifying the ExtensionDebugLevel registry value under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonGPExtensions{827D319E-6EAC-11D2-A4EA-00C04F79F83A}. Use the Registry Editor to add the ExtensionDebugLevel registry value or modify it if the value already exists. Set the value to 0x00000002. To disable security logging, set this value to 0x00000000.

When this value is enabled, Winlogon.log is created under %Windir%securitylogs. This log tracks security policy processing events, as shown in the following listing:

Process GP template gpt00001.inf.
-------------------------------------------
Sunday, January 30, 2005 10:05:20 AM
   Administrative privileged user logged on.
   Parsing template C:WINDOWSsecurity	emplatespoliciesgpt00001.inf.
----Configuration engine was initialized successfully.----
----Reading Configuration Template info...
----Configure Group Membership...
   Configure CPANDLDesktop Admins.
   Group Membership configuration was completed successfully.
----Configure Security Policy...
     Start processing undo values for 7 settings.
     There is already an undo value for group policy setting <MinimumPasswordLength>.
     There is already an undo value for group policy setting <PasswordHistorySize>.
     There is already an undo value for group policy setting <MaximumPasswordAge>.
     There is already an undo value for group policy setting <MinimumPasswordAge>.
     There is already an undo value for group policy setting <PasswordComplexity>.
     There is already an undo value for group policy setting <RequireLogonTo-
ChangePassword>.
     There is already an undo value for group policy setting <ClearTextPassword>.
   Configure password information.
     Start processing undo values for 3 settings.
     There is already an undo value for group policy setting <LockoutBadCount>.
     There is already an undo value for group policy setting
<ForceLogoffWhenHourExpire>.
   Configure account force logoff information.
   System Access configuration was completed successfully.
   Audit/Log configuration was completed successfully.
   Configure machinesystemcurrentcontrolsetserviceslanmanserverparameters
autodisconnect.
     There is already an undo value for group policy setting <machinesystem
currentcontrolsetserviceslanmanserverparametersautodisconnect>.
   Configuration of Registry Values was completed successfully.
----Configure available attachment engines...
   Configuration of attachment engines was completed successfully.
----Un-initialize configuration engine...
this is the last GPO.

In this example, security policy processing is working from the cached copy of the security template file that it received from the GPO. This file is called Gpt00001.inf and it is stored in the %SystemRoot%security emplatespolicies folder. The first task it per forms is to configure group membership, also known as Restricted Group policy, to add a group called Desktop Admins to another group. It then processes the rest of security policy, including account policy information (which, in this case, needs to be removed) and any other security-related policy that has been set. Any problems with security policy processing will appear in this log file, so you can often use the file to determine the nature of the problem.