Sdílet prostřednictvím

  • Článek

Group Policy overview for Office 2010

 

Applies to: Office 2010

Topic Last Modified: 2011-08-05

Banner stating end of support date for Office 2010 with link to more info

Group Policy enables administrators to apply configurations or policy settings to users and computers in an Active Directory directory service environment. Administrators who plan to use Group Policy to manage Microsoft Office 2010 applications can review this article for a brief overview of Group Policy concepts. Answers to frequently asked questions about Group Policy and Office 2010 are available in FAQ: Group Policy (Office 2010).

In this article:

  • Local and Active Directory-based Group Policy

  • Group Policy processing

  • Changing how Group Policy processes GPOs

  • Administrative Templates

  • True policies vs. user preferences

  • Group Policy management tools

  • Office Customization Tool and Group Policy

Local and Active Directory-based Group Policy

Group Policy is an infrastructure that is used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers in an Active Directory directory service environment. The Group Policy infrastructure consists of a Group Policy engine and several individual extensions. These extensions are used to configure Group Policy settings, either by modifying the registry through the Administrative Templates extension, or setting Group Policy settings for security settings, software installation, folder redirection, Internet Explorer Maintenance, wireless network settings, and other areas.

Each installation of Group Policy consists of two extensions:

  • A server-side extension of the Group Policy Object Editor Microsoft Management Console (MMC) snap-in, used to define and set the policy settings applied to client computers.

  • A client-side extension that the Group Policy engine calls to apply policy settings.

Group Policy settings are contained in Group Policy objects (GPOs), which are linked to selected Active Directory containers such as sites, domains, or organizational units (OUs). When a GPO is created, it is stored in the domain. When the GPO is linked to an Active Directory container, such as an OU, the link is a component of that Active Directory container. The link is not a component of the GPO. The settings within GPOs are evaluated by the affected targets by using the hierarchical nature of Active Directory. For example, you can create a GPO named Office 2010 settings that contains only configurations for Office 2010 applications. You can then apply that GPO to a specific site so that users contained in that site receive the Office 2010 configurations that you specified in the Office 2010 settings GPO.

Every computer has a local GPO that is always processed, regardless of whether the computer is a member of a domain or is a stand-alone computer. The local GPO cannot be blocked by domain-based GPOs. However, settings in domain GPOs always take precedence, because they are processed after the local GPO.

Note

