Windows 2000 Group Policy Technical Paper

Operating System

Windows 2000 Group Policy

Technical Paper

Abstract

This paper describes Group Policy, one of the key change and configuration management technologies provided in the Microsoft ® Windows ® 2000 operating system. Administrators use Group

Policy to specify options for managed desktop configurations for groups of computers and users.

Group Policy includes options for registry-based policy settings, security settings, software installation, scripts, and folder redirection.

This paper is intended for information technology managers and system administrators who are interested in using Group Policy to manage users’ desktop environments.

Note This paper documents Windows 2000 Server Beta 3 functionality.

Version 2.0 (May 1999)

© 1999 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft

Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

Note that this paper documents Windows 2000 Server Beta 3 functionality.

This white paper is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, Active Directory, IntelliMirror, JScript, Visual Basic, Visual C++, Win32,

Windows, theWindows logo, and Windows NT are either trademarks or registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

0599

CONTENTS

INTRODUCTION .......................................................................... 1

GROUP POLICY INFRASTRUCTURE AND MECHANICS ............. 3

Administrative Requirements for Using Group Policy 4

MMC Snap-in Extension Model

Group Policy Snap-in Namespace

4

5

Creating Custom Group Policy Snap-in Consoles

Multiple Group Policy Objects

14

16

SPECIFYING A DOMAIN CONTROLLER FOR SETTING GROUP

POLICY ...................................................................................... 17

Specifying Policy for Domain Controller Options

Error Handling on Failure to Reach a Domain Controller

DC Selection Results

18

18

19

GROUP POLICY HIERARCHY .................................................... 20

Enforce and Block Policy Options 20

USING SECURITY GROUPS TO FILTER AND DELEGATE GROUP

POLICY ...................................................................................... 21

Filtering the Scope of the Group Policy Object

Delegating Control of Group Policy

Creating Group Policy MMC Consoles to Delegate Group Policy

21

22

27

GROUP POLICY PROCESSING .................................................. 28

Synchronous and Asynchronous Processing 28

Periodic Refresh Processing

Group Policy and Network Connections (Slow Links)

29

29

Registry Reads

Other Processing

Group Policy Snap-in and the Operations Master

Client-side Processing of Group Policy

30

31

31

31

USING GROUP POLICY ON STAND-ALONE COMPUTERS ....... 34

Local Group Policy Object 34

Starting the Group Policy Snap-in on Windows 2000 Professional

Using the Group Policy Snap-in Focused on a Remote Computer

Local Group Policy Object Processing

34

35

36

GROUP POLICY LOOPBACK SUPPORT .................................... 37

EXTENDING THE GROUP POLICY SNAP-IN ............................. 39

CLIENT SUPPORT FOR WINDOWS NT 4.0, WINDOWS 95, AND

WINDOWS 98 ............................................................................. 40

MIGRATING FROM WINDOWS NT 4.0 TO WINDOWS 2000 ...... 42

Effects of Migration on Group Policy 42

Migration Scenario

Impact of Heightened Security in Windows 2000 on System Policies

43

44

APPENDIX A: FREQUENTLY ASKED QUESTIONS ................... 45

Infrastructure

—Server side

45

Infrastructure

—Client side

57

Group Policy Snap-in

Administrative Templates (.adm Files)

61

61

Scripts

Security Settings

General Issues

Troubleshooting

63

64

68

70

APPENDIX B: ADMINISTRATIVE TEMPLATES ......................... 72

Creating Custom .adm Files 72

Adding .adm Files

Namespace Naming Conventions

73

73

Registry Key Locations for Policy

ADM Language Components

73

74

APPENDIX C: WINDOWS NT 4.0, ZERO ADMINISTRATION KIT,

AND WINDOWS 2000 NAMESPACE COMPARISON .................. 89

APPENDIX D: GROUP POLICY STORAGE ................................. 94

Group Policy Container 94

Group Policy Template 94

APPENDIX E: THE REGISTRY.POL FILE ................................... 98

How Registry.pol Files Are Created 99

APPENDIX F: ACTIVE DIRECTORY OVERVIEW...................... 101

Active Directory Namespace 103

GLOSSARY .............................................................................. 106

FOR MORE INFORMATION ...................................................... 113

Management and Overview Papers 113

Technical Papers 114

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.

The Microsoft Windows NT ® 4.0 operating system introduced the System Policy

Editor, a tool that is used to specify user and computer configurations stored in the

Windows NT registry. With the System Policy Editor, you can create a System

Policy to control the user work environment and actions and to enforce system configuration settings for all computers running either Windows NT 4.0 Workstation or Server. System policies are registry settings that define the behavior of various components of the desktop environment.

In Windows 2000, you use Group Policy to define configurations for groups of users and computers. You create a specific desktop configuration for a particular group of users and computers by using the Group Policy Microsoft Management Console 1

(MMC) snap-in. The Group Policy snap-in extends the functionality of the System

Policy Editor and provides enhanced capabilities for specifying options for managed desktop configurations for groups of computers and users. The Group Policy snapin provides built-in features for setting Group Policy, including options for registrybased policies, security settings, software installation, scripts, and folder redirection.

The Group Policy settings that you create are contained in a Group Policy Object

(GPO) that is in turn associated with selected Active Directory™ directory system containers: sites, domains, and organizational units (OUs).

Windows NT 4.0 and Windows 2000 Policy Comparison

In Windows NT 4.0 (and Windows 95 and 98), the system policies you specify with the System Policy Editor (Poledit.exe):



Are applied to domains.



May be further controlled by user membership in security groups.



Are not secure.

 Persist in users’ profiles (this is sometimes referred to as tattooing the registry).

This means that after a registry setting is set using Windows NT 4.0 system policies, the setting persists until the specified policy is reversed or the user edits the registry.



Are limited to desktop lockdown.

In Windows 2000, Group Policy:



Represents the primary method for enabling centralized change and configuration management.



Can be associated with sites, domains, and organizational units.



Affects all users and computers in the specified Active Directory container (site,

1

The Microsoft Management Console (MMC) provides an open, extensible, common console framework for management applications. MMC provides a unified user interface for hosting administrative tools, including snap-ins, to administer networks, computers, services, and other system components.

Microsoft Windows 2000 Server Beta 3 Technical Paper 1

domain, or OU).



May be further controlled by user or computer membership in security groups.



Are secure.



Default policy settings do not persist in the registry.

 Can be used for expanded desktop lockdown and to enhance the user’s computing environment.

The Windows NT 4.0 effect of persistent registry settings can be problematic when a user’s group membership is changed. An advantage of the Windows 2000 Group

Policies is that this does not occur. The reason for this is that in Windows 2000, registry settings written to the following two secure registry locations are cleaned up when a Group Policy Object no longer applies:



\Software\Policies



\Software\Microsoft\Windows\CurrentVersion\Policies


GROUP POLICY

INFRASTRUCTURE AND

MECHANICS

Group Policy uses a document-centric approach to creating, storing, and associating policy settings. Just as Microsoft Word stores information in .doc files,

Group Policy settings are contained in Group Policy Objects. By analogy, the Group

Policy snap-in is to GPOs as Microsoft Word is to .doc files.

GPOs are associated with specific Active Directory containers (sites, domains, or

OUs), thus maximizing and extending the Active Directory. Data within the GPOs is then evaluated by the affected clients, using the hierarchical nature of the Active

Directory.

You create Group Policy by using the Group Policy MMC snap-in, either as an extension to the Active Directory-related snap-ins or as a stand-alone tool. The preferred method is to use the Group Policy snap-in as an extension to the Active

Directory Users and Computers snap-in or the Active Directory Site and Services snap-in. To do this, in 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. This allows you to browse the Active Directory for the correct Active Directory container, and then you can define Group Policy based on the selected scope.

Figure 1 below is an illustration of the relationship between Group Policy Objects and the Active Directory.

Figure 1 Group Policy and the Active Directory


You can filter the effects of Group Policy on computers and users by using membership in security groups and setting discretionary access control list (DACL) permissions. This ensures faster processing of Group Policy Objects, while allowing

Group Policy to be applied to security groups. Furthermore, you can limit who in your organization can create Active Directory links to GPOs, as well as who has access to create and modify GPOs, by using security groups.

To achieve the highest level of policy settings security, activate the Process even if the Group Policy Objects have not changed policy for each of the Group Policy client side extensions that require it. This policy is located in the Computer

Configuration node, under Administrative Templates , System , Group Policy .

Each client-side extension has a policy setting for controlling the policy processing.

By default, all Group Policy client-side extensions update the policy settings only when there are new or changed settings. Choosing this option ensures that the selected settings are applied at every logon to the Active Directory. Selecting this option negates the performance optimization achieved by skipping the application of policy settings when they have not changed.

For information on Windows 2000 security, see the security-related white papers at: http://www.microsoft.com/ntserver .

Administrative Requirements for Using Group Policy

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).

By default, Group Policy affects all computers and users in a selected Active

Directory container. However, you can filter the effects of Group Policy, based on users’ or computers’ membership in a Windows 2000 security groups. To filter

Group Policy, you use the Security tab on a Group Policy Object’s

Properties page to specify discretionary access control list (DACL) permissions. You also use DACL permissions to delegate the use of the Group Policy snap-in tool.

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, and Folder Redirection.

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 using the

MMC method of creating custom consoles and by using policy settings to control the behavior of MMC itself. See the Administrative Templates node to configure these policy settings. Using this extension model, developers can create an MMC


extension to the Group Policy snap-in to expand its capability to provide additional policies. These snap-in extensions may in turn be extended. An example of such a snap-in is the Security Settings snap-in, which includes several snap-in extensions.

More information on the Group Policy snap-in extensions is presented in the

Extensions to the Group Policy Snap-in section.

For more information on the Microsoft Management Console, see the Microsoft

Platform SDK documentation at: http://msdn.microsoft.com/developer/sdk/platform.htm

.

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 [MSMSRV01.streetmarket.com] Policy

The namespace is then divided into two parent nodes: Computer Configuration and

User Configuration. These are the parent folders that you use to configure specific desktop environments and to enforce Group Policy on groups of computers and users on the network.

Computer Configuration

This includes all computer-related policies that specify operating system behavior, desktop behavior, application settings, security settings, computer assigned application options, and computer startup and shutdown scripts. Computer-related

Group Policy is applied when the operating system initializes and during the periodic refresh cycle, explained later in this document.

User Configuration

This includes all user-related policies that specify operating system behavior, desktop settings, application settings, security settings, assigned and published applications options, user logon and logoff scripts, and folder redirection options.

User-related Group Policy is applied when users log on to the computer and during the periodic refresh cycle.

Note: In a public computing environment, such as libraries or schools, it may be useful to provide a specific desktop configuration regardless of which user logs on to the computer. This is called

loopback processing and is explained in the section titled Group Policy Loopback Support.

Under the Computer Configuration and User Configuration parent nodes are several child nodes; each of these nodes constitutes a separate Group Policy snap-in extension.

Extensions to the Group Policy Snap-in

The Group Policy snap-in includes several snap-in extensions. A Group Policy


snap-in extension may extend either or both of the User or Computer Configuration nodes in either the Windows Settings node or the Software Settings node. Most of the snap-in extensions extend both of these nodes, but frequently with different options. The Group Policy snap-in extensions include:

 Administrative Templates —Include registry-based Group Policy, which you use to mandate registry settings that govern the behavior and appearance of the desktop, including the operating system components and applications.

 Security Settings —You use the Security Settings extension to define security configuration for computers within a Group Policy Object. You can define local computer, domain, and network security settings.

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

 Scripts —You can use scripts to automate computer startup and shutdown and user logon and logoff. For these purposes, you can use Windows Scripting

Host 2 to include Microsoft Visual Basic ® Scripting Edition programming system

(VBScript), and Microsoft JScript ® programming system type scripts.

 Folder Redirection —Allows you to redirect special folders to the network.

2

Windows Scripting Host, like Internet Explorer, serves as a controller engine of ActiveX Scripting engines.

Windows Scripting Host supports scripts written in VBScript and Jscript.


Figure 2 below shows the Group Policy snap-in.

Figure 2. The Group Policy snap-in console

Administrative Templates

The Windows NT 4.0 System Policy Editor uses files called administrative templates

(.adm files) to determine which registry settings can be modified. The .adm file defines which settings are available through the System Policy Editor user interface.

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

The Administrative Templates node of the Group Policy snap-in includes all registrybased Group Policy information. Administrative Templates settings include Group

Policy for the Windows 2000 operating system and its components and for applications. These settings are written either to the User or Local Machine portion of the registry database. 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 is a text file that consists of a hierarchy of categories and subcategories that together define how the options are displayed through the Group

Policy snap-in UI. It also indicates the registry locations where changes should be made if a particular selection is made, specifies any options or restrictions (in values) that are associated with the selection, and in some cases, specifies a default value to use if a selection is activated. Windows 2000 includes two .adm files, System.adm

and Inetres.adm, which contain all the settings initially displayed in the Administrative Templates node. See the Explain tab of each policy’s

Properties page for more details on the policy settings.

The Administrative Templates node of the Group Policy snap-in can be extended by using custom .adm files. However, unlike other Group Policy snap-in extensions, it is not extensible by an MMC snap-in extension.

For more information on creating .adm files, see Appendix B: Administrative

Templates .

Extensions to the Administrative Templates Node

The Administrative Templates node includes settings for Remote OS Installation and Disk Quotas. Both Remote OS Installation and Disk Quotas use the registry; however, they use separate Client Side Extensions, which are dynamic-link libraries

(DLLs) that are responsible for implementing Group Policy at the client computers.

Remote OS Installation

Remote OS Installation is a new optional component included in Windows 2000

Server. Administrators can use Remote OS Installation to remotely install a local copy of the Windows 2000 Professional operating system on supported computers throughout their organization. Using Remote OS Installation, administrators can deploy a new version of an operating system upgrade to large numbers of clients at one time, from a centralized location.

Administrators use the Remote OS Installation snap-in extension to define Group

Policy for the client installation options that groups of users can access. These options are determined by the specific Remote OS Installation Group Policy settings that administrators have defined for the site, domain, or OU to which the users belong, in conjunction with the specific security group or user account.

The administrator can use Group Policy to define which group of users can access specific installation options by configuring the appropriate Group Policy settings.

At the client computer, when an end user logs into the Remote OS Installation

Client Installation wizard to install the operating system, the Remote OS Installation server checks for Group Policy pertaining to remote installation options defined for the user.

For more detailed information on Remote OS Installation, check the following web site: .

Disk Quotas

You use the Disk Quotas options in the Administrative Templates node to monitor


and limit disk space use for NTFS volumes formatted as NTFS version 5.0. After you enable disk quotas, you can set options for disk quota limits and warnings.

For more information on Disk Quotas, see the Windows 2000 Server online Help.

Security Settings

You can define a security configuration within a Group Policy Object. A security configuration consists of settings applied to one ore 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 enforcement.

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:



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.

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.

These incremental templates should be applied only to Windows 2000 systems that have been clean-installed onto an NTFS partition. For NTFS computers that have been upgraded from Windows NT 4.0 or earlier, a Basic security template

(described in the next section) should be applied to configure the upgraded computer with the new Windows 2000 default security settings. Windows 2000 systems that are installed on FAT file systems cannot be secured.


The following table lists the incremental security templates included in Windows

2000.

Templates Description Security Configuration Computer

Compatible

Secure

High Secure

Workstation, and server

Workstation, server, and domain controller

Compatws.inf For customers that 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.

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 wellknown 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.

Workstation, server, and domain controller

Hisecws.inf and

Hisecdc.inf

The High Secure configuration is provided for Windows 2000 computers that operate in native 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 high secure computer cannot communicate with a down-level Windows client.

Windows 2000 Default Security Templates

Windows 2000 includes three default security templates called Basi c. These new default security settings are applied only to Windows 2000 systems that have been clean-installed onto an NTFS partition. When computers are upgraded from

Windows NT 4.0 or earlier, security is not modified. When Windows 2000 is installed onto a FAT file system, security cannot be applied.

To secure upgraded NTFS computers in the same fashion as clean-installed NTFS machines, the following Basic security templates are provided:



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.


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, as well as the type of user accessing the system. No inference should be made with respect to the security of applications running in this environment.

Templates applied

Default

Default + Compatible

Default

Default + Secure

Default + Secure + High Secure

User level

Power User

User

User

User

User

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

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 a pplication on all the users’ desktops. The next time a user logs on to Microsoft

Windows NT, 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, users can open a document file associated with a published application (for example, an .xls file to install Microsoft Excel).

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 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.

Folder Redirection

You use the Folder Redirection extension 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



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.

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.

Creating Custom Group Policy Snap-in Consoles

You can create and save custom Group Policy MMC consoles (.msc files), which include only a subset of the Group Policy snap-in extensions. 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.

After you create a custom console, you need to determine which users and groups have access permissions to the Group Policy Object (GPO) and the associated

Active Directory container (site, domain, or OU).

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 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.

6. Click Extensions , and select the extension snap-ins you want to use.

7. Click Finish .

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 access to the GPO by specified groups.


Domain

(second)

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

Linking Sites, Domains, and

OUs (SDOUs) to GPOs

SDOU - Group Policy Properties page

GPOs

A1

OUs

(third)

B1

A2 B2

Site

(first)

Group Policy processing order is: Site, Domain, OU, and OU.

Figure 3. Linking Active Directory containers to Group Policy Objects

Group Policy Storage

Group Policy Objects store Group Policy information in two locations: a Group

Policy Container (GPC) and a Group Policy Template (GPT). A Group Policy

Container is an Active Directory container that stores Group Policy Object properties, including information on version, GPO status, and list of components that have settings in the GPO. A Group Policy Template is a folder structure that stores Administrative Template-based policies, security settings, applications available for Software Installation, and script files; it is located in the system volume folder of domain controllers (Sysvol) in the \Policies sub-folder.

Optionally, a Group Policy snap-in may store data outside the GPO; however, this requires that at least a link to the GPO be stored either in a Group Policy Container

(Active Directory data store) or a Group Policy Template (file type data stored on the Sysvol folder).

Note: Any Group Policy snap-in that stores data outside of the GPO (using a link) is responsible for cleaning up that data when the GPO is deleted. Data stored outside of the GPO also complicates backup and restore procedures.


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.

The Group Policy Model

Storage

Gr oup Policy Snap-in

GPOs Re gis tr y

(Re gis try.pol)

Sysvol

GUID

Dom ain

Contr olle r s

Group

Policy

Container in Active

Directory

Linked to GPO

This requires a link in one of the other storage locations.

Any other storage location

Figure 4. Group Policy and storage

For additional information on storage of Group Policy information, see Appendix D:

Group Policy Storage .

Multiple Group Policy Objects

You can associate multiple Group Policy Objects with a single site, domain, or organizational unit, and you can prioritize how these GPOs affect the directory container to which they are applied. Conversely, multiple sites, domains, and OUs can use a single GPO.

Any site, domain, or OU may be associated with any Group Policy Object, even across domains.


SPECIFYING A DOMAIN

CONTROLLER FOR

SETTING GROUP

POLICY

Two methods are available to set domain controller options for Group Policy. One method is by using the Group Policy snap-in user interface, where the user can set domain controller options by using the DC Options dialog box, as described next.

The other method allows the primary domain administrators to set DC options by using a policy in the Administrative Templates node, as described in Specifying

