3 Designing A Group Policy Infrastructure

16/11/2014
3 Designing a Group Policy Infrastructure

Section Topics
Overview of Active Directory
Introducing the Design Stages for Implementing Group Policy
Planning Your Group Policy Design
Designing Your Group Policy Solution
Deploying Your Group Policy Solution
Managing Your Group Policy Solution
Section Objectives
After completing this section, you will be able to:

Describe the basic structure of Active Directory
Describe the four stages of implementing Group Policy
Explain how to plan your Group Policy in accordance with company requirements
Describe the guidelines that you should follow when you create new GPOs
Explain how to deploy Group Policy based on the Active Directory structure
Explain how to manage Group Policy by delegating administration and setting permissions
Section Overview
https://skillpipe.courseware-marketplace.com/reader/en-GB/Book/BookPrintView/b6175ac1-149e-4f52-83bd-6350c9133320?ChapterNumber=4&FontSize=
1/49
16/11/2014
This section describes the Active Directory environment and explains how Group Policy uses
Active Directory as its foundation. This section describes the steps you should follow to
deploy Group Policy, linking your design to how your company can best use the features.
This section also defines the essential network components and the security design.
Administrators must have a firm design developed before deploying Group Policy to a live
environment.
Overview of Active Directory
Figure 42: Overview of Active Directory

Active Directory is a distributed database that stores information about objects such as user
accounts. It can also provide information about network resources and application data for
directory-enabled applications and services. You can organize Active Directory into a
hierarchical structure that reflects the layout of your organization and possibly matches the
DNS architecture.
Active Directory promotes the use of a single sign-on to the environment for ease of use and a
more top-down administrative model. Within an Active Directory forest, a user can be
permitted access to resources that exist on any computer in any domain.
Active Directory is very flexible and extensible. Many potential uses for the Active Directory
platform exist. The most important goals for Active Directory are:
2/49
16/11/2014
Storing object information: Active Directory stores information for dozens of different
object types. The most important of these object types are users, groups, and computers.
Authenticating users: Before gaining access to any part of the Active Directory
infrastructure, users must prove who they are. This authentication is the responsibility of
the domain controller. Before anyone is allowed in, the domain controller must check user
credentials against the Active Directory database. If the information provided is correct, the
user receives a TGT as the pass to get STs before accessing any resources.
Implementing security and group policies: Security and group policies are stored in
Active Directory to reflect the policies of the organization for items such as password
strength, account lockout settings, restricted software, auditing guidelines, event log settings,
and much more. These policies are carried down to any computer within the scope of the
Security Policy.
Active Directory Objects
Figure 43: Active Directory Objects

The heart of Active Directory is a database that stores meaningful object information. Many
different object types are created within Active Directory. Administrators create and interact
with only a handful of the following possible objects.
Users: User accounts are the most prominent objects within Active Directory. They
establish the list of known individuals who are allowed to log on to the system.
3/49
16/11/2014
Groups: Groups are very important in the reduction of administrative overhead.

Collecting users into groups allows the administrator to assign privileges to the group instead
to each individual.
Computers: Computer objects are created either ahead of time or when a computer joins
the domain. Once a computer object is created, it is allowed to participate in the security
context of the domain.
Contacts: Contacts are used to establish e-mail aliases for individuals who are outside the
organization. Contacts do not have a user name and cannot log on to the domain
environment.
Printers: Printers exist within the directory as a convenient method to share a printer within
the network.
Shared folders: Shared folders are also created for convenience. A shared folder in Active
Directory points to a physical share on a server or workstation. Creating a share in Active
Directory does not create the share on the target computer. The destination share must
already exist.
Active Directory Architecture
Figure 44: Active Directory Architecture
4/49
16/11/2014
Active Directory is made up of a collection of components that work at different levels of a

hierarchy. You should understand the designations of these levels even when you implement
smaller Active Directory structures.
Site: Sites are established to provide an indication of the physical architecture of the
environment. Usually a site is established for each physical location; then a Global Catalog
is placed on a domain controller within each of the sites. Sites provide a foundation for
replication and for local logons.
Global Catalog: The Global Catalog for an Active Directory forest summarizes all the
objects that are stored on each domain in the forest. Each domain contains its own
database, which is separate from the databases of other domains. The Global Catalog binds
these multiple domain directories into one larger searchable directory.
Forest: A forest could be a single domain. However, the word forest generally depicts
something larger. A forest could be made up of two or more trees with different
namespaces (for example, hq.local and widget.com). Trees and domains in the forest are
bound together by links known as trusts.
Tree: A tree is a collection of one or more domains in the same namespace (for example,
hq.local). Domains in the tree are linked together by trust relationships.
Domain: The domain is the basic building block and security boundary for the Active
Directory environment. The domain also establishes a storage area for Active Directory
objects within the domain controllers in that domain.
Domain controller: A domain controller is a computer that runs the Active Directory
service and is able to answer logon requests and queries about objects. The domain
controller replicates any changes to the Active Directory database for redundancy.
OU: OUs (Organizational Units) are containers in which other objects, such as users and
groups, are stored. OUs are very important organizational techniques for dealing with large
numbers of objects. It is difficult to manage thousands of user accounts all in one flat list.
Instead, you can gather objects into meaningful subdivisions called OUs that you can
manage more efficiently.
Naming Standards
5/49
16/11/2014
Figure 45: Naming Standards

Active Directory uses a combination of different naming technologies to provide access to the
directory database.
DNS: DNS (Domain Name System) is one of the most important pieces of the Active
Directory puzzle. DNS provides the host name to TCP/IP address resolution that is
necessary to communicate with all of the Active Directory services. It also provides the
naming structure for Active Directory itself.
LDAP: LDAP (Lightweight Directory Access Protocol) is used to query and access the
directory database. LDAP is an open standard used by other vendors for their own
directory services and follows a common access scheme. Other network devices and
services can use LDAP to leverage Active Directory for their own purposes.
X.500: The X.500 standard is a naming structure that defines the hierarchical structure of a
directory database. Active Directory loosely conforms to the X.500 specifications, making it
easier to convert objects from other directory services to Active Directory, and vice versa.
Active Directory naming architecture: When Active Directory was first designed,
Microsoft did not adopt the entire X.500 naming scheme for the Active Directory database.
Instead, the developers took part of the X.500 architecture (the cn= and ou=) and
appended the naming scheme that you use every day on the Internet today, DNS.
The DNS domain name information (for example, gk.com) is turned into a series of dc=
qualifiers.
6/49
16/11/2014
The following is an example of an Active Directory distinguished name: cn=JaneD,

