Share via

Overview of Group Policy for Office 2013

  • Article

 

Applies to: Office 2013, Office 365 ProPlus

Summary: Use Group Policy to apply and enforce settings for Office 2013.

Audience: IT Professionals

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 Office 2013 applications can review this article for a brief overview of Group Policy concepts. For more information about Group Policy, see Windows Server article Group Policy overview.

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 (AD DS) environment.

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 2013 settings that contains only configurations for Office 2013 applications. You can then apply that GPO to a specific site so that users who are contained in that site receive the Office 2013 configurations that you specified in the Office 2013 settings GPO.

Every computer has a local GPO that is always processed, regardless of whether the computer is a member of a domain or 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 7, and Windows 8, Windows Server 2008, and Windows Server 2012 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, Windows Server 2008, or Windows Server 2012-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 later applied 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 that are linked to the site to which the computer belongs are processed next. Processing is completed in the order that is 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 that is 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 that are 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 that are 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 that is 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 that are 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 that are deployed in GPOs that are linked to parent containers that are in Active Directory are inherited by child containers and combine with settings that are deployed in GPOs that are linked to the child containers. If multiple GPOs attempt to set a policy setting that has conflicting values, the GPO that has 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 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 120 minutes.

After you edit security policy settings, the policy settings on the computers in the OU to which the GPO is linked are processed on the following schedule:

  • When a computer restarts.

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

Note

By default, security policy settings that are 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 that are 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, you might have 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 can't 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 XP, Windows Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, and Windows Server 2012 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.

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 that are 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 that are 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 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 make sure 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 who logs 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 that runs Windows Server 2003, Windows Server 2008, or Windows Server 2012. 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 XML files that consist of a hierarchy of categories and subcategories to define how options are displayed 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 two file versions:.admx, and .adml. The .adml files are the language-specific versions of .admx files. You can use the .admx and .adml files on computers that run Windows Vista, Windows 7, Windows 8, Windows Server 2008, or Windows Server 2012.

The functionality of the administrative template files is limited. The purpose of.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 that are under Computer Configuration manipulate registry settings for the computer. Settings that are 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

.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.

Administrative Template files for Office 2013

Administrative Template files specifically for Office 2013 are available as a separate download and let you do the following:

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

  • Manage security in the Office 2013 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 2013 Administrative Templates, see Group Policy Administrative Template files (ADMX, ADML) and Office Customization Tool (OCT) files for Office 2013.

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

Application Administrative Template files

Access 2013

access15.admx, access15.adml

Excel 2013

excel15.admx, excel15.adml

InfoPath 2013

inf15.admx, inf15.adml

Lync 2013

lync15.admx, lync15.adml

Office 2013

office15.admx, office15.adml

OneNote 2013

onent15.admx, onent15.adml

Outlook 2013

outlk15.admx, outlk15.adml

PowerPoint 2013

ppt15.admx, ppt15.adml

Project 2013

proj15.admx, proj15.adml

Publisher 2013

pub15.admx, pub15.adml

SharePoint Designer 2013

spd15.admx, spd15.adml

Visio 2013

visio15.admx, visio15.adml

Word 2013

word15.admx, word15.adml

Important

You can use Group Policy to manage the following versions of Office 2013:

  • Office suites available through volume licensing. For example, Office Standard 2013.

  • Individual Office programs sold through retail stores or through volume licensing.

If you buy Office as part of Office 365, your license plan determines whether you can use Group Policy to manage your Office programs. The Office Applications Service Description lists which Office 365 plans support Group Policy.

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 changes the registry on users’ computers.

True policies

Registry values for true policies are stored under the approved registry keys for Group Policy. Users can't 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 2013, true policies are stored in the following registry locations.

For computer policy settings:

  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\15.0

For user policy settings:

  • HKEY_CURRENT_USER\Software\Policies\ Microsoft\Office\15.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 can 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, choose the Administrative Templates node, choose View, choose 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   Manage most Group Policy management tasks.

  • Group Policy Object Editor  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, Windows Server 2008, Windows Server 2012 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 inside 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 the policy settings that are applied under circumstances that are 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 Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, or Windows Server 2012.

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 Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, and Windows Server 2012 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, Windows 8, Windows Server 2008, or Windows Server 2012). 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 divided into folders that contain the different kinds of policy settings that you can 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 Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, and Windows Server 2012. 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 2013 applications:

  • Office Customization Tool (OCT)   Use the OCT to create a Setup customization file (.msp file). Administrators can use the OCT to customize features and configure user settings. Users can change 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/15.0. This tool is typically used in organizations that do not manage desktop configurations centrally. For more information, see Office Customization Tool (OCT) reference for Office 2013.

  • Group Policy   Use Group Policy to configure the Office 2013 policy settings that are contained in Administrative Templates. 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 (OCT) reference for Office 2013.

See also

Plan Group Policy for Office 2013
Use Group Policy to disable user interface items and shortcut keys in Office 2013
Group Policy Administrative Template files (ADMX, ADML) and Office Customization Tool (OCT) files for Office 2013

Windows Server Group policy
Group Policy Planning and Deployment Guide