Your Guide to Group Policy Troubleshooting

[patris1]

Derek Melber

At a Glance:

• Common GPO Issues
• Group Policy Rules
• Troubleshooting GPO problems
• Tools for troubleshooting

Microsoft Active Directory has become a critical component of many IT infrastructures. One of the most important features of Active Directory is Group Policy, which allows administrators to centralize the management of domain controllers, member servers, and desktops.
While Group Policy clearly provides many benefits, it has one small glitch. It can be complex to design and implement in a large organization and even more problematic to troubleshoot when something goes awry. In this article, I'll investigate how Group Policy is structured and show you how to troubleshoot it. By the end, you will have all of the ammunition you need to tackle almost any Group Policy issue.

Troublesome Settings
There are many moving parts within Group Policy, especially in regard to the way it interfaces with the overall Active Directory® design and implementation. When troubleshooting many kinds of access and network issues, you must always include Active Directory and the basics of Group Policy implementation in your search for a solution. To begin the troubleshooting process, let's look at Group Policy settings that can be configured incorrectly, then move on to more complex issues that might cause Group Policy to malfunction.
Group Policy settings are viewed by Active Directory administrators using administrative template files (ADM or ADMX files) and the Group Policy Object Editor, or GPEdit (launched by running gpedit.msc). Using GPEdit, the administrator creates Group Policy Object files, or GPOs. The GPOs are configured to apply (or not apply) to computers and users within the Active Directory structure. There are a number of rules GPOs must follow in order to function correctly. Let's look at them now.
GPO Must Be Linked When a new GPO is created, it may not be linked to any node within Active Directory. Even though the GPO can be edited and modified, it will not affect any objects until it is linked to a node. To ensure that the GPO is properly linked, you can view the information window in the Group Policy Management Console (GPMC) that is shown in Figure 1.
Figure 1 GPO Links Are Clearly Shown (Click the image for a larger view)

GPO Must Target Correct Object As you know, Group Policy must target the correct objects in Active Directory. However, this is sometimes overlooked in the midst of a troubleshooting exercise. Within a GPO, there are two major categories: computer and user. When you configure a GPO, be sure to note if it is for a computer or user object. Then you can verify that the correct object types are placed in the Organizational Unit (OU) where the GPO is linked.
GPOs Don't Apply to Groups Although you may wish it were so, a GPO cannot apply to an Active Directory security group object. The only two objects that a GPO setting can configure are computers and users. GPOs can't configure objects via group membership. For example, if there is a GPO linked to the Finance OU, as shown in Figure 2 the only objects that will be affected by the setting are Derek and Frank. The settings in the GPO will not affect the members of the Marketing group, no matter who has membership in that group.
Figure 2 Finance OU and the Objects Within It (Click the image for a larger view)

Target Object Must Be in the Path of the GPO When you notice that a GPO setting is not affecting an object as it should, there is one more important setting-the object must be in the Scope of Management (SOM) of the GPO. This means that the object must be located under the node where the GPO is linked (even a child node will be sufficient). For example, none of the objects in the Marketing OU will be affected by a GPO that is linked to the Finance OU, as shown in Figure 3. The SOM of a GPO is from the node where it is linked, down through the Active Directory structure.
Figure 3 When OUs Are at the Same Level, GPOs Only Apply to the OU Where It Is Linked (Click the image for a larger view)

GPO Needs To Be Enabled When a GPO is created, it is not configured to make any modifications to target objects. However, it is enabled for both the computer and user portions. If either of these portions is disabled, it can be tricky to track this down. Therefore, when you are troubleshooting a GPO that will not apply, it is a good idea to check to see if some or all of the GPO is disabled. You can do so by looking under Group Policy Objects | Account Policy in the GPMC and checking the GPO status.
Some Settings Need a Reboot When a GPO setting is not working properly, it might be due to the inherent processing of GPOs. When the periodic background refresh of GPOs is triggered, it can only process some of the GPO settings, but not all. So while you may have created a setting, it may not have taken effect yet. There are some settings that are categorized as Foreground Policies, and they are only applied when the computer is rebooted or the user logs off and then logs back in. Examples of settings that behave this way include software installation, folder redirection, and script application.

