Controlling the User

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Ashley J. Meggitt and Timothy D. Ritchey

Chapter 7 from Windows NT User Administration, published by O'Reilly & Associates, Inc.

Controlling users is perhaps the one thought that continually pushes its way to the forefront of an already overworked systems administrator's mind. Certainly in an environment similar to ours, where students, by their nature an inquisitive body, often pursue an unhealthy interest in the forbidden, controlling them is paramount. Machines left open, that is, without appropriate restrictions in place, soon become dysfunctional, and this generally leads to two situations: A student finds himself or herself up in front of the authorities for computer misuse, or a number of students suffer the annoyance of having a machine down over the weekend, just when the all-important essay is due, or both. Neither is acceptable.

Control should not only be considered a way to prevent misuse, it should also be considered a tool for creating both a suitable and safe working environment. For instance, users with limited computer goals can often feel intimidated by the sheer variety of options a modern system offers them. One way to allay such fears is to simplify the environment, hiding the complexity of the system behind a well- managed interface.

How does the systems administrator go about creating the appropriate environment for his or her users? NT offers us two methods, the System Policy Editor (SPE) and the User Profile. The SPE gives both direct control of the user, through the management of the user's hive, and indirect control, through the manipulation of the operating system and application software settings. The user profile offers the administrator a way to create a controlled environment, add to it dynamically, and even lock it down so that no changes can be implemented by a user. The combination of these two methods gives the administrator a heady concoction of environment restriction and fine tuning.

The System Policy Editor

The primary function of the SPE is to combine individual policies to produce a single strategy with the aim of restricting the actions of both users and machines alike. These policies are in essence a collection of Registry keys and values that are imposed on the Registry of a target machine when a user logs on. The SPE aims to supply a workable interface, an abstraction of the Registry, that allows for easy manipulation of given components of the Registry. These components are defined in files referred to as template files. NT supplies two sets of template files that cover what Microsoft considers the most appropriate Registry keys and values that an administrator would need to control. These template files are named winnt.adm and common.adm, and they can be found in the directory %systemroot%\winnt\inf. The .adm extension associates this file type with the SPE.

Note: To apply a policy, the component, such as the shell or specific application, has the responsibility of checking the Registry and acting on the information it finds. This means you can impose a policy on a component only if the component knows that it should be checking for one.

A Closer Look at a Policy

An individual policy can be regarded as an invitation to constrain an item, action, or object. All policies have the option of being enabled or disabled, and they can contain, depending on the type of policy, a number of associated settings. These settings are referred to as parts, and a policy can contain many such parts of varying data types, typically Boolean, numeric, or string values. For instance, there is a policy supplied by NT that allows the administrator to force display restrictions. This policy, called Restrict display, has a number of parts associated with it. All these parts are Boolean values and are represented by check boxes. Each part enables or disables options available to the user with regard to display settings. One such part hides the screen saver tab, thus stopping the user from changing whatever the current setting happens to be. How you actually achieve this through the SPE is covered later in this chapter. Similar policies are grouped together to form Categories. Categories can contain either policies or other categories. Continuing with the discussion of the display settings, Figure 7-1 shows the hierarchy of a section of a system policy. This has a category called Control Panel that contains a subcategory called Display that contains a policy called Restrict display that contains five Boolean parts.

Figure 7-1: Components of the machine-specific policy

Individual categories are grouped together to form either a user- or machine-specific strategy. User-specific strategies act directly on the Registry key HKEY_CURRENT_USER; machine-specific strategies act on HKEY_LOCAL_MACHINE. To all intents and purposes then, the SPE is a Registry editor, albeit an indirect one. To illustrate this, let's look at the connection between the single policy selected in Figure 7-1 and the Registry settings of a participating user.

The policy selected through the SPE is Restrict display, and out of the five parts available, the part Hide Screen Saver tab has been enabled. What happens in the Registry? In this case, NT adds a new key and associated value to the Registry, one that it knows to look for when executing the policy. The added value is located under the new key System in the following section of the Registry:

HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \System

The new value name is NoDispScrSavPage with a value of 0x1 of type REG_DWORD. There are two states to this Registry value. Either it is set to a value 0x1, in which case the tab element of the display property is not shown, or it is set to a value of 0x0, in which case the tab element is shown.

Note: Any policy put in place will continue to be effective until it is specifically revoked. Simply removing the system policy from the Primary Domain Controller has no effect as the local Registries have already been amended. You must explicitly change the system policy to undo the restrictions.

The above example demonstrates the control available to you through predefined policies. Being able to use these policies relies on the programmers' having supplied either a policy template file (.adm) or the details of the policies known by the software. Another way to use the SPE is to create your own template files that affect known Registry elements.

Later in this chapter we explain how to create your own template file.

Creating a System Policy

Having launched the SPE (from Start-->Programs-->Administrative Tools (Common) ), you must first open a new policy, FileNew--> Policy. This places two icons in the SPE window, named Default Computer and Default User.

Default Computer

This icon represents the machine-specific settings that can be used to control any machine that has not had a specific policy associated with it. When a system policy is invoked, the workstation first looks to see if a computer policy is associated with the name of the workstation itself. If not, it looks for the default policy. If one does not exist, then the machine-related part of the workstation's Registry is left untouched.

Default User

As with the default computer policies, if a user policy has been neither specifically created nor associated with a group policy, then the default user controls are evoked.