Policy for Domain Controller Options .

The Group Policy snap-in View menu contains an entry called DC Options , which opens the Options for domain controller selection dialog box, where you will be able to specify a domain controller (DC) to use for editing Group Policy:

Figure 5. Options for domain controller selection dialog box

The available options for the Options for domain controller selection dialog box are:



The one with the Operations Master token for the PDC emulator . This is the default and preferred option. Using this option helps ensure that no data loss occurs. This forces the Group Policy snap-in to use the same DC. Data loss could occur if two administrators were working on changes to the same

GPO on different DCs within the replication cycle. In this version of Windows

2000, Group Policy writes data to the GPO for each change. If two administrators are editing a GPO on different DCs, it increases the possibility of changes being overwritten by replication. It is strongly recommended that the number of administrators be limited, that Group Policy use the PDC emulator

Operations Master, and that the administrator be aware of other administrators that may be editing the same GPO.



The one used by the Active Directory Snap-ins . Uses the DC that the Active

Directory management snap-in tools are currently using. Each of these snapins includes an option for changing which DC is the focus of their current operations. When this option is selected, the Group Policy snap-in uses the same DC. For example, if the Active Directory Users and Computers snap-in is focused on DC3, Group Policy also uses DC3.




Use any available domain controller . The third, and least desirable option, in most cases, allows the Group Policy snap-in to choose any available DC. When this option is used it is likely that a DC in the local site will be selected.

All of these options may be overridden by a policy setting, described below. These settings are available in the User Configuration, Administrative Templates, System,

Group Policy node of the Group Policy snap-in.

Specifying Policy for Domain Controller Options

The primary domain administrators 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. If that option is not available, the user will get an error message. In such cases, the DC Options menu item will be grayed out

(unavailable) since a policy is in place that overrides any setting that the user picks.

This policy allows domain administrators to indicate that all administrators must use the PDC, for example. The DC options policy will be available in the Administrative

Templates node for User Configuration, in the System\Group Policy sub-container.

The available DC options are the same as the preference settings listed above in the Options for domain controller selection dialog box description.

This functionality will be useful in some corporate scenarios. For example, if you are an administrator in Japan and the PDC is in New York. You can make your policy edits locally, so the performance is acceptable.

Error Handling on Failure to Reach a Domain Controller

If the Group Policy snap-in cannot reach the intended DC, the following error dialog box is displayed:

Figure 6. Domain controller not found dialog box

The default option for this dialog box is always the first option. If there is a policy in place, this error dialog box is not displayed. Instead, the following message is display ed: “Failed to find a domain controller. There may be a policy that prevents you from selecting another domain controller.”


DC Selection Results

The following table indicates what will result from various combinations of conditions. Where:

PDC : means use the DC with the Operations Master token for the PDC emulator.

Inherit : means used the DC used by the Active Directory snap-ins.

Any : means use any available DC.

1) and 2) : means that 1) will be tried first then 2)

User preference

Any

N/A

N/A

N/A

N/A

Undefined

PDC

Inherit

Inherit

Policy

Undefined

Undefined

Undefined

Undefined

Undefined

PDC

Inherit

Inherit

Any

Inherit DC

N/A

N/A

Yes

No

N/A

N/A

N/A

Yes

No

Results

1) PDC 2) Prompt

1) PDC 2) Prompt

Inherit

Any DC

Any DC

PDC only

Inherit

Any DC

Any DC


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 is processed according to the following order: site, domain, and OU.

The default inheritance method is to evaluate Group Policy, starting with the Active

Directory container furthest away from the computer or user object. The Active

Directory container closest to the computer or user can override Group Policy set in a higher-level AD container.

Enforce and Block Policy Options

Options exist that allow you to enforce the Group Policy in a specific Group Policy

Object so that GPOs in lower-level Active Directory containers are prevented from overriding that policy. For example, if you have a defined a specific GPO at the domain level and specified that the GPO be enforced, 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. For example, if you specify a particular policy for an OU, and then mark that policy as block policy inheritance , this prevents policy in higher-level Active

Directory containers (such as a higher-level OU or domain) from applying. However, enforced policy options always take precedence.


USING SECURITY

GROUPS TO FILTER AND

DELEGATE GROUP

POLICY

You use security groups with Group Policy for two purposes:



To filter the scope of the Group Policy Object



To delegate control of Group Policy Objects

Filtering 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. This means that for any GPO, y ou can filter the Group Policy Object’s effect on members of specified security groups. To do this, use the Security tab on the Properties page of the GPO.

Setting Security Permissions for Group Policy

The Properties page of the Group Policy snap-in hosts the Security tab. To use the Security tab on the Properties page, right-click the root node of the Group

Policy snap-in, click Properties , and then click 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 .

You use the Security property page to set access permissions (discretionary access control lists 3 , or DACLs) on a selected GPO to allow or deny access to the

GPO by specified groups.

Administrators can specify which groups of users and computers have Apply Group

Policy Access Control Entries 4 access to the GPO. Groups that have Apply Group

Policy and read access to the GPO receive the Group Policy settings contained in it, and groups that do not have Apply Group Policy or read access to the GPO do not get the Group Policy settings contained in it. By default, authenticated users have both Apply Group Policy and read DACL permissions. This means that by default, users cannot modify the information in the GPO. By default, domain administrators, enterprise administrators, and the local system have full control permissions, without the Apply Group Policy Access Control Entry. By default, administrators are also authenticated users, which means that they also have the

Apply Group Policy attribute set. See Editing Group Policy Objects for more information.

To prevent GPO policy from applying to a specified group requires removal of the

Apply Group Policy Access Control Entry from that group.

Best Practice: For groups containing non-administrators, the read Access Control

Entry should also be removed, since data would be viewable to anyone with read access.

Network administrators (members of the Enterprise or Domain Administrators group) can also use the Security tab on the GPO Properties page to determine which administrator groups can modify policies in GPOs. To do this, the network

3

A discretionary access control list (DACL) is a list of permissions within a security descriptor.

4

Access control entries (ACEs) are permission entries within a DACL.


administrator can define groups of administrators (for example, marketing administrators), and then provide them with read and write access to selected

GPOs. This allows the network administrator to delegate control of the GPO policies. Granting read and write access to a GPO allows administrators to control all aspects of it.

Similarly, you can also access the Security tab on the GPO Properties page in the

Active Directory Sites and Services Manager snap-in (by first clicking a site container). Domain administrators can then set read and write permissions for groups of administrators, as described previously.

Delegating Control of 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 (SDOUs).

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



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



Creating Group Policy Objects



Editing Group Policy Objects

The following table lists the security permission settings for a Group Policy Object.

Groups or Users Security permission

Authenticated User Read with Apply Group Policy ACE

Domain Administrators Full control without Apply Group Policy

ACE.

Enterprise Administrators

Creator Owner

Local System

Note: By default, administrators are also authenticated users, which means that they have the Apply Group Policy attribute set.

See Editing Group Policy Objects for more information.

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

By default, administrators can configure Group Policy for sites, domains or organizational units. Using the Active Directory tools and getting properties for the specified site, domain, or OU does this. The Group Policy tab in the SDOU’s

Properties page 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 policy setting.

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.

Creating Group Policy Objects

By default, only domain administrators, enterprise administrators, Group Policy administrators, 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 Administrators security group. When a non-administrator who is a member of the Group Policy

Administrators 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 Administrators 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 full control of all the GPOs for the domain.

Editing Group Policy Objects

By default Group Policy Objects give Domain Administrators, Enterprise

Administrators, the operating system, and the GPO Creator Owner full control without the Apply Group Policy attribute. This means that they can edit the GPO, but the policies contained in that GPO do not apply to them.

By default Authenticated Users have read access to the Group Policy Object with the Apply Group Policy attribute set.

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 and add their own security group with the Apply Group

Policy attribute 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.

When a non-administrator creates a GPO, he or she becomes the Creator Owner of the Group Policy Object. When an administrator creates a GPO, the Domain

Administrators group becomes the Creator Owner of the Group Policy Object.

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 delegated access to this user by using the Security tab in the GPO Properties page.


The following flow chart illustrates the delegation control process.

SDOU

Delegation Flow Chart

Start

GPO

Delegate an

SDOU or GPO

•

•

•

•

•

Select the site, domain, or OU in the

Active Directory tool.

Right-click, and select Delegate

Control .

Select the User(s) or Group(s) to delegate control.

In the Predefined tasks list, select

Manage Group Policy links .

Complete the rest of the wizard.

•

•

•

Navigate using one of the Active Directory tools to a site, domain, or OU with the

GPO linked to it.

Right-click the GPO and select

Properties .

In the Security tab, add the User(s) or

Group(s) to delegate control.

Can this User or

Group create new

GPOs?

•

•

•

Yes

In the Active Directory Users and

Computers snap-in, select the Group

Policy Creators security group.

Right-click and select Properties .

On the Members tab, add the User(s) or

Group(s) to delegate control

No

Finished

Figure 7. Delegation in Group Policy


Examples of Group Policy Delegation

This section presents three examples of Group Policy delegation.

Example 1

In this example, control of an organizational unit is delegated to a nonadministrative user so that a group of users (or user) can select from existing Group

Policy Objects, 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 Delegation of Control Wizard, press Next to go past the introduction page.

You will be asked to confirm the OU that you wish 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 group (or user), 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.

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

Example 2

In this example, control of an organizational unit is delegated to a non-administrator user so that the group of user or (user) 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 group of users (or user) to the Group Policy Administrators 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 Administrators .

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 group of users (or user) will be able to create new Group Policy Objects, and the specific user who created each object will become the creator owner of that

GPO.


Example 3

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

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 group of users (or user), and give them full control.

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. The Full Control checkbox will also be cleared, but the user will still have read and write access to the GPO.

4. Press OK to save the changes.

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

Creating Group Policy MMC Consoles to Delegate Group Policy

You delegate Group Policy by creating and saving Group Policy MMC snap-in consoles (.msc files), and then specifying which users and groups have access permissions to the Group Policy Object or to an Active Directory container (site, domain, or OU). You define permissions for a Group Policy Object by using the

Security tab on the Properties page of the Group Policy Object; these permissions grant or deny access to a Group Policy Object to specified groups.

This type of delegation is also enhanced by the policy settings available for the

MMC. Several policies are available in the Administrative Templates node, under

Windows Components, Microsoft Management Console. These policies enable the administrator to establish which MMC snap-ins may or may not be run by the affected user. 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. See the Explain tab text of the individual policy setting for more information.


GROUP POLICY

PROCESSING

Group Policy is processed according to the following criteria:



Active Directory Group Policy Object hierarchy; that is, site first, domain next, and OU last, including any nested organizational units. This also includes any exceptions that you have defined for a Group Policy Object, such as Block or

Enforce Group Policy. Block Group Policy occurs at the SDOU container level, whereas Enforce Group Policy happens at the GPO level.



Any security group filters that you have applied to a Group Policy Object.

An ordered list of Group Policy Objects is created on a per-site, domain, and OU basis. A Client-side extension (CSE) to Group Policy is a dynamic-link library (.dll) that implements Group Policy at the client computer. For each Client-side extension, the Group Policy Object processing order is obtained from a list of Group

Policy Objects, which is obtained from the GetGPOList Win32 function. Each

Client-side extension processes the resulting list of GPOs.

Synchronous and Asynchronous Processing

By default, the processing of Group Policy is synchronous, which means that computer Policy is completed before the CTRL+ALT+DEL dialog box is presented, and user Policy is completed before the shell is active and available for the user to interact with it.

Note: You can change this default behavior by using a policy setting for each so that processing is asynchronous. However, this is not recommended because it can cause unpredictable or undesirable side effects. To provide the most reliable operation, leave the processing as synchronous.

Best Practice: Consider the processing of user logon scripts as an example. It is a good idea to use Group Policy scripts and to avoid using per-user scripts, if at all possible. However, if per-user scripts are required, asynchronous processing of

Group Policy means that the order in which the scripts are run is a race condition, which usually signifies that the per-user policy processing will happen before the

Group Policy scripts. Conversely, with synchronous processing of Group Policy, the

Group Policy scripts are processed first, and then per-user scripts are processed.

Group Policy for computers is applied at computer startup. For users, Group Policy is applied when they log on.


Periodic Refresh Processing

You can specify that Group Policy be processed periodically. By default, this is done every 90 minutes with a randomized offset of up to 30 minutes. You can change these default values by using a Group Policy setting in Administrative Templates.

Setting the value to zero minutes causes the refresh rate to be set to seven seconds.

Note: This practice is not recommended in a production environment; it is intended to be used only in test or demonstration scenarios.

For domain controllers, the default period is every five minutes. The application of

Group Policy cannot be scheduled or pushed to the clients.

Software Installation and Folder Redirection processing occurs only during computer startup or when the user logs on, rather than on a periodic basis. This is because processing periodically could cause undesirable results. For example, for

Software Installation, if an application is no longer assigned, it is removed. If a user is using the application while Group Policy tries to uninstall it or if an assigned application upgrade takes place while someone is using it, problems occur.

Group Policy and Network Connections (Slow Links)

When Group Policy detects a slow link, it sets the GPO_INFO_FLAG_SLOWLINK flag in the GPO_INFO structure to indicate that policy is being applied across a slow link. Individual Client-side extensions can determine whether or not to apply policy over the slow link.

The default settings are as follows:



Security Settings

—ON



Administrative Templates

—ON (and cannot be turned off)



Software Installation

—OFF



Scripts

—OFF



Folder Redirection

—OFF

For all but the Administrative Templates snap-in, a policy is provided for toggling the settings.

Setting Policy for Slow-Link Definition

You can use Group Policy to set the definition of a slow link for computers and users, and for user profiles.

For Group Policy, Windows 2000 uses a new IP ping algorithm to ping the server, rather than measuring the file system performance method that was used in

Windows NT 4.0.

A slow link is, by default, based on the following algorithm (where ms = milliseconds):


1. Ping the server with 0 bytes of data and time the number of milliseconds.

This value is time#1. If it is less than 10 ms, exit (assume a fast link).

2. Ping the server with 4 KB of data, and time the number of milliseconds.

This value is time#2.

3. DELTA = time#2 - time#1. This removes the overhead of session setup, with the result being equal to the time to move 4 KB.

4. Loop three times, adding to TOTAL each DELTA value.

5. TOTAL/3 = Average of DELTA, in milliseconds.

6. 4k * 1000/DELTA = X

7. X*8= Zbps

8. Z/1024=Kbps. The resulting value is evaluated against the policy setting.

The default is greater than or equal to 500 Kbps is a fast link. This value may be set through Group Policy in the Administrative Templates node.

To specify policy settings for Group Policy slow link detection for computers, you use the Computer Configuration\Administrative Templates\System\Group

Policy node. To set this policy for users, you use the User

Configuration\Administrative Templates\System\Group Policy node. The connection speed is set for kilobytes per second (Kbps).

For User Profiles, the Slow network connection timeout for user profiles policy is located in the Computer Configuration\Administrative

Templates\System\User Profiles node. This policy has support for both pinging the server and checking the performance of the file system. This is because user profiles can be stored anywhere, and that server may or may not have IP support.

Therefore, the user profile code first tries to ping the server. If the server does not have IP support, it falls back to measuring the file system's performance. You must specify connection speeds in both kilobytes per second (Kbps) and milliseconds

(ms) when setting this policy.

Registry Reads

Group Policy snap-in extensions can temporarily claim (or lock) a mutex (mutual exclusive) for policy, and then release that mutex. APIs exist to allow an application to claim the mutex, read the required values, then release the critical section. If it is not released in 10 minutes, the application is forced to release it. This ensures that the background refresh of Group Policy does not occur during the read process.

For information on server-side details of Group Policy and related APIs, see the

Microsoft Platform SDK, at: http://msdn.microsoft.com/developer/sdk/platform.htm

.

For more information on the Windows 2000 Group Policy APIs, see the Microsoft

Windows Platform SDK at: http://msdn.microsoft.com/developer/sdk .


Other Processing

Messages and Events

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

On-Demand Processing

Group Policy can also be applied on demand. To do this, applications can call the

RefreshPolicy function, which allows applications to request a policy refresh.

Group Policy Snap-in and the Operations Master

The Group Policy snap-in uses the primary domain controller (PDC) emulator

Operations Master token when editing a GPO. This ensures that the Group Policy snap-in is always focused on the same domain controller (DC). User preference options and policy settings are available to modify this behavior. For more information on setting DC options, see the Specifying a Domain Controller for

Setting Group Policy section.

Client-side Processing of Group Policy

As mentioned previously, some of the Group Policy components include Client-side extensions (.dlls) that are responsible for implementing Group Policy at the client computers.

The Client-side extensions are loaded on an as needed basis when a client computer is processing policy. The client computer first gets a list of Group Policy

Objects. Next, it loops through all the Client-side extensions and determines whether each Client-side extension has any data in any of the GPOs. If a Clientside extension has data in a GPO, the Client-side extension is called with the list of

Group Policy Objects that it should process. If the Client-side extension does not have any settings in any of the GPOs, it is not called.


The Client-side extensions are listed in the following table.

Client-side extension DLL file name

Registry (Administrative Templates)

Disk Quota (in Administrative Templates)

Folder Redirection

Scripts


Security

Userenv.dll

Dskquota.dll

Fdeploy.dll

Gptext.dll

Appmgmts.dll

Scecli.dll

IP Security Gptext.dll

EFS (Encrypting File System) Recovery Scecli.dll

Computer Policy for Client-Side Extensions

A computer policy exists for each of the Group Policy Client-side extensions. Each policy includes a maximum of three options (checkboxes). Some of the Client-side extensions include only two computer policy options; in those cases, this is because the third option is not appropriate for that extension.

The computer policy options are:



Allow processing across a slow network connection . When a Client -side extension registers itself with the operating system, it sets values in the registry, specifying whether it should be called when policy is being applied across a slow link. Some extensions move large amounts of data, so processing across a slow link can affect performance (for example, consider the time involved in installing a large application file across a 28.8 Kbps modem line).

Best Practice: The values that the Client-side extension puts in the registry are considered to be preferences. However, if an administrator decides that the Client-side extension should run across a slow link, regardless of the amount of data, he or she can enable this policy.



Do not apply during periodic background processing . Computer policy is applied at boot time, and then again in the background, approximately every 90 minutes thereafter. User policy is applied at user logon, and then approximately every 90 minutes after that. Some extensions can process policy only during the initial run because it is risky to do it in the background. For example, with

Software Installation application upgrades, applications are installed during the initial run and not in the background. If it were done in the background, a user could be running an application, and then have it uninstalled and a new version installed. The application could also have a shared component that is in use by another application. This prevents the installation from completing successfully.

The Do not apply during periodic background processing option gives the administrator the ability to override this logic and force the extension to either run or not run in the background.



Process even if the Group Policy Objects have not changed . By default, if the GPOs on the server have not changed, it is not necessary to continually


reapply them to the client, since the client should already have all the settings.

However, users may be able to change some policies and settings, if they are administrators of their computers. In this case, it may make sense to reapply these settings during logon or during the periodic refresh cycle to get the computer back to the desired state.