ou=Sales, dc=atl, dc=hq, dc=local
Users and Groups
Figure 46: Users and Groups

User and group management comprises a large part of an administrators job. When a
company hires new employees, as employees leave the company, or when users forget their
passwords, the administrator must step in.
To manage users and groups effectively, the administrator must understand the interaction
between users, groups, organizational units, and permissions.
Local User Accounts
In an enterprise environment, local user accounts should be used sparingly. Although local
users and groups are a necessity when a computer is part of a workgroup, after a computer
becomes part of a domain, the local user accounts are not as important.
Creating local user accounts for services is another possible scenario. Even in a domain
environment, local service accounts are more resilient when the domain is unavailable for
logon and critical services need to start.
7/49
16/11/2014
To create local user and group accounts, use either Control Panel, the User Accounts tool, or
the Computer Management Console.
Domain User Accounts
Domain user accounts have many advantages over their local counterparts. Once you
authenticate a user in the domain as a particular individual, he or she can access any resources
that he or she has been given permissions to. Known as an SSO or single sign-on, this
eliminates the cumbersome process of juggling multiple accounts and passwords on different
systems. If the resources are in the same domain, you can grant access to the one user
account.
User account objects are usually created within the Active Directory Users and Computers
tool.
However, you can use other tools to create accounts in bulk, such as:
Csvde.exe
Ldifde.exe
VBScript
Any ADSI compatible tool
Group Types and Scopes

Groups are collections of user accounts that you can leverage to provide access to the
operating system resources. Groups differ by type and scope.
Group Types
Groups in Active Directory come in two different group types:
Security: A security group is used to provide access to resources throughout the domain.
8/49
16/11/2014
Any user within a security group obtains all the rights and permissions of the group itself. A
user who is a member of more than one group will receive all those rights combined.
Distribution: A distribution group is used strictly for e-mail distribution. When an e-mail
message is directed to the address of the group, all users who are part of the group will
receive the message. For this mechanism to function properly, an e-mail service such as
Microsoft Exchange must be running to enumerate the inboxes of the users who are in the
group.
Group Scopes
Groups in Active Directory come in three different group scopes:

Domain local: A domain local group is local to the domain where it has been created.
These groups are limited to accessing resources only within that domain; they are not
permitted to access resources in other domains. However, domain local groups can contain
users and global groups from other domains in order to facilitate access to resources.
Global: Global groups can access resources in any domain that they have permissions to.
However, unlike local groups, global groups can contain users only from within the same
domain that they are created in.
Universal: Universal groups take on the features of both the global groups and the domain
local groups. They can contain users from anywhere in the forest, and they can access
resources anywhere in the forest. The caveat is that the universal group is stored within the
Global Catalog. For this reason, it is undesirable to place frequently changing objects (such
as users) inside the universal group. It is much better suited as a replacement for domain
local groups when resource access must cross domains. In this scenario, global groups are
nested within the universal groups.
Organizational Units
9/49
16/11/2014
Figure 47: Organizational Units

An OU is a structure borrowed from the X.500 specification that allows for the
compartmentalization of objects within the directory structure. OUs can be arranged as a
hierarchy of containers that can represent the structure of the organization itself.
OUs and Groups
Figure 48: OUs and Groups

OUs are not groups. Differences include:
https://skillpipe.courseware-marketplace.com/reader/en-GB/Book/BookPrintView/b6175ac1-149e-4f52-83bd-6350c9133320?ChapterNumber=4&FontSize
10/49
16/11/2014
Users are members of groups for access control purposes, whereas users are contained
within OUs for storage and for applying Group Policy.
A user can be a member of as many groups as the administrator sees fit, but an account
object can be stored in only one OU at a time.
These differences can get confusing at times, especially when some of the OUs and groups
have similar names. To avoid confusion, some organizations prefix OUs with the letters
OU-. This practice is not very commonplace and you can avoid it by naming groups
descriptively and naming OUs more briefly.
Creating an OU Structure
Figure 49: Creating an OU Structure

An OU structure can be designed around several different types of schemes. The choice of
scheme depends upon the size and distribution of the organization. In many cases, you can
use a combination of techniques.
Geographic
The geographic design is useful when a company is spread widely throughout a region, or
perhaps globally. The design should not stop at that level though. Within the regional OUs,
11/49
16/11/2014
you can create sub-OUs to further divide organizational resources based upon other
categories.
Departmental
The most popular OU design is a departmental one. This design fits neatly into the company
profile and you can base it upon existing organizational charts that depict the breakdown of the
corporate structure. A tool that is commonly used to design these organizational charts is the
Microsoft drawing tool Visio. Since the introduction of Active Directory, Microsoft Visio has
been able to export the graphical organizational charts into a format compatible with Active
Directory. For a new Active Directory deployment, this feature can reduce the effort needed
to establish the initial OU structure.
Functional
The functional design does not usually stand on its own. Most organizations subdivide either
their geographic or departmental model into sub-OUs representing a more granular structure of
departments and job roles.
Introducing the Design Stages for Implementing Group

Policy
Figure 50: Introducing the Design Stages for Implementation Group Policy
12/49
16/11/2014
You might get many practical tips for deploying and managing Group Policy in a classroom
environment, but the real test is when you deploy a Group Policy in your own Active
Directory enterprise.
Although deploying Group Policy presents many challenges, its benefits become apparent soon
after deployment.
The four major stages required for successfully implementing a Group Policy solution are:
Planning
Designing
Deploying
Managing
Planning Your Group Policy Design
Figure 51: Planning Your Group Policy Design