The administrator must first decide what criteria to apply to split the users and machines into appropriate control units. Machine restriction can be configured only through the default machine or specially created individual machine policies. Users, on the other hand, can be controlled through the default user, specific individual users, and groups. Doing this does beg the question of which control unit-the default, individual, or group-takes priority. The following list shows the order:

A specific user policy takes precedence over any group policy that applies to that user.
Any group policy that applies to a user takes precedence over the default user policy.
A specific user policy takes precedent over the default user policy.
If many group policies apply to a user, then the group that appears highest in the group priority list takes precedent. The group priority list is maintained through the main menu item Option-->Group Priority.

Adding a new user, group, or machine is done through the menu option Edit, followed by the appropriate menu item. Having made your selection and named it accordingly, you open it by double-clicking on it. You are now presented with a series of categories that contain either other categories or actual policies. The interface is the usual Explorer type. If you open a user policy and navigate down through the option Control Panel, you are presented with the same details as shown in Figure. From looking at Figure 7-1, you can see there is only the single policy, Restrict display, that, if you highlight its name but do not select the check box, shows you the five parts associated with it. The check box alongside the policy name supports three states; these are as follows:

A ticked check box indicates that the policy is enabled.
An empty check box indicates that the policy is disabled.
A greyed-out check box indicates that the policy should be left in its current state.

This last state is an interesting one. All policies are initially in this state, allowing the settings of HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE to remain set to their defaults until a change is required. If you did not have this neutral state, then all Registry settings would have a policy forced on them even if one was not required or desired. You should be very careful here; do not go about clicking policies without having first considered the consequences. For instance, changing any policy that is not of a simple Boolean type without first noticing its original settings may well leave your workstation in an unusable state.

Having added and configured new machines, groups, and users, you must save the settings into a system policy file. These files use the extension .POL and can be stored just like any other file. For a system policy to take effect, you must store the policy you wish to use in the NETLOGON share of the PDC. This is actually the %systemroot%\system32\repl\import\scripts directory. The policy file must also be called NTCONFIG.POL.

Adding Templates

If you want to use template files either of your own design or supplied by a third party, you need first to load them in the SPE. Doing this is quite straightforward. From the main menu select Options-->Policy Template; you will see which template files are currently in use. You can now include a new template through the Add option. Having done this, you will see new policies appear under any subsequent computer- or user-specific sections of the system policy.

Registry Editing

The SPE also gives the administrator the ability to directly view or edit a subset of both a machine's and a user's Registry entries. Selecting File-->Open Registry displays these details through the same interface SPE uses to allow policy control. Obviously, by doing this you see only the settings that the SPE knows about from the template files. By highlighting the various individual policies you can determine the current settings for the local machine and the currently logged-on user. The SPE also allows the administrator to look at the Registry of any machine in the domain providing an active user is logged on. To do this, select File-->Connect and enter the name of the machine you wish to investigate. For some annoying reason, there is no browse capability here. This Registry editing feature gives the administrator the chance to view the current setting of a machine's Registry before a system policy is deployed. Its usefulness lies in the fact that you can document the details of any Registry entries your system policy intends to change. Although reinstating any changes to Boolean values is not a problem, reinstating string variables is troublesome as the variable could have contained any text. If you did not make a note of it, you may find it impossible to find its original form. No changes you make to a Registry have any effect until you explicitly save them.

Downloading the Policy

Having created a system policy, the administrator must consider in which way he or she wishes the policy to be distributed, if at all, to the workstations and member servers of the domain in question. The option that dictates the type of download is itself found in the set of computer-related sections (such as the default computer) of the system policy. The download policy for the default computer is found under Network\System\policies\update.

Three states can be set for downloading policies:

Off (No Policy)

If the download option is set to Off, then all local user and computer Registry settings are left untouched.

Automatic

Policies are automatically downloaded from the NETLOGON share of the PDC. This is the default option for newly created system policies.

Manual

Policies are downloaded from a specific path that specifies both the pathname and the policy file. The specified path can take the form of either a UNC path or a mapped path.

Deploying system policies through the manual download option needs a bit more explanation because what happens to the Registry during the manual setup is not immediately obvious.

Remember that we are dealing with Registry settings and as such must consider the way in which NT loads and observes these settings. Let's look at the order in which settings are loaded from the system policy and when those loaded changes come into effect. When a user logs on to a domain workstation, the following occurs:

The computer-specific settings within the system policy are loaded into the Registry of the local machine. These settings have no effect on the machine until a new logon has occurred. Why? Because the hardware part of the logon process has occurred before the computer-specific settings from the system policy have been loaded. It takes a new logon to activate them.
The user-specific settings from the system policy are merged with the settings from the Ntuser.dat file of the user logging on. These settings take immediate effect as they are loaded into the Registry before any user-specific actions occur and are therefore considered the current settings.

Bearing this in mind, we now look at an example. Suppose we have 10 machines we wish to use as library terminals and we want them all to share the same system policy. Also assume that we have other machines on the network dedicated to other purposes, so we need to make the destination clear. The following actions need to take place.

First, we need to create the policy that the 10 library workstations will use. We do this by using the SPE to edit the default computer setting that will enforce our restrictions. We save this policy to a directory that has sharing enabled, in this case LibData, and we call the policy file LibWorkStations.POL. It is worth stating here exactly what we have set in the policy. First we should mention that the library machines are set to automatically log on a user called LibUser. This user's profile is mandatory with all profile directories except the Start Menu\programs directory, which keeps shortcuts to two applications to which we want the users to have access. These applications are a library program and Internet Explorer. The computer-related part of the library workstations policy, default computer, consists only of the enabling of the logon banner with customized text. This is done under Windows NT System\Logon\Logon banner. The text threatens the usual prosecution, fining, and death if users abuse the machine. The user-related part of the policy, default user, is more interesting. You could impose dozens of individual policies on a user, but the following lists the ones we chose for this example:

