Vous êtes sur la page 1sur 11

Group Policy is an Active Directory feature that provides the means for you to effectively and efficiently

manage large numbers of computers. You can manage both user and computer configuration settings
centrally, from one position of administration. You can define group policies as being a collection of user and
computer configuration settings which you can link to the following components:

• Computers
• Sites
• Domains
• Organizational Units (OUs)

Once linked, Group Policy defines the manner in which the operating system, network resources, and
applications and programs operate for users within the organization. In other words, group policies define
the behaviour of the desktops of users.

You can use Group Policy for the following administrative operations:

• Through group policies, you can define and configure scripts that run at:

o Computer startup
o Computer shutdown
o User logon
o User logoff

• To change Registry settings


• To deploy and manage programs and applications
• To establish domain password and account policies
• To redirect system folders
• To enforce software distribution and installation

You can define policies that behave differently for a computer, and a user:

• You can define group policies that affect a computer, irrespective of the particular user
logging on to the computer. For instance, you can through a policy, configure the proxy server
settings for a computer.
• You can define group policies that affect a user, irrespective of the computer which the
user utilizes to log on to the system. For instance, you can use group policies to specify the
applications or programs which are available to the user, and the programs which should exist
on the user's desktop.

Group Policy settings can therefore apply to the following types of Active Directory objects:

• User objects
• Computer objects

Because users and computers in Active Directory can be located in groups, and categorized in
Organizational Units (OUs), using group policies can simplify the management of thousands of computers.

You can also define policies that affects resources connected to a particular computer (local policy), or you
can define policies that affect the Active Directory directory (non-local policies).
You need to be familiar with, and understand the concepts that affect Group Policy operations, the different
components of Group Policy, and the terminology used with Group Policy in order to implement it within your
organization. The remainder of this Article focuses on this.

Understanding Group Policy Objects (GPOs)


A group policy object (GPO) is an Active Directory object which contains one or more Group Policy settings
which affect the configuration settings for users or computers. A GPO acts as a container for the settings
configured in Group Policy files. The Active Directory components that can be linked to a GPO are
computers, sites, domains, organizational units (OUs). By linking a GPO to sites, domains, and OU actually
applies the GPO settings to any user or computer objects within that particular container.

As already mentioned, a GPO can be thought of as being a container that contains Group Policy settings.
The GPO identifies the following components of Group Policy:

• Group Policy Template (GPT): A GPT contains a set of instructions which implements a
group of policies. GPTs are located in policy folders, and stored in the SYSVOL of domain
controllers.
• Group Policy Container (GPC): This is an Active Directory object that contains the names
of the Group Policy Templates (GPTs) connected to a specific GPO.

An important Group Policy concept is that Group Policy settings are hierarchical. What this means is that it
can be lined and applied at different levels, as illustrated below:

• Sites: You can define GPOs, and link it to an entire site in Active Directory. The GPOs
would then apply to each domain and server that belongs to the particular site. If the site
contains multiple domains, the GPOs are applied to all the domains within the site.
• Domains: When you define GPOs, and link it to a particular domain in Active Directory, it
is applied to all Computer objects and User objects that belong to, or are stored within that
particular domain.
• Organizational Units (OUs): As is the case with the other two levels at which you can link
and apply GPOs, you can define and link GPOs to a specific OU in Active Directory. The GPOs
are then applied to all Active Directory objects stored within the particular OU.

When determining the manner in which Group Policy settings are hierarchically applied, remember the
following: All computers and users located beneath the container that the GPO is linked to, is automatically
within the scope of the particular GPO. They will therefore be affected by each and every Group Policy
setting specified in the GPO.

This makes it possible for a user or computer to fall within the scope of numerous GPOs linked to a site,
domains, and OUs. The concept, Resultant Set of Policies (RSoP), refers to the total impact of the policies
in the GPOs on the user or computer.

GPOs can be grouped into the categories listed below. The category into which a GPO falls is determined
by the location at which the Group Policy settings originated.

• Local GPOs: A local GPO is stored on a computer, whether it is a member server, or a


