This article is based on the latest builds of Windows
2000 Server & Professional RC 1.System policies
Group Policy Objects
Corporate wide settings
One method of managing and locking down server and workstation
configurations under NT 4.0 was by using System Policies.
These provided a centralised method of controlling certain registry settings on a number
of machines throughout a corporate network. Using these, the network administrator could
lock down a desktop, removing items from the Start menu and Control Panel, running custom
shells, and even specifying the wallpaper on the PC. These restrictions could be applied
to individual users, groups or computers in the domain, and could be saved as Template
However, System Policies had a few drawbacks. Firstly, not every aspect of the user
experience could be controlled from their registry settings, meaning that the
administrator had to fiddle about in several different places to achieve the precise
effect required. For instance, under NT 4.0 setting a minimum password length was an
Account Policy which had to be set in User Manager nothing to do with System
Policies. Secondly, once a Policy had been applied, the associated registry changes were
permanent. This meant that even if the policy was subsequently removed, the changes were
not rolled back, leaving the administrator to create yet another policy to reset the
changed registry settings, or effect those changes manually.
In Windows 2000, all the necessary settings are available in a single place under
Group Policies. The whole thing also feels much more part of the operating system now,
rather than the mish-mash of controls that felt as though they had been tacked on to NT
4.0 as an afterthought. Group Policies extend the functionality of the old System Policy
Editor, giving the administrator a much finer degree of control than was previously
possible. As well as user rights and account policies, Group Policies can be used to alter
other security settings, change the behaviour and appearance of the desktop, process
scripts, redirect local folders to the network, and even deploy applications. The
administrator can now control almost every aspect of the computing environment from a
Strangely enough, given that Group Policies are Active Directory-based, the *.adm files
are still there and still have the same purpose they did under NT 4.0. This is a strange
thing to do, given that it prevents multiple administrators from updating the same policy
at the same time, which they would be able to do if the policy objects were stored wholly
in Active Directory (AD). Actually, only the copy on the PDC emulator (one Domain
Controller in a Windows 2000 domain is tasked with emulating an old PDC for backwards
compatibility) can be updated. This gets around the conflict issue, but could introduce
problems of its own only time will tell if Microsoft has got this right.
The other strange thing about Group Policies, given their name, is that they have
absolutely nothing to do with groups. They certainly cannot be applied to groups.
Instead, they are applied at Organisational Unit (OU) level within Active Directory. Fire
up the AD Users and Computers utility and right click on the required domain to bring up
the Properties dialogue box. Under the Group Policy tab you will find there is the Default
Domain Policy that is created when Windows 2000 is installed.
Group Policy Objects
GPOs can be created at site, domain or OU level, and any settings will flow down from
site, to domain, to higher level OUs, and finally to the lowest child OUs. At
any level, multiple GPOs can be defined in which case the settings are applied in
the order the objects are listed. It is possible to apply a GPO to an individual machine,
but it is unlikely that such an option will be exercised too frequently, since the whole
point of the exercise is to provide the administrator with the means to administer and
control multiple machines from a single location. Dont forget that in AD there is
nothing to stop the user and his computer existing in different OUs, so a completely
different set of Group Policy objects might be processed for the computer than for the
When editing a Group Policy Object, there are a number of sections available. As
with the old System Policies you can apply settings to the User Configuration or the
Software Settings: This is where the administrator can publish applications to be
installed on all computers or users to which this Policy applies. Assigned
applications are placed on the Start menu and installed automatically at next logon or
when the user first tries to run them. Published applications appear in the
Add/Remove programs applet allowing users to install these on demand.
Windows Settings: Here the administrator can specify Folder Redirection
settings (to force files normally stored on the users PC to a network location),
Security Settings (User Rights, Audit Policy and Account Policy, for example), Internet
Explorer settings (connection and security settings, for example), and Scripts
(which can be run at computer start-up or shutdown, or at logon or logoff).
Administrative Templates: This is the area that is similar to System Policy,
allowing the administrator to effect changes to Registry settings for a User or Computer.
Remember the problem with the old System Policies when you removed them? With Group
Policies under Windows 2000, if a GPO is removed, all the settings are automatically
rolled back too.
Corporate wide settings
One of the nice things about Windows 2000 is the consistent use of the Microsoft
Management Console (MMC). This Explorer-like interface provides a uniform means of
accessing the various management utilities throughout the OS, and administrators can
create their own Consoles for specific uses and assign them to other administrators or
users to delegate management tasks. This is true of Group Policies too, since it is
possible to create a MMC which includes some or all of the GPO snap-in extensions and
which can be focused on a particular OU if required.
Any settings that are considered "corporate-wide" would be applied at a higher
level such as at the site, domain, or at a higher OU. These higher-level settings are then
inherited automatically at lower levels in the AD tree. Leaving administrators at lower
levels free to concentrate on local settings. Inheritance is a purely linear process, so
that if the domain GPO specifies a wallpaper that says "Acme Inc" and the Leeds
office administrator specifies one that says "Leeds United", it is the latter
that will appear on the desktops of all users in the Leeds OU.
Just in case the enterprise administrator has defined a number of settings that are
critical and should not be altered (perhaps they are security related), he can prevent
these from being overridden lower down the tree by setting the "No Override" GPO
option on a particular policy. Because it is possible to create multiple policy objects at
any level, the critical settings could be contained in a Policy called
"Critical", on which the "No Override" option is set, whilst the
suggested settings can be left in the default policy at the same level. These can then be
overridden lower down if required.
Even this may not be necessary, however, since certain security settings, such as minimum
password length only apply at the domain level, even though you can apparently set it at
the OU level as well. Another safeguard is that it is impossible to delete the default
domain policy. This is important because the default domain policy contains security
settings that are applied to the domain by default. These fail-safes prevent lower-level
administrators from compromising security inadvertently.
Within a complicated structure, it is possible that for a particular OU lower down the
tree you do not want Group Policies from higher levels to be processed. If that is the
case, you can block inheritance for a particular OU, causing the child group policy not to
inherit settings from its parents. Obviously, this inheritance blocking can also be
prevented by using the "No Override" option.
Another powerful feature is the ability to link GPOs together. In organisations with
a number of different sites, domains and OU hierarchies, creating a single GPO that will
provide inheritance at all levels in the different structures would be impossible. Windows
2000 allows you to create a single corporate-wide GPO if required, and then link to this
from anywhere in the tree, even if there is no hierarchical relationship between the
OUs where the object is to be applied.
Finally, from the GPO Properties tab it is possible to assign permissions to a Policy. The
most interesting setting here provides the ability to permit or deny the application of
the Group Policy. Thus you could create two Groups of users (Groups still work under
Windows 2000, even though we have OUs as well) and two GPOs for a single OU.
Using the permit/deny Apply Group Policy permission you could apply one Policy to one
Group and another Policy to the other, without having to split them out into separate
Group Policies offer a huge amount of control for the administrator. However, with the
permutations possible with inheritance and permissions the situation can quickly become
very complex, and great care is needed in their implementation. What is required are good
auditing tools, allowing the administrator to see exactly what effect the application of
Policies has had, and the sooner they appear the better.
[an error occurred while processing this directive]