Introduction

This paper is part of a series that describes Windows 2000 Group Policy. The first paper, “Introduction to Windows 2000 Group Policy,” presented an overview of Group Policy. This paper provides more detailed technical information.

Group Policy provides directory-based desktop configuration management. In Windows 2000, you use Group Policy to define configurations for groups of users and computers. With Group Policy, you can specify settings for registry-based policies, security, software installation, scripts, folder redirection, remote installation services, and Internet Explorer maintenance. The Group Policy settings that you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory™ service system containers—sites, domains, and organizational units (OUs)—you can apply these settings to the users and computers in those Active Directory containers. To create GPOs, you use the Group Policy Microsoft Management Console[1] (MMC) snap-in.

Administrative Requirements for Using Group Policy

To make use of all of its features, Group Policy requires Active Directory and Windows 2000 clients. To set Group Policy for a selected Active Directory container, you must have a Windows 2000 domain controller installed, and you must have read and write permission to access the system volume of domain controllers (Sysvol folder) and modify rights to the currently selected directory container. The system volume folder is automatically created when you install a Windows 2000 domain controller (or promote a server to domain controller).

Note: Group Policy depends on Active Directory; therefore, it is crucial to understand Active Directory and its structure. It is highly recommended that you familiarize yourself with Active Directory concepts before implementing Group Policy.
To learn about Active Directory directory services, see the Active Directory white papers at http://www.microsoft.com/windows2000/library/howitworks. Information on planning and implementing Active Directory is available in the Windows 2000 Server Resource Kit Deployment Planning Guide at http://www.microsoft.com/windows2000/library/resources/reskit/dpg/default.asp.

What this Paper Contains

This paper presents information on the following topics:

Overview of Group Policy Infrastructure and Mechanics

Delegating Group Policy

Group Policy Extension Snap-ins

Group Policy Processing

Specifying a Domain Controller for Setting Group Policy

Local Group Policy

Group Policy Loopback Support

Policy Settings for Group Policy

Group Policy and Active Directory Sites

Design Considerations for Organizational Unit Structure and Use of Group Policy Objects

IntelliMirror Features without Active Directory

Migrating Policy-Enabled Clients from Windows NT 4.0 to Windows 2000

Security Settings and User Rights

Group Policy Settings for Internet Explorer

Group Policy Storage

Windows NT 4.0, Zero Administration Kit, and Windows 2000 Namespace Comparison

Frequently Asked Questions

Overview of Group Policy Infrastructure and Mechanics

Group Policy uses a document-centric approach to creating, storing, and associating policy settings. Similar to the way in which Microsoft Word stores information in .doc files, Group Policy settings are contained in Group Policy objects (GPOs). By analogy, the Group Policy snap-in is to GPOs as Microsoft Word is to .doc files.

GPOs are associated with the following Active Directory containers: sites, domains, or OUs. The settings within the GPOs are then evaluated by the affected clients, using the hierarchical nature of the Active Directory.

To create Group Policy you use the Group Policy MMC snap-in, either as a stand-alone tool or as an extension to an Active Directory-related snap-in (such as the Active Directory Users and Computers snap-in or the Active Directory Sites and Services snap-in). The preferred method is to use the Group Policy snap-in as an extension to an Active Directory snap-in. This allows you to browse the Active Directory for the correct Active Directory container, and then define Group Policy based on the selected scope. To access Group Policy from either the Active Directory Users and Computers snap-in console or in the Active Directory Site and Services snap-in console, select the Group Policy tab from the Properties page of a site, domain, or organizational unit.

Linking Group Policy Objects to Active Directory Containers

Any site, domain, or OU may be associated with any Group Policy Object. As shorthand, we will use the acronym SDOU to mean a site, domain, or OU.

A given GPO can be associated (linked) to more than one site, domain, or OU. Conversely, a given site, domain, or OU can have multiple GPOs linked to it. In the case where multiple GPOs are linked to a particular site, domain, or OU, you can prioritize the order of precedence in which these GPOs are applied.

By linking GPOs to Active Directory sites, domains, and OUs, you can implement Group Policy settings for as broad or as narrow a portion of the organization as you want:

§ A GPO linked to a site applies to all users and computers in the site.

§ A GPO applied 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 applied to an OU applies directly to all users and computers in the OU and by inheritance to all users and computers in child OUs.

GPOs are stored on a per-domain basis, however, you can link a site, domain, or OU to a GPO in another trusted domain, although this is not recommend in general for performance reasons.

To link a GPO to a site, use the Active Directory Sites and Services snap-in. To link a GPO to a domain or OU, use the Active Directory Users and Computers snap-in. In either tool, right-click the site, domain, or OU to which you want to link the GPO, and select Properties. Then select the Group Policy tab, which you use to create, edit, and manage GPOs.

The following illustration shows the Group Policy model of linking sites, domains, and OUs to Group Policy objects.

Figure 1. Linking Active Directory containers to Group Policy Objects

Group Policy Hierarchy

By default, Group Policy is inherited and cumulative, and it affects all computers and users in an Active Directory container. Group Policy objects are processed according to the following order:

1. The local Group Policy object (LPGO) is applied (See Local Group Policy section for details).

2. GPOs linked to sites.

3. GPOs linked to domains

4. GPOs linked to organizational units (OUs). In the case of nested OUs, GPOs associated with parent OUs are processed prior to GPOs associated with child OUs.