workstation. Each computer running Windows Server 2003 has a local GPO. A local GPO
applies only to the particular computer, and relates to activities on that particular computer. For
computers that are part of Active Directory, the local GPO is lower-ranking than nonlocal GPOs.
This basically means that in cases where the computer belongs to Active Directory, the local
GPO settings can be overridden by nonlocal GPO settings. The local GPO is located in the
Systemroot%\System32\GroupPolicy folder. Nodes that are located beneath Security Settings
can be configured for local GPOs.
• Nonlocal GPOs: In addition to a computer running Windows Server 2003 having one local
GPO, the computer can fall within the scope of numerous nonlocal GPOs. Nonlocal GPOs are
also called Active Directory based GPOs. All nonlocal GPOs are defined in Active Directory and
have to be linked to a site, domain or OU. Once linked, it is applied to User objects and
Computer objects. Nonlocal GPOs therefore affect Active Directory objects, and are executed or
carried out whenever the particular object is active. Nonlocal GPOs are located under
%Systemroot%\Sysvol\Domain Name\Policies\GPO GUID\Adm. The GPO GUID represents the
Global Unique Identifier (GUID) of the GPO. Because nonlocal GPOs are created in Active
Directory, are linked to sites, domains, or OUs; and are applied to User objects or Computer
objects, a Windows 2000 or Windows Server 2003 domain controller has to be installed before
you can use nonlocal GPOs. When the Active Directory directory service is installed, the
following Nonlocal GPOs are automatically created:
o Default Domain Policy: The Default Domain Policy is linked to the domain. This
GPO impacts users and computers that are part of the domain using Group Policy
inheritance.
o Default Domain Controllers Policy: The Default Domain Controllers Policy is
linked to the Domain Controllers OU. The GPO only impacts domain controllers.

You define one of the following policy types:

• User policies, which are applied when the user logs on. These policies determine the
manner in which User objects operate within the network.
• Computer policies, which are applied to computers running in Active Directory. These
policies determine the manner in which Computer objects operates within the network.

Group Policy settings in the GPO are regarded as being cumulative and hierarchical in nature. When a GPO
is applied to a site, the GPO is applied to all computers within the site. This is because Active Directory
directory information is replicated as follows:

• To all domain controllers in the site.


• To all domain controllers in sites where a site link has been created.

Where a domain level GPO, and OU level GPO applies to the same users, the settings of both GPOs are
applied to the user. GPOs are by default cumulative and inherited. You can though configure the following
options which either blocks inheritance or forces inheritance, at the different levels to which the GPO is
linked:

• Force Policy Inheritance: This option is used to set inheritance properties on parent
objects. Any child objects located beneath the parent object, automatically inherit Group Policy
settings linked to the parent object.
• Block Policy Inheritance: This option can be used to explicitly define that the Group Policy
settings of an object are not inherited from its associated parent object(s).

To configure and manage policy settings in GPOs, and link GPOs to computers, sites, domains and
organizational units (OUs), Windows Server 2003 provides the following set of management tools:

• The Active Directory Users And Computers (ADUC) console


• The Group Policy Management console
• The Group Policy Object Editor
• The Resultant Set Of Policy snap-in

The Group Policy Object Editor is the tool used to manage and define the Group Policy settings in each
GPO. You can use the Group Policy Object Editor to examine the Group Policy settings for a GPO.

You can use the steps below to open the Microsoft Management Console (MMC) for the local GPO.
1. Proceed to open the Microsoft Management Console.
2. On the Menu bar, click File and select Add/Remove Snap-In.
3. When the Add/Remove Snap-In dialog box opens, click the Add button on the Standalone
tab.
4. On the Add Standalone Snap-In dialog box, select Group Policy Object Editor. Click Add.
5. On the Select Group Policy Object dialog box, in the Group Policy Object box, verify that
Local Computer is listed.
6. Click Finish.
7. Click Close on the Add Standalone Snap-In dialog box.
8. Click OK on the Add/Remove Snap-In dialog box.

You can perform the following management tasks for GPOs:

