SolutionBase: Troubleshooting Group Policy in Windows Server 2003

Properly setting up Group Policies in Windows Server 2003 can be very complicated. When things aren't working with them, you need a strategy to keep from going crazy. Brien Posey shows you how to troubleshoot group policies in Windows Server 2003.

One of the toughest aspects of Windows networking to troubleshoot absolutely has to be group policies. The complexity and distributed nature of the group policy object hierarchy can make troubleshooting group policy related problems a nightmare, especially in large organizations. In this article, I will discuss some techniques that you can use to solve group policy related problems.

Before I begin

Group policy related problems really come in two different flavors. Some group policy related problems are administrative in nature. For example, an administrator might have trouble accessing a group policy object that they should have rights to. The more common type of group policy related problems have to do with group policy objects being applied to users and / or computers in an unexpected manner (or not at all). In this article, I will begin my discussion by talking about some common administrative issues related to creating or modifying group policy objects. I will then go on to talk about issues related to the way that group policy objects are applied.

Administrative issues

The first administrative issue that I want to talk about is that sometimes an administrator may have trouble opening a group policy object within the Group Policy Editor. In smaller organizations this doesn't tend to be a problem because typically the full burden of managing the organization falls on a hand full of administrators who have an equal set of rights. In larger organizations though, it is not uncommon for administrators to only have administrative permissions over a portion of the network.

This is the most common cause of administrators having trouble opening a group policy object. In order to open a group policy object through the Group Policy Editor, an administrator must have both read and write permissions over the group policy object. Read permissions alone won't allow the group policy object to be opened within the object editor.

A similar issue that an administrator might encounter when attempting to open a group policy object is that they may receive a message indicating that the Group Policy Editor failed to open a group policy object. Although this particular issue may at first sound similar to the rights issue that I just described, this particular issue is more commonly related to network functionality issues.

Typically, if an administrator receives an error message stating that the Group Policy Editor failed to open a group policy object, it means that for some reason the computer that the administrator is using is having trouble communicating with the Active Directory. There are a number of issues that can cause this, but assuming that the Active Directory appears to be working for everyone else, and no domain controllers are offline or anything like that, the issue is most likely DNS related. The computer that the administrator is using might be configured to use the wrong DNS server or it may be having trouble communicating with a DNS server due to a link failure.

Another strange issue that you may occasionally encounter is that when an administrator attempts to edit a group policy object, they may receive an error message indicating that the Active Directory container is missing. As the message implies, this particular error occurs when a group policy object is connected to an Active Directory object (structure) that no longer exists.

There are two primary reasons why this might occur. If the Active Directory object was recently created, then there is a chance that the Group Policy Editor is attempting to retrieve the group policy object from a domain controller to which the object in question has not yet been replicated. If this happens, then usually all you have to do is to wait for the next replication cycle to complete. If the error doesn't eventually go away then you can use the Replication Monitor to test to make sure that you are not having any replication failures among your domain controllers.

The other thing that can cause the Active Directory Container Is Missing error message is that the object may have been deleted. Keep in mind that the Active Directory is a distributed environment. Therefore, if another administrator deletes an object from another domain controller, you may not see the object disappear for a while.

One last administrative issue that I want to discuss is that in some cases, when an administrator attempts to use the Group Policy Editor, they may receive an error message indicating that the snap-in failed to initialize. If you happen to receive this error message, you will be happy to know that it is related to the way that the computer that you are using is configured, and not to a problem related to the Active Directory.

More specifically, this particular error occurs when the Microsoft Management Console cannot find the file FRAMEDYN.DLL on the computer's hard disk. A normal Windows installation should never encounter this issue. However, if an installation script was used, or if hard disk corruption exists, or if the computer's path has been tampered with, then this error can become an issue.

To fix this particular problem, you must verify that the FRAMEDYN.DLL file exists within the %SYSTEMROOT%\System32\Wbem folder. Assuming that the file does exist, you must make sure that you have the rights to access the file and that the %SYSTEMROOT%\System32\Wbem folder is included in the computer's path. If the file does exist and the rights and the path appear to be correct, then it could be that the FRAMEDYN.DLL file is corrupt. You could try copying the file from another computer to see if that corrects the problem. If you do decide to copy the file from another machine though, make sure that the machine that you copy the file from is running the same service pack level as the machine that you are having problems with.

Problems with the way Group Policy settings are being applied

Now that I have talked about some of the administrative issues that you may encounter when attempting to create or modify a group policy object, I want to move on and talk about some reasons why group policy objects might not be applied in the expected manner.