This order of GPO processing – local, site, domain, OU – is significant because policy applied later overwrites policy applied earlier.

No Override and Block Inheritance Policy Options

You can enforce the Group Policy settings in a specific Group Policy object by using the No Override option so that GPOs in lower-level Active Directory containers are prevented from overriding that policy. For example, if you have defined a specific GPO at the domain level and specified the No Override option, the policies that the GPO contains apply to all OUs under that domain; that is, the lower-level containers (OUs) cannot override that domain Group Policy.

You can also block inheritance of Group Policy from parent Active Directory containers by using the Block policy inheritance option. For example, if you specify the Block policy inheritance option for an OU, this prevents policy in higher-level Active Directory containers (such as a higher-level OU or domain) from applying. However, No Override policy options always take precedence.

Figure 1 below shows a sample domain structure to illustrate how Group Policy objects can be applied to containers in the Active Directory.

Figure 2. Group Policy and the Active Directory

Using Security Groups to Filter the Scope of the Group Policy Object

You can further refine which groups of computers and users a particular GPO influences by using Windows 2000 security groups. To do this, you use the Security property page of a given GPO to set access permissions (discretionary access control lists[2], or DACLs) to allow or deny access to the GPO by specified groups.

You can view and modify the security settings from the Security tab on the Properties page of the specific GPO. The Security tab is accessible by right-clicking the root node in the Group Policy snap-in, clicking Properties, and then Security. Or from the Properties page of a given site domain, or OU, select the Group Policy tab, right-click the appropriate Group Policy object in the GPO list, select Properties, and then click Security.

By default, a GPO affects all users and computers that are contained in the linked site, domain, or OU. By changing the Access Control Entries (ACEs) within the DACL, the effect of any GPO can be modified to exclude or include the members of any security group.

Both Read and Allow Group Policy ACEs are required for a GPO to apply to a group. By default, authenticated users have both Apply Group Policy and Read ACE permissions set to Allow. Everyone in the organization is automatically an Authenticated User. Therefore, the default behavior is for every Group Policy object to apply to every Authenticated User. By default, domain administrators, enterprise administrators, and the local system have full control permissions, without the Apply Group Policy ACE. However, administrators are members of Authenticated Users, which means that they will receive the settings in the GPO by default.

To prevent GPO policy from applying to a specified group requires removal of the Apply Group Policy ACE from that group. If you remove the Apply Group Policy ACE (clear the Allow checkbox) for Authenticated Users, you can then explicitly grant this permission to individual security groups that should receive the policy settings. Alternatively, you could set Apply Group Policy to Deny for certain classes of users, such as administrators, that will never need that policy.

Note: Use the Deny ACE with caution. A Deny ACE setting for any group has precedence over any Allow ACE given to a user or computer because of membership in another group.

Best Practice: If you disallow Apply Group Policy for a GPO for some users, consider also disallowing Read access to those users. When the Read ACE is allowed and the Apply Group Policy is not, the GPO is still processed by the user even though it is not applied to the user. Therefore, to improve performance, you should remove the Read Access Control Entry to prevent the user from processing the GPO. In addition, removing Read access increases security. With Read access allowed, it is possible for an inquisitive user with considerable knowledge of the Active Directory to read the contents of that GPO, even if it’s not applied to them. This may not be desirable in some cases, for example, a GPO for the Human Resources (HR) group. It might be advisable to limit Read access on GPOs that affect the HR users to only those users.

Security groups and DACLs are also used to delegate control of Group Policy objects, as explained in Delegating Group Policy.

MMC Snap-in Extension Model

The nodes of the Group Policy MMC snap-in are themselves MMC snap-in extensions. These extensions include Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, and Internet Explorer maintenance. Extension 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 extensions to the Group Policy snap-in to provide additional policies.

For more information on creating MMC extensions, see the Microsoft Management Console section of the Microsoft Platform SDK documentation at: http://msdn.microsoft.com/developer/sdk/platform.htm .

By default, all the available Group Policy snap-in extensions are loaded when you start the Group Policy snap-in. You can modify this default behavior by creating a custom MMC console, or by using policy settings to control the behavior of MMC itself. The MMC options are accessed under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node. To find out more, see Specifying Group Policy to Control the Behavior of MMC and Snap-ins, later in this document.

For further information on the Microsoft Management Console, see the "Microsoft Management Console: Overview" white paper at http://www.microsoft.com/windows2000/library/howitworks/management/mmcover.asp and the "Step-by-Step Guide to the Microsoft Management Console" at http://www.microsoft.com/windows2000/library/planning/mamagement/mmcsteps.asp, both of which are available on the Windows 2000 Web site, www.microsoft.com/windows 2000.

Group Policy Snap-in Namespace

The root node of the Group Policy snap-in is displayed as the name of the GPO and the domain to which it belongs, in the following format:

GPO Name [DomainName.com] Policy

For example:

Default Domain Policy [HQ-RES-DC-01.reskit.com] Policy

Computer Configuration and User Configuration

Below the root node, the namespace is divided into two parent nodes: Computer Configuration and User Configuration. These are the parent folders that you use to configure Group Policy settings. Computer-related Group Policy is applied when the operating system boots and during the periodic refresh cycle, explained later in this document. User-related Group Policy is applied when users log on to the computer and during the periodic refresh cycle.

Extensions to the Group Policy Snap-in