Control Panel\Display\Restrict Display

All the associated parts of this policy are selected. This disables the user's ability to use any display property tabs, as well as the control panel application Display, to change any display properties.

Shell\Restrictions\Remove Run command from Start menu

This removes the Run command from the Start menu, thus stopping users from attempting to run unauthorized applications from the command line.

Shell\Restrictions\Remove folders from Settings on Start menu

Again, as it says, this removes the control panel and printer folders from the Settings option on the Start menu. It stops users from trying to run control panel applications or fiddle with printer settings.

Shell\Restrictions\Remove taskbar from Settings on Start menu

Imposing this policy removes the last item from the Settings option on the Start menu. This stops users from fiddling with the taskbar properties.

Shell\Restrictions\Remove Find command from Start menu

This policy removes the Find command from the Start menu. There is no need for users of the library terminals to root around the system looking for files, either data or applications. Removing Find from the start menu avoids any temptations.

Shell\Restrictions\Hide all items on desktop

For this example, this policy is a killer. It removes all desktop settings including Network Neighborhood, My Computer, and the Recycle Bin. The desktop is barren.

System\Restrictions\Run only allowed Windows application

This is the final policy implemented, and it stops all applications from being run except those registered in "List of allowable applications." The only two applications listed are the library application and Internet Explorer. This supplies ultimate control of the workstation, with the other policies simply used to tidy up the taskbar and desktop.

The next step is to edit the default system policy. We add entries for each of the 10 library workstations and make Remote update the only active setting (under Network\System policies\update). We now change the part Update mode to Manual and supply a pathname in the appropriate field. We must also include the name of the new policy we intend to use, in this case LibWorkStations.POL. As we have saved the new policy file in the share LibData, we use a UNC path; the path looks like the following:

\\iago\LibData\LibWorkStations.pol

We now save the default system policy, and we are ready to go. There is, however, a small problem. Three logons have to take place before we see the effect of the new policy. Why? Remember the order in which settings are loaded and used. In this case, it takes the first logon to load the policy settings that point to the new policy file LibWorkStations.POL. The second logon uses the Registry settings established from the first logon to find the new policy and load it. Finally, the third logon uses the settings established from the second logon to implement the new policy.

User Profiles

A user profile is a collection of user-specific settings that define the user's working environment. These settings include such items as the wallpaper, screen resolution, color schemes, application settings, and network connections. Every time a user logs onto an NT machine or domain, the profile for the user is deployed. When users log on to a domain account, they are supplied with server-based profiles called roaming profiles. These profiles appear to follow them from domain machine to domain machine, giving them a consistent personal working environment made up of three specific areas: Registry details, directories containing user-specific links and files, and directories containing links and files specific to a workstation or server.

Registry Details

Every user has a separate hive file that contains settings loaded into the Registry when he or she logs on. This file is called ntuser.dat and is located in the user's profile directory. Refer to Chapter 6, NT Internals and Managing Users, to remind yourself of the contents of the ntuser.dat hive.

User Profile Directories

Profile directories are stored at the location defined by the profile path setting supplied for each user through the User Manager or User Manager for Domains, depending on the profile type. The default location for profiles is %systemroot%\profiles. You can expect to see two default directories:

profiles\Application Data

Repository for specialist settings required by NT applications. It is up to the individual applications to make use of this directory.

profiles\Desktop

Any extra items that sit on the desktop that are not supplied by NT as default. For instance, My Briefcase and the user's own shortcuts appear here.

All of the following hold shortcuts to related items or files, or both:

profiles\Favorites

Favorite locations used, for instance, by Internet Explorer.

profiles\NetHood

Network Neighborhood items.

profiles\Personal

Program items. Word uses this as a default location for document storage.

profiles\PrintHood

Printer-related items.

profiles\Recent

Most recently worked-on documents.

profiles\SendTo

Items that files can be sent to, such as disk drives, notepad, or paint.

profiles\StartMenu

Items that form the Start menu, such as programs.

profiles\Templates

Template files. Again, applications such as Word make use of this folder to store user-defined templates.

Note: the directories of a profile are downloaded from the machine specified to hold the profiles (usually a server of one sort or another) to a workstation when a domain user logs into a domain. As these directories can be used to store data files as well as shortcuts, it is quite possible that they can grow to such a size as to start affecting the logon and logoff times. For instance, Word 97 uses the profiles\Personal directory as the default location to store its documents. Over a period of time, a user stores Word documents, and the size of this directory increases. Eventually, depending on your type of network, the directory reaches such a size that it starts to affect the time taken to both log on and log off (the profile is copied back to a central location on logoff). Not only this, but if profile caching is on, then large amounts of local disk space get wasted. Keep this in mind when setting up applications, especially Word. You may want to change the location of file storage for the application if it defaults to a profile directory.

Each new profile is created from a copy of a default profile directory called Default user, which is also located in the %systemroot%\profiles directory. This is also where the template for each NTuser.dat hive is stored.

The Machine-Specific Directories

