Group Policy Collection

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Group Policy Collection

Group Policy is an infrastructure that allows you to implement specific configurations for users and computers. Group Policy settings are contained in Group Policy objects (GPOs), which are linked to the following Active Directory directory service containers: sites, domains, or organizational units (OUs). The settings within GPOs are then evaluated by the affected targets, using the hierarchical nature of Active Directory. Consequently, Group Policy is one of the top reasons to deploy Active Directory because it allows you to manage user and computer objects. Group Policy is one of a group of management technologies, collectively known as IntelliMirror management technologies, which provide users with consistent access to their applications, application settings, roaming user profiles, and user data, from any managed computereven when they are disconnected from the network. IntelliMirror is implemented through a set of Microsoft Windows features, including Active Directory, Group Policy, Software Installation, Windows Installer, Folder Redirection, Offline Folders, and Roaming User Profiles. This collection includes detailed information about each of the following areas of Group Policy:

Core Group Policy Group Policy Components Group Policy Administrative Tools

This page introduces Group Policy management concepts and architecture, summarizes the areas included in the Group Policy collection, and describes Group Policy scenarios.

Group Policy Management

Administrators face increasingly complex challenges in managing the IT infrastructure. You must deliver and maintain customized desktop configurations for more types of workers such as mobile users, information workers, or others assigned to strictly defined tasks, such as data entry. Security settings and updates must be delivered efficiently to all the computers and devices in the organization. New users need to be productive quickly without costly training. In the event of a computer breakdown or disaster, service must be restored with a minimum of data loss and interruption. All of these tasks, known collectively as Change and Configuration Management, must be achieved at the lowest possible cost. You need to be able to implement change quickly and affect large numbers of users and computers. Group Policy is the infrastructure that allows you to implement change on the object level in Active Directory. You need to be able to define configurations once and rely on the operating system to enforce that state. With Active Directory, GPOs can be linked to sites, domains, and OUs, allowing Group Policy settings to be applied to users and computers. In addition, GPOs can be used to help manage server computers, through many serverspecific operational and security settings. This infrastructure provides a high degree of flexibility, allowing you to customize configurations, such as delivering a specific piece of software to specialized users based on their membership in an OU. In addition, the Group Policy Management Console (GPMC) simplifies implementation and management of Group Policy.

Group Policy Architecture

Group Policy uses a document-centric approach to creating, storing, and associating Group Policy settings. Similar to the way in which Microsoft Word stores information in .doc files, Group Policy settings are contained in GPOs. A GPO is a virtual object; policy-setting information is stored in two locations: the Active Directory container to which the GPO is linked, and the Sysvol on the domain controller. Group Policy is configured primarily through the use of two tools: Group Policy Object Editor, (previously known as the Group Policy snap-in, Group Policy Editor, or Gpedit) and Group Policy Management Console (GPMC), available for download from the Microsoft Web site. Whereas Group Policy Object Editor is used to configure and modify settings within GPOs, GPMC is used to create, view, and manage GPOs. Group Policy architecture is shown in the following diagram, which shows how the primary components interact through read or write access. Components are described in the figure below.

Group Policy Architecture

Group Policy Components

Component Server (Domain Controller) Active Directory

Description In an Active Directory forest, the domain controller is a server that contains a writable copy of the Active Directory database, participates in Active Directory replication, and controls access to network resources. Active Directory, the Windows-based directory service, stores information about objects in a network and makes this information available to users and network administrators. Administrators link GPOs to Active Directory containers such as sites, domains, and OUs that include user and computer objects. In this way, Group Policy settings can be targeted to users and computers throughout the organization. A GPO is a collection of Group Policy settings, stored at the domain level as a virtual object consisting of a Group Policy container (GPC) and a Group Policy template (GPT). The GPC, which contains information on the properties of a GPO, is stored in Active Directory on each domain controller in the domain. The GPT contains the data in a GPO and is stored in the Sysvol in the /Policies sub-directory. GPOs affect users and computers that are contained in sites, domains, and OUs. Sysvol is a shared directory that stores the server copy of the domains public files, which are replicated among all domain controllers in the domain. The Sysvol contains the data in a GPO: the GPT, which includes Administrative Template-based Group Policy settings, security settings, script files, and information regarding applications that are available for software installation. It is replicated using the File Replication Service (FRS). The local Group Policy object (local GPO) is stored on each individual computer, in the hidden %systemroot%\System32\GroupPolicy directory. Each computer running Windows 2000, Windows XP Professional, Windows XP 64-Bit Edition, Windows XP Media Center Edition, or Windows Server 2003 has exactly one local GPO, regardless of whether the computers are part of an Active Directory environment. Local GPOs do not support certain extensions, such as Folder Redirection or Group Policy Software Installation. Local GPOs do support many security settings, but the Security Settings extension of Group Policy Object Editor does not support remote management of local GPOs. Local GPOs are always processed, but are the least influential GPOs in an Active Directory environment, because Active Directory-based GPOs have precedence. Although you can configure local GPOs on individual computers, the full power of Group Policy

Group Policy object (GPO)

Sysvol

Local Group Policy object

can only be realized in a Windows Server network with Active Directory installed. In addition, some features and Group Policy settings require client computers running Windows XP. Group Policy Object Editor Server-Side Snap-Ins Group Policy Object Editor is a Microsoft Management Console (MMC) snap-in that is used to edit GPOs. It was previously known as the Group Policy snap-in, Group Policy Editor, or Gpedit. The MMC snap-in is loaded, by default, in Group Policy Object Editor. Server-side snap-in extensions provide the user interface to allow you to configure various policy settings while client-side extensions implement the actual policy settings on target client computers. Snap-in extensions include Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, Internet Explorer Maintenance, Disk Quotas, Wireless Network Policy, and QoS Packet Scheduler. Snap-ins may in turn be extended. For example, the Security Settings snap-in includes several extension snap-ins. Developers can also create their own MMC extension snap-ins to Group Policy Object Editor to provide additional Group Policy settings. Client-side extensions (CSEs) run within dynamic-link libraries (DLLs) and are responsible for implementing Group Policy at the client computer. The following CSEs are loaded, by default, in Windows Server 2003: Administrative Templates, Wireless Network Policies, Folder Redirection, Disk Quotas, QoS Packet Scheduler, Scripts, Security, Internet Explorer Maintenance, EFS Recovery, Software Installation, and IP Security. GPMC is a new tool designed to simplify implementation and management of Group Policy. It consists of a new MMC snap-in and a set of scriptable interfaces for managing Group Policy. The Group Policy Management Console provides:

Client-Side Extensions

Group Policy Management Console (GPMC)

A user interface based on how customers use and manage Group Policy, rather than on how the technology is built. Import/Export, Copy/Paste, and searching of GPOs. Simplified management of Group Policy-related security.

Reporting (printing, saving, read-only access to GPOs) for GPO and Resultant Set of Policy (RSoP) data. Backup/Restore of GPOs.

Scripting of GPO operations that are exposed within this tool (but NOT scripting of settings within a GPO). Resultant Set of Policy (RSoP) snap-in Winlogon Group Policy engine File System Registry The Resultant Set of Policy (RSoP) snap-in is an MMC snap-in that that simplifies Group Policy implementation and troubleshooting. RSoP uses Windows Management Instrumentation (WMI) to determine how Group Policy settings are applied to users and computers. For RSoP functionality, it is recommended to use the reporting features in GPMC. A component of the Windows operating system that provides interactive logon support, Winlogon is the service in which the Group Policy engine runs. The Group Policy engine is the framework that handles common functionalities across client-side extensions including scheduling of Group Policy application, obtaining GPOs from relevant configuration locations, and filtering and ordering of GPOs. The NTFS file system on client computers. A database repository for information about a computers configuration, the registry contains information that Windows continually references during operation, such as: 1. Profiles for each user.

2. The programs installed on the computer and the types of documents that each can create. 3. Property settings for folders and program icons.

4. 5.

The hardware on the system. Which ports are being used.

The registry is organized hierarchically as a tree, and it is made up of keys and their subkeys, hives, and entries. The Group Policy engine has read and write access to the Registry. Registry settings can be controlled via the Group Policy Administrative Templates extension. Event Log The Event log is a service, located in Event Viewer, which records events in the system, security, and application logs. The Group Policy engine has write access to the Event Log on client computers and domain controllers. The Help and Support Center on each computer has read access to the Event Log. The Help and Support Center is a component on each computer that provides HTML reports on the Group Policy settings currently in effect on the computer. 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 WMI. In logging mode (Group Policy Results), RSoP queries the CIMOM database on the target computer, receives information about the policies and displays it in 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 to a local CIMOM database on the domain controller before the information is passed back and displayed in GPMC. WMI is a management infrastructure that supports monitoring and controlling of system resources through a common set of interfaces and provides a logically organized, consistent model of Windows operation, configuration, and status. WMI makes data about a target computer available for administrative use. Such data can include hardware and software inventory, settings, and configuration information. For example, 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. WMI Filtering in Windows Server 2003 allows you to create queries based on this data. These queries (also called WMI filters) determine which users and computers receive all of the policy configured in the GPO where you create the filter.

Help and Support Center Resultant Set of Policy (RSoP) infrastructure

WMI

Core Group Policy

This subject explains Group Policy infrastructure including how the Group Policy engine controls policy processing, including retrieval of GPOs, invocation of individual extensions, and other infrastructure functionality.

Group Policy Components

The Group Policy Components subcollection describes the role of extensions including server-side snap-in extensions and client-side extensions. These extensions include: Administrative Templates, Software Installation, Security Settings, Scripts, Remote Installation Services, Internet Explorer Maintenance, Folder Redirection, QoS Packet Scheduler, Disk Quotas, and Wireless Network Policies.

Group Policy Administrative Tools

This subcollection explains administrative tools including the Group Policy Object Editor, Group Policy Management Console, and the Resultant Set of Policy (RSoP) snap-in.

Group Policy Scenarios

Group Policy is used to define configurations for groups of users and computers. With Group Policy, you can specify specific configurations for a wide range of areas including Administrative Templates (registry-based policies), security, software installation, scripts, folder redirection, remote installation services, and Internet Explorer maintenance. Group Policy settings are contained in a GPO. By associating a GPO with selected Active Directory system containerssites, domains, and organizational unitsthe GPO's Group Policy settings are applied to the users and computers in those Active Directory containers. This section provides an overview of what you can do with Group Policy. Managing Desktops, Applications, and Components with Registry-Based Policies Administrative Templates (or .adm files) enable you to control registry settings using Group Policy, providing the means to configure the behavior and appearance of the desktop, including the operating system, components, and

applications. Windows comes with a predefined set of Administrative template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a GPO. These .adm files are stored in two locations by default: inside GPOs in the Sysvol folder and in the %windir%\inf directory on the local computer. Managing Security Group Policy is used to manage the following types of securityoptions for users, clients, servers, and domain controllers:

Security settings. These Group Policy settings are used to define values for various security-relevant operating system parameters, such as password policy, user rights assignment, audit policy, registry values, file and registry ACLs, and service startup modes. IPSec policies. These Group Policy settings are used to configure IPSec services for authenticating or encrypting network traffic. An IPSec policy consists of a set of security rules, and each security rule consists of an IP filter with an action. Software restriction policies. These Group Policy settings are used to help protect computers from code that is not trusted by identifying and specifying which applications are permitted to run. Wireless network policies. These Group Policy settings are used to configure settings for the Wireless Configuration Service, a user-mode service that operates on each of the IEEE 802.11 wireless network adapters that are installed on a computer. Public Key Policies. These Group Policy settings are used to:

Specify that computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate. Create and distribute a certificate trust list. Establish common trusted root certification authorities. Add encrypted data recovery agents and change the encrypted data recovery policy settings.

Implementing Group Policybased Software Installation The Software Installation snap-in is used to centrally manage software. Software can be assigned or published to users and assigned to computers. Group Policy-based software installation can be used to install software applications when a computer is started, when the user logs on, or on demand. Software installation Group Policy settings can be applied to users or computers in an Active Directory structure. Group Policy-based software installation can also be used to upgrade deployed applications or remove earlier applications that are no longer required. Users can be restricted from installing any software from local media, such as a CD-ROM, or disk, or other unapproved applications. Medium and large organizations may wish to consider using Systems Management Server (SMS). SMS provides advanced capabilities such as inventory-based targeting, status reporting, server- and client-side scheduling, multisite facilities, complex targeting, centralized hardware and software inventory, remote diagnostic tools, software metering, software distribution-point population and maintenance, support for Windows 95, Windows 98, Windows NT 4.0, Windows 2000, and Windows XP clients, and enhanced software deployment features. SMS does not require Active Directory. Managing Remote Operating System Installations Remote Installation Services (RIS) is used to control the behavior of the Remote Operating System Installation feature as displayed to client computers. Remote Installation enables administrators to perform a new installation of Windows on Preboot eXecution Environment (PXE) remote boot-enabled client computers throughout an organization. Using a customized, fully automated installation process from a remote source, an administrator does not have to visit the new computer to install a new operating system and core applications. Managing with Scripts Scripts are used to automate tasks at computer startup and shutdown, and at user logon and logoff. Scripts can be written in any language supported by Windows Script Host including the Microsoft Visual Basic development system, Scripting Edition (VBScript), JavaScript, PERL, and MS DOS-style batch files (.bat and .cmd). Managing Internet Explorer

Internet Explorer Maintenance is used to manage and customize Internet Explorer on computers running Windows 2000 or later. You can set options for the Browser UI, connections, URLs, proxy settings, security zones, Favorites, and Internet Explorer Enhanced Security Configuration component (also known as Microsoft Internet Explorer hardening). . Managing Folder Redirection You can use folder redirection to redirect special directories on Windows 2000 or Windows Server 2003 from their default user profile location to an alternate location on the network. These special folders include My Documents, Application Data, Desktop, and the Start menu.

Core Group Policy Technical Reference

Group Policy is an infrastructure that allows you to specify managed configurations for users and computers in an Active Directory directory service environment. Group Policy settings are contained in Group Policy objects (GPOs). GPOs exist in a domain, and can be linked to the following Active Directory containers: sites, domains, or organizational units (OUs). A GPO consists of two parts one part is located in Active Directory, the other is located in the Sysvol folder both of which are replicated to all domain controllers in the domain. The settings within GPOs are then evaluated by the affected targets, using the hierarchical nature of Active Directory. Core Group Policy or the Group Policy engine is the framework that handles common functionalities across all client side extensions. In this subject

What Is Core Group Policy? How Core Group Policy Works Core Group Policy Tools and Settings

What Is Core Group Policy?

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section

Change and Configuration Management Core Group Policy Infrastructure Core Group Policy Scenarios Core Group Policy Dependencies Related Information

Group Policy is an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory environment. This infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) responsible for writing specific policy settings on target client computers. Group Policy settings are contained in Group Policy objects (GPOs), which live in the domain and can be linked to the following Active Directory containers: sites, domains, or organizational units (OUs). The settings within GPOs are then evaluated by the affected targets, using the hierarchical nature of Active Directory. Consequently, Group Policy is one of the top reasons to deploy Active Directory. Group Policy is one of a group of management technologies, collectively known as IntelliMirror, that provides users with consistent access to their applications, application settings, roaming user profiles, and user data, from any managed computer even when they are disconnected from the network. IntelliMirror is implemented through a set of Windows features, including Active Directory, Group Policy, Group Policy-based Software Installation, Windows Installer, Folder Redirection, Offline Folders, and Roaming User Profiles. Core Group Policy or the Group Policy engine is the framework that handles common functionalities across Administrative Template settings and other client-side extensions. The following figure shows how the Group Policy engine interacts with other components as part of processing policy settings. You use Group Policy Management Console (GPMC) to create, view, and manage GPOs and use Group Policy Object Editor to set and configure the policy settings in GPOs.

Group Policy Components

Change and Configuration Management

Administrators face increasingly complex challenges in managing their IT infrastructures. You must deliver and maintain customized desktop configurations for many types of workers, including mobile users, information workers, or others assigned to strictly defined tasks, such as data entry. Changes to standard operating system images might be required on an ongoing basis. Security settings and updates must be delivered efficiently to all the computers and devices in the organization. New users need to be productive quickly without costly training. In the event of a computer failure or disaster, service must be restored with a minimum of data loss and interruption. Specifically, an IT department must respond to various factors that require change in an IT environment including:

New operating systems and applications. Updates to operating systems and applications. New hardware. New business requirements that require configuration changes. Security influences that require configuration changes. New users.

Managing this change can be viewed as a continuous cycle, in which new business requirements demand changes that must first be tested before they can be deployed as a standard configuration. This cycle is shown in the following figure. Change and Configuration Management Process

These roles, known collectively as Change and Configuration Management, enable administrators to implement change quickly and affect large numbers of users and computers at the lowest possible cost. You can use Group Policy to maintain standard operating environments for specific groups of users, such as developers or information workers. As software changes and policies change over time, Group Policy can be used to update the alreadydeployed standard operating environment until the image can be updated. Group Policy can also enforce rules, if necessary, by restricting the programs that can be run on company computers. For example, it can prevent access to games or other programs unrelated to the workplace. Group Policy is a key enabling technology that allows you to implement Change and Configuration Management along with other technologies in IntelliMirror. For example, you can deploy new operating systems with Remote Installation Services or other imaging technology. You can deliver updates to computers throughout the network using Software Update Services (SUS). Although you can deploy software using Group Policy, larger organizations might want to use Microsoft Systems Management Server (SMS) to take advantage of the scalability that SMS provides. In summary, Group Policy is the delivery mechanism that allows you to implement change and configuration for users and computers on the object level in Active Directory. Because you can target Group Policy settings to individual objects throughout the Active Directory hierarchy, Group Policy is the central enabling technology that allows organizations to effectively use Active Directory as a management tool. In addition, the Group Policy Management Console simplifies implementation and management of Group Policy.

Core Group Policy Infrastructure

Group policy is an infrastructure with pluggable extensions. Extensions that exist on client computers include Administrative Templates (also known as registry-based policy), Security Settings, Software Installation, Folder Redirection, Scripts, and Wireless Network Policies. The policy settings exist in a GPO. A GPO is a virtual object that lives in the domain; part of the GPO is located in Active Directory and is called the Group Policy container. The other part of a GPO is located in the Sysvol and is called the Group Policy template. When policy settings need to be applied, the framework calls each extension and the extension then applies the necessary settings. Each Group Policy extension has two extensions a client extension that is called by the Group Policy engine to apply policy, and a server-side extension that plugs into Group Policy Object Editor to define and set the policy settings that need to be applied to client computers. Although you can configure Local Group Policy objects (Local GPOs) on individual computers, the full power of Group Policy can only be realized in a Windows 2000 or Windows Server 2003-based network with Active Directory installed. In addition, some features and policy settings require client computers running Windows XP. Group Policy and Active Directory Active Directory organizes objects by sites, domains, and OUs. Domains and OUs are organized hierarchically, making the containers and the objects within them easy to manage. The settings defined in a GPO can only be applied when the GPO is linked to one or more of these containers. By linking GPOs to sites, domains, and OUs, you can implement Group Policy settings for as broad or as narrow a portion of the organization as you want. GPO links affect users and computers in the following ways:

A GPO linked to a site applies to all users and computers in the site. A GPO linked to a domain applies directly to all users and computers in the domain and by inheritance to all users and computers in child OUs. Note that policy is not inherited across domains. A GPO linked to an OU applies 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 container, not a component of the GPO. An example of how GPOs can be linked to sites, domains, and OUs is shown in the following figure. Sample Active Directory Organizational Structure

In this configuration, the Servers OUs have the following GPOs applied: A1, A2, A3, A4, A6. The Marketing OUs have the following GPOs applied: A1, A2, A3, A5. Loopback processing with merge or replace Loopback is an advanced Group Policy setting that is useful on computers in certain closely managed environments, such as servers, kiosks, laboratories, classrooms, and reception areas. Setting loopback causes the User Configuration settings in GPOs that apply to the computer to be applied to every user logging on to that computer, instead of, or in addition to, the User Configuration settings of the user. This allows you to ensure that a consistent set of policies is applied to any user logging on to a particular computer, regardless of their location in Active Directory. Loopback is controlled by the setting, User Group Policy loopback processing mode, which is located in Computer Configuration\Administrative Templates\System\Group Policy. Loopback only works when both the user account and the computer account are in a Windows 2000 or later domain. Loopback does not work for computers joined to a workgroup. Loopback is not enabled if the computer or user is not in an Active Directory domain. Filtering the Scope of the Group Policy Object Group Policy is a powerful tool for managing the Windows Server 2003 environment. The value of Group Policy can only be realized through properly applying the GPOs to the Active Directory containers you want to manage. Determining which users and computers will receive the settings in a GPO is referred to as scoping the GPO. Scoping a GPO is based on three factors:

The site(s), domain(s), or organization unit(s) where the GPO is linked. The security filtering on the GPO. The WMI filter on the GPO.

You can use the site, domain, and OU links from a GPO as the primary targeting principle for defining which computers and users should receive a GPO. You can then use security filtering and WMI filtering to further reduce the set of computers and users to which the GPO will apply. Scoping or targeting of a GPO allows you to apply or deny an entire GPO; you cannot choose to filter settings within a GPO. Group Policy Inheritance In addition to the ability to filter the scope of GPOs, you can change the way GPOs are applied by managing Group Policy inheritance. In most environments, the actual settings for a given user and computer are the result of the combination of GPOs that are applied at a site, domain, or OU. When multiple GPOs apply to these users and computers, the settings in the GPOs are aggregated. The settings deployed by GPOs linked to higher containers (parent containers) in Active Directory are inherited by default to child containers and combine with any settings deployed in GPOs linked to child containers. If multiple GPOs attempt to set a setting to conflicting values, the GPO with the highest precedence sets the setting. GPO processing is based on a last writer wins model, and GPOs that are processed later have precedence over GPOs that are processed earlier. Viewing and Reporting of Policy Settings In order to properly implement, troubleshoot, and plan Group Policy, administrators need to be able to quickly view the settings in a GPO. When multiple GPOs apply to a given user or computer, they can contain conflicting policy settings. For most policy settings, the final value of the policy setting is set only by the highest precedent GPO that contains that setting. Resultant Set of Policy (RSoP) helps you understand and identify the final set of policy that is applied as well as settings that did not apply as a result of policy inheritance.

Specifically, Resultant Set of Policy helps you determine:

The final value of the setting that is applied as a result of all the GPOs. The final GPO that set the value of this setting (also known as the winning GPO). Precedence details that show any other GPOs that attempted to set this setting and the value that each GPO attempted to set for that policy setting.

Group Policy Management Console, available as a separate download from the Microsoft Web site, addresses some common reporting requirements including the ability to document all the settings in a GPO to a file for printing or viewing. Users can either print the reports, or save them to a file as either HTML or XML. Delegating Administration of Group Policy Organizations need to be able to delegate administration of Group Policy to other administrators who can take responsibility for a given OU, domain, or other container. Active Directory is designed to allow you to delegate control of portions of the directory service in managing aspects of Group Policy. The following areas can be delegated:

GPO delegation. This includes permission to create GPOs in a domain or permission to edit an existing GPO. Note that having permission to edit a GPO does not include any delegated rights on the GPO links. Link delegation. This includes permission to add, delete, or change links to GPOs. Note that having link delegation does not include any delegated rights on the GPO itself. RSOP delegation. This includes permission to run RSoP (in either planning or logging mode) on objects under a container. WMI filter delegation. This includes permission to create WMI filters or permission to edit an existing filter.

In GPMC, delegation is simplified because it manages the various Access Control Entries (ACEs) required for a task as a single bundle of permissions for the task. You can also use the Access Control List (ACL) editor to view or manage these permissions manually. The underlying mechanism for achieving delegation is the application of the appropriate DACLs to GPOs and other objects in Active Directory. This mechanism is identical to using security groups to filter the application of GPOs to various users. You can also specify Group Policy to control who can use MMC snap-ins. For example, you can use Group Policy to manage the rights to create, configure, and use MMC consoles, and to control access to individual snap-ins.

Core Group Policy Scenarios

The Group Policy engine is designed to apply policy configurations to individual computers and users through Group Policy objects. Settings within a GPO are configured by individual client-side extensions and are applied to individual computers and users by the client-side extension. This section summarizes the core scenarios for the Group Policy engine.

Scheduling of Group Policy application. Group Policy starts each time the computer starts or a user logs in, a process called foreground policy application. Group Policy is also applied in the background at regular refresh intervals. In addition, it can be forced to apply through command line tools such as Gpupdate. Obtaining GPOs from the relevant configuration locations. The Group Policy engine obtains GPOs from the appropriate site, domain, and OU containers, known collectively as Scope of Management (SOM). Handling special cases affecting all CSEs. The Group Policy engine implements additional changes specified by the administrator such as changing the link order in which GPOs should be applied. In addition, the Group Policy engine handles any loopback processing that has been set by an administrator. Loopback processing, typically used for public workstations or kiosks, specifies that the user settings defined in the computers GPOs replace or are merged with the user settings normally applied to the user. Filtering and ordering of GPOs. The Group Policy engine checks for any conditions set by the administrator to filter GPOs or specify the order in which GPOs should be applied.

Configuring CSEs. CSEs can be configured to run only in some conditions, as specified in the registry. Maintaining version numbers and histories for all CSEs. A history list is maintained for each CSE in the Registry, showing when the CSE last applied policy. A status is also maintained to figure out whether the client-side extension applied policy successfully last time the policy was applied by the CSE. Calling into the CSE. When the Group Policy engine has determined that a particular CSE needs to be executed, it loads the dynamic link library (DLL) associated with the CSE and loads up the entry point. Notifying various components of any changes made by Group Policy. After all the extensions have been called, the Group Policy engine updates the registry information to specify what the next policy foreground application should be, as well as schedule the next background refresh time. Processing RSoP data. The Group Policy engine periodically refreshes the RSoP data, ensuring that actual policy application is updated and stored in the WMI namespace on each computer.

Group Policy Dependencies

Group Policy has several key dependencies. Domain-based Group Policy requires an Active Directory environment with DNS properly configured. Active Directory Active Directory is the Windows 2000 Server and Windows Server 2003 directory service that stores information about all objects on the computer network and makes this information easy for administrators and users to find and apply. With Active Directory, users can gain access to resources anywhere on the network with a single logon. Similarly, administrators have a single point of administration for all objects on the network, which can be viewed in a hierarchical structure. In a network environment, Group Policy depends on Active Directory as the targeting framework that allows you to link GPOs to specific Active Directory containers such as sites, domains, or OUs. In a stand-alone environment without Active Directory, you can use Local Group Policy objects to configure settings on individual computers. Domain Name System (DNS) DNS is a hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as IP addresses. DNS enables the location of computers and services by user-friendly names, and it also enables the discovery of other information stored in the database. Group Policy application requires clients to access specified servers, including domain controllers and other servers such as share points and install points. Group Policy management also requires access to domain controllers. DNS is used to locate and identify these servers. In Windows 2000 Server and later Active Directory requires DNS support. If the network is functioning, but clients or consoles such as the Group Policy Object Editor or GPMC are unable to locate the servers, there might be a problem with your network's DNS system. Replication Group Policy depends on other technologies in order to properly replicate between domain controllers in a network environment. A GPO is a virtual object stored in both Active Directory and the Sysvol of a domain controller. Property settings, stored in the Group Policy container, are replicated through Active Directory replication. Replication automatically copies the changes that originate on a writable directory partition replica to all other domain controllers that hold the same directory partition replica. More specifically, a destination domain controller pulls these changes from the source domain controller. Data settings, stored in the Sysvol as the Group Policy template, are replicated through the File Replication Service (FRS), which provides multi-master file replication for designated directory trees between designated servers running Windows Server 2003. The Group Policy container stores GPO properties, including information about version, GPO status, and a list of components that have settings in the GPO. The Group Policy template is a directory structure within the file system that stores Administrative Template-based policy settings, security settings, script files, and information regarding applications that are available for software installation. The Group Policy template is located in Sysvol in the \Policies sub-directory for its domain. GPOs are identified by their globally unique identifiers (GUIDs) and stored at the domain level. The settings from a GPO are only applied when the Group Policy container and Group Policy template are synchronized. DFS publishing The Sysvol folder is shared on each domain controller and is accessible through the UNC path \\dcname.domainname\sysvol. The Sysvol is also published as a domain-based Distributed File System (DFS) share. This allows clients to access the Sysvol by using the generic path \\domainname\sysvol. A request for a DFS referral for \\domainname\sysvol will always return a replica in the same Active Directory site as the client if one is available. This is the mechanism that the Group Policy client-side extensions use to retrieve a local copy of the Group Policy template information.

How Core Group Policy Works

Updated: September 2, 2009 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Core Group Policy Works

In this section

Core Group Policy Architecture Core Group Policy Physical Structure Core Group Policy Processes and Interactions Network Ports Used by Group Policy Related Information

Core Group Policy or the Group Policy engine is the infrastructure that processes Group Policy components including server-side snap-in extensions and client-side extensions. You use administrative tools such as Group Policy Object Editor and Group Policy Management Console to configure and manage policy settings. At a minimum, Group Policy requires Windows 2000 Server with Active Directory installed and Windows 2000 clients. Fully implementing Group Policy to take advantage of all available functionality and the latest policy settings depends on a number of factors including:

Windows Server 2003 with Active Directory installed and with DNS properly configured. Windows XP client computers. Group Policy Management Console (GPMC) for administration.

Core Group Policy Architecture

The Group Policy engine is a framework that handles client-side extension (CSE) processing and interacts with other elements of Group Policy, as shown in the following figure: Core Group Policy Architecture

The following table describes the components that interact with the Group Policy engine.

Core Group Policy Components

Component Server (domain controller) Active Directory

Description

In an Active Directory forest, the domain controller is a server that contains a writable copy of the Ac replication, and controls access to network resources.

Active Directory, the Windows-based directory service, stores information about objects on a network network administrators. Administrators link Group Policy objects (GPOs) to Active Directory container that include user and computer objects. In this way, policy settings can be targeted to users and com

Sysvol

The Sysvol is a set of folders containing important domain information that is stored in the file system default, stored in a subfolder of systemroot folder (%\systemroot\sysvol\sysvol) and is automatically The Sysvol contains the largest part of a GPO: the Group Policy template, which includes Administrat files, and information regarding applications that are available for software installation. It is replicate domain controllers in a domain.

Group Policy object (GPO)

A GPO is a collection of Group Policy settings, stored at the domain level as a virtual object consisting The Group Policy container, which contains information about the properties of a GPO, is stored in Ac The Group Policy template contains the data in a GPO and is stored in the Sysvol in the /Policies subd contained in sites, domains, and OUs.

Local Group Policy object

The Local Group Policy object (Local GPO) is stored on each individual computer, in the hidden Wind running Windows 2000, Windows XP Professional, Windows XP 64-Bit Edition, Windows XP Media Cen GPO, regardless of whether the computers are part of an Active Directory environment. Local GPOs are always processed, but are the least influential GPOs in an Active Directory environme

Winlogon Group Policy engine Client-side extensions File system Registry

A component of the Windows operating system that provides interactive logon support, Winlogon is t The Group Policy engine is the framework that handles common functionalities across registry-based

CSEs run within dynamic-link libraries (DLLs) and are responsible for implementing Group Policy at th The CSEs are loaded on an as-needed basis when a client computer is processing policy The NTFS file system on client computers.

A database repository for information about a computers configuration, the registry contains informa such as:

Profiles for each user. The programs installed on the computer and the types of documents that each can create. Property settings for folders and program icons. The hardware on the system. Which ports are being used.

The registry is organized hierarchically as a tree, and it is made up of keys and their subkeys, hives, Registry settings can be controlled through Group Policy, specifically, Administrative Templates (.adm of Administrative Template files, which are implemented as text files (with an .adm extension), that d These .adm files are stored in two locations by default: inside GPOs in the Sysvol folder and in the W Event log Help and Support Center Resultant Set of Policy (RSoP) infrastructure WMI

The Event log is a service, located in Event Viewer, which records events in the system, security, and

The Help and Support Center is a component on each computer that provides HTML reports on the po

All Group Policy processing information is collected and stored in a Common Information Model Objec This information, such as the list, content, and logging of processing details for each GPO, can then b Instrumentation (WMI).

WMI is a management infrastructure that supports monitoring and controlling of system resources th organized, consistent model of Windows operation, configuration, and status. WMI makes data about a target computer available for administrative use. Such data can include har information. For example, WMI exposes hardware configuration data such as CPU, memory, disk spa data from the registry, drivers, file system, Active Directory, the Windows Installer service, networkin Windows Server 2003 allows you to create queries based on this data. These queries (WMI filters) de

policy configured in the GPO where you create the filter.

Group Policy Engine Architecture

The primary purpose of Group Policy is to apply policy settings to computers and users in an Active Directory domain. GPOs can be targeted through Active Directory containers, such as sites, domains, and OUs, containing user or computer objects. The Group Policy engine is in userenv.dll, which runs inside the Winlogon service. This is shown in the following figure. Group Policy Engine Architecture and CSE Components

Group Policy Engine Architecture and CSE Components

Component Group Policy Engine Winlogon.exe Userenv.dll gptext.dll fdeploy.dll scecli.dll iedkcs32.dll appmgmts.dll dskquota.dll

Description The framework that handles functionalities across CSEs, the Group Policy engine runs inside userenv.dll.

A component of the Windows operating system that provides interactive logon support, Winlogon is the ser only system component that actively interacts with the Group Policy engine.

Userenv.dll runs inside Winlogon and contains the Group Policy engine and the Administrative Templates ex Used to configure Scripts, IP Security, QoS Packet Scheduler, and Wireless settings. Used to configure folder redirection Used to configure security settings. Used to manage various Internet Explorer settings. Used to configure software installation settings. Used for setting disk quotas.

RSoP Architecture
Resultant Set of Policy (RSoP) uses WMI to determine how policy settings are applied to users and computers. RSoP has two modes: logging mode and planning mode. Logging mode determines the resultant effect of policy settings that have been applied to an existing user and computer based on a site, domain, and OU. Logging mode is available on Windows XP and later operating systems. Planning mode simulates the resultant effect of policy

settings that are applied to a user and computer. Planning mode requires a Windows Server 2003 computer as a domain controller. For RSoP functionality, using GPMC is recommended, which includes RSoP features integrated with the rest of GPMC. In GPMC, RSoP logging mode is referred to as Group Policy Results; planning mode is referred to as Group Policy Modeling. The following figure shows the high-level architecture of RSoP for Group Policy Results and Group Policy Modeling: RSoP Architecture

Windows Server 2003 collects Group Policy processing information and stores it in a WMI database on the local computer. (The WMI database is also known as the CIMOM database.)This information, such as the list, content and logging of processing details for each GPO, can then be accessed by tools using WMI. In Group Policy Results, RSoP queries the WMI database on the target computer, receives information about the policies and displays it in GPMC. In Group Policy Modeling, RSoP simulates the application of policy using the Resultant Set of Policy Provider on a domain controller. Resultant Set of Policy Provider simulates the application of GPOs and passes them to virtual CSEs on the domain controller. The results of this simulation are stored to a local WMI database on the domain controller before the information is passed back and displayed in GPMC (or the RSoP snap-in). This is explained in greater detail in the following section.

Windows Management instrumentation (WMI) and Common Information Model Object Management (CIMOM)
WMI provides a common scriptable interface to retrieve, and in some cases set, a wide variety of system and application information. WMI is implemented through the winmgmt.exe service. The WMI information hierarchy is modeled as a hierarchy of objects following the Common Information Model (CIM) standards. This information hierarchy is extensible, which allows different applications and services to expose configuration information by supplying a WMI provider. WMI providers are the interface between the WMI service and the application's data in its native format. WMI data can be dynamic (generated on demand when required by a management application) or static. Static data is stored in the CIMOM database. This data can be accessed at any time (security controls permitting) by management applications. RSoP uses WMI and the CIMOM to write, store and query RSoP settings information.

Resultant Set of Policy Provider

RSoP in planning mode has the special requirement that no settings information is actually applied to the client system during the RSoP data generation. In fact, in many planning scenarios, there might not be a computer or user object to apply the settings to. To meet this requirement, the RSoP provider runs on domain controllers and performs some of the functions of a client system for GPO application. The RSoP provider is actually a WMI provider that performs the role of Winlogon in invoking CSEs to log RSoP information to the CIM repository. It takes parameters supplied by the RSoP wizard to select GPOs from the directory. It uses the following parameters:

Scope of management (SOM). This is the combination of user object OU and computer object OU and Site (although the latter is optional). Either the User or Computer SOM can be omitted but one must be

specified. This can be specified as either an existing computer, user, or both, or as existing OUs for the computer, user, or both.

Security group memberships for the computer and user objects. By default, these are the existing security group memberships if actual user or computer objects are chosen as the SOM. Security filtering can be ignored entirely or a new or a modified set of groups can be chosen. WMI filter. New or modified WMI filters can be applied to the GPOs during the RSoP generation.

RSoP provider is a service on a domain controller and runs in system context. There are two ramifications to this design. The service manually evaluates the security descriptor of each GPO in the SOM against the user object and computer object security identifiers (SIDs) and their security group membership. If Active Directory is locked down, some security group membership analyses might fail until the user is provided the correct access. In addition, because the RSoP provider has Domain Admin-equivalent access rights, some control needs to be placed on who can generate RSoP information in the directory. This control is achieved by an extended access right GenerateRSoPData. To execute an RSoP session for a particular container, the user must have the Generate RSoP (planning) access right for that container.

Planning Mode (Group Policy Modeling)

In planning mode, RSoP provider performs the RSoP data generation in the following steps: 1. 2. RSoP tool gets the user, computer and domain controller name from the wizard. RSoP connects to the WMI database on the specified domain controller. WMI service in turn calls the WMI Provider (an out-of-process service provider) on the same computer to create the RSoP data. RSoP provider gets the list GPOs for the user and computer from Active Directory. RSoP provider populates the WMI database with instances of the GPOs for user and computer. The list of registered CSEs is retrieved. Each of the policy extensions is dynamically loaded in succession by the RSoP provider and the list of computer and user GPOs is passed to each extension. Each policy extension takes the list of GPOs and instead of applying the policy, it populates the WMI database with instances of policy objects that describe the effective policy. After the WMI database population is over, RSoP provider returns the namespace under which the RSoP data was created to the WMI service. This returns the namespace to the RSoP tool. The RSoP tool connects to the namespace on the WMI database on the domain controller. RSoP navigates or iterates through the populated data in the WMI database using WMI enumeration APIs to retrieve the policy data. The RSoP data is displayed to the user. When the user is done looking at the RSoP data, the RSoP tool calls RsopDeleteSession on the WMI service to delete the data in WMI's database that was previously created.

3. 4. 5.
6.

7.

8.

9.

Logging Mode (Group Policy Results)

In logging mode, the RSoP data generation is controlled by Winlogon and is part of the normal GPO processing operation. The Winlogon process retrieves the list of GPOs from the Active Directory using the security context of the user or computer.

Winlogon process populates the WMI database with instances of the GPOs. The list of registered policy extensions is retrieved. Each of the policy extensions is dynamically loaded in succession by the Winlogon process and the list of GPOs is passed to each policy extension. Each extension takes the list of GPOs and, in addition to applying the policy, it populates the WMI database with the policies set and which GPOs applied them.

Core Group Policy Physical Structure

Understanding where GPOs are stored and how they are structured can help you troubleshoot problems you might encounter when you implement Group Policy. Although GPOs can be linked to sites, domains, and OUs, they are stored only in the domain. As explained earlier, a GPO is a virtual object that stores its data in two locations: a Group Policy container and a Group Policy template.

Group Policy Container

A Group Policy container is a location in Active Directory that stores GPOs and their properties. The properties of a GPO include both computer and user Group Policy information. The Policies container is the default location of GPOs. The path to the Policies container, in Lightweight Directory Access Protocol (LDAP) syntax, is CN=Policies,CN=System,DC=Domain_Name, where the Domain_Name values specify a fully qualified domain name (FQDN). The Active Directory store contains the Group Policy container of each GPO in the domain. The Group Policy container contains attributes that are used to deploy GPOs to the domain, to OUs, and to sites within the domain. The Group Policy container also contains a link to the file system component of a GPO the Group Policy template. Some of the information in a Group Policy container includes:

Version information. Ensures that the information is synchronized with the Group Policy template information. Status information. Indicates whether the user or computer portion of the GPO is enabled or disabled. List of components. Lists (extensions) that have settings in the GPO. These attributes are gPCMachineExtensionNames and gPCUserExtensionNames. File system path. Specifies the Universal Naming Convention (UNC) path to the Sysvol folder. This attribute is gPCFileSysPath. Functionality version. Gives the version of the tool that created the GPO. Currently, this is version 2. This attribute is gPCFunctionalityVersion. WMI filter. Contains the distinguished name of the WMI filter. This attribute is gPCWQLFilter.

System Container
Each Windows Server 2003 domain contains a System container. The System container stores per-domain configuration settings, including GPO property settings, Group Policy container settings, IP Security settings, and WMI policy settings. IP Security and WMI policy are deployed to client computers through the GPO infrastructure. The following subcontainers of the System container hold GPO-related settings:

Policies. This object contains groupPolicyContainer objects listed by their unique name. Each groupPolicyContainer object holds subcontainers for selected computer and user policy settings. Domain, OUs and Sites. These objects contain two GPO property settings, gPLink and gPOptions. Default Domain Policy. This object contains the AppCategories container, which is part of the Group Policy Software installation extension. IP Security. This object contains IP Security policy settings that are linked to a GPO. The linked IP Security policy is applied to the recipients (user or computer) of the GPO. WMIPolicy. This object contains WMI filters that can be applied to GPOs. WMI filters contain one or more Windows Query Language (WQL) statements.

System\Policies Container
The System container is a top level container found in each domain naming context. It is normally hidden from view in the Active Directory Users and Computers snap-in but can be made visible by selecting Advanced Features from the snap-in View menu inside MMC. (Objects appear hidden in the Active Directory Users and Computers snap-in when they have the property showInAdvancedViewOnly = TRUE.) Group Policy information is stored in the Policies subcontainer of this container. Each GPO is identified by a GroupPolicyContainer object stored within the Policies container.

The Group Policy container is located in the Domain_Name/System/Policies container. Each Group Policy container is given a common name (CN) and this name is also assigned as the container name. For example, the name attribute of a Group Policy container, might be: {923B9E2F-9757-4DCF-B88A-1136720B5AF2}, which is also assigned to the Group Policy container's CN attribute. The default GPOs are assigned the same Group Policy container CN on all domains. All other GPOs are assigned a unique CN. The default GPOs and their Group Policy container common names are:

Default Domain Policy: {31B2F340-016D-11D2-945F-00C04FB984F9}. Default Domain Controllers Policy: {6AC1786C-016F-11D2-945F-00C04fB984F9}.

Knowing the common names of the default GPOs will help you distinguish them from non-default GPOs.

How a Group Policy Container is Named

Group Policy containers are named automatically when they are created. The CN of each Group Policy container is a GUID (Globally Unique Identifier). This is distinct from and unrelated to the Object GUID given to each Active Directory object. The CN is the name of the Group Policy container used to ensure uniqueness of Group Policy container names within the Policies container. There is no requirement for these GUIDs to be unique between domains (the Default Domain Policy and the Default Domain Controllers Policy GPOs each have identical GUIDs in all Active Directory installations). However, an Object GUID is always unique across all installations of the Active Directory store. The following table shows permissions on Group Policy container: Default Group Policy Container Permissions

Trustee Authenticated Users Domain Admins System

Access Read, Apply Group Policy Read, Write Read, Write

GPO Attributes in the Policies CN

GPOs are created by instantiating the groupPolicyContainer class in the Active Directory schema and storing the resulting GPO in the System/Policies container of the Active Directory store. After creating a GPO, you can review its CN from the Active Directory Users and Computers snap-in by enabling the Advanced view and then expanding the Policies CN. You can review all GPO attributes and their values from the Active Directory Services Interface Editor snap-in, ADSI Edit. Object attributes are either mandatory or optional, as defined in the Active Directory schema. The CN attribute is mandatory for the class Container, Group Policy container's parent class. Three attributes instanceType, objectCategory, and objectClass are mandatory for the class Top, CN's parent class. Thus the Group Policy container class inherits all four mandatory attributes. The following table describes the mandatory attributes: Mandatory Attributes of the groupPolicyContainer Class

Name CN instanceType objectCategor y objectClass

Description

The common name of the GPO. This is in the form of a GUID to avoid GPO naming conflicts within the Policies

An attribute that dictates how an object is instantiated from its class on a particular server. In this case, it de GPO in the Active Directory. A GPO is assigned the instanceType value of 4.

An object class name, including the object's path, used to group object's of the instantiated class. For exampl is: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=contoso,DC=com.

The list of classes from which this class is derived. For a GPO, the objectClass is Container, groupPolicyContai

There are also a number of optional attributes inherited from the top class, and others that are assigned directly to the Group Policy container. Many optional attributes are required in order for the Group Policy container to function properly. For example, the GPCFileSysPath optional attribute must be present or the Group Policy container will not be linked to its corresponding Group Policy template.

GroupPolicyContainer Subcontainers
Within the GroupPolicyContainer there are a series of subcontainers. The first level of subcontainers User and Machine belong to the class Container. These two containers are used to separate some User-specific and Computer-specific Group Policy components.

Group Policy Container-Related Attributes of Domain, Site, and OU Containers

Windows Server 2003 uses domain, DNS, site, and organizational unit classes to create domain, site, and OU container objects respectively. These objects contain two optional Group Policy container-related attributes, gPLink and gPOptions. The gPLink property contains the prioritized list of GPOs and the gPOptions property contains the Block Policy Inheritance setting. The gPLink attribute holds a list of all Group Policy containers linked to the container and a number for each listed Group Policy container, that represents the Enforced (previously known as No Override) and Disabled option settings. The list appears in priority order from lowest to highest priority GPO. The gPOptions attribute holds an integer value that indicates whether the Block Policy Inheritance option of a domain or OU is enabled (0) or disabled (1).

Managing Group Policy Links for a Site, Domain, or OU

To manage GPO links to a site, domain, or OU, you must have read and write access to the gPLink and gPOptions properties. By default, Domain Admins have this permission for domains and organizational unit, and only Enterprise Admins and Domain Admins of the forest root domain can manage links to sites. Active Directory supports security settings on a per-property basis. This means that a non-administrator can be delegated read and write access to specific properties. In this case, if non-administrators have read and write access to the gPLink and gPOptions properties, they can manage the list of GPOs linked to that site, domain, or OU.

How WMIPolicy Objects are Stored and Associated with Group Policy Container Objects
A single WMI filter can be assigned to a Group Policy container. The Group Policy container stores the distinguished name of the filter in gPCWQLFilter attribute. The Group Policy container locates the assigned filter in the System/WMIPolicy/SOM container. Each Windows Server 2003 domain stores its WMI filters in this Active Directory container. Each WMI filter stored in the SOM container lists the rules that define the WMI filter. Each rule is listed separately. For example, consider a WMI filter containing the following three WQL queries:

SELECT * FROM Win32_Product WHERE IdentifyingNumber = "{5E076CF2-EFED-43A2-A62313E0D62EC7E0}" SELECT * FROM Win32_Product WHERE IdentifyingNumber = "{242365CD-80F2-11D2-989A00C04F7978A9}" SELECT * FROM Win32_Product WHERE IdentifyingNumber = "{00000409-78E1-11D2-B60F006097C998E7}"
Three WMI rules are defined in the details of the filter. Each rule contains a number of attributes, including the query language (WQL) and the WMI namespace queried by the rule.

Group Policy Template

The majority of Group Policy settings are stored in the file system of the domain controllers. This part of each GPO is known as the Group Policy template. The GroupPolicyContainer object for each GPO has a property, GPCFileSysPath, which contains the UNC path to its related Group Policy template. All Group Policy templates in a domain are stored in the \\domain_name\Sysvol\domain_name\Policies folder, where domain_name is the FQDN of the domain. The Group Policy template for the most part stores the actual data for the policy extensions, for example Security Settings inf file, Administrative Template-based policy settings .adm and .pol files, applications available for the Group Policy Software installation extension, and potentially scripts.

The Gpt.ini File

The Gpt.ini file is located at the root of each Group Policy template. Each Gpt.ini file contains GPO version information. Except for the Gpt.ini files created for the default GPOs, a display name value is also written to the file. Each Gpt.ini file contains the GPO version number of the Group Policy template.

[General]

Version=65539
Normally, this is identical to the version-number property of the corresponding GroupPolicyContainer object. It is encoded in the same way as a decimal representation of a 4 byte hexadecimal number, the upper two bytes of which contain the GPO user settings version and the lower two bytes contain the computer settings version. In this example the version is equal to 10003 hexadecimal giving a user settings version of 1 and a computer settings version of 3. Storing this version number in the Gpt.ini allows the CSEs to check if the client is out of date to the last processing of policy settings or if the currently applied policy settings (cached policies) are up-to-date. If the cached version is different from the version in the Group Policy template or Group Policy container, then policy settings will be reprocessed.

Group Policy Template Subfolders

The Group Policy template folder contains the following subfolders:

Machine. Includes a Registry.pol file that contains the registry settings to be applied to computers. When a computer initializes, this Registry.pol file is downloaded and applied to theHKEY_LOCAL_MACHINE portion of the registry. The Machine folder can contain the following subfolders (depending on the contents of the GPO):

Scripts\Startup. Contains the scripts that are to run when the computer starts up. Scripts\Shutdown. Contains the scripts that are to run when the computer shuts down.

Applications. Contains the advertisement files (.aas files) used by the Windows installer. These are applied to computers. Microsoft\Windows NT\Secedit. Contains the Gpttmpl.inf file, which includes the default security configuration settings for a Windows Server 2003 domain controller. Adm. Contains all of the .adm files for the GPO.

User. Includes a Registry.pol file that contains the registry settings to be applied to users. When a user logs on to a computer, this Registry.pol file is downloaded and applied to the HKEY_CURRENT_USER portion of the registry. The User folder can contain the following subfolders (depending on the contents of the GPO):

Applications. Contains the advertisement files (.aas files) used by the Windows installer. These are applied to users. Documents and Settings. Contains the Fdeploy.ini file, which includes status information about the Folder Redirection options for the current user's special folders. Microsoft\RemoteInstall. Contains the OSCfilter.ini file, which holds user options for operating system installation through Remote Installation Services. Microsoft\IEAK. Contains settings for the Internet Explorer Maintenance snap-in. Scripts\Logon. Contains all the user logon scripts and related files for this GPO. Scripts\Logoff. Contains all the user logoff scripts and related files for this GPO.

The User and Machine folders are created at install time, and the other folders are created as needed when policy is set. The permissions of each Group Policy template reflect the read and write permissions applied to the GroupPolicyContainer through the Group Policy Object Editor. These permissions are automatically maintained and are shown in the following table. Default Group Policy Template Permissions

Trustee Authenticated Users Administrators Group Policy Creator Owners Creator Owner System

Access Read and Execute Full Control Read and Execute Full Control (Subfolders and Files only) Full Control

Group Policy Object Editor use of Sysvol

Each policy setting changed in a GPO causes at least two files to be rewritten the GPT.ini and the file holding the changed setting. Making many changes to a GPO can cause a lot of network traffic as Sysvol replicates these changes. This congestion should only occur on a local area network where Sysvol replication occurs frequently. Across wide area network links, the inter-site replication schedule will cause these changes to be amalgamated into a smaller amount of traffic (for example, four changes to the Registry.pol file will result in only a single file replication).

The Local Group Policy Object

The Local GPO has no Active Directory component. Information stored in the Group Policy container of an Active Directory GPO is instead stored in the Group Policy template of a Local GPO. The Group Policy template of a Local GPO is located in the Windows\system32\GroupPolicy folder. The Gpt.ini file in this GroupPolicy folder must hold more management information than its counterpart in a domain-based GPO because there is no Active Directory component to hold this information. The following table shows the attributes for the Group Policy template.ini file. Local GPO GPT.INI Attributes

Attribute gPCUserExtensionNames GPCMachineExtensionNames Options

Description

Includes a list of GUIDs that tells the client-side engine which CSEs have User data in the GPO The format is: [{GUID of CSE}{GUID of MMC extension}{GUID of second MMC extension if ap

Includes a list of GUIDs that tells the client-side engine which CSEs have computer data in the Refers to GPO options such as User portion disabled or Computer portion disabled.

The following extensions are disabled in a Local GPO:

Group Policy Software installation extension Folder Redirection

The following extensions have reduced functionality in a Local GPO:

Public Key policies; EFS only; there are not any options for trust lists or auto enrollment. Security Settings; there are not any options for Restricted Groups or File System, Registry or Service Access Control Lists (ACLs).

Core Group Policy Processes and Interactions

Application of GPOs to targeted users and computers relies on many interactive processes. This section explains how GPOs are applied and filtered to Active Directory containers such as sites, domains, and OUs. It includes information about how the Group Policy engine processes GPOs in conjunction with CSEs. In addition, it explains how Group Policy is replicated among domain controllers.

Group Policy Processing Rules

GPOs that apply to a user or computer do not all have the same precedence. Settings that are applied later can override settings that are applied earlier. Group Policy settings are processed in the following order:

Local Group Policy object. Each computer has exactly one Group Policy object that is stored locally. This processes for both computer and user Group Policy processing. Site. Any GPOs that have been linked to the site that the computer belongs to are processed next. Processing is in the order that is specified by the administrator, on the Linked Group Policy Objects tab for the site in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence. Domain. Processing of multiple domain-linked GPOs is in the order specified by the administrator, on the Linked Group Policy Objects tab for the domain in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence. Organizational units. GPOs that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then GPOs that are linked to its child organizational unit are processed, and so on. Finally, the GPOs that are linked to the organizational unit that contains the user or computer are processed.

To summarize, 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. All of this processing is subject to the following conditions:

WMI or security filtering that has been applied to GPOs. Any domain-based GPO (not Local GPO) can be enforced by using the Enforce option so that its policies cannot be overwritten. Because an Enforced GPO is processed last, no other settings can write over the settings in that GPO. If you have more than one Enforced GPO, it's possible to set the same setting in each GPO to a different value, in which case, the link order of the GPOs determines which one 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 policy from Enforced GPOs from applying.

Every computer has a single 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 can't be blocked by domain-based GPOs. However, settings in domain GPOs always take precedence since they are processed after the Local GPO.

Targeting GPOs
The site, domain, and OU links from a GPO are used as the primary targeting principle for defining which computers and users should receive a GPO. Security filtering and WMI filtering can be used to further reduce the set of computers and users to which the GPO will apply. The Group Policy engine uses the following logic in processing GPOs: If a GPO is linked to a domain, site, or OU that applies to the user or computer, the Group Policy engine must then determine whether the GPO should be added to its GPO list for processing. A GPO is blocked from processing in the following circumstances:

The GPO is disabled. You disable either or both the computer or user components of a GPO from its Policy Properties dialog box. The computer or user does not have permission to read and apply the GPO. You control permission to a GPO through security filtering, as explained in the following section. A WMI filter applied to a GPO evaluates to false on the client computer. A WMI filter must evaluate to true before the Group Policy engine will allow it to be processed, as explained in the following section.

Security Filtering
Security filtering is a way of refining which users and computers will receive and apply the settings in a GPO. By using security filtering to specify that only certain security principals within a container where the GPO is linked apply the GPO, you can narrow the scope of a GPO so that it applies only to a single group, user, or computer. Security filtering determines whether the GPO as a whole applies to groups, users, or computers; it cannot be used selectively on different settings within a GPO.

In order for the GPO to apply to a given user or computer, that user or computer must have 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 both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. This is how all authenticated users receive the settings of a new GPO when it is applied to an organizational unit, domain or site. Therefore, the default behavior is for every GPO to apply to every Authenticated User. By default, Domain Admins, Enterprise Admins, and the local system have full control permissions, without the Apply Group Policy access-control entry (ACE). However, administrators are members of Authenticated Users, which means that they will receive the settings in the GPO by default. 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 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.

How Security Filtering is Processed

Before processing a GPO, the Group Policy engine checks the Access Control List ACL associated with the GPO. If an ACE on a GPO denies a security principal to which the computer or user belongs, either the Apply Group Policy or Read permission, the Group Policy engine does not add the GPO to its list of GPOs to process. Additionally, an ACE on a GPO must allow the appropriate security principal both Apply Group Policy and Read permissions in order for the Group Policy engine to add the GPO to the GPO processing list. If appropriate permissions are granted to the GPO, it is added to the list of GPOs to download. In general, Deny ACEs should be avoided because you can achieve the same results by granting or not granting Allow permissions.

Windows Management Instrumentation (WMI) Filtering

WMI makes data about a target computer available for administrative use. Such data can include hardware and software inventory, settings, and configuration information. For example, 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. WMI filtering allows you to filter the application of a GPO by attaching a Windows Query Language query to a GPO. The queries can be written to query WMI for multiple items. If the query returns true for all queried items, then the GPO will be applied to the target user or computer. When a GPO that is linked to a WMI filter is applied on the target computer, 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. Each GPO can have only one WMI filter; however the same WMI filter can be linked to multiple GPOs. WMI filters, like GPOs, are stored only in domains. A WMI filter and the GPO it is linked to must be in the same domain.

How Windows Management Instrumentation (WMI) Filtering is Processed

If, after security filtering, appropriate permissions are granted to the GPO, it is added to the list of GPOs to download. Upon download, the Group Policy engine reads the gPCWQLFilterattribute in the Group Policy container to determine if a WMI filter is applied to the GPO. If so, the WMI filter, which contains one or more WQL statements, is evaluated. If the statement evaluates to true, then the GPO is processed. There are tradeoffs in using WMI filters because they can increase the amount of time it takes to process policy especially if the filter to be evaluated takes a long time to process.

Windows Management Instrumentation (WMI)Filtering Scenarios

Sample uses of WMI filters include:

Services. Computers where DHCP is turned on. Registry. Computers that have this registry key populated. Hardware inventory. Computers with a Pentium III processor. Software inventory. Computers with Visual Studio .NET installed.

Hardware configuration. Computers with network interface cards (NICs) on interrupt level 3. Software configuration. Computers with multi-casting turned on. Associations. Computers that have any services dependent on Systems Network Architecture (SNA) service.

Client support for WMI filters exists only on Windows XP, Windows Server 2003, and later operating systems. Windows 2000 clients will ignore any WMI filter and the GPO is always applied, regardless of the WMI filter. WMI filters are only available in domains that have at least one Windows Server 2003 domain controller.

Application of Group Policy

Application of Group Policy involves a series of processes, beginning with user and computer logon.

Initial Processing of Group Policy

Group Policy for computers is applied at computer startup. For users, Group Policy is applied when they log on. In Windows 2000, the processing of Group Policy is synchronous, which means that computer Group Policy is completed before the logon dialog box is presented, and user Group Policy is completed before the shell is active and available for the user to interact with it. As explained in the following section, Windows XP with Fast Logonenabled (which is the default setting) allows users to log on while Group Policy is processed in the background.)

Synchronous and Asynchronous Processing

Synchronous processes can be described as a series of processes where one process must finish running before the next one begins. Asynchronous processes, on the other hand, can run on different threads simultaneously because their outcome is independent of other processes. You can change the default processing behavior by using a policy setting for each GPO so that processing is asynchronous instead of synchronous. For example, if the policy has been set to remove the Run command from the Start menu, it is possible under asynchronous processing that a user could logon prior to this policy taking effect, so the user would initially have access to this functionality.

Fast Logon in Windows XP Professional

By default in Windows XP Professional, the Fast Logon Optimization feature is enabled for both domain and workgroup members. This means that policy settings apply asynchronously when the computer starts and when the user logs on. This process of applying policies is similar to a background refresh process. As a result, users can logon and begin using the Windows shell faster than they would with synchronous processing. Fast Logon Optimization is always off during logon under the following conditions:

When a user first logs on to a computer. When a user has a roaming user profile or a home directory for logon purposes. When a user has synchronous logon scripts.

Note that under the preceding conditions, computer startup can still be asynchronous. However, because logon is synchronous under these conditions, logon does not exhibit optimization. The following table compares policy processing of Windows 2000 and Windows XP client computers. Default Policy Processing for Client Computers

Client Windows 2000 Windows XP Professional

Application at startup/log on Synchronous Asynchronous

Windows XP clients support Fast Logon Optimization in any domain environment. Fast Logon Optimization can be disabled with the following policy setting: Computer Configuration\Administrative Templates\System\Logon\ Always wait for the network at computer startup and logon.

Note that Fast Logon Optimization is not a feature of Windows Server 2003.

Folder Redirection and Software Installation Policies

Note that when Fast Logon Optimization is on, a user might need to log on to a computer twice before folder redirection policies and software installation policies are applied. This occurs because the application of these types of policies requires the synchronous policy application. During a policy refresh (which is asynchronous), the system sets a flag indicating that the application of folder redirection or a software installation policy is required. The flag forces synchronous application of the policy at the user's next logon.

Time Limit for Processing of Group Policy

Under synchronous processing, there is a time limit of 60 minutes for all of Group Policy to finish processing on the client computer. Any CSEs that are not finished after 60 minutes are signaled to stop, in which case the associated policy settings might not be fully applied.

Background Refresh of Group Policy

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 CSE will only reapply the settings if it detects that a change was made on the server in any of its GPOs or its list of GPOs. In addition, software installation and folder redirection processing occurs only during computer startup or user logon. This is because background processing could cause undesirable results. For example, in software installation, if an application is no longer assigned, it is removed. If a user is using the application while Group Policy tries to uninstall it or if an assigned application upgrade takes place while someone is using it, errors would occur. Although the Scripts CSE is processed during background refresh, the scripts themselves only run at startup, shutdown, logon, and logoff, as appropriate.

Periodic Refresh Processing

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. Group Policy can be configured on a per-extension basis so that a particular extension is always processed during processing of policy even if the GPOs haven't changed. Policy settings for each extension are located in Computer Configuration\Administrative Templates\System\Group Policy.

On-Demand Processing
You can also trigger a background refresh of Group Policy on demand from the client. However, the application of Group Policy cannot be pushed to clients on demand from the server.

Messages and Events

When Group Policy is applied, a WM_SETTINGCHANGE message is sent, and an event is signaled. Applications that can receive window messages can use them to respond to a Group Policy change. Those applications that do not have a window to receive the message (as with most services) can wait for the event.

Refreshing Policy from the Command Line

You can update or refresh Group Policy settings manually through a command line tool. On Windows 2000, you can use Secedit with the /refreshpolicy option; on Windows XP and Windows Server 2003, you can use Gpupdate.

Group Policy and Slow Links

When Group Policy detects a slow link, it sets a flag to indicate to CSEs that a policy setting is being applied across a slow link. Individual CSEs can determine whether or not to apply a policy setting over the slow link. The default settings are as follows: Default Slow Link Settings

Extension Security Settings Administrative Templates

Default Setting On (and cannot be turned off) On (and cannot be turned off)

Software Installation Scripts Folder Redirection

Off Off Off

Group Policy Loopback Support

Group Policy is applied to the user or computer, based on where the user or computer object is located in Active Directory. However, in some cases, users might need policy applied to them, based on the location of the computer object, not the location of the user object. The Group Policy loopback feature gives you the ability to apply User Group Policy, based on the computer that the user is logging onto. The following figure shows a sample site, domain, and OU structure and is followed by a description of the changes that can occur with loopback processing. Sample Active Directory Structure

Normal user Group Policy processing specifies that computers located in the Servers organizational unit have the GPOs A3, A1, A2, A4, and A6 applied (in that order) during computer startup. Users of the Marketing organizational unit have GPOs A3, A1, A2, and A5 applied (in that order), regardless of which computer they log on to. In some cases this processing order might not be what you want. An example is when you do not want applications that have been assigned or published to the users of the Marketing organizational unit to be installed while they are logged on to the computers in the Servers organizational unit. With the Group Policy loopback feature, you can specify two other ways to retrieve the list of GPOs for any user of the computers in the Servers organizational unit:

Merge mode. In this mode, the computers GPOs have higher precedence than the user's GPOs. In this example, the list of GPOs for the computer is A3, A1, A2, A4, and A6, which is added to the user's list of A3, A1, A2, A5, resulting in A3, A1, A2, A5, A3, A1, A2, A4, and 9A6 (listed in lowest to highest priority). Replace mode. In this mode, the user's list of GPOs is not gathered. Only the list of GPOs based upon the computer object is used. In this example, the list is A3, A1, A2, A4, and A6.

The loopback feature can be enabled by using the User Group Policy loopback processing mode policy under Computer Settings\Administrative settings\System\Group Policy. The processing of the loopback feature is implemented in the Group Policy engine. When the Group Policy engine is about to apply user policy, it looks in the registry for a computer policy, which specifies which mode user policy should be applied in.

How the Group Policy Engine Processes Client-Side Extensions

Client-side extensions are the components running on the client system that process and apply the Group Policy settings to that system. There are a number of extensions that are pre-installed in Windows Server 2003. Other Microsoft applications and third party application vendors can also write and install additional extensions to implement Group Policy management of these applications. The default Windows Server 2003 CSEs are listed in the following table:

Default Windows Server 2003 CSEs

Client-Side Extension Software Installation Security Settings Folder Redirection Scripts IP Security Internet Explorer Maintenance Administrative Templates Disk Quota EFS Recovery Remote Installation Wireless Network Policies QoS Packet Scheduler

Active Directory Component PackageRegistration objects

IPSec Policy objects

Client-Side Extension Operation

CSEs are called by the Winlogon process at computer startup, user logon and at the Group Policy refresh interval. CSEs are registered with Winlogon in the registry. This registration information includes a DLL and a DLL entry point (function call) by which the CSE processing can be initiated. The Winlogon process uses these to trigger Group Policy processing. Each extension can opt not to perform processing at any of these points (for example, avoid processing during background refresh).

Client-Side Extensions Registered with WinLogon

Each of the CSEs is registered under the following key: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions Each extension is identified by a key named after the GUID of the extension. These extensions are shown in the following table. CSE Extensions

Extension GUID 25537BA6-77A8-11D2-9B6C-0000F8080861 35378EAC-683F-11D2-A89A-00C04FBBCFA2 3610EDA5-77EF-11D2-8DC5-00C04FA31A66 426031c0-0b47-4852-b0ca-ac3d37bfcb39 42B5FAAE-6536-11D2-AE5A-0000F87571E3 827D319E-6EAC-11D2-A4EA-00C04F79F83A A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A C6DC5466-785A-11D2-84D0-00C04FB169F7 E437BC1C-AA7D-11D2-A382-00C04F991E27

Extension Name Folder Redirection

Administrative Templat Disk Quotas QoS Packet Scheduler Scripts Security

Internet Explorer Maint EFS Recovery Software Installation IP Security

How Group Policy Processing History Is Maintained on the Client Computer

Each time GPOs are processed, a record of all of the GPOs applied to the user or computer is written to the registry. GPOs applied to the local computer are stored in the following registry path: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History GPOs applied to the currently logged on user are stored in the following registry path: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

Preferences and Policy Configuration

Manipulating these registry values directly is not recommended. Most of the items in which you might need to change the behavior of an extension (such as forcing a CSE to run over a slow link), are available as Group Policy settings. These can be found in the Group Policy Object Editor in the following location: Computer Settings\Administrative Templates\System\Group Policy The behavior can be changed for the following CSEs:

Administrative Templates (Registry-based policy) Internet Explorer Maintenance Software Installation Folder Redirection Scripts Security IP Security EFS recovery Disk Quotas

Order of Extension Processing

Administrative Templates policy settings are always processed first. Other extensions are processed in an indeterminate order.

Policy Application Processes

There are two primary milestones that the Group Policy engine uses for GPO processing:

Creating the list of GPOs targeted at the user or computer. Invoking the relevant CSEs to process the policy settings relevant to them within the GPO list.

The following figure shows the steps required to reach the first milestone in GPO processing, GPO list creation. GPO List Creation

Creating the GPO list involves the following steps:

1. 2.
3.

Query the Active Directory for the gPLink and gPOptions properties in the Site and Domain hierarchies to which the user or computer object belongs. Query the Active Directory for the GroupPolicyContainer objects referenced in the gPLink properties. Evaluate security filtering to determine if the user or computer have the Apply Group Policy access permission to the GPO. Evaluate the WMI query against the WMI repository on the client computer to determine if the computer meets the query requirements.

4.

Once the GPO list is created, the Group Policy engine and the CSEs work together to process Group Policy template components. The following figure shows the steps required to determine which CSEs to call. Determining CSEs to Call

Determining which CSEs to call involves the following steps: 1. 2. Retrieve the list of CSEs registered with Winlogon. Check to see whether it is appropriate to run a particular CSE (for example, whether background processing or slow link processing is enabled for the extension). Check the CSE history against list of Applied GPOs. GPOs with new version numbers and GPOs that have settings relevant to the CSE (that is, they have the CSE extension GUID in the Group Policy container gpcUserExtension or gpcMachineExtension properties) are added to the Changed GPO List. GPOs no longer in the Applied GPO List are added to the Deleted GPO List. Check to see whether the appropriate CSE should be processing policy settings for the user or the computer. Check the version number listed in the GPO against its recorded version history in the registry to determine whether the GPO needs reprocessing.

3.

4.

5.

If all of the version numbers are unchanged the MaxNoGPOListChanges interval might have expired; if so, the CSE processes policy settings without regard to an unchanged version number. Steps 3 through 5 are repeated by each CSE for all GPOs in the GPO list. After one CSE is done, the next CSE that needs to run repeats the entire process. Group Policy updates are dynamic and occur at specific intervals. If there have been no changes to Group Policy, the client computer still refreshes the security policy settings at regular intervals for the GPO. If no changes are discovered, GPOs are not processed. Security policies have a periodic force apply every 16 hours. For security policies, there is a value that sets a maximum limit of how long a client can function without reapplying non-changed GPOs. By default, this setting is every 16 hours plus a randomized delay of up to 30

minutes. Even when GPOs that contain security policy settings do not change, the policy is reapplied every 16 hours

Group Policy Replication

In a domain that contains more than one domain controller, Group Policy information takes time to propagate, or replicate, from one domain controller to another. Low bandwidth network connections between domain controllers slow replication. The Group Policy infrastructure has mechanisms to manage these issues. Each GPO is stored partly in the Sysvol on the domain controller and partly in Active Directory. GPMC and Group Policy Object Editor present and manage the GPO as a single unit. For example, when you set permissions on a GPO in GPMC, GPMC is actually setting permissions on objects in both Active Directory and the Sysvol. It is not recommended that you manipulate these separate objects independently outside of GPMC and the Group Policy Object Editor. As shown in the following figure, it is important to understand that these two separate components of a GPO rely on different replication mechanisms. The file system portion is replicated through FRS, independently of the replication handled by Active Directory. Only the Sysvol subfolder (%systemroot%\SYSVOL\sysvol) is shared and replicated. Sysvol was designed to allow multiple domains Sysvols to be replicated in the same tree each domains Sysvol is contained under a subfolder of the Sysvol share. For the current domain, a copy of the domains Sysvol subtree is also stored directly under the %systemroot%\SYSVOL\domain folder. Group Policy Replication

FRS is a multi-master replication service that synchronizes folders between two or more Windows Server 2003 or Windows 2000 systems. Modified files are queued for replication at the point the file is closed. In the case of conflicting modifications between two copies of an FRS replica, the file with the latest modification time will overwrite any other copies. This is referred to as a last-writer-wins model. FRS replication topology configuration is stored as a combination of child objects of each FRS replica partner (in the FRS Subscriptions subcontainer) and objects within another hidden subcontainer of the domain System container. Replication links between systems are maintained as FRS subscription objects. These objects specify the replica partner and the replication schedule. It is possible to view the schedule by browsing to an FRS subscription object and viewing the properties. The replica partner is stored as the object GUID of the computer account of that partner. The Sysvol folder is a special case of FRS replication. Active Directory automatically maintains the subscription objects and their schedules as the directory replication is built and maintained. It is possible, but not recommended, to modify the properties (for example, the schedule) of the Sysvol subscription objects manually. The FRS replication schedule only approximates to the directory replication schedule so it is possible for the directory-based Group Policy information and the file-based information to get temporarily out of synch. Since GPO version information is stored in both the Group Policy container object and in the Group Policy template, any discrepancy can be viewed with tools such as Gpotool.exe and Repadmin.exe. For those Group Policy extensions that store data in only one data store (either Active Directory or Sysvol), this is not an issue, and Group Policy is applied as it can be read. Such extensions include Administrative Templates, Scripts, Folder Redirection, and most of the Security Settings. For any Group Policy extension that stores data in both storage places (Active Directory and Sysvol), the extension must properly handle the possibility that the data is unsynchronized. This is also true for extensions that need multiple objects in a single store to be atomic in nature, since neither storage location handles transactions.

An example of an extension that stores data in Active Directory and Sysvol is Group Policy Software installation extension. The .aas files are stored on Sysvol and the Windows Installer package definition is in Active Directory. If the .aas file exists, but the corresponding Active Directory components are not present, the software is not installed. If the .aas file is missing, but the package is known in Active Directory, application installation fails gracefully and will be retried on the next processing of Group Policy. The tools used to manage Active Directory and Group Policy, such as GPMC, the Group Policy Object Editor, and Active Directory Users and Computers all communicate with domain controllers. If there are several domain controllers available, changes made to objects like users, computers, organizational units, and GPOs might take time to appear on other domain controllers. The administrator might see different data depending on the last domain controller on which changes were made and which domain controller they are currently viewing the data from. If multiple administrators manage a common GPO, it is recommended that all administrators use the same domain controller when editing a particular GPO, to avoid collisions in FRS. Domain Admins can use a policy to specify how Group Policy chooses a domain controller that is, they can specify which domain controller option should be used. The Group Policy domain controller selection policy setting is available in the Administrative Templates node for User Configuration, in the System\Group Policy subcontainer.

Network Ports Used by Group Policy

Port Assignments for Group Policy

Service Name Lightweight Directory Access Protocol SMB DCOM RPC

UDP n/a n/a Dynamicallly assigned Dynamically assigned

Core Group Policy Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section

Group Policy Tools Group Policy Settings Group Policy WMI Classes Related Information

This section summarizes the tools and settings associated with Group Policy.

Group Policy Tools

The following is a list of administrative tools associated with Group Policy. For more information about Group Policy administrative tools, see the following topics in this collection:

Group Policy Administrative Tools Group Policy Object Editor Tools and Settings Group Policy Management Console Technical Reference What Is Resultant Set of Policy?

For information about tools specific to Group Policy extensions, see the appropriate Group Policy Components topics in this collection. For more information about other Resource Kit tools, see the Windows Server 2003 Deployment Kit Tools page. GPUpdate.exe This tool is used for refreshing local and Active Directory policy settings on the computer from which you run the GPUpdatecommand. Category This command-line tool is included in Windows XP and Windows Server 2003. Version compatibility You can use GPUpdate locally on Windows XP and higher computers to refresh policy immediately. On computers running Windows 2000, this behavior is provided by the using the secedit.exe command line tool, with a specific parameter. GPUpdate refreshes local Group Policy settings and Group Policy settings that are stored in Active Directory, including security settings, on the computer from which it is run. This command supersedes the now obsolete /refreshpolicy option for the secedit command line tool. For more information about GPUpdate, type GPUpdate /? at the command line. GPResult.exe GPResult.exe is a Group Policy tool for examining the settings applied during Group Policy refresh. Category There are two versions of GPResult: One shipped with the Windows 2000 Resource Kit; the other is included with Windows XP and Windows Server 2003. The Windows 2000 version runs only locally on Windows 2000. The windows Server 2003 version runs locally or remotely on Windows XP or Windows Server 2003. The different versions are not compatible. Version compatibility GPResult utilizes Resultant Set of Policy (RSoP) data. You can use GPResult that shipped with Windows Server 2003 family on Windows XP and higher computers. You can use GPResult that shipped with Windows 2000 Resource Kit for Windows 2000. GPResult for Windows Server 2003 displays Group Policy settings and Resultant Set of Policy (RSoP) for a user or a computer. Because you can apply overlapping levels of policies to any computer or user, the Group Policy feature generates a resulting set of policies at logon. GPResult displays the resulting set of policies that were enforced on the computer for the specified user at logon. GPResult for Windows 2000 estimates the Group Policy settings that would be applied at a specific computer. Full documentation for this version of GPResult is available in the readme file distributed with the tool. Dcgpofix.exe: Dcgpofix Category Dcgpofix ships with Windows Server 2003. Version compatibility You can run Dcgpofix only on servers running Windows Server 2003 family. This tool can restore default domain policy and default domain controllers policy to their original state after installation, except for some securityrelated settings that are impossible to return to their exact original state. When you run Dcgpofix, you will lose any changes made to these Group Policy objects. For more information about Dcgpofix, type Dcgpofix /? at the command line. This tool should be used as a last-resort disaster-recovery tool. A better solution is to use GPMC to back up and restore these GPOs. GPMonitor.exe: Group Policy Monitor Tool Category Group Policy Monitor tool is included in the Windows Server 2003 Deployment Kit. Version compatibility The Group Policy Monitor tool works on Windows XP and higher computers. Group Policy Monitor tool collects Group Policy information at every Group Policy refresh and sends that information to a centralized location that you specify. You can then use the Group Policy Monitor user interface (UI) to view the data. The Group Policy Monitor UI can provide a historical view of policy changes. The UI is also designed to make it easy to navigate through historical snapshots of data and trace changes. For more information about the Group Policy Monitor tool, type GPMonitor /? at the command line. You can find full documentation for the Group Policy Monitor tool in the Windows Server 2003 Deployment Kit Tools.

GPOTool.exe: Group Policy Verification Tool Category Group Policy Verification tool is included in the Windows Server 2003 Deployment Kit. Version compatibility The Group Policy Verification tool works on Windows 2000 and higher computers. You use Group Policy Verification tool to check the health of the Group Policy objects on domain controllers. The tool checks GPOs for consistency on each domain controller in your domain. The tool also determines whether the policies are valid and displays detailed information about replicated Group Policy objects (GPOs). GPOTool.exe ships with the Microsoft Windows 2003 Server Resource Kit and is also available as a free download at the Gpotool.exe: Group Policy Verification Tool page. For more information about the Group Policy Verification tool, type GPOTool /? at the command line. You can find full documentation for Group Policy Verification tool in the Windows Server 2003 Deployment Kit Tools. AdmX.exe: ADM File Parser Category The ADM File Parser (AdmX) is a command-line tool that enables an administrator to export Group Policy settings to a tab-delimited text file. The administrator can then use the text produced by ADM File Parser (AdmX) to find changes for the policy settings between different versions of the operating systems. AdmX is for use only with policies based on administrative templates. Version compatibility The AdmX.exe tool runs on Windows 2000, Windows Server 2003, and Windows XP Professional. AdmX.exe also requires the Microsoft .NET Framework 1.0. Administrators use AdmX.exe to extract policy setting information from .adm files and to list differences between two .adm files. For more information about the ADM File Parser, type AdmX.exe /? at the command line. Other Tools For information about tools specific to Group Policy extensions, see the appropriate Group Policy Components Tools topics in this collection.

Group Policy Settings

Many Group Policy settings are configurable within the Administrative Template (.adm) files supplied with Windows 2000 and Windows Server 2003. Administrators can access these files from the Group Policy Object Editor for a specific GPO, and can configure Group Policy settings contained in the template files. A registry setting exists for a Group Policy template setting only when the setting state has been changed from Not Configuredto either Enabled or Disabled. You can change the setting state from the appropriate Administrative Template node in the Group Policy Object Editor. To download a complete reference to the Group Policy settings in the .adm files supplied with Windows Server 2003, see the Group Policy Settings Reference for Windows Server 2003. This reference is in Microsoft Excel spreadsheet format. For a reference to settings specific to Group Policy behavior, and for a list of registry locations that are associated with Group Policy on the domain controller, target, or both, see the Group Policy Object Editor Tools and Settings topic in this collection. For a reference to settings specific to Group Policy extensions, see the appropriate Group Policy Components topics in this collection.

Group Policy WMI Classes

For complete information about WMI classes associated with Group Policy, see the WMI SDK documentation on MSDN.

Related Information
The following resources contain additional information that is relevant to this section.

The Group Policy Administrative Tools topic in this collection. The Group Policy Object Editor Tools and Settings topic in this collection.

The What Is Group Policy Management Console? topic in this collection. The What Is Resultant Set of Policy? topic in this collection. The appropriate Group Policy Components Tools topics in this collection. The Group Policy Management Console page. The Group Policy Settings Reference for Windows Server 2003. The Microsoft Platform SDK page. The Windows Server 2003 Deployment Kit Tools page. The Tools and Settings Collection.

Group Policy Components

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Group Policy Components

Depending on the size and complexity of the organization, administrators must set, maintain, and manage various standard configurations for groups of users and computers. Users may require specialized software or have unique needs, such as the ability to always work remotely. Client computers must be set up for specific purposes with configurations for kiosks, labs, general office use, and other roles. Group Policy is the infrastructure that enables you to deliver and apply these and other configurations to targeted users and computers within an Active Directory directory service environment. The Group Policy infrastructure consists of a Group Policy engine and various individual components known as client-side extensions that plug into the infrastructure. These client-side 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, wireless network settings, and other areas. Group Policy settings are contained in Group Policy objects (GPOs) that are applied to users and computers. Group Policy components provide you with the means of enforcing and maintaining a wide variety of configurations, thereby reducing the risk of disruption in your computing environment. In addition, the Group Policy infrastructure is designed to be flexible and extensible, allowing you to develop your own extensions, if desired. You administer Group Policy components using two primary tools. The first tool is Group Policy Management Console (GPMC), which lets you create, view, and manage GPOs. The second tool is Group Policy Object Editor, which which lets you configure and modify settings within GPOs.

Group Policy Component Architecture

Group Policy settings are implemented by a variety of components. There are two basic types of components:

Extensions that allow you to administer and configure Group Policy settings using Group Policy Object Editor. These are server-side snap-ins that are extensions to the Microsoft Management Console (MMC) snap-in. Extensions that interpret Group Policy settings and apply them on the client computer. These are extensions to the logon process Winlogon and are known as client-side extensions.

Group Policy Component Architecture

Group Policy Components Server Side MMC Snap-in Extensions You configure Group Policy settings using Microsoft Management Console (MMC) snap-ins. The snap-in provides the basic organization of the Group Policy Object Editor and the top-level namespace (Software Settings, Windows Settings, and Administrative Templates). There are server-side snap-in extensions for most of the client-side extensions shown in the figure earlier. However, some client-side extensions, such as Disk Quotas, do not require separate server side snap-ins. In many cases client-side extensions only require registry settings to be transferred to the client system and these can be configured using the Administrative Templates snap-in. Server-side snap-in extensions include:

Administrative Templates. Security Settings. IP Security. Scripts. Software Installation. Internet Explorer Maintenance.

All MMC snap-ins and extensions are registered under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\Nodetypes
Each extension may have further child extensions. In this way, Group Policy Object Editor consists of an extensible tree of administrative components. This allows components to be updated or new components to be added without affecting other components. Client-Side Extensions Client-side extensions are the components running on the client system that process and apply the Group Settings to that system. There are a number of extensions that are preinstalled in Windows Server 2003. Other Microsoft applications and third-party application vendors can also write and install additional extensions to implement Group Policy management of these applications. The default CSEs are listed in the following table.

Default Client-Side Extensions

Client-Side Extension Administrative Templates Software Installation Security Settings Folder Redirection Scripts IP Security Internet Explorer Maintenance Disk Quotas EFS Recovery Remote Installation QoS Packet Scheduler

Active Directory Component

Sysvol Component Registry.pol (+ .adm)

PackageRegistration objects

.aas files Gptmpl.inf fdeploy.ini Scripts

IPSec Policy objects .ins and branding .inf files. Registry.pol Registry.pol Oscfilter.ini Registry.pol and .adm files.

Client-side extensions are implemented within DLLs that are installed and registered on the client computer during operating system installation. To trigger Group Policy processing, the Group Policy engine running within Winlogon calls each CSE DLL using the CSE registration settings contained below the Winlogon key in the registry. Each of the CSEs is registered under the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows

NT\CurrentVersion\Winlogon\GPExtensions Group Policy Component Scenarios

Group Policy is used to define configurations for groups of users and computers. With Group Policy, administrators can specify Group Policy settings for registry-based policies, security, software installation, scripts, folder redirection, remote installation services, and Internet Explorer maintenance. Group Policy settings are contained in a GPO. By linking a GPO with selected Active Directory system containerssites, domains, and organizational units the GPO's Group Policy settings are applied to the users and computers in those Active Directory containers. Administrative Templates Administrative Templates enable administrators to control registry settings using Group Policy, providing the means to configure the behavior and appearance of the desktop, including the operating system, components, and applications. Windows comes with a predefined set of Administrative Template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a GPO. These .adm files are stored in two locations by default: inside GPOs in theSysvol folder and in the %windir%\inf directory on the local computer. Administrative Templates Group Policy settings are also referred to as .adm settings or registry-based settings. As new versions of Windows are released, new Administrative Templates policy settings are added. In addition to supporting these new settings, each successive version of Windows supports all registry policy settings that were available in earlier versions of Windows. For example, the Windows Server 2003 family of operating systems supports all Administrative Templates policy settings available in Windows 2000 and Windows XP. Security Settings You can define security settings that are enforced on any number of computers, by using the Security Settings extension of Group Policy. By specifying the security configuration of a Group Policy object (GPO), you can affect the computers in a site, domain, or organizational unit to which the GPO is linked. You can configure the following types of security settings:

Account Policies. This includes settings for Password Policy, Account Lockout Policy, and Kerberos Policy. Local Policies. This includes settings for Audit Policy, User Rights Assignment, and Security Options. Event Log. This includes settings for application, system, and security Event Log settings. Restricted Groups. This specifies policies for membership of security-sensitive groups.

System Services. This specifies policies for startup and permissions for system services. Registry. This includes policies that specify permissions for registry keys. File System. This includes policies that specify permissions for folders and files.

IP Security Policy Internet Protocol security (IPSec) is a framework of open standards designed to ensure private, secure communications over Internet Protocol (IP) networks, through the use of cryptographic security services. IPSec supports network-level data integrity, data confidentiality, data origin authentication, and replay protection. In an Active Directory environment, you can use Group Policy to centralize IPSec policy distribution and management. You can use the IP Security Policies snap-in to configure IPSec policies to meet the security requirements of a user, group, application, domain, site, or global organization. You can also specify IPSec policies on a local computer that is not a member of a domain. Software Restriction Policies The Windows Server 2003 family of operating systems and Windows XP include software restriction policies, a new policy-based feature that identifies software programs running on computers in a domain, and controls the ability of those programs to run. Software restriction policies are a part of Microsofts security and management strategy to assist enterprises in increasing the reliability, integrity, and manageability of their computer networks. You can specify software restriction policies in an Active Directory environment or on a local computer. You can use Software Restriction Policies to:

Fight viruses. Regulate which ActiveX controls can be downloaded. Run only digitally signed scripts. Enforce that only approved software is installed on system computers. Highly restrict (lock down) a computer.

Wireless Network Policies A new Wireless Network (IEEE 802.11) Policies Group Policy extension allows you to configure wireless network settings that are part of Group Policy for Computer Configuration. Wireless network settings include the list of preferred networks, Wired Equivalent Privacy (WEP) settings, and IEEE 802.1X settings. These settings are downloaded to targeted domain members, making it much easier to deploy a specific configuration for secure wireless connections to wireless client computers. Public Key Policies These Group Policy settings are used to:

Specify that computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate. Create and distribute a certificate trust list. Establish common trusted root certification authorities. Add encrypted data recovery agents and change the encrypted data recovery policy settings.

Software Installation The Software Installation snap-in is used to centrally manage software. Software can be assigned or published to users and assigned to computers. Group Policy-based Software Installation can be used to install software applications when a computer is started, when the user logs on, or on demand. Software installation Group Policy settings can be applied to users or computers in an Active Directory structure. Group Policy-based Software Installation can also be used to upgrade deployed applications or remove earlier applications that are no longer required. Users can be restricted from installing any software from local media, such as a CD-ROM, or disk, or other unapproved applications.

Medium and large organizations may wish to consider using Microsoft Systems Management Server (SMS). SMS provides advanced capabilities such as inventory-based targeting, status reporting, server- and client-side scheduling, multisite facilities, complex targeting, centralized hardware and software inventory, remote diagnostic tools, software metering, software distribution-point population and maintenance, support for Windows 95, Windows 98, Windows NT 4.0, Windows 2000, and Windows XP clients, and enhanced software deployment features. SMS does not require Active Directory. Remote Installation Services Remote Installation Services (RIS) is an optional component that is included in the Windows Server operating system and works with other Windows Server 2003 technologies to implement the Remote Operating System Installation feature. Administrators use Remote Operating System Installation to remotely install a copy of the Windows XP Professional operating system on supported computers. Administrators use the RIS extension of Group Policy to specify which options are presented to users by the Client Installation Wizard, for example, Automatic Setup, Custom Setup, and Restart Setup. Scripts Scripts are used to automate tasks at computer startup and shutdown, and at user logon and logoff. Scripts can be written in any language supported by Windows Script Host including the Microsoft Visual Basic development system, Scripting Edition (VBScript), JavaScript, PERL, and MS DOS-style batch files (.bat and .cmd). Internet Explorer Maintenance Internet Explorer Maintenance is used to manage and customize Internet Explorer on computers running Windows 2000 or later. Administrators can set options for the Browser UI, connections, URLs, proxy settings, security zones, Favorites, and Internet Explorer Enhanced Security Configuration component (also known as Microsoft Internet Explorer hardening). Folder Redirection Folder redirection is used to redirect special directories on Windows 2000 or Windows Server 2003 from their default user profile location to an alternate location on the network. These special folders include My Documents, Application Data, Desktop, and the Start menu. Disk Quotas Disk quotas provide a way to limit each users utilization of disk space on a volume. Disk quotas are implemented as part of the NTFS File System. Disk quota settings are read from the registry at startup and during GPO processing. Disk Quotas are configured through the Administrative Templates snap-in and are stored in the registry.pol GPO registry settings file there is no GPO snap-in for disk quotas. The Disk Quota CSE retrieves the resultant setting from the client systems registry and configures the disk quota parameters accordingly. Prioritization of multiple GPO settings is handled by the Administrative Templates CSE. QoS Packet Scheduler Quality of service (QoS) allows you to use your existing resources efficiently and guarantee that critical applications receive high-quality service, without having to expand as quickly or even over-provision your networks. Quality of Service parameters are configured as registry settings using the Administrative Templates snap-in. The QoS Packet Scheduler CSE reads these settings from the registry and configures the Packet Scheduler service on the client system with these parameters.

Administrative Templates Extension Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 The Administrative Templates extension consists of a Microsoft Management Console (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. Although other Group Policy extensions manipulate the registry to implement policy settings, the Administrative Templates Extension exists specifically for registry-based policy. In this subject

What Is Administrative Templates Extension? How Administrative Templates Extension Works Administrative Templates Extension Tools and Settings

What Is Administrative Templates Extension?

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section

Core Scenarios for Administrative Templates Extension Related Information

The Administrative Templates Extension is the largest of all available Group Policy extensions and includes more than 700 policy settings for applications and operating system components. These policy settings are applied by modifying the registry on target clients. Administrative Templates policy settings is also referred to as registrybased policy or simply registry policy. Administrators need a simple way to configure policy settings and apply those changes to many users and computers throughout the network. You need to be able to modify policy settings quickly and be able to delete policy settings and remove them from all target computers without the risk of old policy settings remaining in the registry. In addition, developers need a way to integrate policy management into new applications. Administrative Templates provides dynamic management capabilities to administrators and an infrastructure for developers to policy-enable their applications. The Administrative Templates Extension consists of a server-side snap-in that is loaded by default in Group Policy Object Editor and a client-side extension that writes policy settings that manipulate registry keys on target client computers. The server-side snap-in loads a predefined set of Administrative Template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a Group Policy object (GPO). .Adm files are Unicode files which consist of a hierarchy of categories and subcategories that define how the options are displayed through the Group Policy Object Editor and GPMC. They also indicate the registry locations where changes should be made if a particular selection is made, specify any options or restrictions (in values) that are associated with the selection, and in some cases, indicate a default value to use if a selection is activated. Its important to note that the functionality of .adm files is limited. The only purpose of .adm files is to enable a user interface to configure policy settings. .Adm files do not contain actual policy settings; these are contained in registry.pol files located in the Sysvol on domain controllers.

Core Scenarios for Administrative Templates Extension

You use Administrative Templates Extension to modify and remove registry-based policy settings. Developers can create .adm files to integrate policy settings management into their applications. Manipulating Administrative Template Extension Policy Settings The Administrative Templates server-side snap-in provides an Administrative Templates node that appears twice in Group Policy Object Editor; once under the Computer Configuration node, and again under the User Configuration node. The settings under the computer node manipulate registry settings for the computer, while settings under the user node manipulate registry settings for users. Although some policy settings require simple UI elements, such as text boxes to enter values, most settings contain only the following options:

Enabled Disabled Not configured

The default setting is not configured, so you only need to decide whether to turn the setting on or to turn it off. Administrative Templates provide administrators with a Group Policy interface for the DSQ and QoS CSEs, among others. Removing Policy Settings Implemented by Administrative Template Extension In addition to being easy to set, administrators can also easily remove default registry-based policy settings implemented with Administrative Templates Extension. This is accomplished by having all default registry-based policy settings from Windows 2000 or later stored in one of four specific registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\policies (preferred location) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies HKEY_CURRENT_USER\SOFTWARE\policies (preferred location)

HKEY_ CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

Policy settings that are stored in these locations are known as true policies. Registry keys used for true policy are secured so they cannot be modified by a non-administrator. More importantly, when Group Policy changes, for any reason, all settings from these registry keys are removed, and new registry keys are written based on the policy settings in the GPO. This prevents the behavior that was often present in Windows NT 4.0, whereby System Policies resulted in persistent settings in the user and computer registry. The policy remained in effect until the value was reversed, either by a counteracting policy or by editing the registry. Persistent policy settings persist because they are stored outside the approved registry locations. These types of settings are known as preferences. All the policy settings in the default administrative template files manipulate settings under the approved registry keysresulting in true policy settings. This means that they will not cause persistent settings in the registry when the GPO that applies them is no longer in effect. By default, Group Policy Object Editor only displays true policy settings. Default Administrative Template Files Windows Server 2003 includes the following administrative template files: System.adm, Inetres.adm, Conf.adm, Wmplayer.adm, and Wuau.adm, which contain all the settings initially displayed in the Administrative Templates node. These administrative template files are stored in two locations by default: inside GPOs in the Sysvol folder and in the Windows\inf directory on the local computer. As new versions of Windows are released, new policy settings are added. In addition to supporting these new settings, each successive version of Windows supports all registry policy settings that were available in earlier versions of Windows. For example, the Windows Server 2003 family supports all registry policy settings available in Windows 2000 and Windows XP. On Windows XP and Windows Server 2003, each registry setting contains a Supported on tag that indicates which operating system versions support that policy setting. If a setting is specified and deployed to a client operating system that does not support that setting, the settings are ignored. Because all successive iterations of administrative template files include settings from earlier versions, and because there is no harm if a new setting is applied inadvertently to a computer running an earlier operating system that does not support that setting, it is recommended to always create and edit GPOs from a computer that has the latest administrative template files available. Extending Registry-Based Policy with Administrative Template Files If a developer needs to provide policy settings specific to an application, they can extend registry-based policy by using administrative template files. The Administrative Templates Extension to Group Policy provides this capability. Developers can specify that that Administrative Templates Extension writes settings under the secure registry keys to create true policy settings; these policy settings are designed to be manipulated by an administrator using Group Policy Object Editor. Developers can also specify that the application write policy settings outside the secure registry keys to create preferences; these settings are designed to be manipulated by end-users working from within the developers application. The Group Policy settings set by administrators take precedence over user preferences. Because Group Policy stores the policy settings set by administrators under the approved Group Policy keys, users cannot change or disable these policy settings.

Related Information
The following contains additional information that is relevant to this section.

Group Policy Settings Reference in the Tools and Settings Collection

How Administrative Templates Extension Works

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 Administrative Templates are the primary means of configuring the client computers registry settings through Group Policy. Organizations benefit the most by using Administrative Templates policy settings in a Windows Server 2003 environment with Active Directory installed and Windows XP client computers. In this section

Administrative Templates Extension Architecture

Administrative Templates Extension Physical Structure Administrative Templates Extension Processes and Interactions Network Ports Used by Administrative Templates Extension Related Information

Administrative Templates Extension Architecture

The following diagram shows how components interact in implementing Administrative Templates policy settings. Administrative Templates Extension Architecture

Components and protocols significant to Administrative Templates Extension are included in the following table. Administrative Templates Components

Component Administrator Domain controller

Description The computer that you use to configure Administrative Templates policy settings in Local Group Policy Editor or Group Policy Management Console (GPMC). The server that contains a writable copy of the Active Directory database, participates in Active Directory replication, and controls access to network resources. Each domain controller contains:

The Group Policy container (GPC), which stores information about GPO properties in Active Directory. The Group Policy template (GPT), which stores GPO data in the Sysvol. Data includes the Registry.pol file that stores Administrative Templates policy settings. Target client Registry The computer(s) to which you intend to apply Administrative Templates policy settings. A database repository for information about a computers configuration, the registry is organized

hierarchically as a tree, and is made up of keys and their subkeys, hives, and entries. Administrative Templates Extension directly modifies registry keys in order to configure Machine and User policy settings. Administrative Templates Snap-in Extension Administrative Templates clientside extension The MMC server-side snap-in extension used to configure and modify Administrative Templates-based policy settings. The snap-in is contained within userenv.dll located in Windows\System32\. It appears in Local Group Policy Editor or GPMC as a node under Computer Configuration and User Configuration. Administrative Templates client-side extension runs inside userenv.dll and is responsible for modifying the registry according to the Administrative Template policy settings that you configure in Local Group Policy Editor or GPMC. Userenv.dll is registered at the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. This is the location of all Group Policy CSE registration. A requirement for implementing domain-based Group Policy, Active Directory provides the containers in which you link Group Policy objects (GPOs). The framework that handles functionalities across client-side extensions (CSEs). The Group Policy engine invokes the Administrative Templates client-side extension with a list of GPOs to be applied. The Event log is a service, located in Event Viewer, which records events in the system, security, and application logs. The NTFS file system on client computers.

Active Directory Group Policy engine Event log File system

Group Policy object Administrative Templates policy settings are contained in GPOs, which can then be linked to Active Directory containers such as sites, domains, and OUs. Local Group Policy object The GPO stored on each individual computer in the hidden %systemroot%\System32\GroupPolicy directory. Although you can configure Administrative Templates policy settings in local GPOs, they are the least influential GPOs in an Active Directory environment, because Active Directory-based GPOs have precedence. Any time the registry extensions (client or server) access any information about the Sysvol, or any other domain resource, authentication traffic is generated to the Active Directory. Kerberos is an authentication mechanism used to verify user or host identity. The Kerberos V5 authentication protocol is the default authentication service. Administrative Templates client-side extension communicates with Active Directory using Kerberos. A security package that provides authentication between clients and servers. NTLM is also used by Administrative Templates client-side extension to communicate with Active Directory. Windows Management Infrastructure (WMI) is a management infrastructure that supports monitoring and controlling of system resources through a common set of interfaces and provides a logically organized, consistent model of Windows operation, configuration, and status. Each computer contains a WMI database that stores information about policy settings. WMI makes data about a target computer available for administrative use. The actual Administrative Templates policy settings that are in effect on a client computer (known as Resultant Set of Policy or RSoP) is periodically updated. During processing, the Administrative Templates CSE writes the processing data to the RSoP namespace in WMI. The namespaces in WMI to which the extension writes are:

Kerberos

NTLM WMI

LDAP SMB

Root/RSoP/Computer. Root/RSoP/User/<user SID>.

The Lightweight Directory Access Protocol used to communicate with Active Directory. Server Message Block (SMB) protocol is the primary method of file and print sharing. Both the Administrative Templates client-side extension and the Administrative Templates snap-in use SMB to access the Sysvol as well as back up and retrieve files to a remote file system. The client computer also uses SMB to read the Sysvol on the domain controller. When you edit policy settings, the Administrative Templates snap-in writes changes to the Registry.pol file in the GPO located on the Sysvol. (Or the local GPO on the local computer). The ADM files in the ADM directory can also be updated at administration time. During processing the Administrative Templates CSE only reads the Registry.pol files from the GPO. No other files are read. No files are written to the Sysvol during processing. Communication to the Sysvol takes place through standard Win32 file system API calls. DCOM is used by the Administrative Templates CSE to communicate with the WMI database.

Distributed

Component Object Model (DCOM) dskquoui.dll dskquota.dll gptext.dll The dskquoui.dll file provides the Quota tab user interface on NTFS volumes. The dskquota.dll file provides the Disk Quotas client-side extension and server-side extension. The gptext.dll file provides the QoS Packet Scheduler client-side extension and server-side extension

Administrative Templates Extension Physical Structure

The following figure shows the files used by the Administrative Templates Extension.

Descriptions of these files are included in the following table. Physical Structure Components

Component Sysvol

Description The Sysvol is a set of folders containing important domain information that is stored in the file system rather than in Active Directory. The Sysvol folder is stored in a subfolder of systemroot folder (%\systemroot\sysvol\sysvol) and is automatically created when a server is promoted to a domain controller. .Adm files are Unicode text files that enable a user interface to allow you to modify Registry-based policy settings using Local Group Policy Editor or GPMC. .Adm files do not contain any policy setting information. Actual policy setting information is contained in Registry.pol files. .Adm files are stored in two places:

. adm files

Local .adm files stored on the computer where you run Local Group Policy Editor or GPMC.

Domain-based .adm files stored on the Sysvol. These files are copies of the local .adm files and are updated whenever you modify Administrative Templates policy settings. System.adm Inetres.adm Conf.adm Provides policy settings to configure the operating system. System.adm is loaded by default in Windows Server 2000, Windows XP, and Windows Server 2003. Provides policy settings to configure Internet Explorer. Ineteres.adm is loaded by default in Windows 2000 Server, Windows XP, and Windows Server 2003. Provides policy settings to configure NetMeeting. Conf.adm is loaded by default in Windows 2000 Server, Windows XP, and Windows Server 2003. Note: Conf.adm is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.

Wmplayer.adm Provides policy settings to configure Windows Media Player. Wmplayer.adm is loaded by default in Windows XP and Windows Server 2003. Wmplayer.adm is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family. Wuau.adm Registry.pol Provides policy settings to configure Windows Update. Wuau.adm is loaded by default in Windows 2000 Service Pack 3 (SP3), Windows XP Service Pack 1 (SP1), and Windows Server 2003. Unicode files that contain the Administrative Templates policy settings that are to be applied to the computer or user portion of the registry. In contrast to .adm files, the Registry.pol files contain the actual Group Policy settings used by the Group Policy engine during processing. Registry.pol files contain instructions to add or delete registry keys, corresponding to the policy settings you specify in Local Group Policy Editor or GPMC. An archive file on client computers that is updated each time the Administrative Templates CSE sets a policy setting. As processing completes, an Ntuser.pol containing the history of applied registry based policies in the Group Policy managed policies tree is written to the root of the users profile containing user policy settings and to the all users profile containing computer policy settings.(%Allusersprofile %\ntuser.pol for computer policy and %userprofile%\ntuser.pol for user policy.) The dynamic link library in which the Administrative Templates CSE runs. Userenv.dll is part of the code of the Group Policy engine and is always called whenever policy settings are processed. A log file that records warnings and events as a result of Administrative Templates processing. The Userenv.log contains more verbose logging than the event log and is not enabled by default. It is located on client target computers in Windows\debug\usermode. UserEnv.log also contains entries for profiles. A log file located on client computers in Windows\debug\usermode. You can use gptext.log to view errors in the processing of Administrative Templates policy settings.

Ntuser.pol

Userenv.dll Userenv.log

Gptext.log

Administrative Templates Extension Processes and Interactions

The Administrative Templates CSE is invoked by the Group Policy engine with a list of GPOs to be applied. Each GPO contains a Registry.pol file. In order to modify settings in the registry, the Administrative Templates CSE parses the ntuser.pol files to remove previously set registry settings, returning the registry settings to a default state. The Administrative Templates Extension then retrieves the Registry.pol files from each GPO in the list and applies the Registry.pol changes to the local registry in order of precedence for the GPOs. Data is also written to WMI by the Administrative Templates Extension for RSoP to retrieve later. As the Registry.pol files are processed, the ntuser.pol file is created to centrally manage the registry keys that have been set. Events are written to the event log during this process. If debugging is enabled, data is written to the userenv.log as well. Unlike other CSEs, the Administrative Templates CSE is coded within the Group Policy engine as a piece of userenv.dll. As a result, the extension is always called whenever Group Policy is processed. In addition, the Administrative Templates CSE is always called first by the Group Policy engine, in advance of any other CSEs that might be processed. Administrative Templates CSE will run only if there are any changes in any the GPOs that the Administrative Templates CSE has enabled. True Policies and Preferences The Administrative Templates CSE has control over a part of the registry for both user and computer registry hives and treats these specially. These parts are for the computer and user hives respectively:

HKEY_LOCAL_MACHINE\SOFTWARE\policies (preferred location) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

HKEY_CURRENT_USER\SOFTWARE\policies (preferred location) HKEY_ CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

These trees cannot be modified by a non-administrator. Because all keys and values beneath these paths are erased before applying the resultant registry policy settings, the registry policies applied in these subtrees will only persist as long as a valid Group Policy setting exists. Policy settings that are stored in these specific locations of the registry are known as true policies. All the policy settings in the standard Administrative Template files that shipped with Windows 2000 Server and Windows Server 2003 use true policies. This prevents the behavior that was often present in Windows NT 4.0, whereby System Policies resulted in persistent settings in the user and computer registry. The policy remained in effect until the value was reversed, either by a counteracting policy or by editing the registry. These settings are stored outside the approved registry locations listed and are known as preferences. Although Group Policy settings take priority over preferences, they do not overwrite or touch the registry key used by the preference. If both a policy and preference are present, the preference will be 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 configuration of the wallpaper on the Windows desktop illustrates an example of simultaneous policy and preference settings. In the Windows shell, it is possible for a user to configure their desktop wallpaper using the Display icon in Control Panel. An administrator can also configure desktop wallpaper using a default policy setting called Active Desktop Wallpaper, which can be found under User Configuration\Administrative Templates\Desktop\Active Desktop node in Local Group Policy Editor or GPMC. The following table lists the resultant behavior for Group Policy settings and preferences. Results of Group Policy Settings and Preferences

Scenario 1 2 3 4

Policy present No No Yes Yes

Preference present No Yes No Yes

Resultant behavior Default Preference configures behavior Policy configures behavior Policy configures behavior; preference ignored

It is common practice to offer both a preference and a policy setting for most applications. The application reads the registry keys and uses them accordingly. Registry-based data is appropriate for many types of policy settings and is also the least complex way to create custom policy settings. In addition, Registry-based policy managed through administrative template files automatically supports Resultant Set of Policy (RSoP) capabilities. Registry.pol Files Registry.pol files are formed by the following process:

When you start Local Group Policy Editor or GPMC, a temporary registry tree is created that consists of two nodes: USERand MACHINE. As you navigate the Administrative Templates node of the Local Group Policy Editor or GPMC, .adm file nodes are displayed. The .adm files within Local Group Policy Editor or GPMC nodes are loaded dynamically when a particular node is selected, and the .adm file is then cached. When a policy is selected in the details pane (the right side of the Local Group Policy Editor or GPMC), the temporary registry is queried to determine whether the selected policy already has registry values assigned to it; if it does, those values are displayed in the Policy dialog box. If the selected policy does not have a registry value assigned to it, the default value from the .adm file or from the associated MMC snap-in extension is used. After you modify a policy, the registry values that you specify are written to the appropriate portion of the temporary registry (either MACHINE or USER). When you close Local Group Policy Editor or GPMC, the temporary registry hives are exported to the Registry.pol files in the appropriate folders of the Group Policy template: GPT\Machine and GPT\User.

The next time you start Local Group Policy Editor or GPMC for the same Group Policy object for which you have previously set Group Policy settings, the registry information from the corresponding Registry.pol files is imported into the temporary registry tree. Therefore, when you view the policy settings, they reflect the current state.

Registry.pol in the Local GPO During processing, the local Registry.pol files in the Machine and User directories of the Local GPO are read. There is a Registry.pol file in both the Machine and User directories of the Local GPO directory structure for machine- and user-based policies respectively. The Local GPO is distinct from domain policy in that it updates the Registry.pol file as each policy setting is set and refreshes policy settings on the computer at the time each policy setting is configured. .Adm Files Administrative Template files describe where Registry-based policy settings are stored in the registry, by associating a description and explain text with a registry key and value. Local Group Policy Editor or GPMC displays only the descriptive text and provides various dialog boxes that you can use to modify the setting. A section of the users hive is mapped to the registry policy setting. .Adm files, unlike Registry.pol files, do not affect the actual policy processing by the Administrative Templates CSE. .Adm files only affect the display of the policy settings in the Local Group Policy Editor or GPMC snap-in. If an .adm file is removed, the settings corresponding to the .adm file will not appear in Local Group Policy Editor or GPMC. However, the policy settings that are configured from the .adm file will remain in the Registry.pol file and continue to apply to the appropriate target client or user. Each administrative workstation that is used to run Local Group Policy Editor or GPMC stores .adm files in the Windows\Inf folder. When GPOs are created and first edited, the .adm files from this folder are copied to the \adm subfolder in the Group Policy template (GPT). By default, when GPOs are edited, Local Group Policy Editor or GPMC compares the time stamps of the .adm files in the workstations Windows\Inf folder with those that are stored in the GPT \adm folder. If the workstations files are newer, Local Group Policy Editor or GPMC copies these files to the GPT \adm folder, overwriting any existing files of the same name. This comparison occurs when the Administrative Templates node (computer or user configuration) is selected in Local Group Policy Editor or GPMC, regardless of whether you actually edit the GPO. The .adm files stored in the Group Policy template can be updated by viewing a GPO in Local Group Policy Editor or GPMC. The process is simplified for local GPOs where all adm files are stored locally in a single adm folder. Because of the importance of time stamps on .adm file management, the editing of system-supplied .adm files is not recommended. If a new policy setting is required, Microsoft recommends that you create a custom .adm file. This prevents the replacement of system-supplied .adm files when service packs are released. Using the latest .adm files As a general rule, each operating system or service pack release includes a superset of the .adm files provided by earlier releases, including policy settings that are specific to operating systems that are different to those of the new release. For example, the .adm files that are provided with Windows Server 2003 include all policy settings for all operating systems, including those that are only relevant to Windows 2000 or Windows XP Professional. This means that only viewing a GPO from a computer with the new release of an operating system or service pack effectively upgrades the .adm files. How .adm files are handled by Local Group Policy Editor or GPMC By default Local Group Policy Editor or GPMC attempts to read .adm files from the GPO (from the Sysvol on the domain controller). Alternatively, the .adm file can be read from the local workstation computer. This behavior can be controlled by a policy setting. By default, if the version of the .adm file found on the local computer is newer (based on the time stamp of the file) than the version on the Sysvol, the local version is copied to the Sysvol and is then used to display the settings. This behavior can be controlled by a policy setting. If the GPO contains registry settings for which there is no corresponding .adm file, these settings cannot be seen in Local Group Policy Editor or GPMC. However, the policy settings are still active and will be applied to users or computers targeted by the GPO. How .adm files are handled by Group Policy Management Console GPMC uses .adm files to display the friendly names of policy settings when generating HTML reports for GPOs, Group Policy Modeling, and Group Policy Results. By default, GPMC uses the local .adm file, regardless of time stamp. If the file is not found, GPMC will look in the GPOs directory on Sysvol. You can specify an alternate path for where to find .adm files. If specified, this takes precedence over the previous locations. GPMC never copies the .adm file to the Sysvol.

Extensions that use Administrative Templates There are additional extensions that are located within the Administrative Templates for Computer Configuration in the Local Group Policy Editor or GPMC. These are:

Disk Quotas QoS Packet Scheduler.

Disk Quotas Disk Quotas are used to manage NTFS file system disk space. Administrators use the Disk Quotas Extension to configure Group Policy for Disk Quotas on target computers. The Disk Quotas Extension includes a server-side extension and a client-side extension. Administrators manage Disk Quotas policy settings under the following node in the Local Group Policy Editor or GPMC: Computer Configuration\Administrative Templates\System\Disk Quotas. The Disk Quotas node is the user interface for the server-side component of the Disk Quotas extension. There is no user interface for the client-side component, although you can view changes made by the CSE on the Quota Property tab for NTFS volumes. The Group Policy engine, using the Disk Quotas client-side extension component, applies settings to the target computer. The Disk Quotas CSE is registered with Winlogon in the registry at the following path: {HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\{3610eda577ef-11d2-8dc5-00c04fa31a66} QoS Packet Scheduler QoS Packet Scheduler Extension is an extension to Local Group Policy Editor or GPMC. Administrators use QoS Packet Scheduler Extension to set QoS Packet Scheduler Group Policy. QoS Packet Scheduler Extension is included in the same binary (gptext.dll) as the Scripts, IP Security, and Wireless Group Policy extensions. Administrators manage QoS Packet Scheduler policy settings under the following node in the Local Group Policy Editor or GPMC: Computer Configuration\Administrative Templates\Network\QoS Packet Scheduler. The QoS Packet Scheduler CSE is registered with Winlogon in the registry at the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ GPExtensions\{426031c00b47-4852-b0ca-ac3d37bfcb39}

Network Ports Used by Administrative Templates Extension

Administrative Templates CSE communicates with Active Directory using LDAP to complete the following tasks:

GPO list retrieval. Group Policy container retrieval.

It uses SMB to complete the following tasks:

Request DFS referral for \\domainname\sysvol. SysvolDFS replica location \\dcname.domainname\sysvol. Open and read GPT.INI. Return GPT.INI. Open and read GPT settings files. Return GPT file.

Port Assignments for Group Policy Administrative Templates

Service Name

UDP

TCP

Lightweight Directory Access Protocol SMB

n/a n/a

389 445

Related Information
The following contains additional information that is relevant to this section.

Group Policy Settings Reference in the Tools and Settings Collection

Administrative Templates Extension Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section

Administrative Templates Extension Tools Administrative Templates Extension Registry Locations Administrative Templates Extension Group Policy Settings Administrative Templates Extension WMI Classes Network Ports Used by Administrative Templates Extension Related Information

This section describes the tools and templates available for the Group Policy Administrative Templates extension.

Administrative Templates Extension Tools

The following tools are associated with the Group Policy Administrative Templates extension. For more information about Group Policy administrative tools, see the following topics in this collection:

Group Policy Administrative Tools Group Policy Object Editor Tools and Settings Group Policy Management Console Technical Reference What Is Resultant Set of Policy?

For information about tools specific to other Group Policy extensions, see the appropriate Group Policy Components Tools topics in this collection. For more information about other Resource Kit tools, see the Windows Server 2003 Resource Kit Tools page. AdmX.exe: ADM File Parser Category The ADM File Parser (AdmX) is a command-line tool that enables an administrator to export Group Policy settings to a tab-delimited text file. The administrator can then use the text produced by ADM File Parser (AdmX) to find changes for the policy settings between different versions of the operating systems. AdmX is for use only with policies based on administrative templates. Version compatibility The AdmX.exe tool runs on Windows 2000, Windows Server 2003, and Windows XP Professional. AdmX.exe also requires the Microsoft .NET Framework 1.0. Administrators use AdmX.exe to perform the following two tasks:

Extract policy setting information from .adm files.

Compare two .adm files. This can be used to determine what has changed between two like files, such as the system.adm file from two different operating systems.

For more information about the ADM File Parser, type AdmX.exe /? at the command line. GPUpdate.exe This tool is used for refreshing local and Active Directory policy settings on the computer from which you run the GPUpdatecommand. Category This command-line tool is included in Windows XP and Windows Server 2003. Version compatibility You can use GPUpdate locally on computers running Windows XP and higher to refresh policy immediately. On computers running Windows 2000, this behavior is provided by the using the secedit.exe command line tool, with a specific parameter. GPUpdate refreshes changed local Group Policy settings and Group Policy settings that are stored in Active Directory, including security settings, on the computer from which it is run. This command supersedes the now obsolete /refreshpolicy option for the secedit command line tool. Group Policy can be forced to reprocess all policy settings whether there has been a change or not by using the /force switch. For more information about GPUpdate, see Core Group Policy Tools and Settings in this collection. GPResult.exe: Group Policy Results This command line tool displays Resultant Set of Policy (RSoP) for a user or computer. You can use GPResult.exe to see what policy is in effect and to troubleshoot problems on computers running Windows XP or later. Category There are two versions of GPResult: One shipped with the Windows 2000 Resource Kit; the other is included with Windows XP and Windows Server 2003. The Windows 2000 version of GPResult runs only locally on Windows 2000. The Windows Server 2003 version runs locally or remotely on Windows XP or Windows Server 2003. The different versions are not compatible. Version compatibility The GPResult.exe that ships with Windows XP and Windows Server 2003 family is completely different than the original version of GPResult.exe that shipped in the Windows 2000 Resource Kit. The newer version cannot be used to view policy information for computers running Windows 2000. For more information about GPResult, see Core Group Policy Tools and Settings in this collection. Dcgpofix.exe: Dcgpofix Category Dcgpofix ships with Windows Server 2003. Version compatibility You can run Dcgpofix only on servers in a Windows Server 2003 domain. This tool can restore default domain policy and default domain controllers policy to their original state after installation. When you run Dcgpofix, you will lose any changes made to these Group Policy objects. This tool should be used as a last-resort disasterrecovery tool. A better solution is to use Group Policy Management Console (GPMC) to back up and restore these GPOs. For more information about Dcgpofix, type Dcgpofix /? at the command line. GPMonitor.exe: Group Policy Monitor Tool Category Group Policy Monitor tool is included in the Windows Server 2003 Deployment Kit. Version compatibility The Group Policy Monitor tool works on Windows XP and higher computers. Group Policy Monitor tool collects Group Policy information at every Group Policy refresh and sends the information to a centralized location that you specify. You can then use the Group Policy Monitor user interface (UI) to view the data. The Group Policy Monitor UI can provide a historical view of policy changes. The UI is also designed to make it easy to navigate through historical snapshots of data and trace changes. For more information about the Group Policy Monitor tool, type GPMonitor /? at the command line. You can find full documentation for the Group Policy Monitor tool in the Windows Server 2003 Resource Kit Tools.

GPOTool.exe: Group Policy Verification Tool Category Group Policy Verification Tool is included in the Windows Server 2003 Deployment Kit. Version compatibility The Group Policy Verification tool works on Windows 2000 and higher computers. You can use Group Policy Verification Tool to check the health of the Group Policy objects on domain controllers. The tool checks GPOs for consistency on each domain controller in your environment. The tool also determines whether the policies are valid and displays detailed information about replicated Group Policy objects (GPOs). GPOTool.exe ships with the Microsoft Windows 2003 Server Resource Kit and is also available as a free download at the Gpotool.exe: Group Policy Verification Tool page. For more information about the Group Policy Verification tool, type GPOTool /? at the command line. You can find full documentation for Group Policy Verification Tool in the Windows Server 2003 Resource Kit Tools. Regview.exe: Registry.pol Viewer Tool Category Regview.exe is a Group Policy tool for viewing the contents of any registry.pol file, which is created by the Group Policy Object Editor for containing the administrative settings. It is included in the Windows Server 2003 Deployment Kit. Version compatibility The Group Policy Viewer tool works on Windows 2000 and higher computers. Because the registry.pol file is not an ASCII file, you cannot easily view the contents. If an administrator needs to troubleshoot or just wants to document the contents of the file, this tool supplies the contents in a delimited format. Other Tools For information about tools specific to Group Policy extensions, see the appropriate Group Policy Components Tools topics in this collection.

Administrative Templates Extension Registry Locations

The following registry locations are associated with the Administrative Templates extension. All default registrybased policy settings from Windows 2000 or later are stored in one of four specific registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies (preferred location) HKEY_CURRENT_USER\SOFTWARE\Policies (preferred location) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies HKEY_ CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

Policy settings that are stored in these locations are known as true policies. The information here is provided as a reference for use in troubleshooting or verifying that the required settings are applied. You should not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

Administrative Templates Extension Group Policy Settings

Administrative templates (.adm files) enable administrators to configure registry settings by using Group Policy. These settings appear under the Administrative Templates item for both User Configuration and Computer Configuration in the console tree of the Group Policy Object Editor (GPEdit.dll), and in HTML reports produced by the Group Policy Management Console (GPMC). For a full list of Administrative Templates policy settings, see Group Policy Settings Reference for Windows Server 2003. Group Policy Settings For more information about Group Policy settings, see the Group Policy Settings Reference for Windows Server 2003.

Administrative Templates Extension WMI Classes

Like other Administrative Templates policy settings, RSoP data is updated whenever policies applied to a computer changes. The extension writes this data into WMI during processing so that the data maintained in WMI is consistent with what is applied to the computer. The administrative template files themselves used in editing the GPO are stored in the Windows/inf folder of the administrative computer. The extension writes to the following WMI namespaces:

Root/RSoP/Computer Root/RSoP/User/<user SID>

For more information about these WMI classes, see the WMI SDK documentation on MSDN.

Network Ports Used by Administrative Templates Extension

The Group Policy Administrative Templates extension communicates with Active Directory using Lightweight Directory Access Protocol (LDAP) to complete the following tasks:

GPO list retrieval Group Policy container retrieval

The Administrative Templates extension uses Server Message Block (SMB) to complete the following tasks:

Request Distributed File System (DFS) referral for \\domainname\sysvol SysvolDFS replica location \\dcname.domainname\sysvol Open and read GPT.INI Return GPT.INI Open and read Group Policy template (GPT) settings files Return GPT file

The following table lists the network ports used by the Administrative Templates extension. Port Assignments for Group Policy Administrative Templates

Service Name Lightweight Directory Access Protocol SMB

UDP n/a n/a

TCP 389 445

Related Information
The following resources contain additional information that is relevant to this section.

The Group Policy Administrative Tools topic in this collection. The Group Policy Object Editor Tools and Settings topic in this collection. The What Is Group Policy Management Console? topic in this collection. The appropriate Group Policy Components Tools topics in this collection. The Implementing Registry-Based Group Policy page. The Group Policy Management Console page.

The Group Policy Settings Reference for Windows Server 2003. The Microsoft Platform SDK page. The Windows Server 2003 Resource Kit Tools page. The Tools and Settings Collection

Group Policy Software Installation Extension Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 By using the Group Policy Software installation extension of Microsoft Windows Server 2003, an administrator can centrally deploy, install, and manage applications throughout an organization. From a central location, the administrator can also perform routine maintenance tasks such as upgrading, patching, and removing applications without going to individual workstations, which gives users reliable access to the applications that they need to perform their jobs, no matter which computer they are using. The Group Policy Software installation extension relies on both the Active Directory directory service included with Windows Server 2003 and Group Policy. In this subject

What Is Group Policy Software Installation Extension? How Group Policy Software Installation Extension Works Group Policy Software Installation Extension Tools and Settings

What Is Group Policy Software Installation Extension?

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What Is Group Policy Software Installation Extension?

In this section

Group Policy Software Installation Extension Scenarios Group Policy Software Installation Extension Dependencies Comparing Microsoft Software Management Solutions

This section provides a high-level overview of the Group Policy Software installation extension and compares it with other Microsoft software-management technologies. Microsoft offers several key technologies to aid organizations with deploying new software and software upgrades or updates. One of the key reasons for implementing the Group Policy Software installation extension, a Group Policy-based technology, is to lower the companys total cost of ownership of its computers. Because installing, upgrading, and updating applications are critical business processes, companies can leverage the built-in Group Policy software distribution technology to increase users' productivity as changes occur. The following table describes the capabilities of the Group Policy Software installation extension. Group Policy-Based Software Installation Capabilities

Capability

Description

Central location to create distribution instructions Central location to initiate delivery of software Scheduling Distribution targeting Installation and configuration status Distribution reporting Disaster recovery for applications

Windows Server 2003 administrators create the packages and configure the details of the packages that are published to Active Directory. By using Group Policy configurations, software is made available to computers and users that are part of the Active Directory hierarchy. Software is made available to users immediately in Add or Remove Programs in Control Panel, or is automatically installed at computer startup or user logon. Software deployment uses the Active Directory and Group Policy infrastructure services that are built into Windows Server 2003 to perform its targeting. Group Policy Results (formerly known as RSoP) provides detailed information on the client about what has been installed and why. Group Policy provides interfaces for collecting data on individual software installations, but provides no such network-wide data collection mechanisms. With Group Policy, assigned applications automatically reinstall after system loss, and published applications are available for users to reinstall on-demand or by choosing the software in Add or Remove Programs.

Group Policy Software Installation Extension Scenarios

The Group Policy Software installation extension enables the administrator to create a controlled environment, providing on-demand software installation and automatic repair of applications. Users benefit from reliable access to the applications that they need to perform their jobs on any computer they use on their network. Scenarios where organizations might use Group Policy-based software distribution include the following:

Publish applications that are nonessential for the users. When software is published for a user, it does not initially appear to be installed on the computer. There is no Windows Installer advertisement information about the software on the computer in the registry, on the desktop, or on Start menu as a shortcut. On an as-needed basis, the user installs the published software by using Add or Remove Programs in Control Panel. Users can also install the published application by selecting a file that has a file name extension for an application. Assign software to users or computers for either of the following reasons:

To make a particular application available to all users of a computer, assign the application to the computer. To make mission-critical software available to users or computers at all times, assign the application to the users.

Group Policy Software Installation Extension Dependencies

The Microsoft Windows 2000, Windows XP Professional, and Windows Server 2003 operating systems provide software distribution by using Group Policy, which is built on the management infrastructure services in the operating system. Group Policy requires Active Directory directory service. Windows Server 2003 provides a robust and feature-laden software distribution mechanism for organizations by using Active Directory. The Group Policy Software installation extension also depends on Windows Installer. For detailed information about Group Policy dependencies, see Core Group Policy Technical Reference."

Comparing Microsoft Software Management Solutions

Microsoft offers several software solutions for networked users. An organization might already have objectives and requirements for a software installation and management product. This section compares Microsoft technologies for software deployment. Group Policy, which is built-in to the Windows 2000, Windows XP Professional, and Windows Server 2003 operating systems, offers a convenient method for distributing software in an Active Directory environment, especially if it already uses Group Policy for other purposes, such as securing client and server computers. However, a Group Policy-based software installation has some basic limitations, including difficulties with scheduling installation, consistently managing network bandwidth, and providing feedback on the status of the installation.

To carefully schedule installations, manage network use, perform hardware and software inventory, or monitor installation status, consider using Microsoft Systems Management Server (SMS). For more information about SMS, see the Microsoft Systems Management Server Product Information page. Using the right solutions can benefit an organization by providing a centralized, efficient means to perform routine tasks such as updating software. The following table compares the various software management technologies. Comparing Software Management Technologies

Management Function Patch and upgrade Windows XP, Windows Server 2003, and Windows 2000 Create consistent user environment (persistence of data, software, and settings) Perform disaster recovery for applications in Windows 2000, Windows XP, and Windows Server 2003 Perform inventory, advanced deployment, troubleshooting, and diagnostic tools Manage environments that are not Active Directory-based

Group Policy N/A

Microsoft Systems Management Server (SMS) Yes When using SMS for software management, also use it to patch Windows-based computers instead of SUS. Software only

Terminal Services

Microsoft Software Update Services (SUS)

Although Terminal Services Windows patches does not automate patching, only (no upgrade) it can be used it to remotely log on and apply patches. Yes N/A

Yes

Yes

Yes

N/A

N/A

Limited

Yes

Limited

None

No

Yes

Yes

Yes (Windows patches only)

Although all these Microsoft management technologies provide important software distribution capabilities, SMS is the preferred Microsoft software distribution solution for medium-sized, and especially for enterprise-sized, organizations. SMS provides advanced features for deploying and managing software, Windows patches, and critical updates. For organizations that use SMS as a software management solution, the Microsoft Software Update Services (SUS) SMS Feature Pack for SMS 2.0 provides the features of SUS for users of SMS 2.0 for distributing patches and critical updates to clients. However, SUS used with the Automatic Updates client is the recommended solution for distributing Windows patches in conjunction with Group Policybased software distribution. Although there are specific instances where an administrator might choose one software deployment method over another, many of these Microsoft technologies can be used together, depending on an organizations needs. The following sections describe each of these solutions. Group Policy Software Installation Extension The Group Policy Software installation extension is well-suited to deploy and manage software if the organization is small or medium in size, and the following conditions exist:

The administrator has deployed Active Directory. The administrator has determined that Group Policy provides the management features the organization requires. The administrator has a base of client computers running Windows 2000 Professional or Windows XP Professional and member servers running Windows 2000 Server and Windows Server 2003. Note that the servers do not have to run Windows Server 2003 to use Group Policybased software deployment.

Group Policy can also serve the needs of large enterprises that use other software installation solutions, such as SMS, across the organization. In conjunction with SMS or other solutions, Group Policy can be useful for distributing software within various groups, such as individual divisions, where the advanced capabilities of SMS might not be needed.

The following figure shows the Group Policy Object Editor interface after a new package has been added to a GPO by using the Group Policy Software installation extension. Group Policy Software Installation Extension

This topic details the Group Policy Software installation extension for providing application management. Systems Management Server SMS is appropriate for organizations if any of the following conditions exist:

The organization is medium or large in size. Its users are running operating systems earlier than Windows 2000 Professional. The organization requires more advanced capabilities for planning, scheduling, distributing, and tracking software.

The advanced capabilities of SMS include such features as inventory-based targeting, status reporting, server-side and client-side scheduling, support for multisite facilities, centralized hardware and software inventorying, remote diagnostic tools, software metering, software distribution-point population and maintenance, and other enhanced software deployment features. SMS also provides support for Microsoft Windows 95, Windows 98, Windows NT 4.0, Windows 2000, and Windows XP clients. Additionally, SMS does not require Active Directory. For more information about SMS, see the Microsoft Systems Management Server Product Information page. Terminal Services Terminal Services can be very useful if an organization has Windows-based desktop applications that require frequent updates, and the users who require those applications are in remote locations and have low bandwidth. When used as a terminal server, a server becomes a Windows application server. This allows the user to run Windows-based applications remotely on the server while only the mouse, keyboard, and display data are transmitted to the local computer. Terminal Services allows an administrator to offer users software as a remote service instead of as a local installation package, as with Group Policy-based software distribution. For more information about Microsoft Terminal Services, see the Terminal Services topic. Microsoft Software Update Services Microsoft Software Update Services (SUS) can be used to quickly acquire and distribute critical Windows patches to computers in an organization. By using SUS, an administrator can choose which of the latest critical or security patches to download, test them in a company-standard operating environment, and then efficiently deploy the patches to the appropriate computers running the Automatic Updates client.

How Group Policy Software Installation Extension Works

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Group Policy Software Installation Extension Works

In this section

Terms and Definitions Group Policy Software Installation Extension Architecture Group Policy Software Installation Extension Components Group Policy Software Installation Extension Processes and Interactions

The Group Policy Software installation extension allows administrators to use the Group Policy Object Editor to centrally manage the installation of software on all client computers in an organization. This is accomplished either by assigning applications to users or computers, or by publishing applications for users. Software can be assigned on a per-user or per-computer basis when an organization does not want to give users the choice to install or remove the software. For example, if a user removes a user-assigned application by using Add or Remove Programs in Control Panel, the Group Policy Software installation extension automatically reapplies the advertisement information after the user logs on or the computer restarts, and the software is reinstalled the next time a user selects it or tries to open a file with an associated file name extension. It is not possible for a user to delete a computer-assigned application. In most cases, packages that are assigned to users or computers include applications that are essential but do not create congestion between the clients and the software distribution points. Group Policy-based software deployment allows administrators to publish software for users only; in other words, published software is not available for computers. Publishing software for users allows them to decide if and when they want to install it. They can install the software from a list of published applications in Add or Remove Programs. For example, not everyone in the organization requires software for project management. Therefore, a software administrator is likely to publish a project management package for only those users who require it. Managers who require the software can then choose to install it. Users can always see both assigned and published applications in Add or Remove Programs. Add or Remove Programs includes an active Web link for each application, which provides users with the support information they need to install certain applications. However, administrators can overwrite the default link by using the Group Policy Software installation extension. The support link then corresponds to the internal product support resources. This Web link can also point to a support page that includes information such as an FAQ about a specified application, a help desk article about using the application, or instructions for requesting support. Group Policybased Software Installation in the Ideal Environment The following components are necessary to deploy software using the Group Policy Software installation extension:

Group Policy. Windows 2000 Server or Windows Server 2003 domain controllers. A network that uses Active Directory directory servicebased domains. Target computers that run Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or Windows Server 2003.

The Group Policy Management Console (GPMC) is not required but necessary for simple, powerful, and efficient administration. See the Group Policy topic for more information about GPMC.

Terms and Definitions

The following are terms used in this document to describe aspects of Group Policybased software deployment. Advertisement The process of making an application that supports Windows Installer appear installed on the desktop, by installing the shortcuts for the application on the Start menu or desktop, and by populating the registry with the application information. Advertisement script

The output of the Group Policy Software installation extension Microsoft Management Console (MMC) snap-in, which advertises an application that supports Windows Installer. The advertisement script is stored in Active Directory. Assigned One of the modes of targeting supported by Group Policy-based software deployment. Administrators can assign the software that users require to perform their jobs. Administrators can assign software to users and to computers. User-assigned applications are advertised on the desktop; they appear to be installed on the users desktop, but they get installed the first time that the user starts the application, typically from the Start menu. If a user deletes an assigned application, it will be re-advertised. Computer-assigned applications are installed the next time that the computer restarts. Package A Windows Installer .msi file. At its core is a database that contains the instructions to manage the software on a computer. Published One of the modes of targeting supported by Group Policy-based software deployment. Administrators can publish software to users. Published applications are not advertised on the desktop; there is no physical appearance of published applications on the users desktop. Users install published applications from the Add or Remove Programs in Control Panel or by opening a file type associated with an application. Repackaging The process of preparing software for distribution by making an image of a correctly configured computer, then installing the software and making a post-installation image of the computer. The repackaging software takes the difference of the two images and creates the necessary installation instructions to reproduce the installation. Group Policy Software installation extension snap-in The MMC component of Group Policy Object Editor that an administrator uses to manage software. Transform (Verb) The process of modifying or customizing a Windows Installer-based .msi package. Transform (Noun) A Windows Installer customized package that, if associated with another Windows Installer-based .msi package at deployment time, results in a customized installation. Windows Installer Windows Installer is a Windows operating systembased service that can install, modify, repair, and remove software. Windows Installer includes the operating systembased service, a package format, and an applicationprogramming interface (API) that allows both the operating system and applications to interact with the service to install, modify, or repair the software.

Group Policy Software Installation Extension Architecture

This section details the architecture behind Group Policybased software distribution. The Group Policy Software installation extension performs two processes: application publishing and application assignment. The following figure shows the server-side perspective of Group Policybased software deployment. Server Architecture and Components of the Group Policy Software Installation Extension

Application Publishing Publishing is simply advertising that a package is available to be installed it does not mandate that an application be installed. A published package is created by using the Group Policy Software installation extension. The Group Policy Software installation extension extracts advertising information about the package and stores this, in modified form, in both the directory and the Sysvol folder. Advertising information includes the name and installation path of the application; it also includes information about the file associations, Program IDs (ProgID), and Component Object Model (COM) Class IDs (CLSID) that the application supports or implements. Published applications can be either Windows Installer .msi files or text-based .zap files. Each is treated differently: The Group Policy Software installation extension uses the Windows Installer subsystem to extract advertising information from the .msi package. This information is programmed into the .msi package by the author of the package, normally the application vendor. A .zap package is a simple text wrapper around a setup command. The author of the .zap file can include information such as file name extension and COM support in the .zap file. This information is extracted directly by the Group Policy Software installation extension. A subset of the advertising information file name extensions, CLSIDs, and ProgIDs is used to create an Active Directory package publication object (PackageRegistration) in the ClassStore container. This is located in the GPO GUID\User\Class Store\Packages subcontainer of the Group Policy object (GPO) in which the package is published and given a newly generated globally unique identifier (GUID) for a common name (CN). This published package then becomes available to all recipients of the advertised application. The Group Policy Software installation client-side extension (CSE) also creates an Application Advertising script in the Sysvol folder that is derived from the same advertising information. This has the same name as the related PackageRegistration object with a file name extension of .aas. In this case, more of the advertising information such as Start menu shortcuts created by the application, which are omitted from the PackageRegistration object is used in the creation of the .aas file. This file is stored in GPO GUID\User\Applications. Published applications do not cause any change on the client computer during normal GPO processing, so no information is downloaded from Active Directory or Sysvol. However, the applications published to the user can be viewed in Add or Remove Programs. The user must perform some action to cause the published application to be installed. The simplest case is that the user chooses to install the application from Add or Remove Programs. The Group Policy Software installation extension also supports a more sophisticated method for installing applications. If a user attempts to open a document with a file name extension for which there is no application currently installed, or tries to call a COM object for which there is no local definition in the registry, the Group Policy Software installation extension service searches Active Directory for PackageRegistration objects that support the file name extension or COM CLSID and that have been published to the user by using a GPO. If one is found, the .aas script is downloaded to the client computer and runs to create advertisements on the computer. When the user again attempts to open a document or a COM operation is retried, the advertisement triggers the installation of the application (or at least that part of it required to support the document or COM operation

attempted). If more than one suitable PackageRegistration object is found, the one in the highest-priority GPO is selected. Where there is more than one in the same GPO, the one with the latest creation date is selected. The following figure shows the Group Policybased software publishing architecture. Group Policybased Software Deployment Processing Architecture and Components (Published Software)

Application Assignment Assigning is a superset of publishing. The same description for published-application processing applies to assignment except that the application is either fully or partly installed on the client computer during GPO processing. Assignment differs from publishing in that the Group Policy Software installation extension either advertises the application on the client computer (in the case of a user assignment) or fully installs the application (in the case of a computer assignment). Assigning to a user creates an advertisement of the application on the client computer this can include application shortcuts on the Start menu and registry entries defining COM and program registrations supported by the application. Unlike publishing, applications can also be assigned to computers. The Group Policy Software installation CSE only processes during startup and logon, never during periodic refresh. By default, it also does not process over a slow link (this behavior can be changed). The creation of an assigned package is similar to that of a published package. This produces an almost identical PackageRegistration object and .aas file. The only difference is that the PackageFlags property of the PackageRegistration object identifies this as an Assigned rather than a Published application. Advertising is a function of Windows Installer and works by placing entry points to the application on the client system. Examples of these entry points are Start menu shortcuts, COM Class IDs, Program IDs, and Multipurpose Internet Mail Extensions (MIME) types. These entry points are configured so that, if any of them are called, Windows Installer installs the application. Windows Installer checks to see whether the application or application component that implements the call has been installed. If not, it installs the application. To the user, the advertisements appear to be already installed. During GPO processing, the Group Policy Software installation CSE queries the directory for available assigned PackageRegistration objects for applied GPOs that have changed or are new. Any packages found are compared to those already downloaded onto the client computer the client computer records received packages in the registry and caches .aas files. Any new or changed packages are processed. The corresponding .aas file is read from the Sysvol folder and then cached in %systemroot%\appmgmt. This folder also contains AppMgmt.ini, which stores configuration settings. The following figure shows Group Policybased software assignment architecture. Group Policybased Software Deployment Processing Architecture and Components (Assigned Software)

Software Distribution Point Servers Deploying applications is the process of setting up and managing distribution points or server shares where users have access to the packaged software and can install it on their computers. These servers act as file shares for the .msi packages identified in software installation GPOs. Two methods can be used for deploying and managing software distribution point servers:

Universal naming convention (UNC) path to a server share. Distributed File System (DFS).

UNC Paths to Server Shares By using UNC paths, a user or application can specify the physical server and share names to gain access to file information. For example: \\Server\Share\Path\File_name. A UNC path can be used to allow direct access to a shared file by mapping to a network drive, where the drive letter denotes \\Server\Share. Administrators can also perform a net use command to navigate beyond the redirected drive. However, as networks grow and as organizations begin using existing storage for new purposes, mapping a single drive letter to individual shares becomes inefficient. Also, despite the fact that users and applications can refer to UNC names directly, the increasing number of places users must go to retrieve data can be overwhelming. DFS and Software Distribution Point Servers DFS provides fault tolerance for software distribution points by mapping a specific logical name to shared folders on multiple file servers. This way, software remains available for installation, regardless of whether one of the physical servers where the software deployment files reside becomes unavailable. DFS also improves storage scalability because administrators can deploy additional or higher-performance file servers and present the storage on the new computers as new directories in an existing namespace. When using DFS in combination with Group Policybased software deployment, organizations benefit from its loadsharing abilities and location-independence. These features simplify management and optimize the installation for users. Instead of allowing all users to install software from a single server, and taxing the server, a DFS namespace can distribute network traffic across multiple servers.

Group Policy Software Installation Extension Components

Group Policybased software deployment uses the Windows Server 2003 features and technologies described in the following table. Essential Tools and Components for Group Policybased Software Deployment

Component or Tool

General Description

Combined with Group Policy Software Installation Extension

Active Directory

A hierarchical collection of objects including domains, sites, organization units (OUs), users, computers, and printers that allow an organization to manage these resources. An administrative tool for defining and controlling the way programs, network resources, and the operating system work for users and computers in an organization. In an Active Directory environment, Group Policy is applied to users or computers on the basis of their membership within sites, domains, or OUs. A service based on an operating system, which provides software installation services using a standard package format. Administrators can use Windows Installer to manage the installation, modification, upgrade, and removal of software applications. An extension of the Group Policy Object Editor snap-in that includes a user interface that allows administrators to deploy and manage software.

Provides the scope of management mechanism to locate users and computers. Stores software deployment information through Group Policy. Enables administrators to deploy applications in a GPO associated with one or more Active Directory containers, such as sites, domains, or OUs. Use the Group Policy Software Installation extension snap-in to deploy applications.

Group Policy

Windows Installer

Installs, modifies, upgrades, and removes software applications.

Group Policy Software installation extension

Communicates with Active Directory, GPOs, and Windows Installer to assign or publish applications as follows:

Assigns software to users. Installs userassigned applications entirely the first time the user logs on after deployment, or allows users to install certain components or features of an application as needed.

Assigns software to computers. Installs an application the next time the computer starts. The application is available for all the users on that computer.

Publishes applications for users only: Users can choose to install the software from a list of published applications located in Add or Remove Programs in Control Panel. Appmgmts.dll Group Policy Management Console (GPMC) The client-side extension for the software installation component of Group Policy. A new tool that consists of an MMC snap-in and command-line tools. This tool unifies management of all aspects of Group Policy across an enterprise. GPMC allows administrators to manage all GPOs, Windows Management Instrumentation (WMI) filters, and permissions on a network. This is the extension file on the client that configures software installation settings. Group Policy Modeling (formerly known as RSoP planning) allows administrators to run hypothetical scenarios to verify software configurations under various sites, domains, and OUs. Provides printable HTML-based reports. Group Policy Results(formerly known as RSoP logging)verifies which software applications are properly installed for a specific group of users or computers. It also pinpoints the causes of unintended removal or damage to software. Provides printable HTML-based reports.

Add or Remove Programs

A user interface in Control Panel of Windows XP Lists both published and assigned applications so Professional and Windows 2000 Professional. Add or that users can install, modify, and remove Remove Programs lets users manage software on software from their desktop computers. their own computers. These include GPResult.exe, GPOTool.exe, GPUpdate.exe, ReplMon.exe, NetDiag.exe, InstallShield, and the new Group Policy Management Console (GPMC) MMC snap-in. Some are installed by default; others must be installed manually. Helps manage, optimize, or troubleshoot Group Policybased software deployment.

Command-line and Graphical User Interface (GUI) tools or scripts

How Windows Installer Works

Many software authors develop applications to include native Windows Installer packages. A native Windows Installer package contains a single product, such as Microsoft Office 2000, which can be made up of several features, such as Microsoft Word, Microsoft Excel, and Microsoft PowerPoint. However, software can be configured to install features individually. When the user selects an uninstalled feature, the feature is installed. Each feature (Word, Excel, PowerPoint, and so on) contains components, such as a thesaurus, spelling checker, or an additional user-interface language. When the user selects a feature or component that is not installed, the feature or component is automatically installed. Automatic (or on-demand) installation of selected features saves network bandwidth during the initial installation. It also gives users only the features and components that they need to do their jobs. Automatic installation can also save space on users local disk drives. However, this type of installation delays the availability of a feature when the user first selects it. Windows Installer packages ensure that an accidentally deleted file, such as Winword.exe, is reinstalled the next time the user tries to start Word because Windows Installer detects and reinstalls missing files. Windows Installer technology uses the following two components to help an organization install and manage software:

A Windows Installer package (an .msi file), which is a database containing information that describes the installed state of an application. The Windows Installer package performs the installation, modification, and removal of the software. An application programming interface (API) that allows applications and management tools to interact with Windows Installer to install or remove additional features of the application after the initial installation is completed.

The managed state of an application includes installation, modification, upgrade, or removal. Windows Installer provides administrators with consistent and reliable methods to customize installations, update and upgrade applications, and resolve configuration problems. The following are some of its advantages:

Note

Helps manage the state of software during and after installation. Defines a standard format for application setup and tracks components such as groups of files, registry entries, shortcuts, and other aspects of the application that must be managed together. Detects whether software is installed correctly or whether a program file is missing. It can immediately reinstall the damaged or missing files. Repairs applications and ensures that they are installed or removed without overwriting or deleting files that are required by another application. Enables administrators to modify an installation by adding or removing features after the installation. Enables deployment of 32-bit and 64-bit Windows applications using Windows Installer version 2.0.

Versions of Windows Installer earlier than version 2.0 can install and manage 32-bit Windows Installer packages only on 32-bit operating systems. Windows Installer version 2.0 supports all of the setup functionality that is available in earlier Windows Installer versions.

Software installed by using the Windows Installer uses the following parameters:

\>msiexec /I \\servername\share\<software.msi> TRANSFORMS = \\servername\share\<software.mst> /qb

In this example, Software.msi is the Windows Installer package, and Software.mst is the transform applied at deployment time. Transforms for Customizing Windows Installer Packages A transform (.mst file) is a collection of specified changes that are applied to a base Windows Installer package file at the time of deployment. Windows Installer packages are modular to simplify deployment. When transforms are applied to an .msi file, Windows Installer can dynamically add or modify data in the installation database to customize the installation of the application.

For example, Office 2000 provides the Office 2000 Custom Installation wizard, which can be used to build transforms. Administrators can create a transform for managing the configuration of Office 2000 that is deployed to users in an organization. Other tools in the Windows Installer software development kit (SDK), or other nonMicrosoft tools, can also help to create transforms for Windows Installer packages that do not include their own custom installation tools. Transforms tailor the installation of an application. Although they are optional, transforms can be used for a variety of purposes including customizing and encapsulating. Customizing Customizing can involve configuring installations so that a particular set of features from a specified software application, or suite of software applications, is installed locally on the computer. Transforms can also add new features to an existing applications package. For example, they can add custom Excel templates for an organizations Finance group. Encapsulating Administrators can encapsulate numerous customizations of a base package that are required by different groups. For example, in organizations where the Finance and Marketing departments require different installations of an application, the base package of the application can be made available to everyone at one software distribution point. Then the appropriate customizations can be distributed separately as transforms to each group of users. Reauthoring Applications for Windows Installer When administrators reauthor an application, they create applications that adhere to the Windows Installer format. Reauthoring is essentially redeveloping the setup portion of the application to take full advantage of the advanced capabilities of Windows Installer. There are some authoring tools available to help developers create new Windows Installer packages, but the procedures can be resource-intensive and costly. If an organization determines that the application will play a key role in its future, it is important to weigh the benefits of reauthoring with the costs. .Zap Files Applications that do not use the .msi file format for the Windows Installer Service can be set up for distribution by creating a text file that has a .zap file name extension. When organizations have many applications that do not contain native Windows Installer packages and plan to discontinue these applications, they often create software installation settings (.zap) files for the installation executable files, such as Setup.exe or Install.exe. Additionally, if an organization uses custom applications that do not have Windows Installer support, but plan to use them in the long term, .zap files might be the only choice. Users of .zap files do not benefit from the capabilities of Windows Installer. The Group Policy Software installation extension recognizes .zap files that wrap 32-bit or 64-bit Setup.exe files into a .zap file format. Applications published in this format are available for users to install by using Add or Remove Programs. Because these applications do not use Windows Installer setup programs, they do not do the following:

Use elevated permissions for installation. While applications that are installed by using .zap files run their original setup programs, they do not run with the elevated permissions that Windows Installer packages have. If installing the application requires administrative permissions, only users who have those permissions can install it. Install a feature on the first use of the feature. Roll back an unsuccessful operation, such as install, modify, repair, or removal. Detect a broken state and automatically repair it. Implement customized installations (also known as transforms).

64-Bit Application Packaging In Windows Server 2003, the Group Policy Software installation extension and Windows Installer version 2.0 continue to support and protect the investment that organizations have made in 32-bit applications. Additionally, Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, introduce support for 64bit application installation. Windows Installer version 2.0 can install three types of Windows Installer packages on a computer running a 64bit operating system:

32-bit packages that contain only 32-bit components


Note

64-bit packages containing some 64-bit components and some 32-bit components 64-bit packages containing only 64-bit components

64-bit applications cannot be published or installed on 32-bit operating systems. Group Policy will attempt to install an incorrectly configured 64-bit package for 32-bit clients, but then removes the package during logon. It then installs the package again the next time a user logs on, and so on.

The Group Policy Software installation extension can be configured to allow or disallow installation of 32-bit applications to 64-bit clients. More .zap applications fail on 64-bit clients than on 32-bit clients. Unless the default behavior is changed, 32-bit .zap applications are deployed so that they are not listed in Add or Remove Programs on 64-bit clients. Repackaging Applications for Windows Installer Administrators repackage an .msi package for Windows Installer when they cannot reauthor it. Repackaging an application for Windows Installer involves making an image of a fresh computer (including the registry settings, files, and system settings), installing the software, and then taking a post-installation image of the computer. The repackaging software detects the difference between the two images, and then creates the necessary instructions to reproduce the installation. If any registry changes, files changes, or system setting changes occur during the capture process, they are included in the installation. Repackaging is useful when administrators do not have control over dynamic-link library (DLL) files, source code, and registry entries, or for applications about which they do not have in-depth knowledge. Repackaging requires a thorough knowledge of the applications installation program and of the Windows Installer configuration on the Windows platform. Success with repackaging is affected by the state of the computer on which an administrator performs the repackaging. The computer should have only the operating system and operating system service packs installed before running the repackaging software. Because of this limitation, and other issues, repackaging is not recommended. Repackaging is not a function or a feature of Windows Installer. As with reauthoring applications, several vendors provide tools to enable administrators to repackage applications for a variety of needs. The same vendors who provide tools to reauthor applications can also help repackage them. During repackaging, an application, the existing components, such as DLLs, .ini files, registry settings, and shortcuts, are replaced, and then the administrator creates a path for Windows Installer to find these items at installation time. For more information about repackaging applications in the .msi format, see the Windows Installer SDK for detailed documentation about the Windows Installer package format.

Group Policy Software Installation Extension Processes and Interactions

Because software can be published for users, assigned to users, or assigned to computers, administrators can establish a workable combination of those three options to meet an organizations software management goals. Publishing Software for Users The benefit of publishing software, instead of assigning it, is that it requires less management when change occurs in the Active Directory structure. Typically, applications that are nonessential for the users are published. When software is published for a user, it does not initially appear to be installed on the computer. There is no Windows Installer advertisement information about the software on the computer in the registry, on the desktop, or on Start menu as a shortcut. On an as-needed basis, the user installs the published software by using Add or Remove Programs in Control Panel. An exception is when an application is published in a new GPO, when the GPO must be simultaneously linked to the users in a site, domain, or OU. If a GPO is linked and the software is deployed at the same time, the GPO must be refreshed by an administrator or by a user logging on before the application appears in Add or Remove Programs. Users can also install a published application by opening an associated document if the application is deployed to do that (if Auto-Installis selected). The user can remove published software, and then later choose to reinstall it, by using Add or Remove Programs. The following figure shows how Group Policybased software publishing works. Group Policybased Software Publishing for Users

Assigning Software There are three methods for assigning software: assign to users on-demand, assign to users, or assign to computers. Note

By default, Group Policy allows administrators to configure a user-assigned application that has a staggered, on-demand installation. Windows Server 2003 allows administrators to turn off the default installation and install the entire application at once. This is the same behavior as computer-assigned application installation.

Assigning Software to be Available on Demand After a software package is assigned to users in a site, domain, or OU, the software is advertised on user desktops. The application becomes available to the user the next time the user logs on (if the applications GPO applies to that user). The application is fully installed by the user from the Start menu, from Add or Remove Programs, from a desktop shortcut, or by opening a document (on demand) that has a file name extension that is associated with the application. The user can remove the software, and then later choose to reinstall it as they did previously. Group Policy ensures that assigned applications that are available on-demand are available, regardless of whether users remove them, and that the applications are available again the next time the user logs on or starts the computer. Assigning Software to Users After a software package is assigned to users in a site, domain, or OU, administrators can use the Install this application at logon option to install the whole application the next time the computer starts, or after the user logs off and then logs on again. Alternatively, for users of Windows XP Professional, Logon Optimization can delay the installation of software to the second logon to prevent installation during the first logon. The application is also immediately available in Add or Remove Programs. The user can remove the software, and then later choose to reinstall it. Note

Some published applications might not appear in Add or Remove Programsin a domain that has multiple domain controllers until the changes have replicated to all domain controllers in the domain.

The following figure shows the client-side perspective of assigning Group Policybased software deployment. Group Policybased Software Assignment to Users

Assigning Software to Computers After assigning a software package to computers in a site, domain, or OU, the software is installed the next time the computer restarts or the user logs on. For users of Windows XP Professional, Logon Optimization can delay the installation of software to the second logon to prevent installation during the first logon. Only the local or network administrator can remove the software, though a user can repair the software. The following figure shows the client-side perspective of publishing Group Policybased software deployment. Group Policybased Software Assignment to Computers

Patches for Installed Applications Installing a patch updates a previously installed application or applications. A patch package (.msp file) is obtained from the software manufacturer or from the internal developers of the original program. Installing patches allows existing applications to be updated without removing the product. This preserves the customizations of the installation and can lower the cost of making the change. The patch might change only a few bytes of a single application file. It is more efficient to distribute those few bytes than to remove and redeploy the whole product. Note

A patch might change all of the files and registry keys in a product.

After a patch is applied, it is cached on the users computer, this allows the user to:

Perform any installation on demand. Reinstall the application. Repair the application.

Remove the application.

A patch package (.msp file) does not include a database as a regular installation package does. Instead, it contains, at a minimum, one database transform that adds patching information to the database of its target Windows Installer .msi package. For an application to perform maintenance operations, such as adding, removing, or repairing the installation, the package codes for both the installed application and the source must match. Software Upgrades During an upgrade where the ProductVersion or ProductCode property of the package has changed, Windows Installer searches for upgradeable products by querying the Upgrade table of the upgrade package. The newer version of the product is installed. If Windows Installer finds an older version of the product, it removes the old version. The author of the applications setup can choose to remove the old version, and then install the new version. The maintenance mode and removal do not trigger these actions because remove existing versions of an application is now automatic. The Windows Installer package for a repackaged application does not have declared upgrade relationships. Administrators must manually create upgrade relationships. The Group Policy Software installation extension can be used to create upgrade relationships between the new package and the packages that the application replaces. This includes making a formal upgrade relationship between two similar products from completely different vendors. A vendors application can replace anothers, or an administrator can upgrade a repackaged application.

Group Policy Software Installation Extension Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Group Policy Software Installation Extension Tools and Settings

In this section

Group Policy Software Installation Extension Tools Group Policy Software Installation Extension Group Policy Settings and Registry Entries Related Information

This section summarizes the tools and settings associated with the Group Policy Software installation extension.

Group Policy Software Installation Extension Tools

The following tools are associated with the Group Policy Software installation extension:

InstallShield Application Experience Lookup Service Windows Installer

InstallShield Category InstallShield products do not ship with Windows. Version compatibility InstallShield Corporation creates several tools for building Windows Installer packages that work on all versions of Windows managed by Group Policy. Make sure you use the correct version for the systems that you manage. InstallShield creates popular tools for developing Windows Installer .msi packages. Application Experience Lookup Service Category The Application Experience Lookup Service is a new service included in Windows Server 2003 with Service Pack 1 (SP1). Version compatibility

This service is part of an infrastructure that provides a way to apply fixes to applications in order to ensure that they run on newly released Windows operating systems or service packs. This service needs to be running for the application fixes to work. There are no entry points to this service for customizations and it is for operating system internal use only. There is no out-of-the box communication in the service. This service does not use any Active Directory, network, or internet resources. The functionality of the service can be disabled though Group Policy settings for application compatibility. When this setting is disabled, the service will continue to run, but there will be no calls made to the service. The service itself cannot be stopped or disabled. Windows Installer Category Windows Installer ships with Microsoft Windows Server 2003 family, Windows XP, Windows 2000, and Windows Millennium Edition (Windows Me). The installer is also provided as a service pack for Microsoft Windows NT version 4.0, Windows 98, and Windows 95. Version compatibility Windows Installer version 2.0 adds advanced features and requires Windows NT 4.0 with Service Pack 6 or later, Windows 2000, Windows Me, or Windows XP. Earlier Windows Installer versions require Windows NT 4.0 with Service Pack 3 or later, Windows 2000, or Windows Me. Windows Installer supports advertisement of applications and features according to operating system. The following table outlines Windows Installer advertisement support on different operating systems. Group Policy Software Installation Advertisement Support on Different Operating Systems

Operating System Windows 2000 Windows XP

Advertisement Support

Shortcuts and their icons.

NOTE: AppId and Typelib information is only written when an advertised component is installed.

Extensions and their icons specified in the ProgId table. Shell and command Verbs registered underneath the ProgId key. CLSID contexts and InProcHandler.

Install-On-Demand through OLE is only available programmatically through CoCreateInstance (C or C++) and CreateObject or GetObject (Visual Basic). Windows 98 Windows Me Microsoft Windows 95 with IE4.01 Service Pack 1 installed with Windows Desktop Update installed (shell32.dll of 4.72.3110.0 or newer) Windows NT 4.0 with IE4.01 Service Pack 1 installed with Windows Desktop Update installed (shell32.dll of 4.72.3110.0 or newer) Windows 95 Windows NT 4.0 (shell32.dll older than 4.72.3110.0) All of the above except CLSID, which is only written when installing an advertised component. Shell and MIME support. All of the above except CLSID, which is only written when installing an advertised component. Shell and MIME support.

Advertisement is not supported by these platforms.

On Windows 98 or Windows 95 with the updated shell32.dll, advertised shortcuts do not work until the computer is restarted. This only affects the first product that installs the package for Windows Installer. The installation of the product might not require a restart, but any advertised shortcuts do not work until the computer has been restarted. Advertised shortcuts of subsequent installations work without a restart. Conditional statements can check the ShellAdvtSupport property and Version9X property. Windows Installer is a Windows operating system-based service that reduces the total cost of ownership by allowing administrators to manage the installation, modification, upgrade, and removal of software applications using a standard package format. Windows Installer includes the operating system-based service, a package format, and an applicationprogramming interface (API) that allows both the operating system and applications to interact with the service to install, modify, or repair the software.

Group Policy Software Installation Extension Group Policy Settings and Registry Entries
In addition to setting configuration options for the application in Properties, you can use several Group Policy settings to control the behavior of Windows Installer and the Add or Remove Programs feature of Windows. The following tables list the Group Policy settings and associated registry keys that control Windows Installer and Add or Remove Programs. The settings are all part of the System.adm file. The following table lists the Group Policy Machine settings and associated registry keys that control Windows Installer. These settings are found in these locations:

Group Policy Location: MACHINE\Administrative Templates\Windows Components\Windows Installer Registry Location: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows

Group Policy Settings for Windows Installer (Machine)

Setting Disable Windows Installer Always install with elevated privileges Prohibit rollback

Description Disables or restricts the use of Windows Installer. This setting can prevent users from installing software on their systems or permit users to install only those programs offered by a system administrator. Directs Windows Installer to use system permissions when it installs any program on the system. This setting extends elevated privileges to all programs. Prohibits Windows Installer from generating and saving the files it needs to reverse an interrupted or unsuccessful installation. This setting prevents Windows Installer from recording the original state of the system and sequence of changes it makes during installation. It also prevents Windows Installer from retaining files it intends to delete later. As a result, Windows Installer cannot restore the computer to its original state if the installation does not complete. Prevents users from searching for installation files when they add features or components to an installed program. This setting disables the Browse button beside the Use feature from list in the Windows Installer dialog box. Prevents users from using Windows Installer to install patches. Allows Web-based programs to install software on the computer without notifying the user.

Remove browse dialog box for new source Prohibit patching Disable IE security prompt for Windows Installer scripts Enable user control over installs Enable user to browse for source while elevated Enable user to use media source while elevated Enable user to patch

Permits users to change installation options that typically are available only to system administrators. This setting bypasses some of the security features of Windows Installer. It permits installations to complete that otherwise would be halted due to a security violation. Allows users to search for installation files during privileged installations. This setting enables the Browsebutton in the Use feature from dialog box. As a result, users can search for installation files, even when the installation program is running with elevated system privileges. Allows users to install programs from removable media, such as floppy disks and CD-ROMs, during privileged installations. This setting permits all users to install programs from removable media, even when the installation program is running with elevated system privileges. Allows users to upgrade programs during privileged installations. This setting permits all users to

elevated products Allow admin to install from Terminal Services session Cache transforms in secure location on workstation Logging Prohibit User Installs Turn off creation of System Restore Checkpoints

install patches, even when the installation program is running with elevated system privileges. Allows Terminal Services administrators to install and configure programs remotely.

Saves copies of transform files in a secure location on the local computer.

Specifies the types of events that Windows Installer records in its transaction log for each installation. The log, Msi.log, appears in the Temp directory of the system volume. Allows you to configure user installs. This setting is useful in environments where the administrator only wants per-computer applications installed, such as on a kiosk or a Windows Terminal Server. If you disable this setting or do not configure it, the Windows Installer automatically creates a System Restore checkpoint each time an application is installed.

The following table lists the Group Policy User settings and associated registry keys that control Windows Installer. These settings are found in these locations:

Group Policy Location: USER\Administrative Templates\Windows Components\Windows Installer Registry Location: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows

Group Policy Settings for Windows Installer (User)

Setting Always install with elevated privileges Search order Prohibit rollback

Description Directs Windows Installer to use system permissions when it installs any program on the system. This setting extends elevated privileges to all programs. Specifies the order in which Windows Installer searches for installation files. Prohibits Windows Installer from generating and saving the files it needs to reverse an interrupted or unsuccessful installation. This setting prevents Windows Installer from recording the original state of the system and sequence of changes it makes during installation. It also prevents Windows Installer from retaining files it intends to delete later. As a result, Windows Installer cannot restore the computer to its original state if the installation does not complete. Prevents users from installing programs from removable media.

Prevent removable media source for any install

The following table lists the Group Policy User settings and associated registry keys that control Add or Remove Programs. These settings are found in these locations:

Group Policy Location: USER\Administrative Templates\Control Panel\Add or Remove Programs Registry Location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\

Group Policy Settings for Add or Remove Programs (User)

Setting Remove Add or Remove Programs Hide Change or Remove Programs page Hide Add New Programs page Hide Add/Remove Windows

Description Prevents users from using Add or Remove Programs. This setting removes Add or Remove Programs from Control Panel and removes the Add or Remove Programs item from menus. Removes the Change or Remove Programs button from the Add or Remove Programsbar. Removes the Add New Programs button from the Add or Remove Programs bar. Removes the Add/Remove Windows Components button from the Add or Remove

Components page

Programs bar.

Hide the Set Program Access Removes the Set Program Access and Defaults button from the Add or Remove and Defaults page Programs bar. Hide the Add a program from CD-ROM or floppy disk option Hide the Add programs from Microsoft option Hide the Add programs from your network option Go directly to Components Wizard Remove Support Information Specify default category for Add New Programs Removes the Add a program from CD-ROM or floppy disk section from the Add New Programs page. Removes the Add programs from Microsoft section from the Add New Programs page. Prevents users from viewing or installing published programs. This setting removes the Add programs from your network section from the Add New Programs page. Prevents users from using Add or Remove Programs to configure installed services. This setting removes the Set up services section of the Add/Remove Windows Componentspage. Removes links to the Support Info dialog box from programs on the Change or Remove Programs page. Specifies the category of programs that appears when users open the Add New Programspage. If you enable this setting, only the programs in the category you specify are displayed when the Add New Programs page opens.

The following table lists the Group Policy Machine settings and associated registry keys for application compatibility. These settings are found in these locations:

Group Policy Location: MACHINE\Administrative Templates\Windows Components\Application Compatibility Registry Location: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows

Group Policy Settings for Application Compatibility (Machine)

Setting Turn Off Application Compatibility Engine Turn Off Program Compatibility Wizard Remove Program Compatibility Property Page Turn On Application Help Log Events Prevent access to 16-bit applications

Description Controls the state of the application compatibility engine in the system. Controls the state of the Program Compatibility Wizard. When enabled, this setting disables the start page of the wizard in Help and Support, and in the Start menu. Controls the visibility of the Program Compatibility property page shell extension. Blocks known incompatible applications and displays a dialog to the end-user regarding the problem. Specifies whether to prevent the MS-DOS subsystem (ntvdm.exe) from running on this computer. This setting affects the launching of 16-bit applications in the operating system.

The following table lists the Group Policy User settings and associated registry keys for application compatibility. These settings are found in these locations:

Group Policy Location: USER\Administrative Templates\Windows Components\Application Compatibility Registry Location: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows

Group Policy Setting for Application Compatibility (User)

Setting Prevent access to 16-bit applications

Description Specifies whether to prevent the MS-DOS subsystem (ntvdm.exe) from running for all users. This setting affects the launching of 16-bit applications in the operating system.

Related Information
The following resources contain additional information that is relevant to this section.

How Group Policy Software Installation Extension Works Core Group Policy Technical Reference Group Policy Administrative Tools Group Policy Object Editor Tools and Settings Group Policy Management Console Technical Reference Group Policy Settings Reference in the Tools and Settings Collection Resource Kit Tools in the Tools and Settings Collection Microsoft Platform SDK on MSDN for more information about Windows Installer.

Security Settings Extension Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In an Active Directory directory service environment, you can use the Security Settings snap-in to modify the security policy assigned to a Group Policy object that is linked to an organizational unit, domain, or site. The Security Settings snap-in is an extension of the Group Policy Object Editor Microsoft Management Console (MMC) snap-in. You can use the Security Settings snap-in from any computer that is joined to a domain. On a local computer, you can use the Local Security Policy snap-in to modify account and local policies, public key policies, and IP security policies. In this subject

What Is Security Settings Extension? How Security Settings Extension Works Security Settings Extension Tools and Settings

What Is Security Settings Extension?

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section

Security Settings Extension Overview Securing Distributed Systems Related Information

Security settings policies are rules that administrators configure on a computer or multiple computers for the purpose of protecting resources on a computer or network. The Security Settings extension of the Group Policy Object Editor snap-in allows you to define security configurations as part of a Group Policy object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, or organizational units, and enable administrators to manage security settings for multiple computers from any computer joined to the domain. Security settings policies are used as part of your overall security implementation to help secure domain controllers, servers, clients and other resources in your organization. Security settings can control:

User authentication to a network or computer. The resources that users are permitted to access. Whether to record a users or groups actions in the Event log. Membership in a group.

Security Settings Extension Overview

Administrators can use the Security Settings extension to specify the security configuration of a Group Policy object. This in turn affects all the computers in the Active Directory container to which the Group Policy object is linked. All security policies are computer-based policies. To manage security configurations for multiple computers, you can use one of the following options:

Edit specific security settings in a GPO. Use the Security Templates snap-in to create a security template that contains the security policies you want to apply, and then import the security template to a Group Policy object. A security template is a file that represents a security configuration, and can be imported to a GPO, or applied to a local computer, or can be used to analyze security.

The Security Settings extension of Group Policy Object Editor includes the following types of security policies:

Accounts Policies. These polices are defined on computers; they affect how user accounts can interact with the computer or domain. Accounts policies include the following types of policies:

Password Policy. These policies determine settings for passwords, such as enforcement and lifetimes. Password policies are used for domain accounts. Account Lockout Policy. These policies determine the conditions and length of time that an account will be locked out of the system. Account lockout policies are used for domain or local user accounts.

Kerberos Policy. These policies are used for domain user accounts; they determine Kerberosrelated settings, such as ticket lifetimes and enforcement. Local Policies. These policies apply to a computer and include the following types of policy settings:

Audit Policy. Specifies whether to log security events into the Security log on the computer, and specifies what types of security events to log (success, failure, or both). User Rights Assignment. Specify the users or groups that have logon rights or privileges on a computer. Security Options. Specify security settings for the computer such as Administrator and Guest Account names, access to floppy disk drive and CD-ROM drive, installation of drivers, logon prompts and so on.

Event Log. Specifies settings for the application, security, and system logs. Restricted Groups. Controls membership in a security-sensitive (restricted) group, and specifies the groups to which a restricted group should belong. Restricted Groups policy states that only the members that you have added can belong to that group. System Services. Specifies startup options for system services, and define access permissions. Registry. Specifies access permissions (on discretionary access control lists (DACLs) and audit settings (on system access control lists (SACLs)) for registry keys.

File System. Specifies access permissions and audit settings for file system objects.

Securing Distributed Systems

Organizations are faced with the complex, costly, and time-consuming task of securing and managing network systems, and keeping their desktops and servers protected with up-to-date security updates. Administrators' tasks include:

Keeping desktops and servers up-to-date with the latest security patches. Ensuring that the corporate security policies are enforced across desktops and servers. Monitoring systems for potential security compromises.

Organizations need efficient ways to maintain network security and manage updates, while reducing total costs for security management. Policy-Based Security Settings Management Windows Server 2003, Windows 2000, and Windows XP provide an integrated policy-based management infrastructure to help administrators manage and enforce their security policies. Windows Server 2003 and Windows 2000, through Group Policy and Active Directory, enable IT administrators to define and apply security settings policies to users, groups, and network servers and clients. A group of servers with the same functionality can be created (for example, a Microsoft Internet Information Services (IIS) server), and then Group Policy objects can be used to apply common security settings to the group. If more servers are added to this group later, many of the common security settings are automatically applied, reducing deployment and administrative labor. Using security settings policies simplifies and centralizes security configuration and management for computers running Windows Server 2003. Security policies can help reduce administrative tasks by automating some processes for applying security to servers. Computers running Windows Server 2003 that are members of a domain periodically access Active Directory; if they detect that a new policy exists or that an existing one has been changed, they automatically download the policy and apply it locally. Common Scenarios for Using Security Settings Policies Security Settings policies are used to manage the following aspects of security: accounts policy, local policy, user rights assignment, registry values, file and registry Access Control Lists (ACLs), and service startup modes. As part of your security strategy, you can create GPOs with security settings policies configured specifically for the various computer roles in your organization, such as domain controllers, file servers, member servers, clients, and so on. You can create an organizational unit (OU) structure that groups computers according to their roles. Using OUs is the best method for separating specific security requirements for the different computer roles in your network. This approach also allows you to apply customized security templates to each class of server or computer. After creating the security templates, you create a new Group Policy object (GPO) for each of the OUs, and then import the security template (.inf file) into the new GPO. Importing a security template to a Group Policy object ensures that any accounts to which the GPO is applied automatically receive the templates security settings when the Group Policy settings are refreshed. On a workstation or server, the security settings are refreshed every 90 minutes, and on a domain controller, this process occurs every 5 minutes if changes have occurred in any of the GPO settings that apply. The settings are also refreshed every 16 hours, whether or not any changes have occurred. By using Group Policy-based security configurations in conjunction with the delegation of administration, you can ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU. This approach makes it simple to update a number of servers with any additional changes required in the future. Dependencies on Other Operating System Components For computers that are members of a Windows Server 2003 or Windows 2000 Server domain, Security Settings policies depend on the following components: Active Directory. The Windows-based directory service, Active Directory, stores information about objects on a network and makes this information available to administrators and users. By using Active Directory, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single logon.

Group Policy. The infrastructure within Active Directory that enables directory-based configuration management of user and computer settings on computers running Windows Server 2003, Windows 2000, and Windows XP Professional operating systems. By using Group Policy, you can define configurations for groups of users and computers, including policy settings for Windows Server 2003 registry-based policies, software installation, scripts, folder redirection, Remote Installation Services, Internet Explorer maintenance, and security. Domain Name System (DNS). A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to domain names. This allows users, computers, and applications to query the DNS to specify remote systems by fully qualified domain names rather than by IP addresses. Winlogon. A component of the Windows operating system that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three components: the Winlogon executable, a Graphical Identification and Authentication dynamic-link library (DLL), and any number of network providers. Setup. Security configuration interacts with the operating system setup process during a clean installation or upgrade of Windows Server 2003 or Windows 2000 Server. Security Accounts Manager (SAM). A Windows service used during the logon process. SAM maintains user account information, including groups to which a user belongs. Local Security Authority (LSA). A protected subsystem that authenticates and logs users onto the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system. Windows Management Instrumentation (WMI). A component of the Microsoft Windows operating system, WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI provides access to information about objects in a managed environment. Through WMI and the WMI application programming interface (API), applications can query for and make changes to static information in the Common Information Model (CIM) repository and dynamic information maintained by the various types of providers. Resultant Set of Policy (RSoP). An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if situation, and what the extension has done in an actual situation. This allows administrators to determine easily the combination of policy settings that apply to, or will apply to, a user or computer. Service Control Manager (SCM). Used for configuration of service startup modes and security. Registry. Used for configuration of registry values and security. File system. Used for configuration of security. File system conversions. Security is set when an administrator converts a file system from FAT to NTFS. Microsoft Management Console (MMC). The user interface for the Security Settings tool is an extension of the Group Policy Object Editor MMC snap-in. Security Settings Policies and Group Policy The Security Settings extension of Group Policy Object Editor is part of the Windows Server 2003 Security Configuration Manager tool set. The following components are associated with Security Settings: a configuration engine; an analysis engine; a template and database interface layer; setup integration logic; and the secedit.exe command line tool. The security configuration engine runs on computers running Windows Server 2003, Windows 2000 and Windows XP and is responsible for handling security configuration editor-related security requests for the system on which it runs. The analysis engine analyzes system security for a given configuration and saves the result. The template and database interface layer handles reading and writing requests from and to the template or database (for internal storage). The Security Settings extension of Group Policy Object Editor handles Group Policy from a domain-based or local computer. The security configuration logic integrates with Windows Server 2003 and Windows 2000 setup and manages system security for a clean installation or upgrade of

Windows Server 2003 and Windows 2000 systems. Security information is stored in templates (.inf files) or in the Secedit.sdb database. The following figure shows Security Settings and related components, including:

Scesrv.dll. Provides the core security engine functionality. Scecli.dll. Provides the client-side interfaces to the security configuration engine and provides data to Resultant Set of Policies (RsoP). Wsecedit.dll. The Security Settings extension of Group Policy Object Editor. Scecli.dll is loaded into Wsecedit.dll to support the Security Settings user interface. Gpedit.dll. The Group Policy Object Editor MMC snap-in.

Security Settings Policies and Related Components

Related Information
The following resources contain additional information that is relevant to this section.

"What Is Core Group Policy?" in the Group Policy Technical Reference collection "Security Policy Settings" in the Security collection.

How Security Settings Extension Works

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section

Security Settings Extension Architecture Security Settings Policy Processes and Interactions

Related Information

The Security Settings extension of the Group Policy Object Editor MMC snap-in allows you to specify security configurations as part of Group Policy objects, which can be linked to Active Directory sites, domains, or organizational units. An Active Directory-based deployment of security settings policy requires deployment of at least Windows 2000 Server, and Windows 2000 Professional or Windows XP clients. However, to gain full advantage of the latest security settings policies, you need:

Windows Server 2003 with Active Directory installed and DNS dynamic update protocol properly configured. Windows XP client computers. Group Policy Object Editor, which you can access by using Group Policy Management Console (GPMC). The Security Settings extension of Group Policy Object Editor.

For computers that are not participating in a domain, you can use the Local Security Policy snap-in. This section discusses how the Security Settings extension of Group Policy Object Editor works. It presents information about how security settings are stored and how security settings policy is processed.

Security Settings Extension Architecture

The Security Settings extension of Group Policy Object Editor is part of the Security Configuration Manager tools, as shown in the following diagram: Security Settings Architecture

The security settings configuration and analysis tools include a security configuration engine, which provides local computer (non-domain member) and Group Policy-based configuration and analysis of security settings policies.

The security configuration engine also supports the creation of security policy files. The primary components of the security configuration engine are: Scecli.dll Provides client side interfaces to the security configuration engine and does Resultant Set of Policies (RsoP) logging during policy propagation. Scesrv.dll Provides core security engine functionality including support for import, configure, analyze, and policy propagation operations. Communications between components of the Security Settings extension occurs by using the following methods:

Component Object Model (COM) calls Local remote procedure call (LRPC) Lightweight Directory Access Protocol (LDAP) Active Directory Service Interfaces (ADSI) Server Message Block (SMB) Win32 APIs Windows Management Instrumentation (WMI) calls

The following table describes the Security Settings-related components: Components and Description

Component Scesrv.dll

Description

This .dll is hosted in Services.exe and runs under local system context. Scesrv.dll provides core Security Config functionality, such as import, configure, analyze, and policy propagation. Scesrv.dll performs configuration and analysis of various security-related system parameters by calling corresp including LSA, SAM, and the registry. Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made over and fails the call if it is not. On domain controllers, Scesrv.dll receives notifications of changes made to SAM and the LSA that need to be sy domain controllers. Scesrv.dll incorporates those changes into the Default Domain Controller Policy GPO by usin template modification APIs. Scesrv.dll also performs configuration and analysis operations.

Scecli.dll

This is the client-side interface or wrapper to scesrv.dll. Scecli.dll is loaded into Wsecedit.dll to support MMC sn setup to configure default system security and security of files, registry keys, and services installed by the Setu The command line version of the security configuration and analysis user interfaces, Secedit.exe, uses Scecli.dl Scecli.dll implements the client side extension for Group Policy. Scesrv.dll uses Scecli.dll to download applicable Group Policy files from Sysvol in order to apply Group Policy se local computer. Scecli.dll logs application of security policy into WMI (RSoP). Scesrv.dll policy filter uses Scecli.dll to update Default Domain Controller Policy GPO when changes are made to

Wsecedit.dll Secedit.sdb User databases .Inf Templates

The Security Settings extension of the Group Policy Object Editor snap-in. You use this tool to configure securit Policy object for a site, domain, or organizational unit. You can also use SecuritySettings to import security tem

This is a permanent system database used for policy propagation including a table of persistent settings (somet a tattoo table) for rollback purposes. A user database is any database other than the system database created by administrators for the purposes of analysis of security.

These are text files that contain declarative security settings. They are loaded into a database before configurat Policy security policies are stored in .Inf files on the Sysvol folder of domain controllers, where they are downlo copy) and merged into the system database during policy propagation.

Security Settings Policy Processes and Interactions

Before learning about how Security Settings policy is processed, it is useful to review some basic concepts related to Group Policy processing. Group Policy Processing When a computer starts and a user logs on, computer policy and user policy are applied according to the following sequence:

The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start. An ordered list of Group Policy objects is obtained for the computer. The list might depend on these factors:

Whether the computer is part of a domain and, therefore, subject to Group Policy through Active Directory. The location of the computer in Active Directory.

Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not changed, no processing is done. Computer policy is applied. These are the settings under Computer Configuration from the gathered list. This is a synchronous process by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior. The user presses CTRL+ALT+DEL to log on. After the user is validated, the user profile loads; it is governed by the policy settings that are in effect. An ordered list of Group Policy objects is obtained for the user. The list might depend on these factors:

Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory. Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback policy setting. The location of the user in Active Directory.

Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not changed, no processing is done. User policy is applied. These are the settings under User Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed. Logon scripts run. Unlike Windows NT 4.0 scripts, Group Policy-based logon scripts are hidden and asynchronous by default. The user object script (which, as in Windows NT 4.0, is run in a normal window) runs last. The operating system user interface that is prescribed by Group Policy appears.

Note

In mixed environments, there are three special cases you need to consider: If the computer account object is in a Windows NT 4.0 domain and the user account object is in Active Directory, only computer (not user) System Policy is processed when the user logs on. Then, user (not computer) Group Policy is processed. If the computer account object is in Active Directory and the user account object is in a Windows NT 4.0 domain, computer (not user) Group Policy is processed during computer startup. When the user logs on, user (not computer) System Policy is processed. If the Windows XP computer and user accounts are members of a Windows NT 4.0 domain, only System Policy (not Group Policy) for the computer and user is applied when the user logs on.

Group Policy Objects (GPOs) Storage A Group Policy object is a virtual object that is identified by a Globally Unique Identifier (GUID) and stored at the domain level. The policy setting information of a GPO is stored in the following two locations:

Group Policy containers in Active Directory. The Group Policy container is an Active Directory container that contains GPO properties, such as version information, GPO status, plus a list of other component settings. Group Policy templates in a domains system volume folder(Sysvol). The Group Policy template is a file system folder that includes policy data specified by .adm files, security settings, script files, and information about applications that are available for installation. The Group Policy template is located in the Sysvol folder in the domain \Policies subfolder.

The GROUP_POLICY_OBJECT structure provides information about a GPO in a GPO list, including the version number of the GPO, a pointer to a string that indicates the Active Directory portion of the GPO, and a pointer to a string that specifies the path to the file system portion of the GPO. Group Policy Processing Order Group Policy settings are processed in the following order:

1. 2. 3. 4.

Local Group Policy object: Each Windows XP computer has exactly one Group Policy object that is stored locally. Site: Any Group Policy objects that have been linked to the site are processed next. Processing is synchronous and in an order that is specified by the administrator. Domain: Processing of multiple domain-linked Group Policy objects is synchronous and in an order specified by the administrator. Organizational units: Group Policy objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy objects that are linked to its child organizational unit, and so on. Finally, the Group Policy objects that are linked to the organizational unit that contains the user or computer are processed.

At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy objects can be linked. If several Group Policy objects are linked to an organizational unit, their processing is synchronous and in an order that is specified by the administrator. This order means that the local Group Policy object is processed first, and Group Policy objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy objects. This is the default processing order and administrators can specify exceptions to this order. A Group Policy object that is linked to a site, domain, or organizational unit (not a local Group Policy object) can be set to Enforced with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as Block Inheritance. Group Policy object links that are set to Enforced are always applied, however, and they cannot be blocked. Security Settings Policy Processing Security Settings policy is processed in the context of Group Policy processing.

1.
2.

During Group Policy processing, the Group Policy engine determines which security settings policies to apply. If security settings policies exist in a GPO, Group Policy invokes the Security Settings client-side extension. The Security Settings extension downloads the policy from the appropriate location such as a specific domain controller. The Security Settings extension merges all security settings policies according to precedence rules. The processing is according to the Group Policy processing order of local, site, domain, and organizational unit (OU), as described earlier in the Group Policy Processing Order section.If multiple GPOs are in effect for a given computer and there are no conflicting policies, then the policies are cumulative and are merged. This example uses the Active Directory structure shown in the following figure (Multiple GPOs and Merging of Security Policy). A given computer is a member of OU2, to which the GroupMembershipPolGPO GPO is linked. This computer is also subject to the UserRightsPolGPO GPO, which is linked to OU1, higher in the hierarchy. In this case, no conflicting policies exist so the computer receives all of the policies contained in both theUserRightsPolGPO and the GroupMembershipPolGPO GPOs. Multiple GPOs and Merging of Security Policy

3.

4.

5.

The resultant security policies are stored in secedit.sdb, the security settings database. The security engine gets the security template files and imports them to secedit.sdb. The security settings policies are applied to computers.

6.

The following figure illustrates the security settings policy processing. Security Settings Policy Processing

Merging of Security Policies on Domain Controllers Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged:

Network Security: Force logoff when logon hours expire Accounts: Administrator account status Accounts: Guest account status Accounts: Rename administrator account Accounts: Rename guest account

Another mechanism exists that allows security policy changes made by administrators using net accounts to be merged into the Default Domain PolicyGPO. User rights changes that are made by using Local Security Authority (LSA) APIs are filtered into the Default Domain Controllers Policy GPO. Special Considerations for Domain Controllers If an application is installed on a primary domain controller (PDC) with operations master role (also known as flexible single master operations or FSMO) and the application makes changes to user rights or password policy, these changes must be communicated to ensure that synchronization across domain controllers occurs. Scesrv.dll receives a notification of any changes made to the security account manager (SAM) and LSA that need to be synchronized across domain controllers and incorporates the changes into the Default Domain Controller Policy GPO by using Scecli.dll template modification APIs. When Security Settings are Applied There are several instances after you have edited the security settings policies, when the settings are refreshed on the computers in the organizational unit linked to your Group Policy object:

When a computer is restarted. 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.

It is possible to change this default period by using the registry entry MaxNoGPOListChangesInterval in the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon \GPExtentions\{827D319E-6AC-11D2-A4EA-00C04F79F83A}, The data type of this entry is REG_DWORD and the value is number of minutes. Note

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Microsoft Windows Server 2003 Deployment Kit companion CD.

Persistence of Security Settings Policy Security settings can persist even if a setting is no longer defined in the policy that originally applied it. In Windows Server 2003 and Windows XP, security settings might persist in the following cases:

The setting has not been previously defined for the computer. The setting is for a registry security object. The settings are for a file system security object.

In Windows 2000, security settings might persist even if the setting is no longer defined in the GPO that originally applied it. All settings applied through local policy or through a Group Policy object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is. This behavior is sometimes referred to as tattooing. Registry and file security settings will maintain the values applied through Group Policy until that setting is set to other values. On domain controllers running Windows Server 2003 or Windows 2000, all security settings persist. Permissions Required for Policy to Apply Both Apply Group Policy and Read permissions are required to have the settings from a Group Policy object apply to users or groups, and computers. Filtering Security Policy By default, all GPOs have Read and Apply Group Policy both Allowed for the AuthenticatedUsers group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or will not have a Group Policy object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU. Note

Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it.

Migration of GPOs Containing Security Settings In some situations, a policy administrator might want to migrate GPOs from one domain environment to another environment. The two most common scenarios are test-to-production migration, and production-to-production migration. The GPO copying process has implications for some types of security settings. Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the Sysvol share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs is not as simple as taking a folder and copying it from one computer to another.

The following security policies can contain security principals and might require some additional work to successfully move them from one domain to another.

User rights assignment Restricted groups Services File system Registry The GPO DACL, if you choose to preserve it during a copy operation

To ensure that data is copied correctly, administrators can use Group Policy Management Console (GPMC). When migrating a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also introduces migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs. For more information about GPMC, see How Group Policy Management Console Works in this collection. Security Settings Policies Security Settings includes the following types of policies: Account Policies Defined for computers, account policies affect how user accounts can interact with the computer or domain. Account policies are implemented at the domain level. For domain controllers, Windows Server 2003 and Windows 2000 allow only one domain account policy: the account policy applied to the root domain of the domain tree. The domain account policy becomes the default account policy of any Windows-based computer that is a member of the domain; this account policy affects all domain users. If an account policy is defined for an organizational unit (OU), it will affect only local accounts on member servers. The account policy settings for the OU affect the local policy on any computers contained in the OU. For domain accounts, only one account policy is permitted per domain. This account policy must be specified in the Default Domain Policy GPO, or in a new GPO that is linked to the root of the domain and has precedence over the Default Domain Policy GPO. The Default Domain Policy GPO is created when a computer running Windows Server 2003 or Windows 2000 Server is first promoted to domain controller. A domain controller always gets the account policy from a GPO linked to the domain, by default from the Default Domain Policy GPO. Account policies include the following types of policies: Password Policy Used for domain or local user accounts. Determines settings for passwords, such as enforcement and lifetimes. Account Lockout Policy Used for domain or local user accounts. Determines the circumstances and length of time that an account will be locked out of the system. Kerberos Policy Used for domain user accounts. Determines Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in local computer policy. Local Policies These policies apply to the local computer and include the following settings: Audit Policy Determine whether security events are logged into the Security log on the computer. Also determines whether to log successful attempts, failed attempts or both. (The Security log is part of Event Viewer.) User Rights Assignment Determine which users or groups have logon rights or privileges on the computer. Security Options Enable or disable security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.

Event Log Event Log security policies specify attributes for events logs such as log size maximum, access rights, and retention methods. There are settings for application, security, and system logs. Restricted Groups You can define two properties for restricted groups, Members, and Members Of. The Members list defines who belongs and who does not belong to the restricted group. The Member Of list specifies which other groups the restricted group belongs to. System Services You can specify security policy for starting system services in automatic or manual mode, or to disable them. You can also set security properties on the objects to specify access permissions, inheritance or auditing settings, and ownership. Registry You can configure security descriptors for registry keys. File System You can use Security Settings to configure security descriptors for files, folders for file system objects. Predefined Security Templates Windows 2000 and Windows Server 2003 provide predefined security templates that you can use as a starting point for creating security policies that are customized to meet different organizational requirements. The templates can be customized using the Security Templates snap-in. After you customize the predefined security templates, they can be used to configure an individual computer or multiple computers. To configure individual computers, you can use the Security Configuration and Analysis snap-in, the secedit.exe command line tool, or you can import the template into Local Security Settings. You can configure multiple computers by importing a template into a Group Policy object. You can also use a security template as a baseline for analyzing a system for potential security gaps or policy violations using the Security Configuration and Analysis snap-in. By default, the predefined security templates are stored in: Systemroot\Security\Templates. Compatible (compatws.inf) Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the highest privilege, while Users have the lowest. One way to significantly improve the security, reliability, and total cost of system ownership is to do the following:

Make sure that end-users are members of the Users group Deploy applications that can run successfully under a User context. Applications that comply with the Certified for Windows Program meet this criterion. However, applications that are not certified for Windows 2000 or Windows Server 2003 might not run under a User context. The Certified for Windows Program is designed to ensure that applications that run on Windows Server 2003 or Windows 2000 Server can meet the highest standards for reliability, availability, security, and supportability. If you must support non-certified applications, you have two options:

Allow end-users to be members of the Power Users group. Relax the default permissions granted to the Users group.

Since Power Users have inherent capabilities, such as creating users, groups, printers and shares, some customers would rather relax the default User permissions than allow end-users to be members of the Power Users group. This is precisely what the Compatible template is for. The Compatible template loosens the default file and registry permissions granted to Users in a manner that is consistent with the requirements of most non-certified applications. Additionally, since it is assumed that the administrator applying the compatible template does not want end users to be Power Users, the compatible template also removes all members of the Power Users group. Note

The Compatible template should not be applied to domain controller computers. For example, do not import the compatible template to the Default Domain Policy GPO or the Default Domain Controller Policy GPO.

Information about the Microsoft Certified for Windows Program is available on the Windows Server 2003 Web site. Secure (secure*.inf) The Secure templates (secure*.inf) define enhanced security settings that are least likely to impact application compatibility. For example, the Secure templates define stronger password, lockout, and audit settings. The Secure templates also limit the use of the LAN Manager and NTLM authentication protocols by configuring clients to send only NTLMv2 responses and Servers to refuse LAN Manager responses:

In order to apply securews.inf to a member computer, all of the domain controllers that contain the accounts of all users that will logon to the client must be running Windows NT 4.0 Service Pack 4 or higher. In order to apply securews.inf to a member computer that is joined to a domain containing Windows NT 4.0 domain controllers, the clocks between the NT 4.0 domain controllers and the member computers must be within 30 minutes of each other. If a client is configured with securews.inf, it will not be able to connect to servers that only use the LAN Manager authentication protocol or Windows NT 4.0 servers prior to SP 4 using a local account defined on the target server. If a client is configured with securews.inf, it will not be able to connect to Windows 2000 or Windows NT 4.0 servers using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client. If a client is configured with securews.inf, it will not be able to connect to a computer running Windows XP by using a local account that is defined on the target computer unless the clock on the target computer is within 20 hours of the clock on the client. If a client is configured with securews.inf, then it will not be able to connect to servers running LAN Manager that are operating in share-level security mode. If a server is configured with securews.inf, then a user with a local account on that server will not be able to connect to the server by using that local account from a client computer that is running only LAN Manager. If a Windows 2000 server is configured with securews.inf, then a client using a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two computers are within 30 minutes of each other. If a computer running Windows 2000 or Windows Server 2003 is configured with securews.inf, then a client with a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two computers are within 20 hours of each other. If a domain controller is configured with securedc.inf, then a user with an account in that domain will not be able to connect to any member server from a client computer that is running only LAN Manager using their domain account.

LAN Manager clients include Windows for Workgroups, Windows 95, and Windows 98 platforms that do not have the Active Directory Client Extensions Pack installed. If the Active Directory Client Extensions Pack is installed on Windows 95 or Windows 98 platforms, those clients can use NTLMv2. Microsoft Windows Millennium Edition supports NTLMv2. Windows NT-based computers (SP 4 and higher) can be configured to send only NTLMv2 responses by setting HKEY_LOCAL_MACHINE\System CurrentControlSet\Control\Lsa\LMCompatibilityLevel =3 or higher. The LMCompatibilityLevel registry value is exposed in the Local Policies\Security Options node of the Security Configuration Manager tools (Local Security Policy and Security Settings extension of Group Policy Object Editor) as Network Security: Lan Manager authentication level policy setting. Clients that have the secure or high secure template applied to them will have LMCompatibility set to 3 or higher. The Secure templates also provide further restrictions for anonymous users by preventing anonymous users (for example, users from untrusted domains) from doing the following:

Enumerating account names and shares

Performing SID to Name or Name to SID translations

Finally, the Secure templates enable server-side SMB packet signing, which is disabled by default for workstations and servers. Since client-side SMB packet signing is enabled by default, SMB packet signing is always negotiated when workstations and servers are operating at the secure level. High Secure (hisec*.inf) The High Secure templates are supersets of the Secure templates that impose further restrictions on the levels of encryption and signing required for authentication and for the data that flows over Secure Channels and between SMB clients and servers. For example, while the Secure templates cause servers to refuse LAN Manager responses, the High Secure templates cause servers to refuse both LAN Manager and NTLM responses. The secure template enables server-side SMB packet signing, but the High Secure template requires it. The High Secure Template also requires strong (128 bit) encryption and signing for the Secure Channel data that constitutes domain-member and domain-domain trust relationships.

To apply hisecws.inf to a member computer, the following requirements must be met:

All the domain controllers that contain the accounts of all users that will logon to the client must be running Windows NT 4.0 Service Pack 4 or higher, Windows 2000, or Windows Server 2003. All the domain controllers for the domain to which the client is joined must be running at least Windows 2000. To apply hisecdc.inf to a domain controller, all of the domain controllers in all trusted or trusting domains must be running Windows 2000 or later. If a client is configured with hisecws.inf, it will not be able to connect to servers running only LAN Manager or Windows NT 4.0 servers prior to SP 4 using a local account defined on the target server. If a client is configured with hisecws.inf, it will not be able to connect to Windows 2000 or Windows NT 4.0 servers using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client. If a client is configured with hisecws.inf, it will not be able to connect to a computer running Windows 2000 server or Windows Server 2003 using a local account defined on the target server unless the clock on the target server is within 20 hours of the clock on the client. If a client is configured with hisecws.inf, then it will not be able to connect to servers running LAN Manager operating in share level security mode. If a server is configured with hisecws.inf, then a client with a local account on that server will not be able to connect to it from a client that does not support NTLMv2. If a server is configured with hisecws.inf, then a Windows NT client with a local account on that server will not be able to connect to the server unless the Windows NT client is configured to send NTLMv2 responses. If a server is configured with hisecws.inf, then all clients that want to use SMB to connect to that server must have client-side SMB packet signing-enabled. Client-side SMB packet-signing is enabled by default for all Windows 2000 computers. If a domain controller is configured with hisecdc.inf, then a user with an account in that domain will not be able to connect to member servers by using the domain account if the connection is being made from a computer using only LAN Manager authentication protocol. If a domain controller is configured with hisecdc.inf, then a user with an account in that domain will not be able to connect to member servers using that domain account unless the following conditions apply:

Both client and target server are Windows 2000 or Windows Server 2003 and, thus, can use Kerberos rather than LAN Manager-based authentication.

The client is configured to send NTLMv2 responses.

If a domain controller is configured with hisecdc.inf, then LDAP clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. Thus, bind requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with Windows XP or Windows Server 2003 request data signing if Transport Layer Security\Secure Sockets Layer (TLS\SSL) protocol is not already being used. If TLS\SSL is being used, then data signing is considered to be negotiated.

Clients that do not support NTLMv2 include Windows for Workgroups, Windows NT clients prior to SP 4, and Windows 95 and Windows 98 platforms that do not have the DS Client Pack installed. Windows NT-based computers (SP 4 and higher) can be configured to send only NTLMv2 responses by settingHKEY_LOCAL_MACHINE\System CurrentControlSet\Control\Lsa\LMCompatibilityLevel = 3 or higher. The LMCompatibilityLevel registry value is exposed in the Local Policies\Security Options node of the security configuration manager tools (Local Security Settings and Security Settings extension of Group Policy Object Editor) as the Network Security: Lan Manager authentication level policy setting. Clients that have the secure or high secure template applied to them will have LMCompatibility set to 3 or higher. In addition to further restrictions on the use of computers running LAN Manager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the High Secure templates also restrict clients from caching domain credentials for subsequent logons when the domain controllers arent available. For example, this would prohibit traveling users who dont have a network connection available for domain authentication from being able to login to their laptop. Finally, Hisecws.inf uses restricted group settings to:

Remove all members of the Power Users group. Ensure that only Domain Admins and the local Administrator account are members of the local Administrators group.

Hisecws defines these group restrictions under the assumption that only applications that are certified for Windows 2000 or Windows Server 2003 are deployed. With certified applications in place, neither the unsecured Compatible template nor the unsecured Power Users group is needed. Instead, end users can successfully run certified applications under the secure context of a normal User, which is defined by the default file system and registry ACLs. Root Directory Permissions (rootsec.inf) Specifies the new root permissions introduced with Windows XP. By default, rootsec.inf defines these permissions for the root of the system drive. This template can be used to reapply the root directory permissions if they are inadvertently changed or the template can be modified to apply the same root permissions to other volumes. As specified, the template does not overwrite explicit ACEs defined on child objects, it propagates only the permissions that are inherited by child objects. No Terminal Server SID (notssid.inf) The default file system and registry ACLs on servers grant permissions to a Terminal Server SID. The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Server is not being used, this template can be applied to remove the unnecessary Terminal Server SID from these file system and registry locations. Removing the ACE for the Terminal Server SID from these default file system and registry locations does not increase the security of the system. Instead of removing the Terminal Server SID, it is recommended to simply run Terminal Server in Full Security mode rather than Application Compatibility mode. When running in Full Security mode, the Terminal Server SID is not used. Setup security.inf Setup security is a computer-specific template that represents the default security settings applied during installation of the operating system including the file permissions for the root of the system drive. This template, or portions thereof, can be used for disaster recovery purposes. Setup security.inf shouldnot be applied by using Group Policy. Note

Do not apply the predefined security templates to production systems without performing comprehensive testing first to ensure that the security and functionality requirements for your specific organization are met.

You can view Security template settings by using the Security Templates snap-in. You can also examine the changes that a template would make if it were applied by using the Security Configuration and Analysis snap-in.

To examine the proposed changes, import the template into a database then perform an analysis against that database. Performing an analysis does not change any system settings, but will highlight the differences between the settings specified in the template and the settings as they currently exist on the system.

Related Information
The following resources contain additional information that is relevant to this section.

How Core Group Policy Works in the Group Policy Collection. For information about the Microsoft Certified for Windows Program, see the Windows Server 2003 Web site.

Security Settings Extension Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this subject

Resultant Set of Policies Command Line Tools Security Settings Policies Related Information

This section presents an overview of Resultant Set of Policies (RSoP), which you use to determine which policy settings are currently in effect for a computer or user, and to assess how policy settings would affect computers or users if a specific Group Policy object were applied to them. It also describes the Windows Server 2003 commandline tools for configuring and analyzing security settings.

Resultant Set of Policies

Windows XP and the Windows Server 2003 family of operating systems support an enhanced Group Policy infrastructure that utilizes Windows Management Instrumentation (WMI) to collect Group Policy-related data for planning and troubleshooting Group Policy. This structure is the Resultant Set of Policy (RSoP), a query engine that polls existing policy settings and planned policy settings, and then reports the results of those queries. RSoP polls existing policies based on site, domain, domain controller, and organizational unit. RSoP gathers this information from the Common Information Management Object Model (CIMOM) database (also known as the CIMcompliant object repository) by using WMI. Administrators can use RSoP in one of two modes. To determine which policy settings are in effect for a particular computer or user, administrators use Resultant Set of Policy Logging Mode, and to evaluate how policy settings would affect a computer or user if a specific Group Policy object were applied to users or computers, they use Resultant Set of Policy Planning Mode. In Windows Server 2003, you can use the Group Policy Results node Group Policy Management Console (GPMC) to access the Resultant Set of Policy Logging Mode capabilities. Group Policy Results represents the actual resultant set of policy that was applied to a given user and computer. This information is obtained by directly querying the target user/computer. Each sub-node represents a different RSoP query for a given user/computer combination. The Group Policy Modeling node in GPMC allows administrators to access the Resultant Set of Policy Planning Mode capabilities of Windows Server 2003. Note

As with other Group Policy settings, you must fully test your implementation in a test domain before you deploy your security settings to your production environment.

Some of the security settings extensions of Group Policy provide RSoP classes to represent data pertaining to security policy settings. The Security Policy RSoP Classes section, later in this document, lists the RSoP classes for security policy settings. On Windows 2000 computers, you can use the Gpresults.exe tool to display information about how Group Policy affects both the currently logged-on user and the computer. For information about the Gpresults syntax, see IPSec Policy Extension Tools and Settings in this collection.

The Gpresults command-line tool is available in the Windows 2000 Resource Kit. To download this tool, see the download site for Windows 2000 Server Resource Kit tools. For more detailed information about RSoP and WMI and to download SDKs, see the Microsoft Platform SDK link on the Web Resources page. For more information about GPMC, see the Group Policy Management Console link on the Web Resources page. Security Policy RSoP Classes The RSoP Windows Management Instrumentation (WMI) Method Provider supports the following security policy classes, as listed in the following table. Security Policy RSoP Classes

Class RSOP_AuditPolicy RSOP_File RSOP_RegistryKey RSOP_RegistryValue RSOP_RestrictedGroup

Description

This class represents the security setting for a local Group Policy that relates to the a type. Events can include, among others, system events and account management ev

This class represents a security policy setting that defines the access permissions and securable file system object.

This class represents a security policy setting that defines the access permissions and particular registry key. This class represents specific security-related registry values.

This class represents a security policy setting that defines the members of a restricte group.

RSOP_SecurityEventLogSettingBoolean This class represents a security policy setting that determines whether or not guests application and security event logs.

RSOP_SecurityEventLogSettingNumeric This class represents a security policy setting that determines numeric properties rela application and security event logs. Properties include the number of days to retain e log size. RSOP_SecuritySettingBoolean RSOP_SecuritySettingNumeric RSOP_SecuritySettings RSOP_SecuritySettingString RSOP_SystemService RSOP_UserPrivilegeRight

This class represents the Boolean security setting for an account policy. Account polic policies and account lockout policies.

This class represents the numeric security setting for an account policy. Account polic policies, account lockout policies, and Kerberos-related policies. This is the abstract class from which other RSoP security classes derive. Instances of logged. RSOP_SecuritySettings derives from the RSOP_PolicySetting class. This class represents the string security setting for an account policy.

This class represents the security policy setting that defines the start-up mode and ac particular system service.

This class represents the security setting for a local Group Policy that relates to the a particular user privilege.

RSOP_PolicySetting The RSOP_PolicySetting WMI class is the class from which policy objects for client-side extensions are inherited. An instance of this class corresponds to a specific policy setting. This class was added for Windows XP. Requirements for this class are as follows:

Client: Included in Windows XP Professional. Server: Included in Windows Server 2003.

Command Line Tools

This section describes the Windows Server 2003 command line tools for configuring, analyzing, and updating security settings:

Secedit.exe

Gpupdate.exe

Secedit.exe You can use the secedit.exe command to configure and analyze system security by comparing your current configuration to at least one template. Note

Secedit /refreshpolicy has been replaced with gpupdate. To refresh local Group Policy settings and Group Policy settings that are stored in Active Directory, including security settings, use gpudate. See Gpupdate, later in this section.

Secedit supports the following commands:

analyze configure export import validate generateRollback

Secedit /analyze This command allows you to analyze the security settings on a computer by comparing them against the baseline settings in a database. You can view the results of the analysis in the Security Configuration and Analysissnap-in. Syntax

secedit /analyze /dbFileName.sdb [/cfgFileName] [/overwrite] [/logFileName] [/quiet]

Parameters /db FileName .sdb This parameter specifies the database used to perform the analysis. /cfg FileName This parameter specifies a security template to import into the database prior to performing the analysis. Security templates are created using the Security Templates snap-in. /log FileName This parameter specifies a file in which to log the status of the configuration process. If not specified, configuration data is logged in the scesrv.log file which is located in the %windir%\security\logs directory. /quiet This parameter specifies that the analysis process should take place without further comments. Examples The following is an example of how you can use this command: secedit /analyze /db hisecws.sdb Secedit /configure You can use secedit /configure to configure local computer security by applying the settings stored in a database. Syntax

secedit /configure

/db FileName [/cfg FileName ] [/overwrite][/areasArea1 Area2 ...] [/logFileName] [/quiet]

Parameters /db FileName This parameter specifies the database used to perform the security configuration. /cfg FileName This parameter specifies a security template to import into the database prior to configuring the computer. Security templates are created using theSecurity Templates snap-in. /overwrite This parameter specifies that the database should be emptied prior to importing the security template. If this parameter is not specified, the settings in the security template are accumulated in the database. If this parameter is not specified and there are conflicting settings in the database and the template being imported, the template settings take precedence. /areas Area1 Area2 This parameter specifies the security areas to be applied to the system. If this parameter is not specified, all security settings defined in the database are applied to the system. To configure multiple areas, separate each area by a space. The following security areas are supported:

Area name SECURITYPOLICY GROUP_MGMT USER_RIGHTS REGKEYS FILESTORE SERVICES /log FileName

Description This includes Account Policies, Audit Policy, Event Log settings, and Security Options. This includes Restricted Groups settings. This includes User Rights Assignment. This includes Registry permissions. This includes File System permissions. This includes System Services settings.

This parameter specifies a file in which to log the status of the configuration process. If not specified, configuration data is logged in the scesrv.log file, which is located in the %windir%\security\logs directory. /quiet This parameter specifies that the configuration process should take place without prompting the user. Examples The following are examples of how you can use this command: secedit /configure /db hisecws.sdb/cfgFileName hisecws.inf /overwrite /log hisecws.log If dbFileName (database filename) doesns exist, secedit creates a new database using the settings in cfgFileName (template filename) and applies the configuration. If dbFileName exists, then secedit merges the settings into the database before applying the newly merged configuration. If you omitcfgFileName, secedit applies the configuration using the settings already stored in the database. Secedit /export Running secedit /export allows you to export the security settings stored in the database. Syntax

secedit

/export [/DBFileName] [/mergedpolicy] [/CFG FileName] [/areasArea1 Area2 ...] [/logFileName] [/quiet]
Parameters /db FileName This parameter specifies the database used to configure security. /mergedpolicy This parameter merges and exports domain and local policy security settings. /CFG FileName This parameter specifies the template the settings will be exported to. /areas Area1 Area2 This parameter specifies the security areas to be exported to a template. If an area is not specified, all areas are exported. Each area should be separated by a space. The following table lists the security areas that can be exported. Security Areas and Descriptions

Area name SECURITYPOLICY GROUP_MGMT USER_RIGHTS REGKEYS FILESTORE SERVICES /log FileName

Description This includes Account Policies, Audit Policy, Event Log settings, and Security Options. This includes Restricted Groups settings. This includes User Rights Assignment. This includes Registry permissions. This includes File System permissions. This includes System Services settings.

This parameter specifies a file in which to log the status of the export process. If not specified, the default is %windir%\security\logs\scesrv.log. /quiet This parameter specifies that the configuration process should take place without prompting the user. Examples The following is an example of how you can use this command: secedit /export /db hisecws .inf /log hisecws .log Secedit /import Running secedit /import allows you to import a security template into a database so that the settings specified in the template can be applied to a system or analyzed against a system. Syntax

secedit /import /db FileName .sdb /cfg FileName.inf [/overwrite] [/areasArea1 Area2 ...] [/logFileName] [/quiet]

Parameters /db FileName .sdb This parameter specifies the database to which the security template settings will be imported. /CFG FileName This parameter specifies a security template to import into the database. Security templates are created using the Security Templates snap-in. /overwrite FileName This parameter specifies that the database contents should be cleared prior to importing the security template. If this parameter is not specified, the settings in the security template are accumulated in the database. If this parameter is not specified and there are conflicting settings in the database and the template being imported, the template settings take precedence. /areas Area1 Area2 This parameter specifies the security areas to be exported to a template, as listed in the following table. If an area is not specified, all areas are exported. Each area should be separated by a space.

Area name SECURITYPOLICY GROUP_MGMT USER_RIGHTS REGKEYS FILESTORE SERVICES /log FileName

Description This includes Account Policies, Audit Policy, Event Log settings, and Security Options. This includes Restricted Groups settings. This includes User Rights Assignment. This includes Registry permissions. This includes File System permissions. This includes System Services settings.

This parameter specifies a file in which to log the status of the export process. If not specified, the default is %windir%\security\logs\scesrv.log. /quiet This parameter specifies that the configuration process should take place without prompting the user. Examples The following is an example of how you can use this command: secedit /import /db hisecws.sdb /cfg hisecws.inf /overwrite Secedit /validate You can use secedit /validate to validate the syntax of a security template to be imported into a database for analysis or application to a system. Syntax

secedit /validate FileName

Parameters FileName This parameter specifies the file name of the security template you have created with Security Templates. Examples The following is an example of how you can use this command: secedit /validate /cfg filename

Secedit /GenerateRollback You can run secedit / GenerateRollback to generate a rollback template with respect to a configuration template. When applying a configuration template to a computer you have the option of creating rollback template which, when applied, resets the security settings to the values before the configuration template was applied. Syntax

secedit /GenerateRollback /CFG FileName.inf /RBK SecurityTemplatefilename.inf [/logRollbackFileName.inf] [/quiet]

Parameters /CFG FileName This parameter specifies the file name of the security template for which you want to create a rollback template of. /RBK FileName This parameter specifies the file name of the security template that will be created as the rollback template. Gpupdate You can use gpupdate to refresh local Group Policy settings and Group Policy settings that are stored in Active Directory, including security settings. This command supersedes the now obsolete /refreshpolicy option for the secedit command. Syntax

gpupdate [/target:{computer | user}] [/force] [/wait:Value] [/logoff] [/boot]

Parameters /target:{computer | user} This parameter specifies to processes only the Computer settings or the current User settings. By default, both the computer settings and the user settings are processed. /force Using this parameter ignores all processing optimizations and reapplies all settings. /wait:Value Indicates the number of seconds that policy processing must wait to finish. The default is 90 minutes with a randomized delay of up to 30 minutes for a total maximum refresh interval of up to 120 minutes. 0 equals no wait, and -1 equals wait indefinitely. /logoff This parameter specifies that a user log off occurs after the refresh has completed. This is required for those Group Policy client-side extensions that do not process on a background refresh cycle but that do process when the user logs on, such as user Group Policy Software Installation and Folder Redirection. This option has no effect if there are no extensions called that require the user to log off. /boot Using this parameter restarts the computer after the refresh has completed. This is required for those Group Policy client-side extensions that do not process on a background refresh cycle but that do process when the computer starts up, such as computer Group Policy Software Installation. This option has no effect if there are no extensions called that require the computer to be restarted. /? Using this parameter displays help at the command prompt. Examples The following examples show how you can use the gpupdate command:

gpupdate This command triggers a Group Policy refresh.

gpupdate /target:computer This command triggers a Group Policy refresh of the Computer Settings policies only.

gpupdate /force /wait:100 This command triggers a Group Policy refresh, reapplies all policy settings, and indicates to wait 100 seconds for policy to finish processing.

gpupdate /boot This command triggers a Group Policy refresh and then causes the computer to restart.

Security Settings Policies

Security Settings include policy settings to control the following aspects of security:

Account Policies Local Policies Event Log Restricted Groups System Services Registry File System

For a description of all security settings policies, seeSecurity Policy Settings in the Security Collection.

Related Information
The following resources contain additional information that is relevant to this section.

Security Policy Settings in the Security Collection. How Core Group Policy Works in this collection. What Is Resultant Set of Policy? in this collection. IPSec Policy Extension Tools and Settings in this collection. For information about RSoP and WMI and to download SDKs, see the Microsoft Platform SDK link on the Web Resources page. For information about GPMC, see the Group Policy Management Console link on the Web Resources page. The Tools and Settings Collection.

IPSec Policy Extension Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 Internet Protocol Security (IPSec) consists of a set of open standards designed to ensure private, secure communications over Internet Protocol (IP) networks, through the use of cryptographic security services. IPSec uses policy-based management to define IPSec configuration options and security settings to enable two systems to agree on how to secure traffic between them. To configure IPSec security services, you create IPSec policies. An IPSec policy is a collection of settings and rules that determine IPSec behavior, including the types of network traffic IPSec examines, whether to permit or block traffic, whether to negotiate security, and how to authenticate an IPSec peer.

IPSec is included in the Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; Windows Server 2003, Web Edition operating systems; the 64bit editions of Windows Server 2003, and Windows 2000 Server and Windows 2000 Professional, Windows XP Professional, and Windows XP Home Edition operating systems (Kerberos authentication is not available in Windows XP Home edition). In this subject

What Is IPSec Policy Extension? How IPSec Policy Extension Works IPSec Policy Extension Tools and Settings

What Is IPSec Policy Extension?

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What Is IP Security Policy Extension?

In this section

IPSec Policy Settings and Rules IPSec Policy Core Scenarios IPSec Policy Advantages Related Information

Internet Protocol Security (IPSec) is an architecture defined by the Internet Engineering Task Force (IETF) RFC 2401. This architecture involves several protocols that perform various functions in the architecture. A network is not secure until servers can identify the computers communicating with them. IPSec enables secure, trusted communications between IP addresses. The system behind the IP address has an identity that is verified by using an authentication process. The only computers that must be aware of IPSec are the sending and receiving computers. Each computer handles security at its respective end, and assumes that the medium over which the communication takes place is not secure. Any computers that route data between the source and destination computer are not required to support IPSec. You can deploy IPSec in several scenarios:

A local area network (LAN) for client/server and server-to-server. A wide area network (WAN) for router-to-router and gateway-to-gateway. A remote networks dial-up clients and for Internet access from private networks.

Both the sending and the receiving computer require IPSec configuration (an IPSec policy) to specify options and security settings to enable the two systems to agree on how to secure traffic between them. The IP Security Policies extension of the Group Policy Object Editor snap-in is used to configure IPSec policies based on Active Directory. You can also configure IPSec policies on a computer that is not a domain member; however, it is more difficult to assign and manage IPSec policy configurations and trust relationships for computers that are not members of a trusted domain.

IPSec Policy Settings and Rules

An IPSec policy contains general IPSec policy settings that apply regardless of the rules that are configured, and one or more IPSec policy rules that determine IPSec behavior. General IPSec Policy Settings

The general IPSec policy settings specify the name of the policy, its description for administrative purposes, polling interval for policy change, key exchange settings, and key exchange methods. The following table lists these general settings. General IPSec Policy Settings

Settings Name Description Policy change poll interval

Description The name for the policy.

The optional text description used to describe the purpose of the IPSec policy. It is recommended that you c this description to provide a summary of the settings and rules for the policy.

Specifies the number of minutes between consecutive polls for changes in IPSec policies based on Active Dire does not detect a change in domain or organizational unit membership, or the assignment or removal of ass policy. These events are detected when the Winlogon service polls for changes in Group Policy, which occurs default. Define the way in which new keys are derived and how often they are renewed. Determine the ways in which identities are protected during the key exchange. The default key exchange settings and methods are configured to work for most IPSec deployments. Unless security requirements, default settings should not have to be changed.

Key exchange settings Key exchange methods

IPSec Policy Rules IPSec policy rules specify settings such as the type of traffic IPSec examines, whether to permit or block traffic, whether to negotiate security, and how to authenticate an IPSec peer. IPSec rules include a list of IP filters that specify a particular subset of inbound or outbound network traffic that should be secured. A filter is required to cover any traffic to which an associated IPSec rule applies. IPSec filters are inserted into the IP layer of the TCP/IP networking protocol stack on the computer so that they can filter all inbound or outbound IP packets. IP Filter Settings An IP filter contains the following settings: The source and destination address of the IP packet. You can specify any IP address assigned to the IPSec peer, a single IP address, IP addresses by DNS name, or groups of addresses to specify IP subnets. The protocol over which the packet is being transferred. By default, all protocols in the TCP/IP protocol suite are selected. However, you can specify an individual protocol for this filter to meet special requirements, including custom protocols. The source and destination port for TCP and UDP. By default, all TCP and UDP ports are selected, but you can select a specific TCP or UDP port. IPSec Rule Entries An IPSec rule contains the following configurable entries: Filter list. This list contains one or multiple predefined filters that specify IP addresses and the types of traffic to which an action (permit or block traffic, or negotiate security) is applied. Filter action. This entry specifies the security requirements for data transmission. You can configure one of the following options for a filter action:

Permit. Select this option to permit traffic. IPSec passes this traffic without modification or the requirement for security. This is appropriate for traffic from specific computers that are not IPSec-capable. Be sure to limit the IP filter list to a minimal scope when using this type of filter action, so you do not let traffic through which should be secured. Block. Select this option to block traffic. IPSec silently discards this traffic. Be sure to use an IP filter list that appropriately defines the scope of traffic when using a blocking filter action so that you do not block valid computers from communicating.

Negotiate security. Select this option to negotiate IPSec parameters. IPSec requires the negotiation of security associations and the sending or receiving of IPSec-secured traffic. If you choose this option, you can also configure: security methods; allowance of initial incoming unsecured traffic (Accept unsecured communication, but always respond using IPSec); enabling of communication with non-IPSecenabled computers (Allow unsecured communication with non-IPSec-aware computer); and generation of session keys from new keying material (Use session key perfect forward secrecy (PFS)).

Authentication. This entry contains one or more authentication methods in order of preference that are used for protection during Internet Key Exchange (IKE) negotiations. The available authentication methods are the Kerberos v5 protocol, the use of a certificate issued from a specified certification authority, or a pre-shared key. The IKE protocol securely establishes a trust relationship between each computer, negotiates security options, and dynamically generates shared, secret cryptographic keying material. Tunnel endpoint. This entry contains settings that determine whether traffic is tunneled and, if it is, the tunnel endpoint. The tunnel endpoint is configured on the Tunnel Setting tab in the properties of an IPSec rule within an IPSec policy. Connection type. This entry contains a setting that specifies whether the rule applies to only local area network (LAN) connections, to only Point-to-Point Protocol (PPP)-based connections, or to both types of connections. The interface applicability is configured on the Connection Type tab in the properties of an IPSec rule within an IPSec policy. For more detailed information about IPSec, see What Is IPSec? in the Networking collection.

IPSec Policy Core Scenarios

Corporate networks face various types of external and internal threats from untrusted computers, such as denialof-service attacks, data corruption, and data theft. Network-based attacks on any application or service running on an internal corporate network server can result in:

Loss of service through denial-of-service of the application, the service, or the network. Data corruption. Theft of information such as user credentials or data theft. Administrative control of the server or other network computers.

To protect network servers against network-based attacks, administrators can use IPSec. To provide enhanced security for networks against untrusted network attacks, you can require IPSec-authenticated, signed, and encrypted communication between computers. You can use IPSec as part or your organizations security strategy to provide protection against network-based attacks from untrusted computers. IPSec is intended for use in environments where untrusted network access and attacks on network traffic are a realistic threat. The features of IPSec (such as strong, cryptographic-based authentication and encryption) make it particularly useful for securing traffic that must traverse untrusted network paths such as the corporate intranet or the Internet. IPSec is also appropriate for securing traffic that uses protocols and applications that do not provide sufficient security for communications. By using policy based on Active Directory, you can secure most communications for a group of servers. You can also use command-line tools to create, modify, and assign IPSec policies. The tools you use vary, depending on the operating system running on the computers. For more information about command-line tools, see the IPSec Policy Extension Tools and Settings section in this collection.

IPSec Policy Advantages

IPSec provides a key line of defense against private network and Internet attacks. IPSec keeps data intact as it is transmitted across the network and protects communications between private network computers, domains, sites, remote sites, extranets, and dial-up clients. By using cryptographic protection services, security protocols, and dynamic key management, IPSec:

Protects the content of IP packets.

Provides a defense against active and passive network attacks by using packet filtering and the enforcement of trusted communication.

IPSec provides protection against the following types of attacks: Sniffers (lack of confidentiality). The Encapsulating Security Payload (ESP) protocol in IPSec encrypts the payload of IP packets to provide data confidentiality. Data modification. IPSec uses cryptography-based keys, shared only by the sending and receiving computers, to create a cryptographic checksum for each IP packet. Any modification to the packet data alters the checksum, indicating to the receiving computer that the packet was altered in transit. Identity spoofing, password-based, and application-layer attacks. IPSec permits the exchange and verification of identities without exposing that information to interpretation by an attacker. To establish trust between the communicating systems, and to ensure that only trusted systems can communicate with each other, IPSec uses mutual authentication. After identities are established, IPSec uses cryptography-based keys to create a cryptographic checksum for each IP packet. The checksum ensures that only the computers that have knowledge of the keys could have sent each packet. Man-in-the-middle attacks. IPSec combines mutual authentication with shared, cryptography-based keys to provide end-to-end data integrity and information hiding. Denial-of-service attacks. IPSec uses IP packet filtering methodology to determine whether communication is allowed, secured, or blocked, according to the IP address ranges, IP protocols, or specific TCP and UDP ports. IPSec Management with Group Policy To provide strong, cryptography-based security to protect data, and to reduce administrative costs, IPSec uses policy-based administration. You can configure IPSec policies to meet the security requirements of a computer, application, organizational unit, domain, site, or global enterprise. You can use the IP Security Policies Management snap-in provided in Windows XP, Windows 2000, and Windows Server 2003 to define IPSec policies for computers through Active Directory (for domain members), or on the local computer (for computers that are not members of a domain).

Related Information
The following resources contain additional information that is relevant to this section:

How Core Group Policy Works in the Group Policy collection. What Is IPSec? in the Networking collection.

How IPSec Policy Extension Works

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How IP Security Policy Extension Works

In this section

IPSec Policy Extension Architecture IPSec Policy Extension Processes and Interactions Related Information

An Active Directory deployment is recommended for central management and distribution of Internet Protocol Security (IPSec) policies. Deployment of IPSec policy in an Active Directory environment requires Windows Server 2003, Windows 2000 Server, and Windows 2000 Professional or Windows XP Professional clients. The IP Security Policies extension of Group Policy Object Editor is used for managing IPSec in Active Directory environments. Policy based on Active Directory is not supported for computers running Windows XP Home Edition.

For computers that are not members of a domain, you can use the IP Security Policy Management snap-in to manage the local computer. To successfully deploy IPSec, the following conditions must also be met:

Each computer that must establish IPSec-secured communications has an assigned IPSec policy. The assigned policy must be compatible with the IPSec policy that is assigned to other computers with which it must communicate. Authentication is configured correctly and an appropriate authentication method is selected in the IPSec policy, so that mutual authentication can occur between IPSec peers. Routers, firewalls, or other filtering devices are configured correctly on all parts of the corporate network to permit IPSec protocol traffic, if IPSec-secured traffic must pass through these devices. IPSec policy compatibility issues must be considered if computers are running different versions of the Windows operating system (Windows Server 2003, Windows XP, and Windows 2000). For client computers that need to establish IPSec-secured connections with servers, servers must be adequately sized to support those connections. If necessary, IPSec hardware offload network adapters can be used.

This section discusses how IPSec Policy Extensions work. It presents information about IPSec architecture and how IPSec policies are stored.

IPSec Policy Extension Architecture

The basic components of IPSec in Windows Server 2003 include the Policy Agent, the Internet Key Exchange (IKE) module, the IPSec driver, and the TCP/IP driver, as shown in the following figure. IPSec Policy Extension Architecture

The following table describes the IPSec policy-related components. IPSec Policy-Related Components and Descriptions

Component IP Security Policy Management Snap-in

Description

This is the administrative tool for configuring IPSec policies in Active Directory or on the local compu Security Policy Management snap-in loads as part of a GPO, it appears in the Computer Configura Settings node of Group Policy Object Editor(displayed as IP Security Policies). IP Security policies se linked to a site, domain, organizational unit (OU), or local computer follow GPO inheritance and filter

Policy Agent

The Policy Agent controls the retrieval and distribution of IPSec policy and maintains the most curren data for the IPSec Driver and IKE module. The Service Control Manager starts the Policy Agent, whic of the local security authority (LSA). The Policy Agent performs the following tasks when it is started Security Authority is initialized):

1. 2. 3. 4. 5. 6.

Starts the IKE module. Retrieves IPSec policies. Determines the filter list order. Delivers IP filters to the IPSec driver. Delivers both Phase 1 and Phase 2 settings to IKE. Polls for policy updates.

For more information about the Policy Agent tasks, see Process Flow, later in this section. Internet Key Exchange (IKE) Module

The IKE module is used to establish a combination of mutually agreeable policy settings and keys th services, protection mechanisms, and cryptographic keys between communicating peers. This comb security association (SA). The IPSec driver in Windows 2000 and Windows Server 2003 uses the IKE corresponding network traffic. To create an SA between the two computers, the IETF has established a standard method of SA and resolution, which combines the Internet Security Association and Key Management Protocol (RFC 24 Determination Protocol (RFC 2412). This standard method is IKE and is described in RFC 2409.

IPSec Driver

The IPSec driver receives the active IP filter list from the IPSec Policy Agent, and then attempts to m and outbound packet against the filters in the list. If a packet matches a filter, the IPSec driver appl packet does not match any filters, the packet is passed back without modification to the TCP/IP driv transmitted. If the filter action permits transmission, the packet is received or sent with no modifications. If the a transmission, the packet is discarded. If the action requires the negotiation of security, main mode a negotiated.

TCP/IP Driver Policy Store Local Registry Local Cache Windows Management Instrumentation (WMI)

The TCP/IP driver is the Windows 2000 implementation of the TCP/IP protocol. It starts the IPSec dr

This maintains both IPSec policy descriptions and interfaces to applications and other tools that prov management. The policy store accesses IPSec policy data stored in either the local registry or Active

The local registry stores the locally configured IPSec policies, the local cache, and other IPSec settin

The local cache stores IPSec policies after they are pulled from an Active Directory domain controller part of the registry.

WMI is a component of the Microsoft Windows operating system and is the Microsoft implementation Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for management information in an enterprise environment. WMI uses the Common Information Model ( to represent systems, applications, networks, devices, and other managed components. You can use administrative tasks in an enterprise environment. Each domain OU has an internal system container in Active Directory. IPSec policies created with IP stored in this location.

IP Security Container

IPSec Policy Extension Processes and Interactions

This section discusses how IPSec Policies are processed, assigned, and stored. The sequence of events is as follows: 1. During computer startup, the TCP/IP driver starts the IPSec driver. The Service Control Manager starts the IPSec Policy Agent. The Policy Agent service performs the following tasks when it is initialized:

2.

In preparation for loading the IPSec policy from either Active Directory or the local registry, the Policy Agent initializes the policy state and polling interval.

The policy agent loads the IPSec policy from the appropriate store. If boot time security is enabled, the IPSec driver mode is changed from the boot mode (block or stateful) to normal operational mode. The policy agent retrieves the appropriate IPSec policy (if one has been assigned) from the Active Directory directory store or from the registry. To determine if IPSec policies exist, the Policy Agent checks the local registry and the Active Directory domain or OU to which the computer belongs. The Policy Agent checks the registry for the value that indicates the location of the computers IPSec policy in Active Directory. If the computer is a member of a domain and an IPSec policy exists, this value was set during computer initialization. The registry key checked is: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\IPSec \GPTIPSECPolicy\DSIPSECPolicyPath. If the computer is not a member of a domain, or if there is no IPSec policy in Active Directory, a value does not exist. If IPSec policies are found in Active Directory, in a Group Policy object, the Policy Agent retrieves the policies and stores them in the local cache. Note that the local Active Directory cache is not used for locally assigned policies. If IPSec policies are defined both locally and in Active Directory, the policies based on Active Directory override the local policies. If there are no IPSec policies in Active Directory or the registry, or if the IPSec Policy Agent cannot connect to Active Directory, the IPSec Policy Agent waits for policy to be assigned or activated.

3.

The IKE module, which runs in the context of the local security authority (LSA) is started. After the policy load process is completed, the Policy Agent begins a service loop. In Windows Server 2003, if an unexpected event occurs, the IPSec driver is put into Block mode and all network traffic is blocked. This is the network security component failing to a secure mode. This applies only to Windows Server 2003; Windows 2000 and Windows XP do not block traffic.

4.

For more information about Windows Server 2003 IPSec, see What Is IPSec? in the Networking Collection. Assignment of IPSec Policy You can assign IPSec policy to a local computer and to computers in Active Directory sites, domains or organizational units. For computers that are not members of a domain, you can assign local IPSec policy. The main method for building an IPSec policy is to use the IP Security Policy Management snap-in to create, modify, and activate IPSec policies, and then assign them to computers in either Active Directory (for domain members) or to the local computer (for computers that are not members of a domain). When you assign an IPSec policy in a GPO, a Lightweight Directory Access Protocol (LDAP) pointer to the IPSec policy is recorded in theIPSecOwnersReference attribute of the GPO. When the GPO is applied to the computer, the IP Security Policies extension of Group Policy Object Editor reads the LDAP pointer from the GPO and writes it to the registry. When the IPSec service starts on the computer, it reads the LDAP pointer and queries Active Directory to obtain the IPSec policy settings. The IPSec service maintains a current local cache of the IPSec Policy by periodically polling for changes. The polling frequency is based on a polling interval that is specified on the IPSec policy. You can also create and assign persistent IPSec policy to secure a computer even if a local IPSec policy or an Active Directory IPSec policy cannot be applied. This policy adds to or overrides the local or Active Directory policy, and remains in effect regardless of whether other policies are applied. Persistent IPSec policies enhance security by providing a secure transition from computer startup to IPSec policy enforcement. Persistent policy also provides backup security in the event of an IPSec policy corruption, or if errors occur during the application of local or domain-based IPSec policy. To configure persistent policies, you must use the netsh ipsec static set store location=persistent command. Administering IPSec Policies with Group Policy Management Console IPSec policies are stored separately from the GPOs that have policies applied; therefore, administrators need to be aware of the following differences. Domain-based IPSec policies are stored in the IP Security Policiescontainer in the System container.

Back-up and Restore of IPSec Policies Group Policy Management Console (GPMC) provides back-up and restore operations for Group Policy objects (GPOs). These operations help administrators maintain their Group Policy deployment in the event of a disaster. It is a recommended practice to regularly back up all GPOs. To provide consistency, when you use these tools, make sure that you include IPSec policies. However; GPMC tools do not store the IPSec policies themselves; therefore, you cannot use GPMC tools to back up and restore the actual IPSec policies. You can only back-up and restore information about whether the IPSec policies are assigned to Group Policy objects and, if so, to which Group Policy objects. The IPSec policy objects in the IP Security Policies container in Active Directory can be backed up and restored by using the Export Policies and Import Policies commands in the IP Security Policiesconsole. The Export Policies command exports all IPSec policy objects from the policy store into one .IPSec file. The Import Policies command imports all IPSec policy objects in the .IPSec file into the destination policy store. Note

Importing IPSec policy into Active Directory overwrites existing IPSec policy objects.

For information about GPMC, see What Is Group Policy Management Console? in this collection. Delegation of Rights to Manage IPSec Policies GPMC delegation of rights and security filtering permissions only apply to the GPO; they do not apply to the IPSec policy that is assigned in the GPO. Thus, delegation of edit rights in GPMC only enables a user to assign or unassign an existing IPSec policy in the specific GPO, and only if the user also has read access rights to the IPSec policy. To delegate rights to create, edit, or delete IPSec policies, administrators must perform the delegation on the IPSec policies container. Applied IPSec Policies You can use the GPMC Group Policy Results wizard to show which GPOs are applied to a computer, including the IPSec policy assignments. Advanced View in the computer node shows which IPSec policy is assigned to a specific computer. On computers running Windows XP, IPSec does not provide Resultant Set of Policy (RSoP) information. GPMC Group Policy Results only shows the GPO being processed, but does not show which IPSec policy is assigned. To view the assigned IPSec policy, you can use netdiag /test:ipsec. For information about netdiag, see IPSec Policy Extension Tools and Settings. IPSec Order of Precedence Although most Group Policy settings are cumulative, you can assign only one IPSec policy to a computer at a time. If multiple IPSec policies have been assigned at different Active Directory levels, the last one applied is the one that takes effect. IPSec policy settings differ from other types of Group Policy settings in that IPSec policy settings from different OUs are not merged. IPSec policy uses the same precedence sequence as other Group Policy settings, from lowest to highest. The following list outlines the default order in which policies are applied. You can override this order by using Group Policy options, including Enforced, Block Policy Inheritance, and the loopback policy processing option (the User Group Policy loopback processing mode policy setting):

Local GPO. Each computer has one local GPO. If a computer is not a member of a domain, this is the only place where you can assign IPSec policy. You can assign an IPSec policy by editing the local GPO, but you can also assign a local policy directly in the IP Security Policy Management snap-in, outside of the Group Policy context, or by using the Netsh IPSec context. When IPSec policy assignments are made outside of the GPO context, the GPO cannot display the local IPSec policy that is assigned. Site. IPSec policies are infrequently assigned at the site level because this would require all computers within a site to have the same security needs, which is unlikely. Furthermore, if the computer moves to another subnet such as when a user travels to another location with a laptop that uses DHCP different policies might be in effect, resulting in different security behaviors. Domain. Simple IPSec policies are often assigned at the domain level and then superseded by more specific IPSec policies, as required on various OUs. OU. Specific IPSec policies are assigned to groups of computers. This is the last policy applied under normal conditions and, therefore, the policy takes precedence. If an OU is nested within another OU, the IPSec policy assigned to the nested OU takes precedence.

Persistence of IPSec Policy An IPSec policy that has been assigned might remain active (persist) even after a GPO to which it is assigned has been deleted. When you assign an IPSec policy in a GPO, a Lightweight Directory Access Protocol (LDAP) pointer to the IPSec policy is recorded in the IPSecOwnersReference attribute of the GPO. The IP Security Policies extension reads the LDAP pointer from the GPO and writes it to the registry when the GPO is applied to the computer. This registry entry can persist if you delete a GPO that contains an assigned IPSec policy. Although the IPSecOwnersReference LDAP pointer is updated when the GPO is deleted, it points to an unreadable object (the location of the deleted objects container), which IPSec services cannot access. As a result, IPSec policy fails and an error is logged. To prevent an IPSec policy from persisting, you must unassign the IPSec policy in the GPO beforeyou delete the GPO. Unassigning the IPSec policy deletes the LDAP pointer from the GPO. Storage of IPSec Policy Settings Domain-based IPSec policy objects are stored in the IP Security Policies container in Active Directory, which is separate from the GPOs to which the IPSec policies are applied. The domain administrator must grant permissions to the IP Security Policies container for other delegated administrators to administer IPSec policies. Standard delegation tools cannot be used to delegate permissions to administer IPSec policies. Instead, domain administrators must use Active Directory Service Interfaces (ADSI) Edit for this purpose. ADSIEdit is a Microsoft Management Console (MMC) snap-in that domain administrators can use to edit objects in the Active Directory database. When domain administrators delegate permissions to others to administer IPSec policies, the delegated administrators must have Full Control permissions to all IPSec policy objects in the IP Security Policies container. After an IPSec administrator creates an IPSec policy, a member of the Group Policy Creator Owners group or other delegated owner of the GPO can assign the IPSec policy to the appropriate GPOs. Note

To modify ACLs on the IP Security Policies container, domain administrators should use the tools that are provided with the Windows 2000 or Windows Server 2003 operating system CD. When domain administrators modify ACLs on the IP Security Policies container, they must specify that all modifications are also propagated to all child objects. Incorrect modification of the ACLs on the IP Security Policies container, failure to propagate modifications to the child objects of this container, or both, can result in the failure of IPSec policy settings to be properly applied.

On standalone computers, IPSec policy is stored in the local registry. ADSIEdit is one of the Windows Server 2003 Support Tools which are included on the Windows Server 2003 operating system CD. You install these tools separately by running the Support Tools Setup program, Suptools.msi, from the \Support\Tools folder. For more information about permissions for the IPSec Policies container, see article 329194, Permissions on the IPSec Policy Store in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Baselink on the Web Resources page. IP Security Container Default Permissions In Windows Server 2003, the default discretionary access control lists (DACLs) for the IP Security container are described in the following tables. The IPSec container owner is the Domain Admin, and group membership is Domain Admin. The following table lists access rights related to the IPSec container and describes their values. IPSec Container Access Rights Values and Descriptions

Access Right Value ADS_RIGHT_DS_READ_PROP

Description

The right to read properties of the object. The ObjectType member of an access con contain a GUID that identifies a property set or property. If ObjectType does not co controls the right to read all of the object properties.

ADS_RIGHT_DS_WRITE_PROP

The right to write properties of the object. The ObjectType member of an ACE can c identifies a property set or property. If ObjectType does not contain a GUID, the AC write all of the object properties.

ADS_RIGHT_DS_CONTROL_ACCESS The right to perform an operation controlled by an extended access right. The Objec ACE can contain a GUID that identifies the extended right. If ObjectType does not c controls the right to perform all extended right operations associated with the object.

ADS_RIGHT_DS_LIST

The right to list a particular object. If the user is not granted such a right, and the us ADS_RIGHT_ACTRL_DS_LIST set on the object parent, the object is hidden from the ignored if the third character of the dSHeuristics property is '0' or not set.

ADS_RIGHT_DS_LIST_OBJECT

The right to list a particular object. If the user is not granted such a right, and the us ADS_RIGHT_ACTRL_DS_LIST set on the object parent, the object is hidden from the ignored if the third character of the dSHeuristics property is '0' or not set.

ADS_RIGHT_DS_CREATE_CHILD

The right to create children of the object. The ObjectType member of an ACE can co identifies the type of child object whose creation is controlled. If ObjectType does n ACE controls the creation of all child object types.

ADS_RIGHT_DS_DELETE_CHILD

The right to delete children of the object. The ObjectType member of an ACE can co identifies a type of child object whose deletion is controlled. If ObjectType does not ACE controls the deletion of all child object types.

ADS_RIGHT_READ_CONTROL ADS_RIGHT_WRITE_DAC ADS_RIGHT_WRITE_OWNER ADS_RIGHT_DELETE ADS_RIGHT_DS_DELETE_TREE ADS_RIGHT_DS_SELF

The right to read data from the security descriptor of the object, not including the da

The right to modify the discretionary access-control list (DACL) in the object security

The right to assume ownership of the object. The user must be an object trustee. The the ownership to other users. The right to delete the object.

The right to delete all children of this object, regardless of the permissions of the chil

The right to perform an operation controlled by a validated write access right. The Ob an ACE can contain a GUID that identifies the validated write. If ObjectType does no ACE controls the rights to perform all valid write operations associated with the objec

The following table lists the access control rights for the IPSec container. DACLs for IPSec Container

DACLs Allow domain computers

Access Rights ADS_RIGHT_DS_READ_PROP ADS_RIGHT_DS_LIST ADS_RIGHT_DS_LIST_OBJECT ADS_RIGHT_READ_CONTROL ADS_RIGHT_DS_READ_PROP ADS_RIGHT_DS_LIST ADS_RIGHT_DS_LIST_OBJECT ADS_RIGHT_READ_CONTROL ADS_RIGHT_DS_READ_PROP ADS_RIGHT_DS_WRITE_PROP ADS_RIGHT_DS_CONTROL_ACCESS ADS_RIGHT_DS_LIST ADS_RIGHT_DS_LIST_OBJECT ADS_RIGHT_DS_CREATE_CHILD ADS_RIGHT_DS_DELETE_CHILD ADS_RIGHT_READ_CONTROL ADS_RIGHT_WRITE_DAC ADS_RIGHT_WRITE_OWNER ADS_RIGHT_DS_SELF ADS_RIGHT_DS_READ_PROP ADS_RIGHT_DS_WRITE_PROP ADS_RIGHT_DS_CONTROL_ACCESS ADS_RIGHT_DS_LIST ADS_RIGHT_DS_LIST_OBJECT ADS_RIGHT_DS_CREATE_CHILD ADS_RIGHT_DS_DELETE_CHILD ADS_RIGHT_READ_CONTROL ADS_RIGHT_WRITE_DAC ADS_RIGHT_WRITE_OWNER ADS_RIGHT_DELETE ADS_RIGHT_DS_DELETE_TREE ADS_RIGHT_DS_SELF

Allow Group Policy Creator Owner

Allow Domain Admin

Allow Local SYSTEM

The following changes are implemented in Windows Server 2003, and they apply to both new and upgrade installations of Windows Server 2003:

An inheritable DACL is included with the IP Security container. An empty DACL is included with the built-in IPSec policies. Because the DACL is empty, objects can inherit permissions from the IP Security container and other parent containers in Active Directory. The default DACL for all IPSec objects is changed so that all new objects that you create have an empty DACL and can inherit permissions. As a result, IPSec policies that are created from Windows 2000, Windows XP or Windows Server 2003 management clients have the new permissions.

To view these ACLs, you can use the ADSIEdit.exe tool (described earlier in Storage of IPSec Policy Settings) or Ldp.exe. The Ldp.exe tool provides an interface to perform Lightweight Directory Access Protocol (LDAP) operations against Active Directory. Ldp.exe and ADSIEdit.exe are two of the Windows Server 2003 Support Tools, which are included in the Windows Server 2003 operating system CD. You can install these tools by running the Support Tools Setup program, Suptools.msi, from the Support\Tools folder. For more information about delegating IPSec permissions, see Delegating Permissions to Modify Active Directory Based IPSec Policy in the Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server article available at the Microsoft Download Center. For more information about control access rights, search for Control Access Rights in the Directory Services SDK Documentation in the Microsoft Platform SDK on MSDN. IPSec Policy Polling Interval The general IPSec policy settings include a polling interval, Policy change poll interval, which specifies the number of minutes between consecutive polls for changes in IPSec policies based on Active Directory. The default value for the Policy change poll interval is 180 minutes. This polling does not detect a change in domain or organizational unit membership, or the assigning or unassigning of a new policy; these events are detected when the Winlogon service polls for changes in Group Policy, which occurs every 90 minutes by default. To generate an immediate update of changes in IPSec policy settings, instead of waiting for the next polling period, you can use the Gpupdate command, by typing the following at the command prompt: gpupdate /target:computer.

Related Information
The following resources contain additional information that is relevant to this section.

How Core Group Policy Works in the Group Policy Collection. What Is IPSec? in the Networking Collection. Deploying IPSec in the Deploying Network Services guide of the Microsoft Windows Server 2003 Deployment Kit. Control Access Rights in the Directory Services SDK Documentation in the Microsoft Platform SDK on MSDN.

IPSec Policy Extension Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

IP Security Policy Extension Tools and Settings

In this subject

Resultant Set of Policies Tools for Viewing IPSec Policy Assignment on Computers Running Windows Server 2003 Tools for Viewing IPSec Policy Assignment on Computers Running Windows 2000

Tools for Viewing IPSec Policy Assignment on Computers Running Windows XP Tools for Managing and Monitoring IPSec Policy Network Ports Used by IPSec Related Information

This section is an overview of IPSec tools, Resultant Set of Policies (RSoP) in particular, which are used to determine which IPSec policy settings are currently in effect for a computer or a user. RSoP is also used to assess how policy settings would affect computers or users if a specific Group Policy object were applied to them. This section also describes the Windows Server 2003 command-line tools for configuring and analyzing IPSec policy settings.

Resultant Set of Policies

Windows XP and the Windows Server 2003 family support an enhanced Group Policy infrastructure that utilizes Windows Management Instrumentation (WMI) to collect Group Policy-related data for planning and troubleshooting Group Policy. This structure is the Resultant Set of Policy (RSoP), a query engine that polls existing policy settings and planned policy settings, and then reports the results of those queries. RSoP polls existing policies based on site, domain, domain controller, and organizational unit. RSoP gathers this information from the Common Information Management Object Model (CIMOM) database (also known as CIM-compliant object repository) by using WMI. Administrators can use RSoP in one of two modes. To determine which policy settings are in effect for a particular computer or user, administrators use Resultant Set of Policy (RSoP) Logging Mode; to evaluate how policy settings would affect a computer or user if a specific Group Policy object were applied to users or computers, they use Resultant Set of Policy (RSoP) Planning Mode. In Windows Server 2003, you can use the Group Policy Modeling node in the Group Policy Management Console (GPMC) to access the RSoP Planning Mode capabilities of Windows Server 2003. By using this feature, administrators can simulate policy settings applied to users and computers with Group Policy before actually applying the policy settings. You can also use the Group Policy Results node of GPMC to access the RSoP Logging Mode capabilities. Group Policy Results represents the actual resultant set of policy that was applied to a given user and computer. This information is obtained by directly querying the target user or computer. Each subnode represents a different RSoP query for a given user/computer combination. RSOP_IPSECPolicySetting The RSOP_IPSECPolicySetting WMI class represents the policy data for the IPSec extension. The RSOP_IPSECPolicySetting class is derived fromRSOP_PolicySetting, and is included in Windows Server 2003. This class was available starting with Windows Server 2003 family and might not be available in future versions of Windows. For more detailed information about RSoP and WMI and to download SDKs, see the Microsoft Platform SDK page. For more information about GPMC, see the Group Policy Management Console page.

Tools for Viewing IPSec Policy Assignment on Computers Running Windows Server 2003
IPSec provides support for RSoP to enhance deployment and troubleshooting of IPSec Policy in Windows Server 2003. You can run an RSoP Logging-Mode query or an RSoP Planning-Mode query to view detailed settings (the filter rules, filter actions, authentication methods, tunnel endpoints, and connection types) for the IPSec policy that is currently being applied, or would be applied if you deployed that IPSec policy. The RSoP console displays the following information for each Group Policy object (GPO) that contains an IPSec policy assignment: the name of the IPSec policy, the name of the GPO to which the IPSec policy is assigned, the IPSec policy precedence, and the name of the site, domain, and organizational unit to which the GPO containing the IPSec policy applies (that is, the scope of management for the GPO). The lower the number in the Precedence column, the higher the precedence of the IPSec policy. A precedence of 1 indicates the IPSec policy that is being applied. To provide support for RSoP in Windows Server 2003, the RSOP_IPSECPolicySetting WMI class was created. For more information, seeRSOP_IPSECPolicySetting earlier in this document. RSoP and the Group Policy Management Console If you have installed Group Policy Management Console (GPMC), you can find out which policies are currently applied to a specific computer, including the IPSec policy assignments, by using the Group Policy Results node in GPMC. This runs the GPMC Group Policy Results wizard, which replaces the Resultant Set of Policy (RSoP)

Logging Mode capabilities. Running the wizard shows which IPSec policy is assigned to a specific computer by right-clicking on the computer node, and then selecting Advanced View. GPMC is available as a download from the Microsoft Web site. For more information about GPMC, see the Group Policy Management Console page. Netsh Commands for IPSec Netsh is a command-line scripting utility that you can run on a local or remote computer to display or modify the network configuration of a computer that is currently running. Netsh also provides a scripting feature so you can run a group of commands in batch mode against a specified computer, and it can also save a configuration script in a text file for archival purposes or to help you configure other servers. Netsh interacts with other operating system components using dynamic-link library (DLL) files. Netsh helper DLLs provide an extensive set of features called a context, which is a group of commands specific to a networking component. These contexts extend the functionality of netsh by providing configuration and monitoring support for one or more services, utilities, or protocols. For example, Nshipsec.dll provides netsh the context and set of commands necessary to configure and manage IPSec policies and state. To run a netsh command, you must start netsh from the Cmd.exe prompt and change to the context that contains the command you want to use. The contexts that are available to you depend on which networking components you have installed. For computers running members of the Windows Server 2003 family, you can use the netsh commands for Internet Protocol security (netsh ipseccontext) as an alternative to the console-based management and diagnostic capabilities provided by the IP Security Policy Management and the IP Security Monitor snap-ins. By using the netsh commands for IPSec, you can script IPSec configuration, and change the IPSec configuration for troubleshooting. You can also use this command to extend the security and manageability of IPSec. For example, you can use the netsh commands for IPSec to enable IPSec driver event logging, set default traffic exemptions, and configure computer startup security. Note

For computers running Windows 2000, use Ipsecpol.exe, which is provided with the Windows 2000 Server Resource Kit. For more information about Ipsecpol.exe, see Ipsecpol.exe: Internet Protocol Security Policies Tool on the download site for Windows 2000 Server Resource Kit tools.

The Netsh ipsec command supports both static and dynamic mode: Netsh ipsec static mode commands. You can use the netshipsec static commands to perform the same management tasks that you can perform by using the IP Security Policy Management console. By using these commands, you can create, modify, and assign IPSec policies without immediately affecting the configuration of the active IPSec policy. Netsh ipsec dynamic mode commands. You can use the netsh ipsec dynamic commands to display the active state of IPSec and to immediately affect the configuration of the active IPsec policy. These commands directly configure the security policy database (SPD). Changes that you make to an IPSec policy while using these commands take effect only while the IPSec service is running. If the IPSec service is stopped, the dynamic policy settings are discarded. You can use the netsh ipsec dynamic mode commands to perform the monitoring tasks of the IPSec Monitor snap-in. The netsh ipsec dynamic command allows the active state of IPSec to be displayed, and it also allows modification of the state (unlike the IPSec Monitor tool, which does not allow modification of the state). You can run these commands from the Windows Server 2003 command prompt or from the command prompt for the netsh ipsec context. For these commands to work at the Windows Server 2003 command prompt, you must type netsh ipsec before typing ipsec commands (such as add filter or add rule) and parameters. To find more information about netsh ipsec, see Command Line References in Tools and Settings. Gpupdate This command-line tool refreshes local Group Policy settings and Group Policy settings that are stored in Active Directory, including security settings. This command supersedes the now obsolete /refreshpolicy option for the secedit command. Syntax

gpupdate [/target:{computer | user}] [/force] [/wait:Value] [/logoff] [/boot]

Parameters The following table lists the Gpupdate parameters. Gpupdate parameters

Parameter

Description

/target:{computer| user} Processes only the Computer settings or the current User settings. By default, both the compute settings are processed. /force /wait: Value /logoff Ignores all processing optimizations and reapplies all settings.

Number of seconds that policy processing waits to finish. The default is 600 seconds. 0 equals n wait indefinitely.

Logs off after the refresh has completed. This is required for those Group Policy client-side exten process on a background refresh cycle but that do process when the user logs on, such as user G Installation and Folder Redirection. This option has no effect if there are no extensions called tha log off.

/boot

Restarts the computer after the refresh has completed. This is required for those Group Policy cl that do not process on a background refresh cycle but that do process when the computer starts Group Policy Software Installation. This option has no effect if there are no extensions called tha to be restarted. Displays help at the command prompt.

/?

Examples The following examples show how you can use the gpupdate command: gpupdate gpupdate /target:computer gpupdate /force /wait:100 gpupdate /boot

Tools for Viewing IPSec Policy Assignment on Computers Running Windows 2000
On computers running Windows 2000, you can use the Group Policy Results tool, Gpresult.exe, to display information about how Group Policy affects both the currently logged-on user and the computer. Gpresult displays Group Policy information regarding:

The last time that Group Policy was applied and the domain controller that applied the Group Policy setting for the user and the computer. A list of all applied GPOs and their details, including a summary of the extensions that each GPO contains. Registry settings that are applied and the details. Folders that are redirected and their details. Disk quota information. Internet Protocol (IP) Security settings. Scripts.

Gpresult.exe Syntax Gpresult.exe uses the following syntax:

gpresult [/v] [/s] [/c] [/u]

The following table lists the Gpresult parameters. Gpresult.exe parameters

Parameter Explanation /v

Use this parameter to run Gpresult.exe in verbose mode. When you use this parameter, the following information additional to the information that is typically displayed):

A list of the users security rights. GPO details including globally unique identifier (GUID), friendly name, version, and source. Details for the following Group Policy extensions:

1. 2. 3. 4. 5.
6. /s

Administrative Templates (registry-based policy settings) Application management Disk quotas Folder redirection IP Security Scripts

Use this parameter to run Gpresult.exe in super-verbose mode. When you use this parameter, the following infor addition to the information that is typically displayed):

/c /u

Binary values of binary registry settings (when applicable) A detailed list of the programs that are displayed in the Add or Remove Programs tool in Control Panel The Group Policy container and Group Policy template version numbers of the GPO

Use this parameter to display information about computer settings only. Use this parameter to display information about user settings only.

The Gpresults command-line tool is available in the Windows 2000 Resource Kit. To download this tool, see Windows 2000 Server Resource Kit tools Web site. Gpotool.exe You can use Gpotool.exe on a domain controller to check Group Policy object integrity and monitor policy replication. GpoTool performs the following tasks:

Checks Group Policy object consistency. The tool reads mandatory and optional directory services properties such as version, friendly name, extension globally unique identifiers (GUIDs), and SYSVOL data (Gpt.ini). GpoTool also compares directory services and SYSVOL version numbers and performs other consistency checks. If the extensions property contains any GUID, the functionality version must be 2 and the user/computer version must be greater than 0. Checks Group Policy object replication. The tool compares the Group Policy object instances from each domain controller. Displays information about a particular Group Policy object, including properties that cannot be accessed by means of the Group Policy snap-in, such as functionality version and extension GUIDs.

Browses Group Policy objects. A command-line option can search based on either friendly name or GUID. A partial match is also supported for both name and GUID. Designates preferred domain controllers. By default, all available domain controllers in the domain are used, but this can be overwritten with a list of domain controllers supplied from the command line. Provides cross-domain support. You can use the command-line option to check Group Policy objects in different domains. Runs in verbose mode. If all the Group Policy objects are acceptable, the tool displays a validation message. If errors occur, the tool displays information about the corrupted Group Policy objects. A command-line option can turn on verbose information about each Group Policy object that is being processed.

GpoTool Syntax

gpotool [/gpo:GPO[,GPO]] [/domain:DNSname] [/dc:DC[,DC]] [/checkacl] [/verbose] [/new:GPO[,GPO...]] [/del:GPO[,GPO...]] [/?] [/help]
Where: /gpo: GPO[,GPO] processes preferred Group Policy objects GPO[,GPO]. Partial GUID and friendly name matches are accepted for GPO. If GPO is not specified, the tool processes all Group Policy objects in the domain. /domain: DNSname specifies the DNS name for the domain hosting the Group Policy objects. If a name is not specified, the users domain is used. /dc: DC[,DC] finds the preferred list of domain controllers DC[,DC]. If not specified, finds all controllers in the domain. /checkacl verifies the SYSVOL ACL. For faster processing, this step is skipped by default. /verbose displays detailed information. /new: GPO[,GPO...] create new Group Policy objects with the specified friendly names GPO[,GPO...]. /del: GPO[,GPO...] deletes Group Policy objects with the specified friendly names GPO[,GPO...]. /? or /help displays GpoTool syntax.

Tools for Viewing IPSec Policy Assignment on Computers Running Windows XP

On computers running Windows XP, IPSec does not provide RSoP information. GPMC Group Policy Results shows the GPO being processed, but it does not show which IPSec policy is assigned. To view the assigned IPSec policy, you must use the netdiag /test:ipsec command. Netdiag.exe is a command-line tool that you can use to display information about IPSec policies and statistics, reports network configuration, and tests basic networking capabilities and domain-based functionality. Specifically, Netdiag.exe displays information about IPSec policy assignments, including the name of the active IPSec policy, the name of the Group Policy object that assigned the policy, and the policy path. For Windows XP, Netdiag.exe is available for installation from the Windows XP CD. You install it by running the Setup.exe file from the \Support\Toolsfolder, and choosing the Complete setup option. Netdiag.exe On computers running Windows XP, you can use Netdiag.exe to view information about IPSec policies and statistics, report network configuration, and test basic networking capabilities and domain-based functionality. Syntax Netdiag uses the following syntax:

netdiag [/q] [/v] [/l] [/debug] [/d:domain_name] [/fix] [/dcaccountenum] [/test:test_name] [/skip:test_name]
Parameters You can use the following parameters with Netdiag:

Parameter /q /v /l /debug

Explanation Use this parameter to specify quiet output and display errors only.

Use this parameter to run Netdiag in verbose mode and display information about the actions that are pe

Use this parameter to write output to the Netdiag.log file. The Netdiag.log file is created in the same folde Netdiag.

Use this parameter to run Netdiag in debug mode. This parameter specifies a more verbose output than w the/v parameter.

/d:domain_name Use this parameter to locate a domain controller in the specified domain. /fix Use this parameter to correct minor issues.

/dcaccountenum Use this parameter to enumerate domain controller computer accounts. /test: test_name

Use this parameter to specify the test or tests that you want to run, where test_name can be any of the f

Autonet: Automatic Private IP Addressing (APIPA) address test Bindings: Bindings test Browser: Redir and Browser test DcList: Domain controller list test DefGw: Default gateway test DNS: Domain Name Service (DNS) test DsGetDc: Domain controller discovery test IpConfig: Internet Protocol (IP) address configuration test IpLoopBk : IP address loopback ping test IPSec: IP Security Protocol (IPSec) security test IPX: Internetwork Packet Exchange (IPX) test Kerberos: Kerberos Test Ldap: Lightweight Directory Access Protocol (LDAP) test Member: Domain membership test Modem: Modem diagnostics test NbtNm: NetBIOS over TCP/IP (NetBT) name test Ndis: Netcard queries test NetBTTransports: NetBT transports test Netstat: Netstat information test NetWare: NetWare test Route: Routing table test

Trust: Trust relationship test WAN: Wide Area Network (WAN) configuration test WINS: Windows Internet Name Service (WINS) service test Winsock: Winsock test

Example To use Netdiag to display the currently active Internet Protocol security (IPSec) policy, type the following line: netdiag /test:ipsec /debug For more information about Netdiag, see the Microsoft Knowledge Base page, and search for Knowledge Base article number 321708 How to: Use the Network Diagnostics Tool (Netdiag.exe) in Windows 2000.

Tools for Managing and Monitoring IPSec

This section describes tools for administering and monitoring IPSec policies:

IP Security Policy Managementsnap-in. You can apply IPSec policies to domains, sites, organizational units, or any Group Policy object in Active Directory, as well as to the local computer. To create, modify, and assign IPSec policies, you can use the IP Security Policy Management snap-in. IP Security Monitorsnap-in. You can use this tool to view details about IPSec policy settings as they are applied to a computer.

IP Security Policy Management Microsoft Windows XP and the Windows Server 2003 family provide the IP Security Policy Management snap-in, which you can use to define IPSec policies for computers through Active Directory (for domain members) or on the local computer (for computers that do not belong to domains). By using IP Security Policy Management, you can create IPSec policies to meet the security requirements of a computer, application, organizational unit, domain, site, or global corporation. IP Security Monitor On computers running Windows XP and the Windows Server 2003 family of operating systems, you can use the IP Security Monitor snap-in to view IPSec policy settings as they are applied to the computer. This tool monitors IPSec SAs, rekeys, negotiation errors, and other IPSec statistics. Note

On computers running Windows 2000, you use the Ipsecmon.exe program to view IPSec policy settings.

You use IP Security Monitor to perform the following tasks:

Monitor IPSec information for local computer and remote computers. View details about active IPSec policies, including the name, description, date last modified, store, path, organizational unit, and Group Policy object name. View the following IPSec details in main mode and quick mode:

Generic filters and specific filters Statistics Security associations

Customize refresh rates, and use DNS name resolution for filter and security association output.

Search for specific main mode or quick mode filters that match any source or destination IP address, a source or destination IP address on your local computer, or a specific source or destination IP address.

Network Ports Used by IPSec

IPSec uses the following ports:

IPSec protocol IPSec ESP IPSec AH ISAKMP IPSec NAT-T

Uses Protocol 50. Protocol 51. UDP port 500.

Source port of Any or UDP port 4500 (a source port of Any might be used because the network address transl source port UDP 4500 to a different source port). Destination port of UDP 4500.

Related Information
The following resources contain additional information that is relevant to this section.

What Is IPSec? in the Networking collection. For more information about RSoP and WMI and to download SDKs, see the Microsoft Platform SDK page. For more information about GPMC, see the Group Policy Management Console page. The Tools and Settings Collection.

Software Restriction Policies Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 Microsoft Windows XP and the Windows Server 2003 family include software restriction policies, a new Group Policy-based feature that identifies software programs running on computers in a domain, and controls the ability of those programs to run. Software restriction policies are part of the Microsoft security and management strategy to assist enterprises in increasing the reliability, integrity, and manageability of their computers. In this subject

What Are Software Restriction Policies? How Software Restriction Policies Work Software Restriction Policies Tools and Settings

What Are Software Restriction Policies?

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What Are Software Restriction Policies?

In this section

Protecting Computer System Integrity Dependencies on Other Operating System Components

Related Information

Software restriction policies provide administrators with a Group Policy-driven mechanism to identify software and control its ability to run on the local computer. These policies can be used to protect computers running Microsoft Windows XP Professional against known conflicts and safeguard the computers against security threats such as malicious viruses and Trojan horse programs. You can also use software restriction policies to create a highly restricted configuration for computers, in which you allow only specifically identified applications to run. Software restriction policies are integrated with Microsoft Active Directory and Group Policy. You can also create software restriction policies on stand-alone computers. Software restriction policies are trust policies, which are regulations set by an administrator to restrict scripts and other code that is not fully trusted from running.

Protecting Computer System Integrity

Business users collaborate by using e-mail, instant messaging, and peer-to-peer applications. As these collaborations increase, especially with the use of the Internet in business computing, so do the threats from malicious code, such as worms, viruses, and malicious user or attacker threats. Users might receive hostile code in many forms, ranging from native Windows executable files (.exe files), to macros in documents (such as .doc files), to scripts (such as .vbs files). Malicious users or attackers often use social engineering methods to get users to run code containing viruses and worms. (Social engineering is a term for tricking people into revealing their password or some form of security information.) If such code is activated, it can generate denial-of-service attacks on the network, send sensitive or private data to the Internet, put the security of the computer at risk, or damage the contents of the hard disk drive. IT organizations and users must be able to determine which software is safe to run and which is not. With the large numbers and forms that hostile code can take, this becomes a difficult task. To help protect their network computers from both hostile code and unknown or unsupported software, organizations can implement software restriction policies as part of their overall security strategy. Group Policy-Based Software Restrictions Administrators can use software restriction policies to define which applications are allowed or not allowed to run on a target computer. The configuration is deployed in Group Policy objects. To help organizations address the problem of unknown code, administrators can use software restriction policies to perform the following tasks:

Fight computer viruses Regulate which ActiveX controls can run Run only digitally signed scripts Enforce that only approved software is run on system computers Create a highly restricted configuration for a computer (for example, stipulate that only specific programs are allowed to run)

Scenarios for Using Software Restriction Policies Administrators can use software restriction policies for the following tasks:

Define what is trusted code Design a flexible Group Policy for regulating scripts, executable files, and ActiveX controls

Software restriction policies are enforced by the operating system and by applications (such as scripting applications) that comply with software restriction policies. Specifically, administrators can use software restriction policies for the following purposes:

Specify which software (executable files) can run on clients Prevent users from running specific programs on shared computers

Specify who can add trusted publishers to clients Set the scope of the software restriction policies (specify whether policies affect all users or a subset of users on clients) Prevent executable files from running on the local computer, organizational unit (OU), site, or domain. This would be appropriate in cases when you are not using software restriction policies to address potential issues with malicious users.

Advantages of Software Restriction Policies Using software restriction policies provides the following advantages: Administrators can enforce software restriction policies in domains or on the local computer. The software restriction policies can be implemented in a large enterprise with various types of computers and applications, and can also be applied in a stand-alone environment for computers that are not members of a domain. Software restriction policies leverage Active Directory and Group Policy for manageability. The software restriction policies are stored in a GPO. Administrators create the software restriction policy, and then define which applications are trusted and which are not. The software restriction policy is enforced at run time and users do not receive prompts allowing them to choose whether to run executable files. Software restriction policies apply to multiple types of files. Software restriction policies provide control over Microsoft Visual Basic Scripting Edition (VBScript), JScript, and other scripting languages. Software restriction policies also integrate with the Windows Installer feature to provide control over the types of software packages (.msi files) that can be installed on clients. This feature includes an application programming interface (API), which you can use to coordinate the software restriction policy run time with other run times. Software restriction policies provide flexibility. Administrators can prohibit unauthorized scripts from running, regulate Microsoft ActiveX controls, or lockdown client computers. Software restriction policies use strong cryptography to identify software. Software restriction policies can identify software by using a hash or a certificate.

Dependencies on Other Operating System Components

Software restriction policies rely on the following operating system components: Active Directory. The Windows-based directory service, Active Directory, stores information about objects on a network and makes this information available to administrators and users. By using Active Directory, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single logon. Group Policy. The infrastructure within Active Directory, Group Policy, enables directory-based configuration management of user and computer settings on computers running Windows Server 2003, the Windows 2000 family, and the Microsoft Windows XP Professional operating systems. By using Group Policy, you can define configurations for groups of users and computers, including policy settings for Windows Server 2003 registry-based policies, software installation, scripts, folder redirection, Remote Installation Services, Microsoft Internet Explorer maintenance, and security. Windows Installer. Windows Installer is an installation and configuration service that reduces the total cost of ownership. Windows installer is included in Microsoft Windows Server 2003 family, Windows 2000, Windows XP, and Windows Millennium Edition (Windows Me). It is also provided as a service pack to Microsoft Windows NT version 4.0, Windows 98, and Windows 95. Windows Installer version 2.0 is integrated with Software Restriction Policies in Microsoft Windows XP and Windows Server 2003. The Windows Installer version 2.0 only installs packages allowed to run at the unrestricted level. Patches or transforms must also be allowed to run at the unrestricted level. If a package, patch, or transform is not configured to run fully trusted (unrestricted), the Windows Installer displays an error message and logs an entry in the application event log. Software restriction policy is evaluated the first time an application is installed, when a new patch is applied, and when the installation package is re-cached. Msiexec.exe is the executable program that interprets packages and installs products. Authenticode and WinVerifyTrust.

These components are used to process signed executable files. Microsoft Authenticode, which is based on industry standards, allows developers to include information about themselves and their code with their programs through the use of digital signatures. The WinVerifyTrust function performs a trust verification action on a specified object. The following figure illustrates the interactions of software restriction policies, Active Directory, and Group Policy. Software Restriction Policies and Related Components

Related Information
The following resource contains additional information that is relevant to this section.

What Is Core Group Policy? in the Group Policy Collection.

How Software Restriction Policies Work

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Software Restriction Policies Work

In this section

Software Restriction Policies Architecture Software Restriction Policies Overview

Software Restriction Policies Processes and Interactions Related Information

Software restriction policies provide administrators with a policy-driven mechanism for identifying the software programs running on computers in a domain and for controlling the ability of those programs to run. Deployment based on Active Directory requires Windows Server 2003, and Windows XP Professional clients, specifically:

Windows Server 2003 with Active Directory installed and dynamic DNS properly configured. Windows XP client computers. The Group Policy Object Editor and the Software Restriction Policies extension of Group Policy Object Editor.

For Windows XP computers that are not participating in a domain, you can use the Local Security Settings snapin to access Software Restriction Policies.

Software Restriction Policies Architecture

Software restriction policies provide a mechanism for the operating system and applications compliant with software restriction policies to restrict the runtime execution of software programs. At a high level, software restriction policies consist of the following components:

Software restriction policies (sometimes referred to as Safer) Application Programming Interfaces (APIs), which are used to create and configure the rules that constitute the software restriction policy. There also are software restriction policies APIs for querying, processing, and enforcing software restriction policies. A software restriction policies management tool. This consists of the Software Restriction Policies extension of the Group Policy Object Editorsnap-in, which administrators use to create and edit the software restriction policies. A set of operating system APIs and applications that call the software restriction policies APIs to provide enforcement of the software restriction policies at runtime. Active Directory and Group Policy. Software restriction policies depend on the Group Policy infrastructure to propagate the software restriction policies from the Active Directory to the appropriate clients, and for scoping and filtering the application of these policies to the appropriate target computers. Authenticode and WinVerify Trust APIs which are used to process signed executable files. Event Viewer. Software restriction policies functions log events to the Event Viewer logs. Resultant Set of Policies (RSoP), which can aid in the diagnosing of the effective policy that will be applied to a client.

The following figure shows an example of the Group Policy Object Editor targeted on one of three different Group Policy objects (GPOs) that apply to a workstation. The Group Policy Object Editor is viewing a GPO containing software restriction policies, A1GPO, which is associated with the University domain. When the computer starts or the user logs on, the policies from A1GPO, A2GPO, and A3GPO are downloaded and applied. Software Restriction Policies, Group Policy and Active Directory

After Group Policy downloads the software restriction policy, the policy is stored in the registry. This policy is processed during the calls to the software restriction policies (Safer) enforcement APIs. For example, when users double-click an executable file (.exe) in Windows Explorer, the enforcement API,SaferIdentifyLevel, is called to determine the rule details that are associated with that executable file. In this example, if the software restriction policy does not indicate that the program is fully trusted, the executable file does not run. ShellExecute calls SaferIdentifyLevel when a non-natively executable file is double-clicked (this is covered only by Designated File Types). For natively-executable files (a portable executable file or PE),CreateProcess calls SaferIdentifyLevel. See Default Designated File Types, later in this section for more information. Software restriction policies consist of the following components. Software Restriction Policies Components

Component

Description

Software Restriction This component is an API for creating and manipulating software restriction policies. The functions in thi Policies (Safer) API and set the rules that constitute a software restriction policy. Safer APIs provide applications that launch

external sources the ability to query security policy for approval before an executable file is launched. Management tools

These components include the Group Policy Object Editor snap-in, the Software Restriction Policie command line tools. The management tools use the Software Restriction Policies (Safer) APIs to allow th administrator to author and edit software restriction policies.

Safer Enforcement APIs

In Windows Server 2003, these components include functions (SaferIdentifyLevel and SaferCompute that the operating system and applications compliant with software restriction policies use to enforce the policy. These functions can process the set of software restriction policies rules contained in the policy an appropriate rule for a given program.

Operating system APIs and applications

A set of operating system APIs and applications, compliant with software restriction policies, which call in enforcement functions to provide enforcement of the policy at runtime. These include Microsoft Office Ma Component Object Model (COM), and these APIs:

1. 2.

ShellExecute. Performs an operation on a specified file.

CreateProcess. Creates a new process and its primary thread. The new process runs t file in the security context of the calling process. Microsoft Windows Script Host

Windows Script Host is not a component of Software Restriction Policies; however, it interacts with Softw Policies. Windows Script Host calls into Software Restriction Policies to apply software restriction policies being run. Note that other script engines do not do this. If you want to perform script checking, you can that call software restriction policies. Windows Script Host is a language-independent scripting host for Windows Script compatible scripting en simple, powerful, and flexible scripting to the Windows 32-bit platform, enabling you to run scripts from desktop and the command prompt.

Windows Installer

Windows Installer (Msiexec) is not a component of Software Restriction Policies, but it also interacts with Policies. Windows Installer calls into Software Restriction Policies to apply software restriction policies to installed. Windows Installer implements the Software Restriction Policies API.

Group Policy

Group Policy is a feature included in Windows XP, Windows 2000, and Windows Server 2003. Software r the Group Policys Registry.pol files. The Administrative Templates extension of Group Policy saves information in Registry.pol files. These file customized registry settings that you specify (by using Group Policy) to be applied to the computer or us registry. One Registry.pol file contains registry settings that are specific to the HKEY_LOCAL_MACHIN the Group Policy Template folder, in the \Machine subfolder. The other Registry.pol file contains registry specific to the HKEY_CURRENT_USER key; it is stored in the Group Policy Template folder, in the \Use Software restriction policies do not use a client side extension. Software restriction policies depend on G propagate the policy from the Active Directory to the appropriate clients and use the appropriate filtering

Event Viewer Authenticode and WinVerifyTrust

Software restriction policies functions log events in the Event log. The SaferRecordEventLogEntry fun to an event log.

These components are used to process signed executable files. Microsoft Authenticode, which is based o enables developers to include information about themselves and their code with their programs through signatures. The WinVerifyTrust function performs two actions: signature checking on a specified object action.

Windows Management Instrumentation (WMI) Resultant Set of Policy (RSoP) Registry

The Software Restriction Policies extension queries the registry policy by using WMI. WMI is a componen Microsoft Windows operating system and is the Microsoft implementation of Web-Based Enterprise Mana is an industry initiative to develop a standard technology for accessing management information in an en WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, n other managed components. You can use WMI to automate administrative tasks in an enterprise environ

RSoP is a Group Policy feature that aids in diagnosing effective policy settings that will be applied to a cl restriction policies provide support for RSoP. Software restriction policies are stored in the registry. InHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer or inHKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows.

For information about the Software Restriction Policies (Safer) functions, see the topic Safer in the Security section of the Microsoft Platform SDK onMSDN.

Software Restriction Policies Overview

A software restriction policy consists of a default rule that defines which programs can run, and a set of exceptions to the default rule.

You can set the default rule, which specifies whether software can run, to either Unrestricted (program can run) or Disallowed (program cannot run). If you set the default rule to Unrestricted, you can also define exceptions to specify a set of programs that are not allowed to run. The Unrestricteddefault setting is appropriate in an environment with lightly managed clients. For example, you can prevent users from installing a program that conflicts with existing programs by creating a rule to block that program. For environments that require a more secure method of software control, you should set the default rule to Disallowed and then allow only a specific set of programs to run. If you use the Disallowed default setting, you have to identify all the software that users are permitted to run and create appropriate rules for them. The Disallowed default setting is the preferred default for securing Windows XP clients. Rules in Software Restriction Policies Software restriction policies use rules to identify one or more software applications, and to specify whether the software is permitted to run. By creating rules, administrators can identify software that is an exception to the default rule. Each rule can include descriptive text to indicate why the rule was created. To identify software, software restriction policies support the following rules:

Hash. A cryptographic fingerprint of the file Certificate. A software publisher certificate used to digitally sign a file Path. The local or universal naming convention (UNC) path of where the file is stored Zone. Internet Zone

Hash Rule A hash is a cryptographic fingerprint that uniquely identifies a file regardless of its name or where it is accessed. With a hash rule, software can be renamed or moved into another location on a disk, but it will still match the hash rule because the rule is based on a cryptographic calculation involving file contents. Hash rules work effectively in a static environment. If the software in your clients is upgraded frequently, hash rules can become difficult to manage. Whenever a program executable is updated, the hash rule needs to be updated to support the new executable version. For secure environments using a default level of Disallowed, hash rules are a very secure way to identify applications that you want to allow to run asUnrestricted. For environments using a default level of Unrestricted, hash rules allow you to specifically identify one particular version of an application to disallow. A hash rule consists of three pieces of data, separated by colons:

MD5 or SHA-1 hash value File length Hash algorithm ID

A hash rule uses the following format:

[MD5 or SHA1 hash value]:[file length]:[hash algorithm id]

Files that are digitally signed use the hash value contained in the signature, either SHA-1 or MD5. Files that are not digitally signed use an MD5 hash. For example, the following hash rule matches a file with a length of 126 bytes and with contents that match the MD5 (denoted by the hash algorithm identifier of 32771) hash of 7bc04acc0d6480af862d22d724c3b049:

7bc04acc0d6480af862d22d724c3b049:126:32771
Certificate Rule A certificate rule specifies a code-signed software publishers certificate. For example, a company can require that all scripts and ActiveX controls be signed with a particular set of publisher certificates. Certificates used in a certificate rule can be issued from a commercial certificate authority (CA) such as VeriSign, a Windows 2000 or Windows Server 2003 Public Key Infrastructure (PKI), or a self-signed certificate. A certificate rule uses signed hashes contained in the signature of the signed file to match files regardless of name or location. If you want to make exceptions to a certificate rule, you can use a hash rule to identify the exceptions. Certificate rules provide more flexibility than hash rules. By using a certificate rule, you can allow (or deny)

multiple applications at once. Certificate rules also allow low maintenance of the software restriction policies ruleset, but they can provide the security of hash rules. Path Rule A path rule can specify a folder or fully qualified path to a program. When a path rule specifies a folder, it matches any program contained in that folder and any programs contained in subfolders. Software restriction policies support local and Uniform Naming Convention (UNC) paths. The administrator must define all directories for launching a specific application in the path rule. For example, if the administrator creates a shortcut on the desktop to launch an application, then in the path rule, the administrator must also grant the user Read access rights to both the executable file and the shortcut paths to run the application. If all the path information necessary for launching the application in the path rule is not defined, it can trigger theSoftware Restricted warning when the user attempts to run the application. Environment variables in path rules You can use environment variables in a path rule. Since path rules are evaluated in the client environment, the ability to use environment variables (for example, %Windir%) allows a rule to adapt to a particular users environment. Note

Environment variables are not protected by Access Control Lists (ACLs). There are two types of environment variables: Users and System. Users that are able to start a command prompt can redefine the Users environment variable to a different path. The reason for this is that if an administrator uses %Windir% in a path rule, then a user can run Cmd.exe, change the value of %Windir% to a directory where the users .exe file is, run his or her .exe file, and then exit that shell or change %Windir% back. It is also possible for a user to make changes programmatically or by using the System Properties page in Control Panel. Only users in the Administrators group have permissions to change the System environment variable. If you need to provide enhanced security in your environment, use the registry-based path rules, which is the preferred method. See Registry Path Rules, later in this section.

The following examples show instances of applying environment variables to a path rule:

%UserProfile% matches C:\Documents and Settings\User and all subfolders under this directory. %ProgramFiles%\Application matches C:\Program Files\Application and all subfolders under this directory.

Wildcards in path rules A path rule can incorporate the ? and * wildcards, allowing rules such as *.vbs to match all Visual Basic Script files. The following examples illustrate the use of wildcards:

\\DC-??\login$ matches \\DC-01\login$, \\DC-02\login$ *\Windows matches C:\Windows, D:\Windows, E:\Windows c:\win* matches c:\winnt, c:\windows, c:\windir

Registry path rules Many applications store paths to their installation folders or application directories in the Windows registry. You can create a path rule to look up these registry keys. For example, some applications can be installed anywhere on the file system. These locations might not be easily identifiable by using specific folder paths, such as C:\Program Files\Microsoft Platform SDK, or environment variables, such as %ProgramFiles%\Microsoft Platform SDK. If the program stores its application directories in the registry, you can create a path rule that uses the value stored in the registry, such as%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\Install Dir%. This type of path rule is called a registry path rule. Using registry path rules is a recommended practice because users cannot bypass the path rule by undermining the environment variable expansion. The registry path format is: %[Registry Hive]\[Registry Key Name]\[Value Name]% Note

A registry path rule suffix must not contain a backslash (\) character immediately after the last percent sign (%) in the rule. The registry hive name must be written out; abbreviations will not work.

The following conditions apply to registry paths rules:

The registry path must be enclosed in percent signs (%). The registry value must be a REG_SZ or REG_EXPAND_SZ. You cannot use HKLM as an abbreviation for HKEY_LOCAL_MACHINE, or HKCU as an abbreviation for HKEY_CURRENT_USER. If the registry value contains environment variables, these will be expanded when the policy is evaluated. A registry path rule can also contain a suffix path such as %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache%OLK*. This registry path rule identifies the folder that Microsoft Outlook XP uses to store attachments before launching them. The attachment folder always starts with the letters OLK so the rule uses wildcard matching. For example, this rule matches the following path: C:\Documents and Settings\username\Local Settings\Temporary Internet Files\OLK4.

Note

When you set a path rule, you should check the access control list (ACL) entries on the path. If users have write access to a path, they can modify its contents. For example, if you allow C:\Program Files, any power user on the computer can copy software into the Program Files folder.

When the default rule is set to Disallowed, there are four registry paths that are setup so the operating system has access to system files for normal operation. These registry path rules are created as a safeguard against locking yourself and all other users out of the system. These registry rules are set to Unrestricted. Only advanced users should consider modifying or deleting these rules. The registry path rule settings are:

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot %\*.exe %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\SystemRoot %\System32\*.exe %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Path rule precedence When there are multiple matching path rules, the most specific matching rule takes precedence. The following is a set of paths, from highest precedence (more specific match) to lowest precedence (more general match):

Drive:\Folder1\Folder2\FileName.Extension Drive:\Folder1\Folder2\*.Extension *.Extension Drive:\Folder1\Folder2\ Drive:\Folder1\

Zone Rule A rule can identify software from the Internet Explorer zone from which it is downloaded. These zones are:

Internet Intranet

Restricted Sites Trusted Sites My Computer

The current version of the Internet zone rule applies to only Windows Installer (*.msi) packages. This rule does not apply to software downloaded by using Internet Explorer. All other file types affected by zone rules are listed in the table on designated file types that appears under the Default Designated File Types heading, later in this section. There is one list of designated file types that is shared by all zone rules. Note

Each rule is associated with a globally unique identifier (GUID). An example GUID is {f8c2c158-e1af4695-bc93-07cbefbdc594}. Two identical rules, for example two Disallowedhash rules on the same program, have a different GUID associated with each. This GUID is stored in the registry along with the rule data.

Rules Precedence Rules for software restriction policies are evaluated according to a specific order. The rules that more specifically match a program take precedence over rules that more generally match the same program. If two identical rules with differing security levels are established for the same software, the rule with the highest security level takes precedence. For example, if two hash rules, one with the security level Disallowed and one with the security levelUnrestricted, are applied to the same software program, the rule with the security level Disallowed takes precedence, and the program will not run. The following ordered list defines the precedence order for the rules from the most specific (hash) to the least specific rule (default): 1. 2. 3. 4. 5. Hash rule Certificate rule Path rule Zone rule Default rule

Policy Enforcement Options There are two policy enforcement options that influence the behavior of a software restriction policy. The following options define how software restriction policies are applied for all files, including signed files:

Apply software restriction policies to the following: All files. This option includes dynamic-link libraries (DLLs). Apply software restriction policies to the following users: All users except local administrators. This option prevents the software restriction policies from applying to local administrators.

Including DLLs Most programs consist of an executable file and many supporting DLLs. By default, software restriction policy rules are not enforced on DLLs. Not checking DLLs is the recommended option for most customers for the following reasons:

Including DLLs degrades system performance because it has to check all libraries linked to the application. For example, if a user runs 10 programs during a logon session, the software restriction policy evaluates each program. When the Apply software restriction policies to the following: All files is selected, the software restriction policy evaluates each DLL load within each program. If each program uses 20 DLLs, this results in 10 executable program checks plus 200 DLL checks, so the software restriction policy must perform 210 evaluations. A program such as Internet Explorer consists of an executable file, iexplore.exe, and many supporting DLLs. Setting the default security level to Disallowed forces the system to identify both the main executable file andits supporting DLLs before the .exe file can run, which places added burden on the system.

Note

To provide the highest assurance possible for the programs running in environments that want the highest assurance possible when running programs, DLL Checking is the recommended option. DLL checking is recommended because while viruses primarily target executable files, some specifically target DLLs. To ensure that a program does not contain a virus, you can use a set of hash rules that identify the executable file and its constituent DLLs.

Excluding Administrators An administrator might want to disallow programs from running for most users, but allow administrators to run all of them. For example, an administrator might have a shared computer that multiple users connect to using terminal server. The administrator might want users to run only specific applications on the computer, but allow members in the local Administrators group to run any program. You can use the Apply software restriction policies to the following users: All users except local administrators enforcement option to do this. If the software restriction policy is created in a GPO linked to an object in Active Directory, instead of using the Skip Administrators option, consider denying the Apply Group Policy permission on the GPO to the Administrators group. This approach consumes less network traffic because GPO settings that do not apply to administrators are not downloaded. Note

Software restriction policy defined in local security policy objects cannot filter user groups. In this case, use the Skip Administrators option.

Default Designated File Types Software restriction policy rules apply automatically to some types of executable files, regardless of their extension type. This includes the following types of files:

Windows operating system executable files (.exe, .com, .dll) Windows scripting files (when processed by Windows Script Host, such as .vbs, and .wsh files) Command batch files (when processed by Windows CMD, such as .bat, .cmd) Installation packages when processed by Windows Installer (.msi)

You can apply software restriction policies rules to additional file types, even when they are handled by nonMicrosoft programs. However, if the other program does not enforce software restriction policies itself, the software restriction policies restrictions will only apply when either Windows Explorer or Internet Explorer is used to open the file. Opening the other program and then opening the executable script from within that program circumvents software restriction policies. To resolve this issue, contact the software provider and request that they enforce software restriction policies when opening executable scripts, or disallow execution of the other scripting host. The file types are listed in the Designated File Types Properties dialog box. This dialog is accessible in the Group Policy Object Editor, in Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies, under Designated File Types in the details pane. Additional file types to which you want to apply rules can be added to this list. For example, for Perl scripting files you might choose to add .pl and other file types associated with the Perl engine to the Designated file types list under the General tab of the Designated File Types Properties dialog box. Note that you can check only the initial script this way; if a Perl script calls another Perl script, there will be no software restriction policies check. The following table lists what is considered to be executable code. This is in addition to standard program files such as .exe, .dll, and .vbs. Default Designated File Types

File Extension .ade .adp .bas

File Description Microsoft Access Project Extension Microsoft Access Project Visual Basic Class Module

.bat .chm .cmd .com .cpl .crt .exe .hlp .hta .inf .ins .isp .lnk1 .mdb .mde .msc .msi .msp .ocx .pcd .pif .reg .scr .shs .url .vb .wsc
1

Windows Batch File Compiled HTML Help File Windows NT Command Script Application Control Panel extension Security Certificate Application Windows Help File HTML Applications Setup Information File Internet Communication Settings Internet Communication Settings Shortcut MDB File Microsoft Access MDE Database Microsoft Common Console Document Windows Installer Package Windows Installer Patch ActiveX Controls Photo CD Image Shortcut to Program Registration Entries Screen Saver Shell Scrap Object Internet Shortcut (Uniform Resource Locator) VB File Windows Script Component

If you click a .lnk file (shortcut) in the UI, ShellExecute applies software restriction policies to it if the .lnk extension is included in Designated File Types. Otherwise, ShellExecute runs the target, where software restriction policies get applied in CreateProcess. If the file type of the shortcuts (.lnk) target is not an executable file directly, such as a .doc file, and if .doc is included in Designated File Types,software restriction policies rules are applied to the .doc file. If .doc is not included in Designated File Types,ShellExecute runs the handler with specified options (such as running WinWord filename.doc). At this point, CreateProcess applies software restriction policies to the application, WinWord, and not to the filename.doc, which was the actual target of the .lnk. Trusted Publishers You can use the Trusted Publishers Properties dialog box to configure which users can select trusted publishers. You can also determine which, if any, certificate revocation checks are performed before trusting a publisher. With certificate rules enabled, software restriction policy will check a certificate revocation list (CRL) to ensure the softwares certificate and signature are valid. This can decrease performance when starting signed programs. The options under the General tab of the Trusted Publishers Properties dialog box. You access this dialog in the Group Policy Object Editor snap-in, by navigating to Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies, anddouble-clicking Trusted Publishers in the details pane. Note

If you enable the Trusted Publishers option, you must also explicitly add the certificates of allowed ActiveX publishers to the Trusted Publisher certificate store. Adding the certificates is required to ensure that installation and other operations work properly and to maintain the appropriate system functions. If you dont add the certificates, ActiveX controls will not install, and some applications which perform signature validation might exhibit unexpected behavior. All trust validations using the default Authenticode policy fail unless the signing certificate is in the Trusted Publishers store. For example, Windows Update automatically validates its own signature and the signatures of downloaded files. The Trusted Publishers restrictions are only recommended for the most restrictive environments.

Default Settings for a Software Restriction Policy The default settings for a software restriction policy include the following:

Default Security Level: Unrestricted Enforcement options:

Apply to Files: All software files except libraries (such as DLLs) Apply to Users: All users

Additional Rules: none Designated File Types: These are defined in the Default Designated File Types section, earlier in this document. Trusted Publishers:

Select Trusted Publishers: End users Publisher certificate revocation checking: Not selected Timestamp certificate revocation checking: Not selected

Example: Applying Software Restriction Policies in a Highly Restricted Environment In some cases, you might want to manage all of the software that runs on a computer. For example, even when users have insufficient rights to replace system files or files in shared folders such as Program Files, if the users have a place on the file system to which they can write, they could copy a program there and start it from that location. Administrators can create a highly-restricted (locked down) configuration to prevent users from modifying the contents of the Program Files or Windows folders, and allow them to run only software that is installed by the administrator. In this case, you would also need to ensure that users are not administrators on their local computers. The following policy can help prevent users from running malicious code:

Default Security Level: Disallowed Apply software restriction policies to the following users: All users except administrators Path Rules:

%WINDIR% Unrestricted %PROGRAMFILES% Unrestricted

This policy disallows all software on the users computer, except software that is installed in the Windows directory, Program Files directory, or their respective subfolders. The policy does not apply to administrators.

If all the programs a user needs are not installed in %WINDIR% or in %PROGRAMFILES%, or there are programs in those folders that the administrator does not want the user to run, the administrator can make additional exceptions as follows:

Path Rules:

%WINDIR%\regedit.exe: Disallowed %WINDIR%\system32\cmd.exe: Disallowed \\CORP_DC_??\scripts: Unrestricted

%HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates \InoculateIT\6.0\Path\HOME%: Unrestricted As a result of these exceptions, the following occurs:

Both the command prompt (cmd.exe) and the registry editor (regedit.exe) are disallowed. An exception is created to allow login scripts to run on the users computer. The use of the question mark ? wildcard allows the rule to match \\CORP_DC_01, \\CORP_DC_02, and others. A registry path rule is added that allows the anti-virus software on the computer to run.

Software Restriction Policies Processes and Interactions

This section discusses how software restriction policies are processed and stored, and also explains how software restriction policies are merged. Software Restriction Policies Processing Software restriction policy is distributed by using the normal Group Policy process. That is, software restriction policies are saved in Group Policy objects (GPOs), and the management tools use the Group Policy Interfaces (IGroupPolicyObject) to save and load the software restriction policies. GPOs are linked to sites, domains, or organizational units (OUs) in Active Directory. An administrator can use the standard Group Policy mechanisms to apply additional filtering options to a GPO to have it apply to a select set of users or computers within an OU. When a computer starts up or when a user logs on, the Group Policy engine queries Active Directory for any GPOs that apply to it. It downloads and applies these GPOs in a specific order (local, site, domain, and OU), where the closest OU to the user or computer object is the last GPO applied. If Group Policy fails to download any of the GPOs, the entire process is aborted and no GPOs are applied. In regard to software restriction policies (also referred to as Safer), Group Policy processing essentially involves downloading a number of Registry.pol files from Active Directory. The Registry.pol files contain the registry keys and values set through the Safer policy APIs. The keys and values of each policy are then copied into the local users registry in the HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER registry hive as appropriate. This process is repeated for each GPO that contains a software restriction policy. Group Policy is periodically refreshed: on clients, security policy reapplies every 16 hours regardless of whether policy changes have occurred. If there is a policy change, it applies within 90 minutes of the change. All the policy distribution is handled by the Group Policy infrastructure and not by the software restriction policies extension directly. The Safer Enforcement APIs base their decisions on the effective policy, which is the result of combining the software restriction policies in the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USERregistry hives. Software restriction policies do not implement a client side extension to Group Policy. Group Policy Processing Order By default, Group Policy is inherited and cumulative, and it affects all computers and users in an Active Directory container. Group Policy objects are processed according to the following order:

Local Group Policy object. Each computer has one Group Policy object that is stored locally. This processes for both computer and user Group Policy processing. The local GPO cant be blocked by domainbased GPOs. However, settings in domain GPOs always take precedence because they are processed after the local GPO.

Site. Any GPOs that have been linked to the site that the computer belongs to are processed next. They are processed in the order specified by the administrator, on the Linked Group Policy Objects tab for the site in the Group Policy Management Console (GPMC). The GPO with the lowest link order is processed last, and therefore has the highest precedence. Domain. Multiple domain-linked GPOs are processed in the order specified by the administrator, on the Linked Group Policy Objects tab for the domain in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence. Organizational units. GPOs that are linked to the OU that is highest in the Active Directory hierarchy are processed first. Then GPOs that are linked to its child OU are processed, and then any lower child OUs. Finally, the GPOs that are linked to the OU that contains the user or computer are processed.

This processing is subject to the following conditions:

WMI or security filtering that has been applied to GPOs. A domain-based GPO can be enforced by using the Enforce option to ensure that its policies cannot be overwritten. Because an Enforced GPO is processed last, no other settings can overwrite the settings in that GPO. If more than one Enforced GPO exist, its possible to set the same setting in each GPO to a different value, in which case, the link order of the GPOs determines which one contains the final settings. At any domain or OU, Group Policy inheritance can be selectively designated as Block Inheritance. However, because enforced GPOs are always applied and cannot be blocked, blocking inheritance does not prevent policy from Enforced GPOs from being applied.

Group Policy Refresh Period By default, Group Policy is processed every 90 minutes plus a randomized offset of up to 30 additional minutes for a total maximum refresh interval of up to 120 minutes. For domain controllers, the default period is every 5 minutes. You can change the default values for computers by using the Group Policy Refresh Interval for Computers Group Policy setting under Administrative Templates in the Default Domain Controllers GPO. For domain controllers, the Group Policy Refresh Interval for Domain Controllers setting controls this default; it is available under Computer Configuration\Administrative Templates\System\Group Policy. For computers, the Gpupdate command can also be used to trigger a background refresh of Group Policy on demand from the client. Merging for Multiple Software Restriction Policies Whenever two or more Group Policy objects apply to a user or computer, the policies are merged. When two or more software restriction policies are merged, the following occurs:

The GPO with the highest precedence sets the following values:

Default Security Level Designated File Types Skip Administrators DLL Checking

The rules from multiple GPOs are always merged. Thus, all additional rules from all GPOs are preserved.

A software restriction policy can be set for user scope and computer scope. The following semantics are observed when merging user and computer scope:

The more restrictive default security level is chosen. The list of designated file types in the computer policy, if present, is used. If not present, the list of designated file types in the user policy is used. The Skip Administrators value is always chosen from the computer policy.

If DLL checking is enabled in either policy, then it is enabled. All the rules between user and computer policies are merged.

Storage of Software Restriction Policies Settings After a software restriction policy is applied, the software restriction policy configuration is stored in the system registry. The security access control list (ACL) protecting these registry keys allows only members of the Administrators group and the SYSTEM account to change them. Software restriction policies use these registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer andHKEY_CURRENT_USE R\Software\Policies\Microsoft\Windows.

CodeIdentifiers. Default Level (DWORD). 40000 for Unrestricted, 0 for Disallowed. ExecutableTypes (REG_MULTI_SZ). List of extensions for designated file types. TransparentEnabled (DWORD). Defines which files to include during rule evaluation. 0 means no enforcement, 1 indicates to exclude DLLs in evaluation, and 2 indicates to include all files in evaluation. PolicyScope (DWORD). Defines the scope of users to which this policy applies. 0 applies to all users, and 1 applies to all users except administrators. Note that this value is only valid for HKEY_LOCAL_MACHINE. AuthenticodeEnabled (DWORD). Defines if certificate rules should be applied, 0 means disabled, 1 indicates that certificate rules will be applied. Note that this value is only valid for HKEY_LOCAL_MACHINE. LogFileName (REG_SZ). An optional registry value that needs to be set manually. This value defines a path to the log file that captures advanced logging. If this value is set, advanced logging is enabled and written to this log file. Note that this value is only valid for HKEY_LOCAL_MACHINE. The zero (0) key. Indicates a SAFER_LEVELID_DISALLOWED security level. Entries under this key are Disallowed rules.

Hashes. All hash rules are defined under this key.

{GUID}. This is uniquely generated for each Rule defined. Description (REG_SZ). This is the administrator-defined description of the rule. FriendlyName (REG_SZ). This is the name of the hash. HashAlg (REG_DWORD). This is the type of hash that is stored in ItemData. For files that are not digitally signed or are signed with MD5, this value is defined as 0x8003 or CALG_MD5 or (ALG_CLASS_HASH | ALG_TYPE_ANY | ALG_SID_MD5). ItemData (REG_BINARY). The actual hash to the file. This value should always be 16 bytes and is generated with a call toCodeAuthzpComputeImageHash(). ItemSize (REG_QWORD). This is the actual file size of the target file. To evaluate this value, reverse the bytes. For example, if the value data was: 00 0A 01 00 00 00 00 00, the file size would actually be 010a00 or 68,096 bytes. LastModified (REG_QWORD). This is the date and time down to seconds of when this entry was last updated. Several utilities exits to extract this name into a readable format however just as the ItemSize data was reversed so should this value. SaferFlags (REG_DWORD). Not used and will always be set to zero.

Path. All Path rules are defined under this key.

{GUID}. This is uniquely generated for each Rule defined. Description (REG_SZ). This is an administrator defined description of the rule.

ItemData (REG_EXPAND_SZ Or REG_SZ). This is the path to be used for this rule. Note that if the data provided for this value includes any environment variables that must be expanded the value type will be REG_EXPAND_SZ otherwise it will be REG_SZ.

LastModified (REG_QWORD). This is the date and time down to seconds of when this entry was last updated. Several utilities exits to extract this name into a readable format however just as the ItemSize data was reversed so should this value.

SaferFlags (REG_DWORD). This is not used and will always be set to zero.

UrlZones. All zone rules are defined under this key.

{GUID}. This is uniquely generated for each Rule defined.

ItemData (REG_BINARY). Defines the URLZone to which this rule is defined. URL Zones are defined in urlmon.h and are of type enum tagURLZONE. For example if a value of 0x3 appears in this value that evaluates to URLZONE_INTERNET.

LastModified (REG_QWORD). This is the date and time down to seconds of when this entry was last updated. Several utilities exits to extract this name into a readable format however just as the ItemSize data was reversed so should this value.

SaferFlags (REG_DWORD). This is not used and will always be set to zero.

262144. Indicates a SAFER_LEVELID_FULLYTRUSTED security level. Entries under this key are Unrestricted rules.

Certificate Rules Certificate rules are stored in a separate key in the registry. Certificate rules for user software restriction policies are stored in this registry key:

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\SystemCertificates

Certificate rules for computer software restriction policies are stored in this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates

Resultant Set of Policy To obtain information about policy stored in the registry, the Software Restriction Policies extension queries the registry policy by using WMI. The RSOP_RegistryPolicySetting WMI namespace represents policy data for registry or administrative template extension. Policy settings in an administrative template file (.adm) involve setting values on registry keys that are abstracted by this namespace. Software Restriction Policies also store information in the registry. To retrieve this registry data, the IwbemServices WMI interfaces ExecQuery method is used to perform a query to retrieve objects from theRSOP_RegistryPolicySetting namespace.

Related Information
The following resources contain additional information that is relevant to this section.

How Core Group Policy Works in the Group Policy Collection.

How Group Policy Software Installation Extension Works in the Group Policy Collection.

Software Restriction Policies Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Software Restriction Policies Tools and Settings

In this section

Software Restriction Policies Tools Software Restriction Policies Group Policy Settings Related Information

Administrators can use command line tools to refresh Group Policy settings, including software restriction policies, and to display the resulting set of policies that were enforced on the computer for a specified user at logon. To assess the policy settings that are in effect for a computer or user, administrators use the Resultant Set of Policy (RSoP) snap-in.

Software Restriction Policies Tools

The following tools are associated with Software Restriction Policies: Gpupdate.exe This tool is used for refreshing local and Active Directory policy settings on the computer from which you run the gpupdate command. For more information about this tool, see Core Group Policy Tools and Settings in this collection. Gpresult.exe This tool enables you to examine the Group Policy settings applied during a policy refresh. For more information about this tool, see Core Group Policy Tools and Settings in this collection. Resultant Set of Policy (RSoP) This tool polls for existing Group Policy settings and planned policy settings, and then reports the results of those queries. For more information about RSoP, see What Is Resultant Set of Policy? in this collection.

Software Restriction Policies Group Policy Settings

The following table lists and describes the Group Policy settings that are associated with software restriction policies. Software Restriction Policies Security Levels and Additional Rules

Security Levels Disallowed Unrestricted Additional Rules

Description Does not allow the specified software to run.

Allows the specified software to run on the computer with the full rights of the currently logged on user.

Security Levels Hash Rule

Description

A series of bytes with a fixed length that uniquely identifies a software program or file. A hash (also called a me obtained by applying a one-way mathematical function (sometimes called a hash algorithm) to an arbitrary amo input data changes, the hash changes. The hash can be used in many operations, including authentication and If you create a hash rule for a software program, software restriction policies calculate a hash of the program. W open a software program, a hash of the program is compared to existing hash rules for software restriction poli software program is always the same, regardless of where the program is located on the computer. However, if

to the software program, its hash also changes, and it no longer matches the hash in the hash rule for software Path Rule Certificate Rule Internet Zone Rule

Identifies a program according to a folder or its fully qualified path. Both URL and UNC paths are permitted. You in path rules: environment variables, wildcards (question mark ? and asterisk *), and registry path rules.

Identifies software based on a signed certificate. You create a certificate rule that identifies software and then s to either allow or not allow the software to run.

Identifies software from a zone that is specified through Internet Explorer. The zones are Internet, Intranet, Re sites, and My Computer. These rules apply only to Windows Installer packages (.msi files).

The following table lists the software restriction policy options. Software Restriction Policy Options

Options Enforcement

Description

Enforcement enables you to specify whether to turn on dynamic-link library (DLL) checking and skip administ software restriction policies from applying to local administrators. Use the Apply software restriction policies to the following option to select one of the following:

All software files except libraries (such as DLLs). This option specifies that the rules will not aff

All software files. This option applies software restriction policies to all files, including DLLs. This op checking. Use the Apply software restriction policies to the following users option to select one of the following:

All users. This option specifies that all the rules you define apply to all users.

All users except local administrators. This option prevents software restriction policies from applying to lo This is used when administrators want to prevent most users from running certain programs, but allow local a any program.

Designated File The Designated File Types dialog box lists the file types to which the software restriction policy applies. The li Types of files that are considered executable files. The rules you specify in a software restriction policy apply only to the Designated File Types list. If you want to be able to set rules on additional file types, add them to the Des Trusted Publishers

The Trusted Publishers options enable you to configure settings related to ActiveX controls and other signed c Publishers includes the following options:

Enterprise Administrators: Use this option to allow only domain administrators to make decisions active content.

Local computer Administrators: Use this option to allow local computer administrators to make al signed active content. End Users: Use this option to allow any user to make decisions regarding signed active content.

Publisher: Use this option to ensure that the certificate used by the software publisher has not been

Timestamp: Use this option to ensure that the certificate used by the organization that time-stampe has not been revoked. For more information about software restriction policies rules and enforcement options, see How Software Restriction Policies Work in this Collection.

Related Information
The following resources contain additional information that is relevant to this section.

What Is Resultant Set of Policy? in this collection. What Is Group Policy Management Console? in this collection.

For more information about the command-line tools listed in this document, see Core Group Policy Tools and Settings in this collection. For GPMC download information, see the Group Policy Management Console page. Tools and Settings Collection

Scripts Extension Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 Microsoft Windows 2000 Server and Windows Server 2003 use Group Policy settings to provide directory-based desktop configuration management. These Group Policy settings are stored in a Group Policy object (GPO). You can create and manage GPOs by using the Group Policy Object Editor. General classes of Group Policy settings are implemented as extensions to the operating system. These extensions are packaged as dynamic-link libraries (DLLs), and exist as two types of extension:

Server-side extension A Microsoft Management Console (MMC) snap-in that is used for administration and configuration. Client-side extension (CSE) An extension that runs on the client computer that interprets and applies the MMC type settings to the client computer, also known as the target computer.

The GPO settings are configured via the server side extension, and applied to individual computers and users, by the client-side extension (CSE). The Group Policy engine is the framework used to manage all client side extensions, including the Scripts client-side extension. In this subject

What Is Scripts Extension? How Scripts Extension Works Scripts Extension Tools and Settings

What Is Scripts Extension?

Updated: December 13, 2010 Applies To: Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Vista

What Is Scripts Extension?

Active Directory domains use the Scripts extension to run scripts on client computers. The Scripts extension consists of two components; an MMC server-side snap-in and a client-side extension (CSE). A Group Policy CSE is a dynamic-link library (DLL) on the client (target) that interacts with the Group Policy infrastructure and that implements Group Policy scripts on the target. You can control how the Scripts CSE implements scripts by using the Group Policy Object Editor on the server. The following figure shows Group Policy Object Editor, a Microsoft Management Console (MMC) snap-in with the scripts node. Group Policy Object Editor

Before the introduction of the GPO Scripts extension, user logon scripts were added to the user account object. Only one script was added to the object, and the script was a user script; no computer scripts were allowed. The Scripts CSE now allows the following four script types, corresponding to four of the target events triggering the Scripts extension:

User logon scripts User logoff scripts Computer startup scripts Computer shutdown scripts

Other Scripts extension trigger events are:

User policy refresh event User policy force refresh event Computer policy refresh event Computer policy force refresh event Secedit tool or gpupdate

These events tell the computer which scripts need to be run at each script execution opportunity; these events do not run the scripts. Scripts are added to the Group Policy object (GPO), and multiple scripts for each script type can be added to the GPO. A script can be written in any language supported by the client computer, with Windows Script Host (WSH) supported languages and command files being the most common. WSH languages include VBScript and JScript, which are the languages used for the sample scripts included with Group Policy Management Console (GPMC). Script names and their command-line arguments are stored in the registry when script policy processes. You can specify Administrative Templates Group Policy settings that modify how Group Policy scripts behave by using the

options shown in the following table. These settings are located under Computer Configuration|Administrative Templates|System|Scripts. Computer Configuration Script Options

Option Allow logon scripts when NetBIOS or WINS is disabled This setting requires Windows Vista or later. Run logon scripts synchronously Run startup scripts asynchronously Run startup scripts visible Run shutdown scripts visible Maximum wait time for Group Policy scripts

Description

Enable this setting to allow user logon scripts to run if NetBIOS or WINS is disabled during logons a the DNS suffixes being configured.

Enable this option to force the system to run the scripts synchronously, one after another. This opt and user configuration, which can have a different value. In case of conflict, the computer configura

The default setting is for scripts to run synchronously (and hidden). Use this option to optimize the processes so users can logon before startup scripts have finished. Enable this option to run startup scripts in a visible window. Enable this option to run shutdown scripts in a visible window.

Use this option to set the script timeout interval. The default interval is 600 seconds (10 minutes), range from 0 to 32000 seconds. If the value of this setting is greater than 900 seconds (15 minutes), for computers running Window the value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gpsvc for Preshutdow corresponding value that is slightly greater than the value of the "Maximum wait time for Group Po example, in order for "Maximum wait time for Group Policy scripts" to work with a value of 30 minu the gpsvc for PreshutdownTimeout registry entry to a value of 1800000 (The registry setting va

Run Windows PowerShell Enable this option to run PowerShell scripts before non-PowerShell scripts at computer startup and scripts first at computer startup, shutdown This setting requires Windows 7 or Windows Server 2008 R2. Run Windows PowerShell Enable this option to run PowerShell scripts before non-PowerShell scripts at logon and logoff. scripts first at user logon, logoff This setting requires Windows 7 or Windows Server 2008 R2. You can specify user configuration Group Policy settings that modify how Group Policy scripts behave by using the options shown in the following table. These settings are located under User Configuration|Administrative Templates|System|Scripts User Configuration Script Options

Option Run logon scripts synchronously Run legacy logon scripts hidden Run logon scripts visible Run logoff scripts visible Run Windows PowerShell scripts first at user logon, logoff This setting requires

Description

Enable this option to force the system to run the script synchronously, one after another. This Computer configuration, which can have a different value. In case of conflict, the computer co prevails. On computers running Windows XP, the explorer starts before scripts finish running. Enable this option to run legacy, Windows NT version 4type logon scripts hidden. By default can be canceled by users. Enable this option to run logon scripts in a visible window. Enable this option to run logoff scripts in a visible window.

Enable this option to run PowerShell scripts before non-PowerShell scripts at logon and logoff.

Windows 7 or Windows Server 2008 R2.

Change History
Date December 13, 2010 Revision

Updated the topic so it applies to Windows Vista, Windows Server 2008, Windows 7, and Windows Server 200 Added information about configuring the value of the gpsvc for PreshutdownTimeout registry entry for com Windows 7 when the Maximum wait time for the Group Policy scripts setting is greater than 900 seconds. Added settings that require Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2. Deleted row that incorrectly listed Run logoff scripts synchronously.

How Scripts Extension Works

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Scripts Extension Works

The Scripts extension is one of the Group Policy extensions that automate configuration of the Group Policy infrastructure. The Scripts extension consists of two parts. The server-side extension, a Microsoft Management Console (MMC) snap-in, enables administrators to make enterprise-wide script Group Policy settings. The Scripts client side extension (CSE) implements those settings on the client computer. A separate process, Userinit, actually runs the scripts. In this section

Scripts Extension Architecture Scripts Extension Protocols Scripts Extension Physical Structure Scripts Extension Processes and Interactions Network Ports Used by Scripts Extension

Scripts Extension Architecture

The Group Policy Scripts client-side extension (CSE) is managed by the Group Policy core, which stores a list of Group Policy objects (GPOs) received from Active Directory. The GPO list is then passed into the Scripts CSE where the scripts.ini file of each GPO is read from the Sysvol folder. This information required for script processing is stored in the client registry. When Group Policy is finished processing, the WinLogon process retrieves the registry information, and then creates a Userinit process that actually runs the scripts. During logoff and shutdown, WinLogon again creates a Userinit process to run the relevant scripts. The Userinit process uses the ShellExecute command to run each script. The following figure shows the Scripts extension architecture and the client-server interaction of the two extension components. Scripts Extension Architecture

Components important to the Scripts extension, seen in the preceding figure, are described in the table below. Components not seen in the figure, but important to the process are also described. Scripts Logical Architecture Components

Component Group Policy engine

Description

The Framework that manages and implements the Group Policy settings and configurations, made by client-side extensions (CSE). Userinit actually executes the script; not the CSE. Userenv.dll is the Gr module.

Scripts client-side extension (CSE) WinLogon Resultant Set of Policy (RSoP) snap-in Userinit Local GPO

The Scripts CSE is the component that is called by the Group Policy engine, and that applies the scrip CSE writes the relevant script information into the registry. It does not run the scripts. WinLogon is the service that contains the Group Policy engine.

Displays the results of Group Policy, including what scripts have run and when they were last run. Fo about RSoP, see What Is Resultant Set of Policy?. Called by Winlogon to run Group Policy scripts by calling ShellExecute. Contains Group Policy settings for the local computer, including potential scripts policies.

The CSE registration information is written at setup to the HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\ GPExtensions registry key. This registry key structure exists on both the target and on the domain controller systems.

Scripts Extension Protocols

The various protocols used within the Scripts extension architecture are summarized in the following table. Scripts Extension Protocols

Protocol Win32 NTLM or Kerberos Server Message Block (SMB) Distributed Component Object Model (DCOM)

Description Windows API function call.

Authentication protocol used by the client to authenticate with Active Directo SMB is a file access protocol used by Userinit to access the Sysvol folder.

DCOM is used by CSEs to communicate with Windows Management Instrum

Scripts Extension Physical Structure

Most Group Policy settings are stored in the Group Policy template, part of the domain controllers file system. Group Policy templates are stored in the %systemroot%\SYSVOL\sysvol\domainname\policiessubfolder. The root of each Group Policy template contains a Gpt.ini file. Each Group Policy template contains a Machine and User subfolder, both of which contain a Scripts subfolder that contains the Scripts.ini file. The Machine Scripts subfolder contains a Shutdown and a Startup subfolder. The User Scripts subfolder contains a Logoff and a Logon subfolder. These four subfolders contain their respective Group Policy scripts to be implemented on the target by the Scripts CSE. Components important to the Scripts CSE are described in the following table. Scripts Physical Architecture Components

Component Sysvol folder

Description

The Sysvol folder contains the set of folders shared on each domain controller that stores file-system do compared to registry domain information. The Sysvol folder is one of the locations that the Scripts.ini fil location is the Local GPO.

Group Policy template Gpt.ini ADM folder Machine folder User folder Scripts folder Scripts.ini file External Scripts server Scripts Server-side extension Snap-in Logon folder Logoff folder Startup folder Shutdown folder

The Group Policy template is part of the GPO, and is the portion of Group Policy settings stored in the fil between domain controllers. The Group Policy template makes up the majority of the Group Policy settin template folder is a subfolder of the Policies folder and has a globally unique identifier (GUID).

Gpt.ini is a file in the Group Policy template root folder that stores the GPO version number of the Group Group Policy CSEs use this version number to confirm that directory and file components are synchroniz The ADM folder stores the System.adm file, among others. The Machine folder stores GPO Computer settings files. One of the subfolders is the Scripts folder. The User folder stores GPO User settings files. One of the folders is the Scripts folder.

The Scripts folder, a subfolder of both the Machine and User folders, stores the Scripts.ini file and refere The Scripts.ini file is stored on the Sysvol folder in the Scripts folder and stores the path to each script. A server, other than the domain controller, on which the actual scripts can be stored.

A snap-in that is a server side component that loads with Group Policy Object Editor. The snap-in display Windows Settings of both Computer Configuration and User Configuration.

A subfolder of the Sysvol folder containing any user logon scripts to be implemented by the Scripts CSE.

A subfolder of the Sysvol folder containing any user logoff scripts to be implemented by the Scripts CSE

A subfolder of the Sysvol folder containing any computer startup scripts to be implemented by the Scrip

A subfolder of the Sysvol folder containing any computer shutdown scripts to be implemented by the Sc

Scripts Extension Processes and Interactions

The Scripts CSE processes all applied GPOs. The Scripts CSE reads the command-line options for the scripts from the Scripts.ini file. If a full path is specified, the full path is stored in the registry. If only a name is specified, the CSE creates the full path to the file in the Sysvol folder, prior to storing it in the registry. On Windows XP and better, The Scripts CSE stores this information in the clients registry, in the following keys:

HKEY_LOCAL_MACHINE\Software\Policies\Windows\System\Scripts HKEY_COMPUTER_USER\Software\Policies\Windows\System\Scripts

The script type is stored as one of the following registry values:

Logon Logoff Startup

Shutdown

The Scripts CSE sorts scripts by using the following rules:

By GPO priority By priority order within each GPO

Scripts are usually stored in the Startup and Shutdown subfolders of the Machine\Scripts folder or in the Logon and Logoff subfolders of the User\Scripts folder. Scripts can be stored in a different location, or on a different server. However, for the script to run, the script file must be available and accessible (read access) for it to be run. Note that the user must have read access for logon and logoff scripts and the computer must have access for startup and shutdown scripts. Both are members of the Authenticated Users group, so by default both have access to run their respective scripts. The script is run from the file path location stored in Scripts.ini and the script is not cached on the client computer. If the network is unavailable when scripts are set to run, they will not run.

Network Ports Used by Scripts Extension

The following table summarizes the network protocols and port numbers used by the Scripts CSE. The Scripts extension impersonates the user and computer for network communication. Port Assignments for Scripts CSE

Task Retrieve GPO list Retrieve Group Policy container Request Distributed File System (DFS) referral for the Sysvol folder on the domain controller Determine Sysvol DFS replica location for the Sysvol folder on the domain controller Open and read Gpt.ini Open and read Group Policy template settings files Return Group Policy template file

Scripts Extension Tools and Settings

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Scripts Extension Tools and Settings

This section contains references to tools associated with the Scripts Extension. This section also contains settings, Registry entries, WMI Classes, and Network information associated with the Scripts extension. In this section

Scripts Extension Group Policy Settings Related Information

Scripts Extension Group Policy Settings

You can use the Windows Settings\Scripts node under both Computer Configuration and User Configuration to specify scripts to be run. Note that the scripts server-side extension permits you to specify the path to the scripts that need to be run. It does not create the script. The following tables describe the Computer and User Configuration Windows Settings\Scripts node settings. Computer Configuration\Windows Settings\Scripts

Option Scripts (Startup\Shutdown)

Description

Use this node to specify the script files to be run when the computer starts up and shuts down. You c files by selecting the button to open the explorer window. Add or delete the script files using this win

User Configuration\Windows Settings\Scripts

Option Scripts (Logon\Logoff)

Description

Use this node to specify the script files to be run when the user logs on and logs off. You can add or delet selecting the button to open the explorer window. Add or delete the script files using this window.

You can also specify Administrative Templates Group Policy settings that modify how Group Policy scripts behave. There is an Administrative Templates node for both Computer Configuration and User Configuration in Group Policy Object Editor. The following tables summarize the Group Policy settings that are associated with Scripts Extension in a Windows 2000 or greater domain. Computer Configuration\Administrative Templates\System\Scripts

Option Run logon scripts synchronously Run startup scripts asynchronously Run startup scripts visible Run shutdown scripts visible Maximum wait time for Group Policy scripts

Description

Enable this option to force the system to run the scripts synchronously, one after another. This computer and user configuration. Computer setting has precedence.

Use this option to optimize the startup/logon processes so users can logon before startup script default startup scripts run synchronously.

Enable this option to run startup scripts in a visible window. By default scripts run invisible, use interact or cancel scripts that run invisible.

Enable this option to run shutdown scripts in a visible window. By default scripts run invisible, u interact or cancel scripts that run invisible.

Use this option to set the script timeout interval. The default interval is 600 seconds (10 minute range from 0 to 32000 seconds. This affects both computer and user scripts that run synchrono

Computer Configuration\Administrative Templates\System\Group Policy

Option Scripts policy processing

Description When enabled, this changes how the scripts client-side extension processes scripts policy. (Note that this processing of scripts policyit does not affect how or when scripts are run). When enabled, options include:

Processing scripts policy when on a slow link. (Note that this will not stop existing scripts from run stops scripts from processing scripts policy). Processing scripts policy during periodic background refresh. Always process scripts policy, even if there were no changes detected.

User Configuration\Administrative Templates\System\Scripts

Option Run logon scripts synchronously Run legacy logon scripts hidden Run logon scripts

Description

Enable this option to force the system to run the script synchronously, one after another. This option als configuration, which can have a different value. In case of conflict, the computer configuration setting pr running Windows XP, the Windows Explorer starts before scripts finish running.

Enable this option to run legacy, Windows NT 4type logon scripts hidden. By default these run visible a by users. Enable this option to run logon scripts in a visible window. By default scripts run invisible, users are not

visible Run logoff scripts visible

cancel scripts that run invisible. Enable this option to run logoff scripts in a visible window. By default scripts run invisible, users are not cancel scripts that run invisible.

There are policies that control which Microsoft Management Console (MMC) snap-ins can and cannot be run. By setting these policies, a user can be restricted from administering scripts policies by restricting the scripts MMC snap-in. These policies are shown in the following table. User Configuration\Administrative Templates\Windows Components\Microsoft Management Console\Restricted/Permitted snap-ins\Group Policy\Group Policy snap-in extensions

Option Scripts (Logon/Logoff) Scripts (Startup\Shutdown)

Description

The default setting is Not Configured, which causes the Restrict users to the explicitly per setting to apply. Enabling Scripts (Logon/Logoff) permits the snap-in. Disabling the settin

The default setting is Not Configured, which causes the Restrict users to the explicitly per setting to apply. Enabling Scripts (Startup\Shutdown) permits the snap-in. Disabling the snap-in.

Restrict users to the explicitly permitted list of snap-ins

The default setting of Not Configured and Disabled permits any snap-in that is not explici setting is Enabled, only explicitly Enabled snap-ins are permitted.

For more information about Group Policy settings, see the Group Policy Settings Reference for Windows Server 2003.

Related Information
The following resources contain additional information that is relevant to this section.

Group Policy Settings Reference for Windows Server 2003 Tools and Settings Collection

Wireless Network Policies Extension Technical Reference

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 The Wireless Network Policies Extension is a Group Policy extension that you can use to automate configuration of Wireless Network Group Policy settings. Configuration of Wireless Group Policy settings requires, at minimum, one domain controller running a Microsoft Windows Server 2003 operating system. The Wireless Network Policies Extension is supported on client computers running Windows XP Professional (Service Pack 1 and later) and using IEEE 802.11 access with IEEE 802.1x authentication in a wireless network. In this subject

What Is Wireless Network Policies Extension? How Wireless Network Policies Extension Works Wireless Network Policies Extension Tools and Settings

What Is Wireless Network Policies Extension?

Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What Is Wireless Network Policies Extension?

This section describes the Wireless Network Policies Extension. On computers running Microsoft Windows Server 2003 Active Directory, domain administrators use the Wireless Network Policies Extension to automate wireless Group Policy management. The Wireless Network Policies Extension is one of the Group Policy client-side extensions that plug into the Group Policy infrastructure.

Wireless Network Policies Extension is one of the general classes of Group Policy settings that are implemented as extensions to the operating system. These extensions are packaged as DLLs, and exist as two types of extensions:

MMC snap-inAn administration and configuration extension that runs on the server. Client-Side ExtensionAn extension that interprets and applies the MMC type settings to the target system (client), and which runs on the client.

The following figure shows an overview of a wireless network. The MMC snap-in fits in the Directory box on the server, and the CSE fits in the Wireless Client box. Wireless Network Overview

Organizations need a way to centrally manage wireless Group Policy configuration for multiple users. The administrator needs to make specific wireless Group Policy decisions, including:

Group Policy object (GPO) application criteria. Number of GPOs required. Location of GPOs. Number of Wireless LAN (WLAN) profiles required.

The Wireless Network Policies Extension provides central wireless Group Policy management that includes:

Active Directory-based group filtering to provide Wireless Network Policy to a single computer global group. A single GPO Wireless Network Policy. A single GPO created and applied from the ForestRootDomain object. A single WLAN profile configured for 802.1x-compliant organizations. For multiple profiles, you have the option to support a phased migration from a legacy production WLAN.

This solution implementation is seen in the following figure. The figure shows the Group Policy Object Editor for a GPO, named gpo_Name. The Wireless Network (IEEE 802.11) Policies node contains a single wireless policy, named GPfield. It is from this central location that you implement the above wireless Group Policy solution. Group Policy Object Editor for the gpo_Name GPO

You can use the Wireless Network Policies Extension to configure Active Directory-based Group Policy configurations for client computers. Specifically, the Wireless Network Policies Extension enables you to:

Make wireless network Group Policy settings to protect a wireless network from unauthorized access by client computers with a compatible WLAN adapter. Protect data transferred over the wireless network, based on Group Policy settings. Make wireless network Group Policy settings to implement either certificate-based or password-based authentication for client computers accessing the wireless network. Configure Group Policy to add User authentication to computer authentication, ensuring round-the-clock network availability.

This Group Policy affects wireless client interaction between wireless Access Points (AP), the RADIUS server, and other wireless networks.