Three nodes exist under the Computer Configuration and User Configuration parent nodes: Software Settings, Windows Settings, and Administrative Templates. The Software Settings and Windows Settings nodes contain extension snap-ins that extend either or both of the Computer Configuration or User Configuration nodes. Most of the extension snap-ins extend both of these nodes, but frequently with different options. The Administrative Templates node namespace contains all policy settings pertaining to the registry; it can be extended by using administrative template (.adm) files.

The Group Policy extension snap-ins include:

· Administrative Templates. This extension contains all registry-based policy settings, including those for the Windows 2000 operating system and its components, and any registry-based policy settings provided by applications. You use these policies to mandate registry settings that control the behavior and appearance of the desktop, the operating system components, and applications that provide registry-based policy. This node uses administrative template (.adm) files to specify the registry settings that can be modified through the Group Policy snap-in user interface. For more information on .adm files, see Administrative Templates later in this paper.

· Security Settings. The Security Settings extension is used to set security options for computers and users within the scope of a Group Policy object. You can define local computer, domain, and network security settings. For more information on security settings, see Security Settings and Appendix E: Security Settings, later in this paper, and the security white papers available on the Windows 2000 Server Web site at http://www.microsoft.com/windows2000/library/technologies/security/default.asp.

· Software Installation. You can use the Software Installation snap-in to centrally manage software in your organization. You can assign and publish software to users and assign software to computers. For detailed information on software installation, see Software Installation, later in this document, and the "Software Installation and Maintenance" white paper at http://www.microsoft.com/windows2000/library/operations/management/siamwp.asp.

· Scripts. Scripts are used to automate tasks at computer startup and shutdown, and at user logon and logoff. You can use any language supported by Windows Scripting Host. These include the Microsoft Visual Basic® development system, Scripting Edition (VBScript), JavaScript, PERL, and MS‑DOS®-style batch files (.bat and .cmd). See Scripts, later in this document, and the Microsoft Scripting Technologies website at http://msdn.microsoft.com/scripting/default.htm for more information.

· Remote Installation Services. Remote Installation Services (RIS) is used to control the behavior of the Remote Operating System Installation feature as displayed to client computers. See Remote Installation Services, later in this document, and the "Remote Operating System Installation" white paper at http://www.microsoft.com/windows2000/library/planning/management/remoteos.asp.

· Internet Explorer Maintenance. Internet Explorer Maintenance is used to manage and customize Internet Explorer on Windows 2000-based computers. You can also export settings for Windows 95, Windows 98, and Windows NT 4.0 clients (the settings are exported into an .ins and .cab file format for those platforms). Administrators can set options for Browser UI, connections, URLs, proxy settings, security zones, and Favorites and Channels. See Internet Explorer Maintenance, later in this document, and the MS Internet Explorer 5.0 Resource Kit Tools and Utilities at http://www.microsoft.com/TechNet/IE/reskit/ie5/tools.asp.

· Folder Redirection. You can use Folder Redirection to redirect Windows 2000 special folders 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. See Folder Redirection, later in this document, and the "User Data and Settings Management" white paper at http://www.microsoft.com/windows2000/library/operations/management/settings.asp.

Information on extending the functionality of the Group Policy snap-in can be found in a white paper called “Implementing Registry-Based Group Policy for Applications,” which is being posted at http://www.microsoft.com/windows2000/library/howitworks/default.asp

Figure 3 below shows the Group Policy snap-in.

Figure 3. The Group Policy snap-in console

Client-side Extensions to Group Policy

Some of the Group Policy snap-in extensions also include client-side extensions. These extensions are dynamic-link libraries (DLLs) that are responsible for implementing Group Policy at the client computers.

For more information on the client-side extensions, see the Client-side Processing of Group Policy section later in this paper.

Group Policy Storage

A Group Policy object is a virtual object. The policy setting information of a GPO is actually stored in two locations: the Group Policy Container (GPC) and the Group Policy Template (GPT). The GPC is an Active Directory container that stores GPO properties, including information on version, GPO status, and a list of components that have settings in the GPO. The GPT is a folder structure within the file system that stores Administrative Template-based policies, security settings, script files, and information regarding applications that are available for Software Installation. The GPT is located in the system volume folder (Sysvol) in the \Policies sub-folder for its domain.

It is possible to store data related to policy information outside the GPO. However, this requires that at least a link to the data be stored either in the GPC or the GPT. This is not recommended because it could complicate back up and restore procedures. In addition, the information outside the GPO may not be deleted if you delete the GPO, whereas Windows 2000 will automatically delete the information from the GPC and GPT.

Replication of a GPO to other domain controllers happens through two different mechanisms. The GPC is replicated by using Active Directory replication, whereas the GPT is replicated using File Replication Service (FRS). The settings from a GPO are only applied when the GPC and GPT are synchronized. GPOs are identified by their globally unique identifiers (GUIDs) and stored at the domain level.

The following illustration shows the interaction between the Group Policy snap-in, a GPO, and the storage location of the data contained in the GPO.

Figure 4. Group Policy and storage

For additional information on storage of Group Policy information, see Appendix C: Group Policy Storage, later in this paper.

Delegating Group Policy

One of the features of the Active Directory is its ability to delegate control of portions of the directory service. This section explains how Group Policy fits in with the delegation of sites, domains, and organizational units.

The delegation of Group Policy consists of the following 4 aspects, which can be used together or separately, as a particular situation requires:

§ Managing Group Policy links for a site, domain, or OU

§ Editing Group Policy Objects

§ Creating Group Policy Objects

§ Specifying Group Policy to Control the Behavior of MMC extensions

The underlying mechanism for achieving delegation using the first three methods is the application of the appropriate DACLs to Group Policy objects and other objects in the Active Directory. This mechanism is identical to using security groups to filter the application of Group Policy objects to various users, as described earlier in this paper.

The fourth method of delegation relies on several policy settings within the Group Policy infrastructure that are designed to control the behavior of the MMC and 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.

Using Security Groups to Delegate Group Policy

The following table lists the default security-permission settings for a Group Policy object:

Groups or Users

Security permission

Authenticated User

Read with Apply Group Policy ACE

Domain Administrators

Enterprise Administrators

Creator Owner

Local System

Full control without Apply Group Policy ACE.

Note: By default, administrators are also authenticated users, which means that they have the Apply Group Policy attribute set. If this is not desired, administrators have two choices:

§ Remove Authenticated Users from the list on the security tab of the GPO, and add a new security group with the Apply Group Policy and Read attributes set to Allow. This new group should contain all the users that this Group Policy is intended to affect.

§ Set the Apply Group Policy attribute to Deny for the Domain and Enterprise Administrators, and possibly the Creator Owner groups. This will prevent the GPO from being applied to members of those groups. Remember that an ACE set to Deny always takes precedence over Allow. Therefore, if a given user is a member of another group that is set to explicitly Allow the Apply Group Policy attribute for this GPO, it will still be denied.

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

The Group Policy tab in the Properties page for a site, domain, or OU allows the administrator to specify which Group Policy objects are linked to this site, domain, or OU. This property page stores the user’s choices in two Active Directory properties called gPLink and gPOptions. The gPLink property contains the prioritized list of Group Policy objects and the gPOptions property contains the Block Policy Inheritance setting.

To manage GPO links to a site, domain, or OU, you must have read and write access to the gPLink and gPOptions properties. By default, domain administrators have this permission for domains and OUs, and only Enterprise Administrators and Domain Administrators of the forest root domain can manage links to sites.

The Active Directory supports security settings on a per-property basis. This means that a non-administrator can be given read and write access to specific properties. In this case, if non-administrators have read and write access to the gPLink and gPOptions properties, they can manage the list of GPOs linked to that site, domain, or OU. To give a user Read and Write access to these properties, use the Delegation Wizard and select the Manage Group Policy links predefined task.

Example 1

In this example, control of an organizational unit is delegated to a non-administrative user so that a user or group of users can select from existing Group Policy Objects and apply them to users, but not create new Group Policy Objects.

1. In the Active Directory Users and Computers snap-in, right-click the Organizational Unit that you want to delegate, and select Delegate Control.

2. In the Delegate Control Wizard, press Next to go past the introduction page.
You will be asked to confirm the OU that you want to delegate.

3. Press Next.
You will be prompted for the names of the users and groups to which you want to delegate control.

4. Select a previously defined user or group, and press Next.

5. In the list of Predefined Tasks, select Manage Group Policy links, and press Next.

6. Press Finish to complete the changes.

The user or the members of the group that you selected in step 4 will be able to change the list of Group Policy links for the OU selected in step 1.

Creating Group Policy Objects

By default, only domain administrators, enterprise administrators, Group Policy Creator Owners, and the operating system can create new Group Policy objects. If the domain administrator wants a non-administrator or group to be able to create GPOs, that user or group can be added to the Group Policy Creator Owners security group. When a non-administrator who is a member of the Group Policy Creator Owners group creates a GPO, that user becomes the creator and owner of the GPO; therefore, the user can edit the GPO. Being a member of the Group Policy Creator Owners group gives the non-administrator full control of only those GPOs that the user creates or those explicitly delegated to that user; it does not give the non-administrator any additional rights over other GPOs for the domain—these users are not granted rights over GPOs they didn’t create.

Note that when an administrator creates a GPO, the Domain Administrators group becomes the Creator Owner of the Group Policy Object.

When delegating to non-administrators, you should also consider delegating the ability to manage the links for a specific OU. The reason is that by default, non-administrators cannot manage links, and this will prevent them from being able to use the Active Directory Users and Computers snap-in to even create a Group Policy object. There is a work-around whereby these users can create a custom MMC console, and they can create a GPO when they select the All tab.

Example 2

In this example, control of an organizational unit is delegated to a non-administrator user so that the user or group of users can select from existing Group Policy objects and also create new Group Policy objects.

1. First, complete all the steps in Example 1 above.

2. To allow for creation of new Group Policy objects, you need to add the user or group of users to the Group Policy Creator Owners group. In the Active Directory Users and Computers tools, navigate to the Users container in the root of the domain.

3. Double-click Group Policy Creator Owners.

4. In the Properties page, select the Members tab.

5. Press Add, and add the group of users (or user) selected above to the security group.

The user or group of users will be able to create new Group Policy objects. The user who creates each object becomes the Creator Owner of that GPO.

Editing Group Policy Objects

To edit a GPO, the user must have both read and write access to the GPO. For the current release of the product, read-only support for opening a GPO is not provided. To edit a GPO, the user must be one of the following:

§ An administrator.

§ A Creator Owner.