Planning the design of the Group Policy architecture is important due to the complexity that
may exist in many large organizations. This is not a problem exclusive to the Group Policies
themselves. You may need to address issues related to the OU structure, the existing
management practices, and who is ultimately going to be in charge of administering the various
policy components.
13/49
16/11/2014
Policy Survey
Figure 52: Policy Survey

The planning stage involves consulting with your help desk, end users, management, and
support staff to answer questions like the ones listed in Figure 52.
You need enough information to decide exactly which components of Group Policy to deploy
in your organization.
Your Group Policy design is ultimately bound by the design and implementation of your
Active Directory infrastructure. Because you can link GPOs to sites, domains, and OUs, your
Active Directory design might make it easier to use sites rather than domain settings, or
domains instead of sites or OUs.
Policy Objectives
14/49
16/11/2014
Figure 53: Policy Objectives

During the planning process, you will start to gather information about your company and how
it carries out its day-to-day business with an Active Directory network. Analyzing the way
your workers do their job will help you design a plan that will be acceptable and workable.
Throughout the design stage, the initial scope of Group Policy may be broadened or reduced
based on the settings that are deployed on all users versus the settings that are applied for
select groups of users.
If your company has several divisions, you need information about how the network
infrastructure is managed. If the administration is centrally controlled and administered, then
having divisions within your company does not provide the structure you need for network
administration or Group Policy.
Your Group Policy design will be based on your physical and logical Active Directory
deployment. At a minimum, subnets (sites) and domains will be used; organizational units will
be used as well. Remember the basic rule of a new plan: keep it simple.
Your Group Policy will be deemed successful if it can seamlessly fit into your existing Active
Directory environment.
Policy Components
15/49
16/11/2014
Figure 54: Policy Components

A well-thought-out Group Policy design manages the following:
Computer security: Can departments agree on security?
Software deployment: Are MSI packages useful to deploy?
Logon scripts: Are they user or enterprise?
Folder redirection: Will you replace roaming user profiles?
Administrative Template settings: What settings can be implemented to improve the user
experience and reduce support calls?
Preferences settings: Can cumbersome logon scripts be eliminated by implementing
Preferences?
A successful Group Policy design takes into account the many levels of policies that are
implemented within your company. It balances acceptable network security levels against the
IT department requirements, the businesses requirements, and potentially, government
requirements.
Planning for Security
The first step in designing a functional Security Policy is to understand what your company
will accept and what it will reject. Enabling a password policy that contains complex
passwords might, on paper, be a smart security choice, as long as your users do not write the
password down on a scrap of paper and pin it to their cubicle bulletin board.
16/49
16/11/2014
Analyzing the needs of your company and what management and IT will accept is important
in deploying a sound Security Policy.
A policy that enforces a 15-character password that will be changed once every 6 months may
be more palatable to all users from the top of the management tree to the bottom than a 7
character password with complexity that is changed every month and is constantly being
written down.
Designing Your Group Policy Solution
Figure 55: Designing Your Group Policy Solution

Designing your Group Policy solution involves configuring the physical components of the
environment, laying out the Group Policy model, delegating management authority, creating
new GPOs, and designing the interaction of GPOs with Active Directory sites.
Group Policy Solution Components
17/49
16/11/2014
Figure 56: Group Policy Solution Components

Many components are involved in designing a group policy solution for a large environment. If
you properly structure all of these components, you will help achieve a successful group policy
rollout.
Figure 56 lists the subjects that are described in this topic.
Networking
Active Directory must be operational in order to deploy Group Policy settings at the site,
domain, or OU. ICMP must be available to process Group Policy. The client or member
servers use ICMP for communication with domain controllers on your network.
DNS Services
Group Policy uses FQDNs, not NetBIOS names. Therefore, you must have DNS running in
your forest in order to correctly process Group Policy.
Time Synchronization
The time synchronization for authentication between workstations and servers must be within
5 minutes. The updating of Group Policy relies on communication between domain controllers
using DNS services and the FRS.
Administration
By default, only domain administrators or enterprise administrators can create and link GPOs.
However, you can delegate this task to other users. Local administrators can create Group
Policy but do not need full control of the GPO infrastructure.
Client Interoperability
18/49
16/11/2014
Group Policy applies only to computers running the following operating systems:
Windows 2000
Windows XP Professional
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2
Windows 8 Client
Windows Server 2012
(You cannot deploy Group Policy on computers that are running Windows 95, Windows 98,
or Windows NT 4.0.)
If the client and servers in your company primarily run Windows 2000 Professional and you
have Windows Server 2003 servers, use the Windows Server 2003 Administrative
Templates; they are the latest .adm files and include settings for Windows 2000, Windows
XP, and Windows 2003 computer systems. Similarly, the newest .admx templates included
with Windows Server 2008 and later provide all of the newest settings, plus backward
compatibility for older versions of Windows.
Each GPO setting details which version of Windows it supports. If you attempt to apply a
GPO containing newer settings to an older version of Windows that does not support the
applied setting, it will be ignored.
To determine which settings apply to which operating systems, look at the Supported on
information in the description for the setting. This information explains which operating
systems can read the setting.
19/49
16/11/2014
If the destination computer is running Windows 2000 or later, and the computer account and
the account for the logged-on user are both located in an Active Directory domain, both the
computer and the user portions of a GPO are processed.
If either the logged-on user account or the computer account is located in a Windows NT 4.0
domain, System Policy is processed for the accounts that are located in the domain.
Computers running Windows NT 4.0, Windows 95, or Windows 98 use System Policy rather
than Group Policy. System policies can still be deployed from an Active Directory domain to
these older clients.
Designing Your Group Policy Model
Figure 57: Designing Your Group Policy Model

