ACTIVE DIRECTORY WINDOWS 2000/2003: September 2007

Group Policy Infrastructure Requirements

Problems with the application of Group Policy often involve the technologies on which Group Policy depends, or with easy-to-correct oversights in the implementation of Group Policy itself. This section provides a quick review of these dependencies and summarizes how they relate to troubleshooting Group Policy.

Windows Server Domain with Active Directory
Group Policy is not supported in earlier operating systems such as Microsoft® Windows NT® 4.0. Windows NT 4.0 policies cannot be applied using Group Policy. Your Active Directory structure should be designed with an understanding of Group Policy inheritance rules so that it can support your objectives for using Group Policy.

To use the loopback features of Group Policy, the computer must be in a Windows 2000 or Windows Server 2003 domain, as must the user. You cannot deploy Group Policy to users in a Windows NT 4.0 domain by applying loopback to a computer in a Windows 2000 or Windows Server 2003 domain.

Organizational Unit Membership and GPO Links
To receive the Group Policy objects that are created and stored at the domain level, the user or computer must be a member of a site, domain, or organizational unit (OU) that links to a GPO. Group membership is not the basis for Group Policy application, but is used to further restrict the application of the GPO – this is called security filtering.

Network Connectivity and Configuration
For Group Policy to be received at the client there must be network connectivity between the client and the domain controller. Several issues can affect network connectivity:
· TCP/IP is used as the transport for Group Policy, so TCP/IP must be implemented in your network.
· If you use a firewall, be sure that Internet Control Message Protocol (ICMP) is enabled on the network. For more information, see “Internet Control Message Protocol (ICMP)” in Help and Support Center for Microsoft® Windows® Server 2003.
· A user who can log on with cached credentials might not be aware of a connectivity issue.
If a computer’s clock is not synchronized with other clocks on the network, that computer can encounter a variety of problems, including authentication problems. Authentication problems can be masked if a user is able to log on to the computer with cached credentials. In this case, the user appears to have logged on to the network successfully but is unable to access system resources including Group Policy. To check for time synchronization issues, compare the time and date on the client with the time and date on other system resources. To avoid the problem, use the Windows Server 2000 or 2003 Time Service to keep the computers on your network synchronized.

Domain Name System (DNS)
The client uses the fully qualified domain name to access the domain controller (including the SYSVOL share) when reading the GPO. In order for the client to obtain the fully qualified domain name, the Domain Name System (DNS) must be functioning.
If Group Policy settings that apply to that client require access to other network resources, the client-side extensions (CSE) to Group Policy might use DNS to locate those resources.
For best results, do not use host files with DNS. It is more efficient, more scalable, and less error-prone to configure DNS to work dynamically.

SYSVOL Share
GPO information is stored in two locations. The Group Policy container (GPC) portion of the GPO is stored in Active Directory. The Group Policy template portion is stored in a file-based location under the SYSVOL folder on domain controllers. Clients must be able to access the SYSVOL folder and retrieve information from the Group Policy template in order to apply Group Policy settings. For this reason, the SYSVOL share must be accessible to the client. If you suspect SYSVOL problems, first check replication issues, as described in “Replication Convergence”.
Active Directory and File System Replication
Two types of replication are required: Active Directory replication and file system replication. Both must be functioning before you can deploy Group Policy. If Active Directory replication is working properly, but file system replication is not, you might have success when editing or managing Group Policy with Active Directory Sites and Services and with Active Directory Users and Computers, but the application of Group Policy to clients will fail. For more information, see “Replication Convergence”
Default Domain Policy GPO and Default Domain Controllers Policy GPO
Two default GPOs are installed when a domain is created – the Default Domain Policy and the Default Domain Controllers Policy. In general, editing the Default GPO’s is neither necessary nor recommended, with the exception of some security settings that must be edited. If the settings in these default GPOs are incorrectly configured you might have problems with client authentication, directory replication, FRS, and other components. For example, if the default policies are damaged by deleting the Group Policy template files or by modifying the settings in them so that they no longer function as designed, you need to restore them.

In Windows Server 2003 domains, you can do this by using Dcgpofix.exe, which is included with Windows Server 2003 operating systems. In Windows 2000 domains, you can restore the default GPOs to their original settings by using RecreateDefpol.EXE. Any settings that have been added, including those added by applications such as Systems Management Server or Exchange that have been installed on the domain controller, will be lost. There is no tool for repairing the default policies in Windows 2000 domains, but you can repair them manually. See Knowledge Base article:
FRS: Recovering FRS Objects and Files Using System State Restores
http://support.microsoft.com/default.aspx?scid=kb;en-us;811219

Client Operating System
Group Policy relies on client functionality that is built in to Windows 2000, Microsoft® Windows® XP Professional, Windows Server 2003, Windows 2000 Pro and Windows 2000 Server. If the client is running an earlier operating system, it cannot process GPOs and apply Group Policy settings. In addition, some settings are supported only on certain operating systems.

Troubleshooting Group Policy using Group Policy Management Console (GPMC)
Understanding Group Policy Processing
Before discussing Group Policy troubleshooting, you need a general understanding of how Group Policy is processed at the client. Group Policy processing has two distinct phases: core Group Policy processing and CSE processing.

When a client begins to process Group Policy, it must determine whether it can reach a domain controller, whether any GPOs have changed, and what policy settings (based on client side extension) must be processed. The core Group Policy engine performs the processing this in this initial phase.

Policy settings are grouped into different categories, such as administrative templates, security, folder redirection, wireless, IPsec, EFS, and Software Installation. The settings in each category require a specific CSE to process them, and each CSE has its own rules for processing settings. The core Group Policy engine calls the CSEs that are required to process the settings that apply to the client.
Security
In order to administer Group Policy, you must have the necessary privileges to use GPMC and the Group Policy Object Editor. You also need privileges to create GPOs or to manage links from a specific site, domain, or OU to GPOs. Control of existing GPOs can be delegated to specific users or groups, so it is possible for an administrator to be able to use GPMC to view GPOs, but not be able to modify, delete, or link them.
Troubleshooting
· Use Active Directory Users and Computers to verify that the account you are using is a member of a group that has these privileges. (Check the group memberships for the user account, and also verify that the privileges for the group have not been changed.)
· Avoid adding the privileges to an individual user account. If necessary create a new group with a name that clearly indicates its purpose.
· Changes to security groups’ memberships or privileges, or to the permissions on Group Policy objects or actions, need to be replicated to domain controllers throughout the system. Until this replication is completed the changes might be applied unevenly. In rare cases you might want to force replication.
· To see or change the access control lists that affect management of a GPO, open the GPO in GPMC and look at the Delegation tab. The GPO can only be applied by members of groups that have Read permissions. To change the security filters, click Advanced.
You can delegate Group Policy Tasks to users that are not members of Domain Administrators or Group Policy Administrators groups. There are two different roles you can delegate; the permission to create and edit GPOs and the permission to link Group Policy Objects. These can be completely separate roles if required. Here are two of the easiest methods:

1. To delegate GPO Creation/Ownership to a user or group:
Open the GPMC and select ‘Group Policy Objects’ in the Tree View. In the right-hand pane you should see two tabs, Contents and Delegation. Select ‘Delegation’ and Add the User or Group you want to delegate

2. To delegate OU Linking to a user or group
Open the GPMC and select the OU in which you would like to assign the delegation. In the right-hand pane you should see three tabs, select the ‘Delegation’ tab. Add the User or Group you want to delegate.

These same functions can be automated using the sample scripts provided with the GPMC (held in Program Files\GPMC\Scripts):

To delegate GPO Creation/Ownership on a domain to a user or group
SetGPOCreationPermissions.wsf

To delegate OU Linking to a user or group
SetSOMPermissions.wsf

Exposing Preferences in Administrative Templates
Administrative Templates can contain both true policies and preferences, but by default the Group Policy Object Editor exposes only true policies. To expose preferences, highlight the Administrative Templates node for which you want to see preferences. On the View menu, click Filtering, and then clear the Only show policy settings that can be fully managed check box.

Troubleshooting Group Policy Core Functionality
Flowchart for Troubleshooting Group Policy Core Functionality
Use the flowchart (see Figure 1) in this section to quickly identify the likely root causes for unexpected Group Policy behavior, based on three questions that are easily answered from the Group Policy Results rehatport.

Here is an example of how you can use the flowchart:

You have created a new setting in a GPO, but the setting is not being applied to a specific computer / user combination where you expect it to be applied. You generate a Group Policy Results report for that computer and user. The report shows that the GPO has been applied, but the setting is not listed in the report. Following the decision points in the flowchart you find replication, Group Policy refresh, operating system support, and slow link processing as potential causes. You determine that replication and Group Policy refresh seem the most likely reasons for the problem.

Based on the information presented there, you decide that for the case you are investigating Group Policy refresh seems the more likely cause, with replication as a possible but less likely culprit.

Looking at the troubleshooting tips for Group Policy refresh, you conclude that this is the probable cause and one that you can easily test by running GPupdate or Secedit /refreshpolicy. After you run GPupdate or Secedit /refreshpolicy, you see the desired behavior on the client. When you refresh the Group Policy Results report for that computer with that user logged on, you see that the setting as been applied and that the GPO you modified was the winning GPO.
Figure 1 Group Policy Troubleshooting Flowchart
Navigating the Troubleshooting Flowchart
The troubleshooting flowchart focuses on core Group Policy processing. Its primary purpose is to help you validate that the underlying infrastructure is in place to support delivery of GPOs to the client, that the user and computer are appropriately targeted to receive the intended GPOs, and that Group Policy processing puts the correct GPOs into effect.
A Group Policy Results report is the primary resource for troubleshooting Group Policy using this flowchart. Specifically, when investigating a problem, the administrator — where possible — should generate a Group Policy Results report for the user and computer combination encountering the problem. The sections of the report contain the information you use to navigate through the flowchart. For instructions on generating a Group Policy Results report, see “Determine Resultant Set of Policy with Group Policy Results” in GPMC Help.
An example of a Group Policy Results report is shown in Figure 2.
Figure 2 Example of a Group Policy Results Report
This example shows the Summary tab of the report with the Group Policy Objects sections under Computer Configuration Summary and User Configuration Summary expanded.
By examining the GPMC Results report, you can find answers to the following three basic questions associated with the flowchart:
· Was the GPO applied to the client? The Summary tab shows this information.
· Is the policy setting listed in GPMC Results? The Settings tab shows this information.
· Is the GPO listed as Denied in GPO Results? The Summary tab shows this information.
Each question is answered under the following headings that correspond to the flowchart in Figure 3.
GPO Applied, Policy Setting Listed
In this scenario the client has successfully received the GPO and the specific policy setting is in effect at the client. This means that the only problem is that the actual value of the policy setting is incorrect. See the Settings tab of the Group Policy Results report for information about the individual settings that have been applied.
Figure 3 GPO Applied, Policy Setting Listed
The following factors can contribute to this scenario:
GPO Inheritance (Setting Listed)
Although GPOs have been applied, and the correct policy setting is listed, Group Policy inheritance might result in an unexpected GPO “winning” and providing a different value from the one expected. The settings are nested by source and type; click Show on the nested rows to expose the settings. Then look at the Winning GPO column to discover which GPO defines the value for the policy setting. For more information, see Group Policy Inheritance Rules in the section Details for Troubleshooting Core Group Policy Application Functionality.
Replication (Setting Listed)
After a change is made to either the GPO or the user or computer, that change must be replicated throughout the network. If you expected the winning GPO to supply a value for the setting other than the value that was actually applied, it might be that the GPO was changed recently, but the change has not yet been replicated to the domain controller that supplied the GPO to the client. For more information, see “Replication Convergence” .
Group Policy Refresh (Setting Listed)
If Group Policy Refresh has not occurred since the winning GPO was modified and replicated, the old value for the setting is applied. After the changes to a GPO have been replicated to the client’s domain controller, they need to be transmitted to the client. This occurs when the client refreshes Group Policy. Until this has occurred the change will not be reflected at the client. You can either wait for a background refresh or force the refresh. For more information, see Group Policy Refresh.
Asynchronous Application of Group Policy (Setting Listed)
Group Policy can be applied after the computer has started and the user has logged on. This is called asynchronous application of Group Policy, in contrast to synchronous processing that occurs as part of startup or logon.