Synchronous and Asynchronous Application of Settings
Within a GPO you can configure how policy application occurs at boot time and logon. The changes that you can make will either provide immediate access to the desktop while policies are still applying, or ensure all policies apply before the user has access to the desktop. Figure 4 shows how each operating system behaves by default. If you want to alter this behavior, you can modify the following policy setting:

Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon



Figure 4 Default Processing on Client

Operating System Startup Logon Policy Refresh Windows 2000 Synchronously Synchronously Asynchronously Windows XP Professional Asynchronously Asynchronously Asynchronously Windows Server 2003 Synchronously Synchronously Asynchronously


Most administrators prefer to have a synchronous application of policy, to ensure that all policies are applied before the user can access the desktop. This ensures that all security and configuration settings are applied before any work can be done by the user. Note that this is not the default state in Windows® XP Professional, which was optimized for enhanced logon speed.

Altering Default Inheritance
There are four different methods that can be used to alter the default inheritance of GPO processing. These options are powerful and should be used sparingly, as they can cause significant alterations to the behavior of Group Policy processing. They can also be very difficult to troubleshoot. The options for altering default inheritance include the following four settings and configurations:

• Block policy inheritance
• GPO enforcement
• GPO filtering of the access control list (ACL)
• Windows Management Instrumentation (WMI) Filters

Since these settings should be used sparingly, it should be easy to document when they are being used. To find out if these options are in use, look in the GPMC. Block inheritance is performed at the domain or organizational unit (OU) node in GPMC. GPO enforcement, filtering of the ACL, and WMI filtering are set on each GPO.
Alternatively you can run the Gpresult command from the target computer to get an idea about whether any of these settings are prohibiting the policies from applying. To get a more in-depth view of the resulting set of policies being applied, you can add the /v switch to the Gpresult command, which will give you the verbose output.

ADM Template Issues
When you are attempting to configure settings in a GPO under the Administrative Templates section, you are working with ADM templates. In addition to the ADM templates that ship with the operating system, you can customize your own for use in a GPO. The code in the ADM template creates the folders and policies in the Group Policy Editor under the Administrative Templates node. However, if the ADM template is corrupt, missing, or not configured properly, it's quite possible that you won't see some or all of the settings in the editor. Here are some other issues to guard against when using ADM templates.
Missing ADM Templates When you edit a GPO and find that there are settings in a custom ADM template that are not showing up in the editor, you need to import the ADM template into the GPO. You do this by simply right-clicking on the Administrative Templates node in the editor and selecting Add/Remove Templates.
Missing Preferences There are two types of settings that can be created in a custom GPO: Preferences and Policies. Policies are the default Microsoft settings that all fall into one of four subkeys in the registry, each ending with the text "Policies". Preferences are "old style" Registry modifications that don't fall under one of the four subkeys, and are difficult to reverse once configured. These preferences don't show up in the editor by default. You must enable them to show up, which is possible when you go under the View menu on the toolbar. From there, select Filtering, then check the "Only show policy settings that can be fully managed" checkbox. This will immediately display the preferences that are configured in your custom ADM templates that have been imported.

