1. Understanding When Settings Take Effect
If you understand the way in which policy settings are created,
stored, and applied to clients, you can troubleshoot Group Policy more
effectively. In this section, you review the components, processes,
and dependencies of the Group Policy framework. For policies to take
effect:
-
GPO replication must occur.
Before a GPO can take effect, the GPC in Active Directory must be
replicated to the domain controller from which the Group Policy
Client obtains its ordered list of GPOs. Additionally, the GPT in
SYSVOL must replicate to the same domain controller. -
Group changes must be
incorporated. If you have added a new group, or changed
the membership of a group that is used to filter the GPO, that
change must also have replicated, and the change must be in the
security token of the computer and the user, which requires a
restart (for the computer to update its group membership) or a
logoff and logon (for the user to update its group
membership). -
The user or computer Group Policy
refresh must occur. As you know, refresh happens at
startup (for computer settings) and logon (for user settings) and
every 90 to 120 minutes thereafter, by default.
Note
AN AVERAGE OF 45–60
MINUTES
Keep in mind that the practical impact of the Group Policy
refresh interval is that when you make a change in your environment,
it will be on average one-half that time, or 45
to 60 minutes, before the change starts to take
effect.
Even if all of the preceding conditions are true, a setting
might not apply correctly. When this happens, consider the
following:
-
Startup behavior of Windows clients
might not apply the latest policies. By default, Windows
XP, Windows Vista, and Windows 7 clients perform only background
refreshes at startup and logon, meaning that a client might start
up and a user might log on without receiving the latest
policies from the domain. It is highly recommended that
you change this default behavior so that policy changes are
implemented in a managed, predictable way. Enable the Always Wait
For The Network At Computer Startup And Logon policy setting for
all Windows clients.
-
Settings might not take effect
immediately. Although most settings are applied during a
background policy refresh, some CSEs do not apply the setting
until the next startup or logon event. Newly added startup and
logon script policies, for example, do not run until the next
computer startup or logon. Software installation,
occurs at the next startup if the software is assigned in computer
settings. Changes to folder redirection policies do not take
effect until the next logon. -
Most CSEs do not re-apply settings if
the GPO has not changed. Remember that most CSEs apply
settings in a GPO only if the GPO version has changed. That means
that if a user can change a setting that was originally specified
by Group Policy, the setting will not be brought back
into compliance with the settings specified by the GPO until the
GPO changes. Luckily, most policy settings cannot be changed by a
nonprivileged user. However, if a user is an administrator of his
or her computer, or if the policy setting affects a part of the
registry or system that the user has permissions to change, this
could be a real problem.
You have the option of instructing each CSE to reapply the
settings of GPOs even if the GPOs have not been changed.
Processing behavior of each CSE can be configured in policy
settings found in Computer Configuration\Policies\Administrative
Templates\System\Group Policy.
When settings do not apply as expected, you can do the
following:
-
Manually refresh Group Policy with
GPUpdate. When you are experimenting with Group Policy or
trying to troubleshoot Group Policy processing, you might need to
initiate a Group Policy refresh manually so that you do not
have to wait for the next background refresh. The GPUpdate command
can be used to initiate a Group Policy refresh. Used without
parameters, GPUpdate triggers processing identical to a background
Group Policy refresh. Both computer policy and user policy are
refreshed. Use the /target:computer or
/target:user parameter to limit the refresh
to computer or user settings, respectively. During background
refresh, by default, settings are applied only if the GPO has been
updated. The /force switch causes the system
to reapply all settings in all GPOs scoped to the user or
computer. Some policy settings require a logoff or reboot before they actually take effect.
The /logoff and /boot
switches of GPUpdate cause a logoff or reboot, respectively, if settings are applied that require one.
So the command that causes a total refresh, application of
updated policy settings, and (if necessary) reboot and logon
is:
gpupdate /force /logoff /boot
2. Resultant Set Of Policy
Resultant Set Of Policy (RSOP) is the net
effect of GPOs applied to a user or computer, taking into account GPO
links, exceptions such as Enforced and Block Inheritance, and the
application of security and WMI filters.
RSOP is also a collection of tools that help you evaluate,
model, and troubleshoot the application of Group Policy settings. RSOP can query a local or remote computer and report back the exact
settings that were applied to the computer and to any user who has
logged on to the computer. RSOP can also model the policy settings
that are anticipated to be applied to a user or computer under a
variety of scenarios, including moving the object between OUs or sites
or changing the object’s group membership. With these capabilities,
RSOP can help you manage and troubleshoot conflicting policies.
Windows Server 2008 R2 provides the following tools for
performing RSOP analysis:
Generating RSOP Reports with the Group Policy Results
Wizard
To help you analyze the cumulative effect of GPOs and policy
settings on a user or computer in your organization, Group Policy
Management includes the Group Policy Results Wizard. If you want to understand
exactly which policy settings have applied to a user or computer,
and why, the Group Policy Results Wizard is the tool to
use.
The Group Policy Results Wizard reaches into the WMI provider
on a local or remote computer. The WMI provider can report
everything there is to know about the way Group Policy was applied
to the system. It knows when processing occurred, which GPOs were
applied, which GPOs were not applied and why, errors that were
encountered, and the exact policy settings that took precedence and
their source GPOs.
There are several requirements for running the Group Policy Results Wizard:
-
You must have administrative credentials on the target
computer. -
The target computer must be running Windows XP or later.
The Group Policy Results Wizard cannot access Windows
2000 systems. -
You must be able to access WMI on the target computer.
That means that it must be powered on, connected to the network,
and accessible through ports 135 and 445.
Note
ENABLE REMOTE ADMINISTRATION OF
CLIENT COMPUTERS
Performing RSOP analysis by using the Group Policy Results
Wizard is just one example of remote administration. Windows
includes a firewall that prevents unsolicited inbound
connections, even from members of the Administrators group. To
perform remote administration, you might need to configure
inbound rules for the firewall used by your clients and
servers.
Group Policy provides a simple way to enable remote
administration. In the Computer
Configuration\Policies\Administrative
Templates\Network\Network Connections\Windows Firewall\Domain
Profile folder, there is a policy setting named Windows
Firewall: Allow Inbound Remote Administration Exception. When
you enable this policy setting, you can specify the IP
addresses or subnets from which inbound remote administration
packets will be accepted. As with all policy settings, review
the explanatory text in the Help box and test the effect of
the policy in a lab environment before deploying it in
production.
-
The WMI service must be started on the target
computer. -
If you want to analyze RSOP for a user, that user must
have logged on at least once to the computer. It is not
necessary for the user to be currently logged on.
After you have ensured that the requirements are met, you are
ready to run an RSOP analysis. To run an RSOP report, right-click
Group Policy Results in the GPMC console tree, and then click Group
Policy Results Wizard.
The wizard prompts you to select a computer. It then connects
to the WMI provider on that computer and provides a list of users
who have logged on to it. You can then select one of the users or
opt to skip RSOP analysis for user configuration policies.
The wizard produces a detailed RSOP report in a dynamic HTML
format. If Internet Explorer Enhanced Security Configuration (IE
ESC) is enabled, you are prompted to allow the console to display
the dynamic content. You can expand or collapse each section of the
report by clicking the Show or Hide link or by double-clicking the
heading of the section. The report is displayed on three
tabs:
-
Summary The Summary tab displays the status of Group Policy
processing at the last refresh. You can identify information
that was collected about the system, the GPOs that were applied
and denied, security group membership that might have affected
GPOs filtered with security groups, WMI filters that were
analyzed, and the status of CSEs. -
Settings The Settings tab displays the resultant set of policy
settings applied to the computer or user. This tab shows you
exactly what has happened to the user through the effects of
your Group Policy implementation. A tremendous amount of
information can be gleaned from the Settings tab, but some data
isn’t reported, such as IPSec, wireless, and disk quota policy
settings. -
Policy Events The
Policy Events tab displays Group Policy events
from the event logs of the target computer.
After you have generated an RSOP report with the Group Policy Results Wizard, you can right-click the
report to rerun the query, print the report, or save the report as
either an XML file or an HTML file that maintains the dynamic
expanding and collapsing sections. Either file type can be opened
with Internet Explorer, so the RSOP report is portable
outside the GPMC. If you right-click the node of the report itself
underneath the Group Policy Results folder in the console tree, you
can switch to Advanced View. In Advanced View, RSOP is displayed
using the RSOP snap-in, which exposes all applied settings,
including IPSec, wireless, and disk quota policies.
Generating RSOP Reports with Gpresult.exe
The Gpresult.exe command is the command-line version of
the Group Policy Results Wizard. GPResult accesses the
same WMI provider as the wizard, produces the same information, and,
in fact, enables you to create the same graphical reports. GPResult
is available on computers running Windows XP or later versions of
Windows. Windows 2000 includes a Gpresult.exe command, which
produces a limited report of Group Policy processing but is not as
sophisticated as the command included in later versions of
Windows.
When you run the GPResult command, you are likely to use the
following options:
-
/s
computername
Specifies the name or
IP address of a remote system. If you use a dot (.) as the
computer name, or do not include the /s
option, the RSOP analysis is performed on the local computer. -
/scope [user | computer]
Displays RSOP analysis for user or computer settings. If you
omit the /scope option, RSOP analysis
includes both user and computer settings. -
/user
username
Specifies the name of the
user for which RSOP data is displayed. -
/r Displays a summary of RSOP data. -
/v Displays verbose RSOP
data, which presents the most meaningful information. -
/z Displays super-verbose
data, including the details of all policy settings applied to
the system. Often, this is more information than you require for
typical Group Policy troubleshooting. -
/u
domain\user /p
password
Provides credentials that
are in the Administrators group of a remote system. Without
these credentials, GPResult runs using the credentials with
which you are logged on. -
[/x | /h]
filename
Saves the reports in XML
or HTML format, respectively.
|