§ A user with delegated access to the GPO. That is, an administrator, or the Creator Owner, must have provided to this user both read and write access to the GPO by using the Security tab in the GPO Properties page.

By default, Domain Administrators, Enterprise Administrators, the operating system, and the GPO Creator Owner can edit GPOs because they have full control of GPOs without the Apply Group Policy attribute.

Example 3

In this example, control of a Group Policy object is delegated to a non-administrator user or group of users.

1. Open a Group Policy object in the Group Policy snap-in.

2. Right-click on the root node, select Properties, and click Security.

3. Press Add to add the user or group of users, and give them read and write access. At this point, decide whether the users should also have the policy applied to them or just be able to edit it. If they do not need the policy applied to them, clear the Apply Group Policy option.

4. Press OK to save the changes.

The user or group of users () will be able to edit the Group Policy object.

Specifying Group Policy to Control the Behavior of MMC extensions

Windows 2000 Group Policy includes several policy settings designed to control the behavior of MMC snap-ins. For example, you can use Group Policy to manage the rights to use MMC snap-ins.

Restricting Access to a List of Permitted Snap-ins

Administrators can specify which MMC snap-ins may be run by the affected user and which may not. This may be specified to be inclusive, which only allows a set of snap-ins to run, or it may be set as exclusive, which does not allow a set of snap-ins to run.

To create a list of permitted snap-ins for users, enable the Restrict users to the explicitly permitted list of snap-ins policy. When this policy is enabled, only permitted snap-ins can be run. If this policy is disabled or not configured, all snap-ins are permitted, except those you explicitly prohibit.

This policy is available in the Group Policy console under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node. For more information on this policy setting, double-click the policy in the details pane, and click the Explain tab.

Controlling Access to a Snap-in

To restrict or explicitly permit access to a particular snap-in, navigate to User Configuration\Administrative Templates\Windows Components\Microsoft Management Console\Restricted/Permitted snap-ins\Group Policy in the console tree. In the details pane, double-click the snap-in that you want to permit or restrict, and then select an option. For more information on these policy settings, double-click the desired policy in the details pane, and click the Explain tab, as shown in Figure 5, below.

Figure 5. Controlling access to a snap-in

Preventing Use of MMC in Author Mode

Administrators can enable the Restrict the user from entering author mode policy in order to prevent users from using MMC in author mode. This policy is available in the Group Policy console under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node.

For more information on these policy settings, double-click the policy in the details pane, and then click the Explain tab in the policy Properties dialog box.

Creating Custom Group Policy Snap-in Consoles

You can create custom Group Policy MMC consoles (.msc files), which include only a subset of the Group Policy snap-in extensions. You can combine this with the use of the policy settings above to provide a customized tool. For example, you could create a custom Group Policy console that includes only the Security Settings extension. This allows you to define Group Policy settings in a modular fashion.

To start Group Policy as a stand-alone snap-in

1. Click Start, click Run, type MMC, and then press Enter.

2. In the MMC window, on the Console menu, click Add/Remove Snap-in.

3. On the Standalone tab, click Add.

4. In the Add Standalone Snap-in dialog box, click Group Policy, and then click Add.

5. In the Select Group Policy Object dialog box, click Browse to find the GPO you want to manage, and then click OK.

6. Click Finish in the Select Group Policy Object dialog box, and then click Close in the Add Standalone Snap-in dialog box.

7. Select the Extensions tab, and select the extension snap-ins you want to use.

8. Click OK. The Group Policy snap-in opens with focus on the GPO you specified.

9. After you specify the policies you want to use, click Save As on the Console menu to save your settings (in a .msc file).

To set access permissions, use the Security tab on the Properties page of the selected GPO. These permissions allow or deny specified groups access to the GPO.

Group Policy Extension Snap-ins

The Group Policy extension snap-ins constitute the main nodes in the Group Policy snap-in namespace; they are all loaded by default when the Group Policy snap-in is started. You can modify which extensions are loaded by creating custom consoles for Group Policy, and by specifying policy settings for MMC. For more information, see Creating Custom Group Policy Snap-in Consoles and Specifying Group Policy to Control the Behavior of MMC and Snap-ins in this document.

This section presents additional information on the following topics:

§ Administrative Templates

§ Security Settings

§ Software Installation

§ Scripts (Startup/Shutdown and Logon/Logoff)

§ Folder Redirection

§ Internet Explorer Maintenance

§ Remote Installation Services

Administrative Templates

In Windows NT 4.0, the System Policy Editor uses files called administrative templates (.adm files) to determine which registry settings can be modified. These files define which settings are displayed by the System Policy Editor user interface.

In Windows 2000, the Administrative Templates node of the Group Policy snap-in uses administrative template (.adm) files to specify the registry settings that can be modified through the Group Policy snap-in user interface.

The Administrative Templates node includes all registry-based Group Policy information. This includes Group Policy for the Windows 2000 operating system and its components and for applications. Policy settings pertaining to a user who logs on to a given workstation or server are written to the User portion of the registry database under HKEY_CURRENT_USER (HKCU). Computer-specific settings are written to the Local Machine portion of the registry under HKEY_LOCAL_MACHINE (HKLM).

The .Adm File

.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 snap-in UI. 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. Windows 2000 includes three .adm files, System.adm, Inetres.adm, and Conf.adm, which contain all the settings initially displayed in the Administrative Templates node. It also includes .adm files for use with the Windows NT 4.0 System Policy Editor tool, as noted in the following table.