Handy Tools
There are plenty of tools available for helping you track down your Group Policy issues. Some are built into the operating system and others can be downloaded and installed. Next I'll discuss the appropriate tools so you can choose the right one for your task.
Dcgpofix There might be a time when you have an issue with one of the two default GPOs: Default Domain Policy and Default Domain Controllers Policy. If one or both of the GPOs becomes corrupted, too far out of configuration where you can't fix it, or some other unknown issue, you can use the dcgpofix tool to revert them to the default state. This tool is included in Windows Server® 2003. You should not run this tool on a Windows 2000 domain controller; use Recreatedefpol instead. And remember, when you use this tool, you will lose any customized settings.
Recreatedefpol This tool is similar to Dcgpofix, but for Windows 2000 servers. It can return the two default GPOs to their freshly installed state. This tool should only be used in a disaster recovery situation, not for routine maintenance of GPOs. You can download this tool.
Event Viewer The Event Viewer has a wealth of information regarding Group Policy. Unfortunately, it requires you to look at all of the different log files to find entries for Group Policy. There you'll find entries related to policy application, policy replication, and policy refresh, all of which can be useful when trying to track down a problem. There is not always a lot of information on specific Group Policy errors in the event logs, but remember that you can always search TechNet if you find errors you can't identify.
Gpresult This tool can only be run locally on the target computer, but it provides information about the Resultant Set of Policies (RSoP), blocked GPOs, permissions on GPOs, and much more. Using the command with the /v switch will show a great deal of information about the GPOs that are affecting the computer and about user accounts associated with the current logon session.
Gpupdate If you are implementing new GPO settings or trying to ensure that all GPO processing has occurred, you can use the Gpupdate tool. This is a command-line tool that ships with the operating system (Windows XP and greater). When you run it, it will trigger a background refresh which will apply all GPO settings that adhere to this type of refresh. If you add the /force switch, it will reapply all GPO settings, even if there have been no changes to the GPO since the last refresh. Running this command before running the Gpresult command is a very powerful method for tracking GPO issues.
Gpotool Since GPOs are replicated from the domain controller where the GPO changes initially occur to all other domain controllers, there is a chance of replication failing or not converging efficiently. The result of this is inconsistency or failure of the changes to be properly applied to the target computers. Tools such as Gpresult and RSOP can help determine what GPOs have applied, but this tool, Gpotool, can help you determine if the GPOs on each domain controller are consistent. The tool is part of the Windows Server 2003 Resource Kit at go.microsoft.com/fwlink/?LinkId=77613.
Replmon When troubleshooting replication of GPOs from one domain controller to another, it is important to know which tools you can use to help get the replication working. Since there are two parts of a GPO that must be replicated, there are two parts that need to be addressed. The first, which is the contents of SYSVOL on each domain controller, is controlled by the File Replication Service (FRS). There is really not much you can do to control this replication, except to disable and enable the service to help it trigger a replication interval. The other part of the GPO, which is stored in Active Directory, is controlled by Active Directory replication. This replication can be controlled between domain controllers in the same Active Directory site by using Active Directory Sites and Services. However, when you need to trigger a replication between domain controllers in different Active Directory sites, you need to use a tool like Replmon. Replmon can force replication of the Active Directory database across site boundaries, while Active Directory Sites and Services can't. Therefore, when you have a mismatch of Group Policy information, which is stored in Active Directory, you can use Replmon to trigger a replication process to get that information converged on each domain controller. Replmon is part of the Resource Kit and Windows XP Support Tools. You can download it at go.microsoft.com/fwlink/?LinkId=77614.
RSOP Much like the command line tool Gpresult, RSOP provides a graphical interface for looking at the settings that have been applied by all of the GPOs. RSOP.MSC is a built-in tool for Windows XP Professional and Windows Server 2003. The tool provides you with a result of all applied policy settings in a format similar to that of the Group Policy Object Editor, as shown in Figure 5.
Figure 5 Resultant Set of Policies Tool


Wrap-Up
Troubleshooting Group Policy issues is not the easiest task you will ever attempt. In fact, as this article shows, Group Policy can be quite complex. When you approach it for troubleshooting, you need to understand the core architecture and overall processing typical of Group Policy. You also need to understand how a GPO is updated, replicated, processed, and applied. If you have a good grasp of all these concepts, the troubleshooting of any particular Group Policy issue is much easier. By following the guidelines in this article and using your tools appropriately, you'll be ready to tackle all the Group Policy problems you may encounter

---

موضوعات مشابه:

• Quick Guide to Troubleshooting Group Policy Security Settings
• Microsoft Windows Group Policy Guide
• Using Group Policy Preferences to Map Drives Based on Group Membership
• Step-by-Step Guide to Understanding the Group Policy Feature Set
• Reducing the Complexity of Group Policy Troubleshooting

