One method of managing and locking down server and workstation configurations under NT 4.0 was by using System Policies.

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 (*.adm) files.

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.

Group Policies

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

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 OU’s, and finally to the lowest child OU’s. At any level, multiple GPO’s 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. Don’t 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 user.

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 Computer Configuration:

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 user’s 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 GPO’s 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 OU’s where the object is to be applied.

Assigning permissions

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 OU’s as well) and two GPO’s 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 OU’s.

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]