Windows NTServer Operating System
Abstract
This paper
describes Windows NT® 5.0 Group Policy, and includes information on Group
Policy infrastructure and mechanics, Group Policy Editor (an administrative
tool) and its capabilities, extending the Group Policy functionality, and using
Group Policy on stand-alone computers. It also presents instructions for
creating administrative templates (.adm files).
This paper is
intended for information technology managers and system administrators who are
interested in using Group Policy to manage users’ desktop environments.
Group Policies
are used to specify settings for groups of users and computers, including
software policies, scripts (computer startup and shutdown, and user logon and
logoff), user documents and settings, application deployment, and security
settings.
Note:
This
paper documents Windows NT 5.0 Server Beta 2 functionality.
© 1998
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 NT 5.0 Server Beta 2 functionality.
This white
paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft,
ActiveX, the BackOffice logo, JScript, Visual Basic, Visual C++, Win32,
Windows, 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 •
0698 Part no. 098-XXXXX
CONTENTS
Introduction *
Group Policy and Total Cost of Ownership *
Group Policy Capabilities *
Group Policy Benefits *
Group Policy and the Active Directory *
Group Policy and Security Groups *
What This Document Contains *
Group Policy Overview *
Computer Settings and User Settings *
Software Policies *
Software Management *
User Documents and Settings *
Security Settings *
Scripts *
Group Policy Infrastructure and Mechanics *
Infrastructure *
Administrative Templates (.Adm Files) *
Group Policy Object *
How Group Policy is Applied *
Multiple Group Policy Objects *
Group Policy Hierarchy *
Filtering the Scope of the Group Policy Object *
Delegation Support *
Using
Group Policy on Stand-alone
Windows NT-based Computers *
Local Group Policy Object *
Preventing Computers in a Domain from Inheriting Group Policies *
Extending
the Group Policy Editor
Functionality *
Client
Support For Windows NT, Windows 95,
and WINDOWS 98 *
Migrating
from Windows NT 4.0
to Windows NT 5.0 *
Group Policy Design Considerations *
Appendix A: Administrative Templates *
Creating Custom .Adm Files *
ADM Language Components *
Comments *
Strings *
Help Keyword *
#if Version (for Version Comparison) *
PART *
PartTypes *
NUMERIC *
Appendix B: Active Directory Overview *
Active Directory Namespace *
Glossary *
For More Information *
In Windows NT® 5.0,
Group Policies define user and computer settings for groups of users and
computers. You create a specific desktop configuration for a particular group
of users and computers by deploying the Group Policy Editor Microsoft®
Management Console (MMC) snap-in. The Group Policy settings you create are
contained in a Group Policy Object (GPO) that is in turn associated with
selected Active Directory (AD) objects such as sites, domains, or
organizational units (OUs).
Group
Policy and Total Cost of Ownership
Recent studies
on total cost of ownership (TCO), the costs involved in administering
distributed personal computer networks, cite lost productivity at the desktop
as one of the major costs for corporations. Lost productivity is frequently
attributed to user errors such as modifying system configuration files and
rendering the computer unworkable, or to complexity such as the availability of
non-essential applications and features on the desktop.
One way to
address TCO is for administrators to use Group Policies to create managed
desktop environments tailored to users’ job responsibilities and level of
experience with computers. In Windows NT 5.0, administrators can manage
desktops centrally using the Active Directory Service and its Group Policy
support.
You use Group
Policy Editor and its extensions to define Group Policy options for managed
desktop configurations for computers and users. With the Group Policy editor
you can specify settings for:
- Software Policies.You use Software Policies
to mandate registry settings on the desktop, including operating system
components and applications.
- Scripts (such as computer
startup and shutdown, and logon and log off).
- Software management options (for example, the
applications available to users and those that appear on their desktop).
- User documents and settings (for file
deployment and redirecting special folders).
- Security settings (such as for local
computer, domain, and network security settings).
Using Group
Policy, you can define the state of users’ work environment once and rely on
the system to enforce the policies you define.
Group Policy
provides the following advantages:
- Capitalizes on the
Windows NT 5.0 Active Directory Services.
Group Policy allows for centralized or decentralized
management of policy options.
- Offers flexibility and
scalability.
Group Policy handles a wide range of implementation
scenarios that can be applied to both small businesses and large corporations.
- Provides a simple, integrated
tool for managing policy.
Group Policy Editor is an MMC snap-in that extends other
Active Directory administrative tools such as the Active Directory Manager,
Active Directory Site and Services Manager, and Computer Management snap-ins.
Administrators can delegate control of Group Policy Objects.
- Has a clear interface and is
easy to use.
Provides slow link detection and straightforward,
unobtrusive feedback.
- Provides reliability and
security
Group
Policy and the Active Directory
Group Policy
extends and takes advantage of the Active Directory. Group Policy settings are
contained in Group Policy Objects that are in turn associated with these Active
Directory containers: sites, domains, or organizational units.
Group
Policy and Security Groups
You can filter
Group Policy by using membership in Security Groups and setting Access Control
List (ACL) permissions. Doing so enables fast processing of Group Policy
Objects and allows Group Policy to be applied to Security Groups. By using ACLs
and Security Groups, you can modify the scope of Group Policy Objects.
This document
describes Windows NT 5.0 Group Policy, including Group Policy
infrastructure and mechanics, delegation, filtering, and extending the Group
Policy Editor functionality. It also presents information on migrating from
Windows NT 4.0 to Windows NT 5.0, a brief overview of key
Windows NT 5.0 Active Directory concepts, and creating administrative
templates (.adm files).
In
Windows NT 4.0, you used the System Policy Editor tool to configure user
and computer settings stored in the Windows NT Registry database. Using
System Policy Editor, you could create a system policy to control user work
environment and actions, and to enforce system configuration settings for all
computers running Windows NT Workstation and Windows NT Server.
System policies are registry settings that define the behavior of various
components of the desktop environment.
Windows NT
5.0 introduces Group Policy Editor, a tool that extends the functionality of
System Policy Editor and provides enhanced capabilities for configuring user
and computer settings for groups of computers and users. Group Policy Editor is
a Microsoft Management Console snap-in that includes built-in features for setting
Group Policy. Group Policies define the various components of the user’s
environment that system administrators need to manage, and include software
settings, application deployment options, scripts, user settings and document
options, and security settings.
The Group Policy
settings you specify are contained in a Group Policy Object that is in
turn associated with selected Active Directory objects (site, domain, or
organizational unit).
As mentioned
previously, Group Policy makes the most of Windows NT 5.0 Active Directory
containers and Security Groups. 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 NT
5.0 Security Group. To filter Group Policy, you use the standard
Windows NT security ACL Editor user interface. You also use ACL
permissions to delegate the use of the Group Policy Editor tool.
The following
graphic illustrates a Group Policy and Active Directory scenario:
Computer
Settings and User Settings
At the root of
the Group Policy Editor namespace are two parent nodes: Computer Settings and
User Settings. These are the parent folders you use to configure specific
desktop environments and to enforce Group Policies on computers and users on
the network.
Computer
Settings
include policies that specify operating system behavior, desktop appearance,
application settings, assigned applications, file deployment options, security
settings, and computer startup and shutdown scripts. Computer-related Group
Policies are applied when the operating system initializes.
User Settings include all
user-specific information such as operating system behavior, desktop settings,
application settings, assigned and published applications, file deployment
options, security settings, and user logon and logoff scripts. User-related
Group Policy is applied when users log on to the computer.
Note:
You
can specify Group Policy to be applied to all users of specific computers. This
is useful in public computing environments such as libraries or schools, for
example, where you want to provide a specific desktop configuration regardless
of which user logs on to the computer. To set user settings per computer, use
the Software Policies node under Computer Settings.
The Group Policy
Editor's Software Policies node includes all registry-based Group Policy
information—this is what the Windows NT 4.0 system policies controlled.
Software Policies settings include Group Policy for the Windows NT 5.0
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 that are specific to a user who logs on to a given workstation
or server are written to the registry under HKEY_CURRENT_USER (HKCU),
and computer-specific settings are written under HKEY_LOCAL_MACHINE (HKLM).
To generate the
namespace under the Software Policies node of the Group Policy Editor, you use
either custom administrative templates (.adm files) or an MMC extension snap-in
to the Group Policy Editor. For more information on Administrative Templates, see
Appendix A.
You use the
Application Deployment Editor extension to centrally manage software
distribution in your organization. You can install, assign, publish, update,
repair, and remove software for groups of users and computers.
You assign applications
to groups of users so that all users who require the applications automatically
have the application on their desktops—without requiring the administrator or
technical personnel to set up the application on each desktop. When you assign
an application to a group of users, you are actually advertising the
application on all the users’ desktops. The next time a user logs on to
Microsoft Windows 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, and they can decide whether or not to
install such applications. When you publish an application, no shortcuts to the
applications 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 tool, which
includes a list of all published applications that are available for them to
use. Or users can open a document file associated with a published application
(for example, an .xls file to install Microsoft Excel).
You use the User
Documents and Settings extension to add files, shortcuts, or folders to special
folders that represent the user’s desktop. Special folders are those located
under the %Windir%\Profiles folder (where %Windir% is the Windows NT
folder), and they include folders such as My Documents, Start menu, Desktop,
Favorites, and so on. The files you specify are delivered to the user’s desktop
at either machine startup (if specified under Computer Settings), or upon user
logon (if specified under User Settings). The files you place in the Computer
Settings node will be available to all users of that computer. The files you
place in the User Settings node will be available only to the specified
user, regardless of which computer the individual logs on to.
Note that you
can place any files in the Favorites folder; however, the Favorites menu will only
display files that are shortcuts—that is, file types that are marked in the
registry as "IsShortcut" under the ProgID key. This includes
.url, .lnk, .pif, and so on.
You can use the
User Documents and Settings extension to perform the following tasks:
- Redirect any of the special
folders in a user profile to an alternate location (such as a network
destination). 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 the users’
documents are available when they roam from one computer to another.
- Reduce the time it takes to
connect to and disconnect from the network. In Windows NT 4.0, the My
Documents folder is part of the roaming user profile. 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 is managed and protected by the information technology department. - Make users’ network-based My
Documents available to users when they are disconnected from the corporate
network by using Client Side Caching technologies.
- Publish shortcuts or files in
any special folders. For example, you can use this feature in the
following ways:
- You can place a URL shortcut to
the Technical Support Web page on everyone’s desktop or among their
Microsoft Internet Explorer Favorites.
- A group assistant could put a
"Welcome to the Windows NT Group" document on users’
desktops.
Special folders
include the following:
|
Computers |
Users |
|
Application Data |
Application Data |
|
Desktop |
Desktop |
|
Start Menu |
Favorites |
|
Programs Startup |
Local Settings |
|
|
My Documents My Pictures |
|
|
NetHood |
|
|
PrintHood |
|
|
SendTo |
|
|
Start Menu |
|
|
Programs Startup |
You use the
Security Settings extension to define security configuration for
computers within a Group Policy Object. A security configuration consists of
settings applied to each security area supported for the Windows NT
Workstation or Server. This configuration is included within a Group Policy
Object. This security configuration is then applied to computers as part of the
Group Policy enforcement.
The Security
Settings extension has been designed to complement existing system security
tools such as Access Control List Editor, Local User Manager, and Server
Manager. Security Settings extension defines an engine that can interpret a
standard security configuration and perform the required operations
automatically in the background. 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. The term refers to
computer security settings for password policy, lockout policy, and
Kerberos policy in Windows NT 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. This refers to
computer security settings for built-in groups that have certain
predefined capabilities. Restricted Group Policies affect the membership
of these groups. Examples of restricted groups are local groups (such as
administrators, power users, print operators, and server operators), as
well as global groups (such as domain administrators).
You can add categories that you consider sensitive or
privileged to the Restricted Group Management list, along with their membership
information, and you can then track and manage them. In addition to group
membership, Restricted Group Policies track and control reverse membership of
each restricted group, the groups to which a selected group belongs. You can
use reverse membership to control exactly which groups your restricted members
can join, or to limit a selected category of users to one membership group and
prevent them from joining any others.
- System Services. These control
configuration settings and security options (ACLs) for system services
such as network services, file and print services, telephone and fax
services, and Internet/intranet services, and so on. Security Settings
extension directly supports general settings for each system service. This
includes startup mode and security on the service. Note that the name of
the service must be the same as the one used by Service Control Manager.
- Registry. This is used to
configure and analyze settings for security descriptors (including object
ownership), the ACL, and auditing information for each registry key.
When you apply security on registry keys, the Security
Settings extension follows the same inheritance model as used for all
tree-structured hierarchies in Windows NT 5.0 (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 will reduce the administrative overhead
that would result from a needlessly complex access control structure.
- File System. This is used to
configure and analyze settings for security descriptors (including object
ownership), the ACL, and auditing information for each object (volume,
directory, or file) in the local file system.
Microsoft
supplies the following set of predefined configuration files for common
security scenarios:
- Typical workstation settings
(idealws.inf)
- Secure workstation settings
(securews.inf)
- Secure domain controller
settings (securedc.inf)
- Sample workstation settings
(sample.inf)
- Sample domain controller
settings (sampledc.inf)
By default,
these security configuration files are stored in
\%systemroot%\security\templates. You can use these or other security
configurations as the basis for your security settings, and then edit the
settings according to your requirements.
Security
configurations are stored as .inf files in a text format. When you create and
assign a security configuration or edit an existing security configuration,
Security Settings extension processes the configuration file and makes the
corresponding changes to the associated computers as part of Group Policy.
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 NT
5.0 includes Windows Scripting Host, a language-independent scripting host for
32-bit Windows platforms that includes both VBScript and JScript scripting
engines. Microsoft anticipates that other software companies will provide
ActiveX® scripting engines for other languages such as Perl, TCL, REXX, and
Python. Windows Scripting Host will also support those languages.
For more
information about Windows Scripting Host, check the following URL:
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.
Group
Policy Administrative Requirements
Note that to set
Group Policy for a selected AD object, you must have a Windows NT Domain
Controller installed, and you must have read/write permission to access the
system volume of domain controllers (Sysvol folder) and Modify rights to the
currently selected directory object. The System Volume folder is automatically
created when you install a Windows NT 5.0 Domain Controller (or promote a
server to Domain Controller).
The following
sections introduce the Group Policy infrastructure and storage locations, and
provide an overview of how Group Policy is applied.
You create Group
Policy by using the Group Policy Editor MMC snap-in either as a stand-alone
tool or as an extension to the Active Directory Manager, the Active Directory
Site, and Services Manager by using the Manage Group Policy verb. (You can
access the Group Policy Editor extension from the Active Directory Manager
console or the Active Directory Site and Services Manager console by selecting
a site, domain, or OU, and then choosing Manage Group Policy on the Task
menu.)
All Group Policy
settings are contained in Group Policy objects that are associated with Active
Directory containers (sites, domains, or OUs), thus maximizing and extending
the Active Directory.
You can filter
the effects of Group Policy on computers and users by using membership in Security
Groups and setting ACL permissions. This approach ensures faster processing of
Group Policy Objects, while allowing Group Policy to be applied to Security
Groups. Furthermore, you can limit the scope of a Group Policy Object by using
Security Groups and ACLs.
Group Policy
uses a document-centric approach. For example, by analogy, Group Policy Editor
is to Group Policy Objects as Microsoft Word is to .doc files.
Administrative
Templates (.Adm Files)
The Group Policy
Editor requires a source to create the user interface settings an administrator
can set. For this purpose, the Group Policy Editor can employ either an MMC
snap-in extension to the Group Policy Editor snap-in, or an ASCII file referred
to as an administrative template (.adm) file. The .adm file specifies the
registry settings that can be modified through the Group Policy Editor 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 Editor 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.
For more
information on .adm files, see Appendix A: Administrative Templates.
When you use the
Group Policy Editor, you create Group Policy settings that are contained in a
Group Policy Object. These Group Policy Objects are in turn associated with
selected directory objects such as sites, domains, or OUs.
Group Policy
Objects store Group Policy information in two locations: a Group Policy
Container and a Group Policy Template, described in the following section.
Group Policy
Container is an Active Directory object that stores Group Policy Object
properties; it includes subcontainers for Machine 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.
The Group Policy
Container stores the Class Store information for the Application Deployment
Editor, an extension of Group Policy Editor. The Windows NT Class Store is
a Windows NT 5.0 Server-based repository for all applications, interfaces,
and APIs that provide for application publishing and assigning.
Group Policy
Objects also store Group Policy information in a folder structure called Group
Policy Template that is located in the System Volume folder of domain
controllers (Sysvol) in the \Policies subfolder. The Group Policy Template is
the container for all software policy, script, file, and application deployment
information.
When you modify
a GPO, the directory name given to the Group Policy Template is the globally
unique identifier of the Group Policy Object that you modified. For example,
let us assume 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\{47636445-af79-11d0-91fe-080036644603}
where the second
sysvol is shared as SYSVOL. (The default location of the Sysvol folder
is %systemroot%).
In the root of
each Group Policy Template folder is a file called Gpt.ini. This file contains
the following information:
[General]
Version=0
//Version number of the Group Policy Object
Disabled=0
// 1=disabled – this is only valid for local Group Policy Object
(%systemroot%\system32\GroupPolicy)
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
The Gpt.ini file
defines whether the local GPO is disabled or not; for other GPOs this
information is stored in the Active Directory.
Group
Policy Template Subfolders
The Group Policy
Template folder contains the following subfolders:
- Adm. Contains all of the
.adm files for this GPT.
- Scripts. Contains all the
script and related files for this GPT.
- 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 Editor 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.
The Software
Policies extension of the Group Policy Editor 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 Editor) 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
Settings, which is stored in the \Machine subdirectory, and one for User
Settings, which is stored in the \User subdirectory.
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 only
be applied 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 Windows NT 5.0 Group
Policy Editor is a text file. The Windows NT 5.0 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)
Registry values
begin with the symbol "[" and end with "]":
[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 will be used. The following values have special
meaning for this field:
**DeleteKeys — a semi-colon delimited list of
keys to delete.
For example: **DeleteKeys NoRun;NoFind.
**SecureKey — **SecureKey=1 secures the key, giving
administrators and the system full control, and users read-only access. **SecureKey=0 resets access to the key
to whatever is set on the root.
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_BINARY
REG_DWORD
REG_EXPAND_SZ
REG_MULTI_SZ
REG_SZ
Size is 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 zero. 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 valuename
Used
as a value of the designated key.
**DelVals
// Deletes all values in a key
Used
as a value of the designated key.
**SecureKey
// Makes the named key secure. See the SecureKey section for details.
The Registry.pol
file contains data to be written to the registry based on the settings
specified with the Group Policy Editor, and the names of any scripts and their
command lines (in the form of registry keys and values).
**SecureKey
ACLs can be
applied by using a special flag that can be set in the Registry.pol file. When
the Registry.pol file is being parsed, if **SecureKey=1 is found, the
following permissions get set on the registry key that is currently being
modified:
Administrators:
Full Control
Operating
System: Full Control
User: Read
A reset flag (**SecureKey=0)
returns the ACLs to whatever ACLs are set at the root of HKCU. Third-party
vendors can implement this functionality through .adm files by using the SECUREKEY
keyword. This gives the administrator a check box in the user interface to
enable the secure flag. This is needed for
legacy reasons. Applications need this capability to have a secure key when the
application does not yet use the HKCU\Software\Policies tree (which is secure)
for storing their settings.
Note:
Any
application that does not store its policies into the
HKCU\Software\Policies tree will break when a user is moved from one OU to
another with different policies. This is because other keys are not cleaned up
(deleted) during the processing of policy.
To delete keys
or values, set a "**" value in the Registry.pol file. Keys with this
designation are special keys written to the Registry.pol file that tell
Winlogon to act differently based on these values. See the Registry.pol File
Format section for details on deleting keys and values.
When the SECUREKEY
keyword is encountered, a DWORD type key, **SecureKey, is written to the
Registry.pol file. The value is either 0 (unsecure) or 1 (secure). This tells
Winlogon whether or not to make the corresponding key secure.
How
Registry.pol Files Are Created
The following
section outlines how to form Registry.pol files:
- When you start the Group Policy
Editor, a temporary registry tree is created that consists of two nodes: USER
and MACHINE.
- As you navigate the Software
Policies node of the Group Policy Editor, .adm files and snap-in extension
nodes are displayed. The .adm files within the Group Policy Editor 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 you specify are written to the appropriate portion of the
temporary registry (either MACHINE or USER).
- When you close the Group Policy
Editor, 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 Editor for the same Group Policy Object for which you have
previously set Group Policies, the registry information from the
corresponding Registry.pol files is imported into the temporary registry
tree. Therefore, when you view the policies, they will reflect the current
state.
Note: The
Group Policy Editor stores its information in two distributed locations, the AD
(Group Policy Container) and Sysvol (Group Policy Template). Because the
information is stored in distributed locations, the potential exists for policy
settings to be overwritten, as illustrated in the following example. If two
administrators were to launch the GPE focused on the same Group Policy Object,
and they are acting on different Domain Controllers (DCs), each of the
administrators can make policy modifications that may be overwritten by the
other. You should note that in all such cases, the last writer’s policy
modifications would be the ones in effect. One way to help prevent such
occurrences is for domain administrators to reduce the number of users to whom
they grant permission to write to any Group Policy Object.
Group Policy for
computers is applied at computer startup. For users, Group Policy is applied
when they log on.
Synchronous
and Asynchronous Processing
You can specify
the processing of Group Policy to be either asynchronous or synchronous. You
can set this option by using Group Policy just as you would for scripts in
Windows NT 4.0. Setting this option will apply to all Group Policy
processing, software policy, application and file deployment, and scripts. The
default option is to process Group Policy asynchronously (the way logon scripts
are processed in Windows NT 4.0 and 5.0).
Periodical
Processing
You can specify
that Group Policy be processed periodically. By default this is done every
eight hours and can be set from seven seconds to 45 days (1,080 hours).
Application
Deployment 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, if an application
were no longer assigned, it would be removed. If a user were employing the
application while Group Policy tried to uninstall it, or if an assigned
application upgrade took place while someone was using it, problems would
occur.
Messages
and Events
When Group
Policy is applied, a WM_WININICHANGE message is sent and an event is
signaled. Applications that can receive the message 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 on the event.
Registry
Reads
APIs also exist
that allow an application to claim (lock) a critical section of the registry,
read the needed values, then release the critical section. If the section is
not released in 10 minutes, then the application will be forced to release it.
This ensures that the background refresh of Group Policy doesn't occur during
the read process.
Group
Policy and Network Connections (Slow Links)
When Winlogon
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 snap-in extensions can determine whether or not to apply policy over
the slow link.
The default
settings are as follows:
- Software Policy - ON (and can
not be turned off)
- Scripts - ON
- Application Deployment - OFF
- File Deployment - OFF
For the scripts,
application deployment, and user settings and documents snap-ins, a Group
Policy will be provided for toggling the settings.
On-Demand
Processing
Group Policy
will also be applied on demand. To do this, applications can call the RefreshPolicy()
API, which allows applications to request a policy refresh.
Domain
Change
When the domain
to which a computer belongs changes, Winlogon will use the RefreshPolicy()
API to reapply Group Policy. This process no longer requires
a re-boot.
You can
associate multiple Group Policy Objects with a single site, domain, or
organizational unit, and you can prioritize how these Group Policy Objects
affect the directory object to which they are applied. Conversely, multiple
sites, domains, and OUs can use a single Group Policy Object.
Any site,
domain, or OU may be associated with any Group Policy Object, even across
domains.
By default Group
Policy is inherited and cumulative, and it affects all computers and users in
an AD 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 AD container
furthest away from the computer or user object. The AD container closest to the
computer or user can override Group Policy set in a higher-level container.
Options exist
that allow you to enforce the Group Policy in a specific Group Policy Object so
that Group Policy Objects in lower-level AD containers are prevented from
overriding that policy. You can also block inheritance of Group Policy from
parent AD containers. The enforced option always takes precedence.
Filtering
the Scope of the Group Policy Object
You can further
refine which machines and users a particular Group Policy Object influences by
using Windows NT 5.0 security groups. This means that for any Group Policy
Object, you can filter the Group Policy Object’s effect on members of specified
security groups. To do this, you use the standard Access Control List editor.
You gain access to the ACL editor by selecting a Group Policy Object’s Property
page and then clicking Security.
Administrators
also use the ACL editor to determine which users can modify a Group Policy
Object.
You delegate
Group Policy by creating and saving Group Policy Editor MMC consoles (.msc
files), and then specifying which Users and Groups have access permissions to
the Group Policy Object or to a given AD container (site, domain, or OU). You
define permissions for a given Group Policy Object by using the ACL editor;
these permissions grant or deny access to a Group Policy Object by specified
groups.
Setting
Permissions (ACLs) for Group Policy
The Group Policy
Editor’s Properties page hosts the security ACL editor. To use the ACL
editor, right-click the root node of the Group Policy Editor, click Properties,
and then click Security. You use the Security property page to
set access permissions (ACLs) on a selected Group Policy Object to allow or
deny access to the Group Policy Object by specified groups.
Administrators
can specify which groups of users and computers have Apply Group Policy Access
Control Entries (ACE) access to the GPO. Groups that have Apply Group Policy
and read access to the GPO receive the Group Policies contained in it, and
groups that do not have Apply Group Policy or read access to the GPO do not
get the Group Policies contained in it. By default, authenticated users have
both Apply Group Policy and read ACL permissions. This means that users cannot
modify the information in the GPO. You should note that if you place sensitive
data in a GPO that you do not want all affected users to be able to read, you
may want to change the default ACL permissions and give read permissions only
to those users who require that data. By default, domain administrators have
Full Control permissions, but they do not have Apply Group Policy ACLs. This
means that the GPO policy won’t apply to domain administrators by default, but
they will be able to modify GPOs.
Network
administrators (members of the domain administrators group) can also use the
ACL editor to determine which administrator groups can modify policies in GPOs.
To do this, the network administrator can define groups of administrators (for
example, marketing administrators), and then provide them with read/write
access to selected GPOs. This allows the network administrator to delegate
control of the GPO policies. Granting read/write access to a GPO allows
administrators to control all aspects of it.
The ACL editor
will also be hosted in the Manage Group Policy dialog box. To access the
ACL editor, you can right-click an AD object in the Active Directory Manager
MMC console, click Task, click Manage Group Policy, and then
click Security. Similarly, you can also access the ACL editor in the AD
Sites and Services Manager MMC console (by first clicking a site object).
Domain administrators can then use the ACL editor to set read/write permissions
for groups of administrators, as described previously.
You can set
policy for the local machine for any computers that are not members of a
domain. To set local policy, you use the Group Policy Editor focused on the
local computer. You will be able to access the Group Policy Editor tool by
using the Computer Management MMC snap-in for the local computer.
On stand-alone
computers, a Local Group Policy Object (LGPO) exists—this is just the Group
Policy Template portion. The location of the Local Group Policy Object is
%SystemRoot%System32\GroupPolicy. When focused on a GPO, the Group Policy
Editor notifies its extensions and they are loaded based on whether or not they
are appropriate for local use.
The following
table indicates whether or not the Group Policy Editor (GPE) extensions will
open when the Group Policy Editor is focused on a Local Group Policy Object.
|
Group Policy Editor Extension |
Loaded when GPE focused on LGPO |
|
Application Deployment |
No |
|
File Deployment |
No |
|
Scripts |
Yes |
|
Software Policy |
Yes |
|
Security Settings |
Yes |
If the computer
is not a member of a domain, the Group Policy Editor will automatically open to
the Local Group Policy Object.
Preventing
Computers in a Domain from Inheriting
Group Policies
Administrators
can exempt certain computers from inheriting Group Policy from the domain to
which they belong (or from the site, if the computer policy is set at that
level of policy hierarchy). In such cases, the computer will function as if it
were a stand-alone computer with regard to Group Policy. You can enable this
option for any Group Policy Object by using the following registry switch (this
will be included in the .adm file that ships with the product):
HKLM\Software\Policies\Microsoft\Windows\System
DisableGPO Reg_Dword 1,0
If you set this
registry switch, the affected computers will only receive policy from the Local
Group Policy Object; that is, they will not receive policy from the
domain. This capability is useful for non-corporate computers, for example,
employees’ home computers or those for which you do not want to enforce policy.
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, then LGPO policy is applied.
Third-party
application developers can extend the Group Policy Editor 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 A: Administrative
Templates.
- Create a Group Policy Editor
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 Editor MMC snap-in to write registry-based Group Policy to
the Group Policy Template. The Group Policy Editor API documentation will
be included in the Microsoft Platform Software Development Kit. For more
information, check the following URL: http://www.microsoft.com/msdn/sdk/platform.htm.
- 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/App
Name/Version naming convention for such folder. Then you should place the
required files in that GPT sub-folder. On the client side, Winlogon will
call the client side extension for the tool. This in turn would process
the information stored in the directory in the GPT. It is up to the
application developer to 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 for Components for Setup and Systems Management Services
Developers at the following URL:
http://www.microsoft.com/mdsn/sdk/sysmgmt.htm.
The
Windows NT 5.0 Group Policy Editor tool does not provide client
support for Windows NT 4.0 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 tool (Poledit.exe) files.
However, the System Policy Editor user interface will not be exposed in the
Windows NT 5.0
user interface.
You will be able
to install the System Policy Editor tool, Poledit.exe, in Windows NT
Workstations by using the Windows NT 5.0 Optional Administrative Tools package.
During Windows NT Server 5.0 Setup, you can choose to install an optional
component called Windows NT 5.0 Optional Administrative Tools, a Windows
installer package (.msi file) that contains all the information necessary to
install the optional administrative applications—this package is included in
the Windows NT 5.0 Server product. For information on installing System
Policy Editor and using the Windows NT 5.0 Optional Administrative Tools
package, refer to the Windows NT Server 5.0 documentation.
Clients running
Windows 95 and Windows 98 will still need to use the Windows NT 4.0 System
Policy Editor, Poledit.exe.
Note that both
Windows NT Workstations and computers running Windows 95 and Windows 98
will have to copy the resultant .pol file to the domain’s Netlogon share
(…\system32\Repl\Import\Scripts).
Migrating
Windows NT 4.0-based clients to Windows NT 5.0, and Windows NT
4.0-based servers to Windows NT
LGP = Local
Group Policy
LSDOU = Local
Group Policy, Site, Domain, OU
|
Domain |
Windows NT 4.0 Client Receives this Policy |
Windows NT 5.0 Client Receives this Policy |
|
Windows NT 4.0 |
Windows NT 4.0 |
LGP + Windows NT 4.0 |
|
Windows NT 5.0 AD – Windows NT 5.0 native mode. |
Windows NT 4.0 |
LSDOU |
|
Windows NT 5.0 AD – mixed mode (default). |
Windows NT 4.0 |
LSDOU + Windows NT 4.0 |
|
Windows NT
5.0 DS – mixed mode. |
Windows NT 4.0 |
LSDOU +
Windows NT 1 Like logging on
with cached credentials. If not fixed, then LGP + Windows NT 4.0. |
|
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 will receive leftover policy from the domain. |
1. LGP. 2. If setup,
manual Windows NT 4.0 policy. 3. If the client was previously in a Windows NT 5.0 domain, the client will receive some leftover policy from the domain2. |
1To make this work,
requires assuming that the role of the computer (Windows NT 5.0-based
client) is the same as the user. Note that one exception is a user that has never
had a profile. In that case, that user will get no policy.
2Leftover policies refer
to those policies that are outside of the two clean-up locations in registry, HKLM
and HKCU (\Software\Policies and \Software\Microsoft\Windows\Current
Version). For example, Logon Banner.
Note:
Third-party
.adm files that do not use the Policies tree also will have Policies left
behind.
This section
highlights issues you should consider when planning and designing your Group
Policy deployment.
Active
Directory Structure and Group Policy Implementation
When you plan
and design your Active Directory structure, you need to consider how you want
to implement Group Policy for your organization. This is crucial because how
Group Policy is applied depends on the Active Directory structure you define.
If you carefully construct your Active Directory design with Group Policy in
mind, you will be able to make the most of your Active Directory structure and
simplify your Group Policy implementation and administration.
Group Policy is
applied to Group Policy Objects that are in turn associated with specific
Active Directory containers. Group Policy is processed hierarchically in the
following order: site, domain, and OU; the Active Directory container closest
to the computer or user overrides Group Policy set in a higher-level Active
Directory container. By default, the Group Policy settings you define are
cumulative and are inherited from parent Active Directory containers. Note that
this is the default behavior and mechanisms exist that let you either
force or prevent Group Policies from affecting users or computers in sites,
domains, or Ous. However, for optimum performance and simplification, it is
best to minimize the use of these mechanisms when applying Group Policy. For
additional control, one or more Computer or User memberships in Security Groups
can be used to filter the effect of a GPO. This is done by modifying the ACLs
for a GPO such that only members of certain Security Groups will be affected by
the GPO.
Using the Group
Policy capabilities in various combinations makes Group Policy very flexible,
allowing it to meet a variety of business requirements. The overriding caution
is to use the simplest combination of these capabilities as possible, and to
plan their use carefully. The following section lists specific examples of
areas to consider when doing Group Policy planning.
Minimize
the Use of the Block Policy Inheritance Feature
As mentioned
previously, you can prevent Group Policy settings of parent AD containers from
affecting users and computers in lower-level AD containers. This is a useful
and powerful feature that you should use judiciously only when a particular
situation requires it. Blocking the inheritance of policy from parent AD
containers can complicate troubleshooting policy.
Minimize
the Use of the Force Policy Inheritance Feature
You can also
ensure that the policy settings you specify in a given Group Policy Object at a
higher-level AD container are enforced on lower-level AD containers. Only use
this strong and helpful feature when circumstances require it. Overuse of this
feature with other related features such as Block Policy Inheritance can
complicate troubleshooting policy.
Minimize
the Number of Group Policy Objects Associated with Users in Active Directory
Containers
You can assign
more than one Group Policy Object to a particular AD container if your
situation requires you to do so; however, you should note that the number of
Group Policy Objects you assign can affect the logon processing time. During
logon time, each Group Policy Object associated with an AD container (and that
the user or computer has Apply Group Policy ACE access to) is processed, so the
greater the number of associated Group Policy Objects, the longer logon will
take to process them.
One way to lower
the number of Group Policy Objects affecting users is to use Security Groups as
a way of filtering GPOs. If you apply policy from multiple Group Policy
Objects to an Active Directory container and use Group Policy filtering, making
some policies invisible to some users, performance will be significantly
improved. This is because fewer Group Policy Objects would be processed.
If your
situation requires you to use filtering based on security groups, you should
ensure that the users whom you intend to receive policy from a particular Group
Policy Object have Apply Group Policy ACE access to that GPO. If the
users do not have Apply Group Policy access to that GPO, they will not
get those policies.
Override
User-Based Group Policy with Computer-Based Group Policy Only When Necessary
You can set user
settings per computer and thus override user-specific policies with
computer-specific policies. This is useful when you want to provide a specific
desktop configuration regardless of which users log on to the computer. To set
user settings per computer, you would use the Software Policies node under
Computer Settings in the Group Policy Editor console.
Avoid
Using Cross-Domain GPO Assignments
Although you can
assign Group Policy Objects from different domains to a single AD container if
a particular situation requires it, you should note that in such cases Group
Policy processing would be slower. This is because domain boundaries
are crossed.
Administration
of Group Policy Objects
Delegation of
authority, separation of administrative duties, central versus distributed
administration, and design flexibility are important factors you’ll need to
consider when designing Group Policy and selecting which scenarios to use for
your organization.
Whether or not
you implement Group Policy in a modular fashion (for example, creating a Group
Policy Object specific for software management options, a Group Policy Object
specific for security configuration options, and so on) will be determined by
the administrative requirements and roles in your corporation. For example, if
administrators are organized according to their duties (such as software
management administrators, security administrators, logon administrators, and
so on), you may find it useful to define policies in Group Policy Object
modules.
Delegation of
authority will depend largely on whether you use centralized or distributed
administration in your corporation. Based on their particular corporate
requirements, network administrators can use ACL permissions to determine which
administrator groups can modify policies in Group Policy Objects. Network
administrators can define groups of administrators (for example, software
management administrators), and then provide them read/write access to selected
Group Policy Objects, allowing the network administrator to delegate control of
the Group Policy Object policies. Administrators who have read/write access to
a Group Policy Object can control all aspects of that Group Policy Object. If
you are a network administrator that uses centralized administration, you may
choose to give other administrators read-only access to Group Policy Objects.
Doing so would allow those administrators to view the Group Policy Objects, but
they would not be able to change them.
To define the
user interface settings administrators can configure, the Group Policy Editor
uses either administrative templates (.adm files) or MMC extension snap-ins to
the Group Policy Editor MMC. You can create custom .adm files to extend the
capabilities of the Group Policy Editor. The following sections present
information on the ADM language and components:
The .adm file:
- Defines a hierarchy of
categories and subcategories that together specify the registry settings
that can be modified using the Group Policy Editor UI.
- Indicates the registry
locations where changes should be made in the instance of a particular
selection.
- Specifies any options or
restrictions (in values) associated with a certain selection.
- In some cases, it specifies a
default value to use if a selection is activated.
Adding
.Adm Files
To add your .adm
files, you select Software Policies under either the Computer
Settings or the User Settings node in the Group Policy Editor MMC
console, and then select Add/Remove Templates from the Task menu.
When you add an
.adm file, that file is added to the Sysvol\Policies\GPO_GUID\ADM folder of the
currently selected Group Policy Object. The Group Policy Editor namespace is
defined by the hierarchy of category and subcategory 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 in that System Policy Editor displays them more than once in such
cases.
Namespace
Naming Conventions
When you create
custom entries for the Software Policies node, we strongly recommend that you
create the namespace using the \CompanyName\Product\Version (or
\CompanyName\Product&Version) naming convention that is also used in the
registry. For instance, the operating system settings for Windows NT 5.0
will be in \Microsoft\Windows NT.
Registry
Key Locations for Policy
The following
are registry key locations that will be cleaned up if a policy should no longer
be applied; other keys will not be 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)
Two older keys
are also cleaned up, but you should note that this is done only to
provide downlevel compatibility. These keys should not be used:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies
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.
Note:
This
section covers only the mandated system and application policies that were
previously administered using the Windows NT 4.0 System Policy Editor
tool. Post-Beta 2.0 releases of Windows NT 5.0 will present updated
information on .adm file creation.
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.
The Group Policy
Editor requires a string to be defined in the [strings] section of the
.adm file for anything preceded by "!!". The purpose of this is to
use variables to define long strings of text that will 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.
CATEGORY, POLICY, PART
and DEFAULT should always be defined using 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 by double quotation marks.
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"
Result: The My First Category string (without the
quotes) would be displayed in the Group Policy Editor user interface.
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 Settings node in the Group Policy
Editor.
- USER. This section
includes entries found in the User Settings node in the Group Policy
Editor.
Note that 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 Editor loads.
The CATEGORY
name is displayed in the Group Policy Editor as a node in either Computer
Settings or User Settings, 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 Editor list
box. It may optionally be enclosed by 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 will be used by all child categories, policies, and parts, unless
they specifically provide a key name of their own. Names with spaces must be
enclosed by 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
Note that 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
To identify the
policy modifiable by the user, you use the key word POLICY. This is much
like the CATEGORY key word in that we start out 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.
Defines the
options available within a policy. You must 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 will be 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 Editor, then the VALUENAME
needs to be within a PART (see the PART section).
You can use VALUEOFF/VALUEON
to write specific values based on the state of the option. You 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
VALUENAME
ValueToBeChanged
VALUEON
5 VALUEOFF 10
END
POLICY
In each policy,
there can be one HELP keyword followed by at least one space, and then
the help string in quotes or a reference to the help string. For example:
POLICY
!!NetCache
KEYNAME
Software\Policies\Microsoft\Windows\NetCache
#if
VERSION >= 3
HELP
!!IntelliMirrorHelp
#endif
.....
[Strings]
IntelliMirrorHelp="Help
for Windows NT IntelliMirror\n\nThis policy allows you to configure the file
system caching options."
In the preceding
example, Help is offered for the Client Side Caching (CSC) caching options. The
HELP keyword is wrapped in
the version defines to allow this same .adm file to be used with the old policy
editor (which is version 2).
#if
Version (for Version Comparison)
The following
syntax is used for version comparison:
#if
Version (operator) x
#endif
The valid
operators are listed in the following table.
|
Operator |
Signifies |
|
> |
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. |
|
>= |
Greater than or equal to. For example, a >= b means a is greater than or equal to b. |
|
<= |
Less than or equal to. For example, a <= b means a is less than or equal to b. |
You can use PART
to specify various options, including drop-down list boxes, text boxes, and
text in the lower pane of the Group Policy Editor.
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 Editor 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
is information about the part.
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 FLAG(s) {one or more,
defined later}
...
END PART
or:
PART
!!MyVariable FLAG(s) END PART
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 it removes the value completely.
Using the following modifiers can provide additional options. The PartType
referenced previously in the PART section can be one of the following:
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.
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 Editor will 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 ANSI to OEM and
back.
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
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 zero 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 if specified.
- VALUEON. Overrides the
default "on" behavior of the check box if specified.
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
Displays a combo
box with a drop-down list style. The user may only choose 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 valuename
and value pair will be deleted.
ACTIONLIST is an optional action
list to be used if this value is selected.
REQUIRED specifies that the Group
Policy Editor will not allow a policy containing this part to be enabled unless
a value has been entered for the part.
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 will be 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. Note that 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" will generate the value names "SomeName1",
"SomeName2", and so on. The prefix can be empty (""),
which will cause the value names to be "1", "2", and
so on.
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 Editor will 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
VALUENAME
ValueToBeChanged
END
PART
Displays text
only.
For example:
PART
!!MyVariable TEXT
END
PART
Writes a value
to registry with data type REG_DWORD. This is the default unless another
type is specified.
For example:
PART
!!MyVariable NUMERIC
VALUENAME
ValueToBeChanged
END
PART
Writes a value
to registry with data type REG_EXPAND_SZ.
For example:
PART
!!MyVariable EDITTEXT EXPANDABLETEXT
VALUENAME
ValueToBeChanged
END
PART
Writes value to
registry with data type REG_SZ.
For example:
PART
!!MyVariable EDITTEXT
VALUENAME
ValueToBeChanged
END
PART
Generates an
error if the user does not enter a value when required.
For example:
PART
!!MyVariable EDITTEXT REQUIRED
VALUENAME
ValueToBeChanged
END
PART
Specifies
maximum length of text.
For example:
PART
!!MyVariable EDITTEXT
VALUENAME
ValueToBeChanged
MAXLEN
4
END
PART
Specifies a
Default Value. This can be used for text or numeric data.
For example:
PART
!!MyVariable EDITTEXT
DEFAULT
!!MySampleText
VALUENAME
ValueToBeChanged
END
PART
or:
PART
!!MyVariable NUMERIC
DEFAULT
5
VALUENAME
ValueToBeChanged
END
PART
Specifies lowest
and highest valid values.
For example:
PART
!!MyVariable NUMERIC
MIN
100 MAX 999 DEFAULT 55
VALUENAME
ValueToBeChanged
END
PART
Displays a list
box of options from which to choose.
For example:
PART
!!MyVariable DROPDOWNLIST
VALUENAME
ValueToBeChanged
ITEMLIST
NAME
"First" VALUE NUMERIC 1
NAME
"Second" VALUE NUMERIC 2
NAME
"Third" VALUE NUMERIC 3
NAME
"Fourth" VALUE NUMERIC 4
END
ITEMLIST
END
PART
Line
Breaks
To create a line
break, use this syntax:
\n
In
Windows NT 5.0, you apply Group Policy settings to a Group Policy Object
(GPO) that is in turn associated with selected Active Directory (AD) objects
such as sites, domains, or organizational units (OUs). This section introduces
key concepts related to the new Windows NT 5.0 Active Directory that are
important to understand before proceeding to Group Policy concepts.
Windows NT
5.0 introduces the Active Directory, a directory service that is secure,
distributed, partitioned, and replicated. Active Directory extends previous
Windows-based 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. Additionally, Active Directory provides the
following benefits:
Querying
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 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 NT 5.0 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 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.
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 Active
Directory, the directory of each domain stores information about only the
objects located in that domain, rather than using one massive store.
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
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 Active Directory. The
scripts use the script language provided by the Active Directory Service
Interfaces.
Integration
with DNS
Active Directory
uses the Domain Naming System (DNS), a set of protocols and services used
throughout the Internet and other Transport Control Protocol/Internet Protocol
(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 permits you to refer to a computer by a name such as headquarters.yourcompany.com,
rather than the computer’s TCP/IP address.
Active Directory
implements a domain and object-naming model based on the Domain Name System.
Windows NT 5.0 domain names correspond to DNS domain names by default.
Windows NT
5.0 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
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 Active Directory. It is an industry-standard directory service
protocol that allows Active Directory to share information with any other
directory service that supports LDAP.
By supporting
these standards, 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.
The Active
Directory includes a new domain model and hierarchical namespace.
Domains
The core unit in
the Microsoft Windows NT 5.0 Active Directory is the domain. All network
objects 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
given 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. The
following figure illustrates this concept.
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. The following figure illustrates this
concept:
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 given 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.
The following
figure illustrates 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 simply 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. Administrators use the
Active Directory Sites and Services Manager to indicate whether a given domain
controller will hold a global catalog. Active Directory automatically generates
the contents of the global catalog from the domains that comprise the directory
by using the normal replication process.
For more
information about Active Directory, refer to the Windows NT 5.0 Server
documentation.
This section
introduces terminology used in this document.
Access
Control Lists
A list of entries that grant or deny specific access rights
to individuals or groups. ACLs associated with each resource determine valid
users
through the Registry Service, and define the types of operations a user
may perform.
Active
Directory
The Windows NT 5.0 directory service that stores
information about all objects on the computer network and makes this
information easy for administrators and users to find and apply. With Active
Directory, users can 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 Active Directory, see Appendix B: Active Directory
Overview.
administrative
templates (.adm files)
Template files that provide settings pertaining to
Windows NT versions 4.0 and 5.0, 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 Editor 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 Editor 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.
application
assignment
In Windows NT version 5.0, you can use the Application
Deployment Editor extension of the Group Policy Editor 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 object (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 in to
a computer running Windows NT 5.0, 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 NT 5.0, you can use the Application
Deployment Editor extension of the Group Policy Editor 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 (AD) class store. Programs do this by storing their
advertisement information in the AD container class store. These advertised
attributes are used to locate the application and all the information required
for installing it. After the application is advertised in the class store, it
can be activated by document association just as an assigned application. Users
can also set up the program using the Add/Remove Programs 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).
class
store
The repository for the advertisement information pertaining
to applications and components that are available to the users of a
Windows NT 5.0 Active Directory container, such as an organizational unit.
The class store provides key information about these applications so that
workstation computers can find the applications as users or other applications
request them.
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 reflect 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, 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
A hierarchical organization of domains. You use the Active
Directory Manager MMC snap-in tool to join domains into trees, and when you do
so the domains are transparently joined together through two-way, transitive
Kerberos trust relationships. Because these trust relationships are two-way and
transitive, a domain joining a tree has trust relationships established
immediately with every domain in the tree. These trust relationships make all
the objects in all the domains of the tree available to all other domains in
the tree. For example, a user or group in any domain can be granted permissions
for any object in other domains in the tree. This also enables the single
network logon of a user for access to any part of the network.
globally
unique identifiers
A globally unique identifier (GUID) consists of 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 Win32® Software Development Kit, or the guidgen tool
included in the Visual C++® development environment. For more information about
GUIDs, see the OLE Programmer’s Reference, Volume One; the Win32
Software Development Kit documentation; and Inside OLE, 2d ed. by Kraig
Brockschmidt, Redmond, Wash.: Microsoft Press, 1995.
lock-down
policy
A lock-down policy is selective use of the five different
types of Group Policy. You can use the Group Policy Editor to create
locked-down user environments where 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 ACLs 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
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.
packages
(.msi files)
Packages contain all the information necessary to describe
to the Windows installer how-to set up an application in every conceivable
scenario: various platforms, different sets of previously installed products,
earlier versions of a product, and numerous default installation locations.
registry
A database in which Windows NT internal configuration
information and machine- 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.
schema
The formal definition of all object classes, and the
attributes that make up those object classes, that can be stored in the
directory. 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 whenever a user logs on or off at any
type of workstation on the network. Windows NT 5.0 supports Windows
Scripting Host Visual Basic Scripting Edition (VBScript) and JScript (.js),
while continuing to support MS-DOS command scripts and executable files.
server-loaded
application
This is a network-installed application. The application
lives on a server and is run from the server.
site
In Windows NT 5.0 you register your network’s physical
topology by defining sites. A site is defined as one or more IP subnets.
Windows NT 5.0 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, 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. For more information about logical domain structure
and physical structure, refer to the chapter entitled "Introduction to
Active Directory," in the Windows NT Server 5.0 documentation.
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.
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 the latest
information on Windows NT Server, check out our World Wide Web site at http://computingcentral.msn.com/forums/default.asp?windowsnt.