Group Policy processing requires the following protocols and ports to be open between client and Domain Controller:

You can configure RPC/DCOM to use a restricted set of high-level (>1024) by making changes to a client's registry. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomfirewall.asp for more details.

These terms refer to whether or not Group Policy processing occurs while other things are happening in Windows. For example, if computer-specific foreground processing is set to run asynchronously (as is the case by default in XP but not Windows 2000) then as Windows initially boots up, it will not wait for GP processing to finish before presenting a user logon dialog. Similarly, if user-specific foreground processing is set to run asynchronously, Windows will not wait for GP processing to finish before presenting the user's desktop. Asynchronous can speed up the startup and logon process but can also result in certain policy extensions (e.g. Folder Redirection, Software Installation) require two or more foreground processing events to take effect. A foreground processing event is a computer startup or user logon. When foreground processing is set to synchronous, then Windows waits for computer or user GP processing to complete before presenting the user a logon dialog or a desktop, respectively.

The duplicate GPO processing is a function of using Loopback policy in merge mode only (replace mode doesn't cause this). What is going on is, with replace mode, Windows basically says, don’t do any user-specific policy processing for the user logging into a loopback machine. So basically any GPOs that would normally be processed by the user, including local, site, domain and OU- linked ones, are just not processed in replace mode. Instead, all user settings come from any GPOs that apply to the loopback computer, including those linked at the local, site, domain and OU level. By contrast, merge mode says, first process all user GPOs that the user account would normally get. Then, process all user GPOs that the loopback computer would normally get. So, what that means is that policies that are higher in the hierarchy, like site and domain-linked GPOs that are processed both by the computer and the user, get processed twice. Since the computer-based loopback user settings process last, the result would normally be that any conflicting user-specific settings (like Admin. Template registry settings) would be overridden by the loopback computer settings. And that happens, however, certain policy extensions, like scripts or software installation, don't exhibit override behavior. If two scripts are in the path to be processed, they will process cumulatively rather than one overriding the other. Hence the reason you see logon scripts running twice.

There is no detailed auditing supported in Windows today, for Group Policy changes, that will tell you which GPO setting was changed. However, you can tell when something on a GPO was changed and who made the change by using native Active Directory auditing. Specifically, if you enable auditing for Directory Service Access events on you domain controllers, then each time a GPO is changed, you will see an audit event in the security log on the PDC emulator DC (by default, this is where GP changes are originated unless the administrator changes it in the GP Editor). The event you see will show up as event ID #566 and will show a change to a groupPolicyContainer type of object. And while the friendly name for the GPO will not appear in the event description, the GUID of the GPO will be listed in the Object Name field, allowing you to determine which GPO it is by simply going into GPMC and looking for that GUID.

Loopback policy is a special mode of policy processing that allows you to control what user policy a user receives based on the machine they are logging onto rather than their user account. It is used most often in Terminal Server or "Kiosk" environments, since in both of these situations you want to tightly control the user lockdown of any users logging onto these special-use machines. Loopback is configured on the designated computers that your users will be logging onto. You can enable Loopback by setting the computer-based policy found at Computer Configuration\Administrative Templates\System\Group Policy\User Group Policy loopback processing mode. Loopback comes in two flavors--merge mode and replace mode. These different modes are described in the next question.

When you remove the machine from the domain, the GP settings remain and, since its no longer in the domain, only the local GPO will process. That means that unless the local GPO overrides those domain-based settings, they will remain "tattooed" on your system indefinitely. The best way to handle that is to either move the machine outside of the scope of GP settings before removing it from the domain and let it process the removal of policies, or use the local GPO editor to override the settings on the machine as it exists right now.

The following KB article, http://support.microsoft.com/default.aspx?scid=kb;en-us;831201, describes a hotfix that you can use to modify your DCs to make the logon server always be at the top of the DFS referral list. This guarantees that the DC that your workstations use for authentication and AD access is the same as the one they use for SYSVOL, since SYSVOL is just another DFS replica set.

When you remove the machine from the domain, the GP settings remain and, since its no longer in the domain, only the local GPO will process. That means that unless the local GPO overrides those domain-based settings, they will remain "tattooed" on your system indefinitely. The best way to handle that is to either move the machine outside of the scope of GP settings before removing it from the domain and let it process the removal of policies, or use the local GPO editor to override the settings on the machine as it exists right now.

There are several reasons that I've seen that cause this error. In cases where computer policy processing is failing with this error but user policy processing is occurring just fine, it could be a network stack timing issue. In that case, check out http://support.microsoft.com/default.aspx?scid=kb;en-us;840669

In cases where its just failing outright for all policy there are at least two other possible reasons for this. The first is that one or more SYSVOL replicas on your DCs are not replicating correctly and the gpt.ini file is actually missing from a given DC that the client is hitting. In this case, Windows is not smart enough to failover to another DFS replica (SYSVOL is just a system-maintained DFS replica) and GP processing will simply fail. In that case, the quickest solution is to copy the contents of the failing GPO from a known-good copy of it on another DC. The last reason I've seen for this failing is when you've implemented a restrictive security policy on the client that is processing GPO. For example, if you implement one of the "High Security" templates from the Server 2003 security guide, which may require, for example, SMB signing of all network traffic between server and client. In that case, if the server does not support that requirement, basic file communications between the client processing GP and server will fail. Usually the solution there is to apply a less restrictive security template to the client processing GP (or to the DC serving up GP if the change was made on the DC side)

Wireless Network Policy was first added in Server 2003 and requires the Server 2003 AD schema to be installed in order to create GPOs that leverage this policy. That being said, systems running XP, SP1 and greater added the ability to process Wireless network policy but not edit it. However, you can easily remedy this situation with the following steps. Copy the following three files from a Server 2003 installation's c:\windows\system32 folder to c:\windows\system32 on the XP machine where you plan to edit your GPOs:

wlsnp.dll
wlstore.dll
ws03res.dll 

From a command prompt on the XP machine, change to the system32 directory and issue the following command:

regsvr32 wlsnp.dll

This command will register the Wireless Network Policy editor MMC snap-in extension and you should be able to edit Wireless policy from XP at that point.

A WMI filter takes the form of a WMI Query, using the WMI Query Language (WQL). However, you must preface your query with the name of the WMI namespace you will be accessing. For example, if I wanted to query for all machines running XP, SP2, my WMI Filter would look like this:

In this filter, I'm starting off by telling Windows that I want to perform a query against a WMI class that resides in the root\cimv2 namespace. After following that with a semicolon, I enter my WQL query. In the example above, I'm selecting all instances of the Win32_OperatingSystem class (there is only one on a given Windows system) whose properties Build and CSDVersion equal 2600 (the build # for XP) and "Service Pack 2". The best tool I've found for checking out the name of various WMI classes and their properties is the WMI browser, which is part of the WMI Tools download available at http://www.microsoft.com/downloads/details.aspx?FamilyID=6430f853-1120-48db-8cc5-f2abdc3ed314&DisplayLang=en.

Note that my WMI Filter Validation Tool on the Tools page lets you view, print and validate WMI filters against systems in your environment.

The two profiles govern the behavior of the Windows Firewall that ships with SP2 when the machine is in different network settings. While it may seem obvious, based on the name, when one profile is in effect over the other, the mechanism that Windows uses can sometimes be a little less than intuitive. Specifically, the domain profile is determined to be in effect when the following conditions are true:

• The computer in question is a member of a domain (otherwise standard profile is always used)
• During the last Group Policy update, if the DNS suffix of the connection over which the GP update came is the same as the DNS suffix of the current non-PPP (i.e. VPN or Dial-up) connection. For example. Let's say that during the last GP update, my computer received policy from the "Local Area Network" Connection, which has a DNS suffix of myaddomain.com. That value is then recorded in the registry and compared to the current DNS suffix of the currently active non-PPP connection. If the suffixes are the same, its assumed that I'm still on the "managed" domain network. If not, then its assumed that I'm not on the "managed" network so the standard profile is applied.