• Create a GPO: You would use the Active Directory Sites And Services console to create a
GPO and link it to a site. You would use the Active Directory Users And Computers console to
create a GPO and link the GPO to a domain or OU. You can also use the Group Policy
Management console to create GPOs and link them to sites, domains, or OUs.
• Link GPOs to a site, domain or OU: You can view and manage GPO links on the Group
Policy tab of the Properties dialog box of the particular site, domain, or OU. Computer policies
affect computers in the particular site, domain, or OU to which the GPO is linked. User policies
affect users in the particular site, domain, or OU to which the GPO is linked. You can also use
the Group Policy Management console to manage GPO links.
• Edit existing GPOs: To edit existing GPOs, you have to actually open the Group Policy
Object Editor with the existing GPO as the focal point. To do this:
o For sites, use the Active Directory Sites And Services console, open the
Properties of the particular site, click the Group Policy tab and then click the Edit.
o For domains and OU, use the Active Directory Users and Computers console,
open the Properties of the particular domain or OU, click the Group Policy tab and
then click Edit.
o If you are using the Group Policy Management console, right-click the existing
GPO which you want to edit, and then select Edit on the shortcut menu.

Group Policy Settings


In Active Directory, Group Policy settings are held within a Group Policy object (GPO). A GPO has a globally
unique identifier (GUID) attribute that identifies it within Active Directory. As mentioned previously, you can
use the Group Policy Object Editor to examine the Group Policy settings for a GPO. The types of Group
Policy settings that exist are categorized into user configuration settings and computer configuration
settings. The computer configuration settings are stored in the Computer Configuration node and user
configuration settings are stored in the User Configuration.

• Computer Configuration node: This node contains configuration settings which are applied
to the computer when the operating system starts. The user logging on to the computer does not
affect the execution of these group policies.
• User Configuration node: This node contains configuration settings which are applied
when the user logs on to the computer. The computer being logged on to by the user does not
affect the execution of these group policies.

Both the Computer Configuration and the User Configuration nodes contain the following nodes:

• Software Settings node, includes policy settings for installing, removing, or updating
software on computers running in the network.

• Windows Settings node, includes policy settings for installing and connecting to the
Windows operating system.
• Administrative Templates node, includes policy settings for the Registry.

Software Settings
By default, the Software Settings node under the Computer Configuration node and under the User
Configuration node contains the Software Installation extension. This extension is for assisting with the
configuration of software policy settings that define how software and applications are installed on
computers. You can use software settings to deploy new applications to end users, and define a computer
as the location for an application. Software settings defined under the User Configuration node can be used
to make a specific application available to only a particular user, irrespective of the actual computer the user
logs on to. Only the designated user would be able to view and execute the application. You can also use
software policies to deploy new applications in the network, and make them accessible to users. You can
control the default configuration for these applications as well.

Windows Settings
The Windows Settings node in the Computer Configuration node and in the User Configuration node
contains the following:

• Scripts extension: You can define the following types of scripts:

o In Computer Configuration: Startup and shutdown scripts execute when the


computer starts, or shuts down
o In User Configuration: Logon and logoff scripts execute when the user logs on or
logs off the particular computer.

When more than one script exists for a user or computer, logoff scripts are processed before
shutdown scripts.

• Security Settings node: You can define the security levels assigned to a local GPO or
nonlocal GPO.

The policy settings which you can define are determined by whether they are applied in the Computer
Configuration node, or the User Configuration node.

• Account:
o Location = Computer Configuration\Security Settings node, includes policy
settings for password settings and account lockout settings.
• Folder redirection:
o Location = User Configuration\Security Settings node, includes policy settings for
redirecting particular user folders to other locations.
• Internet Explorer maintenance:

o Location = User Configuration\Security Settings node, includes connection


settings user interface settings, and security zone settings; for changing the settings
for Internet Explorer.
• Public Key policies:
o Location = User Configuration\ Security Settings node, includes policy settings
which are associated with the public key activities of users.
• Public Key policies:
o Location = Computer Configuration\Security Settings node, includes policy
settings which are associated the public key activities of the system.

Administrative Templates
The policy settings that are contained in the Administrative Templates node of the Computer Configuration
node and the User Configuration node are Registry based settings. Group Policy settings for user
configuration are stored in the HKEY_CURRENT_USER (HKCU) registry key. Group Policy settings for
computer configuration are stored in the HKEY_LOCAL_MACHINE (HKLM) registry key.

The Administrative templates node contains Group Policy settings for:

• Windows components, including Terminal Services, Windows Media Player, Internet


Explorer, Windows update, and many more.
• User profiles
• Group policy
• Scripts
• Dial-up connections
• And many more different Group Policy settings for computer configuration and user
configuration.

