Windows NT 4.0 policies aren’t that bad. For all the policies’ abilities, their main purpose is to lock down desktops giving the users a restrictive desktop thereby lowering the Administrator’s workload by effectively ‘not letting the user get into any trouble’.
Before we explore the Windows 2000 changes, let’s first go over the differences between a profile and a policy.

Profiles

A profile is the collection of user environment settings such as colours, sounds, Start menu, Favourites etc. and is stored in the %systemroot%\profiles\%username% folder. These settings are user independent and may be modified by the user. It’s also possible for these profiles to be accessible from any computer by using roaming profiles in which case the profiles are copied to a server at logoff time and downloaded when you logon.

Group Policies

A Group Policy is a collection of user environment settings that are defined by the Administrator and are enforced on the user. It can include items that will restrict the items the user can configure such as Screen Savers, background etc. In Windows NT 4.0, policies can be applied to a specific user, computer or group and a default user and default computer policy can also be configured whose settings will take effect if no specific user or group policy setting applies. Windows 2000 takes the next step forward and allows the administrator to say how he wants to set the user’s system (including configuration and software) and he can rely on the software to configure and maintain that setting.

Policy Editor was the tool used to define Windows NT 4.0 based policies, however, in keeping with the new 2000 tool strategy it has been replaced with the Group Policy Editor Microsoft Management Console snap-in. This tool also encompasses some of the abilities of other NT 4.0 applications such as User Manager’s rights assignment. The old style policy editor used to produce a file – ntconfig.pol – for use by NT-based clients which was placed in the netlogon directory of domain controllers. Group Policy Objects (GPOs) are placed in the Active Directory, the foundation of Windows 2000. Group Policy Objects can be defined for Local computers, sites, domains and Organisation Units and they take effect in that order, LSDOU. Any item configured on the local computer will be overridden by anything defined by a site policy, anything defined on a site can be overridden by a domain policy and anything defined on a domain is overridden by an Organisational Unit policy. OUs can be nested and so the GPO on the OU closest to the object will have priority.

A site is a collection of computers that are grouped by their IP subnet and allow items such as replication to be controlled by a site’s physical location. A site can cross domains but this is not normally the case. An Organisational Unit is a collection of users or computers that have a common logical grouping such as business area. OUs are also used as an authority delegation mechanism and groups of users can be allowed to administer an OU while having no Administrative rights over the rest of the domain. Group Policies are inherited by child directory service containers and so GPOs for parent containers are applied to all child user and computer objects unless a GPO is specifically applied to a child OU container, in which case that GPO would take priority. The Group Policy editor can be launched on its own via the MMC console and a specific group policy edited, be it the local computer policy or a site, domain or OU policy, however this is not the normal method and requires unnecessary administrative effort.

Context menus, the menus displayed when right clicking on an object, play a major role in Windows 2000 and it is via these context menus that the Group Policy Editor snap-in can be launched automatically with the selected policy automatically loaded too.

Applying Group Policies for sites, domains and OUs

The three mechanisms to apply Group Policies for sites, domains and OUs are as follows:

Domain Group Policy Object
Start the ‘Active Directory Users and Computers’ MMC snap-in, right click on the domain and select Properties. Select the ‘Group Policy’ tab

OU Group Policy Object
Start the ‘Active Directory Users and Computers’ MMC snap-in, right click on the OU and select Properties. Select the ‘Group Policy’ tab

Sites Group Policy ObjectStart the ‘Active Directory Sites and Services’ MMC snap-in, expand the sites right click on the required site and select Properties. Select the ‘Group Policy’ tab

By default when you select Group Policy for a container there will be no GPO and you have the option of either adding an existing GPO to the container or creating a new one. To create a new GPO just click the New button and enter a name for the GPO. Once created, clicking the Edit button can modify the specified policy. A new instance of the Microsoft Management Console will be started with the Group Policy Editor loaded with the selected GPO at the root.

Once started you will notice two folders, Computer Configuration and User Configuration and these will effect HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER registry areas respectively. Not all registry settings are effected however, some Windows 2000 policies do not effect the registry as we will see. The two different areas take effect at different times. The Computer Settings of the GPOs take effect as the operating system initialises whereas user-related components of GPOs take effect when the user logs on. Expanding these roots reveals different areas of the policy which correspond to different elements of the environment.

The Software branch of the policy allows the central management of software distribution allowing you to install, assign, publish, update, repair and remove software for the objects in the container affected by the GPO. To support these actions, software applications will ship with a new installer format, the .MSI, which contains all information needed to both install and maintain the software.

Assigned and published applications

Assigned applications means an icon is added to users’ Start menus and the software is installed on the first attempted usage of the application. If the software has already been installed on the computer (by another user for instance) then only the user specific items will be updated, i.e. user specific registry entries. Published applications are those which are optional for the user and rather than the user having to request an Administrator to install the software for them, and can be added using the Add/Remove Software control panel applet and selecting the network as the source. This option will only be available to Active Directory aware clients, i.e. Windows 2000 professional or any that have an Active Directory bolt-on available.

