Using Group Policy, you can easily deliver
one-to-many management of users and computers. Group Policy allows you
to enforce your IT policies, implement any necessary security settings,
and implement a standard computing environment. Having a standard
environment provides a consistent base and helps to alleviate
support-desk calls. Group Policy will also help simplify your day-to-day
administrative tasks and leverage your existing Active Directory
environment.
Before you begin working with Group Policy, you need to be aware of some basic terms. Refer to Table 1
to get up to speed with some of the terminology behind this powerful
tool. Then you'll learn about the scope of policy management as well how
client systems process group policies.
Table 1. Group Policy Terminology
Term | Description |
---|
Group Policy Management Console (GPMC) | This
is the main tool where you create your Group Policy objects. GPMC
creates the links defining what objects the GPO will target and the
three main scopes managed in GPMC: sites, domains, and OUs. |
Group Policy object (GPO) | GPOs
are the objects that contain all the settings you want to apply to your
users or computers. GPOs are also what you link to your organizational
units (OUs), sites, or domains. |
Group Policy Object link | The
GPO link is what links the GPO to the portion of your Active Directory
environment where you want the GPO to be applied. This is referred to as
the scope, and there are three main levels you apply GPOs to: site, domain, and OU. |
Group Policy Management Editor | This
is the tool you use to modify the settings in the GPOs. The available
settings are based on the administrative templates currently loaded. |
Administrative template files (ADMX files) | These
files have two purposes. One is to define the settings and
configuration location (on the local system) for those settings. The
second is to create the interface you use to modify the setting in the
Group Policy Management Editor. |
Group Policy preferences | Preferences
provide an alternative to working with company-wide images to manage
settings previously not easily configured in Group Policy. The settings
initially set by the administrator reflect a default state of the
operating system, and these settings are not necessarily enforced. |
Resultant Set of Policy (RSOP) | RSOP
is the set of policy settings applied after all the Group Policy
processing is complete. This could be a combination of many levels of
group policies. |
1. Know the Difference Between Policy and Preferences
As you begin to work with Group
Policy settings, you will notice that there are two ways to configure
systems: policies and preferences. Both policies and preferences can
modify user and computer objects; however, the reasons to use them are
very different. The main difference is enforcement; policies are
enforced, while preferences are not strictly enforced. In this section,
you will see the difference between the two.
1.1. Policies
When you are working with
policies, the settings and interface are based on administrative
templates. Policies make changes to the registry as directed by the
administrative template. There are special sections in the registry
hives that are controlled by Group Policy. The Group Policy settings
stored in these locations are known as true policies.
Specifically, Group Policy works with these two locations for computer settings:
For the user settings, Group Policy works with the following two locations:
Every time a system
processes a policy and gets the RSOP, these registry hives (all the keys
and values) are erased and rewritten with the new RSOP. This occurs
only as long as a valid group policy is still being applied to the
computer or user.
Lastly, you can also make
your own policy settings by modifying one of the administrator templates
or creating your own. This allows you to work with the entire registry
(except for the keys mentioned earlier). However, it is important to
note these settings will "tattoo" the registry. In other words, the
settings are permanently set until you specifically reverse them in
Group Policy. This means if you just delete your GPO, these types of
settings do not go away; you must reverse them by hand.
1.2. Preferences
Introduced in
Windows Server 2008, preferences provide an alternative to using scripts
to perform common tasks. These tasks were traditionally not done easily
if at all in Group Policy. Preferences allow you to modify local
registry settings, local users and groups, files and folders, printers,
local services, mapped drives, and many other local settings. Since
preferences are not enforced on local systems, users have the ability to
make changes. Additionally, preferences are useful for
non-Group-Policy-aware applications and system settings. However, even
if a user decides to make changes, they most likely will not have the
permission to make the change because a majority of the preferences
require some kind of administrative credentials.
In Windows Server 2008 R2,
the targeting of preferences has been dramatically improved. You now can
leverage the Targeting Editor, as shown in Figure 1.
The Targeting Editor is a
straightforward rules-based tool that allows you to create how you want
to target the preference. You can target based on computer name,
operating system (including version, service pack, 64-bit), RAM, CPU,
and so on. This makes item-level targeting very flexible. To access the
targeting editor, choose the Common tab while modifying your preference
setting and select Item-Level Targeting, as shown in Figure 2.
2. Understand the Scope of Group Policy Management
As you begin working with
Group Policy, you'll start to see how an effective AD design provides
the basis for managing Group Policy. You can apply group policies to the
site, domain, and organizational unit levels. Table 2 describes the impact and recommendations for using the different levels to apply group policies.
Table 2. Scopes of Group Policy Management
Scope | Objects Impacted | Recommendation |
---|
Site | All the domains and the objects in the AD site are impacted; this is the largest scope of impact. | It
is not recommended you use the site scope for a typical Group Policy
setup. However, sites are useful when you are setting network security
settings, such as a proxy server or IPsec policies. You also need to be
an Enterprise Administrator to link GPOs at this level. |
Domain | All the objects in the chosen domain are impacted. | This
is also not a recommended scope for applying group policies. The domain
scope is used for your password policies (length, complexity,
expiration, and so on) and other security settings where you want to
apply them consistently. |
Organizational unit | All the objects in the chosen OU as well as any nested OUs and their objects are impacted. | This
is the recommended scope for applying group policies. OUs provide the
easiest-to-manage location for all of your Group Policy needs. |
As mentioned in Table 2,
organizational units are the recommended way you should apply Group
Policy. One of the benefits of having a good OU design is that it can
assist you in applying group policies by allowing you to target the
unique needs for the users and computers in each OU.
3. Understand and Control the Order of Precedence
When you create group
policies, you are not limited to just one GPO or one scope of
management. By default, the RSOP is the culmination of all the scopes
and all of the GPOs, and policies are cumulative. In other words, the
RSOP could be the combination of multiple GPOs from multiple scopes. You
could have an RSOP containing settings from the site, domain, and OU
scopes. Typically, there is very little conflict when working with
policies, and all the settings will apply as you go through the levels.
However, it is important
you understand the default order of precedence. This becomes important
when you have two or more group policies that have conflicting settings.
The following is the general rule of thumb when working with multiple
GPOs:
The GPO closest to the object (user or computer) wins.
The following is the default order of precedence:
Local policies
Local
policies live on the local system and are applied first, including
multiple local policies on Windows Vista systems or later.
Child OU
If you have nested OUs, these are called child OUs, and they can have separate settings as well.
For example, if you have a setting to remove the run command at the domain scope and a setting to enable the run command at the object's OU, the setting at the OU level will "win," and the run command will be enabled.
With Group Policy you also
have the ability to link multiple GPOs per site, domain, or OU. When
this happens, you need to understand link order. In Figure 3,
you can see an OU with two GPOs linked to the OU. Link order determines
the order in which policies are applied. The link with the highest
order (with 1 being the highest order) is applied last and therefore has
the highest precedence for a given site, domain, or organizational
unit. So, in Figure 6.3, the run
command would be disabled since it has a link order of 1 and is
processed last. By changing the link order, you determine the order of
processing. You can move a link up or down in the list to the
appropriate location.
There are two other ways you can control how Group Policy is processed: block inheritance and enforce (known as no override in previous operating systems).
Block inheritance
prevents GPOs from higher scopes from being inherited and thus from
being applied by the child scopes further down the chain. The only
exception is if the GPO has been marked as enforced. Block inheritance
is selected at either the domain level or the OU level. For example, if
you did not want domain-wide policies applying to the children OUs, you
could block inheritance at the OU level, and the domain policies would
not be inherited.
Enforce
is applied to the Group Policy link and marks the GPO to be processed
last regardless of where the policy falls in the scope of management. In
other words, an enforced policy will always win unless another enforced
policy is further down the scope of management. This also means that
when you use an enforced policy, it will also override the block
inheritance setting.