Creating System Policies for a Mobile Workforce

A how-to guide

System policies in the Windows operating system (OS) environment (Windows NT, Windows 98, and Win95) perform the same function as policies in an employee manual. System policies prevent users from performing actions they would otherwise have had the choice to perform.

Administrators can use system policies to prevent unauthorized users from running a Registry editor. That way, administrators don't encounter the situation in which they try to resurrect crashed machines while employees stand by, vowing that they did nothing to cause the crash. In the Registry, adding one wrong value or deleting one good value can cause hours of work for administrators. (To find out why using system policies is better than locking the Registry, see the sidebar "Why Policies?" page 198.)

Much has been written about how to create and implement system policies for users who work within the confines of a company's buildings, so I will not tread on ground already covered. (For a list of articles and books written about this subject, see "System Policies Related Reading," page 199.) But what about creating and implementing system policies for remote users, such as salespeople and executives who use laptops on the road? You cannot force these users to connect to the server and read the policy on every boot. As a result, remote users typically have full access to all network resources, can edit their Registry, delete printer settings, and perform other actions that might reduce productivity and increase support time for administrators.

Because you cannot force remote users to connect to a server each time they boot, an alternative is to place the system policies on a local drive. Whether your mobile workforce uses NT Workstation or Win95, the steps are similar. First you create the local restrictions, and then you create the policy.

Creating Local Restrictions
Configuring the system for local policy placement requires a Registry modification. You can make this modification using regedit or System Policy Editor (SPE).

Regedit. To modify the Registry using regedit, go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlUpdate. Create or modify two values: UpdateMode and NetworkPath.

The possible DWORD values for UpdateMode are 0, 1, and 2. A value of 0 means that you are not using system policies (i.e., you have not selected the Remote Update check box). A value of 1 means that you are placing the system policies on the server (i.e., automatic mode). A value of 2 means that you are placing the system policies on a location other than the server (i.e., manual mode). Set the DWORD value of UpdateMode to 00000002.

Because you specified that the system policies will be at a location other than the server, you need to specify where you are placing those policies and the name of the file containing them. The default filename is config.pol or ntconfig.pol. However, if you have remote users who like to tinker or read computer books, they might quickly figure out that config.pol or ntconfig.pol contains the system policies. They might search their system, find the file, and "accidentally" delete it so they aren't required to follow system policies. In such a case, you can give the file another name (no naming restrictions exist) such as wipedisk.abc and place it in an obscure directory. Renaming and hiding the file will not affect NT's operation; both SPE and the OS will be able to read it.

After you decide on the filename and location for the system policies, you must specify this information in NetPath. For example, if you decide to use the default filename of config.pol and want to place it on the C drive, you set the string value of NetworkPath to c:config.pol.

SPE. To modify the Registry using SPE (poledit.exe), select Open Registry from the File menu. Select Local Computer, Network, and Update. Select the Remote Update check box, as Screen 1 shows. Select Manual (use specific path) from the Update Mode list, and type

c:config.pol

as the path. Save your changes, and exit SPE.

Regardless of which method you use, the result is the same: Rather than being on the server, the policy is now on a local drive. After you have configured the policies to be local on one machine, you don't need to repeat this process on every machine. You can use a much easier method: Open regedit, and highlight HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlUpdate. From the File menu, select Export Registry File. Give the file a name, such as policy, and save it to a 3.5" disk or a drive that you can access, but users cannot. The resulting executable file, policy.reg, includes several commands:

You can use this file to set the Registry values on any system. You execute the file by opening Explorer and double-clicking the filename or by entering the name of the file (c:policy.reg) at the command prompt.

Creating the Policy
Now you need to use SPE to create the system policies file. Two SPE versions exist. One version comes with Win95; the other version comes with NT 4.0 (Server or Workstation). The utility is the same (poledit.exe) regardless of the OS it came with, so you can run NT's SPE on Win95 and Win95's SPE on NT. However, whether you're making policies for Win95 or NT clients, using NT 4.0's SPE is advantageous because it is newer and lets you load more than one template. All loaded templates aggregate to form one set of options.

To create the system policies file, open SPE, Options, Template. NT users have two complementary default templates (winnt.adm and common.adm) listed. Add both as templates. Win95 users have only one default template (admin.adm) that they can add.

When the templates are loaded, choose New File from the File menu. A screen with two icons--Default User and Default Computer--appears. The settings you establish for these defaults affects all users who log on to the system but don't have named policies.

To establish the correct settings, you need to understand how the logon process works. First, the OS gathers the Registry's policy settings (from ntuser.dat or user.dat) and system information (from several hives in NT or system.dat in Win95).

Next, the OS checks Default User and Default Computer. The Default User settings override the ntuser.dat and user.dat settings. The Default Computer settings override the hive and system.dat settings.

Finally, the OS checks groups and users. Group settings override default settings, and individual user settings override group settings. If a user belongs to more than one group, subsequent group settings can override each other. By default, the OS executes the group settings in order from the most recently created group to the oldest created group. (This order assumes that the first group created has priority over those created after it; by executing the first group last, the OS ensures that the settings in it are not overridden by any other settings.)

If you have a mobile workforce, having multiple groups isn't a good idea. The amount of work involved in their setup and maintenance outweighs the benefits of multiple groups. In addition, if you activate group policies for Win95 clients, you must place the grouppol.dll file in the WindowsSystem directory on every client computer.

Default User Policies
You need to follow solid system basics when setting the defaults. Here are several guidelines:

When creating your settings, you can choose from three options: a selected check box, an empty check box, and a shaded check box. A selected check box means that the noted action will take place. For example, a selected Disable Registry editing tools check box disables the Registry editing tools. Thus, users can't use those tools. An empty check box means that the noted action will not take place. For example, an empty Disable Registry editing tools check box will not disable Registry editing tools. Therefore, users can use those tools. A shaded check box means the action that was previously decided will take place. For example, if you select the Disable Registry editing tools check box in the Default User settings and then shade the Disable Registry editing tools check box in the settings for an individual user, the individual user will not be able to use the Registry editing tools.

After you have created your system policies file for the Default User, you need to add an administrative account for each person who will support the system and its users. When you add an administrative account, the OS uses the Default User settings that you just created as the template. Thus, you need to change the settings to give the administrative account the authority to access those items inaccessible to default users. Simply put, you need to turn the selected check boxes into empty check boxes by clicking each box. (Do not double-click because double-clicking will shade the box.)

After you create the administrative account policy, you can create account policies for individual users or groups. If you want to simplify administrative matters as much as possible, let the Default User settings apply to these policies.

Default Computer Policies
Rather than creating policies based on the user, you can create policies based on the computer. However, I don't recommend creating Default Computer policies for a remote user because this policy resides on only one computer--the computer the remote user is using.

You create the Default Computer policy file the same way you create a Default User policy file. The Default Computer setting applies to all computers unless you create a policy for a specific computer. The name of the policy must match the computer name on the Identification tab of the Network dialog box.

Many Options Open
You are not limited to the policy templates that come with their respective OSs. Many other templates (all have .adm extensions) are available. For example, if your company uses Microsoft Office, you can incorporate the template on the Office Resource Kit CD (95 or 97) to restrict operations in that product. Templates are also available for Microsoft's Internet Explorer (IE) and Novell's NetWare Client 32. Microsoft's Zero Administration Kit (ZAK) is a big set of templates that lets you turn a user's computer into an expensive dumb terminal.

No matter the source of the policy templates, system policies are an important tool for users who work not only within the confines of a company's buildings but also outside those confines. Administrators can use locally placed system policies to make sure that unauthorized remote users don't tamper with the Registry and other vital OS areas.