In fact, more than 500 Registry based Group Policy settings can be set under User Configuration. A few
examples are Start Menu settings, Shared folder settings,Control Panel settings, and Desktop settings. The
locations which contain a description on these Group Policy settings are listed below:

• The Administrative Templates Help feature is new in Windows Server 2003.


• Another new Windows Server 2003 feature, the Extended tab in the Group Policy Object
Editor, offers information on each selected setting.
• The Explain tab in the Properties dialog box for the particular setting.

The Administrative templates node of both the User Configuration node and Computer Configuration node
have the following nodes:

• Windows Components node: Includes Group Policy settings which can be used to
manage Internet Explorer, Microsoft Windows Messenger, Terminal Services, Task Scheduler,
and other Windows components.
• System node: Includes Group Policy settings for user profiles, Group Policy, scripts, and
more Group Policy settings which are specific to either user configuration, or to computer
configuration.
• Network node: Includes Group Policy settings for dial-up connections, and offline files, and
other Group Policy settings which are specific to computer configuration.

Only the Administrative templates node located beneath the Computer Configuration node has a Printers
node which contains Group Policy settings that can be set for printers. Only the Administrative templates
node located beneath the User Configuration node has Start menu and task bar, desktop, Control Panel and
shared folders nodes.

A Group Policy setting in the Administrative Templates node has one of the following states or settings:

• Not Configured
• Enabled
• Disabled
As previously mentioned, Group Policy settings for user configuration are stored in the
HKEY_CURRENT_USER (HKCU) registry key, and Group Policy settings for computer configuration are
stored in HKEY_LOCAL_MACHINE (HKLM) registry key. Each in turn stores Group Policy specific registry
information in one of the following reserved trees:

• HKEY_CURRENT_USER\Software\Policies, for user policy settings.


• HKEY_LOCAL_MACHINE\Software\Policies, for computer policy settings.
• HKEY_CURRENT_USER\Software\Microsoft\ Windows\CurrentVersion\Policies, for user
settings.
• HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows\CurrentVersion\Policies; for
computer settings.

What are Administrative Templates?


Administrative templates in Wndows 2000 and Windows Server 2003 are Unicode based text files that have
a .adm file name extension. An administrative template can be defined as the text file which creates the user
interface for the Group Policy settings which you can configure using the Group Policy Object Editor.

The three types of administrative templates which exist are:

• Default administrative templates: These are the administrative templates which are
included in Windows Server 2003, and includes the following set of default administrative
templates:
o Conf.adm administrative template, includes NetMeeting settings for both
Windows 2000 and Windows Server 2003 clients.
o Inetres.adm administrative template, includes Internet Explorer settings for both
Windows 2000, and Windows Server 2003 clients.
o System.adm administrative template, includes system settings for Windows 2000
and Windows Server 2003 clients.
o Wmplayer.adm administrative template, includes Windows Media Player settings
for both Windows 2000 and Windows Server 2003 clients.
o Wuau.adm administrative template, includes Windows Update settings for
Windows 2000 and Windows Server 2003 clients.
• Vendor supplied administrative templates: These are administrative templates which are
provided with software applications that can run on Windows Server 2003. These administrative
templates usually need to be downloaded from a Web site, and then installed.
• Custom administrative templates: These types of administrative templates are usually
created by application developers, using the .adm language, to exercise controller over user
configuration and computer configuration.

Understanding the Group Policy Processing


Sequence
The process listed below is executed when computer configuration settings and user configuration settings
are applied at computer startup, and user log on.

