Professional Documents
Culture Documents
Updated: March 28, 2003 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
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.
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
Sysvol
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
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 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.
WMI
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.
What Is Core Group Policy? How Core Group Policy Works Core Group Policy Tools and Settings
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.
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.
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.
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.
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.
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.
The following table describes the components that interact with the Group Policy engine.
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.
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.
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
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
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.
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.
3. 4. 5.
6.
7.
8.
9.
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.
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:
Knowing the common names of the default GPOs will help you distinguish them from non-default GPOs.
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.
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.
[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.
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
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.
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).
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.
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.
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
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.
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.
Default Setting On (and cannot be turned off) On (and cannot be turned off)
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.
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
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
Administrative Templates (Registry-based policy) Internet Explorer Maintenance Software Installation Folder Redirection Scripts Security IP Security EFS recovery Disk Quotas
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
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
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.
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 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.
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.
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 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.
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
PackageRegistration objects
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
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.
What Is Administrative Templates Extension? How Administrative Templates Extension Works Administrative Templates Extension Tools and Settings
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 In this section
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.
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_ 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.
Administrative Templates Extension Physical Structure Administrative Templates Extension Processes and Interactions Network Ports Used by Administrative Templates Extension Related Information
Components and protocols significant to Administrative Templates Extension are included in the following table. Administrative Templates Components
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.
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
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
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
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
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 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}
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.
Service Name
UDP
TCP
n/a n/a
389 445
Related Information
The following contains additional information that is relevant to 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.
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:
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.
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.
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:
For more information about these WMI classes, see the WMI SDK documentation on MSDN.
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
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
What Is Group Policy Software Installation Extension? How Group Policy Software Installation Extension Works Group Policy Software Installation Extension Tools and Settings
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.
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.
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
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
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
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.
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.
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.
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.
Component or Tool
General Description
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
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.
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.
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:
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:
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.
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.
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 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.
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
Advertisement Support
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.
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
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.
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
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.
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\
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
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
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.
What Is Security Settings Extension? How Security Settings Extension Works Security Settings Extension Tools and Settings
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.
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.
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.
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.
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.
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
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.
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:
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.
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.
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.
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.
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
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:
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 /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 /configure
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 /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
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.
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 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
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.
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
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.
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.
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.
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.
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.
The following table describes the IPSec policy-related components. IPSec Policy-Related Components and Descriptions
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
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
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.
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
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
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.
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.
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
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.
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.
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.
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.
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:
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.
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.
What Are Software Restriction Policies? How Software Restriction Policies Work Software Restriction Policies Tools and Settings
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.
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.
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.
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 (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.
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.
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.
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
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.
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.
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:
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 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):
Zone Rule A rule can identify software from the Internet Explorer zone from which it is downloaded. These zones are:
Internet Intranet
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 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:
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:
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:
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.
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.
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.
{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.
{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.
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 Group Policy Software Installation Extension Works in the Group Policy Collection.
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.
Allows the specified software to run on the computer with the full rights of the currently logged on user.
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
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
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
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.
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.
Scripts Extension Architecture Scripts Extension Protocols Scripts Extension Physical Structure Scripts Extension Processes and Interactions Network Ports Used by Scripts Extension
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
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.
Protocol Win32 NTLM or Kerberos Server Message Block (SMB) Distributed Component Object Model (DCOM)
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.
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
HKEY_LOCAL_MACHINE\Software\Policies\Windows\System\Scripts HKEY_COMPUTER_USER\Software\Policies\Windows\System\Scripts
Shutdown
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.
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
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
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
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.
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
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
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.
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
What Is Wireless Network Policies Extension? How Wireless Network Policies Extension Works Wireless Network Policies Extension Tools and Settings
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.