Windows Vista, Windows Server 2008, and Windows 7 provide support for managing multiple local GPOs on stand-alone computers. For more information, see Step-by-Step Guide to Managing Multiple Local Group Policy Objects (https://go.microsoft.com/fwlink/p/?LinkId=182215).

Although you can configure local GPOs on individual computers, maximum benefits of Group Policy are obtained in a Windows Server 2003 or Windows Server 2008-based network that has Active Directory installed.

Group Policy processing

Group Policy for computers is applied at computer startup. Group Policy for users is applied when users log on. In addition to the initial processing of Group Policy at startup and logon, Group Policy is applied subsequently in the background periodically. During a background refresh, a client-side extension reapplies the policy settings only if it detects that a change occurred on the server in any of its GPOs or its list of GPOs. For software installation and folder redirection, Group Policy processing occurs only during computer startup or user logon.

Group Policy settings are processed in the following order:

  • Local GPO   Each computer has a GPO that is stored locally. This GPO processes for both computer and user Group Policy.

  • Site   GPOs linked to the site to which the computer belongs are processed next. Processing is completed in the order specified by the administrator, on the Linked Group Policy Objects tab for the site in Group Policy Management Console (GPMC). The GPO that has the lowest link order is processed last and has the highest precedence. For information about how to use GPMC, see Group Policy management tools later in this article.

  • Domain   Multiple domain-linked GPOs are processed in the order specified by the administrator, on the Linked Group Policy Objects tab for the domain in GPMC. The GPO that has the lowest link order is processed last and has the highest precedence.

  • Organizational units   GPOs linked to the OU that is highest in the Active Directory hierarchy are processed first, and then GPOs that are linked to its child OU are processed, and so on. GPOs linked to the OU that contains the user or computer are processed last.

The processing order is subject to the following conditions:

  • Windows Management Instrumentation (WMI) or security filtering applied to GPOs.

  • Any domain-based GPO (not local GPO) can be enforced by using the Enforce option, so that its policy settings cannot be overwritten. Because an Enforced GPO is processed last, no other settings can write over the settings in that GPO. If more than one Enforced GPO exists, the same setting in each GPO can be set to a different value. In this case, the link order of the GPOs determines which GPO contains the final settings.

  • At any domain or OU, Group Policy inheritance can be selectively designated as Block Inheritance. However, because Enforced GPOs are always applied and cannot be blocked, blocking inheritance does not prevent the application of policy settings from Enforced GPOs.

Policy inheritance

Policy settings in effect for a user and computer are the result of the combination of GPOs applied at a site, domain, or OU. When multiple GPOs apply to users and computers in those Active Directory containers, the settings in the GPOs are aggregated. By default, settings deployed in GPOs linked to higher-level containers (parent containers) in Active Directory are inherited to child containers and combine with settings deployed in GPOs linked to the child containers. If multiple GPOs attempt to set a policy setting that has conflicting values, the GPO with the highest precedence sets the setting. GPOs that are processed later have precedence over GPOs that are processed earlier.

Synchronous and asynchronous processing

Synchronous processes can be described as a series of processes in which one process must finish running before the next one begins. Asynchronous processes can run on different threads at the same time, because their outcome is independent of other processes. Administrators can use a policy setting for each GPO to change the default processing behavior so that processing is asynchronous instead of synchronous.

Under synchronous processing, there is a time limit of 60 minutes for all of Group Policy to finish processing on the client computer. Client-side extensions that have not finished processing after 60 minutes are signaled to stop. In this case, the associated policy settings might not be fully applied.

Fast Logon Optimization feature

By default, the Fast Logon Optimization feature is set for both domain and workgroup members. The result is the asynchronous application of policy when the computer starts and the user logs on. This application of policy is similar to a background refresh. It can reduce the length of time it takes for the logon dialog box to appear and the length of time it takes for the desktop to become available to the user.

Administrators can disable the Fast Logon Optimization feature by using the Always wait for the network at computer startup and logon policy setting, which is accessed in the Computer Configuration\Administrative Templates\System\Logon node of Group Policy Object Editor.

Some Group Policy extensions are not processed when the connection speed falls below specified thresholds. The default value for what Group Policy considers a slow link is any rate slower than 500 Kilobits per second (Kbps).

Group Policy refresh interval

By default, Group Policy is processed every 90 minutes, with a randomized delay of up to 30 minutes — for a total maximum refresh interval of up to 120 minutes.

For security settings, after you have edited security settings policies, the policy settings are refreshed on the computers in the OU to which the GPO is linked:

  • When a computer restarts.

  • Every 90 minutes on a workstation or server and every 5 minutes on a domain controller.

  • By default, security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes), even if a GPO has not changed.

Triggering a Group Policy refresh

Changes made to the GPO must first replicate to the appropriate domain controller. Therefore, changes to Group Policy settings might not be immediately available on users’ desktops. In some scenarios, such as application of security policy settings, it might be necessary to apply policy settings immediately.

Administrators can trigger a policy refresh manually from a local computer without waiting for the automatic background refresh. To do this, administrators can type gpupdate at the command line to refresh the user or computer policy settings. You cannot use GPMC to trigger a policy refresh.

The gpupdate command triggers a background policy refresh on the local computer from which the command is run. The gpupdate command is used in Windows Server 2003 and Windows XP environments.

The application of Group Policy cannot be pushed to clients on demand from the server.

Changing how Group Policy processes GPOs

The primary method for specifying which users and computers receive the settings from a GPO is by linking the GPO to sites, domains, and OUs.

You can change the default order by which GPOs are processed by using any of the following methods:

  • Change the link order.

  • Block inheritance.

  • Enforce a GPO link.

  • Disable a GPO link.

  • Use security filtering.

  • Use Windows Management Instrumentation (WMI) filtering.

  • Use loopback processing.

Each of these methods is described in the following subsections.

The GPO link order in a site, domain, or OU controls when links are applied. Administrators can change the precedence of a link by changing the link order, that is, by moving each link up or down in the list to the appropriate location. The link that has the higher order (1 is the highest order) has the higher precedence for a site, domain, or OU.

Block inheritance

Applying block inheritance to a domain or OU prevents GPOs linked to higher sites, domains, or organizational units from being automatically inherited by the child-level Active Directory container.

You can specify that the settings in a GPO link take precedence over the settings of any child object by setting that link to Enforced. GPO links that are enforced cannot be blocked from the parent container. If GPOs contain conflicting settings and do not have enforcement from a higher-level container, the settings of the GPO links at the higher-level parent container are overwritten by settings in GPOs linked to child OUs. By using enforcement, the parent GPO link always has precedence. By default, GPO links are not enforced.

You can completely block how users apply a GPO for a site, domain, or OU by disabling the GPO link for that domain, site, or OU. This does not disable the GPO. If the GPO is linked to other sites, domains, or OUs, they will continue to process the GPO if the links are enabled.