For example, assume that you have used Group Policy to define a specific set of security options for a file. Then the user (with administrative privileges) logs on and changes it. The Group Policy administrator may want to set the policy to process Group Policy even if the GPOs have not changed so that the security is reapplied at every boot. This also applies to applications. Group Policy installs an application, but the end user can remove the application or delete the icon. The Process even if the Group

Policy Objects have not changed option gives the administrator the ability to restore the application at the next user logon.

The following table lists the Client-side extensions that include only two computer policy options, as well as the reason for this.

Client-side extension

Missing policy checkbox Reason

Registry

Security Settings

Slow link (Allow processing across a slow network connection)

Slow link (Allow processing across a slow network connection)

Folder Redirection Background processing (Do not apply during periodic background processing)

Software

Installation

Background processing (Do not apply during periodic background processing)

Registry policy is always applied because it controls the other Client-side extensions.

To ensure that security settings are in effect, they must always be applied, even across a slow link.

It is considered too risky to move users’ files while they are logged on.

It is considered too risky to install and uninstall an application when the user is logged on.


USING GROUP POLICY

ON STAND-ALONE

COMPUTERS

You can set local Group Policy for computers that are not members of a domain. To set local Group Policy, you use the Group Policy snap-in focused on the local computer. You will be able to access the Group Policy snap-in tool by typing mmc at the command prompt, adding the Group Policy snap-in to the MMC console, and focusing the Group Policy snap-in on the local computer.

Local Group Policy Object

On stand-alone computers, a Local Group Policy Object (LGPO) exists

—this is just the Group Policy Template portion. The location of the LGPO is

\%SystemRoot%System32\GroupPolicy. Each Group Policy extension snap-in queries Group Policy to get the GPO type, and then decides if they should be displayed.

The following table indicates whether or not the Group Policy snap-in extensions opens when the Group Policy snap-in is focused on a LGPO.

Group Policy snap-in extension Loaded when Group Policy snap-in focused on LGPO

Security Settings



Scripts

Folder Redirection

Yes

Yes

No

Yes

No

Starting the Group Policy Snap-in on Windows 2000

Professional

Windows 2000 Professional does not provide a user interface for accessing the

Group Policy snap-in directly. However, you can access the Group Policy snap-in in the following manner.

To start the Group Policy snap-in on Windows 2000 Professional:

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




5. The Select Group Policy Object dialog box appears. Click Local

Computer to edit the Local Group Policy Object (LGPO), or Browse to find the GPO that you want to use.

6. Click Finish .

7. Click OK . The Group Policy snap-in opens with focus on the specified

Group Policy Object.

Best Practice: To use the Group Policy snap-in on a remote computer, you must have administrative rights on both computers. and the remote computer must be part of the namespace.


Using the Group Policy Snap-in Focused on a Remote

Computer

To focus the Group Policy snap-in on a remote computer, this must be done when the extension is added to an MMC console file, or as a command line option.

To add Group Policy to an MMC console focused on a specific remote computer

1. Click Start , click Run , and type MMC . Or you can open an existing saved console (like Console1.mmc).




By default this is set to open on the local computer.

5. Select Browse .

You may now select a GPO from the Active Directory or as in this case select the Computer tab.

6. Select Another Computer .

7. Either type in the computer name, or click Browse to locate it.

8. You may use the Look in drop-down list box to select the domains to which you have access.

The supported computer name formats are:



NetBIOS names, for example, MachineName .



DNS-style, for example, MachineName.Streetmarket.com

.

The Group Policy snap-in may be started with the following two command line switches:



/gpcomputer:"machinename"

Where " machinename " can be either a NetBIOS or a DNS-style name.

For example:

“gpedit.msc /gpcomputer:"machinename” or

“gpedit.msc /gpcomputer:"machinename.streetmarket.com”



/gpobject:"ADSI path"

For example:

"LDAP://CN={GUID of the

GPO},CN=Policies,CN=System,DC=Streetmarket,DC=com"

For these command line options to work with a saved console file, you must check the checkbox titled " Allow the focus of the Group Policy snap-ins to be changed when launching from the command line. This only applies if you save the console.

"

The shipping Gpedit.msc file is saved with this option on.

Note: The Security Settings extension does not support remote management for local policy in


Windows 2000.

Local Group Policy Object Processing

When a computer is joined to a domain with the Active Directory and Group Policy implemented, a local Group Policy Object is processed. Note that LGPO policy is processed even when the Block Policy Inheritance option has been specified .

Local Group Policy Objects are always processed first, and then domain policy is processed. If a computer is participating in a domain and a conflict occurs between domain and local computer policy, domain policy prevails. However, if a computer is no longer participating in a domain, LGPO policy is applied.


GROUP POLICY

LOOPBACK SUPPORT

Group Policy is applied to the user or computer, based upon where the user or computer object is located in the Active Directory. However, in some cases, users may need policy applied to them, based upon the location of the computer object, not the location of the user object. The Group Policy loopback feature gives the administrator the ability to apply Group Policy, based upon the computer that the user is logging onto.

To describe the loopback feature, we’ll use an example. In this scenario, you have full control over the computers and users in this domain because you have been granted domain administrator rights.

The following illustration shows the Streetmarket domain, which is used to work through this example.

Figure 8. The Streetmarket domain

When users work in their own workstations, they should have Group Policy applied to them according to the policy settings defined, based on the location of the user object. However, when users log on to a computer whose computer object is in the in the Servers OU, they should get user policy settings based on the computer object location, rather than the user object location.

Normal user Group Policy processing specifies that computers located in the

Servers OU have the GPOs A3, A1, A2, A4, A6 applied (in that order) during computer startup. Users of the Marketing OU have GPOs A3, A1, A2, A5 applied (in that order), regardless of which computer they log on to.


In some cases this processing order may not be appropriate, for example, when you do not want applications that have been assigned or published to the users of the

Marketing OU to be installed while they are logged on to the computers in the

Servers OU. With the Group Policy loopback support feature, you can specify two other ways to retrieve the list of GPOs for any user of the computers in the Servers

OU:



Merge mode

. In this mode, during logon the user’s list of GPOs is gathered normally by using the GetGPOList function, and then GetGPOList is called again using the computer’s location in the Active Directory. Next, the list of

GPOs for the computer is added to the end of the GPOs for the user. This causes the computer’s GPOs to have higher precedence than the user’s GPOs.

In this example, the list of GPOs for the computer is A3, A1, A2, A4, A6, which is added to the user’s list of A3, A1, A2, A5 which results in A3, A1, A2, A5, A3,

