Group Policy overview (2007 Office system)
Updated: March 5, 2007
Applies To: Office Resource Kit
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
Group Policy is an infrastructure that administrators can use to implement specific computing configurations for users and computers. Policy settings can also be applied to member servers and domain controllers within the scope of an Active Directory forest. Administrators use Group Policy to define configurations once and then rely on the operating system to enforce that state.
Group Policy settings are contained in Group Policy objects (GPOs), which are linked to selected Active Directory directory service containers — sites, domains, or organizational units (OUs). The settings within GPOs are evaluated by the affected targets using the hierarchical nature of Active Directory.
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 Group Policy extension 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.
The 2007 Microsoft Office system system policy settings are contained in Administrative Template (.adm) files. For more information, see the Administrative Templates section.
The following sections provide an overview of Group Policy concepts. For more detailed information, see Group Policy Collection (https://go.microsoft.com/fwlink/?LinkId=80200) on the Microsoft TechNet site.
In this topic
Local and Active Directory-based Group Policy
Group Policy processing
Group Policy application
Targeting the application of Group Policy Objects
Administrative Templates extension
User Preferences and True Policies
Group Policy Management Tools
Office Customization Tool and Group Policy
Local and Active Directory-based Group Policy
Every computer has a local GPO that is always processed, regardless of whether the computer is part 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, since they are processed after the local GPO.
Although you can configure local Group Policy objects on individual computers, maximum benefits of Group Policy are realized in a Windows 2000 or Windows Server 2003-based network with Active Directory installed.
Administrators can implement Group Policy settings for as broad or as narrow a part of their organization as necessary. To do this, administrators link GPOs to sites, domains, and OUs. GPO links affect users and computers as follows:
GPOs linked to a site apply to all users and computers in the site.
GPOs linked to a domain apply directly to all users and computers in the domain and by inheritance to all users and computers in child OUs. Group Policy is not inherited across domains.
GPOs linked to an OU apply directly to all users and computers in the OU and, by inheritance, to all users and computers in child 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.
Administrators must have GPO creation privileges to create a GPO. By default, only domain administrators, enterprise administrators, and members of the Group Policy creator owners group can create Group Policy objects. You must have edit permissions for the GPO that you want to edit.
For more detailed information about Group Policy infrastructure, see Group Policy Collection (https://go.microsoft.com/fwlink/?LinkId=80200) on the Microsoft TechNet site.
The Windows Vista and Windows Server® 2008 operating systems introduce new functionality for managing local GPOs that gives stand-alone computer administrators the ability to apply multiple Group Policy objects to users of stand-alone computers.
Multiple local GPOs: changes in Windows Vista and Windows Server 2008
Windows Vista and Windows Server 2008 provide support for managing multiple local GPOs on stand-alone computers. This capability is useful for managing environments that involve shared computing on a single computer, such as libraries or computer labs. You can assign multiple local GPOs to local users or built-in groups.
In a workgroup environment, each computer maintains its own policy settings. This feature works with domain-based Group Policy, or it can be disabled through a Group Policy setting.
Administrators can use multiple local GPOs to do the following:
Apply different levels of local Group Policy to local users on a stand-alone computer. This capability is ideal for shared computing environments where domain-based management is not available.
Manage Group Policy based on groups of administrators and non-administrators. For example, if administrators want to set up computers in a computer lab to configure a secure environment, they can create highly managed policy settings for User groups and lightly managed policy settings for built-in Administrator accounts. This obviates the need for local administrators to explicitly disable or remove Group Policy settings that interfere with their ability to manage the workstation before they perform administrative tasks. Windows Vista administrators can also turn off local Group Policy settings without explicitly enabling domain-based Group Policy.
Domain administrators can disable the processing of local Group Policy objects on clients running Windows Vista by enabling the Turn off Local Group Policy objects processing policy setting in a domain Group Policy object. This setting is accessed under Computer Configuration\Administrative Templates\System\Group Policy.
Windows Vista provides three layers of local Group Policy objects: local Group Policy, Administrator and Non-Administrators Group Policy, and user-specific local Group Policy. These layers of local Group Policy objects are processed according to the following order:
Local Group Policy
Administrators and Non-Administrators Group Policy
User-specific local Group Policy
For detailed information about using the multiple local GPOs feature in Windows Vista, see the Step-by-Step Guide to Managing Multiple Local Group Policy Objects on the Microsoft TechNet Web site.
Group Policy processing
The local GPO is processed first, and the organizational unit to which the computer or user belongs (the one that it is a direct member of) is processed last. Group Policy settings are processed in the following order:
Local GPO. Each computer has a Group Policy object 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 done 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 with the lowest link order is processed last and has the highest precedence. For information about Group Policy Management Console, see the Group Policy Management Tools section.
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 Group Policy Management Console. The GPO with the lowest link order is processed last and has the highest precedence.
Organizational units. GPOs linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, and then GPOs that are linked to its child organizational unit are processed, and so on. GPOs linked to the organizational unit 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 may 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 organizational unit, 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 with conflicting values, the GPO with the highest precedence sets the setting. GPOs that are processed later have precedence over GPOs that are processed earlier.
Group Policy application
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 on a periodic basis. 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.
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 simultaneously, 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
The Fast Logon Optimization feature is set by default for both domain and workgroup members. The result is the asynchronous application of policy when the computer starts up and when 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.
Note
Logon Optimization is not enabled and policies are processed synchronously when the user logs on for the first time, the user has a roaming profile, the user has a HomeDir, and the user has a logon script specified in the User object. Folder Redirection and Group Policy Software Installation require a synchronous application of policy. Under these conditions, computer startup can still be asynchronous. However, since logon is synchronous, logon does not exhibit optimization.
Client computers running Windows XP Professional, Windows XP 64-bit Edition (Itanium), and Windows Server 2003 operating systems support Fast Logon Optimization in any domain environment.
For servers, startup and logon processing always behaves as if this policy setting is enabled.
Administrators can disable the Fast Logon Optimization feature with 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. When this policy setting is enabled, logons are performed in the same way as they are for Windows 2000 clients. This means that Windows XP waits for the network to be fully initialized before users are logged on. Group Policy is applied synchronously in the foreground.
Slow links processing
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).
The default settings for processing Group Policy over slow links are as follows.
| Setting | Default |
|---|---|
Security Settings |
ON (cannot be turned off) |
IP Security |
ON |
EFS |
ON |
Software Restriction Policies |
ON |
Wireless |
ON |
Administrative Templates |
ON (cannot be turned off) |
Software Installation |
OFF |
Scripts |
OFF |
Folder Redirection |
OFF |
IE maintenance |
ON |
Administrators can use a policy setting to override the default setting. To specify settings for Group Policy slow link detection for computers, use the Group Policy slow link detection policy setting in the Computer Configuration\Administrative Templates\System\Group Policy node of Group Policy Object Editor.
To set this option for users, use the Group Policy slow link detection policy setting in User Configuration\Administrative Templates\System\Group Policy.
For more information about managing Group Policy over slow links, see Specifying Group Policy for Slow Link Detection (https://go.microsoft.com/fwlink/?LinkId=80435) on the Microsoft TechNet site.
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 organizational unit to which the Group Policy object 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 Group Policy object 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 may 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.
For more information about using gpupdate, see Refresh Group Policy settings with GPUpdate.exe (https://go.microsoft.com/fwlink/?LinkId=80461) on the Microsoft TechNet Web site.
Targeting the application of Group Policy Objects
The primary method for specifying which users and computers receive the settings from a GPO is the GPO link to sites, domains, and organizational units.
You can change the default order in which GPOs are processed by changing the link order, blocking policy inheritance, enforcing a GPO link (previously known as no override), and disabling a GPO link.
Administrators can use security filtering and WMI filtering to modify the set of users and computers to which to apply a GPO.
Administrators can also use the Loopback processing feature to ensure that the same set of policy settings is applied to any user that logs on to a specific computer.
Changing the GPO processing order
Administrators can use one of the following methods to change the order in which GPOs are processed:
Change the link order. 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, moving each link up or down in the list to the appropriate location. The link with the higher order (1 is the highest order) has the higher precedence for a site, domain, or organizational unit.
Block inheritance. Using block inheritance for 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. By default, child-level containers inherit all GPOs from the parent. However, it is sometimes useful to block inheritance.
Enforce a GPO link. Administrators 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 organizational units. With enforcement, the parent GPO link always has precedence. By default, GPO links are not enforced.
Disable a GPO link. By default, processing is enabled for all GPO links. You can completely block the application of a GPO for a site, domain, or organizational unit by disabling the GPO link for that domain, site, or organizational unit. This does not disable the GPO. If the GPO is linked to other sites, domains, or organizational units, they will continue to process the GPO if their links are enabled.
Security filtering
This method is used to specify that only specific security principals within 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 within a GPO.
The GPO applies to a user or computer only if that user or computer has both Read and Apply Group Policy (AGP) permissions on the GPO, either explicitly or effectively though group membership. By default, all GPOs have Read and AGP 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 organizational unit, 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 organizational unit, 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. For information about GPMC, see the Group Policy Management Tools section.
Windows Management Instrumentation filtering
Windows Management Instrumentation (WMI) is the Microsoft implementation of the Web-Based Enterprise Management industry initiative that establishes management infrastructure standards and provides a way to combine information from various hardware and software management systems. WMI exposes hardware configuration data such as CPU, memory, disk space, and manufacturer, as well as 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.
WMI filtering is used 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 which 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 in order 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.
Loopback processing
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. Administrators can use this feature to ensure that a consistent set of policy settings is applied to any user that logs on to a specific computer, regardless of the user's location in Active Directory.
To set Loopback processing, administrators 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 Windows 2000 or later domain. Loopback does not work for computers joined to a workgroup.
For more information about targeting the application of GPOs, see Controlling the Scope of Group Policy Objects using GPMC (https://go.microsoft.com/fwlink/?LinkId=80462) on the Microsoft TechNet site.
Administrative Templates extension
The Administrative Templates extension of Group Policy consists of an MMC server-side snap-in 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.
The 2007 Microsoft Office system policy settings are contained in Administrative Template files, which can be downloaded from 2007 Office System Administrative Templates (ADM) (https://go.microsoft.com/fwlink/?LinkId=78161) on the Microsoft Download Center.
Administrative Template files
Administrative Template (.adm) files are Unicode files which consist of a hierarchy of categories and subcategories that define how options display through the Group Policy Object Editor and GPMC. They also indicate the registry locations where changes should be made if a selection is made, specify options or restrictions (in values) associated with the selection, and, in some cases, indicate a default value to use if a selection is activated.
The functionality of .adm files is limited. The purpose of .adm files is to enable a user interface to configure policy settings. .Adm files do not contain policy settings. The policy settings are contained in registry.pol files 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. The default is not configured for most settings.
Administrative Template files for the 2007 Office System
The following Administrative Template files are available for the 2007 Office system:
office12.adm: shared Office components
access12.adm: Microsoft Office Access 2007
cpao12.adm: Calendar Printing Assistant for Microsoft Office Outlook 2007
excel12.adm: Microsoft Office Excel 2007
groove12.adm: Microsoft Office Groove 2007
ic12.adm: Microsoft Office InterConnect 2007
inf12.adm: Microsoft Office InfoPath 2007
onent12.adm: Microsoft Office OneNote 2007
outlk12.adm: Microsoft Office Outlook 2007
ppt12.adm: Microsoft Office PowerPoint 2007
proj12.adm: Microsoft Office Project 2007
pub12.adm: Microsoft Office Publisher 2007
spd12.adm: Microsoft Office SharePoint Designer 2007
visio12.adm: Microsoft Office Visio 2007
word12.adm: Microsoft Office Word 2007
Administrators can use the 2007 Office system policy settings for tasks such as the following:
Managing security settings for the 2007 Office system applications
Preventing connections to the Internet from the 2007 Office system applications
Hiding or disabling 2007 Office system user interface settings that might be confusing to users or unnecessary for users to perform their work
Creating highly managed or less restricted, standard configurations of users' computers
Setting default File Save options for the 2007 Office system applications to prepare for migration from earlier versions of Office
For example, administrators can use Group Policy to disable, enable, or configure most of the settings that control the Office user interface, such as:
Menu commands
Shortcut keys
Options dialog box settings
The large numbers of Group Policy settings available for the 2007 Office system provide a high degree of flexibility. Administrators can create highly restricted or lightly managed configurations, depending on the specific business requirements and security concerns of their organizations.
To download the 2007 Office system Administrative Template files, see 2007 Office System Administrative Templates (ADM) in the Microsoft Download Center.
You can also download the 2007 Microsoft Office System Open XML Format converters Administrative Template (ADM) file from the Microsoft Download Center. Administrators can use this template to modify the default behavior for the Microsoft Office Word, Excel, and PowerPoint 2007 Open XML Format converters.
Administrators can modify Microsoft Office 2003 and Microsoft Office XP Administrative Template files to set default File Save As options to include the Open XML Formats of the 2007 Office system programs. For more information, see KB article 932127, How to modify an existing Office policy file (ADM file) for Office 2003 and for Office XP to set the Save As default file format to include the new OpenXML file formats of the 2007 Microsoft Office programs on the Microsoft Support Knowledge Base (KB) Web site.
For more information about Administrative Templates, see the Administrative Templates Extension Technical Reference (https://go.microsoft.com/fwlink/?LinkId=56088).
Windows Vista and Windows Server 2008 introduce a new XML-based format for Administrative Template files, as discussed in the next section.
Administrative Template Files: Changes in Windows Vista and Windows Server 2008
First released in Windows NT 4.0, Administrative Template files used a unique file format known as .adm files. In Windows Vista and Windows Server 2008 operating systems, these files are replaced by ADMX files, which use an XML-based file format to display registry-based policy settings. These new Administrative Template files make it easier to manage registry-based policy settings in Windows Vista and Windows Server 2008. The policy settings contained in the Office 2007 ADM and ADMX files are the same.
The new ADMX and ADML files replace earlier .adm files and are divided into language-neutral (ADMX) and language-specific (ADML) resource files. These new file types allow Group Policy tools to adjust the user interface according to the administrator's configured language.
Group Policy Object Editor and Group Policy Management Console continue to recognize earlier .adm files you may have in your current environment. Custom .adm files (or .adm files that are not delivered by default in the operating system) in a GPO are used by Group Policy Object Editor and Group Policy Management Console. The tools do not recognize earlier .adm files that were included by default in the operating system, such as System.adm and Inetres.adm.
Administrators can manage Group Policy settings affecting Windows Vista and earlier operating systems from a workstation running Windows Vista. ADMX files are supported only on the Windows Vista operating system. Copying ADMX files to earlier operating systems has no effect.
Note
Administrators can convert ADM files to the ADMX format by using the ADMX Migrator tool. ADMX Migrator provides an ADMX editor with a graphical user interface for creating and editing administrative templates. For more information, see ADMX Migrator (https://go.microsoft.com/fwlink/?LinkId=77409).
ADMX and ADML file storage in Windows Vista
The central store is a folder created on the Sysvol folder of an Active Directory domain controller. This folder provides a single, centralized storage location for ADMX and ADML files for the domain. Administrators can create a central store on a domain controller running Windows Server 2003 R2, Windows Server 2003 SP1, or Windows 2000 Server. The creation of the central store does not require Windows Server 2008.
For more information about administering ADMX files in Vista, see Managing Group Policy ADMX Files Step-by-Step Guide, Requirements for Editing Group Policy Objects Using ADMX Files, and Scenario 2: Editing Domain-Based GPOs Using ADMX Files on the Microsoft TechNet Web site.
User preferences and true policies
Group Policy settings that administrators can fully manage are referred to as true policies. Settings that users configure or that reflect the default state of the operating system at installation time are referred to as preferences. Both true policies and preferences contain information that modifies the registry on users’ computers. There are important distinctions between true policies and preferences. True policy settings take precedence over preference settings.
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
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 shown in the preceding table. Users can change their preferences.
Administrators can write an .adm file that sets registry values outside of the approved Group Policy registry trees. In this case, this method only ensures that a registry key or value is set in a specific way. With this approach, the administrator configures preference settings instead of true policy settings and marks the registry with these settings. This means that the settings persist in the registry, even if the preference setting is disabled or deleted.
If you configure preference settings by using a GPO in this manner, the GPOs that you create do not have Access Control List (ACL) 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.
In contrast, true registry policy settings do have ACL restrictions to prevent users from changing the settings. The policy values are removed when the GPO that sets the values goes out of scope. For this reason, true policies are considered to be policy settings that can be fully managed. By default, the Group Policy Object Editor only displays policy settings that can be fully managed.
To view preferences in Group Policy Object Editor, click the Administrative Templates node, click View, click Filtering, and then clear Only show policy settings that can be fully managed.
True policy settings take priority over preferences; however, they do not overwrite or modify the registry keys used by the preferences. If a policy setting is deployed that conflicts with a preference setting, the policy setting takes precedence over the preference. If both a policy and preference are present, the preference is successfully restored if the policy is removed or disabled. Preference settings persist in the registry until they are reversed by a counteracting policy setting or by editing the registry.
The following table summarizes the effects of policy settings and preferences.
| Group Policy present | Preference present | Resultant behavior |
|---|---|---|
No |
No |
Default |
No |
Yes |
The preference setting configures behavior. |
Yes |
No |
The policy setting configures behavior. |
Yes |
Yes |
The policy setting configures behavior. The preference setting is ignored. |
For the 2007 Office system, all user-specific policy settings are stored in the HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0 sub-key. Computer-specific policies are stored in the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\12.0 sub-key. By default, both policy sub-keys are locked to prevent users from modifying them.
Group Policy Management tools
Administrators use the following tools to administer Group Policy: Group Policy Management Console (GPMC) and Group Policy Object Editor Microsoft Management Console (MMC) snap-ins. Administrators use Group Policy Management Console for managing most Group Policy management tasks. Group Policy Object Editor is used for configuring policy settings in Group Policy objects.
Group Policy Management Console
GPMC simplifies the management of Group Policy by providing a single tool for managing 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, with the exception of configuring individual policy settings in Group Policy objects. This is done with Group Policy Object Editor. GPMC invokes Group Policy Object Editor. and you can use this tool from GPMC.
Administrators use GPMC to create a GPO with 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 within a GPO, an administrator edits the GPO from within GPMC. Group Policy Object Editor displays 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 what 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 their directory environment. Group Policy Modeling requires that you have at least one domain controller running Windows Server 2003, because this simulation is performed by a service running on a domain controller that is running Windows Server 2003. For more information, see Group Policy Modeling (https://go.microsoft.com/fwlink/?LinkId=82672) on the Microsoft TechNet Web site.
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. For more information, see Group Policy Results (https://go.microsoft.com/fwlink/?LinkId=82673) on the Microsoft TechNet Web site.
GPMC was originally provided as a separate download component for Microsoft Windows Server 2003 and Windows XP. To download GPMC, see Download Group Policy Management Console (GPMC) (https://go.microsoft.com/fwlink/?LinkId=58541) on the Microsoft Download Center Web site.
In Windows Vista and Windows Server 2008, GPMC is integrated directly into the operating system and is the standard tool for managing Group Policy tasks along with Group Policy Object Editor.
For more information about GPMC, see Step-by-Step Guide to Using Group Policy Management Console (https://go.microsoft.com/fwlink/?LinkId=75196) on the Microsoft TechNet Web site.
Group Policy Object Editor
Group Policy Object Editor is an MMC snap-in that is used to configure policy settings in Group Policy objects. The Group Policy Object Editor is contained in gpedit.dll, and is installed with Windows 2000, Windows XP, Windows Server 2003, and Windows Vista and Windows Server 2008 operating systems.
On computers running Windows 2000, Windows XP with the Windows Server 2003 Administration Tools Pack installed, and Windows Server 2003, you can access the Group Policy Object Editor from the Active Directory Users and Computers and Active Directory Sites and Services snap-ins.
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 running Windows Vista 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 provides administrators with a hierarchical tree structure for configuring Group Policy settings in GPOs. These GPOs can then be linked to sites, domains, and OUs that contain computer or user objects.
Group Policy Object Editor consists of two main nodes: User Configuration, which contains settings that are applied to users at logon and periodic background refresh, and Computer Configuration, which contains settings that are applied to computers at startup and periodic background refresh. The main nodes are further divided into folders that contain the different types of policy settings that can be set. These folders include:
Software Settings, which contains software installation settings
Windows Settings, which contains Security Settings and Scripts policy settings
Administrative Templates, which contains registry-based policy settings
For more information about Group Policy Object Editor, see Group Policy (pre-GPMC) (https://go.microsoft.com/fwlink/?LinkId=72742) on the Microsoft TechNet Windows Server 2003 site.
Office Customization Tool and Group Policy
Administrators can use two tools to customize user configurations for the 2007 Office system applications: Office Customization Tool (OCT) and Group Policy. Although both of these tools configure user settings, there are important distinctions.
The Office Customization Tool is 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 accessible portions of the registry, such as HKEY_CURRENT_USER/Software/Microsoft/Office/12.0. This tool is typically used in organizations that do not manage desktop configurations centrally. For more information, see Office Customization Tool in the 2007 Office system.
Group Policy is used to configure the 2007 Office system policy settings 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 organizational unit to which a Group Policy object is linked. True policy settings are written to the approved registry keys for policy, and these settings have ACL restrictions that prevent non-administrator users 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.
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Office Resource Kit information.