次の方法で共有

Deploying Group Policy Using Windows Vista

  • [アーティクル]

With the introduction of Windows® Vista™, you can now use Group Policy to centrally manage a greater number of features and component behaviors than were possible in Windows Server™ 2003. The number of Group Policy settings has increased from approximately 1,800 in Windows Server 2003 Service Pack 1 to approximately 2,500 in Windows Vista and Windows Server 2008. This gives you more than 700 new policies to help you manage desktops, security, and all other aspects of running your network. This document will help you sort through the new and updated features available in Windows Vista, and it provides a number of best practices to help you deploy Group Policy.

Introducing Group Policy

Group Policy allows you to work more efficiently because it enables centralized desktop management. Centrally managing desktops can decrease the total cost of ownership (TCO). Loss of end user productivity is one of the major costs when measuring TCO in a distributed computer environment. The following items contribute to loss of end user productivity:

  • User error: For example, modifying system files, which renders computers inoperable.

  • Complexity: Nonessential applications and features on the desktop that confuse some users or require additional training.

  • Unapproved Applications: Applications delivered in e-mail, downloaded, or transferred from removable media that may compromise the corporate network.

Group Policy helps reduce losses in productivity because it allows you to define policy settings and allowed actions for users and computers. Combining these policy settings creates desktops specific to a user's job responsibility and level of experience.

Group Policy applies not only to users and client computers, but also to member servers, domain controllers, and any other Microsoft Windows computers within the scope of management. By default, Group Policy that is applied to a domain (that is, applied at the domain level, just above the root of Active Directory Users and Computers) affects all computers and users in the domain.

Active Directory Users and Computers also provide a built-in Domain Controllers organizational unit. If you keep your domain controller accounts there, you can use the Group Policy object (GPO) Default Domain Controllers Policy to manage domain controllers separately from other computers. Expanding on the foundation established in Windows Server 2003 and Windows XP, Group Policy is improved with greater coverage of policy settings and extensions, better network awareness and reliability, and easier administration.

Defining Group Policy

You use Group Policy to define specific configurations for groups of users and computers, by creating Group Policy settings. These settings are specified through the Group Policy Management Console (GPMC) or the Local Group Policy Editor and contained in a GPO, which is in turn linked to Active Directory containers, such as sites, domains, or OUs. In this way, Group Policy settings are applied to the users and computers in those Active Directory containers. You can configure the users’ work environment once and rely on the system to enforce the policies as defined.

This approach results in Group Policy applying policy settings to users and computers in those Active Directory containers. You can configure the user's work environment once and rely on Windows Vista to enforce policy settings you defined.

Group Policy capabilities

You create specific policy settings that determine how Windows behaves and to keep users and computers secure. The following sections describe the key features of Group Policy.

Registry-based policy settings

Implementing registry-based policy settings is the most common form of policy setting in Windows. You can define registry-based policy settings for applications and Windows using the GPMC and the Local Group Policy Editor. For example, you can enable a policy setting that adds the Run command to the Start menu for all affected users, in Windows Vista.

Security settings

Group Policy provides options for you to set security options for computers and users within the scope of a GPO. You can specify security settings for the local computer, domain, and network. For added protection, you can apply software restriction policies that prevent users from running files based on the path, URL zone, hash, or publisher criteria. You can make exceptions to this default security level by creating rules for specific software.

Software restrictions policy settings

To defend against viruses, unwanted applications, and attacks on computers running Windows XP and Windows Server 2003, Group Policy includes new software restriction policy settings. You can now use policy settings to identify software running in a domain and control its ability to execute.

Software distribution

You can manage application installation, updates, and removal centrally with Group Policy. Because organizations can deploy and manage customized desktop configurations, they spend less money supporting users on an individual basis. Software can be either assigned to users or computers (mandatory software distribution) or published to users (allowing users to optionally install software through Add or Remove Programs in the Control Panel). Users get the flexibility they need to do their jobs without spending time configuring their system on their own.

You can use Group Policy to deploy approved packages. For example, in a highly managed desktop environment where users do not have permission to install applications, the Windows Installer service will perform an installation on the user's behalf. In addition, for highly managed workstations, Windows Installer integrates with the software restriction policy settings implemented through Group Policy to restrict new installations to a list of acceptable software.

Computer and user scripts

You can use scripts to automate tasks at computer startup and shutdown and user logon and logoff. Any language supported by Windows Script Host, including the VBScript, JavaScript, PERL, and MS-DOS®-style batch files (.bat and .cmd).

Folder Redirection

Folder Redirection allows you to redirect important user folders, such as the Documents folder and Users folder, to a server-based location. Folder Redirection provides centralized management of these folders and gives you the capability to easily back up and restore these folders on behalf of users.

Internet Explorer maintenance

You can manage and customize the configuration of Microsoft Internet Explorer on computers that support Group Policy. The GPMC and the Local Group Policy Editor include the Internet Explorer Maintenance node, which you use to edit Internet Explorer security zones, privacy settings, and other parameters on a computer running Windows 2000 and later.

What’s New in Windows Vista Group Policy

In Windows Vista, enhancements to Group Policy significantly improve the ability to plan, stage, deploy, manage, troubleshoot, and report on Group Policy implementations. This section describes some of the key new features in Group Policy.