Every NT workstation and server contain a directory called the All Users directory. This directory is used to store items common to all users on the local machine. These items are represented as either desktop items or Start menu items. To reflect this, the All Users directory contains two subdirectories called Start Menu and Desktop. The Start Menu directory's purpose is to add machine-specific items to the Start menu, which by default contains a common program directory containing links to the administrative tools. The Desktop directory's role is to contain links and files for those items making up the desktop. The path for the All Users directory is once again %systemroot%\profiles.

To make things a bit clearer, let's look at an example. If, as an administrator, you create a shortcut, say to the floppy drive, and wish all successive users to see this icon on the desktop, then you need to put the shortcut into the All Users\Desktop directory. The icon will appear on the desktop for all users. If you do not put the icon in the All Users\Desktop directory, but place it straight onto the actual desktop, then only you as the administrator will ever see the icon. When you log out, the shortcut is saved to the administrator's personal desktop folder and thus cannot be loaded to the desktop by any other user.

Local and Roaming Profiles

Local profiles are profiles that are stored locally on a workstation. These profiles are used in two differing contexts: The profile is associated with a local user account, or the profile is a cached copy of a domain user profile. The first case is straightforward: A user account created locally on a workstation or server has a profile associated with it. This profile is accessible only from the workstation or server on which it was created. The second case is slightly more complex. When a user logs onto a domain with a server-based profile, termed a roaming profile, the profile is copied to the workstation or server from which the user is logging on. This copy is then used. If a user logs onto a domain and, for one reason or another, the roaming profile is unreachable, then the locally cached copy of that user's profile is used instead. If, when the user next logs on to the domain, the roaming profile becomes available, NT compares the roaming profile with the locally cached copy and, depending on which is the most recent, either uses the roaming profile or gives the user the choice of using the cached local profile. Let's look at an example.

We have configured our system to allow cached copies of the roaming profile to be stored on a workstation, and our maintenance boys have just cut through the UTP cable that connects the workstation to a hub and thus the domain. A user now logs on, and the workstation tries to grab the user's profile from the PDC. As the PDC cannot be contacted, the workstation uses the locally cached copy of the user's profile. Our workstations have Word 97 installed locally, so our user does some work and then logs off. In the meantime, the network team fixes the cut cable, and the workstation is back in contact with the PDC. Our user returns to the workstation and logs back on. NT automatically compares the cached version of the user's profile with the copy stored on the PDC and realizes that the cached version is now the most recent. It asks our user if he or she wants to use the newer cached version or download the older server version. Our user opts to use the new cached version. If our user had opted to use the older version of the profile, then any changes he or she had made to the desktop, any work stored in the profile directories during the disconnection, would have been lost, overwritten by the older profile. It is worth taking the time to explain to users the consequences of selecting one or other of the different versions of the profiles under such circumstances.

As stated in the first paragraph of this section, roaming profiles are server-based and are used to generate a consistent user environment regardless of the domain workstation or server from which a user logs on. The profile follows the user around the domain and provides a useful way in which an administrator can manage some aspects of the user's environment. One restrictive form of the roaming profile is the mandatory profile, a roaming profile that users cannot alter. To create a mandatory profile, you simply need to rename a user's ntuser.dat file to ntuser.man. The user can still make changes to whatever settings for which he or she has permissions, but these changes are not saved centrally so that each time a user logs back on he or she sees the enforced profile. In reality, NT just does not copy back the roaming profile that it has downloaded to the workstation when a user has logged on. It uses the .man extension as a simple flag to enforce the mandatory setting.

As roaming profiles are server-based, it is quite possible to use this centralization for information or application distribution. We have done this ourselves several times in a simple fashion. For instance, we run an administration PDC that handles, among other services, our administrative database. On creation of a new student database, we distribute a new shortcut to all secretarial and administrative personnel that need access to it. We do this by adding the new shortcut to the Start menu\programs directory of their profiles. On the next logon, they see the new link to the database. The following short Perl script demonstrates how simple it is to do this.

The syntax for calling the additem.pl script is as follows :

additem [/v] [/q] filename item_name profile_directory

where /v puts it in verbose mode, /q puts it in quiet mode, filename is a text file of selected usernames, item_name is the item to copy, and profile_directory is the destination user profile directory.

A typical call to this script is as follows:

E:\>additem.pl /v userlist.txt c:\tmp\student.lnk "\Start menu\programs"

where additem.pl is the Perl script, userlist.txt is a text file containing a list of target usernames, student.lnk is the shortcut to the database, and Start menu\programs is the destination profile directory for the shortcut.

Example 7-1 Adding an Item to a Profile Directory

#additem.pl
#The script takes a list of users, finds their profile path and adds
#an item, such as a link, to a destination profile directory.
# Grab the user's profile path
sub GetProfileHome {
     my $username = shift @_;
     my $directories = 0;
     map /\w*\s\w*\s*(\S*)/, grep {
     if (/^Logon script/) {
            $directories = 1;
            0;
        } else {
            $directories = 0 if /^Home directory/;
            $directories;
        }
    } qx(net user $username);
}
#Get the flags, filename, item to copy and profile directory 
#from the command line
$filename = shift @ARGV;
$not_quiet = 1;
if($filename eq "/v") {
    $verbose = 1;
    $filename = shift @ARGV;
} elsif ($filename eq "/q") {
    $not_quiet = 0;
    $filename = shift @ARGV;
}
#Get the item path and the profile destination folder
$itempath = shift @ARGV;
$pfolder = shift @ARGV;
# Open the file containing the usernames and load them into an array
open(USERLIST, $filename) || die "unable to load $filename\n";
print "Retrieving usernames from $filename...\n" if $not_quiet;
while ($username = <USERLIST>) {
    chop($username);
    @users = (@users,$username);  
    print "$username\n" if $verbose;
}
# For each user in the array we call the GetProfileHome function to  
# extract their profile path. To this we add the item path and then carry
# out the copy.
ADDITEM: foreach $username(@users) {
print "Adding $itempath to the $pfolder of $username\n" if $verbose;
     foreach $path(GetProfileHome($username)) {
               $destination= "\"".$path.$pfolder."\"";
           qx(copy $itempath $destination);
               print "Item copied to - $destination\n\n" if $verbose;
          }
}