There are many perfectly legitimate reasons why group policy objects might not be applied in the expected manner. However, group policy objects are also not applied in the expected manner if an administrator doesn't completely understand how group policy objects work. There are at least a couple of very common configuration errors that administrators sometimes make. The reason why the types of errors that I'm about to show you are so common is because on the surface these configurations seem perfectly logical. The problem is that group policies just do not follow this logic.

One classic example is a situation in which an administrator is experiencing problems with a group policy object not being applied to members of a security group even though the group policy object is linked to the Organizational Unit (OU) that contains the security group. This is a perfect example of a situation that seems logical, but that does not conform to the way that group policies work.

As you may know, group policies can be applied at the local computer, domain, site, and OU level to either users or computers. The problem with the situation that I described above is that the actual user objects do not exist in the OU that the group policy is applied to. The security group in question exists within the OU, but the user objects could exist anywhere within the Active Directory. Furthermore, group policies have no effect on security groups.

Therefore, if a group policy object is associated with an OU, then the policy may apply to user or computer objects within the OU (depending on how the group policy object is designed), but it will not have any effect on members of security groups unless those member objects just happen to exist within the same OU.

A similar issue that administrators sometimes encounter is that a group policy object may not seem to have any effect on users within a particular Active Directory container. The reason for this is that group policy objects can not be applied directly to an Active Directory container. Group policy objects can only be applied at the Local Computer, domain, site, and OU levels of the Active Directory.

If you need for an Active Directory object to be applied to users or computers within a specific container, then you must apply the group policy to the parent object (local computer, domain, site, or OU) that contains the container. By default, the group policy object's settings will propagate to the container's child objects, meaning that they will be applied to the container that you needed to apply the object to in the first place.

Now that I have talked about some common ways in which group policy objects are sometimes misconfigured, I want to talk about some reasons why the group policy might yield unexpected results even when a perfectly legitimate configuration is being used.

There are several things that can cause group policy settings to be applied in an unexpected manner. The most common cause of an unexplained group policy setting is that a higher level policy overrides a lower level policy. For example, suppose that a site level group policy set the minimum password length to eight characters, but an Organizational Unit level policy sets the minimum password length to six characters. Assuming that both of these policies apply to a particular user, there would be an obvious contradiction.

Windows resolves this contradiction by giving precedence to the higher level policy. In this particular case, an Organizational Unit level policy is considered to be a higher level policy than a site level policy, so the Organizational Unit policy would take precedence. Thus, the mandate for an eight character password would be replaced by a mandate for a six character password in this case.

Another common issue related to policy precedence has to do with the fact that group policies can be applied to both users and to computers. It is possible for a user level policy setting to contradict a computer level policy setting. When this happens, the computer policy setting always takes precedence. The reason why Microsoft does things this way is to protect you. For example, imagine that for some reason your company has a couple of kiosk machines set up in the lobby that anyone can use. Being that these machines are accessible to anyone who walks through the door, they would need to have a very aggressive security policy applied to them.

Since you have worked so hard to lock these machines down, you probably wouldn't want a normal user to log in to those machines and have their normal access rights. Rights that might be perfectly OK within the confines of a more physically secure portion of your network could be extraordinarily dangerous on a kiosk machine. Therefore, Microsoft makes sure that computer level group policy settings always outweigh user level group policy settings so that a computer's security is never compromised.

One last issue that can cause group policy objects to be applied in an unexpected manner is the blocking of group policy objects through the use of the No Override and Block Policy Inheritance settings. Both of these features have their place, but should be used sparingly, if at all.

As I have already explained, group policies are hierarchical. If two group policy objects contradict with each other, then the higher level group policy will take precedence. This isn't always desirable behavior though. For example, suppose that one domain in your network has some really unique security requirements. If that was the case, you probably wouldn't want that domain's group policy settings to be overwritten by the OU level policy settings. To prevent this from happening, you could apply the No Override attribute to the group policy object. This would prevent settings within the group policy object from being overwritten by higher level policy objects.

The block policy inheritance feature works in a similar, but opposite manner. Higher level group policies only override low level group policies when there is a contradiction. If no contradiction exists, then settings from low level group policies are preserved and combined with settings mandated in higher level policies. Suppose however that you were a forest admin and that there were several other Admins over individual domains within the forest.

Any one of those domain Admins has the potential to create a really strange domain level group policy. As a forest admin, it is your responsibility to keep the forest secure. In an effort to do so, you could create an OU level group policy object and assign it the block policy inheritance attribute. Doing so would prevent the OU level policy that you have created from combining with group policy settings from lower levels of the hierarchy. In effect you would be telling Windows that the policy that you have created should be the effective policy regardless of what anyone at a lower level has set.

As you can see, both the No Override and the Block Policy Inheritance functions have their place. If however you do not know that these attributes are being used, you might be confused as to why group policy objects are not combining together to form the expected resultant policy.