Group Policy is a group of technologies that allows
administrators within a domain to configure a setting one time and have
it apply to multiple users or computers. Group Policy settings can be
configured using the Local Computer Policy or using the Group Policy Management console (GPMC) in a domain.
As a comparison, Figure 1 shows the Local Computer Policy for a Windows 7 computer, and Figure 2 shows the Default Domain Policy for a domain. There are some important differences.
First, the Local Computer
Policy affects only the local machine. If only the Local Computer Policy
is used, each individual computer must be modified. The Default Domain
Policy affects all users and computers in the domain. Other Group Policy objects (GPOs)
can be created in a domain that will affect all the user accounts and
computer accounts in a site or all the accounts in an Organizational
Unit (OU).
When you create a reference
computer that will be used as an image, the Local Computer Policy is
useful to configure settings that will be the same in all deployed
images.
|
|
Second, domain policy
includes policies and preferences. Any settings in the Policies node are
enforced and cannot be changed by users once the settings are applied.
Settings in the Preferences node are set but aren't enforced. In other
words, users can override the settings in the Preferences node.
Group Policy settings are organized in the following nodes:
- Software Settings
This node can be used to
deploy software to clients. Software deployed with Group Policy can be
automatically installed on computers or installed based on a user's
action. For example, a Group Policy–deployed application can appear on a
user's Start menu and be installed when the user first selects it or
deployed to a computer and installed the next time the computer
restarts.
- Windows Settings
This node
includes Security Settings and Scripts for the computer and also Folder
Redirection and Internet Explorer Maintenance for the user. Scripts can
be configured to run when the computer starts or stops and when a user
logs on or logs off.
- Administrative Templates
This node includes
a large assortment of settings that can be used to modify and manage
the user's environment. These settings directly modify the Registry of
the client computers.
There are literally thousands
of Group Policy settings. One of the first things to grasp is that
you'll never learn them all. What you should concentrate on first is how
Group Policy works. Then, as you work with Group Policy, you'll be
exposed to more and more settings.
The good news is that
most of the settings have built-in documentation. When you find the
setting in the GPMC, you also find the documentation. In addition,
there's a built-in search feature that makes it easier to find Group
Policy settings in the Administrative Templates node.
1. Enabling a GPO Setting
Most GPO settings have one of three options that can be applied: Not Configured, Enabled, and Disabled. Figure 10.3 shows an example of an Administrative template setting that can be used to set the roaming profile for all users.
Not Configured
Not Configured simply
means that the setting hasn't been set. If this setting isn't configured
by any other GPOs, the user will be able to modify the setting on the
local computer.
- Enabled
When a setting is enabled,
it will be applied, and if the setting has additional options, they can
be configured when it is enabled. For example, in Figure 10.3, the roaming profile path is set as \\FS1\Profiles\%username%.
- Disabled
When a setting is
disabled, it prevents any options for this GPO from being applied. As an
example, if a previously applied GPO has enabled the setting, the
Disabled setting will prevent the previously applied GPO from taking
effect.
Exercise 1 walks through the steps of viewing the Local Computer Policy and enabling a setting.
Launch the Group Policy Editor for the Local Computer Policy by clicking Start, typing Group in the Search text box, and clicking Edit Group Policy. Alternatively, you can create an MMC using these steps: Click Start, type MMC in the Start Search box, and press Enter. If User Account Control prompts you to continue, click Yes. Click File => Add/Remove Snap-in. Select Group Policy Object Editor and click Add. The Welcome to the Group Policy Wizard appears, with Local Computer selected as the Group Policy object. Click Finish. Click OK.
Expand
Local Computer Policy. You'll see a Computer Configuration node and a
User Configuration node. Browse to the Computer Configuration => Windows Settings => Security Settings node. This node includes many of the security settings, including Account Policies and Local Policies. Browse to the Computer Configuration => Administrative Templates => System => User Profiles node. This node includes several settings that can be used to configure profiles for users. Browse to the Computer Configuration => Administrative Templates =>
System node. This includes several nodes that can be used to control
different functions of the operating system. Feel free to browse around
to different nodes. As long as you don't enable any settings, nothing
will be modified. Select the User Configuration => Administrative Templates =>
Start Menu And Taskbar node. Double-click Remove Games Link From Start
Menu. Click Enabled. Your display will look similar to the following
graphic. Click OK.
Click
Start. You'll notice that the Games link is no longer on the Start
menu. Note that this doesn't actually remove the games. If Chess Titans
is installed, you can still type in Chess in the Start Search text box
to access the Chess game. Return to the Local Group Policy Editor. Double-click Remove Games Link From Start Menu. Click Not Configured and click OK. Click Start. You'll notice that the Games link has reappeared on the Start menu.
|
2. Applying Multiple GPOs
It's possible for multiple
GPOs in a domain to apply to any individual user account or computer
account. When that occurs, the settings are merged.
If the GPO settings are
different, all the settings are applied. For example, one GPO could be
used to configure all computers to download and install updates
automatically, and another GPO could configure all computers to use
roaming profiles. These two settings are different and do not conflict
with each other, so both settings will apply.
However, if any of the same
GPO settings are used with different parameters, there's a conflict. As
an example, one GPO could configure clients automatically to download
updates and notify clients when they are ready to be installed, and
another GPO could configure clients automatically to download updates
and install them without user intervention. This is a conflict.
When there's a conflict, the last GPO applied wins. This is an important phrase—the last GPO applied wins. It will help you understand many of the scenarios with GPOs.
There are some exceptions
to the "last GPO applied wins" rule. These include using the Enforced
option and Loopback Processing.
|
|
As an example, imagine that Local Computer Policy is configured on a reference computer, as shown in Figure 4.
Updates will automatically be downloaded and the user will be prompted
to install the updates. Windows Deployment Services (WDS) can be used to
capture the image of the reference computer and then deploy the image
to 100 clients in the domain.
Unfortunately, users are
not installing these updates when they're being notified that the
updates are ready to be installed. You could configure the Default
Domain Policy with option 4—Auto Download And Schedule The Install. Now
there's a conflict. The Local Computer Policy says one thing, and the
Default Domain Policy says something else. The Default Domain Policy
wins because it was applied after the Local Computer Policy.
Only Group Policy settings
that are set to Enabled or Disabled are evaluated when Group Policy is
applied. If the setting is set to Not Configured in one GPO but set to
Enabled in another GPO, this is not considered a conflict. The setting
that is set to Enabled is applied.
|
|
2.1. GPO Scope
The GPO scope
refers to where it is applied. A Local Computer Policy applies to only a
single GPO, but other GPOs can apply to many users and computers in the
organization.
GPOs can be created and
linked to sites, domains, and OUs. Where a GPO is linked determines
which users and computers will have the GPO settings applied. Any users
or computers within the scope of a GPO will inherit the settings of the
GPO. If a user or computer is within the scope of multiple GPOs, it will
inherit the settings of all the GPOs.
2.1.1. Domain Scope
GPOs linked to the domain
apply to all accounts in the domain. When a domain is first created, the
Default Domain Policy is also created. It includes some basic settings
that apply to all user and computer accounts in the domain.
Consider Figure 5. It shows the Active Directory Users and Computers console in the Wiley.com
domain. There are multiple OUs (Domain Controllers, Servers, Sales, and
IT) and containers within the OUs. The East and West OUs are children
of the Sales OU, but all of the other OUs and containers are on the same
level and don't have a parent/child relationship with each other.
The Default Domain Policy
applies to any accounts that are in any of the OUs or containers in the
domain. This includes the Users and Computers container and any accounts
in child OUs. Another way of saying this is that GPO settings applied
at the domain level are inherited by all the OUs and containers in the
domain.
A container looks similar to a
folder in Active Directory Users and Computers. The Computers container
is the default location for new computers that join the domain, and the
Users container holds the Administrator user account and some groups.
OUs have an additional icon within the folder, and the only default OU
in a domain is the Domain Controllers OU. All other OUs are created by
an administrator.
|
|
GPOs are not inherited between domains. In other words, if a forest has a root domain of Wiley.com and a child domain named Propubs.Wiley.com, any GPOs applied to the Wiley.com domain are not inherited by the Propubs.Wiley.com domain.
2.1.2. OU Scope
GPOs linked directly to an OU
have a scope of that OU. All of the GPO settings apply to accounts in
that OU. In addition, any child OUs inherit the settings of GPOs applied
to the parent OU.
As an example, consider Figure 6, which shows the Group Policy Management console (GPMC) with the Domain Controllers OU selected. The Default Domain Controllers Policy
is linked to the Domain Controllers OU and listed right below it in the
figure. Both are created when the domain is created. Domain controllers
are automatically added to the Domain Controllers OU, so this GPO
applies to the domain controllers in the domain (as long as they aren't
removed from the Domain Controllers OU).
Two additional GPOs have also
been created. The Disable Mandatory Profile GPO is linked to the IT OU
and applies only to users and computers in the IT OU. The Deploy Sales
App GPO is linked to the Sales OU. The East and West OUs are both
children of the Sales OU, so the Deploy Sales App GPO applies to all
accounts in the Sales OU, the East OU, and the West OU.
You can see the hierarchical
relationships among the domain, OUs, and child OUs in the GPMC. The OUs
and containers are indented to show they are children of the domain.
The East and West OUs are indented to show they are children of the
Sales OU. Child OUs inherit GPO settings from the parent.
The Default Domain
Controllers Policy does not apply to any users in the IT, Sales, or
Servers OUs because these are all peers. Similarly, the Disable
Mandatory Profile GPO applies to accounts in the IT OU but does not
apply to accounts in any other OUs or containers.
2.1.3. Site Scope
A site is a group of
well-connected computers or subnets used for multiple-location
environments. As an example, imagine a company with a main location in
one city and a branch office in another city. Individually, each
location is well connected using 1Gbs local area networks. However, the
locations are connected to each other using a T1 line at about 1.544
Mbs. Although a T1 line is not bad for a WAN link, it has only about 1.5
percent of the bandwidth available within the LAN.
Now the organization wants to deploy Microsoft Office to clients using Group Policy. Figure 7
shows an ineffective method of deploying the application with a single
GPO (GPO1) linked to the domain. This single GPO would apply to all the
accounts in the domain (including all the accounts in both sites).
When a single GPO is
used to deploy the application to both sites, it will have to be
deployed over the WAN link for some of the clients, which will be much
slower than if the application was deployed from a server in the same
site. If Microsoft Office is deployed from a server in the main office,
it will go over the WAN link for clients in the remote office. If it's
deployed from a server in the remote office, it'll have to go over the
WAN link for users in the main office.
Instead, two separate GPOs (GPO2 and GPO3) can be used, as shown in Figure 8.
GPO2 can deploy the application from a server in the main office to
users in the main office. GPO3 can deploy the application from a server
in the remote office to users in the remote office.
While it isn't efficient to use a
single GPO to deploy applications to multiple sites, it is efficient to
deploy settings to multiple sites with a single GPO. For example, if
you want to configure computers to use automatic updates, it isn't
necessary to create separate GPOs if the organization has multiple
sites.
|
|
2.2. GPO Order of Precedence
Since the last GPO applied
wins, it's important to understand the order in which GPOs are applied.
This is also known as the order of precedence, and the order is Local
Computer Policy followed by site, domain, and OU GPOs.
- Local Computer Policy
This is applied first. Within a domain, the Local Computer Policy is always overwritten if there is any conflict.
- Site Group Policy
Site GPOs are applied after the Local Computer Policy. If there any conflicts, settings in the site GPO take precedence.
- Domain Group Policy
Any GPOs that are
applied at the domain level override the Local Computer Policy and any
site GPOs (if they exist). The Default Domain Policy is automatically
created in a domain when the domain is created. It's also possible to
create other domain GPOs at the domain level.
- Organizational Unit Group Policy
GPOs can be created and
applied to OUs. When this is done, an OU GPO overrides any GPOs applied
at the local, site, or domain levels. If child OUs are created and GPOs
are applied to the child OUs, the GPOs applied to the child OUs are
applied after parent OUs and take precedence.
As an example, consider Figure 9,
which shows a domain with multiple OUs and multiple GPOs. Look at these
GPOs to see if you can determine the effective policy for users who
have their accounts in different OUs. The relevant Group Policy settings
are explained in the following bullets.
NOTE
In Figure 10.9,
the IT OU, Servers OU, Sales OU, and Computers and Users containers are
all considered peers; they are on the same level directly under the
domain. The East and West OUs are children of the Sales OU.
Default Domain Policy.
Among other settings, this GPO has set a roaming profile path for all
users that is configured as a mandatory profile by renaming the ntuser.dat file to ntuser.man. This setting is in the Computer Configuration => Policies => Administrative Templates => System => User Profiles node as Set Roaming Profile Path For All Users Logging Onto This Computer.
Server Security GPO.
This GPO has modified the Allow Logon Locally user right to allow only
members of the Administrators or G_ITAdmins group this right. Normally,
users can log on to any server in the domain except for domain
controllers. This setting is in the Computer Configuration => Windows Settings => Security Settings => Local Policies => User Rights Assignment node.
Deploy Sales App GPO. This GPO will be used to deploy a Sales User application to users. This setting is in the User Configuration => Policies => Software Settings => Software Installation node.
West Sales GPO. This GPO has set a roaming profile path for all users.
Consider the following scenarios, and see if you can determine the results based on the GPOs shown in Figure 9.
If a user logs on using an account in the IT OU, what kind of user profiles will be used?
Who can log on to servers placed in the IT OU?
Who can log on to servers placed in the Servers OU?
Who will receive the Sales application?
If a user logs on using an account in the West OU, what kind of user profiles will be used?
Here are the results with a short explanation of how the policy is applied.
Local
user profiles will be used. Both the Default Domain Policy and the IT
GPO are applied. The Default Domain policy configures a mandatory
roaming profile, but the IT GPO disables roaming profiles. This is a
conflict and the last GPO applied wins. Since the IT GPO is applied
after the domain GPO, the IT GPO is the winning GPO.
Any
user in the domain can log on to servers placed in the IT OU. By
default, users can log on to any computer in the domain except for
domain controllers. This is not being modified by Group Policy for this
OU.
Only
members of G_ITAdmins group can log on to these servers. The Server
Security GPO is restricting this right to this group. The G_ITAdmins
group would need to be created if it doesn't exist. Then any users or
groups (such as administrators in the IT department and domain
administrators) would be added to this group.
All
the users in the Sales OU, the East OU, and the West OU will receive
the Sales application. The GPO deploying this application is linked to
the Sales OU. Since the East and West OUs are children of the Sales OU,
they inherit the settings from this GPO.
Roaming
profiles will be used (but not mandatory roaming profiles) by users in
the West OU. The Default Domain Policy sets mandatory profiles, but it
is overridden by the West Sales GPO.