Creating a Profile

A user profile is created in one of two ways. It is either automatically copied from a default profile, or it is manually copied from a template profile.

Default Profile

The steps of automatic creation are as follows:

A new user logs on to a workstation with a domain account with no pre-configured roaming profile.
The local workstation's default user profile, Default User, is loaded.
The user logs out, and the profile details are copied to a predefined server location (as specified by the profile path associated with each user).

Note here that the roaming profile is actually based on the configuration of a workstation's default user profile, not the default profile stored on the authentication server. This can lead to problems if each workstation has a differently configured default user profile. Which profile is assigned to a user then depends on which workstation he or she happens to log onto first. There is a way to enforce a uniform default user profile across all the workstations of a given domain. To do this, you first create the new profile with which you intend all your users to start, then copy it to the NETLOGON directory of the PDC in a directory labeled Default User. Make sure Everyone has permission to use this directory. You can copy the newly created profile using the User Profile tab from the control panel application, System. Now when a new user logs on to the domain for the first time, the workstation downloads a copy of the Default User directory from the PDC and makes a new directory called Default User (Network). It then uses this default user profile for the new user. When creating a network default profile, consider from where you intend to create it. Our workstations have quite different video capabilities than our servers, so we created our network default user profile on one of the workstations. This gave us more flexibility in the screen configuration than would have been possible by using the server profiles available.

Templates

An administrator can also create a number of template users with Registry details and program links that are preset to match a number of user types. A newly created user who fits into one of these predefined categories can have the correct template profile copied into his or her new profile directory. This is done manually by the administrator through the control panel application, System. System has a tab named User Profiles that allows an administrator to select an existing profile, in this case a template profile, and copy it to the profile location set up through User Manager or User Manager for Domains. Only one user profile can be created at a time using this method, but it is quite acceptable if you have low user turnover.

The Template File Format

Customizing the System Policy Editor (SPE) as a general-purpose Registry tool has many benefits. It allows the system administrator to control Registry settings for users and machines in a consistent and central manner. This customization depends on template files that define the customization options, interface, and actions taken when loaded into the SPE. Because policies must be enforced by the programs to which they refer (e.g., the Explorer shell), Microsoft intends that policy template files be created by developers of software packages to centralize control of Registry settings for new applications. This means that information about the format of template files is hidden away in Microsoft's Win32 Software Development Kit.

As mentioned earlier, you do not need to depend on Microsoft or any developer to provide a template file for you. If you understand how the Registry works, and how specific programs use the Registry, you can use template files and the SPE to make your own changes. The advantages to using the SPE and template files for altering the Registry are in the centralization and distribution of profile settings. By enacting system and user policies at logon time, changes can be distributed throughout a network environment without the need for an administrator to update each local machine or current user hive manually. Instead, the system automatically propagates change details in a central profile file. In addition, the template policy file and SPE program provide a simple user interface for interacting with complex and sometimes obscure Registry entries.

Profile template files (.adm) have a hierarchical structure that is used by the SPE to generate the tree list used to navigate the policy options. The template file is broken down into individual sections called classes that specify the root key within which the Registry changes are to be carried out. The categories and policies are typically grouped into either a user-specific or machine-specific section. A class statement marks each of these sections:

class [ machine | user ]

If machine is specified, then all Registry key references are in relation to the HKEY_LOCAL_MACHINE root. If user is specified, then all references are based on the HKEY_CURRENT_USER root. These root key differences are reflected in the icon to which the category and policies are added. If no class is specified, and if no other type information is provided in later category definitions, the default placement for all policies is within the HKEY_LOCAL_MACHINE key. There is traditionally only one class machine and class user declaration per file, with policies grouped under the appropriate heading.

Once the class of policy change is determined, you can begin to create the tree structure that the SPE presents to the user. This is done with the category command:

category name [keyname key]
...
end category

Note: If you have access to the Win32 documentation, you will find that it states that the category keyword requires the use of a type modifier to indicate which root key the entries in the category applies. This, in fact, is not readable by the Windows NT System Policy Editor, which will throw an error if it is used. Instead, use the class statement as specified earlier to designate whether the following categories apply to user or machine.

Each category entry in the .adm file creates a corresponding node in the SPE tree. The name value holds the display name for the category, which is presented to the user at each node. If the name field includes spaces, you must place it inside double quotes. The keyname option is used to indicate a Registry key that all policies contained within the category should use unless specified otherwise. This saves your placing the same Registry key name with every policy entry.

Category entries can be nested to create an overall hierarchy that is mimicked by the tree structure in the SPE. As an extended example of how a custom template file might be organized, consider the following code:

class machine
category "Computing Centre Machine Restrictions"
    category "Internet Terminal Policies"
        ...
    end category
    category "Library Terminal Policies"
        ...
    end category
end category
class user
category "Computing Centre User Restrictions"
   ...
end category

In this case, there are different custom policies we wish to implement for different types of machines. To organize the policies themselves, we have broken them down into machine- and user-specific policies, with the machine-specific policies being further broken down into different terminal-type policies. Remember, this organization does not mean that Internet terminal policies could not be enforced on library terminals; it is simply a way to organize the custom policies for easy browsing. You could use your own organization, perhaps based on machine model, for example. Remember, the categories are used for organizing your policies for ease in finding.

Of course, categories are used to organize only the policies you wish to implement. To add policies, you use the policy statement:

policy name [key registry key]
...
end policy

The policy declaration works much like the category keyword in that it demarcates the beginning and end of a specific policy. Creating a policy entry in the template file causes the SPE to generate a leaf in its tree view of the policy option list. This leaf is a check box with three states: selected, cleared, or greyed-out. The optional key declaration is used to indicate which Registry key the policy is to act on if no key has been declared before, for example, in a category declaration. Note that if you have not declared a target key before the policy statement, the key declaration is required. Child parts of the policy will adopt the most recent key declaration or may specify their own. The user interface elements that are displayed in the SPE appear in the lower window. The items appear unfocused if the specific policy to which the parts are associated is not currently selected. The order in which the parts appear is identical to the order in which they are declared in the template file.

Parts allow for specific actions to be carried out in regard to the Registry. Registry changes can involve everything from setting flags to defining strings or numbers; parts, in addition to simply allowing multiple actions to be carried out, allow further user input into the process. To define a part, use the part declaration:

part name type
    ...
    [keyname key_name]
    valuename value_name
end part

The name parameter indicates what string the SPE should use to display with the policy part. The type parameter indicates what kind of part should be created. There are several options for part types, which will be discussed in turn: checkbox, combobox, dropdownlist, edittext, listbox, numeric, text. Depending on what type is declared, each part declaration has a type-dependent section. For example, if the type is text, there is no type-dependent data. On the other hand, if the type is edittext, then there are several parameters indicating the default value and length, which the edittext field created in the SPE will be able to use. These are described in the next section. After the name and type parameters are given, depending on what kind of part is declared, there may be type-specific data that must be provided.

In addition to and after the type-specific data, a part declaration includes an optional keyname and required valuename parameter. The keyname option is used to indicate on which Registry key the profile part is acting. This key name is required only if there is no key definition in a higher portion of the policy file hierarchy. If any more global key name declarations have been made, the local part declaration overrides this setting with the value of key_name. The value_name parameter is used to indicate on which Registry value the profile part is to act. This will be used by the type-specific parameters in customizing the setting of value_name in the Registry. As with the rest of the template file format, the part declaration is closed with an end part statement.

Part Types

Each part declaration must include with it information about the kind of customization interface the SPE should provide for the user. These interfaces are used to change the Registry settings of the key/value pair defined at that point in the hierarchy.

The simplest example of a part type is text. This takes no additional type-specific data and simply displays the name value as a line of static text. In this case, the valuename option is omitted from the part declaration altogether because it does not make sense in this context. The following is an example of a text policy part:

part "This is a test string" text
end part

If you have several parts to a policy that a user will need to set, you can use text to separate and label them into individual groups. Or, you might wish to provide more detailed explanatory text to the policy in general. You will need to create a new text policy part for each line of text in a multilined statement that would otherwise run wider than the available space as a single line.

For Boolean settings, you can use the checkbox type. This type presents a standard check box, which can be either selected or unselected. Unlike the standard policy check boxes, the part type checkbox does not have a third (or greyed-out) state.

The checkbox has five type-dependent data fields that can be provided in the template file to instruct the SPE how to alter the Registry according to the state of the check box.

The valueon and valueoff options are used to indicate what setting the Registry value should take when the checkbox is selected or deselected, respectively. If this value is not specified, then the default of 1 is used for a selected state, and 0 for an unselected state. These data fields can take both string and numeric values. When using numbers, you must specify the value as being numeric.

valueon "\\iago\users"
valueon numeric 256
valueoff ""
valueoff numeric 1024

In addition to individual values, you can also specify more complex actions to be carried out, depending on the state of the check box. These instructions are collected into elements known as actionlists, which are discussed in more detail later. You can specify these instructions by using the actionliston and actionlistoff commands. For example, the following example creates a check box with an action list:

part "This is an additional part" checkbox
    actionliston
        keyname system\currentcontrolset\services\...
        valuename foo
        value "\\iago\users"
        valuename bar
        value numeric 13
    end actionliston
    actionlistoff
        keyname system\currentcontrolset\services\...
        valuename foo
        value ""
        valuename bar
        value numeric 9
    end actionlistoff
    valuename testing
end part

Note that the checkbox part must still specify a default value_name at the end of the definition even though the values are explicitly defined in the action lists. The keyname option is necessary only if the key you wish to use is different from the key defined previously in the hierarchy. This can also be changed for each element in the action list.

If you want the checkbox to be selected by default, use the defchecked option:

part "This is an additional part" checkbox
    defchecked
    actionliston
    ...

Beyond simple check boxes, you can also allow the user to type in specific information by implementing edit boxes, drop-down lists, and combo boxes.