Deploying power management settings

All power management settings have been Group Policy enabled, providing a potentially significant cost savings. Controlling power settings through Group Policy saves organizations a significant amount of money. You can modify specific power settings through individual Group Policy settings or build a custom power plan that is deployable by using Group Policy.

Restricting device access

You can centrally restrict devices from being installed on computers in their organization. You will now be able to create policy settings to control access to devices such as USB drives, CD-RW drives, DVD-RW drives, and other removable media.

Improvements to security settings

The Windows Firewall and IPsec Group Policy settings are combined into the Windows Firewall with Advanced Security Extension to allow you to leverage the advantages of both technologies, while eliminating the need to create and maintain duplicate functionality. Some scenarios supported by these combined Windows Firewall and IPsec policy settings are secure server-to-server communications over the Internet, limiting access to domain resources based on trust relationships or health of a computer, and protecting data communication to a specific server to meet regulatory requirements for data privacy and security.

Expanded Internet Explorer settings management

You can open and edit Internet Explorer Group Policy settings without the risk of inadvertently altering the state of the policy setting based on the configuration of the administrative workstation. This change replaces earlier behavior in which some Internet Explorer policy settings would change based on the policy settings enabled on the administrative workstation used to view the settings.

Assigning printers based on location

The ability to assign printers based on location in the organization or a geographic location is a new feature in Windows Vista. When mobile users move to a different location, Group Policy can update their printers for the new location. Mobile users returning to their primary locations see their usual default printers.

Delegating printer driver installation to users

You can now delegate to users the ability to install printer drivers by using Group Policy. This feature helps to maintain security by limiting distribution of administrative credentials.

Summary of new or expanded Group Policy settings

To review a table that summarizes new or expanded categories of Group Policy settings, see https://go.microsoft.com/fwlink/?LinkId=54020.

Scope of Group Policy tools

The Local Group Policy Editor and Group Policy Management Editor

The Local Group Policy Editor and the Group Policy Management Editor are used for configuring and modifying Group Policy settings within a single GPO. The Local Group Policy Editor is used to edit Local Group Policy Objects (LGPOs). The Group Policy Management Editor, which is available from within the GPMC, can be used to edit domain-based policy objects. For information about the GPMC, see the next section.

Each Windows Vista operating system has one or more LGPOs. The policy settings are applied to the LGPO manually with the Local Group Policy Editor. LGPOs contain fewer policy settings than domain-based GPOs, particularly under security settings. Also, the Local Group Policy Editor does not provide support for managing Group Policy Preferences. LGPOS do not support Folder Redirection, Windows Deployment Services, or Group Policy Software Installation.

Administrators also need to be able to quickly modify Group Policy settings for multiple users and computers throughout a network environment. The GPMC and the Local Group Policy Editor provide you with a hierarchical tree structure for configuring Group Policy settings in a GPO. The GPMC enables administrators to link GPOs to sites, domains, and organizational units (OU) containing computer or user objects.

The GPMC and the Local Group Policy Editor consist of two main sections: User Configuration, which holds settings that apply to users (at logon and periodic background refresh), and Computer Configuration, which holds settings that apply to computers (at startup and periodic background refresh). These sections are further divided into the different types of policies that can be set, such as Administrative Templates, Security, or Folder Redirection.

To work efficiently, you need to have immediate access to information about the function and purpose of individual policy settings. For Administrative Templates policy settings, the GPMC and the Local Group Policy Editor provide information about each policy setting directly in the Web view of the console. This information is called Explain text. Explain text shows operating system requirements, defines the policy setting, and includes any specific details about the effect of enabling, disabling, or not configuring the policy setting.

The GPMC

To edit domain-based policy, you can use the GPMC. The GPMC is a comprehensive administrative tool for Group Policy management that provides unified management of all aspects of Group Policy across multiple forests in an organization. You can use the GPMC to manage all GPOs, Windows Management Instrumentation (WMI) filters, and Group Policy–related permissions in your network. Think of the GPMC as your primary access point to Group Policy, with all the Group Policy management tools available from the GPMC interface.

The GPMC integrates the existing Group Policy functionality of the Property pages on the Active Directory administrative tools into a single, unified console dedicated to Group Policy management tasks. You will still use Active Directory administrative tools to manage Active Directory, but the GPMC replaces the Group Policy management functionality of those tools with its own.

