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.

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.

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.

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.

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.

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 (http://go.microsoft.com/fwlink/?LinkId=80435) on the Microsoft TechNet site.

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

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.

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 (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 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 (http://go.microsoft.com/fwlink/?LinkId=80462) on the Microsoft TechNet site.

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.

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 (http://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.

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.