.Adm file	Use	Description
System.adm	Windows 2000	Loaded by default.
Inetres.adm	Windows 2000	Loaded by default.
Conf.adm	Windows 2000	Loaded by default.
Winnt.adm	Windows NT 4.0	Use with System Policy Editor, Poledit.exe.
Common.adm	Windows NT 4.0, Window 95, and Windows 98	Use with System Policy Editor, Poledit.exe.
Windows.adm	Window 95 and Windows 98	Use with System Policy Editor, Poledit.exe.

Distinguishing True Policies from Group Policy Preferences

In Windows 2000, all shipping policies set registry keys and values in either the \Software\Policies (the preferred location for all new policies) or \Software\Microsoft\Windows\CurrentVersion\Policies trees, in either HKCU or HKLM.

Policy settings that are stored in these specific locations of the registry are known as true policies. Storing settings here has the following advantages:

· These trees are secure and cannot be modified by a non-administrator.

· When Group Policy changes, for any reason, these trees are cleaned, and the new policies are then rewritten.

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 above and are known as preferences.

All the policy settings in the System.adm, Inetres.adm, and Conf.adm files use registry settings in the Policies trees of the registry. 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, only true policies are displayed in the Group Policy snap-in. The following .adm files are loaded:

§ System.adm: contains operating system settings

§ Inetres.adm: contains Internet Explorer restrictions

§ Conf.adm: contains NetMeeting settings

Note: Because of the persistent nature of non-policy settings, they should be avoided.
It is still possible for administrators to add an additional .adm file that sets registry values outside of the Windows 2000 Group Policy trees mentioned previously. These settings might be more appropriately referred to as preferences because the user, application, or other parts of the system can also change them. In this case, the administrator is ensuring that this registry key or value is set in a particular way. Although it is possible to add any .adm file to the namespace, if you use an .adm file from a previous version of Windows, the registry keys are unlikely to have an effect on Windows 2000, or they actually set preference settings and mark the registry with these settings; that is, the registry settings persist.

Viewing Group Policy Preferences

There is a user preference that allows preferences to be displayed in the Group Policy user interface; it is called Show Policies Only and is located in the View menu of the MMC. The ability to clear the checkbox for this setting and allow non-policy settings to be displayed may be prevented by using a policy setting located in User Configuration\Administrative Templates\System\Group Policy. If the preference (or policy) is not set to Show Policies Only, the icon for those settings is displayed in red. True policies are displayed in blue. Note that it is not possible for the selected state for this policy to persist; that is, there is no preference for this policy setting.

A Group Policy called Enforce Show Policies Only is available in User Configuration\Administrative Templates, under the System\Group Policy nodes. If you set this policy to Enabled, the Show policies only command is turned on and administrators cannot turn it off; in addition, the Group Policy snap-in displays only true policies. If you set this policy to Disabled or Not configured, the Show policies only command is turned on by default; however, you can view preferences by turning off the Show policies only command. To view preferences, you must turn off the Show policies only command, which you access by selecting the Administrative Templates node (under either the User Configuration or the Computer Configuration node), and then clicking the View menu on the Group Policy console and clearing the Show policies only check box.

In Group Policy, preferences are indicated by a red icon to distinguish them from true policies, which are indicated by a blue icon.

Use of non-policies within the Group Policy infrastructure is strongly discouraged because of the persistent registry settings behavior mentioned previously. To set registry policies on Windows NT 4.0, Windows 95, and Windows 98 clients, use the Windows NT 4.0 System Policy Editor tool, Poledit.exe.

Security Settings

You can define a security configuration within a Group Policy Object. A security configuration consists of settings applied to one or more security areas supported on Windows 2000 Professional or Windows 2000 Server. The specified security configuration is then applied to computers as part of the Group Policy application.

The Security Settings extension of the Group Policy snap-in complements existing system security tools such as the Security tab on the Properties page (of an object, file, folder, and so on), and Local Users and Groups in Computer Management. You can continue to use existing tools to change specific settings, whenever necessary.

The security areas that can be configured for computers include the following:

§ Account Policies. These are computer security settings for password policy, lockout policy, and Kerberos policy in Windows 2000 domains.

§ Local Policies. These include security settings for audit policy, user rights assignment, and security options. Local policy allows you to configure who has local or network access to the computer and whether or how local events are audited.

§ Event Log. This controls security settings for the Application, Security, and System event logs. You can access these logs using the Event Viewer.

§ Restricted Groups. Allows you to control who should and should not belong to a restricted group, as well as which groups a restricted group should belong to. This allows administrators to enforce security policies regarding sensitive groups, such as Enterprise Administrators or Payroll. For example, it may be decided that only Joe and Mary should be members of the Enterprise Administrators group. Restricted groups can be used to enforce that policy. If a third user is added to the group (for example, to accomplish some task in an emergency situation), the next time policy is enforced, that third user is automatically removed from the Enterprise Administrators group.

§ System Services. These control startup mode and security options (security descriptors) for system services such as network services, file and print services, telephone and fax services, Internet and intranet services, and so on.

§ Registry. This is used to configure security settings for registry keys including access control, audit, and ownership. When you apply security on registry keys, the Security Settings extension follows the same inheritance model as that used for all tree-structured hierarchies in Windows 2000 (such as the Active Directory and NTFS). Microsoft recommends that you use the inheritance capabilities to specify security only at top-level objects, and redefine security only for those child objects that require it. This approach greatly simplifies your security structure and reduces the administrative overhead that results from a needlessly complex access-control structure.