A1, A2, A4, and A6 (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 was implemented in the Group Policy engine 5 , not in the

GetGPOList function. 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. Then, based upon this policy, it calls GetGPOList , as appropriate.

5

The Group Policy engine is the part of Group Policy that runs in the Winlogon process.


EXTENDING THE GROUP

POLICY SNAP-IN

Third-party application developers can extend the Group Policy snap-in functionality to provide Group Policy specific to their applications. For this purpose, they can:



Create an administrative template (.adm file). For more information, see

Appendix B: Administrative Templates.



Create a Group Policy MMC snap-in extension and provide the user interface for setting Group Policy specific to their application. For storing and distributing the policy, the following mechanisms are recommended:



Use the API specific to the Group Policy MMC snap-in to write registrybased Group Policy to the Group Policy Template. The Group Policy snap-in API documentation is included in the Microsoft Platform Software

Development Kit (SDK). For more information, see: http://msdn.microsoft.com/developer/sdk/platform.asp

.



Use the GetFileSysPath function to store non-registry based (file-based) policy information in a Group Policy Template (GPT) subfolder. You should use the Company Name \ Application Name \ Version naming convention for such folder. Then place the required files in that GPT subfolder. On the client side, Winlogon calls the Client-side extension for the tool. This in turn processes the information stored in the directory in the

GPT. The application developer must use this mechanism appropriately.

By storing the data in a GPT subfolder, the application capitalizes on the built-in mechanisms of Group Policy (the GPT and Winlogon) for applying special non-registry-based policy.

For information about Microsoft Management Console, see the Microsoft Platform

SDK documentation at: http://msdn.microsoft.com/developer/sdk/platform.asp

.


CLIENT SUPPORT FOR

WINDOWS NT 4.0,

WINDOWS 95, AND

WINDOWS 98

The Windows 2000 Group Policy snap-in does not provide client support for

Windows NT 4.0 clients and computers running Windows 95 and Windows 98.

Support for Windows NT 4.0 clients is provided by fully supporting the

Windows NT 4.0 style of administrative templates (.adm files) and by providing the

Windows NT 4.0 System Policy Editor 6 (Poledit.exe) files. However, the System

Policy Editor user interface is not exposed in the Windows 2000 user interface.

You can install the System Policy Editor tool, Poledit.exe, in Windows 2000

Professional by using the Windows 2000 Server’s

Windows 2000 Administrative

Tools package. Windows 2000 Server includes a component called Windows 2000

Administration Tools (Adminpak.msi), a Windows Installer package (.msi file) that contains all the files and information required to install the Windows 2000 Server

Administrative tools.

Installing Windows 2000 Administration Tools on Windows 2000 Server

First, install the Windows 2000 Administration Tools package on a server from a

Windows 2000 Server compact disc. To do this:



Open the I386 (or Alpha) folder on the applicable Windows 2000 Server CD.



Double-click the Adminpak.msi file.



Follow the instructions that appear in the Windows 2000 Administration

Tools Setup Wizard.

Installing System Policy Editor on Windows 2000 Server

After Windows 2000 Administration Tools are installed, most of the server administrative tools can be accessed by clicking Start , pointing to Programs , and then pointing to Administrative Tools . Then choose the System Policy Editor from the list of administrative tools.

When you install the System Policy Editor, Poledit.exe and its supporting .adm files

(Winnt.adm, Windows.adm, and Common.adm) are installed into the \System directory and the \Inf directory, as they where in Windows NT 4.0.

Installing Windows 2000 Administration Tools on Windows 2000

Professional

After you have installed Windows 2000 Administration Tools (Adminpak.msi) on the server, you can make the Adminpak.msi file available on a network share. This allows Windows 2000 Professional computers to connect to that share and doubleclick the Adminpak.msi file to install the Windows 2000 Administration Tools.

Alternatively, you can use Software Installation policy to either assign or publish the

Adminpak.msi file. For information on using Software Installation, refer to the

Windows 2000 Server online Help.

6

System Policy Editor is an ASCII tool (including its user interface); however, it does provide support for reading Unicode files.


Installing System Policy Editor on Windows 2000 Professional

Having installed Windows 2000 Administration Tools on Windows 2000

Professional, you can then install the System Policy Editor by clicking Start , pointing to Programs , pointing to Administrative Tools , and selecting System

Policy Editor . This installs the System Policy Editor as it is installed on the server.

Windows 95 and Windows 98 Clients

Clients running Windows 95 and Windows 98 must still use the Windows NT 4.0

System Policy Editor, Poledit.exe.

Note: For Windows 2000 Professional, Windows NT 4.0 Workstations, Windows 95, and Windows 98 clients to be affected by the resultant .pol file, you must copy the .pol file to the domain controller’s

Netlogon share. On Windows NT 4.0, the Netlogon share is located in

%systemdir%\System32\Repl\Import\Scripts; on Windows 2000, it is located in \Sysvol\DN of domain\Scripts.


MIGRATING FROM

WINDOWS NT 4.0 TO

WINDOWS 2000

Migrating Windows NT 4.0

–based clients and servers to Windows 2000 in various combinations causes different behavior for Group Policy. The default behavior for

Windows 2000 Server and Windows 2000 Professional is to process only Windows

2000 Group Policy (that is, no processing of Windows NT 4.0 System Policies).

However, a Group Policy option exists that lets you turn on Windows NT 4.0

–style

System Policy.

Best Practice: If you enable the Group Policy option to turn on Windows NT 4.0 style System Policy, both Windows 2000 Group Policy and Windows NT 4.0

–style policies are processed. Caution should be exercised before enabling this policy.

Both computer and user Windows NT 4.0

–style policies are processed at user logon. Since the Windows 2000 Group Policy policies have been set, any Windows

NT 4.0 style policies that conflict with them override the Group Policy settings.

Then, the user settings are applied before the Group Policy policies; this means that the Group Policy user policies overwrite any conflicting Windows NT 4.0 style user policies. In addition, all Windows NT 4.0 style policies persist in the registry since they are not written to the \Software\Policies tree. This occurs because any policies outside of the \Software\Policies tree are not cleaned up.

Environment

Windows NT 4.0

Windows 2000

Windows 2000. All Windows 2000 domain controllers down with

Windows NT 4.0 backup DCs up.

Computer account in a Windows NT

4.0 domain. User logs on to a

Windows 2000 network.

Computer account in Windows 2000 network. User logs on to a Windows

NT 4.0 domain.

Effects of Migration on Group Policy

The following table summarizes the expected behavior for Group Policy when

Windows NT 4.0

–based servers and clients are migrated to Windows 2000. The following notation is used:

LGP = local Group Policy

LSDOU = local Group Policy, site, domain, organization unit

Windows NT 4.0 = By default - %Netlogon%\NTConfig.pol

Windows NT 4.0 client receives this policy

Windows NT 4.0

Windows NT 4.0

Windows NT 4.0

Windows NT 4.0 from the Windows 2000 Domain

Windows NT 4.0 from the Windows NT 4.0 Domain

Windows 2000 client receives this policy

Windows NT 4.0 + LGP

LSDOU

LSDOU

Like logging on with cached credentials.

Neither computer nor user Group Policy will be applied. Only System Policy will be applied.

Workgroup/stand-alone

No change from current:

1. No policy.

2. If setup, manual Windows NT 4.0 policy.

3. If the client was previously in a Windows NT 4.0 domain, the client receives leftover policy from the domain.

Computer gets Group Policy. User gets no policy

(Group Policy or System Policy). If the plan is to stay in this mode, consider using Group Policy to enable

System Policy.

1. If setup, manual Windows NT 4.0 policy.

2. LGP.

3. If the client was previously in a Windows 2000 domain, the client may receive some leftover policy from the domain.


Leftover policy refers to those policies that are outside of the two clean-up locations in the registry, HKLM and HKCU ( \Software\Policies and

\Software\Microsoft\Windows\Current Version\Policies ). All the shipping .adm files for use with Windows 2000 (System.adm and Inetres.adm) have their policies in the appropriate location to be cleaned up, thus avoiding this situation.

Note: Third-party .adm files that do not use the policies tree have their settings left behind when

Group Policies change.

For a comparison of the policy-related namespace in Windows NT 4.0, the Zero

Administration Kit, and Windows 2000, see Appendix C.

Migration Scenario

The following steps will lead you through a common migration scenario:

1. Start with a Windows NT 4.0 domain with Windows NT 4.0 clients, and create and apply system policies.

2. Upgrade one client to Windows 2000.

3. Verify that the system policies are applied to the Windows 2000 client. The

Windows 2000 client has now been tattooed with those system policies.

This is because system policies have no mechanism for cleaning up registry entries that should no longer be applied. (This is referred to as tattooing the registry.)

4. Upgrade the Windows NT 4.0 PDC to Windows 2000 DC.

5. Modify system policies, and apply to clients.

System policies changes now do not apply to the Windows 2000 client. The client does not process system policies by default. Normally, it would be necessary to manually repair the registry to remove the persistent settings for each affected client.

One solution to this is to use a combination of Group Policy settings and

System Policy to reverse the unwanted settings.

1. Disable the Group Policy setting that prevents System Policy from being applied. This setting is enabled by default in the Default Domain Policy GPO; it is located in Computer Configuration\Administrative Templates\System\Group

Policy and is called Disable system policy (use group policy only).

2. To prevent System policies from overwriting the registry changes made by

Group Policy, enable the Registry policy processing and its sub-policy setting

Process even if the Group Policy Objects have not changed Group Policy.

These settings are located in Computer Configuration\Administrative

Templates\System\Group Policy.

3. Reboot the Windows 2000 clients that have been tattooed. This reapplies the new computer policy settings.

4. Edit the system policies to disable (uncheck, not gray) the policies that had caused the persistent settings (tattooing effect). This reverses the effect of each policy setting.

5. Reboot the affected Windows 2000 clients. This reapplies the policy settings, and the system policies reverse the previous settings.

6. Enable the Disable system policy (use group policy only) Group Policy.

7. Disable the Registry policy processing policy and its sub-section, Process even if the Group Policy Objects have not changed Group policy.


8. Reboot the Windows 2000 clients.

At this point, all persistent registry settings (tattooing) should be removed, and all Windows 2000 clients are now operating in Group Policy –only mode. An alternative to this approach would be to write REGINI scripts that do the registry clean up and run them as logon scripts.

Impact of Heightened Security in Windows 2000 on System

Policies

Windows 2000 has heightened security so that the local system of Windows NT 4.0 clients cannot read user security group information from the Active Directory.

Windows NT 4.0 clients does not get any system policies based on security groups.

System policies are policies created using the System Policy Editor (Poledit.exe).

The most likely occurrence of this is in an upgrade of a Windows NT 4.0 Server to

Windows 2000. The Windows NT 4.0 clients still get any user-specific or the default domain policies. If a user was previously getting policies based on group membership and default policies exist, the client now processes only the default policies.

For detailed information on Windows 2000 security, see the security-related white papers at: http://www.microsoft.com/ntserver .


APPENDIX A:

FREQUENTLY ASKED

QUESTIONS

This section presents frequently asked questions on Group Policy.

Infrastructure—Server side

What happened to File Deployment?

This feature is not part of Windows 2000. The ability to redirect folders has been retained.

Is it possible to set up individual computer or user policies?

You can indirectly set up any Group Policy for computer and user objects. You cannot set up any Group Policy directly on a computer or user. A Group Policy

Object can only be associated with sites, domains, and organizational units (OUs).

After this is done, you can filter the effect of the Group Policy Object by using security groups and discretionary access control lists (DACLs). This can have the effect of applying Group Policy to a specific computer or user without the performance loss it would take to associate Group Policy Objects with computer or user objects.

Do Group Policy Objects linked to a site container affect all computers in a forest of domains (Enterprise)?

GPOs linked to site containers affect all computers in a forest of domains. Site information is replicated and available between all the domain controllers within a domain and all the domains in a forest. Therefore, any Group Policy Object that is linked to a site container is applied to all computers in that site, regardless of the domain (in the forest) to which they belong. This has the following implications:



It allows multiple domains (within a forest) to get the same Group Policy Object

(and included policies), although the Group Policy Object only lives on a single domain and must be read from that domain when the affected clients read their site policy.



If child domains are set up across wide area network (WAN) boundaries, the site setup should reflect this. If it does not, the computers in a child domain will be accessing a site Group Policy Object across a WAN link.

How does one set up policies on a site?

First, start the Active Directory Site and Services Manager snap-in.

To start the Active Directory Site and Services Manager tool

1. From the Start menu, click Programs .

2. Click Administrative Tools , and then click on Active Directory Site and

Services Manager .

Next, you add the site(s) you want to use.

To add new sites, use the Active Directory Site and Services Manager

1. Right-click Sites in the tree in the left pane of the console, and click New .

2. Click Site , and type in a name for the new site (for example, type NewYork ).


If presented with a Default Site Link, you may wish to associate this site to a

Site Link at this time.

Figure 9. Creating a new site

You can now move computers from other sites into this site (under the NTDS

Settings container).

Following the creation of site(s), you need to create the subnet(s) that are in a site.

A site can span multiple subnets, but a subnet cannot span multiple sites.

To create a subnet

1. Right-click on Subnet .

2. Click New Subnet .

3. In the Name: text box, type the network address of the subnet (that is, the base address of the subnet in dotted notation) and the number of bits to be masked, counting from the left to the right.

For example, type 164.110.30.0/24 , which would translate to 164.110.30.0 with a mask of 255.255.255.0.

4. Click on the site that you want to associate with that subnet in the box below.

5. Click OK .

After you have defined the site(s) and linked to a subnet(s), you can apply policy to the site by right clicking on the site name and choosing the Properties page. The rest of the GPO creation is exactly the same as for a domain or OU.

The following are some issues that you need to consider for sites that impact your


policies.

If you create the site(s) prior to DC promotion, your DCs is automatically placed in the correct sites.



If you create the sites(s) after DC promotion, you must manually move the DC to the correct site. The DC must then be rebooted. Do this by drilling down into the site to the server container. Inside the server container is a list of DCs thought to be in that site. To move a server to a different site, right-click on the server, and choose Move . Then click on the site to which you want to move the server.



Replication times between all DCs will then happen on site replication times.

The default site replication time is six hours. To change it, go to the default site link, into the IP link, and change the cost and minutes for replication. This will have a major impact for policy, as explained next.

For example, assume that you leave replication to six hours or change it to an even longer period. You then create a new OU in a domain spanning several sites. If the PDC of the DS is different from the PDC of policy, you might have to wait six hours or longer for that new OU to replicate to the policy PDC before you can create policy. This is not certain to happen, but it is a possibility you should consider.

One way to get around this is to use the Replicate Now feature. To use this feature, you would have to go to every server container in the different sites, and drill down to the NTDS settings. Inside the NTDS settings, you will see different links between servers. If you right-click on the links, you will see the Replicate Now feature.


In which domain in the Enterprise (forest) is a site-linked GPO stored?

By default, creating a new GPO for a site stores that GPO in the Enterprise Root domain. If this not what you want, you can select a GPO specifically created in another domain.

To select a GPO that already exists in another domain

1. From the Group Policy tab of the appropriate site, select Add .

2. Select the appropriate domain in the Look in drop-down list.

3. Select the GPO you want to use.

4. Click OK .

The GPO will be linked to the current site.

If the GPO does not yet exist, you can create one in the appropriate domain.

To create a new GPO in a domain

1. Select Add (not New ) from the Group Policy tab of the site that you want to use.

2. Select the All tab.

3. Select the appropriate domain in the Look in drop-down list.

4. Either right-click and select New , or click the New GPO toolbar button.

5. Give the new GPO a friendly name.

6. Select OK .

The GPO will be linked to the current site.

What are the inheritance rules for Group Policy and the Active

Directory?

Group Policy is processed in the following order: Local Group Policy Object, site, domain, OU, and so on. This means that the local Group Policy Object is processed first, and the OU to which the computer or user belongs (the one that it is a direct member of) is processed last. All of this is subject to the following exceptions:



Any domain-based Group Policy Object (not local GPO) may be enforced so that its policies cannot be overwritten. When more than one GPO has been marked as enforced, the GPO that is highest in the Active Directory hierarchy takes precedence.



At any site, domain, or OU, Group Policy inheritance may be selectively designated as Block Inheritance . However, blocking inheritance does not prevent policy from enforced GPOs from applying; this is because enforced

GPOs are always applied, and cannot be blocked.

How does one use security groups to modify the scope of a GPO?

You can filter the scope of a GPO by using the Security tab on the GPO

Properties page to set discretionary access control list (DACL) permissions and select an access control entry called Apply Group Policy.

This filtering can only be done by using membership in security groups (such as domain, local, and global). Using non-security groups (those of distribution types


like Universal) does not work because of the effect such processing would have on performance. For example, consider the effect of processing 100 to 200 groups and compare that to doing an access check on an access control entry and applying

Group Policy using only the ones that are accessible. Prior to the Beta 2 release of the product, this was done with the read access control entry; in the current release, this is done with the Apply Group Policy access control entry.

You can access the Security tab on the Properties page of a GPO. Right-click a

GPO from the list of GPOs on a given site, domain, or OU, click Properties , and then click Security . You can also access the Security tab at the root node after the

Group Policy snap-in has been opened on a specific GPO.


If you apply policies to an OU that contains only groups (of any kind) and no users, are the policies applied to the members of the group?

No, Group Policy (GPOs) are applied only to the users and computers that are members of the organizational unit. A different mechanism is used to filter the effect of GPOs, based on membership in security groups. The preceding question addresses this issue.

How does one delegate authority for editing a GPO?

For information, see the section on Delegating Control of Group Policy Objects .

What are the default security discretionary access control list settings for GPOs?

See the Delegating Control of Group Policy section for information on this topic.

Can a user or administrator that has only read access (no write access) to a GPO use the Group Policy snap-in to view the settings that it contains?

No, every extension to the Group Policy snap-in assumes that it has write access to the GPO storage locations. Therefore, the Group Policy snap-in does not open a

GPO when the current user does not have write access to it.


Policy

What policy settings are in the Default Domain Policy GPO?

The following table lists the policy settings contained in the Default Domain Policy

GPO .

Value Description

Disable System Policy (use Group Policy only) 1 Prevents application of System Policy. This is policy established using the Windows NT 4.0 System Policy

Editor, Poledit.exe, and read from NTConfig.pol on the

Netlogon share.

EFS Recovery Certificate

Kerberos Policies

MaxTicketAge

MaxRenewAge

MaxServiceAge

MaxClockSkew

10

7

60

5

Maximum user ticket lifetime (in hours).

Maximum lifetime that a user ticket can be renewed (in days).

Maximum service ticket lifetime (in minutes).

Maximum tolerance for synchronization of computer clocks (in minutes).

Enforce user logon restrictions. TicketValidateClient

System Access

Account Policies, Password Policy

MinimumPasswordAge

MaximumPasswordAge

MinimumPasswordLength

PasswordComplexity

1

0

0

0

42

No minimum password age.

Maximum password age.

No minimum password length.

No password complexity.

PasswordHistorySize

RequireLogonToChangePassword

ClearTextPassword

System Access

Account Policies, Lockout Policy

LockoutBadCount

1

0

0

Password history size.

No require logon to change password.

No clear text password.

0 No account lockout.

What policy settings are in the Default Domain Controllers Policy GPO?

The following tables list the policy settings in the Default Domain Controllers

Policy GPO .

Registry Value

Digitally sign server-side communication when possible

Default

Enabled

Comments

Located in

Machine\System\CurrentControlSet\Services\LanManServer\Parame ters\EnableSecuritySignature.


Audit Policy

Audit Account Logon events

Audit Account Management

Audit Directory Service Access

Audit Logon Events

Audit Object Access

Audit Policy Change

Audit Privilege Use

Audit Process Tracking

Audit System Events

0

0

0

0

0

0

0

Defaults

0

0

Comments

Default is No Auditing.









Note: All the following Users Rights policy settings in the Default Domain

Controllers Policy GPO are set when the first domain controller is created, either during an upgrade of a Windows NT 4.0 domain controller or when a stand-alone server is promoted to a domain controller (by running DCPromo from the command line).

User Rights Defaults:

Add = This User Right is added for these security groups.

Remove = This User Right is removed for these security groups.

Comments

Add . The security groups listed in the Defaults column are added to any users or groups which had this User Right on the server prior to

DC promotion.

Remove . Some security groups are removed. For example, if the

Power Users group was previously given this privilege on the server, it is removed when the server is promoted to a DC because Power

Users do not exist on domain controllers

Access this computer from the network

Add : Administrators, Authenticated

Users, and Everyone.

Remove : Backup Operators, Power

Users, Guests, Guest, and Users.

Act as part of the operating system Remove : Power Users.

Add workstations to the domain

Back up files and directories

Bypass traverse checking

Change the system time

Remove : Power Users.

Add : Administrators, Backup

Operators, and Server Operators.


Add : Administrators, Authorized


Remove : Backup Operators, Power

Users, and Users.

Add : Administrators, and Server

Operators.



User Rights

Force shutdown from a remote system

Generate security audits

Increase quotas

Lock pages in memory

Log on as a batch job

Log on as a service

Log on locally

Modify firmware environment variables

Create a pagefile

Create a token object

Create permanent shared objects

Debug programs

Increase scheduling priority

Load and unload device drivers

Manage auditing and security log

Defaults:



Add : Administrators.






Add : Administrators, and Server

Operators.












Add : Account Operators,

Administrators, Backup Operators,

Server Operators, and Print

Operators.

Remove : Power Users, Authorized

Users, Guests, Guest, Users, and

Everyone.





Comments


DC promotion.



Users do not exist on domain controllers.


User Rights Defaults:



Comments


DC promotion.



Users do not exist on domain controllers.

Profile single process

Profile system performance





Replace a process-level token

Restore files and directories

Shut down the system

Take ownership of files or other objects


Add : Administrators, Backup

Operators, and Server Operators.


Add : Account Operators,

Administrators, Backup Operators,

Server Operators, and Print

Operators.

Remove : Power Users,

Authenticated Users, Guests, Guest,




Remove : Power Users. Deny Logon Locally

Deny logon as a batch job

Deny logon as a service



Deny Access to this computer from network


Remove Computer from Docking

Station


Remove . User Rights for Power

Users and Users are removed.

Synchronize directory service data Remove : Power Users.

Enable computer and user accounts to be trusted for delegation


Remove : Power Users and Users.


What are the names of the snap-in extensions to the Group Policy snapin, and what are their actual file names?

The following table lists the Group Policy snap-in extensions and their file names.

Group Policy snap-in extension File name


Security Settings

Scripts


Gptext.dll

Wsecedit.dll

Gptext.dll

Appmgr.dll

Folder Redirection Fde.dll

How does one copy a GPO from one domain to another?

The copy and paste support functionality is being investigated as of the Beta 3 release of the product. When this information becomes available, it will be published as part of the Windows 2000 Resource Kit documentation.

Why can't one delete the default GPO (Default Domain Policy), no matter which administrative group one belongs to?

By default, the Delete access control entry has not been allowed to the

Administrators groups. Administrators do have all other rights. The reason for this is to prevent the accidental deletion of this GPO, which contains important and required settings for the domain. If it is truly required that the GPO be deleted because the settings have been set in other GPOs, the Delete access control entry must be given back to the appropriate group.

Does Group Policy use the Operations Master?

The Group Policy snap-in uses the primary domain controller emulator Operations

Master token when editing a GPO. For information, see Group Policy Snap-in and the Operations Master .

GPOs do not replicate beyond a domain. Yet, there are instances in which enterprise policy needs to be applied to all domains within an enterprise. What is the best method of copying or replicating policies between domains?

No part of the GPO is replicated outside of a domain. The ability to have enterprisewide GPOs and the ability to copy GPOs will be considered for the next release of

Windows 2000 Server.

It is possible to establish a link to a GPO in a domain other than your own. Use the

Add button on the target site, domain, or OU Group Policy Properties page. Use the Look in list box to navigate to the domain in which the GPO exists; then browse to it, and select it. There are performance implications associated with linking GPOs across domains. All computers and users affected by the cross-domain linked GPO must access the other domain and pull the GPO information from it. It is, therefore, important to consider WAN issues before you establish such a link.


Why are users and computers in the Container class, whereas domain controllers are in the Organizational Unit class?

Why can’t one set Group Policy for objects of the Container class (like users and computers)?

This section presents a brief description and comparison of the Container and

OrganizationalUnit object classes, and the Users and Computers objects in

Windows 2000.

Container and OrganizationalUnit Classes

Container is an object class intended for generic containment, for example, a container is used for grouping related things together without any other implied semantics. OrganizationalUnit is an object class intended for modeling organizations (hence the name).

Traditionally, directories have been organized as hierarchies of OrganizationalUnit

(OU) objects, with the top of the organization being an OU named something like

Corporate HQ , and including child OUs for geopolitical or functional divisions, for example, Europe, North America, or Sales, Accounting, and so on.

Users and Computers Objects

Windows 2000 fully supports the hierarchical organizational model described above.

However, Windows 2000 must also provide backward compatibility with earlier versions of Windows NT. To do this, the Active Directory provides a predefined structure that includes a place to put migrated user and computer accounts. These are the Users and Computers containers, respectively. When a Windows NT 4.0 or

Windows NT 3.51 domain is upgraded to Windows 2000, the user accounts and groups are moved to the Users container, and the computer accounts are moved to the Computers container. These containers are not part of any organizational chart; they are simply used for generic containment, and thus they are of class Container and not class OrganizationalUnit.

Group Policy: Sites, Domains, and OUs

The Group Policy infrastructure for Windows 2000 exposes Group Policy on site, domain, and OU objects. These are the object classes that Windows 2000 installations most commonly use for delegated administration. Keeping the number of object classes that explicitly support Group Policy to this small set keeps the scope of testing manageable, without overly constraining the use of Group Policy for management.

Domain Controllers OU

Strictly speaking, domain controllers should be class Container, rather than class

OrganizationalUnit, but to support Group Policy directly without expanding the number of test and documentation scenarios, the simplest course was to make domain controllers class OrganizationalUnit.

Plans for Tighter Active Directory and Group Policy Integration

A future release of Windows may extend Group Policy support to all object classes.

The same release will change the object class of domain controllers from


OrganizationalUnit to Container, making it consistent with the Users and Computers objects. This change will affect only new installations. Windows 2000 clients will be unaffected by this change.

Infrastructure—Client side

How does one get more information into the Event log of a client computer regarding the processing of Group Policy?

A preference exists that may be set for this purpose by using the Poltest.exe tool.

You can also set a policy for this by using the Group Policy snap-in. See the

Troubleshooting section of this appendix for more verbose logging information.

In what order are policies processed during computer startup and user logon?

The policy processing sequence is the following:



The network starts

—Remote Procedure Call System Service (RPCSS) and

Multiple UNC (Universal Naming Convention) Provider (MUP) must be started.



Apply computer Group Policy

—this is done synchronously by default.



Run startup scripts

—these are run hidden and synchronously by default. This means that each script must complete or time out before the next one starts.



CTRL+ALT+DEL is pressed.



After the user is validated, the profile is loaded.



Apply user Group Policy

—this is done synchronously by default. Group Policy is processed in the following order: Windows NT 4.0, local, site domain, OU, and so on. UI is displayed while policies are being processed.

Note: Windows NT 4.0 style policies process both computer and user settings, potentially overwriting the Active Directory–based Group Policy settings that were applied at computer startup.



Run logon scripts

—Group Policy–based logon scripts are run hidden (unlike in

Windows NT 4.0) and asynchronously by default. The user object script, which is run in a normal window (like Windows NT 4.0), is run last.



Start the shell.

Notes: Policy settings exist for reversing the synchronous or asynchronous defaults for running scripts and applying policy. For more details on policy options for scripts see the Scripts section of this paper.

By default, scripts time out after 600 seconds. A policy setting exists that lets you change this default.

Policy settings also exist for specifying whether scripts are run hidden, minimized, or in a normal window.

You can specify a Group Policy to disable Windows NT 4.0–style policies.


How often is Group Policy applied, and how does one change it?

For users and all computers (except domain controllers), policy is applied by default every 90 minutes with a variable offset of 30 minutes. For domain controllers, the default is every 5 minutes. You can change these defaults by setting a Group Policy within the Administrative Templates node of the Group Policy snap-in.

The application of Group Policy cannot be scheduled or pushed to clients.

Exceptions to this include the Software Installation and Folder Redirection snap-ins.

The Scripts extension runs, but the scripts are actually run by Winlogon at the appropriate time.

How long does it take to process Group Policies?

This depends on the number of GPOs being processed for a specified computer or user and on the number of policies set with each GPO.

A great deal of work on performance of Group Policy is in progress for the Beta 3 release of the product. At the time of this writing, no metrics have been collected yet. When those metrics are obtained, that information will be made available.

What happens to Group Policy when the Group Policy Template (data stored on sysvol) and the Group Policy Container (data stored in the

Active Directory) portions of the GPO are not synchronized?

Lack of synchronization between the Group Policy Template and Group Policy

Container portions of the Group Policy Object can occur temporarily because of the differences in the replication schemes used by the Active Directory and the File

Replica Set (FRS

—for system volume data). When this occurs, each Group Policy snap-in properly handles the fact that the Group Policy Template and Group Policy

Container are unsynchronized.

For those Group Policy extensions that store data in only one data store (the Active

Directory or Sysvol), there is no issue with information being unsynchronized. 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 (the Active

Directory and Sysvol), the extension must properly handle the possibility that the data is unsynchronized. This is true for extensions that need multiple objects in the

Active Directory (or files on the Sysvol folder) to be atomic in nature, since neither storage location handles transactions. An example of an extension that stores data in the Active Directory and Sysvol is Software Installation. The script files are stored on Sysvol and the Windows Installer package definition is in the Active Directory. If the script exists, but the corresponding Active Directory components are not present or are incomplete, the application installation fails gracefully. If the script file is missing, the knowledge of the package is not available, and nothing is done.


Is Group Policy applied during a RAS connection or during a slow link?

Group Policy is applied during RAS and slow connections as follows:

User and Computer Group Policy is applied during a RAS connection, when using the Logon using RAS checkbox on the logon prompt, when the computer is a member of the domain that the RAS server also belongs to or is trusted to. When the logon is done with cached credentials, and then a RAS connection is established, Group Policy is not applied.

Group Policy is not applied to computers that are members of a foreign domain or a workgroup. Although the connection may still be made, access to domain resources may be affected (because of mismatched IPSec security).

By default, registry-based Group Policy is always applied (and cannot be turned off). Security settings are also applied by default, but all others are not applied. For all but the registry settings, you can specify whether the default behavior should apply or not by using a policy setting.

RAS does not necessarily imply a slow link, nor does a LAN necessarily imply a fast link. A slow link is by default based on the algorithm described in the Group Policy and Network Connections (Slow Links) section of this paper.

By default which Group Policy Client -side extensions are processed when a slow link is detected?

When a slow link is detected, the registry (Administrative Templates) and securityrelated (IP security, EFS recovery, and security settings) Client -side extensions are processed. The following Group Policy Client-side extensions are not processed during slow link connections:



Folder Redirection



Disk Quota



Scripts




Are there any policies that can be set to control this behavior?

You can specify policy settings to define when the following policies are updated:



Registry in the Administrative Templates folder.



Security under the Windows Settings\Security Settings node.



EFS Recovery under the Windows Settings\Security Settings node.



IP Security in Computer Configuration\Windows Settings\Security Settings\IP

Security Policies on Local Machine.

More information is displayed about these policy settings when you click the

Explain tab.


How can an administrator change the default slow link behavior?

To define what a slow link means, administrators can use the Group Policy slow link detection policy setting under Computer Configuration\Administrative

Templates\System\Group Policy for computers, and User

Configuration\Administrative Templates\System\Group Policy for users.

In Windows NT 4.0, system policies typically 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. Is this also the case in Windows 2000?

The persistent registry settings (tattooing) effect has been changed in Windows

2000; however, it is possible for it to occur, as explained in the next Note entry.

For 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 .

Setting registry values in these specific locations 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.

Note: 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. Doing this still causes persistent registry settings (tattooing effect), as described previously.

Which policies does one see when viewing the policies set when the

Group Policy snap-in is run focused on a local computer?

This shows the information in the local Group Policy Object, but not the cumulative effect of what has been applied to the computer or user. This feature will be investigated for the next release of the product. For Windows 2000, it shows the settings that a local administrator has set for that computer and all users of that computer. In the evaluation process, when the computer is joined to a domain, all the policy settings are subject to being overwritten by domain-based policy (any policy set in the site, domain, or OU).


Group Policy Snap-in

Why aren't the settings under Administrative Templates integrated into the Windows Settings and Software Settings namespaces?

The Group Policy snap-in is a hosting tool for MMC snap-in extensions. All nodes in the Group Policy snap-in are snap-in extensions. The user interface of the

Administrative Templates snap-in extension is driven solely by administrative template files (.adm files). Because of this, the Administrative Templates user interface cannot be integrated with the same namespace as the other Group Policy snap-ins. More information is available in the Administrative Templates section of this paper.

Are there some shortcuts to navigating the Administrative Templates namespace?

You can use the following keyboard shortcuts to navigate the Administrative

Templates namespace:

SHIFT+asterisk ( * ) (on the keypad) automatically expands the current node and all of its child nodes.

The plus sign (+) (on the keypad) expands one level.

Minus ( ) (on the keypad) collapses one level.

Double-click on a Policy in the results pane to bring up the floating Properties page.

When the floating Properties page is displayed, move it out from in front of the

Group Policy snap-in window. Then click back onto one of the Policies in the results pane. You can now use the cursor keys to navigate up and down the list. The information in the Properties page changes. This method also works for the

Explain text. You may also use the Tab key to move back and forth between tree pane and the results pane, while leaving the Properties page open.

Administrative Templates (.adm Files)

What is an .adm file? -

An .adm file is a template file used to define the user interface that an administrator uses to set registry-based policy (previously called Software Policies in the Beta 2 release).

An .adm file is extensible to allow independent software vendors and administrators to create custom Group Policy.

In Windows NT 4.0, the System Policy Editor (Poledit.exe) also used administrative template files; these files have been updated with Explain and Version tags for

Windows 2000. Windows NT 4.0 .adm files can be read and used in Windows 2000, although with certain caveats.


How does one change the .adm files that are being used for a GPO?

In the Group Policy snap-in console, you can add a template file by right-clicking the

Administrative Templates node, and clicking Add/Remove Templates . By default, the first time the Group Policy snap-in is started for a specified GPO, it copies the System.adm file (in the Beta 2 release, it was Winnt.adm and

Common.adm) from the current computer’s \%systemroot%\Winnt\Inf directory to the GPO.

Subsequently, only those .adm files specified in the list will be displayed. At each invocation, the Group Policy snap-in also checks the listed .adm files and copies any newer versions from the local computer's \%systemroot%\Winnt\Inf directory to the GPO.

What happens if one adds multiple .adm files that create the same namespace? With the same policy?

If the .adm file that you add includes a duplicate Category to one that is used in an existing .adm file, the policy settings are merged.

An error may occur under the following conditions. When the existing and the added

.adm file contain the same Category and both of them have a default KEYNAME specified (regardless of whether it is the same name), the following error message is displayed: "Key name specified more than once. Likely causes are: 1) the

KEYNAME tag is defined multiple times in this category, 2) this KEYNAME is already defined in another category with the same name, 3) this KEYNAME is already defined in another category with the same name in a different adm file."

