When you discover a problem with Group Policy processing,
you have several options for locating the source of the problem.
Because Group Policy processing has many elements with many
interdependent pieces of infrastructure, it is important that you take
a methodical approach to troubleshooting.
-
Check
the required infrastructure. Make sure that required services and
components are running and configured as expected.
-
Check computer core configuration. Verify that the computer is
connected to the network, is joined to the domain, is authenticated to
a domain controller, and has the correct system time.
-
Check the scope of management (SOM). Ensure that the user or
computer object is located under the correct organizational unit.
Ensure that the GPO is linked to the correct Active Directory node.
-
Verify that default GPO processing has not been altered. Blocking
policy inheritance, enforcing a GPO, security filtering, WMI filtering,
and Group Policy Preferences item-level targeting alter default policy
processing.
-
Ensure that the GPO and the Group Policy Preferences are not
disabled. If a GPO or a portion of a GPO is disabled, this can prevent
the application of the settings contained within the GPO from applying.
Also, if individual settings are disabled (allowed by Group Policy
Preferences), the policy might not process the settings.
Common Problems with GPOs
Although the failure of all or part of Group Policy to process can
be caused by many misconfigurations, some problems are common and can
easily be identified and fixed. This section describes a variety of
scenarios, problems, and solutions for situations in which Group Policy
fails or provides undesired results.
Many companies, including Microsoft, have reported that over 70
percent of all GPO problems are associated with DNS. So when a Group
Policy problem arises, you should always think DNS first! There can be
many hidden issues with DNS; here are the steps you should take to
check DNS settings:
-
Ensure that the client has the correct IP address configurations. If
the client cannot contact DNS, GPOs will not apply. You can run the
Ipconfig command from the command prompt to verify the IP address.
-
Make sure that the Dynamic Host Configuration Protocol (DHCP) server
has all of the IP configurations correct. These include DNS server,
default gateway, domain name, and subnet mask. The DHCP administration
tool is available in the Administrative Tools menu.
-
Make
sure that the client is receiving IP information, if it is DHCP
enabled. You can run the Ipconfig command with the /all switch to see
all related IP information for that computer.
-
Make sure that the correct records are listed in DNS, for both
client and server (including domain controllers). There must be a CNAME
entry for all computers on the network (domain controllers, servers,
and desktops), and the correct SRV records for the domain controllers
must be running the domain. Refer to the article titled “How DNS
Support for Active Directory Works,” at http://technet2.microsoft.com/windowsserver/en/library/9d62e91d-75c3-4a77-ae93-a8804e9ff2a11033.mspx?mfr=true, for information about how DNS and Active Directory work together.
-
Make sure that the correct DNS server is listed in the primary and
secondary settings on all computers (domain controllers, servers, and
desktops). Without the correct DNS server configured, the domain
controller SRV record will not be found and Group Policy will not
apply. You can view the current DNS server configured on the computer
by running the Ipconfig command with the /all switch.
Asynchronous Group Policy Processing
When Group Policy is configured to process GPO settings
asynchronously, it might take one, two, or even three reboots or logons
to get all of the settings to apply. For your review, asynchronous and
synchronous processing are defined as follows:
-
Asynchronous
. Windows does not wait for the network stack to initialize before starting and allowing the user receive the desktop.
-
Synchronous
. Windows waits for the network stack to initialize,
and all Group Policy foreground processing occurs before the user
receives the desktop.
If you want all settings to apply on a foreground refresh, you must
configure Group Policy to apply synchronously.
Foreground-Only GPO Settings
Some
GPO settings do not process in the background. For example, you might
see that a GPO setting is updated, and then run GPUpdate to apply the
setting. You run Resultant Set of Policy (RSoP) to determine whether
the policy has applied, and you notice that it has. However, the
setting that you configured in the GPO is still not appearing on the
computer.
If the setting is under a CSE such as software installation, folder
redirection, Group Policy drive maps, scripts, deployed printer
connections, Microsoft Internet Explorer branding, Group Policy
printers, or offline files, you will notice this behavior. All of the
settings that fall under these CSEs update only on a foreground
refresh.
In any case in which you are not connected to the network, you will
not get Group Policy updates. When a background or foreground refresh
occurs, Group Policy updates occur only if the entire authentication
and discovery process occurs. This includes much of what we have
discussed in this troubleshooting section, including accessing DNS,
authenticating to a domain controller, and providing the correct log-on
credentials.
To verify that you have network connectivity, you can use the Ping
command. When using the Ping command, you should always Ping many
computers and interfaces. At a minimum, you should Ping your own IP
address, the IP address of a computer on your subnet, the default
gateway, and a domain controller.
To determine which domain controller authenticated your computer at
logon, you can run the Set command from a command prompt. This command
displays many variables, but the Logonserver variable indicates which
domain controller authenticated you. You can also Ping this domain
controller name to determine whether you have connectivity.
If you do not have network connectivity, you should answer the following questions:
-
Is the network adapter enabled?
-
Is the network cable plugged in?
-
Did the DHCP server configure IP information?
-
Is the computer set up for DHCP or static IP information?
-
Is the DNS server configured properly?
-
Are the IP address and subnet mask correct if configured statically?
GPO Function after WMI Filter Deletion
WMI filters can target specific computers based on the current
state, environment, and setup of the computer. However, if you have
linked a WMI filter to a GPO, but you no longer want the WMI filter to
apply to the GPO, you should not just delete the WMI filter file.
The
reason for this is that the WMI filter file is not a part of the GPO—it
is linked to a GPO. When you delete the WMI filter file without
removing the link to the GPO, the GPO still thinks the WMI filter
should be used. When the GPO refers to the WMI filter to return the
list of objects to apply the GPO to, it returns a null set, and the GPO
will not apply to any object.
Kerberos validation and authentication will fail if the time
difference between a client computer and its log-on domain controller
is greater than five minutes. This failure can in turn cause problems
with DNS registration, Group Policy processing, and other essential
computer processes. To check a computer’s current system time and date,
type the following command exactly as shown at a command prompt.
net time \\%ComputerName%
The output is the current time and date on the local computer:
Current time at \\CLIENT1 is 12/7/2007 2:02 PM
To check the system time on the log-on domain controller, type the following command at a command prompt:
net time
The output is the current time and date on the log-on domain controller:
Current time at \\SERVER1 is 12/7/2007 2:02 PM
Note
You can type net time /set
to synchronize the local computer time with the time on the log-on
domain controller. To automatically synchronize time for all computers
in a domain, you can use the Windows Time Synchronization service
(W32Time). For more information about W32Time, refer to the article
titled “Basic Operation of the Windows Time Service” at http://support.microsoft.com/kb/224799.
When the domain controller that controls the PDC emulator role is
not available, editing of GPOs will fail. This is because the system
relies on the PDC emulator to make changes to all GPOs by default. This
is not a hard-coded feature, and in some cases it can be beneficial to
not use the PDC emulator. For example, if you want to target a domain
controller in a remote site for updating a GPO that will affect users
in the site more quickly, you will want to use the domain controller in
that site, which might not be the PDC emulator.
If the PDC emulator is not available, you will be prompted to select another domain controller, as shown in Figure 1.
In this dialog box, you can select a different domain controller to
make the changes to the GPO. The replication of both the Group Policy
template (GPT) and Group Policy container (GPC) will still function as normal, and the changes will be sent to all domain controllers as usual.