Use security filtering

You can use security filtering to specify that only specific security principles in a container where the GPO is linked apply the GPO. Administrators can use security filtering to narrow the scope of a GPO so that the GPO applies only to a single group, user, or computer. Security filtering cannot be used selectively on different settings in a GPO.

The GPO applies to a user or computer only if that user or computer has both Read and Apply Group Policy permissions on the GPO, either explicitly or effectively through group membership. By default, all GPOs have Read and Apply Group Policy set to Allowed for the Authenticated Users group, which includes users and computers. This is how all authenticated users receive the settings of a new GPO when the GPO is applied to an OU, domain, or site.

By default, Domain Admins, Enterprise Admins, and the local system have full control permissions, without the Apply Group Policy access-control entry (ACE). Administrators are also members of Authenticated Users. This means that, by default, administrators receive the settings in the GPO. These permissions can be changed to limit the scope to a specific set of users, groups, or computers within the OU, domain, or site.

The Group Policy Management Console (GPMC) manages these permissions as a single unit and displays the security filtering for the GPO on the GPO Scope tab. In GPMC, groups, users, and computers can be added or removed as security filters for each GPO.

Use Windows Management Instrumentation filtering

You can use Windows Management Instrumentation (WMI) filtering to filter the application of a GPO by attaching a WMI Query Language (WQL) query to a GPO. The queries can be used to query WMI for multiple items. If a query returns true for all queried items, the GPO is applied to the target user or computer.

A GPO is linked to a WMI filter and applied on a target computer, and the filter is evaluated on the target computer. If the WMI filter evaluates to false, the GPO is not applied (except if the client computer is running Windows 2000. In this case, the filter is ignored and the GPO is always applied). If the WMI filter evaluates to true, the GPO is applied.

The WMI filter is a separate object from the GPO in the directory. A WMI filter must be linked to a GPO to apply, and a WMI filter and the GPO to which it is linked must be in the same domain. WMI filters are stored only in domains. Each GPO can have only one WMI filter. The same WMI filter can be linked to multiple GPOs.

Note

WMI is the Microsoft implementation of the Web-Based Enterprise Management industry initiative that establishes management infrastructure standards and lets you combine information from various hardware and software management systems. WMI exposes hardware configuration data such as CPU, memory, disk space, and manufacturer, and also software configuration data from the registry, drivers, file system, Active Directory, the Windows Installer service, networking configuration, and application data. Data about a target computer can be used for administrative purposes, such as WMI filtering of GPOs.

Use loopback processing

You can use this feature to ensure that a consistent set of policy settings is applied to any user who logs on to a specific computer, regardless of the user's location in Active Directory.

Loopback processing is an advanced Group Policy setting that is useful on computers in some closely managed environments, such as servers, kiosks, laboratories, classrooms, and reception areas. Setting loopback causes the User Configuration policy settings in GPOs that apply to the computer to be applied to every user logging on to that computer, instead of (in Replace mode) or in addition to (in Merge mode) the User Configuration settings of the user.

To set loopback processing, you can use the User Group Policy loopback processing mode policy setting, which is accessed under Computer Configuration\Administrative Templates\System\Group Policy in Group Policy Object Editor.

To use the loopback processing feature, both the user account and the computer account must be in a domain running Windows Server 2003 or a later version of Windows. Loopback processing does not work for computers that are joined to a workgroup.

Administrative Templates

The Administrative Templates extension of Group Policy consists of an MMC server-side snap-in that is used to configure policy settings and a client-side extension that sets registry keys on target computers. Administrative Templates policy is also known as registry-based policy or registry policy.

Administrative Template files

Administrative Template files are Unicode files that consist of a hierarchy of categories and subcategories to define how options display through the Group Policy Object Editor and GPMC. They also indicate the registry locations that are affected by policy setting configurations, which include the default (not configured), enabled, or disabled values of the policy setting. The templates are available in three file versions: .adm, .admx, and .adml. The .adm files can be used for computers that are running any Windows operating system. The .admx and .adml files can be used on computers that are running at least Windows Vista or Windows Server 2008. The .adml files are the language-specific versions of .admx files.

The functionality of the administrative template files is limited. The purpose of .adm, .admx, or .adml template files is to enable a user interface to configure policy settings. Administrative Template files do not contain policy settings. The policy settings are contained in Registry.pol files that are located in the Sysvol folder on domain controllers.

