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.