---

[patris1]

http://www.gpoguy.com/FAQs/Whitepapers/tabid/63/articleType/ArticleView/articleId/2/GPO-Troubleshooting-FAQ.aspx

This is really more of a checklist of the kinds of things that typically go wrong in GPO processing, and how you can check for them.
Before you do anything, make sure the GPO is really not being processed or not being processed correctly. Run gpresult.exe on the affected client to ensure that you're actually not getting the policy you expect.
1. Your AD domain controllers are not correctly registered in DNS. While it may not seem like there is any relationship btw GPO and DNS, there is. In fact, your users may be able to authenticate to the domain just fine without DNS being healthy but GPOs will not process. GPO processing requires that the various SRV records related to LDAP be located in order to successfully complete. Specifically, the _ldap._tcp.<sitename>._sites.dc._msdcs.<domainname > record must be found for domain in which the GPO resides. This name allows a machine to find a DC to query for the list of GPOs that it must process. If you have determined that GPOs simply aren't being processed, check DNS first. You can simply do an nslookup on the LDAP name above from the problem workstation to ensure its correctly being resolved to a valid DC as follows:
nslookup _ldap._tcp.mysite._sites.dc._msdcs.gpoguy.com
If the name is not resolved correctly, try restarting the Netlogon service on the missing DC to refresh SRV registration. Check the DC's system event log to make sure there aren't other issues. In larger environments this problem is usually rare, since there are usually some DCs that can be found, even if they're not in the local site.
2. Basic GPO processing infrastructure items are not available. Often times you can't simply get GPO processing going. I've pointed some reasons for this in this list but there are a few other things that you need to check to ensure that all the infrastructure is in place for healthy GPO processing. Specifically, on all client machines that process GPO, the TCP/IP NetBIOS Helper service must be running in order to successfully connect to the SYSVOL share. Additionally, sometimes a DC will have trouble sharing out SYSVOL, especially after its just been DCPromo'd. In order to ensure that the DC your workstation is using to get at the SYSVOL portion of a GPO is available, open a command shell and enter the following:
net use \\<my AD domain name>\sysvol
where <my AD domain name> is the DNS name of your AD domain (e.g. abccompany.com)
If SYSVOL is successfully shared out, then this command should succeed with the message, "The command completed successfully".

3. You have No Override or Block Inheritance Set on a GPO or Container. Sometimes, we can cause our own problems. You can set a GPO as No Override, which means any downstream GPOs are simply not processed. Or, you can set an OU with Block Inheritance, which prevents upstream GPOs from being processed. Note that No Override overrides Block Inheritance in cases where both are in place.
4. GPO synchronization is "whacked". A GPO is composed of two pieces--the GPC that resides in AD under System\Policies and the GPT that resides in SYSVOL\Policies. These two pieces replicate by default from the PDC emulator DC to all other DCs in a domain. Each piece has a version number associated with it. You can see if these version numbers are in sync by using gpotool.exe (part of the Resource Kit), the GPMC (under the Details tab on a given GPO) or Replmon.exe (from Support Tools). The following output from gpotool.exe shows where to look for this.


