3. Group Policy Objects
Now that you have a broad understanding of Group Policy and its
components, you can look more closely at each component. This section
examines GPOs in detail. To manage configuration for users and
computers, you create GPOs that contain the policy settings you
require. Each computer has several GPOs stored locally on the
system—the local GPOs—and can be within the scope
of any number of domain-based GPOs.
Computers running Windows 2000, Windows XP, and Windows Server
2003 each have one local GPO, which can manage configuration of that
system. The local GPO exists whether or not the computer is part of
a domain, workgroup, or non-networked environment. It is stored in
%SystemRoot%\System32\GroupPolicy. The policies in the local GPO affect only the computer on which the GPO is
stored. By default, only the Security Settings policies are configured on a
system’s local GPO. All other policies are set at Not
Configured.
When a computer does not belong to an Active Directory domain,
the local policy is useful to configure and enforce configuration on
that computer. However, in an Active Directory domain, settings in
GPOs that are linked to the site, domain, or OUs
override local GPO settings and are easier to manage than GPOs on
individual computers.
Windows Vista and Windows Server 2008 and later systems have
multiple local GPOs. The Local Computer GPO is the same as the GPO in previous
versions of Windows. In the Computer Configuration node, configure
all computer-related settings. In the User Configuration node,
configure settings you want to apply to all users on the computer.
The user settings in the Local Computer GPO can be modified by the
user settings in two new local GPOs: Administrators and Non-Administrators.
These two GPOs apply user settings to logged-on users according to
whether they are members of the local Administrators group, which
determines whether they use the Administrators GPO or the Non-Administrators GPO. You can further refine user
settings with a local GPO that applies to a specific user account.
User-specific local GPOs are associated with local, not domain, user
accounts.
RSOP is easy to determine for computer settings: the Local
Computer GPO is the only local GPO that can apply computer settings.
User settings in a user-specific GPO override conflicting settings
in the Administrators and Non-Administrators GPOs, which themselves
override settings in the Local Computer GPO. The concept is simple:
the more specific the local GPO, the higher the precedence of its
settings.
To create and edit local GPOs:
-
Click the Start button and then, in the Start Search box,
type mmc.exe and press
Enter.
An empty Microsoft Management Console (MMC) opens. -
Click File, and then click Add/Remove Snap-in. -
Select the Group Policy Object Editor and click
Add.
A dialog box appears, prompting you to select the GPO to
edit. -
The Local Computer GPO is selected by default. If you want
to edit another local GPO, click Browse. On the Users tab, you
can see the Non-Administrators and Administrators GPOs and one
GPO for each local user. Select the GPO and click OK. -
Click Finish, and then click OK to close each of the
dialog boxes.
The Group Policy Object editor snap-in is added, focused
on the selected GPO.
Remember that local GPOs are designed for nondomain
environments. Configure them for your computer at home, for example,
to manage the settings for your spouse or children. In a domain
environment, settings in domain-based GPOs override conflicting
settings in local GPOs, and it is a best practice to manage
configuration by using domain-based GPOs.
Domain-based GPOs are created in Active Directory and stored on
domain controllers. They are used to manage configuration centrally
for users and computers in the domain. The remainder of this
training kit refers to domain-based GPOs rather than local GPOs,
unless otherwise specified.
When AD DS is installed, two default GPOs are created:
-
Default Domain
Policy This GPO is linked to the domain and has no security
group or WMI filters. Therefore, it affects all users and
computers in the domain (including computers that are domain
controllers). This GPO contains policy settings that specify
password, account lockout, and Kerberos policies. You
modify the default settings in this GPO only to align with your
enterprise password and account lockout policies. You should not
add unrelated policy settings to this GPO. If you need to
configure other settings to apply broadly in your domain, create
additional GPOs linked to the domain. -
Default Domain Controllers
Policy This GPO is linked to the Domain Controllers OU. Because computer accounts
for domain controllers are kept exclusively in the Domain
Controllers OU, and other computer accounts should be kept in
other OUs, this GPO affects only domain controllers. The Default
Domain Controllers GPO should be modified to implement your
auditing policies. It should
also be modified to assign user rights required on domain
controllers.
Creating, Linking, and Editing GPOs
To create a GPO, right-click the Group Policy Objects
container and choose New.
You must have permission to the Group Policy Objects container
to create a GPO. By default, the Domain Admins group and the
Group Policy Creator Owners group are delegated the
ability to create GPOs. To delegate permission to other groups,
select the Group Policy Objects container in the Group Policy
Management console tree and then click the Delegation tab in the
console details pane.
After you have created a GPO, you can create the initial scope
of the GPO by linking it to a site, domain, or OU.
To link a GPO, right-click the site, domain, or OU and then
choose Link An Existing GPO. You can also create and link a GPO with
a single step: right-click a site, domain, or OU, and then click
Create A GPO In This Domain And Link It Here.
Note that you will not see your sites in the Sites node of the
GPMC until you right-click Sites, choose Show Sites, and select the
sites you want to manage.
You must have permission to link GPOs to a site, domain, or
OU. In the GPMC, select the container in the console tree and then
click the Delegation tab in the console details pane. In the
Permission drop-down list, select Link GPOs. The users and groups
displayed hold the permission for the selected OU. Click the Add or
Remove buttons to modify the delegation.
To edit a GPO, right-click the GPO in the Group Policy Objects container and choose Edit.
The GPO is opened in the GPME. You must have at least Read
permission to open the GPO in this way. To make changes to a GPO,
you must have Write permission to the GPO. You can set permissions
for the GPO by selecting the GPO in the Group Policy Objects container and then clicking the
Delegation tab in the details pane.
The GPME displays the name of the GPO as the root node. The
GPME also displays the domain in which the GPO is defined and the
server from which the GPO was opened and to which changes are saved.
The root node is in the GPOName
[ServerName] format. In Figure 1, the root node is
CONTOSO Standards [SERVER01.contoso.com] Policy. The GPO name is
CONTOSO Standards, and it was opened from SERVER01.contoso.com,
meaning that the GPO is defined in the contoso.com domain.
Note
EDITING GPOS IN A MULTI-SITE
DOMAIN
By default, both the GPMC and the GPME connect to a specific
domain controller in your environment: the domain controller
acting as the PDC emulator.
Connecting to the PDC emulator reduces the possibility that
a GPO might be changed on two different domain controllers, at
which point during replication there would be no way to reconcile
the changes, and only one version of the entire GPO would “win”
and be replicated. Focusing the administrative tools on one domain
controller helps ensure that changes are made in one place.
However, in a large, distributed environment, the PDC
emulator may be in a distant site, resulting in slow performance
for the GPMCs. You can right-click the root node of each console
and connect to a specific domain controller closer to you. Just be
cognizant of the replication issue: If you are the only one who is
editing a GPO, it is perfectly acceptable for you to do so on a
local, higher-performing domain controller.
Manage GPOs and Their Settings
When you right-click a GPO in the GPMC, you are presented with
a menu of useful management commands:
-
Copy
This command copies the GPO. You can then
right-click the Group Policy Objects container and click
Paste to create a new GPO that contains the
settings and configuration of the copied GPO. This is useful
when you want to create a new GPO in the same domain and start
with the same settings as an existing GPO. It is also useful to
copy a GPO into another domain—for example, between a test
domain and a production domain. To copy a GPO between domains,
add the target trusted domain to the GPMC. You must have
permission to create GPOs in the target domain. When you paste a GPO,
you have the option to copy the access control list (ACL) from
the original GPO, which preserves the security filtering, or to
use the default ACL for new GPOs in the target domain. -
Back Up As with any
critical data, it’s important to back up GPOs. Because a GPO consists of several files, objects,
permissions, and links, managing the backup and restore of GPOs could be
quite difficult. Luckily, the Back Up command pulls all of those pieces into a
single place and makes restore easy. -
Restore From
Backup This command restores an entire GPO, including
its files, objects, permissions, and links, into the same domain
in which the GPO originally existed. -
Import Settings
This command imports only the settings from a
backed up GPO. This operation does not import permissions or
links; it can be useful for transferring GPOs between
non-trusted domains that cannot use copy and paste. If a GPO
includes potentially domain-specific settings, including the UNC
paths or names of security groups, you are asked whether you
want to import those settings exactly as they were backed up, or
use a migration table that maps source to destination
names. -
Save Report
Use this to save an HTML report of the GPO settings. -
Delete This command deletes
the GPO. All links to the GPO are also deleted. -
Rename
This command changes the name of the GPO. Because
a GPO is referred to by its globally unique identifier (GUID),
all links to the GPO are preserved.
Group Policy settings are presented as GPOs in Active
Directory user interface tools, but a GPO is actually two
components: a Group Policy Container (GPC) and Group Policy Template (GPT). The GPC is an Active
Directory object stored in the Group Policy Objects container within the domain
naming context of the directory. Like all Active Directory objects,
each GPC includes a GUID attribute that uniquely identifies the
object within Active Directory. The GPC defines basic attributes of
the GPO, but it does not contain any of the settings. The settings
are contained in the GPT, a collection of files stored in the SYSVOL
of each domain controller in the
%SystemRoot%\SYSVOL\Domain\Policies\GPOGUID
path, where GPOGUID is the GUID of the GPC.
When you make changes to the settings of a GPO, the changes are
saved to the GPT of the server from which the GPO was
opened.
By default, when Group Policy refresh occurs, the CSEs apply
settings in a GPO only if the GPO has been updated. The Group Policy
Client can identify an updated GPO by its version number. Each GPO
has a version number that is incremented each time a change is made.
The version number is stored as an attribute of the GPC and in a
text file, GPT.ini, in the GPT folder. The Group Policy Client knows
the version number of each GPO it has previously applied. If, during
Group Policy refresh, it discovers that the version number of the
GPC has been changed, the CSEs are informed that the GPO is
updated.
The two parts of a GPO are replicated between domain
controllers by using distinct mechanisms. The GPC in Active
Directory is replicated by the Directory Replication Agent (DRA), using a topology
generated by the Knowledge Consistency Checker (KCC) that can be
refined or defined manually. The result is
that the GPC is replicated within seconds to all domain controllers
in a site, and between sites based on your intersite replication
configuration.
The GPT in the SYSVOL is replicated by using one of two
technologies. The File Replication Service (FRS) is used to replicate
SYSVOL. If all domain controllers are running Windows Server 2008 or
later, you can configure SYSVOL replication to use Distributed File System Replication (DFS-R), a much
more efficient and robust mechanism.
Because the GPC and GPT are replicated separately, it is
possible for them to become out of sync for a short time. Typically,
when this happens, the GPC replicates to a domain controller first.
Systems that obtained their ordered list of GPOs from that domain
controller identify the new GPC, attempt to download the GPT, and
notice that the version numbers are not the same. A policy
processing error is recorded in the event logs. If the reverse
happens, and the GPO replicates to a domain controller before the
GPC, clients obtaining their ordered list of GPOs from that domain
controller are not notified of the new GPO until the GPC has
replicated.
On the Microsoft Download Center, you can download the
Group Policy Verification Tool, Gpotool.exe, which is part of Windows Resource Kits.
This tool reports the status of GPOs in the domain and can identify
instances in which, on a domain controller, the GPC and the GPT do
not have the same version. For more information about Gpotool.exe,
type gpotool /? in Command
Prompt.
|