What happened to the policies such as Logon Banner or Disable

CTRL+ALT+DEL that were available in Windows NT 4.0?

These and other policies that are security-related have been moved to the Security

Settings node, under Local Policies\Security Options. This includes the following policies:



Disable CTRL+ALT+DEL.



Do not display last user name in logon screen.



Message text, caption, title for users logging on (legal notice).



Allow system to be shutdown without having to logon.


Scripts

What is the interaction between scripts specified on the User object and those specified using Group Policy? What control does one have over the behavior of all types of scripts?

The following five script types exist:



Legacy logon scripts (those specified on the User object). Support for

Windows Scripting Host 7 scripts has been added in Beta 3. Windows Script

Host supports scripts written in Visual Basic Scripting Edition (VBScript) or

JavaScript. This means that you can now enter a command line like foo.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. A policy exists 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.



Group Policy logon scripts



Group Policy logoff scripts



Group Policy startup scripts



Group Policy shutdown scripts

By default, each of these script types runs asynchronously, and the window is hidden.

7

Windows Script Host serves as a controller of ActiveX scripting engines. With Windows Script Host, you can run scripts directly in Windows 2000 by clicking a script file on the desktop or by typing the name of a script file at the command prompt.


Policy in Computer Configuration\Administrative

Templates\System\Logon

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

Description

Run logon scripts synchronously

Run startup scripts asynchronously

Run startup scripts visible

Run shutdown scripts visible

Maximum wait time for Group Policy scripts

Policy in User Configuration\Administrative

Templates\System\Logon/Logoff


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.

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.

If this option is enabled, startup scripts run in a command window.

If this option is enabled, shutdown scripts run in a command window.

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.

Run legacy logon scripts hidden

Run logon scripts visible

Run logoff scripts visible

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.

If this option is enabled, legacy logon scripts will run in hidden mode.

If this option is enabled, logon scripts run in a command window.

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. In the case of a script running in a minimized window, if the user selects the window, its processing can be stopped.

Security Settings

How are restricted groups processed?

The following dialog box options are available when configuring restricted groups.

Members of restricted group:

Membership is strictly enforced. For a specified restricted group, any user or group that is included in that restricted group’s member list is added to the group. Any user or group that is currently a member of the group but not listed in the restricted


groups’ member list is removed. For the Beta 3 release of the product, if the member list is empty, no action is taken. For the shipping version of Windows 2000, if the members list is empty, all current members of the group are removed.

Restricted group is member of:

Only inclusion is enforced in this case. If the restricted group should belong to a group but does not, the restricted group is added to that group. The restricted group is not removed from other groups that it currently belongs to.

Is it possible to have different password policies in effect for different

OUs?

No. Password, lockout, and kerberos policies are applicable at the domain level only. Domain controllers ignore password, lockout, or kerberos policies defined at an OU or LGPO level.

When using the Security Settings snap-in extension to set User Rights

Assignments and Restricted Groups using specific users (rather than groups of users), it seems to work fine until the Username is changed.

Then, the application of those settings is lost. What is the reason for this?

If a name is used for assigning either User Rights Assignments or Restricted

Groups, it is stored as the name, rather than the security identifier (SID), which uniquely identifies users or groups). Therefore, when the name is changed, the knowledge of User Rights Assignment and Restricted Groups is lost because the name has been saved, rather than the SID, in the .inf file in the GPO. In essence,

User Rights Assignments and Restricted groups are not rename-safe.

The suggested work-around is to use groups for User Rights Assignments and

Restricted Groups. While technically groups are not re-name safe either, the impact can be managed better due to the lower frequency of change. This would be an administration best practice, that is, even when this is fixed, groups would still be the preferred way to accomplish this. Therefore, groups should be used, even if administrators have to create a group to hold a single name.

This issue will be addressed before Windows 2000 is shipped.

Note: The following section is intended to provide information for people who have been using User

Manager to configure security policies in the past to move to the new model of Group Policy for editing and configuring security policies.

The area of security policies has been significantly enhanced. It allows you to configure many more security attributes than it did in the previous releases of the product. It is therefore recommended that you spend some time understanding the Group Policy architecture and learning about security policies in the Windows 2000 Server online Help documentation.

How does one change password policy for the domain?

Start the Active Directory Users and Computers snap-in. Right-click, and select

Properties on the domain node. Select Group Policy . Double-click the Default

Domain Policy to bring up and edit this GPO. In the Group Policy snap-in console,


navigate to Computer Configuration , Windows Settings , Security Settings ,

Account Policies , and then Password Policy . You can then make changes. Note that you can set the password policy in any domain-scoped GPOs, not just the

Default Domain Policy GPO.

How does one change auditing policy or user rights for the domain controllers?

These local policies (audit policy, user rights, and so on) can be different on different DCs, unlike in previous releases of the product. However, they are the same by default on all DCs in the domain. This is because all domain controllers are in the same OU within the Active Directory

– in the Domain Controllers OU. To modify these policies you should not use Group Policy on the local computer, unless you are sure that the particular DC is not getting its policy from the Active

Directory. In most cases (including the default), start the Active Directory Users and

Computers snap-in. Right-click Domain Controllers OU , and select Properties .

Select Group Policy . Double-click the Default Domain Policy GPO to edit it. In the

Group Policy snap-in console, navigate to Computer Configuration , Windows

Settings , Security Settings , Local Policies , and then click either Audit Policy or

User Rights to modify these policies.

How does one change password policy locally on the workstation or member server (non-DCs)?

If the workstation or member server is joined to a domain, it is enforcing the domain's password policy by default. A resource joined to the domain adheres to domain policies (this is how it works in the Beta 3 release of the product). If this does not meet your requirements, you can decide not to be part of the domain.

Otherwise, if you do not want the domain password policy, you have to set the

DACL on the domain GPO so that the computer cannot apply the policy.

Regardless of where the computer is, it always gets the domain GPO unless the domain GPO is restricted or disabled.

See Using Group Policy on Stand-alone Windows NT

–based Computers

for more information on computers that are not participating in a domain.


How does one configure local policies (auditing policy, user rights) on the workstation or member server (non-DCs)?

By default, workstations and member servers are allowed to define their own local policies (such as audit and user rights). This is because of the definition that these are local policies. See Using Group Policy on Stand-alone Windows NT-based

Computers for more information.

I modified the security policies as suggested above; however, they are not taking effect. How does one find out what is happening?

The following issues could affect this:

The Group Policy model specifies that any policies configured locally may be overridden by like policies specified in the domain. Start the Group Policy snap-in by clicking Start , pointing to Run , typing mmc , and then adding the Group Policy snap-in from the list of available snap-ins. Then choose Local Computer in the

Group Policy dialog box to focus on the Local Group Policy Object. In the Group

Policy console, navigate to System Tools , Group Policy , Computer

Configuration , Windows Settings , Security Settings and check that the

Effective Policy option is set for Local Policy . If your setting shows up in local policy but not in effective policy, it implies that there is a policy from the domain that is overriding your setting.

The Group Policy model applies policy changes periodically; therefore, it is likely that the policy changes made in the directory have not been made (by policy refreshing) to your computer yet (DCs, or workstations, or servers). To manually do a policy refresh, type the following at the command line:

> secedit /refreshpolicy MACHINE_POLICY

This could result from some mis-configuration, such as the GPO modified did not apply to the computer, for example. See the information on Group Policy to troubleshoot this problem; you can view the log file on

%windir%\Security\Logs\Winlogon.log to check if the GPO you modified is actually being processed on the the computer.

What is the Add a workstation to domain logon right, and how does it relate to delegating similar permissions on the directory?

Add workstation to domain is a legacy user right (a privilege) which when given to users on domain controllers allowed them to join computers to the domain. The privilege was used because permissions on a domain were not modifiable in previous releases. The right is, and always was, meaningless on non-DC computers. This user right is supported for upgrade compatibility and has exactly the same behavior as it had in Windows NT 4.0.

In Windows 2000, the recommended way to allow a user or group to join computers to a domain is by giving that user (preferably a group) the permission to Create

Computer objects in the Computers container. This can be done by using the

Delegation Wizard or the Security tab on the Properties page of the Computers container in the Active Directory Users and Computers snap-in. Doing so allows the


user to join computers to the domain.

Note: The preceding method should not be allowed indiscriminately because allowing users to create computers in the domain is similar to allowing users to create user accounts in the domain. Computer objects are like user objects; they can be used to do network authentication and, hence, access resources over the network.

The best security practice would be to delegate this ability to a group, for example,

Computer Joiners. Then, add a few identified, trusted users into that group so that only those users can create computer objects. Now these Computer Joiners can join new computers as well as pre-create computer objects such that users who do not have the ability to create computers themselves can then join their computers to the pre-created computer objects (just like with Windows NT 4.0).

General Issues

Do Policies migrate from Windows NT 4.0 to Windows 2000?

Policies do not migrate from Windows NT 4.0 to Windows 2000.

We cannot migrate Windows NT 4.0 policies to Windows 2000. In Windows NT 4.0, system policies were stored in one .pol file with group information embedded; no method is available to translate that information to the Windows 2000 Active

Directory structure. Groups are handled very differently in Windows 2000.

Windows NT 4.0 clients on Windows 2000 Server and Windows 2000 Professional computers on Windows NT 4.0 server will continue to work as they did before, using the Netlogon share.

With Windows 2000 Server, when a Windows NT 4.0 client is upgraded to Windows

2000, it will get only Active Directory based Group Policies and not Windows NT

4.0

–style policies.

Note: Although Windows NT 4.0–style policy may be turned on (using a Group Policy setting) if the administrator chooses to do so, this practice is strongly discouraged. Windows NT 4.0–style policies are applied during user logon only. This means that both computer and user settings are processed.

This is not optimal behavior for the following reasons:

 The Windows NT 4.0–style computer settings override the group Policies that have already been applied to the computer during startup.

 During the Group Policy refresh cycle, the Group Policy–based policies change any conflicting settings back. This creates an indeterminate state.

 Windows NT 4.0–style policies result in persistent settings in the registry (tattooing).

 Terminal Server cannot allow computer settings to be set based on a user logon.


How does one determine the resultant set of policies for a computer and user?

Originally, Microsoft planned to work with ISVs to build tools that would do resultant set of policy (RSoP). In August of 1998, Microsoft hosted several ISVs for a week, giving them access to the information that would allow them to build such tools.

Several ISVs began actively developing tools that enhance the usability and usefulness of Group Policy, including the much needed RSoP tools. The feedback from these ISVs indicated that the current methods of exposing the required information to build such tools are not conducive to building fully capable tools. Over the last several months Microsoft has worked on methods of providing a consistent interface that ISVs could use and at the same time not impact the shipping date of

Windows 2000.

Plan

Concurrent with the existing development effort for Group Policy, Microsoft is starting a parallel effort to work on an isolation layer that exposes all Group Policy data by using a standard schema. The Window Management Instrumentation

(WMI) 8 technology and schema will be used to implement this interface to the

Group Policy data. The intent is that all Group Policy-based tools (that is, the RSoP tools and all the Group Policy snap-in extensions) will migrate to using this interface.

Using this approach provides:



An isolation layer between the data and the snap-ins providing the data, making it easier to maintain the snap-ins.



A consistent data interface for developers to use when creating RSoP tools.



An extensible method for other snap-ins to use, providing immediate benefit from the tools.

In addition, Microsoft will build a basic administrator's RSoP tool that uses the WMIbased infrastructure and provides the following capabilities:



Generates the actual RSoP for a given target, for example, a particular computer or user. This addresses the question of which policies were applied.



Views the potential state. This answers the question of which policies are applied given a particular target, for a user, a computer, and a user on a specific computer.



Indicates the source GPOs for each of the resultant policies.

The goal is to make the WMI-based snap-ins and this basic RSoP tool available shortly after Windows 2000 ships. The exact dates and shipping vehicle are yet to

8

The Windows Management Instrumentation is an implementation of the Desktop Management Task Force’s

(DMTF) Web-based Enterprise Management (WBEM) initiative, which provides standards for accessing and sharing management information in an enterprise environment.


be determined. Microsoft will continue to work with ISVs to ensure that we are providing everything developers require to build the additional feature-rich tools that our customers are requesting.

Do Group Policies override User Profile settings?

Yes.

Where is the System Policy Editor (Poledit.exe) located, and why would one need to use it?

The Windows NT 4.0 System Policy Editor, Poledit.exe, is located in the

%systemroot% directory. The Windows NT 4.0

–style .adm files will be located in the

%systemroot%\inf directory (the same location as in Windows NT 4.0). The System

Policy Editor user interface is not exposed in Windows 2000 server. Poledit.exe will still be needed to create registry-based policies for all down-level clients (Windows

NT 4.0, and Windows 95 and 98 computers).

To create a properly formatted .pol file for Windows 9x, Poledit.exe must be run on a Windows 9x client. For more details about this process and Windows NT 4.0

System Policy, see the white paper titled Implementing Profiles and Policies for

Windows NT 4.0

, available at: http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies

.asp

.

For Windows NT 4.0 and Windows 2000, Poledit.exe may be run on either system.

The resultant .pol file must then be copied to the domain controller's Netlogon share.

Is there a programmatic way to add, edit, or delete GPOs?

N o process is available to script Group Policy Objects. However, you can programmatically add, edit, or delete GPOs by using the IGroupPolicyObject interface defined in the Gpedit.h file. For details on the Group Policy APIs, see the

Microsoft Platform SDK at: http://msdn.microsoft.com/developer/sdk/platform.htm

.

Troubleshooting

What causes the Failed to open the Group Policy Object error?

The most likely causes for this error are network-related. Check the DNS configuration for the following:



Make sure that there are no stale entries in the DNS database.



Resolve local DNS servers and ISP DNS server entries.

Example

The following is an example of a network-related problem and the correction for it.

The DNS settings for my local LAN card pointed to two DNS servers:



+ First entry: The local (and even the same computer) DNS server.



+ Second entry: The DNS Server of my ISP


If I tried to ping my domain <domainname>.<Zonename>, for example,

(testdom.mycomp.com), a message indicates that this is an unknown host. Even with correct local DNS entries, the ISP DNS server does not know anything about testdom.mycomp.com, so there is a difference in their databases.

Correction

To resolve this error, remove the second entry with the ISP DNS server, and add the ISP DNS server IPAddress to the forwarders in the local DNS server.

How does one turn on verbose logging to the Event Viewer?

The Group Policy Client-side Engine supports verbose mode logging to the Event

Viewer log. Enabling the RunDiagnosticLoggingGlobal or

RunDiagnosticLoggingGroupPolicy keys turns on Verbose Diagnostic Logging for Winlogon. The other keys listed below are included for completeness. This is how verbose logging of events works in the Windows 2000 Server Beta 3 release; this may be modified in future releases of the product.

HKLM\Software\Microsoft\Windows

NT\CurrentVersion\Diagnostics\RunDiagnosticLoggingGlobal


NT\CurrentVersion\Diagnostics\RunDiagnosticLoggingGroupPolicy


NT\CurrentVersion\Diagnostics\RunDiagnosticLoggingIntelliMirror


NT\CurrentVersion\Diagnostics\RunDiagnosticLoggingAppDeploy

REG_DWORD 0, 1

0 = Normal logging (as done today in NT4)

1 = Verbose logging (similar to that used with debug DLLs)

Default is 0 (or value missing completely)


APPENDIX B:

ADMINISTRATIVE

TEMPLATES

.adm file

The following table lists the .adm files included in Windows 2000 and their intended use.

Use Description

System.adm

Inetres.adm

Winnt.adm

Common.adm

Windows.adm

Windows 2000

Windows 2000

Windows NT 4.0

Loaded by default.

Loaded by default.

Use with System Policy Editor,

Poledit.exe.

Windows NT 4.0 and Window 95 and Windows 98 Use with System Policy Editor,

Poledit.exe.

Window 95 and Windows 98 Use with System Policy Editor,

Poledit.exe.