The edittext part allows you to create a field where the user can fill in a text string for the Registry value. You can specify a default string using the default option. In addition, you can set a maximum length for the string using the maxlen option. If you want to force the user to enter a value in order for the policy to be used, use the required command. Finally, if the Registry key requires text in OEM format, you can use the oemconvert option. The following is an example of an edittext entry:

part "This is a test part" edittext
    default "test"
    maxlen 20
    required
    valuename test
end part

If you want to provide more than one default option for the edittext, you can use a combobox instead. The combobox uses the same options as the edittext with the additional suggestions command:

part "This is a test part" combobox
    default "test"
    maxlen 20
    required
    suggestions
        option "second option" third
    end suggestions
    valuename test
end part

Notice the use of quotes to separate out strings with spaces.

If you want to provide numeric options, there is a numeric part, which works in a similar manner to the edittext or combobox. The default option is used to indicate the initial numeric value for the field. max is used to indicate the maximum value the number can be (defaults to 9999). The required option is used in the same manner as that of the edittext and comboboxes-that of ensuring the user fills out this option for the policy to be enabled. By default, the part creates a spinner, which allows the user to move through the numbers one at a time. This is set using the spin command. The numeric value associated with this option is used as the increment value for the spin buttons. If it is set to 0, the spin buttons are not displayed. By default, the spinner control is set to 1. If you wish the number to be stored in the Registry value as a REG_SZ type instead of REG_DWORD, use the txtconvert option.

part "This is a test part" numeric
    default 20
    max 100
    required
    spin 2
    valuename test
end part

Two of the more complicated policy parts are the dropdownlist and listbox types. These two can be used to make a wider variety of predefined changes, which appear in selection lists.

The listbox part is used to control set values, which can be entered for a single key. Adding a listbox part to a policy file places a button in the SPE called show that opens up a dialog box with an add and remove button. Pressing the add button allows the user to add valuename/value pairs to the Registry key. The remove button can be used to remove any already installed values. By default, the values in the list box replace any and all entries underneath the Registry key to which you are pointing. This means that if there are already values underneath a key, they will be deleted before the new values are entered. Using the additive option allows the preexisting values to remain, with entries in the listbox only being appended to the key. To have the user specify both the value name and setting, you must use the explicitvalue option. If you want to use a running list of value names and only have the user supply the value settings, you can use the valueprefix option. This causes each new entry in the listbox to be the setting of a value with the name of the prefix with an incremented integer added. For example, if the prefix were user, then adding the entries ajm39, tdr20, and rjh39 would result in the Registry values user1, user2, and user3 to be added with the previous respective usernames. An example listbox part might be:

part "Test part" listbox
    additive
    explicitvalue
end part

Notice that it is up to the user to provide all the information in this part. Additionally, because the user is specifying the value or the values are being provided automatically using the valueprefix option, there is no need to provide a valuename option.

By far the most complex of the policy parts is the dropdownlist. This allows the user to select from a predefined list of items that can have either different values or action lists associated with them. Unlike the listbox, the dropdownlist by default deals only with a single Registry value, although action lists allow you to expand this to several values at once.

The following example shows the use of the dropdownlist with three entries. The first entry simply sets the value of valuename1 to value1. The second item changes the value of valuename1 to a numeric value, in addition to setting the value valuename2 to the setting of value3. The final item deletes the value valuename1 from the Registry entirely.

part "This is a test part" dropdownlist
    itemlist
        name item1 value value1
        name item2 value numeric 2
        actionlist
            valuename valuename2
            value value3
        end actionlist
        name item3 value delete
    end itemlist
    valuename valuename1
end part

In several policy parts, notice the use of constructs known as action lists. The format for these lists is as follows:

actionlist
    [keyname key_name]
    valuename value_name
    value value
    [keyname key_name]
    valuename value_name
    value value
end actionlist

The keyname option is used to designate different Registry keys. If one is not specified, the latest setting for the key is used. The settings for the value option are similar to the rest of the template file format where the argument is taken to be a string value unless proceeded by a numeric qualifier. In addition, you can specify that the entire valuename/value pair be deleted by using value delete.

An Example of the Template File in Use

Now that we have discussed the component parts of the profile template file, we can have a look at a simple example. The idea is to create a logon script whose actions are determined by a number of Registry settings. These settings are generated and configured through a series of policies that have been added into the system policy via the SPE. To achieve this the following needs to be observed:

We create a Perl script that is encapsulated in a batch file, as only batch or command files can be run as logon scripts. This Perl script reads a set of predefined Registry entries and then acts accordingly on the data it finds there. In this case, the script looks for two Registry keys, one of which tells it what additional scripts to run, while the other supplies information for additional drive mappings. The Registry keys are as follows:

HKEY_CURRENT_USER \Environment \Logon \Scripts

HKEY_CURRENT_USER \Environment \Logon \Maps

The Scripts key contains value names that represent the full path of any number of extra scripts the administrator cares to set up. The value itself represents any command-line parameters that need to be passed on to the associated script. Thus, a value name could be d:\scripts\logon\postgrads.pl, and a value could be userlist.txt.

The Map key contains value names that represent a drive letter, and the value represents the path to be mapped. There can be any number of these mappings. For instance, the value name could be M:, and the value could be \\iago\users. These keys and values are generated automatically by the template file, as described later in this example. Note that because the Perl script uses all built-in functions, there is no requirement for invoking the use module syntax.

Example 7-2 is a Perl script designed to follow the policies described above.

Example 7-2 Policy-Controlled Perl logon Script