§ File System. This is used to configure security settings for file-system objects, including access control, audit, and ownership.

§ Public Key Policies. You use these settings to:

o Specify that computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate.

o Create and distribute a certificate trust list.

o Establish common trusted root certification authorities.

o Add encrypted data recovery agents and change the encrypted data recovery policy settings.

§ IP Security Policies on Active Directory. IP Security (IPSec) policy can be applied to the GPO of an Active Directory object. This propagates that IPSec policy to any computer accounts affected by that Group Policy object.

For more information on security settings and IPSec issues, refer to the Windows 2000 Server Online Help at http://www.microsoft.com/windows2000/support/onlinedocs/default.asp.Windows 2000 Default Security Templates

Windows 2000 includes three default security templates called Basic. These new default security settings are applied to Windows 2000 systems that have been installed onto an NTFS partition. When Windows 2000 is installed onto a FAT file system, security cannot be applied.

The following Basic security templates are used:

§ Basicwk.inf for workstations

§ Basicsv.inf for servers

§ Basicdc.inf for domain controllers

The Basic security templates specify default Windows 2000 security settings for all security areas, with the exception of User Rights and Groups. These templates can be applied to Windows 2000 systems using the Security Configuration and Analysis MMC snap-in or by using the Secedit.exe command-line tool.

Incremental Security Templates

Windows 2000 includes several incremental security templates. By default, these templates are stored in %systemroot%\Security\Templates. These predefined templates can be customized using the Security Templates MMC snap-in and can be imported into the Security Settings extension of the Group Policy snap-in.

These security templates were constructed based on the assumption that they would be applied to Windows 2000 computers that are configured with the new Windows 2000 default security settings. In other words, these templates incrementally modify the default security settings. They do not include the default security settings plus the modifications.

The following table lists the incremental security templates included in Windows 2000.

Security Configuration	Computer	Templates	Description
Compatible	Workstation, and server	Compatws.inf	For customers who do not want their users to run as Power Users (by default all users are Power Users on Windows 2000 professional), the Compatible configuration opens up the default permissions for the Users group so that legacy applications are more likely to run. Office 97 should run successfully when users are logged on as a User to a Windows 2000 computer that has had the Compatible security template applied over the default settings. Note that this is not considered a secure environment.
Secure	Workstation, server, and domain controller	Securews.inf and Securedc.inf	The Secure configuration provides increased security for areas of the operating system that are not covered by permissions. This includes increased security settings for Account Policy, Auditing, and some well-known security-relevant registry keys. Access control lists are not modified by the secure configurations because the secure configurations assume that default Windows 2000 security settings are in effect.
Highly Secure	Workstation, server, and domain controller	Hisecws.inf and Hisecdc.inf	The Highly Secure configuration is provided for Windows 2000 computers that operate in native (or pure) Windows 2000 environments only. In this configuration, it is required that all network communications be digitally signed and encrypted at a level that can only be provided by Windows 2000. Thus, a Windows 2000 highly secure computer cannot communicate with a Windows 95, Windows 98, or Windows NT client.

Security Levels

The following table describes the relative levels of security that can be associated with the operating system, based on the templates that have been applied and the type of user accessing the system. No inference should be made with respect to the security of applications running in this environment. The items are listed in the table in order of increasing security level.

Templates applied	User level
Default	Power User
Default + Compatible	User
Default	User
Default + Secure	User
Default + Secure + Highly Secure	User

Thus, logging in as a Power User to a Windows 2000 system that has been installed onto an NTFS system can be less secure than logging into that same system as a User.

For more information on security settings, see the "Step-by-Step Guide to Configuring Enterprise Security Policies" at http://www.microsoft.com/windows2000/library/planning/security/entsecsteps.asp, and the "Step-by-Step Guide to Internet Protocol Security (IPSec)" at http://www.microsoft.com/windows2000/lirary.planning/security/ipsecsteps.asp.For information on the default security settings contained in the Default Domain Policy GPO and Default Domain Controller Policy GPO, see Appendix A: Security Settings and User Rights later in this paper.

Software Installation

You use the Software Installation snap-in to centrally manage software distribution in your organization. You can assign and publish software for groups of users and computers.

You assign applications to groups of users so that all users who require the applications automatically have the application on their desktops—without requiring the administrator or technical personnel to set up the application on each desktop. When you assign an application to a group of users, you are actually advertising the application on all the users’ desktops. The next time a user logs on to Microsoft Windows 2000, the application is advertised. This means that the application shortcut appears on the Start menu, and the registry is updated with information about the application, including the location of the application package and the location of the source files for the installation. With this advertisement information on the user’s computer, the application is installed the first time the user activates the application.

When the user selects the application from the Start menu the first time, it sets up automatically, and then opens.

You can also publish applications to groups of users, making the application available for users to install should they choose to do so. When you publish an application, no shortcuts to the application appear on users’ desktops, and no local registry entries are made. That is, the application has no presence on the user’s desktop. Published applications store their advertisement information in the Active Directory.

To install a published application, users can use the Add/Remove Programs in Control Panel, which includes a list of all published applications that are available for them to use. Alternatively, if the administrator has configured this feature, users can open a document file associated with a published application (for example, an .xls file to install Microsoft Excel).