All the policy settings in the System.adm and Inetres.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. For more information, see the section entitled Registry Key Locations for Policy.

By default, only settings defined in the loaded .adm files that exist in the policies trees are displayed. 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 (uncheck) 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 made to not Show Policies Only , the icon for those settings is displayed in red, and true policies are displayed in blue.

Note: Because of the persistent (tattooing) nature of non-policy settings, they should be avoided.

Creating Custom .adm Files

To define the user interface settings that administrators can configure, the Group

Policy snap-in uses either administrative templates (.adm files) or MMC extension snap-ins to the Group Policy snap-in. You can create custom .adm files to extend the capabilities of the Group Policy snap-in. The following sections present information on the ADM language and components:

The .adm file:



Is a Unicode file and should be created and edited using a Unicode-capable editor such as Notepad.



Defines a hierarchy of categories and sub-categories that together specify the registry settings that can be modified using the Group Policy snap-in UI.



Indicates the registry locations where changes should be made in case of a particular selection.



Specifies any options or restrictions (in values) associated with a certain


selection.



In some cases, specifies a default value to use if a selection is activated.

Adding .adm Files

To add your .adm files, select Administrative Templates under either the

Computer Configuration or the User Configuration node in the Group Policy

MMC snap-in console, and then select Add/Remove Templates from the Task menu.

When you add an .adm file, that file is added to the

Sysvol\Domain.name.com\Policies\{GPO_GUID}\ADM folder of the currently selected Group Policy Object. The Group Policy snap-in namespace is defined by the hierarchy of category and sub-category names specified in the .adm file. Node names that are identical, but appear in different .adm files, are displayed only once in the namespace. This differs from the way System Policy Editor works; System

Policy Editor displays them more than once in such cases.

Namespace Naming Conventions

When you create custom entries in an .adm file for the Administrative Templates node, you should create the namespace using the \ CompanyName \ Product \ Version

(or \ CompanyName \ Product&Version ) naming convention that is also used in the registry.

Registry Key Locations for Policy

The following are registry key locations that are cleaned up if a policy should no longer be applied; other keys are not cleaned up. You should make sure that you use these keys for policy when writing custom .adm files:



HKEY_LOCAL_MACHINE\Software\Policies (for computer policy)



HKEY_CURRENT_USER\Software\Policies (for user policy)

The following two older registry keys are also cleaned up. However, you should not use these keys in your new policies.



HKCU and HKLM



\Software\Microsoft\Windows\CurrentVersion\Policies

Note: Modifying registry keys outside of these locations is not recommended. Doing so will result in

persistent settings in the registry - the settings will follow the computer or user until that key\value is explicitly changed. Typically, registry settings in other parts of the registry are user preferences. If an

.adm file is constructed to write to a preference, the user’s actual preference is lost. Subsequently, removing the policy (changing the policy to Not Configured, removing the GPO, or changing the user or computer to a different site, domain, OU, or security group) leaves the setting as it was (tattooed)


ADM Language Components

ADM provides a framework language. A template (.adm) file describes a number of categories. Each of these categories can contain zero or more policies, and each policy in turn can contain zero or more parts. The following sections describe the various components of the ADM language.

Comments