1. When the network starts, the Remote Procedure Call System Service (RPCSS) and
Multiple Universal Naming Convention Provider (MUP) are started.
2. Next, the list of GPOs is acquired for the computer.
3. The content of the GPO list is determined by whether the computer belongs to a Windows
2000 domain or Windows Server 2003 domain; and where in Active Directory the computer is
actually located.
4. The computer configuration settings are processed first, and in this order:
a. local GPO
b. site GPOs
c. domain GPOs
d. OU GPOs
5. The startup scripts execute next, and in a particular sequence as well. This basically being
that each script has to complete or alternatively timeout before the following script can be
executed.
6. When the user finally logs on to the computer, and is authenticated, the user profile for the
particular user is loaded. This is controlled by the Group Policy settings in use.
7. Next, the list of GPOs is acquired for the particular user logging on to the computer.
8. The content of the GPO list is determined by whether the user belongs to a Windows 2000
domain or Windows 2003 domain, whether Loopback is enabled and the mode of this policy
setting, where in Active Directory the user is actually located, and whether the list of GPOs that
should be applied to the user has changed or not. The default configuration is that if the list has
not since changed, no processing is performed. You can however change this.
9. The user configuration settings are processed next, and in this order:
a. local GPO
b. site GPOs
c. domain GPOs
d. OU GPOs
10. The logon scripts execute after this.
11. The user is displayed the user interface as defined by Group Policy.

Understanding the order in which Group Policy


settings are processed
Nonlocal GPOs or Active Directory based GPOs are applied in a hierarchical manner. The end configuration
of the user or compute is actually the result of the GPOs which are linked to a particular site, domain and
OU.

Group policy settings are processed in the order specified below:

1. Local GPO: Recall from an earlier discussion, that each computer running Windows 2000
or Windows Server 2003 contains one GPO which is stored locally. Because the local GPO is
applied first, it means that policies defined at the local computer have the least priority.
2. Site GPO: Site GPOs are GPOs which are linked to sites. The order of the different site
GPOs are determined and defined by the Administrator.
3. Domain GPOs: Domain GPOs are applied next. These are GPOs which are linked to
domains. Once again, when different domain GPOs are linked to the particular domain, their
order is determined and defined by the Administrator. It is evident now that GPOs linked to a
domain enjoy priority or precedence over site GPOs and local GPOs.
4. OU GPOs linked to the OU highest in the Active Directory hierarchy are applied before
any other OUs.
5. OU GPOs linked to child OUs are applied next.
6. OU GPOs linked to the OU closest to the user or computer are then applied.
7. When the OU that contains the user or computer has a GPO linked to it; that GPO is
applied last. You can see that OUs closest to, or which includes the user/computer have
precedence over GPOs linked to OUs higher up the tree.

The order specified above is affected by the a few exceptions, which are noted below:

• If the computer is a member of a workgroup, only the local GPO is applied to the user or
computer.
• When the No Override setting is enabled for a GPO which is linked to a site, domain or
OU, no Group Policy settings contained in the particular GPO is overridden by other GPOs.
Because of the hierarchical manner in which GPOs are applied, and there happens to be more
than one GPO which has the No Override setting enabled, the GPO highest in the tree has
precedence.
• Block Policy Inheritance can be explicitly specified for a site, domain or OU, and is not
applied to any GPOs or GPO links. When enabled for a site, domain or OU; it prevents any
Group Policy settings from passing down from higher up in the tree, to the particular site, domain
or OU for which it is enabled. The only exception is that any GPO links which have the No
Override settings enabled are not blocked, but are applied.
• The loopback setting: Loopback is a Group Policy setting which is useful for lab computers
and terminal servers. Loopback enables you to configure alternatives to the default method of
obtaining the list of GPOs for a user. You can configure the system to apply the User
Configuration settings from GPOs which are linked to containers containing computer objects.
The following states or settings can be enabled for Loopback:
o Not Configured, Enabled, Disabled.
• Loopback can be enabled in the following modes:
o Replace Mode: In this mode, the list of GPOs for a user is replaced by the GPO
list acquired at computer startup.
o Merge Mode: In this mode, the GPO list acquired when the computer started is
added to the GPO list acquired at user log on. The GPO list acquired at computer
startup is processed last.

Understanding Group Policy Inheritance


When discussing Group Policy, the concept of Inheritance signifies that Group Policy settings which affect
user configuration and computer configuration are the resultant set of policies inherited from parent
containers. Policies are usually passed down from a parent container to its associated child containers. The
exception being that a Group Policy setting defined for a child OU overrides the same setting which it
inherited from its parent OU.

A child OU does not inherit its parent OU policy settings in the following instances:

• When the policy settings of a parent OU are set to the Not Configured setting, no child
OUs would inherit those settings. Policy settings that are Disabled are inheritedas Disabled by
child OUs.
• When a policy setting specified for a parent OU happens to be with the identical policy
setting defined for the child OU, the child OU setting overrides the policy setting which it
inherited from the parent OU.
• When the policy setting specified for a parent OU happens to be incompatible with the
same policy configured for the child OU, the policy is not inherited by the child OU.