If the problem is with a setting that can only be applied during startup or logon, it might have been detected during asynchronous Group Policy processing – for example as part of a Group Policy refresh or during the asynchronous processing used for logon optimization in Windows XP. For more information, see Asynchronous Processing and Logon Optimization in Windows XP.
Client-Side Extension Issue (Setting Listed)
After the core Group Policy engine has completed initial processing of the GPOs, it passes specific settings to CSEs to process. If the setting is listed but the value is wrong or the behavior on the client does not reflect the setting value, the failure might have occurred after this setting was passed to a CSE to process. For example, even if a Folder Redirection setting has been successfully passed to the Folder Redirection CSE, the CSE might not be able to complete processing for the setting. For more information, see Details for Troubleshooting Client-Side Extensions.
Loopback Processing (Setting Listed)
Loopback processing is a way to enforce a set of user settings at a computer regardless of who logs on at that computer. Typically, user settings are applied based on the site and OU membership of the user. If loopback processing is set for a computer, the user settings for anyone logged on to that computer are dependent (partially or fully) on the site and OU membership of the computer. The behavior depends on the mode of loopback processing. In Replace mode, only the user settings defined in GPOs applied to the computer are used. In Merge mode, user settings from GPOs that would normally apply to the user are used provided they do not conflict with user settings in GPOs that apply to the computer.

Loopback processing only works if the computer and user are both in Windows 2000 or Windows Server 2003 domains. They can be in different domains, and one can be in a Windows 2000 domain while the other is in a Windows Server 2003 domain. You cannot deploy Group Policy to users in a Windows NT 4.0 domain by applying loopback to a computer in a Windows 2000 or Windows Server 2003 domain.

Security filters can affect the way loopback processing is applied. Even when the GPOs associated with the computer are used to define user settings, the user’s credentials – not the computer’s credentials – are validated against the GPO’s security filter. Therefore the user’s credentials determine whether the GPO should be applied.
For example, you could create a GPO with a security filter that restricts the GPO to system administrators, and then associate that GPO with a computer that is configured for loopback processing. The settings in that GPO would only be applied when a system administrator is logged on.

To determine whether loopback processing is in effect, look for the User Group Policy loopback processing mode setting on the Settings tab of the report, under Computer Configuration \Administrative Templates \System/Group Policy. For more information, see Loopback Processing.
GPO Applied, Policy Setting Not Listed
In the Group Policy Results report, the structure of the Settings tab is similar to the structure used in the Group Policy Object Editor. Expand the sections on the Settings tab by clicking Show. If the expected policy setting does not appear at all, either no updated GPO containing the expected setting reached the client, or the setting might not be processed at the client.

Figure 4 GPO Applied, Policy Setting Not Listed
Replication (Setting Not Listed)
After a setting is added to either a GPO, that change must be replicated throughout the network. If the setting is specified in the GPO but is not listed in the Group Policy Results report on the client, it might be that the setting was recently added to the GPO, but the change has not yet been replicated to the domain controller that supplied the GPO to the client.. For more information, see “Replication Convergence”.
Group Policy Refresh (Setting Not Listed)
If Group Policy Refresh has not occurred since the winning GPO was modified and replicated, a newly added setting will not be applied. After the changes to the GPO have been replicated to the client’s domain controller, they need to be transmitted to the client. This occurs during Group Policy refresh. You can either wait for a background refresh or force the refresh by running gpupdate, by logging off/on (for user configuration), or by restarting the computer (for computer configuration). For more information, see Group Policy Refresh.
Lack of Operating System Support (Setting Not Listed)
Some policy settings are supported on only certain operating systems or require a minimum service pack to be applied. When a GPO delivers a policy setting to a client computer that does not support that setting, the operating system ignores the setting.
GPO Not Applied, Listed as Denied
If the GPO successfully reaches the client, it appears either in the list of Denied GPOs or in the list of Applied GPOs. A GPO can be explicitly denied for any of a number of reasons.
Figure 5 GPO Not Applied, Listed as Denied
To determine whether a GPO is denied, look on the Summary tab or the Group Policy Results report. Under Computer Configuration Summary and again under User Configuration Summary, click Show to expand Group Policy Objects, and then show Denied GPOs. The reason for the denial is given for each denied GPO.
Security Filtering (GPO Denied)
The user or computer does not have the user rights assigned for the GPO. The required privileges are Read and Apply Group Policy. Alternatively, a GPO might be associated with a Deny ACE, which overrides any other privileges granted to the user or computer. For more information, see Access Control and Security Filtering.
Disabled Link (GPO Denied)
There is a link to the GPO from a site, domain, or OU in the hierarchy of the user or computer, but that link has been explicitly disabled. You can quickly scan the navigation pane of GPMC for disabled links.
Inaccessible GPO (GPO Denied)
There is a link to the GPO, but the GPO cannot be accessed. There are several possible reasons for this:
The permissions on the GPO or on folders in the path to the Group Policy template are insufficient for it to be accessed and read. If this situation occurs the Component Status section of the Group Policy Results report will indicate Failure for the component Group Policy Infrastructure.
The GPO might have been deleted, but the link to it remains for some reason (such as replication lag).
Network connectivity problems might prevent access to the GPO.
The client is unable to contact any domain controller.
The policy belongs to another domain of the forest to which the trust is broken.

For more information, see the sections Missing or Corrupted Files, Replication, and Access Control and Security Filtering.
Empty GPO (GPO Denied)
A GPO will be denied if it has no settings. This occurs when an administrator has configured a GPO and linked to it, but has not set any policy settings within the GPO. Either remove the link to the GPO or add policy settings to the GPO. If there are no remaining links to the GPO, you might want to delete it.
WMI Filter (GPO Denied)
A WMI filter applied to a GPO is essentially a Boolean (true/false) decision as to whether the entire GPO should be applied to the client computer. The filter is evaluated at the client when GPO is applied. Based on the embedded WQL query, the GPO will either be enabled or disabled. See WMI Filtering for further details.
GPO Neither Applied nor Denied
All the GPOs that reach the client appear on the Summary tab in either the Group Policy Objects Applied section or the Group Policy Objects Denied section. There are four lists altogether: two lists (Applied GPOs and Denied GPOs) under Computer Configuration Summary for settings that are delivered from the computer’s Active Directory hierarchy, and another two under User Configuration Summary for settings that are delivered from the user’s Active Directory hierarchy. If the GPO is not listed as either Applied or Denied under either Configuration Summary, it did not reach the client.
Also note whether the GPO is listed in the expected Configuration Summary (Computers or Users). That can affect which settings are actually applied, particularly if loopback processing is in effect.
Figure 6 GPO Neither Applied Nor Denied
Scope of Management (GPO Not at Client)
One of the most common causes of a GPO not being applied to a user or computer is that the GPO is not linked to a site, domain, or OU of which the computer or user is a member. GPOs are delivered to clients based on the site and OU memberships of the computer and the logged-on user; group memberships are only used to further restrict application of the GPO. See Organizational Unit (OU) Membership and GPO Links for further details.
Replication (GPO Not at Client)
After an administrator has linked a GPO to a site, domain, or OU in the hierarchy of the user or computer, the change must be replicated to the domain controller from which the client retrieved its GPOs. Also, if the user or computer has recently been added to an OU, the GPOs that apply to that OU might not be applied to the client until the change in OU membership has been replicated to the domain controller from which the client retrieves GPOs. For more information, see “Replication Convergence”.
Group Policy Refresh (GPO Not at Client)
After an administrator has linked a GPO to a site, domain, or OU in the hierarchy of the user or computer, and the change has been replicated to the client’s domain controller, the GPO still needs to reach the client. This occurs during Group Policy refresh. You can either wait for a background refresh or force the refresh. For more information, see Group Policy Refresh.
Network Connectivity (GPO Not at Client)
Group Policy requires a reliable networking infrastructure to ensure appropriate communication between the client computer and a domain controller. This includes TCP/IP, DNS and other dependent technologies, See Network Connectivity for further details.

D etails for Troubleshooting Core Group Policy Application Functionality
Network Connectivity
Obviously, Group Policy cannot be delivered to clients who are not connected to the network. In this case the user can log on with cached credentials, and the last set of policies that the computer received will be applied. This is relevant to a user who logs onto a corporate network through a VPN connection. In this scenario, the usual application of Group Policy does not occur because the user is already logged on to the computer before the VPN connection is established. One way to ensure that the normal Group Policy processing occurs at logon is by using the option to connect to a remote network through the initial logon prompt (Ctrl-Alt-Del).
Other issues that are related to network connectivity with regard to Group Policy application include slow links, DNS problems, and multi-homed clients. These are discussed in this section. A client might also be unable to access network resources due to time sync problems, as discussed in the Infrastructure Requirements at the beginning of this document under Networking.
Network connectivity can also be the root cause of replication problems.
Troubleshooting
To test for network connectivity problems, check system event logs on the client computer (look for failed access attempts). You can also use the ping or netdiag commands to test network connectivity. For more information, see “Using Network Diagnostics” and “Active Directory support tools” in Help and Support Center for Windows Server 2003.
TCP/IP must be enabled on the network and on the client. ICMP is used to detect a slow link when the client initially connects to a domain controller, and therefore is required for Group Policy. ICMP must also be enabled if a firewall is in use. By default, the packet size used for slow link detection is 2048 bytes. Routers and firewalls must also support this packet size to ensure that slow link detection can succeed. For more information, see TCP/IP and ICMP under Infrastructure Requirements earlier in this document.

Slow Links
By default, Group Policy defines a slow link as 500 kilobits per second or less. You can change this setting in the computer configuration, the user configuration, or both. The setting is in the Administrative Templates; look under System and then under Group Policy.
Troubleshooting
When the computer is connected to the network over a slow link, Security settings and Administrative Template settings are always applied.
By default, Software Installation, scripts, and Folder Redirection settings are not applied over a slow link.
Group Policy is not processed if the user connects to the network over a slow link with cached credentials. To ensure that Group Policy is applied over a slow link, the user must select the Logon using dialup connection check box while using the Logon dialog box.
Even if Group Policy settings are configured to run scripts over slow links, the scripts might be executed so slowly that they exceed the configured time-out period. In this case the script will fail to complete and a UserInit event will be posted.

DNS
Group Policy application requires clients to access specified servers, including domain controllers and other servers such as share points and install points. Group Policy management also requires access to domain controllers. DNS is used to locate and identify these servers. In Windows Server 2003, Active Directory requires DNS support.
If the network is functioning, but clients or GPMC consoles are unable to locate the servers, there might be a problem with your network’s DNS system.
Troubleshooting
First, Ping the computer using the NetBIOS name. Then Ping the computer again using the fully qualified domain name of the target computer. If the first Ping works but the second does not then there is probably a DNS problem. Use Netdiag.exe to research the problem further.
Use Dcdiag.exe to troubleshoot domain controllers, and use Netdiag.exe to troubleshoot client computers. These tools can help determine both server and client DNS misconfigurations. For more information, see article Q265706, "DCDiag/NetDiag Facilitate Join and DC Creation" in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=4441).