The following discussion questions can help you tailor your Group Policy guidelines and
design to the needs of your organization:
Where will your GPOs be linked?
What security filtering will you use on each GPO?
How many GPOs will you have?
What is the scope of where Group Policy is applied?
Are all Group Policy settings applicable to all users?
Are some Group Policy settings not applicable to all users?
20/49
16/11/2014
Are users and computers controlled based on their roles and locations?
Are desktop configurations based on user and computer requirements?
What are your user requirements for various types of users: desktop, notebooks, mobile,
terminal services?
Delegating GPO Responsibilities
Figure 58: Delegating GPO Responsibilities

If possible, designate only one administrator (or one group of administrators) per GPO for all
editing and linking tasks. You can delegate permission to edit and link GPOs to different
groups of administrators. However, without adequate GPO control procedures in place,
delegated administrators with overlapping responsibilities can duplicate GPO settings or create
GPOs that conflict with settings set by another administrator or that are not in accordance with
corporate standards.
Creating New GPOs
21/49
16/11/2014
Figure 59: Creating New GPOs

Be very cautious the first time you create and deploy GPOs. A small number of settings that
work well, for example Adding Logoff to the Start Menu, or forcing the Classic Windows
Desktop, will be greatly appreciated. However, implementing a very rigid policy from the
beginning will cause end-users to become frustrated. Ultimately, they may try to circumvent
the policy.
Use the settings in your GPOs that you are already familiar with and use a domain GPO to
deploy a company-wide GPO with minimal settings that are acceptable to everyone. Avoid
configuring very restrictive settings at the Domain root level as those settings will potentially
impact everyone.
Create more granular GPOs on a per-OU basis to affect smaller number of users and
computers with their specific needs.
Naming GPOs
Define a meaningful naming convention for GPOs that clearly identifies the purpose of each
GPO.
This easy tip is usually overlooked. The name should include the settings applied, and the date
of creation and change.
22/49
16/11/2014
GPO Functionality
The functional characteristics of GPOs are:
GPOs are inherited: If a GPO is linked at the domain level and at the OU level, both the
user and computer accounts in the domain and OU could be affected by both OUs.
GPOs are monolithic: Each GPO is created from the same master template and,
therefore, contains the same choices regardless of its location in the site, domain, or OU.
GPOs and performance are linked: If a computer system or user account has to process
many GPO settings, performance can suffer.
Sites and GPOs
Figure 60: Sites and GPOs

Sites are important in the structure of Active Directory and in the functionality of locationbased GPO processing.
Domain Controller Location
The location of your domain controllers becomes a consideration if your clients are located on
remote subnets with no domain controller and must authenticate across a slow WAN link.
GPOs are stored in both Active Directory and in the Sysvol folder on each domain controller.
These locations have different replication mechanisms.
23/49
16/11/2014
Replication
Replication in Active Directory is controlled by the built-in replication system of Active
Directory. Within the same site, replication between domain controllers that are running at the
functional domain level of Windows 2003 Server within the same site occurs every 15
seconds.
In environments such as a partially upgraded forest that contains domain controllers running
Windows 2000 and Windows Server 2003, a typical replication might take up to 15 minutes.
The FRS controls the replication of the Sysvol folder. Within sites, replication occurs every 15
minutes. If the domain controllers are in different sites, the replication process occurs at set
intervals based on site topology and schedule; the lowest interval is 15 minutes across a WAN
link unless Notification has been enabled.
If it is critical to immediately apply a change to a specific group of users or computers in a
specific site, use Active Directory Users and Computers to connect to the domain controller
closest to these objects, and then make the configuration change on that domain controller.
This technique will allow those users to get the updated policy first.
All changes made to GPOs are replicated from the domain controller that is assigned the
FSMO role of PDC emulator to the other domain controllers hosting the domain. The FRS
links together and updates the Sysvol folders within each domain.
Slow Links
Active Directory defines a link as slow when it falls below the default threshold of 500 kBps.
Group Policy settings that are applied under these conditions are the Administrative
Templates settings along with the security settings.
All other Group Policy settings, including software distribution and folder redirection, are not
applied across slow links. However, this default threshold for both the computer and user can
be changed by modifying the Slow Link Detection policy.
24/49
16/11/2014
Group Policy uses the following process to measure link speed:

1.
The server is pinged with 0 bytes of data and times the number of milliseconds; if the
result is less than 10 ms, the operating system assumes a fast link.
2.
The server is pinged with 2 kB of uncompressible data and times the number of
milliseconds. This value is called time2. DELTA = time2 time1 The result is equal to
the time to move 2 kB of data.
Note
In Windows Vista, Windows Server 2008 and later, Group Policy uses NLA in
the operating system to detect a slow network. This circumvents the issues surrounding the
unreliable usage of ICMP to determine speed.
Deploying Your Group Policy Solution
Figure 61: Deploying Your Group Policy Solution

Deploying your Group Policy solution involves making the policy available to the users and
computers that you want to affect with the settings. You can link the policies to the domain,
site, or at the various levels of a nested OU structure. After deployment, the policy changes
will automatically be discovered at regular intervals.
25/49
16/11/2014
Applying Group Policy Changes
Figure 62: Applying Group Policy Changes

Policy refresh occurs at computer startup and user logon. In addition, clients and servers
check for changes to GPOs every 90 minutes by using a randomized offset of up to 30
minutes.
Any changes to Group Policy settings are not immediately available on the desktops of users
because changes to each GPO must first replicate to the appropriate domain controller where
authentication is occurring.
Security Policy settings delivered by Group Policy are reapplied every 16 hours (960 minutes)
even if security settings have not changed.
It is possible to change this default period (in minutes) by modifying the registry entry
MaxNoGPOListChangesInterval in the following subkey:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtentions
Domain controllers check for computer policy changes every 5 minutes.
To change the default polling frequency, go to Computer Configuration\Administrative
Templates\System\Group Policy for computers and User Configuration\Administrative
Templates\System\Group Policy for users. Modify the following settings:
26/49
16/11/2014
Group Policy Refresh Interval for Computers

Group Policy Refresh Interval for Domain Controllers
Group Policy Refresh Interval for Users
For Windows 2000 Server, Windows XP, and Windows Server 2003, software packages
require:
A logoff and logon to take effect when applied to the user
A reboot when applied to the computer
Windows Vista, Windows Server 2008 and later can apply software packages without the
need to first log off or restart the computer.
Linking GPOs to the Domain
Figure 63: Linking GPOs to the Domain