You can add comments to an .adm file by preceding the comment either with a semicolon (;) or two forward slashes (//). You can place comments at the end of any valid line.

#if Version (for Version Comparison)

You can specify that any part of your .adm file may be evaluated only in specific versions of the policy editing tools (either the Windows 2000 Group Policy snap-in or the Windows NT 4.0 System Policy Editor). The latest version for the Windows

NT 4.0 System Policy Editor is 2. The first version for the Windows 2000 Group

Policy snap-in is 3. To compare versions, use the following syntax:

#if Version (operator) x

#endif

The valid Operators for the Version statement number are listed in the following table.

Operator Signifies

> (GT)

< (LT)

==

(EQ)

Greater than. For example, a > b means a is greater than b.

Less than. For example, a < b means a is less than b.

Equal. For example, a == b means a is equal to b.

!= (NE) Not equal.

>=

(GTE)

Greater than or equal to. For example, to b. a >= b means a is greater than or equal

<=

(LTE)

Less than or equal to. For example, a <= b means a is less than or equal to b.

Strings

The Group Policy snap-in requires a string to be defined in the [strings] section of the .adm file for anything preceded by two exclamation points (!!).This allows variables to define long strings of text that appear in the user interface and to define these strings only once. This is useful if the strings are used in multiple locations throughout the .adm file. This method also allows for easier conversion to other languages (localization). The string must be enclosed in quotes.

To define CATEGORY , POLICY , PART, and DEFAULT , use the [strings] variable mechanism. Although this method is not required (because quoted strings could be hard-coded), not using the strings variable method makes reuse of strings impossible and presents difficulties for localization of the file.


Optionally, you can enclose a variable name in double quotation marks. Names with spaces must be enclosed in double quotation marks.

[Strings] Variable Example

In the body of the .adm file, you could describe a CATEGORY name as follows:

CATEGORY !!FirstCategory

Then, in the [strings] section, you would define the FirstCategory variable:

FirstCategory=“My First Category”

This would display the “My First Category” string (without the quotes) in the Group

Policy snap-in user interface.

Quotes

Quotes are required for any string that contains spaces, and they are optional for text strings that do not include spaces.

Line Breaks

To start next on a new line or to create a line break, use this syntax:

\n = Starts a new line

\n\n = Creates a line break

CLASS

The first entry in the .adm file is CLASS xxxx, where xxxx could be one of the following:



MACHINE. This section includes entries found in the Computer Configuration node in the Group Policy snap-in.



USER. This section includes entries found in the User Configuration node in the

Group Policy snap-in.

Only two valid classes exist within an .adm file. If the .adm file contains a class that is anything other than the valid classes, the errors are ignored when the Group

Policy snap-in loads.

The valid keywords for CLASS are:



CLASS



CATEGORY



StringsSect



USER



MACHINE

CATEGORY

The CATEGORY name is displayed in the Group Policy snap-in as a node in either

Computer Configuration or User Configuration , depending on which CLASS the

CATEGORY is under.


The CATEGORY syntax is as follows:

CATEGORY !!

“variable name”

[KEYNAME “key name”]

[... policy definition statements ...]

END CATEGORY where: variable name is the CATEGORY name as it should appear in the Group Policy snap-in list box. Optionally, you can enclose the variable name in double quotation marks. Names with spaces must be enclosed by double quotation marks. key name is an optional registry key name to use for the CATEGORY . If a key name is specified, it is used by all child categories, policies, and parts, unless they specifically provide a key name of their own. Names with spaces must be enclosed in double quotation marks.

A policy definition statement may not appear more than once in a single category.

An example follows:

CATEGORY !!MyNewCategory

To close the category after filling in the options, use:

END CATEGORY ; MyNewCategory

These can be nested to create subcategories, as in the following example:

CATEGORY !!FirstCategory

CATEGORY !!SecondCategory

CATEGORY !!ThirdCategory

...

...

END CATEGORY ; ThirdCategory

END CATEGORY ; SecondCategory

END CATEGORY ; FirstCategory

The valid keywords for CATEGORY are:



KEYNAME



CATEGORY



POLICY



END

KEYNAME

The KEYNAME keyword is used within a CATEGORY to define which key within the registry is modified as a result of an action here. KEYNAME should be followed by the registry path to the key that contains the value that you want to change. Do not specify HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER because

CLASS defines that portion of the key. If the KEYNAME contains a space, you must enclose the string in quotes.


POLICY

To identify a Policy that the user can modify, you use the keyword POLICY . This is much like the CATEGORY keyword. Start by defining the following:

POLICY !!MyFirstPolicy

...//Then fill in all the policy specifics.

...//And finish with the following:

END POLICY

You can use multiple POLICY key names under one KEYNAME . In the preceding example, you must define the MyFirstPolicy variable in the [strings] section of the

.adm file.

The valid keywords for POLICY are:



KEYNAME



VALUENAME



PART



VALUEON



VALUEOFF



ACTIONLISTON



ACTIONLISTOFF



END



HELP



CLIENTEXT



POLICY

VALUENAME

Defines the options available within a POLICY . First identify the registry value that is to be modified as a result of using the keyword VALUENAME . For example,

VALUENAME MyFirstValue .

Unless you specify otherwise, the value is written in the following format when the user checks or clears the option:



Checked . REG_DWORD with a value of 1.



Unchecked . Remove the value completely.

Other options are available and are listed in the following sections. If the option is to be selected within the lower pane of the Group Policy snap-in, the VALUENAME needs to be within a PART scope.

CLIENTEXT

The CLIENTEXT keyword is used to specify which Client-side extension to the

Group Policy snap-in needs to process the particular settings on the client computer. By default, the Registry extension processes all settings configured under the Administrative Templates node. The CLIENTEXT keyword changes the default behavior and causes the specified extension to process these settings after the Registry extension has placed them in the registry.


CLIENTEXT must be used within either the POLICY scope or the PART scope and should follow the VALUENAME statement.

For example:

POLICY !!DQ_Enforce

EXPLAIN !!DQ_Enforce_Help

VALUENAME "Enforce"

CLIENTEXT {3610eda5-77ef-11d2-8dc5-00c04fa31a66}

PART !!DQ_EnforceTip1 TEXT

END PART

END POLICY

The GUID that follows the CLIENTEXT keyword is the GUID of the Clien-sSide extension. The Client-side extensions are listed in the registry under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\

Winlogon\GPExtensions .

VALUEOFF/VALUEON

You can use VALUEOFF/VALUEON to write specific values based on the state of the option. You can enable this functionality by writing the .adm file as described in the following examples:

KEYNAME ....

POLICY !!MyPolicy

VALUENAME ValueToBeChanged

VALUEON “Turned On” VALUEOFF “Turned Off”

END POLICY or:

KEYNAME ....

POLICY !!MyPolicy


VALUEON 5 VALUEOFF 10

END POLICY

Using Simple Policies and Policies with the VALUEOFF/VALUEON

Statements

This section presents two examples that illustrate the difference between using the default policy states and specifying VALUEON/VALUOFF statements. There is a significant difference between the two example policies below that you should be aware of.

Example 1

In this example, no explicit VALUEON / VALUEOFF statements are used. This means that the Administrative Templates will use the default behavior when the user changes the state of this policy.


POLICY !!EnableSlowLinkDetect

EXPLAIN !!EnableSlowLinkDetect_Help

KEYNAME "Software\Policies\Microsoft\Windows\System"

VALUENAME "SlowLinkDetectEnabled"

END POLICY

The following table lists the default behavior.

State Behavior

Policy enabled

Policy disabled

Policy in gray state

A DWORD with the value 1 is written to the registry.

The registry value is deleted.

Nothing is explicitly written or deleted from the registry.

The important thing to note is the Policy disabled state. The value is not written to the registry with the value of 0; instead it is explicitly deleted. This means a component reading the policy will not find it in the registry, and will fall back to using the default in the code. Essentially, having the policy in the disabled state is the same as having it in the gray state.

Example 2

In this example, the state values are explicitly defined, so the Administrative

Templates will use these values when the user changes the policy.

POLICY !!EnableSlowLinkDetect

EXPLAIN !!EnableSlowLinkDetect_Help

KEYNAME "Software\Policies\Microsoft\Windows\System"

VALUENAME "SlowLinkDetectEnabled"

VALUEON NUMERIC 1

VALUEOFF NUMERIC 0

END POLICY

The following table lists the behavior in this example.

State Behavior

Policy enabled A DWORD with the value 1 is written to the registry.

Policy disabled A DWORD with the value 0 is written to the registry.

Policy in gray state Nothing is explicitly written or deleted from the registry.

EXPLAIN

The EXPLAIN keyword is used to provide Help text for a specific Group Policy.

Each Group Policy that you create should include one EXPLAIN keyword, followed by at least one space, and then the EXPLAIN string in quotes or a reference to the

Help string.


For example:

POLICY !!Pol_NoConfigCache

#if VERSION >= 3

EXPLAIN !!Pol_NoConfigCache_Help

#endif

VALUENAME "NoConfigCache"

PART !!Lbl_NoConfigCacheHelp1 TEXT

END PART

END POLICY

.....

[Strings]

Pol_NoConfigCache_Help="Prevents users from changing the\n\nautomatic synchronization behavior at logoff."

In the preceding example, Help is offered for one of the Offline Files options. The

EXPLAIN keyword wrapped in the #if VERSION allows this.adm file to be used with the Windows 2000 Group Policy snap-in (which is version 3).

PART

You can use PART to specify various options, such as drop-down list boxes, text boxes, and text in the lower pane of the Group Policy snap-in.

The PART syntax is:

PART [!!]name PartType

type-dependent data

[KEYNAME KeyName ]

VALUENAME ValueName

END PART where: name is the PART name as it should appear in the Group Policy snap-in list box. It may optionally be enclosed by double quotation marks. Names with spaces must be enclosed by double quotation marks. As a text string that is visible in the UI, it should use the [STRINGS] variable !!

.

PartType is a Policy part flag. Flags are discussed individually in the PartTypes section. type-dependent data.

Some part types have additional tags, these would go here.

KeyName is an optional key name to use. If no key name is specified, the previous key name in the hierarchy is used.

ValueName is the value name to use to set the data for this part.

An example of PART use follows:

PART !!MyVariable

...

END PART or:

FLAG(s) {one or more, defined later}


PART !!MyVariable FLAG(s)

The valid keywords for PART are:

END PART



CHECKBOX



TEXT



EDITTEXT



NUMERIC



COMBOBOX



DROPDOWNLIST



LISTBOX



END



CLIENTEXT



PART

PartTypes

The basic ADM language allows for the creation of a simple .adm file that makes a

VALUENAME of REG_DWORD type with a value of 1 or removes the value completely. Using the following modifiers can provide additional options.

TEXT

Displays a line of static (label) text. No associated registry value exists for this part type. The TEXT part type accepts no type-specific data. This is useful for displaying a descriptive message in the lower panel.

The valid keyword for TEXT is END .

EDITTEXT

Displays an edit field that accepts alphanumeric text. The text is set in the registry with the REG_SZ type. The EDITTEXT part type accepts the following options:



DEFAULT value. Specifies the initial string to place in the edit field. If this option is not specified, the field is initially empty.



MAXLEN value. Specifies the maximum length of a string. The string in the edit field is limited to this length.



REQUIRED .

Specifies that the Group Policy snap-in does not allow a policy containing this part to be enabled, unless a value has been entered for this part.



OEMCONVERT . Sets the ES_OEMCONVERT style in the edit field so that typed text is mapped from ASCII to OEM and back. ES_OEMCONVERT converts text entered in the edit control. The text is converted from the

Windows character set (ASCII) to the OEM character set and then back to the

Windows set. This ensures proper character conversion when the application calls the CharToOem <JavaScript:hhobj_1.Click()> function to convert an

ASCII string in the edit control to OEM characters. This style is most useful for edit controls that contain file names.


The valid keywords for EDITTEXT are:



KEYNAME



VALUENAME



DEFAULT



REQUIRED



MAXLENGTH



OEMCONVERT



END



EXPANDABLETEXT



CLIENTEXT

COMBOBOX

Displays a combo box. The COMBOBOX part type accepts the same options as

EDITTEXT, as well as the SUGGESTIONS option, which begins a list of suggestions to be placed in the drop-down list. SUGGESTIONS are separated with spaces and must be enclosed by double quotation marks when a value includes spaces. The list ends with END SUGGESTIONS .

For example:

SUGGESTIONS

Alaska Alabama Mississippi ”New York“

END SUGGESTIONS

The valid keywords for COMBOBOX are:



KEYNAME



VALUENAME



DEFAULT



SUGGESTIONS



REQUIRED



MAXLENGTH



OEMCONVERT



END



NOSORT



EXPANDABLETEXT



CLIENTEXT

CHECKBOX

Displays a check box. The value is set in the registry with the REG_DWORD type.

The value will be nonzero if the check box is checked by the user, and 0 if it is unchecked. The CHECKBOX part type accepts the following options:



ACTIONLISTOFF. Specifies an optional action list to be used if the check box is turned off.



ACTIONLISTON.

Specifies an optional action list to be used if the check box is turned on.




DEFCHECKED.

Causes the check box to be initially checked.



VALUEOFF. Overrides the default off behavior of the check box.



VALUEON. Overrides the default on behavior of the check box.

The default behavior of a check box is to write the value 1 to the registry if it is checked, and 0 if it is unchecked. VALUEON and VALUEOFF are used to override this behavior. For example, the following option writes “Fred” to the registry when the check box is checked:

VALUEON “Fred”

The following option writes the value 12 to the registry when the check box is unchecked:

VALUEOFF NUMERIC 12

The valid keywords for CHECKBOX are:



KEYNAME



VALUENAME



VALUEON



VALUEOFF



ACTIONLISTON



ACTIONLISTOFF



DEFCHECKED



CLIENTEXT



END

DROPDOWNLIST

Displays a combo box with a drop-down list style. The user may choose only from one of the entries supplied. The main advantage of a combo box with a drop-down list is that a number of extra registry edits may be specified based on the user's selection. The DROPDOWNLIST part type accepts the ITEMLIST and REQUIRED options.

ITEMLIST begins a list of the items in the drop-down list, which must end with

END ITEMLIST .


Each item in the ITEMLIST option must be specified as follows:

NAME name VALUE value

[ACTIONLIST actionlist]

... where name is the text to be displayed in the drop-down list for this item.

Value is the value to be written as the part's value if this item is selected. Values are assumed to be strings, unless they are preceded by NUMERIC. The following example shows both string and numeric values:

VALUE “Some value”

VALUE NUMERIC 1

If VALUE is followed by DELETE (for example, VALUE DELETE ), the registry value name and value pair are deleted. actionlist is an optional action list to be used if this value is selected.

REQUIRED specifies that the Group Policy snap-in does not allow a policy containing this part to be enabled unless a value has been entered for the part.

The valid keywords for DROPDOWNLIST are:



KEYNAME



VALUENAME



REQUIRED



ITEMLIST



END



NOSORT



CLIENTEXT

LISTBOX

Displays a list box with Add and Remove buttons. This is the only part type that can be used to manage multiple values under one key. The VALUENAME option cannot be used with the LISTBOX part type because there is no single value name associated with this type. By default, only one column appears in the list box, and for each entry a value is created whose name and value are the same. For instance, a “Fred” entry in the list box would create a value named “fred” whose data was “fred”.

The LISTBOX part type accepts the following options:



ADDITIVE . By default, the content of list boxes overrides any values set in the target registry. This means that a control value is inserted in the policy file that causes existing values to be deleted before the values set in the policy file are merged. If this option is specified, existing values are not deleted, and the values set in the list box is in addition to whatever values exist in the target registry.




EXPLICITVALUE . This option makes the user specify the value data and the value name. The list box shows two columns, one for the name and one for the data. This option cannot be used with the VALUEPREFIX option.



VALUEPREFIX prefix. The prefix you specify is used in determining value names. If a prefix is specified, the prefix and an incremented integer are used, instead of the default value naming scheme described previously. For example, a prefix of “SomeName” generates the value names “SomeName1”,

“SomeName2”, and so on. The prefix can be empty (“”), which causes the value names to be “1”, “2”, and so on.

The valid keywords for LISTBOX are:



KEYNAME



VALUEPREFIX



ADDITIVE



NOSORT



EXPLICITVALUE



EXPANDABLETEXT



END



CLIENTEXT

NUMERIC

Displays an edit field with an optional spinner control (an up-down control) that accepts a numeric value. The value is set in the registry with the

REG_DWORD type.

The NUMERIC part type accepts the following options:



DEFAULT value. Specifies the initial numeric value for the edit field. If this option is not specified, the field is initially empty.



MAX value. Specifies the maximum value for the number. The default value is

9999.



MIN value. Specifies the minimum value for the number. The default value is 0.



REQUIRED . Specifies that the Group Policy snap-in does not allow a Policy containing this part to be enabled unless a value has been entered for this part.



SPIN value. Specifies increments to use for the spinner control.



SPIN 0 . Removes the spinner control. SPIN 1 is the default.



TXTCONVERT . Writes values as REG_SZ strings (“1”, “2”, or “128”) rather than as binary values.

For example:

PART !!MyVariable NUMERIC


END PART


The valid keywords for NUMERIC are:



KEYNAME



VALUENAME



MIN



MAX



SPIN



DEFAULT



REQUIRED



TXTCONVERT



END



CLIENTEXT

TEXT

Displays text only.

For example:

PART !!MyVariable

END PART

NUMERIC

TEXT

Writes a value to registry with data type REG_DWORD . This is the default unless another type is specified.

For example:



END PART

EXPANDABLETEXT

Writes a value to registry with data type REG_EXPAND_SZ .

For example:

PART !!MyVariable EDITTEXT EXPANDABLETEXT


END PART

EDITTEXT

Writes a value to the registry with data type REG_SZ .

For example:

PART !!MyVariable EDITTEXT


END PART


REQUIRED

Generates an error if the user does not enter a value when required.

For example:

PART !!MyVariable EDITTEXT REQUIRED


END PART

MAXLEN

Specifies the maximum length of text.

For example:



MAXLEN 4

END PART

DEFAULT

Specifies a default value. This can be used for text or numeric data.

For example:


DEFAULT !!MySampleText


END PART or:


DEFAULT 5


END PART

MIN/MAX

Specifies the lowest and highest valid values.

For example:


MIN 100 MAX 999 DEFAULT 55


END PART


DROPDOWNLIST

Displays a list box of options from which to choose.

For example:

PART !!MyVariable DROPDOWNLIST


ITEMLIST

NAME “First” VALUE NUMERIC 1

NAME “Second” VALUE NUMERIC 2

NAME “Third” VALUE NUMERIC 3

VALUE NUMERIC 4 NAME “Fourth”

END ITEMLIST

END PART

ACTIONLIST

Optional action list to be used if this value is selected.

ACTIONLIST may only be used as part of an ITEMLIST . See the example in the

ITEMLIST section.

Two variants of ACTIONLIST exist ( ACTIONLISTON and ACTIONLISTOFF ), and they may be used with the POLICY tag and the CHECKBOX tag. See the example in the CHECKBOX section.


APPENDIX C: WINDOWS

NT 4.0, ZERO

ADMINISTRATION KIT,

AND WINDOWS 2000

NAMESPACE

COMPARISON

Policy Option – Windows NT4.0 and

ZAK namespace

Default User

Control Panel\Display\Restrict Display\

Deny access to display icon

Hide Background Tab

Hide Screen Saver Tab

Hide Appearance Tab

Hide Settings Tab

Desktop\Wallpaper

Wallpaper Name

Tile Wallpaper

Desktop\Color Scheme

Scheme name

Shell\Restrictions

Remove Run command from Start menu

Remove folders from Settings on Start menu

Remove Taskbar from Settings on Start menu

Remove Find command from Start menu

Hide drives in My Computer

Hide Network Neighborhood

No Entire Network in Network Neighborhood

No Workgroup contents in Network

The following tables list comparisons of the Windows NT 4.0, the Zero

Administration Kit (ZAK), and the Windows 2000 policy-related namespace.

The following notation is used in the tables:

P = Policy

SYS = not in Administrative Templates (system configured)

N/A = not available

Windows 2000 namespace Notes

User Configuration\Administrative

Templates\Control Panel\Display

Prohibit user from running Display control panel

Same

Same

Same

Same

N/A

N/A

N/A

User Configuration\Administrative

Templates\Start Menu & Task Bar








Templates\Windows Components\Explorer


Templates\Desktop




P

P

P

P

P

P

P

P

P

P

P

P

P

Disable changes to Task Bar and

Start menu settings.

Remove Search menu from Start menu.

Hide these specified drives in My

Computer.

My Network Places.

My Network Places.

My Network Places.



ZAK namespace

Neighborhood

Hide all items on Desktop

Disable Shut Down command

Don’t save settings at exit

System\Restrictions

Windows 2000 namespace



Templates\Desktop




Templates\System\Logon/Logoff


Templates\Desktop


Templates\System

Same

Same

P

P

P

P

P

Notes

Disable shutdown.

Remove shutdown.

Disable Registry editing tools

Run only allowed Windows applications

Windows NT Shell\Custom User Interface

Custom Shell

Windows NT Shell\Custom Folders

Custom Programs Folder

Custom Desktop Icons

N/A Shell name.

Hide Start menu subfolders

Custom Startup Folder

Custom Network Neighborhood

Custom Start menu

Windows NT Shell Restrictions

Only use approved Shell extensions

N/A

User Configuration\Windows Settings\Folder

Redirection\Desktop

N/A

N/A

N/A


Redirection\Start Menu

SYS

SYS

Remove File menu from Explorer

Remove common program groups from Start menu

Disable Context Menus for the Taskbar

Disable Explorer’s default context menu


Templates\Windows Components\Windows

Explorer



Explorer






P

P

P

P

P

Called “My Network Places folder” in

Windows 200

Disable File menu in Shell folders.

Hide versus Remove.

Disable context menu in Shell folders.



ZAK namespace

Windows NT System

Parse Autoexec.bat




Remove the Map Network Drive and Disconnect

Network Drive options



Disable link file tracking N/A




Templates\System\Logon/Logoff

N/A

Computer Configuration\Administrative

Templates\System\Logon

Same

N/A

P

P

P

Notes

Disable net connections/disconnections.

Do not involve the domain controller with distributed link tracking

Do not rack shell shortcuts during roaming.

Many others added for Windows 2000

Disable Task Manager

Show welcome tips at logon

ZAK Policies\Windows NT\

User Profiles through System Policies

AppData Folder

P

Favorites Folder

NetHood Folder


Redirection.

N/A


Redirection\

SYS Custom Application Folder.

.

PrintHood Folder

Recent Folder

SendTo Folder

Internet Explorer Security\Active Content

Allow download of ActiveX content

Enable ActiveX Controls and Plug-ins

Run ActiveX scripts

Enable Java Programs

N/A

N/A

N/A

Many new Internet Explorer Policies in User Configuration\Administrative Templates\Windows

Components\Internet Explorer

N/A

N/A

N/A

N/A

Internet Explorer Security\Active Content Security Level



ZAK namespace

Select Security Level


N/A

Drives\Restrictions\Show only selected drives

Choose drives that will be shown User Configuration\Administrative


Explorer

ZAK Policies\Windows\Load

Enter Program to be Run on Startup N/A

Default Computer

Network\System policies update\Remote update

Update mode N/A

Path for manual update

Display error messages

N/A

N/A

Load balancing

System\SNMP

N/A

N/A

N/A

N/A

Communities

Permitted managers

Traps for Public community

System\RUN

Items to run at startup

Windows NT Network\Sharing

Create hidden drive shares (workstation)

Create hidden drive shares (server)

Windows NT Printers

Disable browse thread on this computer

Scheduler priority

Beep for error enabled

Windows NT Remote Access

Max number of unsuccessful authentication

N/A

N/A

N/A

N/A

N/A

N/A

N/A

P

Notes

Hide these specified drives in My

Computer.


retries

Max time limit for authentication

Wait interval for callback

Auto Disconnect

Windows NT Shell\Custom shared folders

Custom shared Programs folder

Custom shared desktop icons

Custom shared Start menu

Custom shared Startup folder

Windows NT System\Logon

Logon banner —Caption, Text

N/A

N/A

N/A

N/A

N/A

N/A

N/A

Computer Configuration\Windows

Settings\Security Settings\Local

Policies\Security Options

Enable shutdown from Authentication dialog box

Do not display last logged on user name




Computer Configuration\Windows

Settings\Security Settings\Local

Policies\Security Options

Computer Configuration\Administrative

Templates\System\Logon\

P

SYS

P

Windows NT System\File System

Do not create 8.3 file names for long file names

Allow extended characters in 8.3 file names

Do not update last access time

Windows NT User Profiles

Delete cached copies of roaming profiles

Automatically detect slow network connections

Slow network connection time-out

Time-out for dialog boxes

N/A

N/A

N/A

Computer Configuration\Administrative

Templates\Logon\

Same

Automatically detect slow network connections for user profiles

Same

Same

P

P

P

P

SYS Message text for users attempting to login.

Message title for users attempting to login.

Disable/Remove the Shutdown

Command.

Do not display last user name in login screen.


APPENDIX D: GROUP

POLICY STORAGE

Group Policy Objects store information in two locations: a Group Policy Container and a Group Policy Template.

Group Policy Container

The Group Policy Container (GPC) is an Active Directory container that stores

Group Policy Object properties; it includes sub-containers for computer and user

Group Policy information. The Group Policy Container has the following properties:



Version information . This is used to ensure that the information is synchronized with the Group Policy Template information.



Status information . This indicates whether the Group Policy Object is enabled or disabled.



List of components (extensions) that have settings in the Group Policy Object.

For example, the Group Policy Container stores information used by the Software

Installation snap-in to describe the state of the software available for installation.

This data repository contains data for all applications, interfaces, and APIs that provide for application publishing and assigning.

Group Policy Template

Group Policy Objects also store Group Policy information in a folder structure called the Group Policy Template (GPT) that is located in the System Volume folder of domain controllers (Sysvol) in the \Policies sub-folder. The Group Policy Template is the container where Administrative Template

–based policies, Security Settings, applications available for Software Installation, and script files are stored.

When you modify a GPO, the directory name given to the Group Policy Template is the globally unique identifier (GUID) of the Group Policy Object that you modified.

For example, assume that you modified a GPO associated with a domain called

Seattle. The resulting GPT folder would be named as follows (the GUID is an example):

%systemroot%\sysvol\<SYSVOL>\Seattle.yourcompanyname.com\Policies\{476364

45-af79-11d0-91fe-080036644603} where the second sysvol is shared as SYSVOL. (The default location of the Sysvol folder is %systemroot%).


Gpt.ini File

At the root of each Group Policy Template folder is a file called Gpt.ini. For local

Group Policy Objects, the Gpt.ini file stores information indicating:



Which Client-side extensions of the Group Policy snap-in contain User or

Computer data in the Group Policy Object.



Whether the User or Computer portion is disabled.



Version number of the Group Policy snap-in extension that created the Group

Policy Object.

For the local GPO, the Gpt.ini file contains the following information:

[General] gPCUserExtensionNames //Includes a list of GUIDs that tells the client side engine which Client Side Extensions have User data in the GPO.

The format is: [{GUID of Client Side

Extension}{GUID of MMC extension}{GUID of second

MMC extension if appropriate}][repeat first section as appropriate].

GPCMachineExtensionNames //Includes a list of GUIDs that tells the client side engine which Client Side Extensions have Machine data in the GPO.

Options..//Refers to GPO options such as User portion disabled or Machine portion disabled.

GPCFunctionalityVersion //The Version number of the Group Policy extension tool that created the Group Policy

Object.

Gpt.ini for Active Directory GPOs

The Gpt.ini file for Active Directory GPOs contains only a Version entry; this information is stored in the Active Directory:

Version=0 //Version number of the Group Policy Object

Local Group Policy Objects

A local Group Policy Object exists on every computer, and by default it contains only security policy. It is stored in %systemroot%\System32\GroupPolicy, and it has the following ACL permissions:



Administrators: full control



Operating system: full control



User: read


Group Policy Template Subfolders

The Group Policy Template folder contains the following subfolders:



Adm . Contains all of the .adm files for this Group Policy Template.



Scripts . Contains all the script and related files for this Group Policy Template.



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 contains the following subfolders:



Apps . Contains the advertisement files (.aas files) used by the Windows installer. These are applied to users.



Files . Contains the files to be deployed. The directory structure matches that of the namespace. These are applied to users.



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 the HKEY_LOCAL_MACHINE portion of the registry. The Machine folder contains the following subfolders:



Apps . Contains the advertisement files (.aas files) used by the Windows installer. These are applied to computers.



Files . Contains the files to be deployed, and the directory structure matches that of the namespace. These are applied to computers.



\Microsoft\Windows NT\SecEdit . Contains the Security Settings file

Gpttmpl.inf.

The User and Machine folders are created at install time, and the other folders are created as needed when policy is set.

Registry.pol Files

The Administrative Templates snap-in extension of Group Policy saves information in the Group Policy Template in ASCII files referred to as Registry.pol files. These files contain the customized registry settings that you specify (by using the Group

Policy snap-in) to be applied to the Machine ( HKLM ) or User ( HKLU ) portion of the registry.


Two Registry.pol files are created and stored in the Group Policy Template, one for

Computer Configuration , which is stored in the \Machine subdirectory, and one for User Configuration , which is stored in the \User subdirectory.

Note: The format of the Registry.pol files in the Group Policy Template differs from that of previous versions of Windows NT and Windows 95 operating systems. Registry.pol files created by

Windows NT 4.0 and Windows 95 can be applied only to the operating system on which they were created. The Registry.pol file produced by the Windows NT 4.0 System Policy Editor was a binary file, whereas the Registry.pol file produced by Administrative Templates node of the Group Policy snap-in is a text file with embedded binary strings. Therefore, it can not be viewed or edited outside the Group

Policy snap-in.

For details on the Windows 2000 Registry.pol file, see Appendix D: The Registry.pol

File.


APPENDIX E: THE

REGISTRY.POL FILE

Registry.pol files are text files that the Administrative Templates snap-in extension of Group Policy uses to save information; they are stored in the Group Policy

Template.

When you use the Administrative Templates extension of the Group Policy snap-in to define customized registry settings to be applied to the Machine (HKLM) or User

(HKLU) portion of the registry, two Registry.pol files are created and stored in the

Group Policy Template. One Registry.pol file is for Computer Configuration-related registry settings and is stored in the \Machine sub-directory, and the other is for

User Configuration settings and is stored in the \User sub-directory.

The Windows 2000 Registry.pol file consists of a header and registry values.

The header contains version information and signature data, both DWORD values:

REGFILE_SIGNATURE 0x67655250

REGISTRY_FILE_VERSION 00000001 (increments each time changed)

The registry values begin with an opening bracket ([) and end with a closing bracket

(]):

[key;value;type;size;data] where: key is the path to the registry key to use for the category. Do not include

HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER in the registry path. The location of the file determines which of these keys is used. The following value has special meaning for this field:



**DeleteKeys

—a semi-colon-delimited list of keys to delete.

For example: **DeleteKeys NoRun;NoFind . value is the name of the registry value. The following values have special meaning for this field:



**DeleteValues

—a semi-colon-delimited list of values to delete. Use as a value of the associated key.



**Del.valuename

—deletes a single value. Use as a value of the associated key.



**DelVals

—deletes all values in a key. Use as a value of the associated key.

Type is a data type. The field can be one of the following values:



REG_DWORD



REG_EXPAND_SZ



REG_SZ


Note that although the file format supports all the registry data types (such as

REG_MULTI_SZ ), the Administrative Templates node does not support these registry types: REG_BINARY, REG_MULTI_SZ.

Size is the size of the data field in bytes. For example, 4.

Data is the raw information. For example, 4 bytes of data 0x00000001.

It is possible that the valuename , type , data , and size could be missing or 0. In this case, only the key should be created.

This pattern of [] entries continues until the end of the file.

The following special keys are used for deleting keys and values:



**DeleteKeys // Semi-colon-delimited list of keys to delete.

For example: **DeleteKeys REG_SZ NoRun;NoFind .



**DeleteValues // Semi-colon-delimited list of values to delete.

Used as a value of the designated key.



**Del.valuename

// Deletes a single value name.




**DelVals // Deletes all values in a key.


The Registry.pol file contains data to be written to the registry based on the settings specified with the Group Policy snap-in, and the names of any scripts and their command lines (in the form of registry keys and values).

How Registry.pol Files Are Created

The following section outlines how to form Registry.pol files:



When you start the Group Policy snap-in, a temporary registry tree is created that consists of two nodes: USER and MACHINE .



As you navigate the Administrative Templates node of the Group Policy snapin, .adm files and snap-in extension nodes are displayed. The .adm files within the Group Policy snap-in 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 MMC console window), 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 the Group Policy snap-in, the temporary registry hives are exported to the Registry.pol files in the appropriate folders of the Group Policy

Template.



The next time you start the Group Policy snap-in 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 policies, they reflect the current state.

Note: The Group Policy snap-in stores its information in two distributed locations, the Active Directory

(Group Policy Container) and Sysvol (Group Policy Template). Because the information is stored in two different storage locations, these locations are unsynchronized at various times during the update cycle. During this time, computers or users affected by these policies will continue to use the last list of

GPOs that was applied successfully until they are again synchronized.


APPENDIX F: ACTIVE

DIRECTORY OVERVIEW

In Windows 2000, you apply Group Policy settings to a Group Policy Object (GPO) that is, in turn, associated with selected Active Directory containers, such as sites, domains, or organizational units (OUs). This section introduces key concepts related to the new Windows 2000 Active Directory that are important to understand before proceeding to Group Policy concepts.

Windows 2000 introduces the Active Directory, a directory service that is secure, distributed, partitioned, and replicated. Active Directory extends previous Windowsbased directory functionality, as well as providing new features.

A directory is a hierarchical information structure that stores information about objects on the network. A directory service, such as Active Directory, includes the directory itself and the services that make the information available.

Active Directory provides network users with access to resources anywhere on the network by using a single network logon. It also provides administrators a single point of administration for all objects on the network that can be organized into an intuitive, hierarchical structure. The Active Directory also provides the following benefits:

Querying

The Active Directory generates a global catalog that users and administrators can employ to find any object on the network, using any attribute of that object. For example, you can find a user by his or her first name, last name, e-mail alias, office location, or other attribute of that person’s user account.

Computers running an Active Directory

–supported client provide menu options that allow the client to query the global catalog for information.

Improved Administration

An access control list (ACL), or permissions, controls which users can view and access objects in the Active Directory. An object ACL lists which users can view or use the object and what specific actions can be performed on the object. Access can be granted specifically for each individual attribute of an object.

Active Directory security supports both inheritance and delegation of authority.

Inheritance enables an object’s specific permission set to be copied to all of its child objects. Administrators can delegate authority and grant specific administrative rights for containers and sub-trees to other individuals and groups.

Security of Information

To provide stronger, more effective security mechanisms; interoperability with outside entities such as the Internet; and compatibility for existing clients;

Windows NT Server supports a variety of network security protocols.

Kerberos version 5, an Internet security standard, is the default protocol for network authentication in Windows NT Server. Windows 2000 also supports the following:



Public-key based protocols, including Secure Sockets Layer 3.0




Distributed Password Authentication