For more information, see the "Software Installation and Maintenance" white paper at http://www.microsoft.com/windows2000/library/operations/management/siamwp.asp and the Step-by-Step Guide to Software Installation and Maintenance at http://www.microsoft.com/windows2000/library/planning/management/swinstall.asp.

Scripts

With the Scripts extensions, you can assign scripts to run when the computer starts or shuts down or when users log on or off their computers. For this purpose, you can use Windows Scripting Host to include both Visual Basic® Scripting Edition (VBScript) and Jscript® development software script types.

Windows 2000 includes Windows Scripting Host, a language-independent scripting host for 32-bit Windows platforms. Microsoft anticipates that other software companies will provide ActiveX® scripting engines for other languages, such as Perl, TCL, REXX, and Python.

For more information about Windows Scripting Host, see http://www.microsoft.com/scripting.

The names of scripts and their command lines (in the form of registry keys and values) are stored in the Registry.pol file, described later in this document.

Types of Scripts

The five script types are as follows:

· Group Policy logon scripts.

· Group Policy logoff scripts.

· Group Policy startup scripts.

· Group Policy shutdown scripts.

· Legacy logon scripts (those specified on the User object). This includes support for Windows Scripting Host[3] scripts. Windows Script Host supports scripts written in VBScript or JavaScript. This means that you can now enter a command line like sample.vbs in the logon script path of the user object.

Note: Consider carefully how to use such scripts if you have a mixed environment that includes Windows NT 4.0, Windows 95, Windows 98, and Windows 2000 clients. The Windows 2000 and the Windows 98 clients will properly run .vbs and .js scripts. To run .vbs and .js scripts on Windows NT 4.0 and Windows 95 clients, you must embed the scripts in batch (.bat) files. The scripts continue to run in a normal window. There is a policy that allows for scripts to be run as hidden or minimized. You can also install Windows Scripting Host on Windows NT 4.0 and Windows 95 clients. For information on Windows Scripting Host, see http://msdn.microsoft.com/scripting/windowshost/default.htm.

By default, each of these script types runs asynchronously, and the window is hidden. User logon and logoff scripts run as the user (not administrator), and computer logon and logoff scripts run as local system.

Specifying Policy Settings for Script Behavior

The following table lists the Group Policy options that are available to control the behavior of scripts.

Policy in Computer Configuration\Administrative Templates\System\Logon	Description
Run logon scripts synchronously	When this option is enabled, the system waits until the script finishes running before it starts Windows Explorer. Note that an equivalent option for this is available under the User Configuration node. The policy setting you specify in the Computer Configuration node has precedence over that set in the User Configuration node.
Run startup scripts asynchronously	By default, startup scripts run synchronously and hidden, which means the user cannot logon until the scripts complete. In some corporations, the administrator might want the scripts to run asynchronously since they could take a long time to complete. This policy allows the administrator to change the default behavior.
Run startup scripts visible	If this option is enabled, startup scripts run in a command window.
Run shutdown scripts visible	If this option is enabled, shutdown scripts run in a command window.
Maximum wait time for Group Policy scripts	This policy setting lets you change the default script timeout period. (By default, scripts will timeout after 600 seconds). The range is 0 to 32000 seconds.

Policy in User Configuration\Administrative Templates\System\Logon/Logoff
Run logon scripts synchronously	When you enable this option, Windows waits for the scripts to finish running before it starts Windows Explorer. Note that an equivalent option for this is available under the Computer Configuration node. The policy setting you specify in the Computer Configuration node has precedence over that set in the User Configuration node.
Run legacy logon scripts hidden	If this option is enabled, legacy logon scripts will run in hidden mode.
Run logon scripts visible	If this option is enabled, logon scripts run in a command window.
Run logoff scripts visible	If this option is enabled, logoff scripts run in a command window.

Note: Scripts that run hidden (and to a lesser degree minimized) can cause an errant script or one that prompts for user input to wait for 600 seconds. This is the default wait-time value and may be changed using a Group Policy. During this time, the system appears to be hung up. In the case of a script running in a minimized window, if the user selects the window, its processing can be stopped.

Best Practice: For easier manageability, it is a good idea to use Group Policy scripts and to avoid using per-user scripts, if at all possible. Rather than using a single monolithic script with lots of internal logic branching, Group Policy-based logon scripts allow for use of tiered and modular scripts targeted to the desired set of users.

Folder Redirection

The Folder Redirection extension is used to redirect any of the following special folders in a user profile to an alternate location (such as a network share):

§ Application Data

§ Desktop

§ My Documents

o My Pictures

§ Start Menu

For example, you could redirect a user’s My Documents folder to \\Server\Share\%username%. By redirecting the My Documents folder, you can provide the following advantages:

§ Ensure that users’ documents are available when they roam from one computer to another.

§ Reduce the time it takes to log on to and log off from the network. In Windows NT 4.0, the My Documents folder is part of the Roaming User Profile (RUP). This means that the My Documents folder and its contents are copied back and forth between the client computer and the server when users log on and log off. Relocating the My Documents folder outside of the user profile can significantly decrease that time.

§ Store user data on the network (rather than on the local computer). The data can then be managed and protected by the Information Technology department.

§ Make users’ network-based My Documents folder available to users when they are disconnected from the corporate network by using Offline Folder technologies.

More information on Folder Redirection will be available in a white paper called “User Data and Settings Management” at