As the name suggests, the Default Domain Policy GPO is also linked to the domain.
The Default Domain Policy GPO is created when the first domain controller in the domain is
installed and the administrator logs on for the first time.
This GPO contains the domain-wide account policy settings, Password Policy, Account
Lockout Policy, and Kerberos Policy, which are enforced by the domain controller computers
27/49
16/11/2014
in the domain.
In order to apply account policies to domain accounts, these policy settings must be deployed
in a GPO that is linked to the domain. It is recommended that you set these settings in the
Default Domain Policy GPO.
Keep in mind the Group Policy inheritance model and how precedence is determined. By
default, options set in GPOs that are linked to higher levels of Active Directory containers
(sites, domains, and OUs) are inherited by all containers at lower levels.
If you want to apply a number of policy settings to computers in a particular physical location
only (for example, network or proxy configuration settings), you can apply these settings at the
site level. However, if the settings do not distinctly match to computers in a single site, it is
better to assign the GPO to the domain or OU structure instead.
Designing an OU Structure that Supports Group Policy
Figure 64: Designing an OU Structure that Supports Group Policy

You can more efficiently manage an OU structure if it is in a single domain environment. In a
single domain, you can move users in and out of OUs without using complex migration tools.
You can also move entire OU structures, with all of their contents, within the single domain.
You can delegate the administration of the OUs to specific groups of users to provide a more
granular administrative architecture.
OU Organization
Make sure that you base your OU design on a solid management strategy for GPO creation
28/49
16/11/2014
and delegation of administrative duties. The goal of your OU design is to simplify Group
Policy application and troubleshooting.
Separate OU Design
One distinct design is to place all the computer accounts in one OU and all the user accounts
in another. Using a structure in which OUs contain either user or computer objects but not
both, you could disable the computer section or user section of a GPO to speed up the
processing of each GPO. However, separating the user and computer components into
separate GPOs will require more GPOs. You can compensate for this by adjusting the GPO
status to disable the user or computer sections of each GPO that do not apply and to reduce
the time required to apply a given GPO.
Central Control
If central control is desired, consider geographically-based OUs as child OUs and duplicate the
structure for each location for a clean familiar structure.
Remember, all child OUs by default inherit GPOs that are linked to the higher layers of your
OU structure.
You can apply Group Policy settings at the domain level, so consider settings at the domain
level for company-wide settings, such as password policies.
Applying Group Policy to New User and Computer

Accounts
29/49
16/11/2014
Figure 65: Applying Group Policy to New User and Computer Accounts
After deployment, the policy changes will automatically be discovered at regular intervals. By
default all new user and computer accounts are created in the CN=Users and
CN=Computers containers shown in Active Directory Users and Computers.
For Windows 2003 and later Active Directory environments, you can apply group policies to
the default user and computer containers if you redirect them with the following command-line
utilities:
redirusr.exe: For user accounts
redircmp.exe: For computer accounts
These command-line utilities enable you to change the default location where new user and
computer accounts are created so that you can more easily design and link GPOs directly to
newly created user and computer objects.
The Redirusr and Redircmp utilities are located in WINNT\system32 on a Windows 2003 or
later domain controller.
Running the Redirusr and Redircmp utilities, a domain administrator can specify the OUs
into which all new user and computer accounts are placed when they are created.
30/49
16/11/2014
Managing Your Group Policy Solution
Figure 66: Managing Your Group Policy Solution

Once group policies have been designed and deployed, mechanisms must be put in place to
manage them on an ongoing basis. The management of policies does not need to all fall on the
shoulders of a single person. Subordinate administrators can be delegated the authority they
need to manage certain aspects of Group Policy.
Another important aspect of Group Policy management is the ability to specify a default
domain controller for GPO editing. This can help reduce issues that occur when managing
policies in widely disbursed environments.
When there are many administrators in an environment, version control is imperative. GPO
rollback, Starter GPOs, GPO Comments, and the AGPM are all tools that can assist in
tracking and controlling GPO management.
Delegating the Administration of Group Policy
31/49
16/11/2014
Figure 67: Delegating the Administration of Group Policy

Your Group Policy design will probably call for delegating certain Group Policy administrative
tasks.
One of the most important factors to consider when assessing the needs of your organization
is the degree to which you should centralize or distribute administrative control of Group
Policy.
A centralized administration model has an IT group providing services and setting standards
for the entire company. In organizations that use a distributed administration model, each
business unit manages its own IT group.
Based on the administrative model of your organization, you need to determine which
components of configuration management should be handled at the site, domain, and OU
levels.
Administrative responsibilities at each site, domain, and OU level might be further delegated at
each level.
When deciding whether to delegate authority at the site, domain, or OU level, remember the
following points:
Authority delegated at the domain level affects all objects in the domain if the permission is
set to inherit to all child containers.
Authority delegated at the OU level can affect either that OU only, or that OU and its child
OUs.
32/49
16/11/2014
Default Rights for Group Policy Management
Figure 68: Default Rights for Group Policy Management

You can always modify the default permissions shown in Figure 69 that are assigned to one of
the system groups. However, to avoid giving a user more control than is necessary, it is best to
create a new group for Group Policy management.
Windows
Rights Granted
Group
Enterprise Admin
Create, delete, edit, and link GPOs in all forest containers (sites, domains, and OUs).
Domain Admins
Create, delete, edit, and link GPOs in the domain and all OUs hosted by the domain, but not
in sites. See note below for exceptions to this rule.
Group Policy Creator
Create GPOs in the domain to which the group belongs. Users who are members of this
Owners
group can edit any GPOs that they create; however, other members of the group cannot.
Deleting GPOs is not allowed. Linking to a site, domain, or OU is also not allowed.
Local Admins
Create GPOs in the domain to which the group belongs. A user that is a member of this
group can edit and delete all GPOs that any other group member has created. Linking the
GPO to the domain and any OUs hosted by the domain is also allowed.
Figure 69: Groups Assigned GPO Rights