Windows NT LAN Manager (NTLM) protocol used by Windows NT versions 4.0 and earlier

Replication

Within each domain, the directory is replicated to each server running the Active

Directory. If the domain contains multiple Active Directory servers (also known as domain controllers), the directory is replicated to multiple servers. Each of these stores and maintains a complete copy of the domain directory. The benefits of replication include fault tolerance, load balancing, and improved performance.

The Active Directory uses multimaster replication, which allows you to change information at any server that contains the directory and automatically copies the changes to the other servers.

Partitioning of Information

With the Active Directory, the directory of each domain stores information about only the objects located in that domain, rather than using one massive store.

The Active Directory permits the use of multiple directory partitions, so it can be scaled from very small to very large companies.

Extensibility of the Directory

The Active Directory is fully extensible. This means that you can add new object types to the directory and you can add new attributes to existing object types by using either the Active Directory Schema Manager tool or by writing a program. You can also write command-line scripts to manage objects in the Active Directory. The scripts use the script language provided by the Active Directory Service Interfaces.

Integration with DNS

The Active Directory uses the Domain Naming System (DNS), a set of protocols and services used throughout the Internet and other TCP/IP networks. DNS provides name registration and name-to-address resolution services, which enable identification and connection to computers and users on TCP/IP networks.

DNS allows domain and computer names to use hierarchically structured friendly names. For example, DNS allows you to refer to a computer by a name such as headquarters.yourcompany.com, rather than the computer’s TCP/IP address.

The Active Directory implements a domain and object-naming model based on the

Domain Name System. Windows 2000 domain names correspond to DNS domain names by default.

Windows 2000 supports dynamic DNS, which lets servers update the DNS database while the operating system is running. Dynamic DNS is described in

Internet Request for Comments document 2136.

Interoperation with Other Directories


The Active Directory supports other industry standards, such as versions 2 and 3 of

Lightweight Directory Access Protocol (LDAP), Name Service Provider Interface

(NSPI), and Hypertext Transfer Protocol (HTTP).

LDAP is the core protocol of the Active Directory. It is an industry-standard directory service protocol that allows the Active Directory to share information with any other directory service that supports LDAP.

By supporting these standards, the Active Directory can expand its services across multiple namespaces and deal with information and resources located on the

Internet, other operating systems, and other directories.

Active Directory Namespace

The Active Directory includes a new domain model and hierarchical namespace.

Domains

The core unit in the Microsoft Windows 2000 Active Directory is the domain. All network objects 9 exist within a domain. To control access to objects, you use access control lists (ACLs) populated with access control entries (ACEs). Access permissions are cumulative within a domain, unless explicitly denied. Administration rights are limited to domain boundaries by default.

Domains are also units of replication. A single domain can span multiple physical locations or sites. Unlike the single-master model used by Windows NT 3 .x

and 4.0, with its primary domain controllers (PDCs) and backup domain controllers (BDCs), the Active Directory uses a multimaster peer-controller model. Thus, all of the domain controllers (DCs) that are authoritative for a domain can receive changes directly and propagate those changes, allowing inter-site replication to occur within a domain (even if any single DC is down).

Domain Trees

A domain tree consists of several domains that share a common schema and configuration and form a contiguous namespace. Domains in a tree are linked together by trust relationships. The Active Directory is a set of one or more trees.

You can view trees in one of two ways: the trust relationship between domains and the namespace of the domain tree.

Viewing Trust Relationships

You can draw a picture of a domain tree, based on the individual domains and their trust relationships with each other.

Windows NT establishes trust relationships between domains based on the

Kerberos security protocol. Kerberos trust is transitive and hierarchical, so if domain

A trusts domain B and domain B trusts domain C, domain A also trusts domain C.

Figure F1 below illustrates this concept.

9

Directory service objects are not true objects. They do not contain extensible methods. Instead, they are attributed representations of various resources that exist on the network.


Domain A Domain B

Established

Trust

Implicit

Trust

Domain C

Figure F1. Kerberos trust relationships

Viewing the Namespace

You can draw a picture of a domain tree based on the namespace, and then determine an object’s distinguished name by following the path up the domain tree’s namespace. This view is useful for grouping objects together into a logical hierarchy. The main advantage of a contiguous namespace is that a deep search from the root of the namespace searches the entire hierarchy. Figure F2 below illustrates this concept: root.com

sub.root.com

other.sub.root.com

Figure F2. Hierarchy in a namespace

Although the Active Directory does not limit forming a contiguous namespace from discontiguous domains and directories, it may be advantageous to form contiguous trees that match the namespace to ensure that the name structure follows the same logic that the namespace presents.

Forests

A forest is a set of one or more trees that do not form a contiguous namespace. All trees in a forest share a common schema, configuration, and Global Catalog. All trees in a forest trust each other by means of transitive hierarchical Kerberos trust relationships. Unlike a tree, a forest does not need a distinct name. A forest exists as a set of cross-reference objects and Kerberos trust relationships known to the member trees. Trees in a forest form a hierarchy for the purposes of Kerberos trust;


the tree name at the root of the trust tree can be used to refer to a given forest.

Figure F3 below illustrates a forest:

Microsof t.Com

Sof tImage.Com

PBS.Microsof t.Com

Finance.Sof tImage.Com

NTDev.PBS.Microsof t.Com

Figure F3. A forest

Sites

A site is a location in a network that contains Active Directory servers. A site is defined as one or more TCP/IP subnets. Defining a site as a set of subnets lets administrators quickly and easily configure the Active Directory access and replication topology to take advantage of the physical network. When a user logs on, the Active Directory client finds Active Directory servers in the same site as the user. This is accomplished easily, because the user’s workstation already knows what TCP/IP subnet it is on, and subnets translate directly to Active Directory sites.

Organizational Units

A type of directory object contained within domains is the organizational unit . OUs are logical containers into which you can place users, groups, computers, and even other organizational units.

Global Catalog

The global catalog is a service and a store that contains directory information from all domains in your corporation. It is intended to answer queries about objects anywhere in the enterprise, across domain trees. Users can use the global catalog to find an object, regardless of which domain it is located in, by searching for any of a number of attributes.

The global catalog is kept on specific servers throughout the enterprise, and only domain controllers can serve as global catalog servers. By default, a global catalog is created automatically on the initial domain controller in the forest. After you install additional domain controllers in the domain, you can change the default location of the global catalog to another domain controller by changing NTDS Settings

Properties, using the Active Directory Sites and Services snap-in.

For more information about Active Directory, see the Windows 2000 Server documentation.


GLOSSARY

This section presents terminology used in this document. Active Directory

The Windows 2000 directory service that stores information about all objects on the computer network and makes this information easy for administrators and users to find and apply. With the Active Directory, users can access resources anywhere on the network with a single logon.

Similarly, administrators have a single point of administration for all objects on the network, which can be viewed in a hierarchical structure. For more information on the Active Directory, see Appendix F: Active Directory

Overview . administrative templates (.adm files)

Template files that provide settings pertaining to Windows NT versions 4.0 and Windows 2000, and Windows 95 and 98 operating system and registry structure. The .adm file specifies the registry settings that can be modified through the Group Policy snap-in user interface. The .adm file consists of a hierarchy of categories and subcategories that together define how the options are displayed through the Group Policy snap-in user interface. It also indicates the registry locations where changes should be made if a particular selection is made, specifies any options or restrictions (in values) that are associated with the selection, and in some cases, specifies a default value to use if a selection is activated.

Administrative Templates snap-in extension

A Group Policy snap-in extension that includes all registry-based Group

Policy, which you use to define registry settings that control the behavior and appearance of the desktop, including the operating system and applications.

The Administrative Templates snap-in extension includes an extension for

Remote OS Installation and functionality for managing disk quotas. application assignment

In Windows 2000, you can use the Software Installation snap-in extension of the Group Policy snap-in to assign applications to users so that the applications appear to be installed and available on the user's desktop whenever a user logs on.

You assign applications to a particular Group Policy Object (GPO), which is, in turn associated with a selected directory container (site, domain, or organizational unit). When you assign applications, the application is advertised to every user managed by the GPO. Advertising the application installs only enough information about the application to make application shortcuts appear on the Start menu and the necessary file associations appear in the registry. When a user managed by the GPO logs on to a computer running Windows 2000, the application appears on his or her

Start menu. When the user selects the application from the Start menu for the first time, the application is installed. Advertised applications can also be installed by clicking on a document managed by the application (by either


file extension or by COM-based activation). application publishing

In Windows 2000, you can use the Software Installation snap-in extension of the Group Policy snap-in to publish applications to users. Published applications are those that the administrator makes available for on-demand use.

Published applications have no presence on the users' computers. That is, no shortcuts or Start menu references to the application are present on the desktop. A published application is advertised to the Active Directory. The advertised attributes are used to locate the application and all the information required for installing it. After the application is advertised in the

Active Directory, it can be activated by document association, just as an assigned application. Users can also set up the program using the

Add/Remove Programs Control Panel tool on their desktop.

.cab file

A .cab file contains one or more files, all of which are downloaded together in a single compressed cabinet file. Included in the cabinet is an .inf file that provides further installation information. The .inf file may refer to files in the

.cab and to files at other uniform resource locators (URLs). discretionary access control list (DACL)

A part of the security descriptor that specifies the groups or users that can access an object, as well as the types of access (permissions) granted to those groups or users. See also security descriptor . disk quotas

Within the Administrative Templates node of the Group Policy snap-in are policy options for managing disk quotas, which administrators can use to monitor and limit disk space use for NTFS volumes formatted as NTFS version 5.0. After you enable disk quotas, you can set options for disk quota limits and warnings. domain

A grouping of servers and other network objects under a single name.

Domains provide the following benefits:



You can group objects into domains to help r eflect your company’s organization in your computer network.



Each domain stores only the information about the objects located in that domain. By partitioning the directory information this way, the Active

Directory scales up to as many objects as you need to store information about on your network.



Each domain is a security boundary

—this means that security policies and settings (such as administrative rights, security policies, and ACLs) do not cross from one domain to another. The administrator of a domain has absolute rights to set policies within that domain only.


domain trees

You can combine multiple domains into structures called domain trees. The first domain in a tree is called the root of the tree, and additional domains in the same tree are called child domains. A domain immediately above another domain in the same tree is referred to as the parent of the child domain.

All domains within a single domain tree share a hierarchical naming structure. Domains that share a common root share a contiguous namespace. Domains in a tree are joined together through two-way, transitive trust relationships. These trust relationships are two-way and transitive, therefore, a domain joining a tree immediately has trust relationships established with every domain in the tree.

Folder Redirection snap-in extension

A Group Policy snap-in extension that you use to place the Windows 2000

Special Folders in network locations other than their default location

(%systemroot%/Documents and Settings) on the local computer. globally unique identifier (GUID)

A 128-bit integer that identifies a particular object class and interface.

GUIDs are virtually guaranteed to be unique. A GUID can be generated using either the uuidgen utility from the Platform Software Development Kit, or the guidgen tool included in the Microsoft Visual C++® development system. For more information about GUIDs, see the

OLE Programmer’s

Reference , Volume One ; the Platform Software Development Kit documentation; and Inside OLE , 2d ed. by Kraig Brockschmidt, Redmond,

Wash.: Microsoft Press, 1995.

Group Policy

A component used in Windows 2000 to define options for managed desktop configurations for groups of users and computers. To specify Group Policy options, you use the Group Policy MMC snap-in.

Group Policy engine

The part of Group Policy that runs in the Winlogon process.

Group Policy Object

The Group Policy settings that you create by using the Group Policy snap-in are contained in a Group Policy Object (GPO), which is in turn associated with selected Active Directory containers: sites, domains, and organizational units (OUs).

Group Policy MMC snap-in

To create a specific desktop configuration for a particular group of users and computers, you use the Group Policy MMC snap-in.

You can specify Group Policy settings for the following:



Registry-based policies —Includes Group Policy for the Windows 2000 operating system and its components and for applications. To manage


these settings, use the Administrative Templates node of the Group

Policy snap-in.



Security options

—Includes options for local computer, domain, and network security settings.



Software installation and maintenance options

—Used to centrally manage application installation, updates, and removal.



Script options

—Includes scripts for computer startup and shutdown and user logon and logoff.



Folder redirection options

—Allows administrators to redirect users’ special folders to the network. lock-down policy

A selective use of the five different types of Group Policy. You can use the

Group Policy snap-in to create locked-down user environments in which a user has limited access to files in the system. Lock-down also requires that you specify system security settings, such as file, folders, or registry access restrictions. To do this, you use discretionary access control lists and security configuration options.

Microsoft Management Console (MMC)

A common console framework for system management applications. The primary goal of the Microsoft Management Console is to support simplified administration and lower cost of ownership through tool integration, task orientation, support for task delegation, and overall interface simplification.

The MMC console hosts the administrative tools (these are called MMC snap-ins); the console itself provides no management functionality.

MMC snap-in

Tools that extend the MMC console and provide administrative functionality.

A snap-in functions independently from other snap-ins.

MMC snap-in extension

A tool that enhances the functionality of a parent snap-in. An extension depends on a parent snap-in for contextual data. organizational unit (OU)

A type of directory object contained within domains. OUs are logical containers into which you can place users, groups, computers, and even other organizational units. registry

A database in which Windows NT internal configuration information and computer- and user-specific settings are stored. registry hive

A section of the registry that is saved as a file. The registry subtree is divided into hives (named for their resemblance to the cellular structure of a beehive). A hive is a discrete body of keys, subkeys, and values.


Remote OS Installation

A new optional component included in Microsoft® Windows® 2000 Server that administrators can use to remotely install a local copy of the

Windows 2000 Professional operating system on supported computers throughout their organization. Administrators can deploy a new version of an operating system upgrade to large numbers of clients at one time from a centralized location.

Administrators can use Group Policy to specify the client installation options that groups of users can access. These options are determined by the specific Remote OS Installation Group Policy settings that administrators define for the site, domain, or OU to which the users belong, in conjunction with the specific security group or user account. schema

The formal definition of all object classes, and the attributes that make up those object classes, that can be stored in the directory. The Active

Directory includes a default schema, which defines many object classes, such as users, groups, computers, domains, organizational units, and security policies. The Active Directory schema is dynamically extensible; this means that you can modify the schema by defining new object types and their attributes and by defining new attributes for existing objects. You can do this either with the Schema Manager snap-in tool included with

Windows NT Server, or programmatically. scripts

Batch files (.bat) or executable (.exe) files that run when a computer starts up or shuts down or when a user logs on or off at any type of workstation on the network. Windows 2000 supports Windows Scripting Host Visual Basic

Scripting Edition (VBScript) and JScript, while continuing to support MS-

DOS command scripts and executable files. security descriptor

A set of access control information attached to every container and object on the network. A security descriptor controls the type of access allowed to users and groups. Administrators assign security descriptors to objects stored in the Active Directory to control access to resources or objects on the network.

A security descriptor lists the users and groups that are granted access to an object (a file, printer, or service, for example), and the specific permissions assigned to those users and groups. See also discretionary access control list and system access control list .


Security Settings snap-in extension

A Group Policy snap-in extension that you use to define security configuration for computers within a Group Policy Object. A security configuration consists of settings applied to each security area supported for

Windows 2000 Professional or Windows 2000 Server. This configuration is included within a GPO. server-loaded application

This is a network-installed application. The application lives on a server and is run from the server. site

In Windows 2000 you register your network’s physical topology by defining sites. A site is defined as one or more IP subnets. Windows 2000 uses site information to direct requests from one computer to be fulfilled by another computer at the same site. For example, when a workstation logs on, the

Active Directory uses the TCP/IP address of the workstation, along with the site information you have entered, to determine a domain controller on the local site. This local controller is used to service the workstation’s requests.

Scripts snap-in extension

A Group Policy snap-in extension that you use to assign scripts to run at computer startup or shutdown or upon user logon or logoff.

Software Installation snap-in extension

A Group Policy snap-in extension that you use to centrally manage software distribution in your organization. system access control list (SACL)

Part of a security descriptor that specifies which user accounts or groups to audit when accessing an object, the access events to be audited for each group or user, and a Success or Failure attribute for each access event, based on the permissions granted in the object’s DACL. total cost of ownership (TCO)

Refers to the administrative costs associated with computer hardware and software purchases, deployment and configuration, hardware and software updates, training, maintenance, and technical support.

Windows Installer packages (.msi files)

Packages that contain all the information necessary to describe to the

Windows Installer how to set up an application in every conceivable situation: various platforms, different sets of previously installed products, earlier versions of a product, and numerous default installation locations.

The Software Installation snap-in extension to the Group Policy snap-in uses .msi packages.

Zero Administration Windows

Microsoft’s solution for lowering the total cost of ownership is an initiative


called Zero Administration Windows. The broad goals for Zero

Administration Windows are to significantly lower the cost of initial configuration from today’s levels and to decrease administrative overhead when the network is running in a steady state. After initial computer configuration, a combination of automatic application setup, scripting, and desktop policies significantly lowers the costs associated with managing workstations.


FOR MORE

INFORMATION

For the latest information on Windows 2000 Server, visit the Web site at: http://www.microsoft.com/ntserver/windowsnt5 .

Management and Overview Papers

The following table lists a series of papers that introduce the Microsoft Windows management services and change and configuration management. These papers are intended for managers and technical decision makers who need to understand the business requirements for, and the benefits of, management features, as well as the Microsoft management architecture, tools, and solutions. We recommend that you read these in the order listed below.

Title Content

Introduction to

Windows Management

Services

An overview of the management roles and disciplines, as well as the architecture for management solutions that will be available, either as part of the operating system or as an add-on.

Introduction to Change and Configuration

Management

An overview of change and configuration management and an introduction to how Microsoft products, such as Windows 2000

IntelliMirror™, Remote OS

Installation and Systems

Management Server address this management discipline.

IntelliMirror An overview of the features of

Windows 2000 IntelliMirror and scenarios for how organizations can benefit from IntelliMirror.

Remote OS Installation An overview of the features of

Remote OS Installation and scenarios illustrating how organizations can benefit from

IntelliMirror.

Systems Management

Server

An overview of the features of

Systems Management Server, and discussion of its benefits.

Point your browser to: http://www.microsoft.com

/ntserver/management. http://www.microsoft.com




/ntserver/management and http://www.microsoft.com

/smsmgmt.


Technical Papers

The following table lists additional technical papers that are or will be available for administrators and Information Technology (IT) managers who are interested in understanding the details of Windows management services features and technologies.

More information on

Active Directory

Group Policy

Group Policy Scenarios

Microsoft Windows Installer Service

Software Installation and Maintenance

Remote OS Installation Service

User Documents and Settings

Windows Management Instrumentation

(WMI)

Implementing Profiles and Policies for

Windows NT 4.0

Will be available in this web site: http://www.microsoft.com/ntserver/window snt5. http://www.microsoft.com/ntserver/window snt5/techdetails/techspecs. http://www.microsoft.com/ntserver/window snt5. http://www.microsoft.com/ntserver/window snt5/deployment. http://www.microsoft.com/ntserver/window snt5. http://www.microsoft.com/ntserver/window snt5. http://www.microsoft.com/ntserver/window snt5. http://www.microsoft.com/ntserver/manage ment/Techdetails. http://www.microsoft.com/ntserver/manage ment/deployment/planguide/prof_policies.a

sp.