Published applications have another use however. How many times have you had a file with an unknown extension and you have to find the application to view/execute it? With the Active Directory just double click on the file, your computer will query the Active Directory for the application needed to use the file, install the application and then open the file. Obviously this is only as good as the applications you publish in the Active Directory so ensure your published applications are kept up-to-date. Assigning an application to a computer means all users of the computer will have use of the application, assigning at the user level means only those users within the GPO will have access to it. The Folder Redirection extension allows the administrator to redirect elements of the users’ environment to alternate locations, such as pointing all users or groups of users Start Menus to an alternate location such as a network drive. Imagine if you modified the ‘My Documents’ area of all users to point to a server share of the format \\server\share\%username%. It would mean the user data would be available at all times even when roaming machines. Logon times would also be drastically reduced if using roaming profiles as, by default, ‘My Documents’ is part of the user’s profile which is copied back and forth to the roaming profile server, redirecting to outside the profile location will stop it being copied at every logon.

Using IntelliMirror, it’s possible for these network-based folders to be replicated to the local machines with no administration, meaning for users with portables, their documents will even be available when offline and when connected to the network. Again the areas will be synchronised to ensure no data is lost.

Security Settings extension applies mainly to the Computer Configuration and allows items such as account policies relating to password, lockout and Kerberos policies to be configured. Local Policies branch takes over the User Manager (Policies’ role in Windows NT 4.0) and allows assignment of user rights, the setting of the Audit policy and Security Options. Under the User Configuration Security area, IP security and Public Key policies can be configured.

Script options

Perhaps one of the most useful new abilities is the vastly improved Script options. We are all familiar with the configuring of a logon script via User Manager and many people have cried out for the ability to have a logoff script and expanded script support. Windows 2000 has it all and a little bit more. Scripts can be defined for Startup, Shutdown, Logon and Logoff and unlike the old basic command file structure, Windows 2000 scripts can be command files, javascript or vbscript allowing far greater flexibility in your scripts. If you choose to use javascript or vbscript make sure the clients support the Windows Scripting Host. It is likely that other software companies will provide ActiveX scripting engines for other languages and so expect to see the ability to run PERL, REXX and other script languages as part of the Windows Scripting Host.

One thing to bear in mind is that GPOs are cumulative and while normally a setting is on or off, with scripts, all defined scripts at all levels will execute. If you define a script, for example, for logon, at domain, site and OU then all three will run when the user logs on! This can be advantageous in some scenarios however you should bear this in mind when configuring scripts at multiple levels. The Administrative Templates will be the most familiar and represent the old Policy Editor functionality. Custom templates can be written using the old NT 4.0 .adm template format. Right click on ‘Administrative Templates’, select ‘Add/Remove Templates’ and you can add and remove any specific .adm files you want. In keeping with NT 4.0 policies, an entry can either be set as enabled, disabled or not set. If an entry is not set then it allows other policies lower down the priorities to take effect.

Policy Editor used to generate a file that was saved to netlogon and then replicated to other domain controllers using directory replication. In Windows 2000 you make a change and it is saved to the Active Directory automatically. For effect, however, it needs to be propagated throughout the domain. This can take some time and it is possible to force propagation using the secedit.exe tool. For example, typing: C:\> secedit /refreshpolicy machine_policy would force the machine policy to be propagated. While we talk about Group Policy Objects for a site, domain or OU there is just the one type that can be assigned to any of the containers, and once you create a GPO for any container it can then be applied to any other. GPOs belong to a domain but can be applied to containers outside the domain. However it would not be recommended due to performance reasons and if a domain was removed or relocated in the domain forest, GPO would be lost. GPOs are objects and so exceptions to their application can be configured by simply modifying the ACL to specific users or groups of users. This will also allow you to limit which GPOs are applied to users and computers.

There is currently no tool to enable an Administrator to view the ‘Resultant set of policy’ or RSoP however both Microsoft and other software companies are working on these tools and should be available in the Windows 2000 release time frame. These RSoP tools will allow you to view which GPOs are being applied to selected objects. The flexibility of the Group Policy Objects is very useful in Windows 2000, however this flexibility may give you enough rope to hang yourself and so its very important to plan carefully as each GPO has to be applied at system startup/logon etc. Too many GPOs applying to any one system could badly affect startup times.

Consider the following:

• Limit users who can update Group Policy Objects as each update requires a large amount of replication.
• Limit the use of blocking inheritance which stops policies being inherited from higher SDOUs
• Don’t use policy enforcing which forces a policy to be used which would normally overwritten by policies in child OUs
• Cross domain GPOs due to performance reasons