The ways in which Group Policy settings can be inherited are listed below:

• When the policy setting for a parent OU is set to Enabled or Disabled; and the child OU
does not have the same policy setting configured, the child OUs inherits the policy setting of its
parent OU.
• When a policy setting specified for a parent OU and a policy setting specified for a child
OU are compatible, inheritance can take place. In this case, the child OU inherits the policy
setting of the parent, and the policy setting configured for the child OU is applied as well.

Delegating Administrative Control of GPOs


Configuring the appropriate security settings on GPOs is important for the following reasons:
• When the security settings on the actual GPOs are not set correctly, both Administrators
and users would be able to override them.
• When numerous Administrators create GPOs and edit existing GPOs, the management of
GPOs can be intricate.

To simplify the management of Group Policy, you can delegate administrative control of the following
administrative tasks:

• Creating GPOs: To delegate administrative control for creating GPOs, you have to include
the specified user as a member of the Group Policy Creator Owners group. You would then
delegate authority to the user to manage GPO linking to the site, domain or OU in which the user
will be creating GPOs.
• Linking GPO: To delegate administrative control for linking GPOs, you need to specify the
Manage Group Policy Links option which is made available through the Delegation Of Control
Wizard for the particular domain or OU.
• Editing GPOs: To delegate administrative control for editing existing GPOs, you have to
grant the Read and Write permission for the selected user.

Filtering Group Policies


As mentioned on numerous occasions throughout this Article, group policies are linked to sites, domains and
OUs, and are then applied to user and computer objects, based on where they are located within Active
Directory. Group policies are therefore never directly linked to security groups.

An option does though exist, whereby which you can apply a GPO to a designated security group(s) through
a process known as filtering the GPO. When filtering the GPO, you can specify that it is only applicable
when a user or computer is a member of the security group. You can define filtering as being the process by
which certain security groups are either included or excluded from the Group Policy settings of the GPOs.
This allows you to filter Group Policy to affect those computers and users which you set for being influenced
by Group Policy. Because the Group Policy settings in a nonlocal or Active Directory based GPO is only
relevant to users that have the Read (Allow) permission and Apply (Allow) permission for the GPO, you can
set the necessary permissions for security groups to include only certain computers and users. When
filtering Group Policy remember that the filter would only apply if the users in the security group are in the
scope of the GPO.

Windows Management Instrumentation (WMI) is a management tool which Windows Server 2003 utilizes in
a number of ways to monitor and manage network objects. WMI can be used to filter a GPO based on the
results of a WQL query. This is a new Windows Server 2003 Group Policy feature. You cannot howeer filter
individual elements of a GPO. You can also only choose one WMI filter for any specified GPO. When a WMI
query is utilized to filter the scope of a GPO, the GPO is applied based on properties available in WMI that
are located in the WMI query.

The WMI components are listed below:

• Managed Objects: The WMI technology gathers information from devices and applications
such as hard drives, CPUs and network adapters.
• Common Information Model (CIM): WMI holds the information it gathered in the Common
Information Model repository.
• Common Information Model Object Manager (CIMOM): The CIMOM processes this
information, and interacts with any applications which need to have information stored in the CIM
repository.
• WMI Query Language (WQL): The WMI query language (WQL) is used to compile WMI
queries. The number of attributes which can be used in WMI queries are numerous.
• Event triggers: Group policies do not utilize WMI events
Resultant Set of Policies (RSoP)
Because, GPOs can be linked, blocked, filtered and its settings inherited; it can be quite a time consuming
and complex task to determine which Group Policy settings are applied to a user or computer. Windows
Server 2003 however includes the Resultant Set of Policy (RSoP) tool which simplifies group policy
management. You can use the Resultant Set of Policy (RSoP) tool to determine what occurs with group
policies when a particular user logs on to the computer.

Through RSoP, you can determine the following:

• Which GPOs are applied


• The level (site, domain, OU) at which they are applied
• Which GPOs are blocked

The tool can also be used to assist in the planning of a Group Policy implementation, and to troubleshoot
Group Policy settings.

Vous aimerez peut-être aussi