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.