You can manage three Group Policy tasks on a per-container basis in Active Directory:
Linking GPOs to the site, domain, or OU
Analyzing Group Policy Modeling for domains and OUs
Reading Group Policy Results data for domains and OUs
33/49
16/11/2014
If your Active Directory network is a single domain, be aware that by default the local
administrator is made a member of the Domain Admins, Enterprise Admin, Schema Admins
and Group Policy Creators groups.
Group Policy Creator Owners Group
Figure 70: Group Policy Creator Owners Group

Following are the main characteristics of the GPCO (Group Policy Creator Owners) group:
Members of the GPCO group cannot link GPOs to containers unless they have been
separately delegated the right to do so on a particular site, domain, or OU. Membership in
the GPCO group allows each member the ability to create GPOs in a domain.
However, they cannot link any GPO that they have created to any other container.
Being a member of the GPCO group gives the non-administrator full control of only those
GPOs that the user creates. When a non-administrator who is a member of the GPCO
group creates a GPO, that user becomes the creator owner of the GPO and can edit the
GPO and modify permissions on the GPO.
GPCO members do not have permissions for GPOs that they do not create.
34/49
16/11/2014
Other Group Policy Creator Owner Details

Because the GPCO group is a domain global group, it cannot contain members from outside
the domain. Therefore, if you add Jane Smith to the GPCO group, she alone can create and
edit GPOs that she has created.
When the Group Policy MMC creates the GPO for Jane, it does not assign the GPCO to the
ACL on the GPO; it instead assigns it directly to the user that created the GPO, in this case
Jane.
The GPCO is just a placeholder for the members of the group; when a user actually creates a
GPO, the permissions are assigned to that specific user.
GPO Delegation
Figure 71: GPO Delegation

Delegation in Active Directory is performed using the Delegation of Control wizard. You can
use this tool to assign security permissions to specific users and groups to perform specialized
administrative tasks on Active Directory objects. Internally, the ACL is doing all the work as
shown in Figure 71. Unfortunately, there is no un-delegation of control wizard.
You can delegate the following Group Policy tasks:
35/49
16/11/2014
Creating GPOs
Managing individual GPOs (for example, granting edit or read access to a GPO)
Performing the following tasks on sites, domains, and OUs:
Managing Group Policy links for a given site, domain, or OU
Performing Group Policy Modeling analyses for objects in that container (not applicable
for sites)
Reading Group Policy Results data for objects in that container (not applicable for sites)
Creating WMI filters
Managing and editing individual WMI filters
To delegate Group Policy-related permission on a site, domain, or OU, select the appropriate
container. Do the following:
1.
Right-click the site, domain, or OU and select Delegation.
2.
Click the Add button to add new groups or a user.
3.
Select the permission that you want to manage: Link GPOs, Perform Group Policy
Modeling analyses, or Read Group Policy Results data.
Note
Group Policy Modeling and Group Policy Results are not available for sites.
Manually Assigning Permissions
36/49
16/11/2014
Figure 72: Manually Assigning Permissions

To manually assign permissions to a GPO, from the Group Policy MMC, right-click the
GPO object and from the GPO properties, click the Security tab.
Figure 73 shows the rights that must be granted to edit, view, link, and delete a GPO.
Rights
Control
Full control
Create, edit, view, and delete the GPO
Read
View the GPO in the Group Policy Console (Opening the GPO to edit is not allowed.)
Write
View and edit the GPO (Note: The read permissions must also be granted to even be able
to view the GPO.)
Create all child objects
Create and edit GPOs (Deleting is not allowed.)
Delete all child objects
Delete a GPO
Figure 73: Rights for GPO Control

Administrative Rights
When an administrator creates a GPO, the Domain Administrators group becomes the creator
owner of the GPO.
If the domain administrator wants a non-administrator or non-administrative group to create
GPOs, that user or group can be added to the Group Policy Creator Owners security group.
37/49
16/11/2014
After a non-domain administrator creates an unlinked GPO, the domain administrator or

someone else who has been delegated permissions to link GPOs in a container can link the
GPO as appropriate.
By default, domain administrators have GPO linking permission for domains and OUs, and
enterprise administrators and domain administrators of the forest root domain can manage
links to sites.
By default, access to Group Policy Modeling and remote access to Group Policy Results data
is restricted to enterprise administrators and domain administrators.
Specifying a Domain Controller for Editing GPOs
Figure 74: Specifying a Domain Controller for Editing GPOs

Resolving Conflicts
To avoid conflicts that could be caused when multiple administrators are editing policies, the
PDC emulator in each domain is used as the default for editing GPOs. This ensures that all
administrators are using the same domain controller. If multiple administrators manage a
common GPO, all administrators actually use the same domain controller when editing a
particular GPO in order to avoid collisions.
38/49
16/11/2014
However, it might not always be desirable for an administrator to use the PDC to edit GPOs.
If the administrator is located in a remote site, or if the users or computers targeted by the
GPO are in a remote site, the administrator might want to choose to target a domain controller
in the site local to the administrator. You can change the default editing location of GPOs from
the PDC emulator to any other domain controller in the domain, as shown in Figure 74.
For example, if you are an administrator in Canada and the PDC emulator is in Denver, CO,
U.S.A., it might be inconvenient to rely on a WAN link to access the PDC emulator in
Denver. CO, U.S.A.
Use the Change Domain Controller function to specify the domain controller that you will use
for a given domain or for all sites in a forest. You have four options:
The domain controller with the operations master token for the PDC emulator (the default
option)
Any available domain controller
Any available domain controller running Windows Server 2003 or later
This domain controller (Select a specific domain controller that you want to use.)
Rolling Back Domain GPOs
39/49
16/11/2014
Figure 75: Rolling Back Domain GPOs