Note that in this figure above, I used the /verbose option to display more detail. Without the /verbose option, the only tells you that the GPO is ok--but doesn't show version information. In this case, both the DS Version (a.k.a. the GPC) and the Sysvol Version (a.k.a. the GPT) have the same number of revisions, meaning that their versions are identical and the GPO is in sync.
If these version numbers are not in sync (i.e. the GPC doesn't get replicated at the same time as the GPT or vice-versa), then the GPO will not be processed. If you find them, check the event logs on the affected DCs for NTFRS or AD replication problems. If everything seems ok, you can always resort to manually copying files from the PDC emulator SYSVOL folders to the out-of-sync DCs, but its not the best approach. If FRS replication is functioning correctly, try making a change on the GPO and see if that forces another replication event that cleans things up. Given how flaky FRS is in the current Windows Server releases and how critical it is to proper GPO processing, I highly recommend downloading and installing Microsoft's free FRS monitoring utility--called Ultrasound.

5. GPOs don't get processed unless they change. This one trips up a lot of people. By default, GPO are processed at machine startup and user logon. They are also processed in the background every 90 min. (with a randomizer) on member servers and workstations and every 5 min. on DCs. However, in all cases, a GPO is not processed by a client unless something on that GPO has changed. The client machine will keep a history of GPO versions in the registry and will compare them to the versions of each GPO that gets processed during a processing cycle. If nothing changes on the GPO, it will not be processed unless you force it to via Administrative Template policy (specifically under Computer Configuration|Administrative Templates|System|Group Policy). The problem arises when people make changes to workstation or server configurations and expect them to get cleaned up automatically via policy. It won't happen until the AD-based GPO changes, or unless you force it using the policy referenced above. Also note that the policy to force a GPO to be processed even if it hasn't changed is set per Client-Side Extension. That is, if you look in the policy area above, it will have a number of processing policy options by CSE (e.g. Registry, IE Maintenance, Software Installation, etc.).
6. Slow link detection prevents certain Policy from Processing
By default, if a client processing policy from a DC detects a slow link (<500Kb/s) to that DC, then certain policy is not processed. This includes Software Installation and Folder Redirection policy. Therefore, if for some reason the client detects a slow link, these policies won't get processed. This can be confusing, since part of the policy is being processed and part isn't. You can change the default slow link threshold via Admin. Template policy (Computer Configuration|Admin. Templates|System|Group Policy if you find this happening. You can also verify if a slow link is being detected by enabling verbose userenv.log logging (see #6 below) or by using gpresult.exe, which will tell you right at the top of its output if a slow link was detected, as shown here:
Created On 3/1/2004 at 3:00:41 PM

RSOP results for TEST\DARREN on Workstation1 : Logging Mode
-----------------------------------------------------------
OS Type: Microsoft Windows XP Professional
OS Configuration: Member Workstation
OS Version: 5.1.2600
Domain Name: TEST
Domain Type: Windows 2000
Site Name: HOME
Roaming Profile:
Local Profile: C:\Documents and Settings\DARREN
Connected over a slow link?: Yes

7. "I can't figure out what's happening during GPO processing". The biggest problem with troubleshooting GPO is figuring out what the heck happened. When I can't figure out a problem using the normal methods (e.g. gpotool.exe, gpresult.exe, event logs) I fall back to logging. Fortunately, there are a number of ways to log the GPO editing and processing operations. First off, the RSoP Logging (aka GPO Results) tools in XP, Server 2003 and GPMC uses WMI to report what policy settings were applied to a given workstation or user. This gives you the effective policy, assuming everything worked well. If there are problems with GPO processing, they are generally logged to the Application event log on the client or in a log file called %systemroot%\debug\usermode\userenv.log. You can just adjust the verbosity of both of these logs. To increase verbosity of Application event logs, create the following registry value (this requires a reboot to go into effect:
\HKLM\Software\Microsoft\Windows NT\Diagnostics\RunDiagnosticLoggingGroupPolicy DWORD 0x1
This will generate an event log entry for each step of the GPO processing cycle.
To enable verbose userenv.log logging, check out http://support.microsoft.com/default.aspx?scid=kb;en-us;221833 which describes this perfectly. I find that userenv.log logging is much better for describing whether a particular GPO or part of a GPO is not being processed, and why. It will also tell you if a slow link has been detected (see #5 above).
There are a number of other logs that you can enabled for some of the specific CSE behavior. Fortunately, I made it a bit easier to enable all these logs without having to remember all of the different registry keys. If you go here you can download my gpolog.adm file, which lets you implement a variety of logging using Group Policy itself. Keep in mind a couple of things when you enable logging. First off, some of these logging parameters aren't activated until after you reboot the system. I find this especially true on Win2K and not as much on XP. Second, make sure that you don't leave these logs enabled in their most verbose mode as they can bog down a system's performance each time GPOs are processed

[patris1]

http://blogs.technet.com/grouppolicy/archive/2009/03/27/group-policy-preferences-not-applying-on-some-clients-client-side-extension-xmllite.aspx

Group Policy Preferences Not Applying on Some Clients: Client-Side Extension, XMLLite

Group Policy Preferences quick tip: To ensure that preferences are applied to clients, make sure that clients have the CSEs and XMLLite installed
If you’re like us, you’re seriously excited about Group Policy Preferences. You’re excited because you can’t wait to save yourself scripting time, and to use the rich administration UI and item-level targeting capabilities of Group Policy Preferences to better manage your clients. So you’ve configured several preference items in the GPMC and added them to a GPO. And now you want to apply these preference items to clients. To make sure that your preference items are actually applied to clients,you’ll need to do the following to make sure that everything is in place:
1. Install the Group Policy Client-Side Extensions (CSEs) on any clients on which you plan to deploy preference items, if the CSEs are not already installed by default. These are required for clients to process Group Policy Preferences.
2. Install XMLLite on the same clients, it is not already installed by default. (No, XMLLite is not a beer, it’s a lightweight XML parser.)
There are two main options for how to install the CSEs and XMLLite:
Option 1: Use a script
Fortunately for us, Jakob H. Heidelberg wrote a handy script that detects whether the CSEs and XMLLite are already installed and then installs them if needed. To get the script and instructions, see: heidelbergit: How to install GPP CSEs using a Startup Script.
Option 2: Get the CSEs via Windows Update or WSUS, or from the Download Center. Then, get XMLLite from the Download Center.
If you’re going with this option, how do you know whether the CSEs and XMLLite need to be installed, and where do you get them?
CSEs: Requirements and Download Location
For the CSEs, this table summarizes requirements and tells you where to get the CSEs, if you need to get them from the Download Center rather than Windows Update or WSUS:
Operating systems
Do CSEs need to be installed?
Where to get the CSEs
Windows Server 2008
No (CSEs are already included)
N/A, not required
Windows Vista, Windows Vista with Service Pack 1
Yes
32-bit edition: Download details: Group Policy Preference Client Side Extensions for Windows Vista (KB943729)
64-bit edition:
Download details: Group Policy Preference Client Side Extensions for Windows Vista x64 Edition (KB943729)
Windows XP with Service Pack 2 or later
Yes
32-bit edition: Download details: Group Policy Preference Client Side Extensions for Windows XP (KB943729)
64-bit edition: Download details: Group Policy Preference Client Side Extensions for Windows XP x64 Edition (KB943729)
Windows Server 2003 with Service Pack 1 or later
Yes
32-bit edition: Download details: Group Policy Preference Client Side Extensions for Windows Server 2003 (KB943729)
64-bit edition: Download details: Group Policy Preference Client Side Extensions for Windows Server 2003 x64 Edition (KB943729)
XMLLite: Requirements and Download Location
For XMLLite, we have another table. First, a note on requirements. XMLLite is not needed if:
· Your clients run Windows Server 2008 or Windows Vista.
· Your clients Windows XP and Windows Server 2003 clients run Internet Explorer 7 and/or the latest service packs.
For clients that run Windows Server 2003 and Windows XP operating system versions that support the CSEs, this table summarizes requirements and tells you where to get XMLLite from the Download Center.
Operating systems
Does XMLLite need to be installed?
Where to get XMLLite
Windows XP SP3
No, XMLLite is already included
N/A, not required
Windows XP SP 2
Yes, unless Internet Explorer 7 is installed (in which case XMLLite is included)
Microsoft Download Center: Search Results
Windows Server 2003 SP2
No, XMLLite is included
N/A, not required
Windows Server 2003 SP1
Yes, unless Internet Explorer 7 is installed
Microsoft Download Center: Search Results
We hope that this information helps make your life easier. And if you need more information about Group Policy Preferences, check out the Group Policy Preferences Overview.
-Connie Rock(“and Roll”), Group Policy User Assistance
Published Friday, March 27, 2009 4:39 PM by GPTeam