The Administrative Templates server-side snap-in provides an Administrative Templates node that appears in Group Policy Object Editor under the Computer Configuration node and under the User Configuration node. The settings under Computer Configuration manipulate registry settings for the computer. Settings under User Configuration manipulate registry settings for users. Although some policy settings require simple UI elements such as text boxes to enter values, most policy settings contain only the following options:

  • Enabled   The policy is enforced. Some policy settings provide additional options that define the behavior when the policy is activated.

  • Disabled   Enforces the opposite behavior as the Enabled state for most policy settings. For example, if Enabled forces a feature's state to Off, Disabled forces the feature's state to On.

  • Not configured   The policy is not enforced. This is the default state for most settings.

The Administrative Template files are stored in the locations on the local computer, as shown in the following table.

File type Folder

.adm

%systemroot%\Inf

.admx

%systemroot%\PolicyDefinitions

.adml

%systemroot%\PolicyDefinitions\<language-specific folder, e.g., en-us>

You can also store and use .admx and .adml files from a central store in the folders on the domain controller, as shown in the following table.

File type Folder

.admx

%systemroot%\sysvol\domain\policies\PolicyDefinitions

.adml

%systemroot%\sysvol\domain\policies\PolicyDefinitions\<language-specific folder, for example, en-us>

For more information about how to store and use the templates from a central store, see “Group policy and sysvol” in the Group Policy Planning and Deployment Guide (https://go.microsoft.com/fwlink/p/?LinkId=182208).

Administrative Template files for Office 2010

Administrative Template files specifically for Office 2010 are available as a separate download and let you:

  • Control entry points to the Internet from Office 2010 applications.

  • Manage security in the Office 2010 applications.

  • Hide settings and options that are unnecessary for users to perform their jobs and that might distract them or result in unnecessary support calls.

  • Create a highly managed standard configuration on users’ computers.

To download the Office 2010 administrative templates, see Office 2010 Administrative Template files (ADM, ADMX, ADML) and Office Customization Tool (https://go.microsoft.com/fwlink/p/?LinkId=189316).

The Office 2010 Administrative Templates are as shown in the following table.

Application Administrative Template files

Microsoft Access 2010

access14.admx, access14.adml, access14.adm

Microsoft Excel 2010

excel14.admx, excel14.adml, excel14.adm

Microsoft InfoPath 2010

inf14.admx, inf14.adml, inf14.adm

Microsoft Office 2010

office14.admx, office14.adml, office14.adm

Microsoft OneNote 2010

onent14.admx, onent14.adml, onent14.adm

Microsoft Outlook 2010

outlk14.admx, outlk14.adml, outlk14.adm

Microsoft PowerPoint 2010

ppt14.admx, ppt14.adml, ppt14.adm

Microsoft Project 2010

proj14.admx, proj14.adml, proj14.adm

Microsoft Publisher 2010

pub14.admx, pub14.adml, pub14.adm

Microsoft SharePoint Designer 2010

spd14.admx, spd14.adml, spd14.adm

Microsoft SharePoint Workspace 2010

spw14.admx, spw14.adml, spw14.adm

Microsoft Visio 2010

visio14.admx, visio14.adml, visio14.adm

Microsoft Word 2010

word14.admx, word14.adml, word14.adm

True policies vs. user preferences

Group Policy settings that administrators can fully manage are known as true policies. Settings that users can configure (but might reflect the default state of the operating system at installation time) are known as preferences. Both true policies and preferences contain information that modifies the registry on users’ computers.

True policies

Registry values for true policies are stored under the approved registry keys for Group Policy. Users cannot change or disable these settings.

For computer policy settings:

  • HKEY_LOCAL_MACHINE\Software\Policies (the preferred location)

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies

For user policy settings:

  • HKEY_CURRENT_USER\Software\Policies (the preferred location)

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

For Office 2010, true policies are stored in the following registry locations.

For computer policy settings:

  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\14.0

For user policy settings:

  • HKEY_CURRENT_USER\Software\Policies\ Microsoft\Office\14.0

Preferences

Preferences are set by users or by the operating system at installation time. The registry values that store preferences are located outside the approved Group Policy keys. Users can change their preferences.

If you configure preference settings by using a GPO, it does not have system access control list (SACL) restrictions. Therefore, users might be able to change these values in the registry. When the GPO goes out of scope (if the GPO is unlinked, disabled, or deleted), these values are not removed from the registry.

To view preferences in Group Policy Object Editor, click the Administrative Templates node, click View, click Filtering, and then clear the Only show policy settings that can be fully managed check box.

Group Policy management tools

Administrators use the following tools to administer Group Policy:

  • Group Policy Management Console   Used to manage most Group Policy management tasks.

  • Group Policy Object Editor   Used to configure policy settings in GPOs.

Group Policy Management Console

Group Policy Management Console (GPMC) simplifies the management of Group Policy by providing a single tool to manage core aspects of Group Policy, such as scoping, delegating, filtering, and manipulating inheritance of GPOs. GPMC can also be used to back up (export), restore, import, and copy GPOs. Administrators can use GPMC to predict how GPOs will affect the network and to determine how GPOs have changed settings on a computer or user. GPMC is the preferred tool for managing most Group Policy tasks in a domain environment.

GPMC provides a view of GPOs, sites, domains, and OUs across an enterprise, and can be used to manage either Windows Server 2003 or Windows 2000 domains. Administrators use GPMC to perform all Group Policy management tasks, except for configuring individual policy settings in Group Policy objects. This is performed with Group Policy Object Editor, which you open within GPMC.

Administrators use GPMC to create a GPO and has no initial settings. An administrator can also create a GPO and link the GPO to an Active Directory container at the same time. To configure individual settings in a GPO, an administrator edits the GPO by using Group Policy Object Editor from within GPMC. Group Policy Object Editor is displayed with the GPO loaded.

An administrator can use GPMC to link GPOs to sites, domains, or OUs in Active Directory. Administrators must link GPOs to apply settings to users and computers in Active Directory containers.

GPMC includes the following Resultant Set of Policies (RSoP) features that are provided by Windows:

  • Group Policy Modeling   Simulates which policy settings are applied under circumstances specified by an administrator. Administrators can use Group Policy Modeling to simulate the RSoP data that would be applied for an existing configuration, or they can analyze the effects of simulated, hypothetical changes to the directory environment.

  • Group Policy Results   Represents the actual policy data that is applied to a computer and user. Data is obtained by querying the target computer and retrieving the RSoP data that was applied to that computer. The Group Policy Results capability is provided by the client operating system and requires Windows XP, Windows Server 2003, or later versions of the operating system.

Group Policy Object Editor

Group Policy Object Editor is an MMC snap-in that is used to configure policy settings in GPOs. The Group Policy Object Editor is contained in gpedit.dll, and is installed with Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7 operating systems.

To configure Group Policy settings for a local computer that is not a member of a domain, use Group Policy Object Editor to manage a local GPO (or multiple GPOs in computers that are running Windows Vista, Windows 7, or Windows Server 2008). To configure Group Policy settings in a domain environment, GPMC (which invokes Group Policy Object Editor) is the preferred tool for Group Policy management tasks.

Group Policy Object Editor gives administrators a hierarchical tree structure for configuring Group Policy settings in GPOs, and consists of the following two main nodes:

  • User Configuration   Contains settings that are applied to users when users log on and periodic background refresh.

  • Computer Configuration   Contains settings that are applied to computers at startup and periodic background refresh.

These two main nodes are additionally divided into folders that contain the different kinds of policy settings that can be set. These folders include the following:

  • Software Settings   Contains software installation settings.

  • Windows Settings   Contains Security settings and Scripts policy settings.

  • Administrative Templates   Contains registry-based policy settings

System requirements for GPMC and Group Policy Object Editor

The Group Policy Object Editor is part of GPMC and is invoked when you edit a GPO. You can run GPMC on Windows XP, Windows Server 2003, Windows Vista, Windows 7, and Windows Server 2008. The requirements vary per Windows operating system as follows:

For more information about how to use GPMC and the Group Policy Object Editor, see Use Group Policy to enforce Office 2010 settings.

Office Customization Tool and Group Policy

Administrators can use either the Office Customization Tool (OCT) or Group Policy to customize user configurations for Office 2010 applications:

  • Office Customization Tool (OCT)   Used to create a Setup customization file (.msp file). Administrators can use the OCT to customize features and configure user settings. Users can modify most of the settings after the installation. This is because the OCT configures settings in publicly available parts of the registry, such as HKEY_CURRENT_USER/Software/Microsoft/Office/14.0. This tool is typically used in organizations that do not manage desktop configurations centrally. For more information, see Office Customization Tool in Office 2010.

  • Group Policy   Used to configure the Office 2010 policy settings that are contained in Administrative Templates, and the operating system enforces those policy settings. In an Active Directory environment, administrators can apply policy settings to groups of users and computers in a site, domain, or OU to which a Group Policy object is linked. True policy settings are written to the approved registry keys for policy, and these settings have SACL restrictions that prevent users who are not administrators from changing them. Administrators can use Group Policy to create highly managed desktop configurations. They can also create lightly managed configurations to address the business and security requirements of their organizations. For more information about the OCT, see Office Customization Tool in Office 2010.