# logon.pl
# perl SPE-LOGON
require "NT.ph";
sub getDriveMappings {
    $index = 0;
    Win32::RegOpenKeyEx(&HKEY_CURRENT_USER,
                        'Environment\Logon\Map',
                        &NULL,
                        &KEY_ALL_ACCESS,
                        $handle) or die "unable to access Registry";
    while(Win32::RegEnumValue($handle, $index++, $valuename, &NULL, $type,
                                  $value)) {
        `net use $valuename $value`;
        print "$valuename $value\n";
    }
    Win32::RegCloseKey($handle);
}
sub getScripts {
    $index = 0;
    Win32::RegOpenKeyEx(&HKEY_CURRENT_USER,
                        'Environment\Logon\Scripts',
                        &NULL,
                        &KEY_ALL_ACCESS,
                        $handle) or die "unable to access Registry";
    while(Win32::RegEnumValue($handle, $index++, $valuename, &NULL, $type,
                                  $value)) {
        `perl $valuename $value`;
        print "$valuename $value\n";
    }
    Win32::RegCloseKey($handle);
}
&getDriveMappings;
&getScripts;

We now have the Perl script that knows about our policies, so the next stage is to create a template file to use with the SPE. The template file gives us not only the opportunity to implement our policies (that is, specify additional logon scripts and drive mappings), but to present to us a graphical interface from which to do it. Example 7-3 is a template file that does just that.

Example 7-3 Template File for Adding Policies to the User Class

class user
category "Logon Script Settings"
    policy "Scripts to Run"
    keyname "Environment\Logon\Scripts"
        part "Scripts" listbox
            explicitvalue
        end part
         part "The NAME of the ITEM represents the full path of the script" text
        end part
        part "Example - D:\scripts\logon\postgrads.pl" text
        end part
        part "The VALUE of the ITEM represents command line arguments" text
        end part
        part "and is optional" text
        end part
    end policy
    policy "Drive Mappings"
    keyname "Environment\Logon\Map"
        part "Mappings" listbox
            explicitvalue
        end part
        part "The NAME of the ITEM represents the drive letter" text
        end part
        part "Example - M:" text
        end part
        part "The VALUE of the ITEM represents the path mapping" text
        end part
        part "Example - \\iago\users" text
        end part
    end policy
end category

Having created the template file, we need to incorporate it into our system policy. To do this we import it into the SPE as a policy template (refer to earlier sections of this chapter for details on how to do this). Having imported the new template file, we can now configure the new policies. Figure 7-2 and Figure 7-3 show the interface of the additional policies for the user class and one of the new policies being configured.

Figure 7-2: The additional policies for the user class

Figure 7-3: The scripts policy being configured

Note that the list box offers us a very convenient way of data entry, and if you examine the code, you will see just how easy it is to do.

Use of Policy Template Files

Why would you want to create your own policy template file? The policy template file as envisioned by Microsoft is a tool for developers to provide policy functionality in their programs. By implementing a set of policies based on the settings of the Registry and then distributing a template file for easy control over these Registry settings, developers can integrate their programs within the wider scope of NT policies. This means that for policies to work, programs must first look to the Registry, and voluntarily limit themselves based on the information they find. It may seem that unless you are writing a Windows program, you would have little need for such a tool. When seen as a general Registry tool, though, there are many possibilities for its use:

When implementing Perl scripts, you may want to run different options based on either the current user or machine on which it is being run. One way to do this is to create a policy file that adds entries to the Registry, which your Perl script could then read and act on accordingly. By creating policies for different machines and groups of users, your customizations are propagated throughout the network as users log onto the system.
Running Windows-based software in a client/server environment can still be difficult at times. Many programs expect to be able to write to the Registry at will upon installation, and they expect that information to be there the next time they run. If you are adding software to a server, simply pointing the user to the files does not mean that the environment will necessarily be set up correctly for the program to run. If the Registry changes made by a program are straightforward, you can propagate them to local workstations by creating a template file with the necessary changes and add them to the default computer policy, which will be added to the computer at next logon.
Many times, programs do not come with their own policy files. Although this means that any customization will be limited, it is possible to control Registry settings to make sure that default values are enforced. Users will always be able to alter these during a session, but each time they log out and back in again they will find them reset.
Updating system files and drivers typically means that you have to sit down at each and every workstation. If instead you were to perform the installation on a template workstation and record changes that are made with a program such as sysdiff, you could load the files and changes to the Registry automatically to every machine when a user logs onto a machine, providing your own version of "zero administration."

The important thing to remember about policies is that they are general Registry changes that are carried out at logon. This provides the perfect opportunity to make any necessary system-wide changes to your workstations or user profiles. You are in no way limited to simply using policy templates as a tool for implementing already-defined policies. At the time of writing there were many changes in this area with regard to Windows 95 and NT. Microsoft's "Zero Administration" initiative is being billed as a solution to the problems of administering large installations of hardware and software. In addition to products Microsoft is releasing, software manufacturers in order to comply with new Logo requirements, will be required to build their applications with administration in mind-including policy templates. We hope these changes to operating system and application maintenance will make your job even easier.

About the Authors

Ashley J. Meggitt is the computing officer for Jesus College of Cambridge University, where Timothy Ritchey is a Ph.D. candidate.

Timothy D. Ritchey has written or contributed to several computing books, including Internet Security Professional Reference. Both authors have extensive programming and administrative experience.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Click to order