There are nine different types of group policies, each of which have different reasons why they might not work consistently. I'm going to assume that you're primarily using Registry-based policies (Administrative Templates) and Security policies.
When you set a Registry policy, you make an entry in a file called REGISTRY.POL that is stored under the policy folder in Sysvol. The policy folder name is the GUID of the policy. For example, if you enable the Hide My Network Places policy in the Default Domain group policy object, the system writes a line into the REGISTRY.POL file saying NONETHOOD and a few pointers at the associated Registry entry.
When a user logs on, the USERENV service queries Active Directory for associated group policy objects. The service downloads the REGISTRY.POL file for every policy linked to a Site, Domain, or Organizational Unit (OU) containing the user?s AD object. USERENV layers the REGISTRY.POL entries on top of each other to produce a Resultant Set of Policies (RSOP) which are then placed in memory in their associated Registry value. The closest OU is applied last, giving it the highest priority.
Two sets of replications must occur for a group policy to get distributed to clients correctly. Active Directory replication must distribute the update to the Group Policy Container object (GPC) while the File Replication Service (FRS) distributes the updates to Sysvol. If these two are out of sync (and they will be for a while), then you might see odd differences in the RSOP at the clients. You might also be enabling or disabling the same policy in different GPOs. You can use GPRESULT from the Resource Kit to check out the RSOP at a client. The tool emulates the same actions as USERENV and the other client-side extensions and gives you list of the policies that are downloaded. Fair warning: it takes a while to figure out all the switches for GPRESULT. You?ll be rewarded by mastering a fairly powerful tool that you will have at your disposal.
Group Policies have two components, a Computer node and a User node. The Computer node policies apply to computers with AD objects within containers linked to the GPOs. The User node policies apply to users with AD objects within containers linked to the GPOs. The User policies in a GPO linked to a container with computer objects are ignored and vice versa. This can be overridden by enabling Loopback Processing. Have you done this, possibly accidentally? You can confuse the bejeebers out of yourself by implementing loopback processing.
Okay, now let?s look at Security policies. These are handled by the SCECLI service. This service maintains a local database called SECEDIT.SDB that holds the security settings applicable to the machine. Security policies set in Active Directory are downloaded as binary blobs and applied to the SECEDIT database. Normally, this is only done: when the computer starts up ; when he computer shuts down; or every 90 minutes ?30 minutes while the computer is running (Domain controller download their security policies every 5 minutes.)
If you don?t want to wait the full 90 minutes , you can force the security policies to take effect at the local machines using the SECEDIT utility. The syntax is secedit /refreshpolicy machine_policy. There are some policies that do not work until you restart, though, so it?s best to shutdown completely and restart when troubleshooting. You can?t just log off. The computer account stays logged on in the background. You can also use SECEDIT to force down user policies by running secedit /refreshpolicy user_policy.
If you try all these tricks and you still can?t get a reliable download of policies, you need a better troubleshooting tool.
This was first published in February 2001