If for some reason there is a problem with the changes to the GPOs and you cannot revert to
the previous or initial states, you can use the Dcgpofix tool to re-create the default policies in
their initial state.
Dcgpofix is a command-line tool that completely restores the Default Domain Policy GPO and
Default Domain Controller GPO to their original states in the event of a disaster.
Dcgpofix restores only the policy settings that are contained in the default GPOs for the
domain at the time it was first created; the default settings are found in Security, RIS, and
EFS.
Dcgpofix does not restore other GPOs that administrators create; it is intended only for
disaster recovery of the default GPOs. Dcgpofix works only in a Windows Server 2003 or
later domain.
The syntax for Dcgpofix is:
dcgpofix [/target: domain | dc | both]
Figure 76 lists the options for Dcgpofix.
Option
Function
/target
Description of option
domain
Recreates the Default Domain Policy
dc
Recreates the Default Domain Controllers Policy
both
Recreates both the Default Domain Policy and the Default Domain Controllers Policy
Figure 76: Options for Dcgpofix.exe
Starter GPOs
40/49
16/11/2014
Figure 77: Starter GPOs

Starter GPOs allow administrators to build a library of common GPO scenarios. They work
like templates in that they enable you to create new GPOs from a set of predefined values that
you can later modify to suit the needs of the situation.
Starter GPOs are not the same as Administrative Templates, however. The Administrative
Templates establish the structure of what is possible in a GPO without defining any actual
settings. A Starter GPO comes with preconfigured settings that allow an administrator to get
started more quickly.
There are several Starter GPOs included in the operating system. Click on the Starter GPOs
container and it will ask if you want it to create them. Additional Starter GPOs can be
downloaded from Microsoft in the form of Solutions Accelerators.
One deficiency of the Starter GPO is that it can contain only Administrative Templates
settings.
Although these settings constitute the bulk of the settings that would be used to define user
environment characteristics or to lock down the desktop, they do not contain security settings
and other parameters that would be useful in a Starter GPO form. Windows Server 2012
includes several new predefined Starter GPOs that address Windows Firewall with Advanced
Security settings. However, you still cannot modify the security section of a Starter GPO that
41/49
16/11/2014
you create yourself.
Adding Comments to a GPO
Figure 78: Adding Comments to a GPO

In large, complex environments, it is important to keep track of the various GPOs and what
they are used for. The new Group Policy structure allows you to add comments to a GPO for
future reference.
To add a comment, follow these steps:
1.
Edit the policy, right-click the name of the policy in the Group Policy Management
Editor, and then select Properties.
2.
Click the Comment tab and then type a description of the policy.
When you select the policy, the comment should be visible in the GPMC, on the Details tab.
Using the AGPM
42/49
16/11/2014
Figure 79: Using the AGPM

Microsoft AGPM (Advanced Group Policy Management) increases control over managing
group policies. AGPM provides role-based delegation and change management control. These
added Group Policy management features will result in fewer conflicting or improperly
configured GPOs.
AGPM is part of the Microsoft Desktop Optimization Pack for Software Assurance, available
to Software Assurance customers. Those who have MSDN or Microsoft TechNet
subscriptions may download and experiment with the MDOP and AGPM features. AGPM
allows for better management and control of enterprise desktop environments.
To use AGPM, you must install a server component on a domain controller within the
enterprise.
Those managing group policies must install the client component to participate.
Note: The current version of AGPM is 4.0. This version works with Windows Server
2008, Server 2008 R2, Windows Vista and Windows 7. There is no official version of
AGPM available for Windows Server 2012 and Windows 8 Client yet.
Figure 79 lists the benefits of the AGPM.

43/49
16/11/2014
Acronyms
The following acronyms are used in this section:
ACL
access control list
ADSI
Active Directory Services Interfaces
ADUC
Active Directory Users and Computers
AGPM
Advanced Group Policy Management
CN
common name
DC
domain controller
DNS
Domain Name System
EC
Enterprise Client
EFS
Encrypting File System
FQDN
fully qualified domain name
FRS
File Replication service
FSMO
Flexible Single Master Operation
GPCO
Group Policy Creator Owners
GPO
Group Policy object
HKLM
HKEY_LOCAL_MACHINE
ICMP
Internet Control Message Protocol
IT
Information Technology
kB
kilobytes
kBps
kilobits per second
LDAP
Lightweight Directory Access Protocol
MDOP
Microsoft Desktop Optimization Pack
MMC
Microsoft Management Console
ms
millisecond
MSDN
Microsoft Developer Network
MSI
Microsoft Software Installer
NetBIOS Network Basic Input/Output System

NLA
Network Location Awareness
OU
organizational unit
PDC
primary domain controller
RIS
Remote Installation Services
SSLF
Specialized Security Limited Functionality
44/49
16/11/2014
SSO
single sign-on
ST
service ticket
TCP/IP
Transmission Control Protocol/Internet