Multi-Homed Computers
If a client has multiple network adapters connected to multiple networks, assign the highest priority to the network adapter that connects to the network that is providing Group Policy to that client. For more information, see Microsoft Knowledge Base Article 258296 (http://go.microsoft.com/fwlink/?LinkId=17909).

Missing or Corrupted Files
Group Policy information is contained in files on both the domain controllers and the clients. If any of these files are missing or corrupted, only some or none of the policies can be applied. For a brief discussion of this issue, see “SYSVOL Share” earlier in this document.
Troubleshooting
Use GPOtool.exe to check for the presence and integrity of the following files in the SYSVOL share and its subfolders on the domain controller.
Files in the Group Policy template.
Registry.pol (Search %windir%\debug\usermode\UserEnv.log for references to this file). This file is used for processing administrative templates through the registry CSE.
When a process is unable to access a file, it generates an event. Whether this event is recorded depends on the event severity and whether verbose logging is enabled for that process. Check the Policy Events tab in the Group Policy Results report for events that point to problems accessing files. You can also use Event Viewer on the client to view the Application logs, and you can enable and view verbose logging for UserEnv and for specific CSEs to Group Policy. For more information, see “Appendix: Group Policy Log Files.”
On the client, check for the presence and integrity of the following files in the %windir%\system32 folder. Replace suspect or files missing from the CD for the client’s operating system. The System File Checker (Sfc.exe) can be used to scan all protected files to verify their versions.
· UserEnv.dll
· Dskquota.dll
· Fdeploy.dll
· Gptext.dll
· Appmgmts.dll
· Gptext.dll
· Scecli.dll
Replication Convergence
Most networks use more than one domain controller for fault tolerance and performance reasons. Any of these domain controllers can respond to system requests from computers in the domain — authentication requests or Group Policy refresh requests, for example. For consistent behavior throughout the network, all the domain controllers need to be providing the same information to clients. This is accomplished by replicating the data among the domain controllers in a single domain.
Two forms of replication are employed:

· Active Directory replication copies the changes to directory information to the data stores on other domain controllers. The replicated information includes the Group Policy container for each GPO, as well as information about the relationships between Active Directory containers that Group Policy client-side extensions use to determine what Group Policy settings apply to them. Active Directory replication occurs at a set interval and can be forced.
· File Replication service (FRS) copies changes to files to other domain controllers, so that the files are mirrored from one domain controller to another. This includes the SYSVOL share, which contains Group Policy template for each GPO. FRS replication occurs at set intervals according to its replication schedule and can be forced using the new command NTFSUTUL /forcerepl (available in Windows 2000 Service Pack 5 and Windows 2003 Service Pack 1.
· There can be a lag time after a change has been made on one domain controller before the change is replicated to all other domain controllers. The propagation and resolution of these changes throughout the network is an ongoing process called replication convergence.
Troubleshooting
Until changes to a GPO have been replicated to the domain controller a client is accessing, that client will receive the earlier version of the GPO during Group Policy refresh. If you suspect both replication and Group Policy refresh issues, address the replication issue first. Then refresh Group Policy at the client.

Changes to the OU memberships of computers and users also need to be replicated before they can be reflected in Group Policy application at the client. For more information see “Organizational Unit Membership and GPO Links.”
In general, it is best to use the same domain controller for all GPO editing or to agree a process – such as delegated administration of GPO’s – to minimize the likelihood of the same GPO being edited on different domain controller. If changes are made to the same GPO at two different domain controllers, the last change wins. Also, if you delegate control of a specific GPO to a user group, members of that group might be unable to perform the delegated tasks until the permissions have been replicated to their domain controller. For more information see “Domain Controller Selection in the Group Policy Object Editor and GPMC” later in this paper.
There are several options for troubleshooting replication issues:
The Group Policy container and Group Policy template are each assigned version numbers, which are incremented when the GPO is modified. Use GPOTool to verify that the versions are synchronized.
Use Event Viewer to examine the directory service for event log on the domain controller. Active Directory replication errors will appear with source=KCC.
Use Event Viewer to examine the File Replication service event log on the domain controller. FRS errors will appear with source=NTFRS.
Verify that the SYSVOL share exists on the domain controller. You should be able to find \\domain_controller_name\SYSVOL, where domain_controller_name is the fully qualified domain name (not the NetBIOS name) of the domain controller.
To troubleshoot Active Directory replication issues, use replmon.exe and the other Active Directory support tools that ship with Windows Server 2003. These are listed in “Active Directory support tools” in Help and Support Center for Windows Server 2003.
You can use GPOtool.exe to identify problems related to domain controller health, including Active Directory replication and FRS issues.
To troubleshoot file replication issues, check the status of the Directory File Service links and targets as described in “To check status of a DFS root, DFS link, or target” in Help and Support Center for Windows Server 2003. Group Policy requires Directory File Service.
You can use the Sonar.exe tool to check the health of the SYSVOL share.

Group Policy Refresh
Group Policy refresh refers to the retrieval of GPOs by a client. During Group Policy refresh, the client contacts an available domain controller. If any GPOs have changed, the domain controller provides a list of all the appropriate GPOs, regardless of whether their version numbers have actually changed.
Replication and Group Policy refresh are both instances of lag-time issues: the system is working properly, but changes have not yet appeared at the client.
Troubleshooting
By default, GPOs are processed by CSEs at the computer only if the version number of at least one GPO has changed on the domain controller that the computer is accessing. You can use policy settings to change this behavior.
Some CSEs process unchanged GPOs if the user’s group membership has changed.
At startup, Group Policy is refreshed, and computer settings are applied.
Group Policy is refreshed and computer and user settings are applied in the following instances:
When a user logs on.
When gpupdate is run at the client computer.
At the refresh interval, if one is configured at that computer. By default, domain controllers are refreshed every five minutes, and all other computers are refreshed every 90 minutes, with a random factor of up plus or minus 30 minutes.
To see the last time the GPOs from the computer’s OU were processed, look on the Summary tab of the Group Policy Results report under Computer Configuration Summary, and then under General.
To see the last time the GPOs from the user’s OU were processed, look on the Summary tab of the Group Policy Results report under User Configuration Summary, and then under General.
To collect Group Policy refresh information from clients and store them at a central location, use gpmonitor.exe. This tool is included in the Windows Server 2003 Deployment Kit.
Note
Some types of settings can only be applied during logon. These include Folder Redirection, Roaming Profiles, and Software Installation settings. If these settings are received when Group Policy is refreshed, the settings are evaluated, but they are not applied until the next time the user logs on.
If the computer is running Windows XP and these settings first reach the computer during logon, they might not be applied until the next time the user logs on. For some extensions, it might take two or three logons for the settings to be applied. For more information see “Asynchronous Processing and Logon Optimization in Windows XP” .
A simple way to troubleshoot a suspected a Group Policy refresh issue is to force the refresh by running gpupdate or secedit /refreshpolicy and either restarting the computer, or by logging off and logging on again. If Folder Redirection, roaming profiles, or Software Installation is involved and the computer is running Windows XP, run gpupdate and then log off and log back on. You might need to log off and log back on more than once. For more information, see “Asynchronous Processing and Logon Optimization in Windows XP”.

Trust Relationships
You can link GPOs across domains, provided there is a trust relationship between them. If the trust relationship is broken, clients will be unable to access the GPO and related files. You might also encounter performance issues with links across domains.
GPMC supports management of other forests from within the console when there is a trust relationship between those forests and the forest in which your user account resides. However, you cannot link a GPO in one forest to a site, domain, or OU in a different forest.
Troubleshooting
If the GPO cannot be applied due to lack of trust, it will appear in the list of Denied GPOs and the reason given will be Inaccessible.
Use Active Directory Domains and Trusts or nltest.exe to verify the trust relationship, and to if repair it if necessary.
If you are not concerned about the identical GPO being applied in both domains, copy the GPO to the domain with the Active Directory containers you want to link to it.
For more information see “Forests in Group Policy Management Console” in GPMC Help and “Forest trusts” in Help and Support Center for Windows Server 2003.

OU Memberships and GPO Linking
GPOs are applied to a client only if they are linked to a site, domain, or OU to which the computer or the user at that computer belongs.
For troubleshooting purposes, you need a solid understanding of your organization’s Active Directory structure and the Group Policy inheritance and filtering rules. With this information and the Resultant Set of Policy (RSoP) functionality in Windows Server 2003 and Windows XP, you can manipulate your Active Directory structure and your Group Policy links and filters to deliver targeted settings to the users and computers in your organization. The same information is needed to troubleshoot situations where these manipulations produce an unexpected result.
Troubleshooting
Check Active Directory Users and Computers to see what site, domain, and OU the user and the computer are in.
In GPMC, expand the Active Directory containers that contain the affected client. In the navigation pane, scan the list of GPOs for each container for disabled links.
GPOs are filtered according to the Active Directory groups that the users and computers belong to. The Active Directory objects in which you place your Active Directory groups and the ways you group users or computers affect how GPOs can be distributed and applied.
Active Directory and FRS replication lag can affect either part of the GPO.
If you have an OU that contains other OUs and you remove Read permissions to the parent OU, then no policy will be processed by computers or users in that OU hierarchy.
If there are conflicting settings in the GPOs that apply to the client, they are resolved according to the Group Policy inheritance rules, which are discussed in the "Resolving Group Policy Inheritance Conflicts" paragraph of the "Troubleshooting Common Scenarios" section of this document.

Adding a User or Computer to an OU
When a user or computer is added to an OU, two things need to happen before the GPOs that the new OU links to are applied to the client:
· The new OU assignment must be replicated to the client’s domain controller. For more information, see “Replication Convergence” earlier in this paper.
· After the replication is complete, you must either log off and log back on again if the user account moved to the new OU, or restart the computer if the computer moved to the new OU.
Some settings can only be applied at system startup or logon. For more information see “Asynchronous Processing and Logon Optimization in Windows XP” later in this paper.

User Settings vs. Computer Settings
In most cases, the computer settings are taken from GPOs that are linked to nodes in the hierarchy that the computer belongs to, and user settings are taken from GPOs that are linked to nodes in the hierarchy that the user belongs to. The exceptions are loopback processing, which is discussed in General Issues for CSE Processing, and explicit denials, which are discussed in the white paper, Windows Server 2003 Group Policy Infrastructure (http://go.microsoft.com/fwlink/?LinkId=14950).
There are two main issues involving user settings and computer settings. The first is when settings are applied – at system startup, at logon, or through background refresh while the computer is in use. The second is how conflicts are resolved after inheritance rules have been applied to determine the GPOs that apply to the client.
Troubleshooting
· Loopback processing can determine which GPOs provide user settings. For more information, see Loopback Processing.
· If a setting is not supported by the operating system running on the computer where the user logs on, the setting is ignored. For more information, see Operating System.
· Computer settings are not applied until Group Policy is refreshed on that computer, or the computer is restarted.
· User settings are not applied until Group Policy is refreshed on that computer, or the user logs on.
Some user settings, notably those involving Software Installation or Folder Redirection, cannot be applied until the user logs on. If the computer is running Windows XP and logon optimization is in effect, the user might need to log on more than once. For more information see “Asynchronous Processing and Logon Optimization in Windows XP” later in this paper.
The computer configuration settings and user configuration settings for a client are listed in the Group Policy Results or Group Policy Modeling report for that client, on the Settings tab.
The computer configuration settings and user configuration settings for a GPO are listed in the GPO, on the Settings tab.

Security Filtering
Group policy can be used to provide or deny access to programs and data in your network, and to enforce policies regarding computer configuration based on assigned privileges and security group memberships. This is accomplished by using the access control functionality built in to Windows 2000 Server and Windows Server 2003 domains and is known as security filtering.
You can restrict application of all the settings in a GPO on the basis of security group memberships by setting a security filter on that GPO. If the computer account or user account does not meet the security filtering criteria, the entire GPO will be denied at that client. For example, you can assign special settings to all the administrators in a portion of the hierarchy by setting the security filter to apply the GPO to all administrators, and then linking the GPO to the highest node in the portion of the hierarchy where you want the settings to apply. All users in that portion of the hierarchy will receive the GPO, but only members of the administrators group will be affected by it.
Troubleshooting
· To see the security groups that were in effect when Group Policy was applied to a specific computer, look in the Group Policy Results report for that computer. Under both Computer Configuration Summary and User Configuration Summary, expand Security Group Membership when Group Policy was applied.
· To see the access control lists that affect where a GPO can be applied, open the GPO in GPMC and look at Security Filtering on the Scope tab. This is also where you would change those settings.
· If a GPO is incorrectly denied or applied due to security filtering because the user or computer had different security group memberships than expected, use Active Directory Users and Computers to check and if necessary change the security group memberships.
· When restricting the application of a GPO, be sure to remove Authenticated Users. Otherwise all users will always be affected by the GPO.
· Computers are members of the Authenticated Users group. If you remove Authenticated Users from the list on the Scope tab and you want the GPO to apply to a computer, you must specifically ensure that the computer belongs to a group that is included in the Security Filtering section on the Scope tab.

Cached Credentials
When a user successfully logs on to the network, the credentials for that user can be cached on the local computer. If network connectivity problems prevent the user from being authenticated the next time the user logs on to the same computer, these cached credentials can be used to give the user access to resources on that computer. If the computer successfully connects to the network later, the cached credentials can be used to provide access to network resources, including GPOs that are received at the next Group Policy refresh.
Troubleshooting
· If a domain controller is not available when the user logs on Group Policy cannot be refreshed at logon. In this case, new Group Policy settings will not be applied until a Group Policy refresh occurs while a domain controller is available.
· Some user settings can only be applied during logon. These include roaming user profile path, Folder Redirection path, and Software Installation settings. If the user is already logged on when these settings are detected, they will not be applied until the next time the user is logged on. For more information, see “Asynchronous Processing and Logon Optimization in Windows XP” in this paper.
· When a user logs on to a computer locally and then accesses the network by using a dialup or VPN connection, cached credentials are always used.

WMI Filtering
If the GPO is linked to a WMI filter, the queries in the WMI filter are evaluated against the data provided by WMI on the client. Such data can include hardware and software inventory, settings, and configuration information.
If all of the criteria are true, the GPO is applied.
If any of the criteria is false, the GPO is denied.
If a WMI filter is deleted, the links to the WMI filter are not automatically deleted. If there is a link to a non-existent WMI filter the GPO with that link will not be processed until the link is removed or the filter is restored.
Note
Only Windows XP, Windows Server 2003, and later operating systems support WMI filtering. If the computer is running an earlier operating system (such as Windows 2000), the WMI filter is ignored and the GPO is applied. Troubleshooting:
If the filter is not producing the expected results, troubleshoot and edit the filter. WMI filters are stored on a per-domain basis separately from the GPOs that link to them. They can be accessed in GPMC on the WMI Filters node under the domain. For more information see GPMC online Help.
You can also use the WBEMtest and WMIC utilities to troubleshoot WMI issues. For more information, see “Windows Management Instrumentation Command-line” and “Windows Management Instrumentation Tester” in Help and Support Center for Windows Server 2003.

Group Policy Inheritance Rules
Before you apply or troubleshoot Group Policy, you should be familiar with Group Policy inheritance rules. These are described in GPMC Help and in “Designing a Group Policy Infrastructure” (http://go.microsoft.com/fwlink/?LinkId=4757) in the Windows Server 2003 Deployment Guide. GPOs can be linked to sites, domains, and OUs.
The following inheritance rules apply to GPOs:
· Certain settings can only be set at the domain level. One example is domain password policies. If an OU lower in the hierarchy links to a GPO with password policy settings, those settings only apply to the local accounts.
· OUs inherit the GPOs linked to their parents. Exceptions are due to the use of Block Inheritance and Enforce settings. (Enforce was previously called No Override.) In contrast to OUs, domains do not inherit Group Policy from parent domains.
· The order in which GPOs are applied is critical because where there are conflicts in settings between these GPOs, the last GPO applied wins. Exceptions are due to Enforce and Loopback Processing settings.
· GPOs from the most distant container are applied first, and GPOs from the nearest container are applied last.
· GPOs from any one Active Directory container are applied according to their precedence, as defined by the link order.
When you view a site, domain, or OU in GPMC, you can view the GPOs linked directly to that container and its parents, including the link order. You can also see where inherited GPOs are linked and whether they are enforced.
Troubleshooting
Conflict resolution applies to individual settings, not to entire GPOs. It could easily happen that one setting in a GPO encounters a conflict but all other settings in that GPO are applied.
The GPO with the lowest link number prevails over other GPOs that the same site, domain or OU is linked to. You can use GPMC to change the order of links for a specific site, domain, or OU. (The links are a property of the site, domain, or OU; they are not a property of the GPO.)
Enforce and Block Inheritance settings can complicate troubleshooting because they counteract the usual inheritance rules.
The Enforce setting is a property of the link between an Active Directory container and a GPO. It is used to force that GPO to all Active Directory objects within a container, no matter how deeply they are nested. The settings within a GPO that is enforced override other settings that would prevail because they are applied later. If there are conflicting settings in GPOs that are enforced at two levels of the hierarchy, the setting enforced furthest from the client prevails. This is a reversal of the usual rule, in which the setting from the nearest-linked GPO would prevail.

The actual effect of Enforce is to change the order of processing. The settings in an Enforced GPO are processed after all other GPOs settings are processed.
The Block Inheritance setting applies to an entire Active Directory container. It blocks the inheritance of all GPOs except for those for which the link from the parent Active Directory object to the GPO has the Enforce setting enabled.
Administrators who have set Block Inheritance on their domain or OU can still make explicit links to GPOs elsewhere in the domain, including GPOs that might otherwise be inherited. (Domains do not inherit GPOs from parent domains.) Note that when Block Inheritance is applied at a domain level it blocks GPO’s linked to sites.

Migrating GPOs Between Forests
Migration in this context refers to transferring a GPO from one forest to another — from a test environment to a production environment, for example. Migrating from a Windows NT 4.0 domain to a Windows 2000 or Windows Server 2003 domain is a different issue and is covered in Migrating from Windows NT 4.0.
Simply backing up and importing the GPO often does not produce the results you want because GPOs include domain-specific information such as security principals and UNC paths. GPMC includes migration support, including a migration table editor, to address these issues. If a GPO that worked in one forest is not working as expected in the new forest, you might need a migration table. You also might need to back up and import the GPO instead of copying it.
Troubleshooting
· Check for a trust relationship between the source domain and the target domain. If there is trust, copy the GPO; if not, import it.
· If the GPO has references to security principles or UNC paths, use a migration table.
· The migration table editor that is included with GPMC provides error checking. However there is still a possibility of mistyped UNC paths.
For more information see Migrating GPOs Across Domains with GPMC (http://go.microsoft.com/fwlink/?LinkId=14321).

Loopback Processing
Some GPOs are delivered to the client through the Active Directory hierarchy the computers belong to, and other GPOs are delivered through the user’s Active Directory hierarchy. GPOs from either source can have both computer settings and user settings.
Typically, the user settings in GPOs linked to a site, domain, or OU in the user’s hierarchy prevail over user settings in GPOs directed to the computer. User settings in GPOs applied to the computer are ignored. If the computer is configured for loopback processing, the user settings from GPOs directed to the computer will affect the processing of the user’s Group Policy settings. The exact effect depends on which mode of loopback processing is configured.
Note
The user’s account is used to check against security filtering for user settings, even if loopback processing is implemented.
There are two modes for loopback processing. In Loopback with Replace, the GPO list for the user is replaced in its entirety by the GPO list assigned based on the computer’s inheritance hierarchy. This is evaluated each time Group Policy is applied. In Loopback with Merge, the user-assigned settings are applied after the computer-assigned user settings – in effect the two sets of user policy settings are merged.
Loopback processing can only be applied to computers in Windows 2000 or Windows Server 2003 domains.
To find out whether loopback processing was applied when Group Policy was evaluated on the client, look in the Group Policy Results report on the Settings tab in the following location: Computer Configuration Administrative templates System/Group Policy
Troubleshooting
· If the loopback processing is appropriate for this client you might need to educate the users so they know what to expect.
· If loopback is desired and it appears that it is not being applied, first verify the loopback policy setting (which is a computer configuration policy) has been applied to the computer through an appropriate GPO.

Details for Troubleshooting Client-Side Extensions
After the core Group Policy processing is completed at the client, the GPOs are handed to the appropriate CSEs. The CSEs are DLLs that process the GPOs. A CSE might process only certain types of settings. For example, the Scripts CSE deals only with settings involving startup, shutdown, logon, and logoff scripts, while the Folder Redirection CSE deals only with settings involving Folder Redirection.

The Core Group Policy Engine is launched by UserEnv.DLL, and runs as part of the Winlogon process. It functions as “master of ceremonies” for Group Policy processing…it sets the stage and coordinates the activity of the various Client Side Extensions, which do most of the actual “work” associated with Group Policy.

Several CSEs ship with Windows 2000, Windows XP Professional, and Windows Server 2003. Other software manufacturers might create additional CSEs to leverage Group Policy functionality and make their products more manageable.
Because CSEs cannot begin to work until core Group Policy processing is completed, the issues described in the previous sections apply regardless of which CSE processes the setting. For example, they can all be affected by network connectivity problems that prevent the GPO from reaching the client, or by inheritance rules.

216357 Identifying Group Policy Client-Side Extensions
http://support.microsoft.com/?id=216357

216358 Troubleshooting Group Policy Client-Side Extension Behavior
http://support.microsoft.com/?id=216358

Folder Redirection CSE
Folder Redirection is used to maintain user data in a centralized location. This permits regular backups of the information, and also provides the user with access to the data from any computer in the network.

The following folders can be redirected:
· My Documents
· Application Data
· Desktop
· Start Menu
The Folder Redirection CSE manages folder Redirection. When events from this CSE are listed on the Policy Events tab in Group Policy Results reports, the source is listed as Folder Redirection.

242557 Registry Settings for Folder Redirection in Windows
http://support.microsoft.com/?id=242557

232692 Folder Redirection Feature in Windows
http://support.microsoft.com/?id=232692

Troubleshooting:
Folder redirection processing contains five steps:
Determine which folders to redirect based on changes to policy at logon time.
Determine desired redirected location and verify access.
If folder does not exist: create folders, set access control lists (ACLs).
If folder exists, check ACLs and ownership.
If desired, move contents.

In order to use the folder, the file system and share permissions must be set such that the user can navigate the path to the folder, and if the folder exists the user must have ownership privileges on it. (The user is given ownership of the folder by default if you allow the folder to be created automatically.) This is a common cause of confusion with folder redirection. When using Folder Redirection Policies, it is best to allow the system to create and set permissions on the folder. This reduces the likelihood of error due to incorrect security settings. For more information, see User Data and Settings Management (http://go.microsoft.com/fwlink/?LinkId=15288).
If you need to set permissions manually, ensure that the user has the appropriate minimum file system and share permissions. The permissions needed are shown in the tables below:
NTFS Permissions for Folder Redirection Root Folder
User Account
Minimum permissions required
Creator/Owner
Full Control, Subfolders And Files Only
Administrator
None
Security group of users needing to put data on share.
List Folder/Read Data, Create Folders/Append Data - This Folder Only
Everyone
No Permissions
Local System
Full Control, This Folder, Subfolders And Files
Share-Level (SMB) Permissions for Folder Redirection Share
User Account
Default Permissions
Minimum permissions required
Everyone
Full Control
No Permissions
Security group of users needing to put data on share.
N/A
Full Control,
NTFS Permissions for Each User’s Redirected Folder
User Account
Default Permissions
Minimum permissions required
%Username%
Full Control, Owner Of Folder
Full Control, Owner Of Folder
Local System
Full Control
Full Control
Administrators
No Permissions
No Permissions
Everyone
No Permissions
No Permissions

Folder Redirection, like Software Installation settings, can only be applied during computer startup or user logon. On computers running Windows XP with logon optimization enabled, this can mean that the user needs to log on more than once before the setting takes effect. For more information see “Asynchronous Processing and Logon Optimization in Windows XP” in this paper.

If the path to the folder does not exist (for example if the path specification is mistyped in the policy setting, if folders in the path have been renamed or removed, or if the server is unavailable), Folder Redirection will fail.

Ensure that the correct Fdeploy.ini file is available on the domain controller that the client is accessing.
To investigate
Turn on fdeploy logging to verify policy was processed.
Error info can also be found in the Event Log. See entries with the source name folder redirection.
To create a detailed log file for folder redirection use the following registry key:
· HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
· Set: FdeployDebugLevel = Reg_DWORD 0x0f
Note: The log file can be found at: %windir%\debug\usermode\fdeploy.log

Best Practices
Let system create folders and set ACLs for you. Folder redirection failures only affect the folder redirection extension on a per-folder basis.

If you’re not following the best practice as noted above, typical errors include:
Redirecting to a folder that is incorrectly ACL’d.
User is not the owner of the folder.
Destination does not exist.

Registry CSE (Administrative Templates)
Administrative Template settings take the form of true policies or preferences. Preferences can be deployed using Group Policy, but they cannot be enforced to the same degree as true policies. For this reason they are hidden by default in the Group Policy Object Editor.
· Users can change preferences, but they cannot change true policies.
· True policies are more secure because they are stored in secured registry hives.
· Changes to true policies override but do not overwrite user preferences. If the policy is later removed, the user setting will again prevail.
· If the GPO ceases to apply to the user or computer, policies no longer apply but preferences remain. This occurs if the user or computer moves out of the site, domain, or OU that the GPO is linked to, or if the GPO is deleted.
If the setting you are using is a preference rather than a true policy, be aware that because preferences can be overwritten but are not removed, the end user might see their behavior as unpredictable. As a result, there might be perceived problems even when preferences are behaving as intended. Troubleshooting preferences requires knowledge about changes to both the GPO and the preferences set by the user.

The registry CSE writes the value for the setting to the registry. Some settings take effect as soon as they are written to the registry, but others take effect only at startup or logon. If you are not seeing the expected results and the Group Policy Results report shows that the policy has been applied, restart the computer or log off and log back on.

The Registry Client-side Extension is invoked when the Administrative Templates nodes are modified. The Registry CSE processes GPOs which contain settings specified via the Administrative Templates. Windows 2003, Windows XP and Windows 2000 provide an improved mechanism for applying such registry-based policy settings, which makes it easier to determine what registry keys have been affected by Policy, and if necessary, undo or adjust the settings.

This improved mechanism relies on the use of the REGISTRY.POL and NTUSER.POL files. A REGISTRY.POL file exists as part of each GPO for which registry-based settings have been specified, i.e. via the Administrative Templates. When Policy is applied, changes are applied from the REGISTRY.POL files to the registry of the target computer, per the GPO order of precedence. As the REGISTRY.POL files are processed, the NTUSER.POL files are created, which reflect all of the changes that have been written to the registry as a result of the applied GPOs.

There are two NTUSER.POL files on each system – one containing User settings, and one containing Computer settings. The user copy is stored in the root of the User Profile. The computer copy is stored in the root of the All Users profile. The core Group Policy engine invokes the Registry CSE at startup, logon, or the Policy Refresh Interval, and passes the extension the list of Group Policy Objects to be applied.

As the GPOs are processed, settings are applied from the REGISTRY.POL files to the appropriate registry keys on the target machine, and the NTUSER.POL files are created. The NTUSER.POL files record all of the registry-based settings applied. At Policy refresh, the Registry CSE parses the existing NTUSER.POL files on the target computer to clear any previously-specified registry settings. The Registry CSE then retrieves the REGISTRY.POL files from each GPO in the list and applies the REGISTRY.POL changes to the local registry in order of precedence for the GPO’s.

Note that any registry modifications specified to keys other than the designated policy registry keys are noted in the NTUSER.POL, but are not cleared at Policy refresh time. Typically, these would be settings specified by an administrator via custom, NT 4.0-style ADM files.

Data is also written to WMI by the Registry CSE, which can be viewed by the RSoP tool at a later time. Events are written to the event log during this process. If debugging is enabled, data is written to the Userenv.log as well.

Troubleshooting
Typical errors include:
Missing or corrupted ntuser.pol file.
Missing or corrupted registry.pol file.
Unable to read policy information from the SYSVOL.
Failure in individual registry policies will cause all registry processing to fail.

To investigate:
Enable verbose Userenv logging.
Check Event logs for UserEnv Warnings and Errors.
Use Regview.exe to view the settings in the NTUSER.POL and Registry.POL

221833 How to enable user environment debug logging in retail builds of Windows
http://support.microsoft.com/?id=221833

REGVIEW.EXE
The creation of the REGISTRY.POL and NTUSER.POL files makes it possible to track what registry-based Policy settings have been applied to a given system.

This tool may be of benefit when troubleshooting issues where unexpected or unwanted settings result from application of registry-based policy, and it is necessary to determine what settings have been applied to a given system.

Regview can be downloaded from the Windows Server 2003 Resource Kit Tools
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

For More Information see the Implementing Registry-Based Group Policy Whitepaper:
http://www.microsoft.com/Windows2000/techinfo/howitworks/management/rbppaper.asp

Scripts CSE
Startup, logon, logoff, and shutdown scripts can be applied using Group Policy settings. The Scripts CSE processes these script settings.

The Scripts CSE updates the registry with the location of one or more script files so that the UserInit process can find those values in the course of its normal processing. When a CSE reports success, it might only mean that the value has been placed in the registry. Even though the setting is in the registry, there could be problems preventing the setting from being applied to the client. For example, if a script specified in a Script setting has an error that prevents it from completing, that Script CSE does not detect error.
Scripts processing contains two steps:
Group Policy processes a GPO and stores the script information in the registry:
· HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\Scripts (User Scripts)
· HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\Scripts (Machine Scripts)
Note
Script is run by means of a UserInit process. (By default, scripts that cannot be completed time out after 10 minutes.)
Only Windows XP, Windows Server 2003, and later operating systems support WMI filtering. If the computer is running an earlier operating system, the WMI filter is ignored and the GPO is applied.

Note
The time-out is the time allotment for all scripts to run. This can be modified using the Computer policy setting: “Maximum wait time for Group Policy Scripts.”

Troubleshooting
Common script errors include:
· Bad script path.
· Script time-out.
· Access to script is restricted by means of ACLs (typically for startup/shutdown scripts that run as computer, not user).
If a logon script fails, it typically does not affect the other scripts. However, startup scripts are often run synchronously, and a failure of one of these scripts can affect scripts intended to run later.

To investigate:
Check the Application Event Log for entries with UserInit as the source.
See Scripts Do Not Run

Security CSE
The binary file that contains the Security CSE is SCECLI.DLL. This name will usually appear in Events, error messages, and log entries generated and logged during processing of Security GPOs.

SCECLI manages application of the Security policy settings that appear under the Security Settings node in GPEdit. SCECLI is responsible for the following areas:
Account Policies
Local Policies
Event Log
Restricted Groups
System Services
Registry
File System

When the Security CSE is notified by the Core GP engine it is provided a list of GPOs to apply. The Security CSE then copies the gpttmpl.inf file from the folder structure of each policy in the Sysvol. It copies that file locally to the hidden folder %SYSTEMROOT%\Security\Templates\Policies. The settings are read from the gpttmpl.inf in the Sysvol and written to an intermediary file named tmpgptfl.inf. Once the copy has completed successfully the file is copied off and is named incrementally starting from gpt00000.inf. If the GPO is linked to the domain then the cached template will be named with the .dom extension otherwise it will be named with the .inf extension.

This is done because some settings are only applied if they are linked to the domain; see 259576 Group Policy Application Rules for Domain Controllers for more information. The templates are then applied from the cached location in order from least to greatest. This means that the gpt00000.inf will be applied before gpt00001.inf and that gpt00001.inf will have a higher precedence in the case of a conflict.

Troubleshooting
SCECLI provides debug logging when enabled, and the log is written to the file WINLOGON.LOG.

245422 How to Enable Logging for Security Configuration Client Processing in
http://support.microsoft.com/?id=245422

Common Security CSE Event ID’s

259398 SceCli Event ID 1001 and UserEnv Event ID 1000 When Dfs Client Is
http://support.microsoft.com/?id=259398

279432 Event ID 1000 and 1202 Messages May Occur Every Five Minutes on the
http://support.microsoft.com/?id=279432

324383 Troubleshooting SCECLI 1202 Events
http://support.microsoft.com/?id=324383

258296 Cannot Access Group Policy Objects--Event ID 1000 and Event ID 1001
http://support.microsoft.com/?id=258296

271213 Event ID 1000 and 1001 Repeat Every 5 Minutes in the Event Log
http://support.microsoft.com/?id=271213

285923 Error Messages Every 5 Minutes Report Events 1000, 1001, and 13508,
http://support.microsoft.com/?id=285923

Software Installation / Application Management CSE
A number of special issues affect Group Policy software installation. For example, network connectivity issues can disrupt access to the software installation packages. Software installation processing is never performed while the user is logged on because doing so could disrupt work and result in data loss. This has implications when Group Policy is configured to run asynchronously. These and other issues are addressed in the troubleshooting issues list in this section.
Software Installation is managed by the Software Installation CSE, which appears as the source Application Manager on the Policy Events tab in Group Policy Results reports. If you need additional logging information, enable verbose logging for the Software Installation CSE and Microsoft® Windows® Installer, as described under Appendix: Group Policy Log Files.

The Software Installation Diagnostics tool (addiag.exe) provides detailed information about the applications visible in Active Directory and installed for the current user, as well as general diagnostic information and related Event Log entries. It is available in the Windows 2000 Server Resource Kit and the Windows 2003 Support Tools.
Troubleshooting
Startup and logon requirements
· Software Installation processing occurs only during computer startup or when the user logs on. This is because processing periodically could cause undesirable results. For example, if an application is no longer assigned, it is removed. If a user were using the application while Group Policy tries to uninstall it or if an assigned application upgrade takes place while someone is using the application, errors would occur.
· If the software installation settings are applied through computer configuration, they are applied at startup. If software installation settings are applied through user configuration, they are applied at logon.
· If the computer is running Windows XP with logon optimization enabled, the user will need to log on after Group Policy refresh. This can entail logging on two or three times. For more information see “Asynchronous Processing and Logon Optimization in Windows XP” earlier in this paper.
Access to share points
· Test for mistyped elements in the path specification by manually following the path.
· Verify that the user account or system account has the necessary privileges to traverse the path and access those resources. The account whose OU supplied the GPO is the one that needs to traverse the path.
Computer versus User settings, and OU memberships
· If the user has a roaming user profile and the user uninstalled the application on another computer using Add or Remove Programs, the application will be unavailable to that user on every computer (with the possible exception of computers where loopback processing rules apply). For more information about roaming user profiles, see “Using roaming user profiles” in Help and Support Center for Windows Server 2003.
· If the application was deployed with the Uninstall this application when it falls out of the scope of management option, verify that the computer and user are still in the necessary security groups and that the GPO is still linked to a site, domain, or OU that the user or computer is in.
Installation package
· Windows Installer packages are the preferred packaging for software installation using Group Policy. ZAP files can be used but they do not support elevated installation privileges (the user must be an administrator or power user in order to install the software). Software installed with ZAP files cannot be repaired or removed by Group Policy after they are installed.
· If problems occur when a Windows Installer package is used, the problem could be with the package itself. For example, the package might be corrupted. For more information, see “Windows Installer” in Help and Support Center for Windows Server 2003. See also the Windows Installer topic “Managing options for computers through Group Policy” in Help and Support Center for Windows Server 2003.
Add or Remove Programs
· For the software to appear in the Add New Programs section of Add or Remove Programs, it must be Published (not Assigned) in Group Policy.
· The Windows Installer package must be written such that the software can appear in Add or Remove Programs.
Install on demand
· Check the order of file name extensions specified for the GPO and ensure that the file name extension is associated with the application, as follows:Edit the GPO. Find the Software Settings node; there is one under Computer Configuration and another under User Configuration. Right-click Software Settings and select Properties. Then click the File Extensions tab.
· Check the client computer for applications that have been installed locally. If there is a conflict, the locally installed application is used instead of the deployed application.
Terminal Services
· User configuration settings for Software Installation cannot be applied to a terminal server. Use Terminal Services Manager to determine whether the computer is a terminal server.
· If the application should be available on the terminal server, you must install it as an administrator at that computer. The administrator can install the application from Add or Remove Programs if has been Published using a Computer Configuration setting.

246509 Troubleshooting Program Deployment By Using Verbose Logging
http://support.microsoft.com/?id=246509

249621 Enabling Windows 2000 Application Deployment Debug Logging
http://support.microsoft.com/?id=249621

As an administrator, you may see several common scenarios when troubleshooting Group Policy. For example, you may see that policy settings aren’t being applied, that policy settings are applied inconsistently, or that you are simply unable to manage Group Policy due to delegation or permission issues. This section shows how to check for these types of problems.
If Group Policy Settings Aren’t Applied
If settings are not applied check the following issue explanations:
· Resolving Group Policy inheritance conflicts.
· Resolving Group Policy security/permission issues.
· Disabled GPOs.
· Resolving replication problems.
· Inter-domain GPO link problems.
· Did you move the user or computer object?
· Are you migrating from Windows NT 4.0?
Resolving Group Policy Inheritance Conflicts
To resolve inheritance conflicts, start the search at the top of the Active Directory tree and check:
1. The order of precedence for each site, domain, or organizational unit (SDOU).
2. Any user or computer conflicts.
3. Settings for No Override or Block Policy Inheritance.
Note: No Override wins over Block Policy Inheritance. You can use the GPResult tool to help determine order of precedence.
Resolving Group Policy Security/Permissions Issues
To resolve permissions issues, check the following:
· Group Policy filtering.
· Read and apply Group Policy access control entries (ACEs).
· Deny ACEs.
· Security group membership.
Disabled GPOs
Check the properties of the GPO and confirm that the user and/or computer portion have not been disabled.
Check the Group Policy links and make sure they are not disabled.
Resolving Replication Problems
To check the status of each GPO on each domain controller, use the Group Policy Verification Tool as explained earlier in this paper.
If the Group Policy container is not synchronized, use Active Directory Replication Monitor to force synchronization.
If the Group Policy template is not synchronized, troubleshoot file replication by placing a file in SYSVOL.
Inter-Domain GPO Link Problems
If an SDOU is linked to a GPO in another domain, access to the GPO is via a trust.
If the trust fails, access to the GPO fails, and so does Group Policy processing in its entirety. Prevent this scenario by having multiple domain controllers per domain, or by creating explicit trusts.
Did You Move the User or Computer Object?
Client computers cache the directory service location for 30 minutes. When user or computer objects are moved from one organizational unit to another, the client may not “know” right away.
If policy refreshes before the client’s cached directory service location is refreshed, the new policies will not be applied.
Note: If you move a computer to a new container or put it in a new group, you should reboot the computer to make sure the change takes effect immediately.
If you move a user to a new container or put it in a new group, you should logoff and back on to ensure the change takes effect immediately.
Are You Migrating from Windows NT 4.0?
If the client computer is running Windows 2003, Windows XP or Windows 2000 and if the computer and user accounts both belong to Windows NT 4.0-based domains you should continue to receive system policy. If the domain is Active Directory based, the computer/user will only receive Group Policy.
If the user account is in Active Directory and the computer account is in Windows NT 4.0, then the computer gets system policy and the user gets Group Policy—and vice-versa.
In addition, if you are planning on using sites, a site which is determined by which IP subnet a machine is in, Group Policy will only get defined if the machine is running Windows 2000 in a Windows 2000 domain with Active Directory.
Note: The local GPO processes regardless of the configuration. For details about how Group Policy is applied with various configurations, see Table 2 below. If your computer/user account is in a Windows 2000 domain that cannot be reached (for example, you are logging on with cached credentials), then all Group Policy processing, including the local GPO, will not be processed.
How Policy is Applied on the Client Computer
Backend
Account Object Location
What Affects the Client
Windows NT 4.0
Computer: Windows NT 4.0
At computer startup: Computer local Group Policy (only if changed).Every time the user logs on: Computer System Policy.
“
Computer refresh
Before Control-Alt-Delete: Computer local Group Policy only.After the user logs on: Computer local Group Policy and computer System Policy.
“
User: Windows NT 4.0
When the user logs on: User System Policy.If local Group Policy changes: User local Group Policy and user System Policy.
“
User refresh
User local Group Policy and user System Policy.
Mixed (migration)
Computer: Windows NT 4.0
At computer startup: Computer local Group Policy (only if changed).Every time the user logs on: Computer System Policy.

Computer refresh
Before Control-Alt-Delete: Computer local Group Policy only.After the user logs on: Computer local Group Policy and computer System Policy.

User: Windows 2000 later.
When the user logs on: Group Policy is processed after computer System Policy.

User refresh
User Group Policy.
Mixed (migration)
Computer: Windows 2000 or later
During system startup: Group Policy.

Computer refresh
Computer Group Policy

User: Windows NT 4.0
When the user logs on: User System Policy.If local Group Policy changes: User local Group Policy and user System Policy.

User refresh
User local Group Policy and user System Policy.
Windows 2000 or later
Computer: Windows 2000 or later
During computer startup and when the user logs on: Group Policy.

User: Windows 2000 or later

Windows 2000 or later in a workgroup (without Active Directory)
Local
Local Group Policy only.

If Group Policy Settings Apply Inconsistently
Check for:
· Preferences versus policies.
· Asynchronous processing.
Are you using IPSec or User Rights policies?
Preferences Versus Policies
Registry policy or Administrative Templates take the form of policies (registry entries under the special keys) or preferences (registry keys anywhere else). Administrative Templates files are used to apply policies or preferences.
It is recommended to use policies rather than preferences:
· Policies don’t “tattoo.” Using a GPO to deploy policies and preferences, when the GPO is removed, the policies will be removed, but the preferences will remain. This process is known as “tattooing.”
· Preferences do not get refreshed unless the GPO changes. Users can change their preferences, and they will not be restored until Group Policy changes and the GPOs are reapplied. Policies on the other hand are ACL’d in the registry, so that users cannot change them.
If you must use preferences, preferences must be added via the .adm file. By default, if nothing changes at the GPO, nothing gets applied to the client computer (assuming the client has received policy in the past).
Note: Policies are stored under HKLM (for computer policy) or HKCU (for user policy).
\Software\Policies (preferred location)
\Software\Microsoft\Windows\CurrentVersion\Policies
Synchronous Versus Asynchronous Processing
In Windows 2000, Group Policy application is synchronous by default. There is no logon screen until computer policy is applied and no desktop until user policy is applied.
You can change to asynchronous (via policy), but this can cause unpredictable side effects.
If You Can’t Manage Group Policy
There are several issues to check if you cannot manage Group Policy including:
· Required permissions for Group Policy Snap-in.
· Delegating control of Group Policy.
· Consistency/Performance problems: Where are GPOs managed?
Required Permissions for Group Policy Snap-in
To have policy applied, you must have Read and Apply Group Policy permissions. To use the Group Policy Editor snap-in, you must have Read and Write permissions.
Note: Domain administrators are covered for all Active Directory-based GPOs and local administrators are covered for local GPOs.
Manage Group Policy Links
This permission is required for an organizational unit administrator to link a GPO created by another administrator. It is assigned using the “Manage Group Policy Links” in the delegation wizard. This permission:
· Allows a user to add, remove, and reprioritize linked GPOs.
· Does not allow user to create or edit GPOs.
· Actually grants read/write access to GPLink and GPOptions properties of SDOU.
To verify existing permissions, from the Active Directory Users and Computers snap-in:
· From the menu bar, click View, then click Advanced Features.
· Right click on the desired container and select Properties.
· Select the Security tab. You can now view and edit the ACEs on that container.
Create GPO
This permission is required for an organizational unit administrator to create a GPO and is delegated by adding a user to the Group Policy Creator Owners security group. This permission:
Allows the organizational unit administrator to create GPOs and edit only GPOs created by that user.
Does not allow the organizational unit administrator to link GPOs to an SDOU.
Edit GPO
This allows a user to edit a GPO but does not allow the user to link the GPO to SDOUs. It is assigned by granting a user read and write permissions on the GPO. Note that to avoid having the GPO apply to the administrator (if it is a lockdown GPO), do NOT set Apply Group Policy.
Consistency/Performance Problems: Where are GPOs Managed?
By default, GPOs are managed on the PDC Operations Manager. Although you can select an alternate domain controller, first consider the following issues:
If multiple administrators edit the same GPO on different domain controllers, the last writer “wins.”
Ensure that no one else is editing the GPO—data is written to the GPO with each change.
Ensure that the GPO has fully replicated before changing it.

Group Policy Engine/Core Processing Failures
Catastrophic failures can occur causing all of policy processing to fail including client side extensions (CSEs).
These kinds of failures generally occur during the information gathering part of policy processing. Errors are logged under Userenv source in the Event Log.
The types of errors causing Group Policy core failures include:
DNS problems. For example no DNS is available or there are missing or stale entries in the DNS database. (To diagnose this issue, use the netdiag tool, as explained earlier.)
Network/Active Directory issues. For example, you cannot connect to the network, or you are unable to ping, find, or bind to a domain controller. To diagnose this issue, use NLTEST, as explained earlier.
Replication. Differences in replication time between directory service replication and SYSVOL replication. Version number is mismatched in the Group Policy container or Group Policy template between Active Directory and SYSVOL. (To diagnose this issue, use the GPOTool.)
Replication between domain controllers causing different versions of policy to be stored. (To diagnose this issue, use the GPOTool.)
Note: Event log errors use source Userenv. Not all failures are logged in the Event Log to avoid Event Log “flooding.”
Investigating Core Failures
To investigate these errors:
· Turn on Userenv logging or turn on verbose event logging, as explained in the previous section.
· View history of applied policies: HKLM or HKCU\Software\Microsoft\Windows\CurrentVersion\GroupPolicy\History\{extension GUID}.

Group Policy Troubleshooting Tools
Group Policy Results Tool GPResult.exe
There are two versions of GPresult.exe.
· The Windows 2000 version shipped in the Windows 2000 Resource Kit, and is also available as a free download on the Windows 2000 downloads site (http://go.microsoft.com/fwlink/?LinkId=12920). It estimates the Group Policy settings that would be applied at a specific computer. For more information, see the readme file included with the download.
· The Windows Server 2003 version is included with Windows Server 2003 operating systems. It gathers and reports the RSoP data available from computers running Windows XP or Windows Server 2003. The report is similar to what you would get by generated a Group Policy Results report in GPMC. For more information, see “Gpresult” in Help and Support Center for Windows Server 2003.

This is a command-line tool that you run on the computer on which you wish to test Group Policy. To run GPResult:
Click Start, Run, and enter cmd to open a command window.
Type gpresult and redirect the output to a text file as shown in Figure 1 below:

Figure 1. Directing GPResult data to a text file
Enter notepad gp.txt to open the file.

GPResult provides the following general information:
· Operating System
· Type (Professional, Server, Domain Controller).
· Build number and Service Pack details.
· Whether Terminal Services is installed and, if so, the mode it is using.
· User Information
· User name and location in the Active Directory® service (if applicable).
· Domain name and type (Windows 2000 or Windows NT®).
· Site name.
· Whether the user has a local or roaming profile and location of the profile.
· Security group membership.
· Security privileges.
· Computer Information
· Computer name and location in Active Directory (if applicable).
· Domain name and type (Windows 2000 or Windows NT).
· Site name.
Policy Application Information
GPResult also provides the following information about Group Policy:
· The last time policy was applied and the domain controller that applied policy, for the user and computer.
· The complete list of applied Group Policy objects and their details, including a summary of the extensions that each Group Policy object contains.
· Registry settings that were applied and their details.
· Folders that are re-directed and their details.
· Software management information detailing assigned and published applications.
· Disk quota information.
· IP Security settings.
· Scripts.
Using GPResult in Different Modes
GPResult can deliver varying levels of detail as shown in Table 1 below.
Table 1. GPResult Syntax
Mode
Description
Enter
Verbose mode
Adds:
List of user's security privileges.
Group Policy object details including globally unique identifier (GUID), friendly name, version, and source.
Details for the following Group Policy extensions:
Administrative Templates (Registry-Based Policies)
Application Management
Disk Quotas
Folder Re-direction
IP Security
Scripts

gpresult /v
Super verbose mode
Delivers all the above plus:
Binary values of binary registry settings when applicable.
A detailed list of which applications will be displayed in Add/Remove Programs.
Both version numbers of a Group Policy object —the version number of the Group Policy container and the version number of the Group Policy Template including binary registry values.

gpresult /s
Computer settings only
Restricts results to computer settings.

gpresult /c
User settings only
Restricts results to user settings.
gpresult /u

Interpreting GPResult Output
This example analyzes the output of Group Policy Results when run in verbose mode using the following command line:

gpresult /v Operating System Information

When GPResult is run with any mode, the following operating system information is always displayed at the top of the output:

Microsoft (R) Windows (R) 2000 Operating System Group Policy Result tool Copyright (C) Microsoft Corp. 1981-1999 Created on Wednesday, September 29, 1999 at 2:47:26 PM Operating System Information:
Operating System Type: Professional Operating System Version: 5.0.2128
Terminal Server Mode: Not supported

This output provides you with:
• Operating system type (Professional, Server, Domain Controller)
• Operating system version (build number and any installed Service Packs)
• Terminal Server mode, which indicates if Terminal Server is installed and if so, the mode in which it is installed

User Output
Following the operating system output comes general information for the current user.
The output begins by detailing the user's configuration. This includes domain membership, domain type, and the current site as indicated below:

User Group Policy results for:
CN=Alan Steiner,OU=Users,OU=Test,DC=ntdev,DC=microsoft,DC=com
Domain Name: NTDEV
Domain Type: Windows 2000
Site Name: Red-Bldg99

Following this the output details profile information about the user.

The output details the roaming profile (if applicable) and location of the current profile that is in use:

Roaming profile: \\ntprofiles\roamprof\AlanS
Local profile: C:\Documents and Settings\AlanS

Next the output details all of the security groups to which the user belongs:

The user is a member of the following security groups: GROUP1\Domain Users
\Everyone
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Power Users
GROUP1\RedirectedDesktop
GROUP1\Department 15333
GROUP1\mydocs1\LOCAL
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users

Following the details of security group membership, the output continues by detailing all of the user's security privilege information (For the complete list of security privileges that may be displayed by GPResult, please refer to Security Privileges section below.):

The user has the following security privileges:
Bypass traverse checking
Manage auditing and security log
Back up files and directories
Restore files and directories
Change the system time
Shut down the system
Force shutdown from a remote system
Take ownership of files or other objects

After detailing security privileges, a time stamp of when the last time Group Policy was applied to current user and the domain controller from which the policy was applied to the current user are listed.

Last time Group Policy was applied: Monday, September 06, 1999 at 9:25:40 AM
Group Policy was applied from: NTDS.ntdev.microsoft.com

Administrative Templates (Registry-Based Policy)
Next, if any registry-based policies have been applied to the user, the following is displayed:

The user received "Registry" settings from these Group Policy objects (GPOs):
Local Group Policy Revision Number: 40
Unique Name: Local Group Policy
Domain Name: EU-DesktopLockDown-Admin
Revision Number: 12 (Active Directory) 12 (Sysvol)
Unique Name: {EF06ECF2-A8C9-11D2-B575-0008C7457B4E}
Domain Name: group.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)EU-DesktopSetup-Admin
Revision Number: 7 (Active Directory) 7 (Sysvol)
Unique Name: {29021088-BF90-11D2-8614-00C04FF621C4}
Domain Name: group.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)
Output details:
• The output is a list of Group Policy objects that contain registry-based policy settings (including Local Group Policy)
• Each Group Policy object is displayed with the following details:
• Friendly Name
• Revision Number
• Unique Name (GUID or Local Group Policy)
• Domain Name
• Linking information

Next the details of the actual registry-based settings that were applied are displayed:

The following settings were applied from: Local Group Policy
KeyName: Software\Microsoft\Windows\CurrentVersion\Policies\System ValueName: VerboseStatus
ValueType: REG_DWORD
Value: 0x00000001 KeyName:Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
ValueName: NoSMHelp
ValueType: REG_DWORD
Value: 0x00000001

The following settings were applied from: Default Domain Policy KeyName: Software\Microsoft\Windows\CurrentVersion\Policies\Explorer ValueName: NoManageMyComputerVerb
ValueType: REG_DWORD
Value: 0x00000001
KeyName: Software\Microsoft\Windows\CurrentVersion\Policies\System ValueName: VerboseStatus
ValueType: REG_DWORD Value: 0x00000001

Output details:
• The output lists all registry settings that were applied to the user and the Group Policy object (by its friendly name) that supplied the registry settings.
• Each registry settings is displayed with the following details:
• Keyname (location in the registry)
• ValueName
• ValueType (for example, DWORD or STRING)
• Value (The value is displayed here only if it is non-binary. To see a binary value, run GPResult in super-verbose mode with the /s switch.

Note:
If any of the registry settings is written to a location outside the locations the Group Policy handles, this registry setting is not a true policy setting. Group Policy uses only the following locations:
• \Software\Policies
• \Software\Microsoft\Windows\CurrentVersion\Policies
If any registry settings outside of these locations are applied, the following warning is also displayed.

+++++++ Warning! The next registry setting is not a true policy setting and will be left in the registry when the GPO that created it is no longer applied.+++++++

Folder Redirection
If any Folder Redirection policy settings have been applied to the user, output similar to the following is displayed:

The user received "Folder Redirection" settings from these GPOs:
EU-RedirectedDesktop-User1
Revision Number: 14 (Active Directory) 14 (Sysvol)
Unique Name: {C19B776C-A8E8-11D2-9BEB-00A024070A22}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-FolderRedirection-User1 Revision Number: 12 (Active Directory) 12 (Sysvol)
Unique Name: {FBEE2508-BCAA-11D2-B3EE-00C04FA3787A}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)
Desktop is redirected to \\ntpolicy1\desktop\%username%
My Pictures is redirected to \\ntpolicy1\mydocs1\%username%\My Pictures
My Documents is redirected to \\ntpolicy1\mydocs1\%username%

Output details:
• The output is a list of Group Policy objects that contain Folder Redirection policy settings (including Local Group Policy).
• Each Group Policy object is displayed with the following details:
• Friendly name
• Revision number
• Unique name (GUID or Local Group Policy)
• Domain name
• Linking information
• A list of the folders that have been re-directed, and their re-directed location, is also displayed.

Scripts
If any Scripts policy settings have been applied to the user, output similar to the following is displayed:

The user received "Scripts" settings from these GPOs:EU-Marketing Revision Number: 12 (Active Directory) 12 (Sysvol)
Unique Name: {EF068882-A229-11D2-B575-0008C7457B4E}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-Canada Revision Number: 44 (Active Directory) 44 (Sysvol)
Unique Name: {HJ924782-A444-11D2-B444-00039573954F}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)
Logon scripts specified in: EU-Marketing \\marketing1\logon$\adlogon.bat
Logoff scripts specified in: EU-Marketing \\marketing1\logon$\adlogoff.bat
Logon scripts specified in: EU-Canada \\toronto3\logon$\pplogon.bat
Logoff scripts specified in: EU-Canada \\toronto3\logon$\adlogoff.bat

Output details:
• The output is a list of Group Policy objects that contain Scripts policy settings (including Local Group Policy).
• Each Group Policy object is displayed with the following details:
• Friendly name
• Revision number
• Unique name (GUID or Local Group Policy)
• Domain name
• Linking information
• A list of scripts that were run is displayed with the following details:
• Type of script (logon, logoff, startup, shutdown)
• Script name
• Location from where the script was run

Application Management
If any Application Management policy settings have been applied to the user, output similar to the following is displayed:

The user received "Application Management" settings from these GPOs: EU-CorpStandard
Revision Number: 156 (Active Directory) 156 (Sysvol)
Unique Name: {9B4293472AC06-44D2-B22A-0008C7457E8J}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-RedmondSite Revision Number: 1536 (Active Directory) 1536 (Sysvol)
Unique Name: {9B4999999AC06-12O2-B66A-0008C7457B4E}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)
The user has been assigned the following applications: Microsoft Office 2000 Premium (RTM)
GPO Name: EU-CorpStandard Removal Option: Application is uninstalled when policy is removed Microsoft FrontPage 20000 GPO Name: EU-RedmondSite Removal Option: Application is uninstalled when policy is removed The user has installed the following published applications: WinZip 7.0 GPO Name: EU-CorpStandard Removal Option: Application is uninstalled when policy is removed

Output details:
• The output is a list of Group Policy objects that contain Application Management policy settings (including Local Group Policy).
• Each Group Policy object is displayed with the following details:
• Friendly name
• Revision number
• Unique name (GUID or Local Group Policy)
• Domain name
• Linking information
• A list of assigned and published applications is displayed with the following details:
• Assigned or published
• Name of application
• Name of Group Policy object where the application was configured
• Removal Option information for the application

If GPResult had instead been run in Super verbose mode (/s), it would also have provided information on which applications would be available in Add/Remove Programs. The output would look similar to the following:

The user has the following applications available in Add/Remove Programs:
Microsoft Money 99
GPO Name: EU-RedmondSite
Installed: No
Connection Manager Self Host -- Smart Card Corpnet Access
GPO Name: EU-RedmondSite
Installed: No
Microsoft Excel 97 SR2 (Legacy Deployment)
GPO Name: EU-RedmondSite
Installed: No

Output details:
• The output is a list of applications that will appear in Add/Remove Programs. The details provided are:
• Name of application
• Name of Group Policy object where the application was configured
• Installed or not installed

Other Group Policy Extensions
For other Group Policy extensions that ship with Windows 2000 that have been applied to the user, the following is displayed for each of these extensions:

The user received "Name of the Extension" settings from these GPOs: EU-SecurityB31
Revision Number: 14 (Active Directory) 14 (Sysvol)
Unique Name: {C19ASDAS-ADD8-11D2-9BEB-002342342342}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-SecurityHR Revision Number: 12 (Active Directory) 12 (Sysvol)
Unique Name: {FBEASDAS-BDDA-11D2-B3EE-002342342342}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)

Computer Output
This section repeats the same processes as above for User Output, but this time displays information for the computer that the user has logged on to.
The output begins with general information for the computer, including the computer name and location, domain name, domain type and site name as indicated below.

Computer Group Policy results for: CN=DEVPC01,CN=Computers,DC=ntdev,DC=microsoft,DC=com Domain Name: NTDEV Domain Type: Windows 2000 Site Name: Red-Bldg99

After detailing the general information, the output shows a time stamp of when the last time Group Policy was applied to this computer and the domain controller from which Computer Group Policy was applied.

Last time Group Policy was applied: Monday, September 07, 1999 at 7:51:59 AM
Group Policy was applied from: NTDS.ntdev.microsoft.com

The Registry Based Policy, Folder Re-direction, and other Group Policy extensions that have been applied to this computer are detailed at this point. This information is output in the same format as detailed earlier in this document for the User Output.

In addition, the Computer section displays the following when applicable:

IP Security
If any IP Security policy settings have been applied to the computer, output similar to the following is displayed:

The computer received "IP Security" settings from these GPOs: EU-IPSecDefaultClientPol-RandyRam
Revision Number: 5 (Active Directory) 5 (Sysvol)
Unique Name: {6EB61A60-A991-11D2-9BEB-00A024070A22}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)
Policy Name: NTDEV Default Client
Policy Description: All NTDEV machines get this
Policy Path: LDAP://CN=ipsecPolicy{163E9FDB-A9AE-11D2-AFD6-006097936A9F}CN=IPSecurity,CN=System,DC=ntdev,DC=microsoft,DC=com

Output details:
• The name of the Group Policy object that applied IP Security settings. For this Group Policy object, the following details are displayed:
• Friendly name
• Revision number
• Unique name (GUID or Local Group Policy)
• Domain name
• Linking information
• IP Security settings details:
• Policy name
• Description
• Policy path

Disk Quotas
If any Microsoft Disk Quota policy settings have been applied to the computer, output similar to the following is displayed:

The computer received "Microsoft Disk Quota" settings from these GPOs: Local Group Policy
Revision Number: 25
Unique Name: Local Group Policy
Domain Name:
Source: Local computer
Disk Quotas enabled: Yes
Disk Quotas enforced: Yes
Quota limit: 80 MB
Warning level: 120 MB
Log event when quota limit exceeded: No
Log event when quota warning level exceeded: No
Apply policy to removable media: No

Output details:
• The name of the Group Policy object that applied Microsoft Disk Quotas. For this Group Policy object, the following details are displayed:
• Friendly name
• Revision number
• Unique name (GUID or Local Group Policy)
• Domain name
• Source
• Disk Quota details:
• Disk Quotas enabled: yes/no
• Disk Quotas enforced: yes/no
• Quota limit
• Warning level
• Log event when quota limit reached: yes/no
• Log event when quota warning level exceeded: yes/no
• Apply policy to remove media: yes/no

Security Privileges
Here is a complete list of security privileges that can be tracked by GPResult in verbose mode:
"Create a token object"
"Replace a process level token"
"Lock pages in memory"
"Increase quotas"
"Add workstations to domain"
"Act as part of the operating system"
"Manage auditing and security log"
"Take ownership of files or other objects"
"Load and unload device drivers"
"Profile system performance"
"Change the system time"
"Profile single process"
"Increase scheduling priority"
"Create a pagefile"
"Create permanent shared objects"
"Back up files and directories"
"Restore files and directories"
"Shut down the system"
"Debug programs"
"Generate security audits"
"Modify firmware environment values"
"Bypass traverse checking"
"Force shutdown from a remote system"
"Remove computer from docking station"
"Synchronize directory service data"
"Enable computer and user accounts to be trusted for delegation"

GPMonitor.exe
The Group Policy Monitor tool, gpmonitor.exe, collects information at every Group Policy refresh and sends that information to a centralized location that you specify. There are two parts to this tool, the gpmonitor service, which collects the data at the client and sends it to the central location, and a viewer that you can use to examine the data. Both portions are wrapped in a Windows Installer package.
Gpmonitor is included in the Windows Server 2003 Deployment Kit. For more information, see the Gpmonitor Help.
GPOTool.exe
GPOTool.exe is a command-line tool to be used in replicated domains—domains that contain more than one domain controller. It traverses all of your domain controllers and checks consistency for each domain controller between the Group Policy container (information contained in the directory service) and the Group Policy template (information contained in the SYSVOL on a domain controller). The tool also determines whether the policies are valid and consistent between all of your domain controllers and displays detailed information about the Group Policy objects (GPOs) that have been replicated between your domain controllers.

If you suspect you are having problems with replication of Group Policy information, this tool will help you diagnose and isolate where Group Policy is not being replicated properly. Additional features let you:
· Search for specific GPO information, based on the name or the globally unique identifiers (GUIDs) of that GPO.
· Limit your checking to specific or preferred domain controllers.
· Go to other domains and verify that policies are replicating across these domains—other than the domain you are currently working in.
The following section explains GPOTool features in more detail.
GPOTool can:
· Check Group Policy object consistency. The tool reads mandatory and optional directory services properties, version, friendly name, extension, GUIDs and SYSVOL data, compares directory services and SYSVOL version numbers, and performs other consistency checks. Functionality version must be 2 and user/computer version must be greater than 0 if the extensions property contains any GUID.
· Check Group Policy object replication. It reads the Group Policy object instances from each domain controller and compares them (selected Group Policy container properties and full recursive compare for the Group Policy template).
· Display information about a particular Group Policy object. This includes properties that can't be accessed through the Group Policy snap-in such as functionality version and extension GUIDs.
· Browse Group Policy objects. A command-line option can search policies based on friendly name or GUID. A partial match is also supported for both name and GUID.
· Use preferred domain controllers. By default, all available domain controllers in the domain will be used; this can be overwritten with the supplied list of domain controllers from the command line.
· Provide cross-domain support. A command-line option is available for checking policies in different domains.
· Run in verbose mode. If all policies are fine, the tool displays a validation message; in case of errors, information about corrupted policies is printed. A command-line option can turn on verbose information about each policy being processed.
Availability
GPOTool.exe ships with the Windows 2000 Server Resource Kit and is also available as a free download at http://www.microsoft.com/windows2000/library/resources/reskit/tools/existing/gpotool-o.asp.

GPOTool can do any of the following:
· Check Group Policy object consistency. The tool reads mandatory and optional directory services properties, version, friendly name, extension, GUIDs and SYSVOL data, compares directory services and SYSVOL version numbers, and performs other consistency checks. Functionality version must be 2 and user/computer version must be greater than 0 if the extensions property contains any GUID. The tool also checks the timestamps of GPOs in the SYSVOL folder.
· Check Group Policy object replication. It reads the Group Policy object instances from each domain controller and compares them (selected Group Policy container properties and full recursive compare for the Group Policy template).
· Display information about a particular Group Policy object. This includes properties that can't be accessed through the Group Policy snap-in such as functionality version and extension GUIDs.
· Browse Group Policy objects. A command-line option can search policies based on friendly name or GUID. A partial match is also supported for both name and GUID.
· Use preferred domain controllers. By default, all available domain controllers in the domain will be used; this can be overwritten with the supplied list of domain controllers from the command line.
· Provide cross-domain support. A command-line option is available for checking policies in different domains.
· Run in verbose mode. If all policies are fine, the tool displays a validation message; in case of errors, information about corrupted policies is printed. A command-line option can turn on verbose information about each policy being processed.

Software Installation Diagnostics Tool (addiag.exe)
The Windows 2000 Server Resource Kit and the Windows 2003 Support Tools includes an advanced troubleshooting tool, Software Installation Diagnostics (addiag.exe) that you can use to gather additional diagnostic information when troubleshooting Software Installation policy issues.
The binary executable for this tool is Addiag.exe. Running addiag.exe /? from a command prompt provides the usage syntax.
This tool displays detailed information about the applications visible in Active Directory and installed for the current user, as well as general diagnostic information and related Event Log entries.

Client Log Files
Log files can be generated by the core client engine (UserEnv) and by every CSE except the Scripts CSE. Scripts processing is logged in the Application log on the client with source=UserInit. Use Event Viewer to view the Application log on the client, or look for these entries on the Policy Events tab of the Group Policy Results report.

The Policy Events tab in Group Policy Results reports generated in GPMC displays the Group Policy–related events that you would see if you used Event Viewer to view these events in the Application log on the client for which you generated the report.
Table 4 lists several log files you can generate at the client that relate to Group Policy troubleshooting.
Table 4 Client Log Files for Troubleshooting Group Policy -
Output from:
Is located in this file:
Enable verbose logging by adding this key or value…
…to this registry key
Group Policy core (UserEnv) and registry CSE
%windir%\debug\usermode\UserEnv.log
UserEnvDebugLevel = REG_DWORD 0x10002
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Security CSE
%windir%\security\logs\winlogon.log
ExtensionDebugLevel = REG_DWORD 0x2
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GpExtensions\{827d319e-6eac-11d2-a4ea-00c04f79f83a}\
Folder Redirection CSE
windir%\debug\usermode\fdeploy.log
FdeployDebugLevel = Reg_DWORD 0x0f
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Software Installation CSE
%windir%\debug\usermode\appmgmt.log
Appmgmtdebuglevel=dword:0000009b
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Windows Installer(deployment-related actions)
%windir%\temp\MSI*.log
Logging = voicewarmup
Debug = DWORD: 00000003
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Windows Installer(user-initiated actions)
%temp%\MSI*.log
Logging = voicewarmup
Debug = DWORD: 00000003
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Notes
The UserEnv logs entries pertaining to profiles as well as Group Policy core processing and registry (.adm) processing on the client. The entries pertaining to profiles are intermingled with the Group Policy entries and not easily distinguished from them.
Use Wilogutl.exe to analyze the Windows Installer log files. For more information see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/wilogutl_exe.asp (http://go.microsoft.com/fwlink/?LinkID=16156).

What’s in the Userenv log?
As shown in Figure 2 below, the Userenv log provides details of errors in core Group Policy processing on your machine. Reading from left to right, this log shows a process code (for example, cc.500), the time it was processed (note the date is not displayed), the process name, followed by a short statement of the error.

Figure 2. Userenv log displays Group Policy process failures and warnings.
Note: The Userenv log has a maximum size of 1 megabyte (MB). At system startup, if the log file exceeds 1 MB, the contents is copied into a Userenv.bak file and a new Userenv log is created. Note the log file exceeds 1MB if the system remains running without being restarted.

Troubleshooting Information from the Event Log
In addition to the Userenv log you can check the Event Log service for failures and warnings from Group Policy (source of Userenv in the application Event Log).
Note: Not all failures are displayed in the Event Log to avoid “flooding“ the log, which could be a problem if you were using a laptop, for example. To retrieve more detailed information on the policy processing displayed through the Event Log, enable verbose logging as explained below.

Verbose Logging to Event Log
When you turn on the switch for verbose logging, it generates all Group Policy-related events and stores them in the Event Log.
Use the following registry key to start verbose logging:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Set: RunDiagnosticLoggingGroupPolicy = REGDWORD 1

Note: This does not show all failures and warnings – Userenv logging will show much more information.
GP Editing Failures
Because problems can occur when editing GPOs, it is sometimes necessary to track error information by turning on the following logs:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
To generate the log file for GP Editor:
Set GPEditDebugLevel = REG_DWORD 0x10002
Log file location: %windir%\debug\usermode\gpedit.log

To generate the log file for some GP CSE information:
Set GPTextDebugLevel = REG_DWORD 0x1002
Log file location: %windir%\debug\usermode\gptext.log

Note: For log file settings to apply you need to restart the Group Policy editing session. For example, if you were editing policy via the Active Directory Users and Computers tool, you would need to close the entire tool and restart it in order to see the editing log information.

ACTIVE DIRECTORY WINDOWS 2000/2003

Wednesday, September 26, 2007

Operations master roles {FSMO Roles}

Monday, September 24, 2007

Group Policy in NuttShel

Look into his eyes

Blog Archive

About Me

Think again.....Chanakya quotes