If you are running Windows Vista with no service packs installed, the GPMC is included with the operating system. Upgrading to Windows Vista with Service Pack 1 removes the GPMC. To reinstall the GPMC, install the Remote Server Administration Tools (RSAT) for Windows Vista with SP1. For information about RSAT, see Description of RSAT for Windows Vista SP1 (Knowledge Base article 94131

Managing desktops in a mixed environment

Group Policy management on Vista

Microsoft Windows Vista introduces a new format for defining registry-based policy settings. Registry-based policy settings (located under the Administrative Templates category in the GPMC and the Local Group Policy Editor) are defined using a standards-based, XML file format known as ADMX files. These new files replace ADM files, which used their own markup language. One of the key benefits of ADMX files is the support for multilingual environments, which are not easily implemented with ADM files. The Group Policy tools—the GPMC and the Local Group Policy Editor—remain largely unchanged except that they have the ability to read the new ADMX files. In the majority of situations, you will not notice the presence of ADMX files during your day-to-day Group Policy administration tasks.

Some situations require an understanding of how ADMX files are structured and the location where they are stored. The Group Policy tools included with Windows Vista or Windows Server 2008 will recognize both ADMX and ADM files. The Group Policy tools included with Windows Server 2003 and earlier versions of Windows will recognize only ADM files.

Unlike ADM files, ADMX files are not stored in individual GPOs. For domain-based enterprises, you can optionally create a central store location of ADMX files that is accessible to anyone with permission to create or edit GPOs. Group Policy tools will continue to recognize custom ADM files associated with existing GPOs, but will ignore any ADM file that has been superseded by ADMX files: System.adm, Inetres.adm, Conf.adm, Wmplayer.adm, and Wuau.adm.

The GPMC and the Local Group Policy Editor automatically read and display Administrative Template policy settings based on ADMX files that are stored either locally or in the optional ADMX central store. The GPMC and the Local Group Policy Editor will automatically display Administrative Template policy settings defined in custom ADM files stored in the GPO. You can still add or remove custom ADM files to a GPO with the Add/Remove template menu option. All Group Policy settings currently in ADM files delivered by Windows Server 2003, Windows XP, and Windows 2000 will also be available in Windows Vista and Windows Server 2008 ADMX files.

The implications of ADMX files in a mixed desktop environment

If you are an administrator in an organization with a mixed desktop environment running Windows Vista, Windows XP, and Windows 2000, then you will need to be aware of the new Group Policy settings. Windows Vista Group policy settings work only on Windows Vista and are ignored on earlier versions of Windows.

  • New Windows Vista–based or Windows Server 2008–based policy settings can be managed only from Windows Vista–based or Windows Server 2008–based administrative computers running the GPMC and the Local Group Policy Editor. Such policy settings are defined only in ADMX files and are not exposed on the Windows Server 2003, Windows XP, or Windows 2000 versions of these tools. An administrator will need to use the GPMC and the Local Group Policy Editor from a Windows Vista–based or Windows Server 2008–based administrative computer to configure new Windows Vista–based Group Policy settings.

  • Group Policy Object Editor on Windows Server 2003, Windows XP, or Windows 2000 computers will not correctly display new Windows Vista Administrative Template policy settings that may be enabled or disabled within a GPO. Instead, the registry values associated with these policy settings will be displayed under "Extra registry settings" in Group Policy Object Editor.

  • The Windows Vista version of the GPMC and the Local Group Policy Editor can be used to manage all operating systems that support Group Policy (Windows Vista, Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000).

  • Administrative Template policy settings that currently exist in ADM files from Windows Server 2003, Windows XP, and Windows 2000 can be configured from all operating systems that support Group Policy (Windows Vista, Windows Server 2003, Windows XP, and Windows 2000).

  • The Windows Vista version of the GPMC and the Local Group Policy Editor supports interoperability with versions of these tools on Windows Server 2003 and Windows XP. For example, custom ADM files stored in GPOs will be consumed by the GPMC and the Local Group Policy Editor on Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP. See Table 1.

The Windows Vista version of the GPMC and the Local Group Policy Editor supports interoperability with versions of Group Policy Object Editor on Windows Server 2000. For example, custom ADM files stored in GPOs will be used by Group Policy Object Editor on Windows Vista, Windows Server 2008, and Windows 2000. (The GPMC does not run on Windows 2000.)

In earlier operating systems, whenever you created a GPO, all the default Administrative Template files (ADM files) were stored in the GPO. The storage cost was approximately 4 MB per GPO. Replication traffic would spike during events that caused all GPOs to be changed, such as modifying permissions on GPOs during an upgrade from a Windows 2000 domain to a Windows Server 2003 domain. This situation caused all ADM files across GPOs to replicate at once, which can impact network bandwidth availability and performance.

This process is replaced in Windows Vista and Windows Server 2008 with a central store on SYSVOL, containing the new ADMX files. Unlike earlier versions of Windows, GPOs created using Windows Vista do not each contain ADMX files. This change means less data replication over the more efficient DFS Replication Service.

As long as all Group Policy administrators use the Windows Vista client, new GPOs will not contain either ADM or ADMX files inside the GPO. The result of this change is a savings of about 4 MB per GPO. After the enterprise is updated to use the new DFS Service, the information that is contained in the GPO replicates, using the DFS Replication Service that only replicates the differences in the GPO. These two changes will greatly reduce the amount of storage and network bandwidth needed after the Group Policy administrator changes a GPO.

Table 1 Behaviors of the GPMC for Windows Vista and for Earlier Versions of Windows

Behavior The GPMC for Windows Vista The GPMC for Earlier Versions of Windows

Can manage Windows Server 2003, Windows XP, and Windows 2000

Yes

Yes

Can manage Windows Vista and Windows Server 2008

Yes

No

Multilingual support

Yes

No

Can read custom ADM files

Yes

Yes

Default location of files

Local

GPO

Can use central store

Yes

No

Avoids duplicated files in the GPO (SYSVOL bloat)

Yes

No

Option to add GPO-specific files (Add/Remove templates)

ADM files only

ADM files only

File comparisons

Version number

Timestamp

Best Practices

Windows Vista introduces more than 800 new Group Policy settings to the Windows environment. This section provides the information needed to apply Group Policy settings from Windows XP to Windows Vista, explaining basic administration concepts and describing the best practices to use when administering security policy.

Recommended rollout
  1. Upgrade the Group Policy administrators' workstations to Windows Vista. All Group Policy management will now be done from the computers running Windows Vista.

  2. (Optional) Create a Central Store on SYSVOL for each Active Directory Primary     Domain Controller (PDC), where Group Policy is managed by administrators running Windows Vista. Populate the Central Store on each PDC with ADMX/ADML files from the Group Policy administrator's Windows Vista workstation. Read the Managing Group Policy ADMX Files Step-by-Step Guide at https://go.microsoft.com/fwlink/?LinkId=75124.

  3. Create new GPOs (or update the existing GPOs) to include the new Windows Vista Group Policy settings you may wish to use.

    Note
    You might want to link these GPOs to the OU that will contain new Windows Vista domain-joined workstations.

    Note

    In rare cases, you might need to extend the Active Directory schema to accommodate the new settings.

  4. Deploy Windows Vista workstations per the deployment project.

    Note

    New or updated GPOs will apply to to Windows Vista workstations as appropriate.

Create a central store

The central store is a folder structure created in the SYSVOL directory on the domain controllers in each domain. You will need to create the central store only once on a single domain controller for each domain in your organization. The File Replication service then replicates the central store to all domain controllers. It is recommended that you create the central store on the domain controller acting as the Primary Domain Controller Emulator FSMO role because the GPMC and the Local Group Policy Editor connect to the primary domain controller by default.

The central store consists of a root-level folder containing all language-neutral ADMX files and subfolders containing the language-specific ADMX resource files.

Note

When there is no central store, the GPMC and the Local Group Policy Editor read the local versions of the ADMX files used by the local GPO on your Windows Vista administrative computer. To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

To create a central store

  1. Create the root folder for the central store %systemroot%\sysvol\domain\policies\PolicyDefinitions on your domain controller.

  2. Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use. Each subfolder is named after the appropriate ISO-style Language/Culture Name. For a list of ISO-style Language/Culture Names, see Locale Identifiers. For example, to create a subfolder for United States English, create the subfolder: %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US.

Populate the central store with ADMX files

There is no user interface for populating the central store in Windows Vista. The following procedure shows how to populate the central store using command line syntax from the domain controller.

To populate the central store

  1. Open a command window: Click Start, click Run, and type cmd, and then press ENTER.

  2. To copy all language-neutral ADMX files (.admx) from your Windows Vista administrative workstation to the central store on your domain controller using the copy command, type:

    copy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\

  3. To copy all ADMX language-specific resource files (.adml) from your Windows Vista administrative workstation to the central store on your domain controller using the copy command, type:

    copy %systemroot%\PolicyDefinitions\[MUIculture]\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\[MUIculture]\

For example, to copy all United States English .adml files, type the following:

copy %systemroot%\PolicyDefinitions\EN-US\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\EN-US\

Download new schemas

Windows Vista supports enhancements that can be configured through Group Policy settings, and those settings are supported by domain controllers running Windows Server 2008. To support these enhancements for an Active Directory service environment consisting of domain controllers running Windows Server 2003 or Windows Server 2003 R2, the Active Directory schema must be extended. For the information needed for the Active Directory schema extensions for Windows Vista wireless and wired Group Policy enhancements, see https://go.microsoft.com/fwlink/?LinkId=70195.

Note

Extending the schema is needed only if you need the wireless and wired Group Policy enhancements or if you need the BitLocker Group Policy enhancements.

For BitLocker schema changes, please refer to the Active Directory for BitLocker and TPM Backup Setup Guide in the BitLocker Active Directory Deployment Kit.

Additional best practices

Before beginning your rollout of Windows Vista Group Policy settings, be sure to read these guidelines and Windows Vista documents because they will give you a solid foundation in Group Policy settings.

Scripts for the GPMC

The GPMC includes a set of scripting interfaces for automating many common GPO management tasks. Using these scripting interfaces, you can manage the Group Policy environment, including generating reports of GPO settings, creating and copying GPOs, and finding unlinked GPOs. Windows Vista does not include any scripts. For more information about the GPMC scripts, see https://go.microsoft.com/fwlink/?linkid=31191

Multilanguage issues

In Windows Vista, Administrative Template settings are divided into language-neutral (.admx files) and language-specific resources (.adml files), available to all Group Policy administrators. These files allow Group Policy tools to adjust their UI according to the administrator's configured language. Adding a new language to a set of policy definitions is achieved by ensuring that the language-specific resource file is available.

For example, a Group Policy administrator creates a GPO from a Windows Vista administrative workstation configured for English. He saves the GPO and links it to the domain deployed across geographic boundaries. A colleague in Paris browses the same domain using the GPMC and selects the GPO created in English. She can view and edit the policy settings in French. The original Group Policy administrator who created this GPO will still see all the settings in his native language of English, including the changes from the French administrator.

Group Policy changes after migrating or upgrading to Windows Vista

After migrating or upgrading to Windows Vista, Group Policy is reapplied as if it were done on a clean installation. For clients in a Windows domain, Group Policy will be applied as if the computer had just joined the domain or as if the user had logged in for the first time. Each extension will either migrate its policy settings or apply these policy settings when applying Group Policy for the first time in the domain. After the upgrade, the Group Policy engine will process policy settings similar to a clean installation, regenerate all RSoP data, and set up all its cached values. The following table provides details of upgrading or migrating specific to each component.

Component Upgrade behavior Migration behavior

GP Engine

Preference keys and values related to core GP Engine (such as link speed) are migrated.

Not migrated.

RSoP

After the upgrade, no migration of RSoP data is required because all policy settings will be reapplied during the first restart.

Not migrated.

Local GPO
  • The local GPO is migrated.

  • The group MLGPO is migrated.

  • The user MLGPO is migrated.

    Note
    When upgrading different SKUs of Windows Vista, MLGPO data is migrated.
  • The local GPO is migrated.

  • The group MLGPO is migrated.

Client-side extensions

Client-side extensions preserve registration data in the registry. The extension registry keys are located at

HKLM\Software\

Microsoft\Windows NT\

CurrentVersion\Winlogon\

GPExtensions

Note

Each client-side extension upgrades its own information.

Not migrated.

ADM templates
  • Previously shipped ADM files are replaced with ADMX files.

  • Custom ADM files are preserved during upgrade.

Not migrated.

Registry-based policy settings
  • All policy settings and values under the Software\Policy registry key are migrated.

  • Preference settings are not migrated.

  • All of the policy settings are reapplied from the domain on first restart after first logon.

Not migrated.

Software installation
  • All applications installed through Group Policy are automatically migrated.

  • All files under %windir%\system32 \appmgmt are automatically migrated.

  • All keys and values are migrated under:

    • HKLM|HKCU Software \Microsoft\Windows \CurrentVersion\ Group Policy\Appmgmt

    • Value ‘appmgmtdebuglevel’ under HKLM\Software\ Microsoft\Windows NT \CurrentVersion\ Diagnostics

Not migrated.

The GPMC and GPEdit
  • Previous versions of GPMC are removed.

    • The scripts folder is preserved after upgrade, including any scripts for the GPMC hat were installed with the previous version of the GPMC.

  • The following configuration data for the GPMC will be migrated:

    • Information currently stored directly in the console file (msc) (such as last connected domain or forest)

    • Registry keys and preferences in the tool (Backup folder location, ADM file options, etc.).

  • For GPEdit, any preference keys, such as Default GPO name, are migrated.

Not migrated.

Note

For the list of registry keys moved by migration, see Appendix B.

Verifying Group Policy Settings—Resultant Set of Policy (RSoP)

All Group Policy processing information is collected and stored in a Common Information Model Object Management (CIMOM) database on the local computer. This information, such as the list, content, and logging of processing details for each GPO, can then be accessed by tools using Windows Management Instrumentation.

In logging mode (Group Policy Results), Resultant Set of Policy (RSoP) queries the CIMOM database on the target computer, receives information about the policies, and displays it in the GPMC. In planning mode (Group Policy Modeling), RSoP simulates the application of policy using the Group Policy Directory Access Service (GPDAS) on a domain controller. GPDAS simulates the application of GPOs and passes them to virtual client-side extensions on the domain controller. The results of this simulation are stored on a local CIMOM database on the domain controller before the information is passed back and displayed in the GPMC.

RSoP using the GPMC

An administrator uses the GPMC to manage Group Policy in an Active Directory environment. The GPMC offers the administrator a persistent view of the Group Policy environment on the network, including GPOs, GPO links, sites, domains, and organizational units (OU) in the selected forest. With the GPMC, an administrator can do any of the administrative tasks previously only available from the Group Policy tab of the Active Directory administrative tools.

The GPMC can also be used to generate RSoP data that either predicts the cumulative effect of GPOs on the network, or reports the cumulative effect of GPOs on a particular user or computer. In addition, the administrator can use the GPMC to perform GPO operations never possible before, like backing up and restoring a GPO, copying a GPO, or even migrating a GPO to another forest. Reading or generating HTML or XML reports of GPO settings is also possible using WMI scripts.

There are certain limitations when using the GPMC because it cannot retrieve the RSoP for Multiple Local Group Policy objects (MLGPOs) and the GPMC reports do not display Windows Firewall with advanced security settings.

Verifying actual policy settings currently in effect

The Resultant Set of Policy (RSoP) snap-in is a Microsoft Management Console (MMC) tool. Administrators use the RSoP snap-in to report and plan the cumulative effects of GPOs. Although you can use the RSoP snap-in for reporting and planning the effects of Group Policy, much of its functionality has been subsumed into the GPMC, which provides a much better experience for the network administrator. The RSoP snap-in has limitations because it does not report all settings (for example, it does not report many of the new Windows Vista settings), and it cannot retrieve the RSoP for a remote computer. Using the RSoP snap-in is not recommended, although it remains available in Windows Vista to collect RSoP data for third-party Group Policy extensions.

The GPMC reporting feature is the recommended tool to determine if policy is applying to a user or computer. However, the GPMC does not work with MLGPOs. Although you cannot use GPMC reporting for MLGPO, you can view this information in the Group Policy Operational Log.

Consumption of Windows Vista settings

Group Policy Scripts can fail due to User Account Control

The main goal of User Account Control (UAC) is to lessen the exposure and attack surface of the operating system. UAC does this by requiring all users to run in standard user mode. This limit minimizes the ability for users to make changes that could destabilize their computers or unintentionally expose the network to viruses through undetected malicious software (also called malware) that has infected their computer.

With UAC, you can run most applications, components, and processes with a limited privilege, but have "elevation potential" for specific administrative tasks and application functions. Windows accomplishes this by using two access tokens for each user: limited and elevated access tokens. Access tokens identify the user, the user's groups, and the user's privileges. The system uses access tokens to control access to securable objects and to control the ability of the user to perform various system-related operations on the local computer.

An elevated token, for a local administrator, includes and enables all of the administrative privileges. UAC requires local administrators to use their elevated token when attempting to perform a system-only task or administrative task. A limited token, for a local administrator, includes all of the administrative privileges; however, these privileges are disabled. This allows Windows to view the administrative user and a normal user, with the option to elevate their privileges.

By default, all users logging on to Windows Vista use their full token to process Group Policy and logon scripts. However, they use their limited user token to load the desktop and all subsequent processes. Nonadministrative limited and elevated tokens are mostly identical, with regard to privileges and groups. Therefore, a process started with a nonadministrative limited user token can view processes started with a nonadministrative elevated token. Windows allows this because the viewing application does not require any elevation to view the process started with the elevated token.

Windows processes a locally logging on administrator the same way. Group Policy and logon scripts process using the elevated user token, and the desktop and all subsequent processes use the limited token. However, there is a privilege difference between the limited and elevated user token. Therefore, Windows restricts processes started with a limited token from the ability to share information with processes started with the elevated token.

UAC may prevent Group Policy logon scripts from appearing to work properly. For example, a domain environment contains a GPO that includes a logon script to map network drives. A nonadministrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the nonadministrative user starts Windows Explorer. The user sees their mapped drives. Under the same environment, an administrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the administrative user starts Windows Explorer. The user does not see their mapped drives.

When the administrative user logs on, Windows processes the logon scripts using the elevated token. The script actually works and maps the drive. However, Windows blocks the view of the mapped network drives because the desktop uses the limited token while the drives were mapped using the elevated token.

To get around this issue, administrative users should map network drives under the limited user token. This mapping is accomplished by using the launchapp.wsf script shown in Appendix A, which works by scheduling the commands using the task scheduler. The task scheduler launches the script under the administrative full token, thereby allowing Windows Explorer, other limited token processes, and the elevated token process to view the mapped network drives.

To configure launchapp.wsf to postpone the execution of a logon script

  1. Copy the logon script and the launchapp.wsf script to a network share.

  2. Start the GPMC. In the GPMC, right-click the GPO you want to modify, and then click Edit.

  3. In the User Configuration node, expand Windows Settings, and then click Scripts.

  4. Right-click Logon, and then click Properties.

  5. In the Logon Properties dialog box, click Add.

  6. In the Script Name box, type launchapp.wsf

  7. In the Script Parameters box, type the full path and name to logon.bat

Group Policy service cannot be stopped

In Windows Vista, Group Policy is moved out of the Winlogon process and runs as a separate service. The Group Policy client is responsible for applying settings configured by administrators for the computer and users through the Group Policy component. In the Services snap-in, the options to start, stop, pause, and resume the Group Policy client are unavailable. This is because if the client service is stopped or disabled, the settings will not be applied, and applications and components will not be manageable through Group Policy. Any components or applications that depend on the Group Policy component might not be functional if the client service is stopped or disabled.

Policy Settings that require a reboot or logon

The registry-based Group Policy settings in this section require either a reboot or a logon when they are enabled. The bulleted items in this section contain the name of the Group Policy setting followed by its function.

Logon

  • Do not allow window animations: This policy setting controls the appearance of window animations such as those found when restoring, minimizing, and maximizing windows.

  • Do not allow desktop composition: This policy setting controls how some graphics are rendered, and facilitates other features, including Flip, Flip3D, and Taskbar Thumbnails.

  • Do not allow Flip3D invocation: This polciy setting disables the 3D window switcher.

  • Specify a default color: This policy setting controls the default color for window frames when the user does not specify a color.

  • Do not allow color changes: This policy setting controls the ability to change the color of window frames.

  • Verbose vs. normal status messages: This policy setting directs the system to display highly detailed status messages.

  • Set action to take when logon hours expire: This policy setting controls which action will be taken when the logon hours expire for the logged-on user.

  • Set action to take when logon hours expire: This policy setting controls which action will be taken when the logon hours expire for the logged-on user. The actions include lock the workstation, disconnect the user, or log the user off completely.

  • Report when logon server was not available during user logon: This policy controls whether the logged-on user should be notified if the logon server could not be contacted during logon, and the user has been logged on using previously stored account information.

  • Custom user interface: This policy setting specifies an alternate user interface.

Reboot

  • Turn off Tablet PC touch input: This policy setting turns off touch input, which allows the user to interact with their computer using their finger.

  • Turn off Windows Defender: This policy setting turns off Windows Defender Real-Time Protection, meaning no more scans are scheduled.

  • Turn off legacy remote shutdown interface: This policy setting controls the legacy remote shutdown interface (named pipe). Pipe remote is needed in order to shut down this system from a remote Windows Server 2003 or Windows XP system.

Folder Redirection interoperability

Window Vista provides many benefits when combined with roaming user profiles and Folder Redirection. Redirecting user data to a central network location reduces the size of the user profile, makes user data immediately available, and increases user logon and logoff performance by transferring less data. Combining Folder Redirection with roaming user profiles allows a user to share roaming data between Windows Vista and Windows XP computers.

Computers running Windows Vista cannot read roaming user profiles created from Windows XP. This creates a problem for users who have a roaming user profile but must roam from Windows Vista and Windows XP computers. Windows Vista Folder Redirection makes this possible.

Folder Redirection allows you to redirect all the well-known folders that ship in a Windows Vista user profile. This ability allows you to share a folder in your Windows XP user profile with a folder in your Windows Vista profile. For example, you can share the Favorites folder between Windows Vista and Windows XP. You redirect the Favorites folder in Windows Vista to the same location where the Windows XP synchronizes the Favorites folder in the roaming user profile.

Use Scenario 3 in the following white paper to create one or more Folder Redirection policies to allow users to share roaming user data with Windows Vista and Windows XP. The share path in the white paper is the share path to the user's roaming user folder.

For additional information, see: https://go.microsoft.com/fwlink/?LinkId=73435.

Network Access Protection and Network Location Awareness

Network Access Protection (NAP) is a policy enforcement platform for Windows Vista, Windows Server 2008,and Window XP that allows you to better protect network assets by enforcing compliance with system health requirements (for example, ensuring that the client has the latest operating system and antivirus updates installed). With NAP, you can create customized health policies to validate computer health before allowing access or communication, automatically update compliant computers to ensure ongoing compliance, and optionally confine noncompliant computers to a restricted network until they become compliant.

When a client computer attempts to access the network, it must present its system health state. If a client computer cannot prove it is compliant with system health policy, its access to the network will be limited to a restricted network segment containing server resources so compliancy issues can be remedied. After the updates are installed, the client computer requests access to the network again. If compliant, the client computer is granted unlimited access.

Keep in mind that NAP is not a security solution. It is designed to help prevent computers with unsafe configurations from connecting to a network—not to protect networks from malicious users who have valid sets of credentials and computers that meet current health requirements.

On the client computer side, the Network Location Awareness (NLA) feature enables the system to receive notifications when connectivity to the domain controller is established, and the Group Policy service makes a determination whether to apply policy settings for that event. However, NLA does not recognize the transition from a quarantine environment (in other words, a NAP environment) to a corporate environment; therefore, NLA will not provide Group Policy with network notifications when the computer comes out of quarantine.

Because NLA does not provide notifications for successful network connectivity after quarantine, the following workaround can be provided. The NAP component records an event in the log files. The administrator needs to write a script that will detect this event, which calls gpupdate to ensure that Group Policy is refreshed during a successful VPN connection.

By leveraging NLA, Window Vista is more responsive to network changes, and there is no longer a delay of up to 90 minutes before Group Policy is refreshed. If the previous policy setting application cycle was skipped (or failed), then Group Policy retries when network connectivity to the Domain Controller is available. This is a key improvement over earlier versions of Group Policy because the Group Policy dependence on ICMP is removed.

Managing Windows Vista features using Group Policy

Windows Vista has many new features that can be managed with Group Policy, including power management, device installation and usage, and security settings. Here is a list of step-by-step guides that will help you configure these features.

List of policy settings

The Group Policy Settings Reference Spreadsheet for Windows Server 2008 and Windows Vista SP1 lists the policy settings for computer and user configurations included in the administrative template files (admx/adml) delivered with Windows Server 2008 and Windows Vista SP1. The policy settings included in this spreadsheet cover Windows Vista RC1, Microsoft Windows Server 2003, Windows XP Professional, and Windows 2000. For information, see Group Policy Settings Reference Spreadsheet for Windows Server 2008 and Windows Vista SP1

Troubleshooting Group Policy

To troubleshoot Group Policy, you need to understand the interactions between Group Policy and its supporting technologies (such as Microsoft® Active Directory® directory service and the File Replication service [FRS]), and the ways that the GPOs themselves are managed, deployed, and applied. With that understanding, you can use specific tools to find answers that will help you to identify and resolve problems.

The Group Policy infrastructure has changed significantly in Windows Vista. Group Policy processing no longer exists within the Winlogon process, but is hosted as its own service. Additionally, the Group Policy engine no longer relies on the trace logging found in userenv.dll. As a result, there is no longer a userenv log file.

Much of the troubleshooting for Group Policy in earlier versions of Windows relied on logging being enabled inside the component userenv.dll. This created a log file named userenv.log in the %WINDIR%\Debug\Usermode folder. This log file contained function trace statements with supporting data. In addition, profile load and unload functions shared this log file, making the log sometimes difficult to diagnose. This log file, used in conjunction with the Resultant Set of Policy Microsoft Management Console (RSoP MMC) was the primary way to diagnose and resolve Group Policy problems.

In Windows Vista, Group Policy is treated as its own component with a new Group Policy Service, a stand-alone service that runs under the Svchost process for the purpose of reading and applying Group Policy. The new service includes changes with event reporting. Group Policy event messages, previously appearing in the application log, now appear in the system log. The event viewer lists these new messages with an event source of Microsoft-Windows-GroupPolicy. The Group Policy Operational log replaces previous userenv logging. The operational event log provides improved event messages specific to Group Policy processing.

For additional troubleshooting tips, see the Windows Vista Group Policy Troubleshooting Guide at:

https://go.microsoft.com/fwlink/?LinkId=74139

Appendix A: Launchapp.wsf

<job>

<script language="VBScript">

'---------------------------------------------------------

' This sample launches the application as interactive user.

'---------------------------------------------------------

' A constant that specifies a registration trigger.

const TriggerTypeRegistration = 7

' A constant that specifies an executable action.

const ActionTypeExecutable = 0

' A constant that specifies the flag in RegisterTaskDefinition.

const FlagTaskCreate = 2

' A constant that specifies an executable action.

const LogonTypeInteractive = 3

If WScript.Arguments.Length <> 1 Then

WScript.Echo "Usage: cscript launchapp.wsf <AppPath>"

WScript.Quit

End If

strAppPath = WScript.Arguments(0)

'********************************************************

' Create the TaskService object.

'********************************************************

Set service = CreateObject("Schedule.Service")

call service.Connect()

strTaskName = "Launch App As Interactive User"

'********************************************************

' Get a folder to create a task definition in.

'********************************************************

Dim rootFolder

Set rootFolder = service.GetFolder("\")

'Delete the task if already present

On Error Resume Next

call rootFolder.DeleteTask(strTaskName, 0)

Err.Clear

'********************************************************

' Create the new task

'********************************************************

Dim taskDefinition

Set taskDefinition = service.NewTask(0)

'********************************************************

' Create a registration trigger.

'********************************************************

Dim triggers

Set triggers = taskDefinition.Triggers

Dim trigger

Set trigger = triggers.Create(TriggerTypeRegistration)

'***********************************************************

' Create the action for the task to execute.

'***********************************************************

' Add an action to the task. The action executes the app.

Dim Action

Set Action = taskDefinition.Actions.Create( ActionTypeExecutable )

Action.Path = strAppPath

WScript.Echo "Task definition created. About to submit the task..."

'***********************************************************

' Register (create) the task.

'***********************************************************

call rootFolder.RegisterTaskDefinition( _

strTaskName, taskDefinition, FlagTaskCreate, _

,, LogonTypeInteractive)

WScript.Echo "Task submitted."

</script>

</job>

Appendix B: List of registry keys, values, and files moved by migration

After migrating to Windows Vista, Group Policy is reapplied as if it were done on a clean installation. For clients in a Windows domain, Group Policy will be applied as if the computer had just joined the domain; this also applies to client-side extensions. Each extension will either migrate its settings or apply the settings when applying Group Policy for the first time in the domain. After the upgrade, the Group Policy engine will process policy settings similar to a clean installation, regenerate all RSoP data, and set up all its cached values. The following list contains the registry keys that are migrated by Windows Vista.

GPedit

            <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy Editor\* [*]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [GPEditDebugLevel]</pattern>

GPBase

            <pattern type="File">%windir%\system32\GroupPolicy\*[*]</pattern>

            <pattern type="File">%windir%\system32\GroupPolicyUsers\*[*]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [HideStartupScripts]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [HideShutdownScripts]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [RunStartupScriptSync]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [GpNetworkStartTimeoutPolicyValue]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [DenyUsersFromMachGP]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [DisableBkGndGroupPolicy]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [SyncForegroundPolicy]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [DisableLGPOProcessing]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [DenyRsopToInteractiveUser]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [RSoPGarbageCollectionInterval]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [GroupPolicyMinTransferRate]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [WaitForNetwork]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [UserenvDebugLevel]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [RsopDebugLevel]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics [gpsvcDebugLevel]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics [RunDiagnosticLoggingGlobal]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics [RunDiagnosticLoggingGroupPolicy]</pattern>

            <pattern type="Registry">HKLM\Software\Policies\* [*]</pattern>

            <pattern type="Registry">HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\* [*]</pattern>

            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [HideLogonScripts]</pattern>

            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [HideLogoffScripts]</pattern>

            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [RunLogonScriptSync]</pattern>

            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon [GroupPolicyMinTransferRate]</pattern>

            <pattern type="Registry">HKCU\Software\Policies\* [*]</pattern>

            <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\* [*]</pattern>

GPMC

            <pattern type="Registry">HKCU\Software\Microsoft\Group Policy Management Console\* [*]</pattern>

          <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics [gpmgmttracelevel]</pattern>

          <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics [gprsoptracelevel]</pattern>

Software Installation

           <pattern type="File">%windir%\system32\appmgmt\*[*]</pattern>

    <pattern type="Registry">HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Appmgmt\* [*]</pattern>

           <pattern type="Registry">HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics [appmgmtdebuglevel]</pattern>

           <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Appmgmt\* [*]</pattern>