Microsoft

Six solutions to Windows Server 2003 group policy problems

Group policies are very powerful tools when it comes to controlling user behavior, but they can also cause you lots of headaches when things conflict. Here are some solutions to the most common problems.


If you’ve used Windows 2000 and are either dabbling in Windows Server 2003 or have begun a deployment, you’re at least somewhat familiar with group policy and how it can be used to greatly simplify management of your infrastructure. Unfortunately, like everything else, group policy eventually requires troubleshooting when the unexpected happens. Here are six problems you might run into with group policy in Windows Server 2003 and their solutions.

1. Unexpected results for a specific user and computer
Assume that you have created a new setting group policy object. However, the setting is not being applied to the target. Group policy problems like this can be somewhat difficult to track down. However, Microsoft has made available a new Group Policy Management Console that you can download for free, which includes a wizard that allows you to quickly view the Resultant Set of Policy (RSoP) information associated with the policy. Figure A shows the RSoP for a particular user on a particular machine.

Figure A
RSoP for Administrator on the server named RAS


As you can see, the default domain policy was denied as a result of a false Windows Management Instrumentation (WMI) filter. This provides a great first step in figuring out exactly where the group policy problem is taking place. In this case, the policy is not being applied because the WMI filter dictates that it is only applied to the user when logging into Windows XP Professional. This particular user is currently logged into a Windows Server 2003 machine, thereby resulting in a failed filter. Figure B shows the WMI filter that is causing the GPO application to fail on Windows Server 2003.

Figure B
The WMI filter dictates Windows XP Pro.


Alternatively, you can use the gpresult.exe Windows Server 2003 Resource Kit command line utility to view the details of the RSoP operation. Because GPMC is so powerful and easier to use, I won’t be going over gpresult.exe in this article.

2. Policies are applied to Windows 2000 machines even though they fail a WMI filter test
This is an easy one to figure out. WMI filters are supported only under Windows XP and Windows Server 2003 clients. Windows 2000 does not support WMI filters, so the policy is applied regardless.

3. Policies aren’t applied to Windows NT or Windows 9x machines
Only computers running Windows 2000 and later can use group policy. Older systems do not support it.

4. You can't administer a GPO
Like most other objects, group policy objects have security permissions associated with them. If you’re having trouble with a GPO, you might not have the appropriate rights to administer it. To check who has rights to a GPO, start the Group Policy Management Console and select the GPO under the domain you're working with. Select the Delegation tab to view the users and groups that have permission to the GPO.

As you can see in Figure C, Authenticated User can read the GPO, which is useful since it wouldn’t be applied otherwise, and various other objects have permission to edit it, delete it, and to perform other functions.

Figure C
GPO security information


To fix this problem, you’ll need to log on as a user with the appropriate rights to modify the GPO. From there, you can either modify the GPO to exhibit the proper behavior or assign rights to the original user object to change it. Ideally, add the administrative user object that did not have permission to modify the GPO to a group that does have the rights, rather than assigning the rights directly to the user object.

5. You just applied changes to a GPO but the clients aren’t getting them
This assumes that you know the machines pass the RSoP tests and that you know for a fact that the client should be getting the policy setting. There are a couple of possibilities with this one.

First, if you have multiple domain controllers, wait for a little while to make sure that the policy has had time to replicate to all of the other domain controllers on the network. If it hasn’t had time, this will likely be the cause of your problem.

If it’s been a while, and a new policy setting has still not taken effect, use the GPOTool to check replication status. The GPOTool reads all group policy information from each domain controller and compares it all. GPOTool can be downloaded from Microsoft as a part of the Windows Server 2003 Resource Kit. You can use this utility by just typing gpotool at the command prompt. When you do, you'll see output similar to this:
C:\Documents and Settings\Administrator>gpotool
Validating DCs...
Available DCs:
ras.example.com
Searching for policies...
Found 2 policies
============================================================
Policy {31B2F340-016D-11D2-945F-00C04FB984F9}
Friendly name: Default Domain Policy
Policy OK
============================================================
Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Friendly name: Default Domain Controllers Policy
Policy OK
============================================================
 
Policies OK

In this instance, there is a single domain controller, and all of the policies tested as OK. GPOTool has a number of command line options:
  • /gpo:GPO[,GPO]…— The GPOs to check; can be specified by GUID or GPO name; when omitted, all GPOs in the domain are processed
  • /domain:name—The name of the domain in which the GPOs are located.
  • /dc:{domain controller}[,{domain controller}—The list of domain controllers on which to process GPOs
  • /checkacl—Verify the ACLs for the sysvol on each server
  • /verbose—Show detailed information during processing

If you find a problem with replication between your domain controllers, correct it and attempt the group policy operation again. While not a recommended course of action long term, you can try to force replication to see if that corrects the GPO problem.

More about replication and group policy
Group policies rely on both Active Directory and file system replication. Active Directory replication is responsible for replicating the directory group policy container, including information about which policies apply to which users and computers. File system replication is used to replicate the SYSVOL share which contains a template for each GPO. Only Active Directory replication can be forced.

Client group policy refresh
A second potential cause of the problem lies at the client and the group policy refresh interval which defines how often changes to group policies will be put into effect. By default, client computers refresh their group policy information every 90 minutes +/- 30 minutes. If you need a setting to take effect immediately, you should know that there are some other events that trigger a group policy refresh:
  • When a user logs on to the machine
  • At system startup
  • When the command line utility ‘gpupdate’ is run at the client

6. GPO showing up as Empty
If a GPO is coming up as being Empty that simply means that there are no policies set inside the GPO. In this instance, there are two appropriate courses of action. First, you can—get ready for it—add some settings. Second, you can remove the link between the domain and the GPO. To unlink a GPO from a domain using GPMC, right-click the GPO and deselect the Link Enabled option, as shown in Figure D.

Figure D
Deselecting a link between a GPO and a domain


Difficult, but worth it
A complex but useful service, Group Policy at times requires troubleshooting steps to be taken. Fortunately, a lot of the problems can be quickly tracked down using readily available tools, most especially the new Group Policy Management Console available from Microsoft.

Editor's Picks