Protocol
TGT
Ticket Granting Ticket
WAN
wide area network
WMI
Windows Management Instrumentation
Section Review
Summary
The heart of Active Directory is a database with object types such as Users, Groups,
Computers, Contacts, Printers, and Shared folders. Active Directory is made up of a
collection of components (Site, Global Catalog, Forest, Tree, Domain, Domain Controller,
and OU) that work at different levels of a hierarchy.
The four stages of implementing Group Policy are:
Planning: During this stage, you will decide which components of Group Policy to
deploy in your organization; start gathering information about your company and how it
carries out its day-to-day business with an Active Directory network; design a Group
Policy that manages entities such as: Computer security, Software deployment, etc.
Designing: During this stage, you will configure the physical components of the
environment, lay out the Group Policy model, delegate management authority, create
new GPOs, and design the interaction of GPOs with Active Directory sites.
Deploying: During this stage, you will make the policy available to the users and
computers that you want to affect with the settings.
Managing: During this stage, you will put mechanisms in place to manage group policies
on an ongoing basis; delegate authority to subordinate administrators to manage certain
aspects of Group Policy; specify a default domain controller for GPO editing; use tools
such as Starter GPOs and the GPO to track and control Group Policy objects.
45/49
16/11/2014
To plan your Group Policy in accordance with your company requirements, do the
following:
Ask your help desk, end users, management, and support staff the planning stage
questions.
Determine which components of Group Policy to deploy.
Find out about the design and implementation of your Active Directory infrastructure.
Start gathering information about your company; how it carries out its day-to-day
business with an Active Directory network.
If your company has several divisions, find out how the network infrastructure is
managed.
Base your Group Policy design on your physical and logical Active Directory
deployment.
Ensure the plan manages the Group Policy entities such as computer security, folder
redirection, roaming user profiles, etc.
Follow these guidelines when you create new GPOs:
Use the settings in your GPOs that you are already familiar with and use a domain GPO
to deploy a company-wide GPO with minimal settings that are acceptable to everyone.
Create more granular GPOs on a per-OU basis to affect smaller numbers of users and
computers with their specific needs.
Define a meaningful naming convention for GPOs that clearly identifies the purpose of
each GPO; the name should include the settings applied and the date of creation and
change.
You can link policies to the domain, site, or at the various levels of a nested OU structure.
Decide the degree to which you should centralize or distribute administrative control of
Group Policy. In a centralized administration model, the IT group provides services and
setting standards for the entire company. In a distributed administration model, each
business unit manages its own IT group. Based on the administrative model, determine
46/49
16/11/2014
which configuration management components should be handled at the site, domain, and
OU levels.
You can manually assign permissions to a GPO from the Group Policy MMC.
Knowledge Check
1.
What types of objects can you store in Active Directory?
2.
Briefly describe the Planning and Design stages of implementing Group Policy.
3.
What should you do when you plan your Group Policy in accordance with your
company requirements? (Choose all that apply.)
a.
Ask the planning stage questions.
b.
Find out about the design and implementation of your Active Directory
infrastructure.
c.
Base your Group Policy design on your physical and logical domain controller
deployment.
d.
Determine how your company carries out its day-to-day business with an Active
Directory network.
4.
What should you include when you name a GPO?
5.
What can you link the policies to when you deploy your Group Policy solution?
6.
Name the two models you can use to delegate the administration of Group Policy.
Knowledge Check Answer Key

The correct answers to the Knowledge Check questions are bolded.
1.
What types of objects can you store in Active Directory?
47/49
16/11/2014
Users, Groups, Computers, Contacts, Printers, and Shared Folders

2.
Briefly describe the Planning and Design stages of implementing Group Policy.
During the Planning stage:
Decided which components of Group Policy to deploy
Start gathering information about your company and how it carries out its dayto-day business with an Active Directory network
Design a Group Policy that manages entities (computer security, software
deployment, etc.)
During the Design stage:
Configure the physical components of the environment
Lay out the Group Policy model
Delegate management authority
Create new GPOs
Design the interaction of GPOs with Active Directory sites
3.
What should you do when you plan your Group Policy in accordance with your
company requirements? (Choose all that apply.)
a.
Ask the planning stage questions.
b.
Find out about the design and implementation of your Active Directory
infrastructure.
c.
Base your Group Policy design on your physical and logical domain controller
deployment.
d.
Determine how your company carries out its day-to-day business with an
Active
Directory network.
4.
What should you include when you name a GPO?
48/49
16/11/2014
The settings applied and the date of creation and change.

5.
What can you link the policies to when you deploy your Group Policy solution?
You can link the policies to the domain, site, or at the various levels of a nested
OU structure.
6.
Name the two models you can use to delegate the administration of Group Policy.
Centralized administration model and distributed administration model
49/49

3 Designing A Group Policy Infrastructure

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 Designing A Group Policy Infrastructure

Uploaded by

Copyright:

Available Formats

16/11/2014

3 Designing a Group Policy Infrastructure

3 Designing a Group Policy Infrastructure

After completing this section, you will be able to:

3 Designing a Group Policy Infrastructure

Overview of Active Directory

Figure 42: Overview of Active Directory

3 Designing a Group Policy Infrastructure

Active Directory Objects

Figure 43: Active Directory Objects

3 Designing a Group Policy Infrastructure

Groups: Groups are very important in the reduction of administrative overhead.

Active Directory Architecture

Figure 44: Active Directory Architecture

3 Designing a Group Policy Infrastructure

Active Directory is made up of a collection of components that work at different levels of a

3 Designing a Group Policy Infrastructure

Figure 45: Naming Standards

3 Designing a Group Policy Infrastructure

The following is an example of an Active Directory distinguished name: cn=JaneD,

Users and Groups

Figure 46: Users and Groups

3 Designing a Group Policy Infrastructure

Group Types and Scopes

3 Designing a Group Policy Infrastructure

Groups in Active Directory come in three different group scopes:

3 Designing a Group Policy Infrastructure

Figure 47: Organizational Units

Figure 48: OUs and Groups

3 Designing a Group Policy Infrastructure

Figure 49: Creating an OU Structure

3 Designing a Group Policy Infrastructure

Introducing the Design Stages for Implementing Group

3 Designing a Group Policy Infrastructure

Planning Your Group Policy Design

Figure 51: Planning Your Group Policy Design

3 Designing a Group Policy Infrastructure

Figure 52: Policy Survey

3 Designing a Group Policy Infrastructure

Figure 53: Policy Objectives

3 Designing a Group Policy Infrastructure

Figure 54: Policy Components

3 Designing a Group Policy Infrastructure

Designing Your Group Policy Solution

Figure 55: Designing Your Group Policy Solution

Group Policy Solution Components

3 Designing a Group Policy Infrastructure

Figure 56: Group Policy Solution Components

3 Designing a Group Policy Infrastructure

3 Designing a Group Policy Infrastructure

Designing Your Group Policy Model

Figure 57: Designing Your Group Policy Model

3 Designing a Group Policy Infrastructure

Delegating GPO Responsibilities

Figure 58: Delegating GPO Responsibilities

Creating New GPOs

3 Designing a Group Policy Infrastructure

Figure 59: Creating New GPOs

3 Designing a Group Policy Infrastructure

Sites and GPOs

Figure 60: Sites and GPOs

3 Designing a Group Policy Infrastructure