Practical Policies -- Microsoft Certified Professional Magazine Online

System policies allow you to focus on productivity and streamline downtime on your network. This guide shares the basics.

Practical Policies

System policies allow you to focus on productivity and streamline downtime on your network. This guide shares the basics.

By Joseph Phillips
12/01/1998

Today isn’t your usual NT administration day. In addition to upgrading hardware and software, and managing users, you’ve just learned that Bob, everyone’s favorite hack, has distributed a polar bear screensaver that whacks your Windows NT, 98, and 95 machines. If only you’d implemented system policies before that polar bear—or Bob—invaded your network.

Some Basics

System policies are rules that control what users are allowed to do on Windows machines. Because policies are based on registry templates , you have complete control over everything from the Display applet to what programs users are allowed to run. You can literally lock your network down tighter than a rusted screw.

Profiles are an excellent way to control how users’ environments look and feel (see “Profiles vs. Policies”). However, policies are the way to control what users are allowed to do. For policies to work with Windows 95 and 98, profiles must be enabled through the Passwords applet in Control Panel. Profiles are enabled by default in Windows NT.

Policies can also manage some profile-like settings. You can assign screen colors, wallpaper, and custom icons for your users. In addition, you can create custom program folders, start-up folders, and entire start menus for your users, and then take away their privilege to change any of it.

If your network is like most networks throughout the world, you’ve got a collage of different operating systems. NT Workstation 4.0, Windows 95, and its successor, Windows 98, all have unique registries and, therefore, their own unique templates and policy editors. You can’t create a policy for NT with the Windows 95 System Policy Editor and vice versa. The mechanics of the policy editors are basically the same; however, the differences warrant a brief discussion.

Figure 1. When a policy is first created in NT’s System Policy Editor, there are two icons: default computer and default user. Changes made to these default accounts affect all users and computers.

Windows 95 and 98’s System Policy Editor, if it has been installed, is found in the System Tools folder under Accessories. If it hasn’t been installed, you’ll need to add it through Control Panel’s Add-Remove Programs applet. Also, each Windows machine requires group policy support to use group policies. You can add group policy support through the Add-Remove Programs applet as well.

Windows 95 and 98 policies can be stored locally or on a server. The default value is that the policy file is stored on a server, either the PDC’s Netlogon share or on a NetWare server in the Sys\public directory. To create a local policy, you’d need to update the local computer account’s Network\Remote Update section through the policy editor to reflect that the policy is local instead of on a server.

Be certain to enable load balancing on the default computer’s network section; otherwise, all 95 and 98 machines will only accept their policy from the Primary Domain Controller (PDC), even if a Backup Domain Controller (BDC) has validated their logon request.

Figure 2. The Group Priority dialog allows you to designate how settings will be decided when they conflict for a user who belongs to multiple groups.

Neither Windows 95 nor 98 requires a user to logon to the system—a simple Esc key clears the logon dialog box. With this in mind, policies saved on a remote server can be ignored by not logging onto the network. Because NT requires a logon to use the machine, policies will always be enforced on Windows NT.

NT’s System Policy Editor is accessed through Programs\Administrative Tools. If the System Policy Editor hasn’t been installed, run the SETUP.BAT file from the NT Server CD-ROM’s clients\svrtools\winnt directory.

The Template Approach

Because each operating system has an entirely different registry and policies are nothing more than cookie cutters of the registry, each OS will require its own policy editor to create effective policies for users of those machines. If you’re participating in a domain environment, however, save each policy file in the Netlogon share on your PDC, which is %systemroot%\system32\Repl\import\scripts.

Name the Windows NT policy file Ntconfig.pol and the Windows 95 or 98 policy file config.pol. The policy file is based on a template of the registry. The template exposes variables of the registry and allows you to configure these settings for each user, group, or computer included within the policy file.

By default, the Windows NT policy editor loads the templates WINNT.ADM and COMMON.ADM. These cover the major components of the registry for Windows NT. If you need to create some obscure setting not included within these templates, you can create your own.

Figure 3. The “Triangle of Terror” gives you a simple mechanism for visualizing how a user’s settings will override each other.

To create a policy, open the System Policy Editor. On the Registry menu, select New. Two icons, Default computer and Default user, represent a default policy file. Changes made to these default accounts affect all users and computers, so, as a rule, only make general changes to these accounts. If you decide to make some very broad, sweeping policies based on these accounts, be certain to add the Domain Admins group with a policy that unlocks all of the features you’re applying on the default user account; otherwise, whatever policy you make will affect the Administrator account as well.

To create specific policies, add one of three types of accounts: user, group, or computer. A user account determines explicit settings for an individual user, such as Bob and his screensavers. A group account would control settings for a group of users, such as the salesreps. A computer account is ideal for a computer used by many different individuals throughout the day, such as a computer on a manufacturer’s shop floor or in a library setting. No matter who logs onto the computer, be it the CEO or the janitor, the computer policy makes the machine look and act the same for each individual.

When you’ve created a computer policy, be aware that the first time you logon from a machine specified with a computer policy you won’t see the policy enforced; this is because you have just downloaded the policy to the local registry. The next time you log onto to this computer, the policy will be enforced because the settings are now in place in the registry.

Get Your Hands Dirty with System Policies

If you’d like to get your hands dirty and create some system policies to go with this article, you’ll need the following ingredients:

1 Windows NT server acting as a domain controller.
Administrative rights in the domain.
1 or 2 NT Workstation PCs configured to log onto the domain
A share on the PDC called Accounts with read rights for Users.

Inside the shared folder, accounts create the following subfolders: Sales, Executives, Finance, Marketing, Developers, and Managers.
Add a different bitmap image in each of the subfolders created above. These bitmaps will become the wallpaper for users in these groups.
Add three or four shortcuts to the subfolders created above.
The shortcuts will serve as each group’s start menu.

The following user accounts: Bob, Sally, Jane, Sarah, Mike, Tom, Bill, Laura, Henry, and Rosemary.

The following global groups with these users as members:

Sales—Bob, Sally, Jane

Executives—Julie, Mike, Sarah

Finance—Bill, Henry, Laura

Marketing—Mike, Sarah, Tom

Developers—Bob, Rosemary, Sally

Managers—Henry, Jane, Rosemary, Sarah

1. Log onto your domain controller as Administrator and open the System Policy Editor.
2. Click on the new policy file button to begin the policy creation.
3. Click on the add group button and add the Sales, Executives, Finance, Marketing, Developers, and Managers groups to your policy file.
4. Set the following variables for each group:

Group	Control Panel	Desktop	Shell	System	NT Shell	NT System
Sales	Restrict Display; Deny Access to the display icon.	Wallpaper: \\your-server-name\ accounts\ sales\ bitmap-name.bmp Scheme: Windows default	Don’t save settings at exit.	Disable Registry Editing Tools.	Hide Start Menu Subfolders; Custom Start Menu: \\your-server-name\ accounts\ sales; Remove common program groups from Start Menu.	Run logon scripts synchro-nously
Exec-utives	Restrict Display; hide settings tab Restrict Display; Hide screen-saver and appearance tab.	Wallpaper: \\your-server-name\ accounts\ Executives\ bitmap-name.bmp Scheme: Wheat	Don’t save settings at exit.	Disable Registry Editing Tools.	Hide Start Menu Subfolders; Custom Start Menu: \\your-server-name\ accounts\ Executives; Remove common program groups from Start Menu.	Run logon scripts synchro-nously
Finance	Restrict Display; allow only the screen-saver tab.	Wallpaper: \\your-server-name\ accounts\ finance\ bitmap-name.bmp Scheme: Blues 256	Don’t save settings at exit.	Disable Registry Editing Tools.	Hide Start Menu Subfolders; Custom Start Menu: \\your-server-name\ accounts\ Finance; Remove common program groups from Start Menu.	Run logon scripts synchro-nously
Market-ing	Restrict Display; Hide screen-savers tab.	Wallpaper: \\your-server-name\ accounts\ marketing\ bitmap-name.bmp Scheme: Evergreen 256	Don’t save settings at exit.	Disable Registry Editing Tools.	Hide Start Menu Subfolders; Custom Start Menu: \\your-server-name\ accounts\ Marketing; Remove common program groups from Start Menu.	Run logon scripts synchro-nously
Dev-elopers	Restrict Display; Hide Appearance tab.	Wallpaper: \\your-server-name\ accounts\ developers\ bitmap-name.bmp Scheme: Rose 256	Don’t save settings at exit.	Disable Registry Editing Tools.	Hide Start Menu Subfolders; Custom Start Menu: \\your-server-name\ accounts\ Developers; Remove common program groups from Start Menu.	Run logon scripts synchro-nously
Mana-gers	Restrict Display; Deny access to the Display icon.	Wallpaper: \\your-server-name\ accounts\ managers\ bitmap-name.bmp Scheme: The Reds	Don’t save settings at exit.	Disable Registry Editing Tools.	Hide Start Menu Subfolders; Custom Start Menu: \\your-server-name\ accounts\ Managers; Remove common program groups from Start Menu.	Run logon scripts synchro-nously

5. From the Options menu choose group priority. Arrange the groups in this order, top to bottom:

Managers
Executives
Sales
Finance
Marketing
Developers

6. Save the policy file as NTCONFIG.POL in the %systemroot%\system32\repl\import\scripts directory.

7. Log onto your NT Workstation as each user and test their policies.

—Joseph Phillips

Policy Priorities

Group policies affect all users within a given group, for instance, the Sales group. But what if a user is a member of more than one group where different policies exist for each—or even multiple groups like Staff, Sales, Accountants, and Managers?

Within the System Policy Editor it’s imperative that you designate the group priority from the options menu. Group priority determines in what order group policy settings are processed. (See Figure 2.) The groups highest in the list will override settings for groups lower in this list. For instance, we could create a policy in which the Sales group couldn’t change the screensaver, whereas the Managers group could. In our group processing order we list Managers at the top of the list and then Sales. Jane, the Sales Manager, is a member of both groups. Jane would be able to change the screensaver because the Managers group allows her to make that simple change.

Figure 4. In the creation of policies, note the three switches. A gray box means to ignore the setting for this account; a check box means to enforce it; and a clear box means to remove it from the registry settings altogether.

Albeit, that was an easy comparison; but imagine an environment where users are members of multiple groups. You would have to create what I call in my NT classes, “the Triangle of Terror.”

Here’s how it works: Imagine a triangle. At the top, situate the group that has the most access to events, or the least restrictive policy. Next, list the group with the second amount of freedom, and so on down this pyramid. If you’ve done this successfully, after some trial and error, you’ll have discovered your processing order. Members of groups at the top of this list will override settings if they’re also members of groups lower in the list. This will always work, even if a user is a member of 20 different groups within your policy file.

Profiles vs. Policies

At first glance, policies are easy to confuse with user profiles. Profiles contain all user-specific settings, such as shortcuts, desktop items, colors, and even the start menu. In Windows NT, profile settings are stored in NTUSER.DAT, while Windows 98 and 95 store their user profiles in USER.DAT. When a user logs onto the machine, his or her profile is loaded into the user portion of the registry.

There are three types of profiles: local, roaming, and mandatory.

Local profiles, as the name implies, are stored locally on the computer. Windows 95 and 98 save their profiles in the windows\profiles directory, while NT saves its profiles in the %systemroot%\system32\profiles directory.

Roaming profiles are identified through User Manager for Domains on the profile tab for each user account. To use roaming profiles, create a network share—typically the Profiles directory—and then on the profile button for each user account identify the profile path as the UNC name with the %username% switch. For example, if you shared out the profile directory on a server called Bach, your UNC profile path for each user would be:

\\Bach\profiles\%username%

The %username% switch creates a folder with that user’s name. Windows 95 and 98 machines store their roaming profiles in each user’s home folder.

Roaming profiles are updated at the server each time a user logs off the network. As the user logs onto various computers, the profile is downloaded to each machine and the desktop is built. Each time the user logs off the network, the roaming profile is updated to the server based on a time stamp.

A problem with roaming profiles is that a user could log onto a machine that’s configured with the wrong time. When that user logs off of the machine, the changes made to his or her profile could be discarded because the time of the machine he or she logged onto was older than the timestamp currently on the roaming profile at the server.

To eliminate this problem, create a time server, typically the server that stores the roaming profiles, by including this line in your users’ logon scripts:

net time \\timeserver /set /yes

Now when your users log onto the domain, their machines will always be in sync with the server’s time.

Mandatory profiles require users to use the default values in the profile created for them. Mandatory profiles don’t prohibit users from making changes to the profile while they’re logged on, such as deleting icons; it only refuses to save the changes made by the users.

Many companies use mandatory profiles to cut down on troubleshooting calls such as, “I just deleted all the shortcuts on my desktop. Now what?” With mandatory profiles, the caller could just log out and log back on.

To create a mandatory profile for a group of users—for example, the global Sales group—log on as a Sales user and create the profile as it should be for all Sales users. Next, as an Administrator, through the System applet, copy the profile to a central, shared folder and give the Sales group permission to use the profile. Select the Sales accounts through User Manager for Domains and identify their account to use the profile you created and shared out in the centralized folder. Finally, change the NTUSER.DAT file to NTUSER.MAN so sales reps can’t make changes to the profile you’ve created.

—Joseph Phillips

One Against the Many

In most environments, you’ll want to work with group policies instead of user policies. After all, who wants to edit each individual user’s policy? However, there will be those pesky people, like Bob, our favorite hack, who require a little extra attention. For those folks we’ll create individual user policies. Even if Bob is a member of several groups, he’ll get a user policy that affects just him.

User policies are applied to individual users. If no user policy exists then group policies are applied in the group priority order. Finally, computer policies are applied and will override variables for both group and user policies.

As you’re creating policies you’ll discover that the selection boxes are actually three different switches. The first switch is just a gray box. This means that this registry setting is ignored for this account. The second switch is a checked box; this means to enforce this variable in the registry. The last switch, a clear box, is to clear out the registry settings.

A Brief Nightmare

A friend of mine, who asked to remain anonymous, was toying with computer policies at a client’s site. He created a logon message that was less than politically correct for his colleagues. After a few laughs, he deleted the NTCONFIG.POL from the Netlogon share. Because it was a computer policy, however, the changes were actually already made at each machine where the policy had been downloaded. Much to the client’s chagrin, the logon message continued to appear. After four days of complaints from users where the computer policy had been downloaded, he went through each registry and removed the logon message manually.

What my buddy could have done was clear the check mark for the logon message in the original NTCONFIG.POL file, which would have wiped out the logon message from each machine the next time the policy was downloaded. Or he could have created a new policy file and cleared the checkmark to wipe out the logon message for each computer that currently had the message downloaded.

Generating Productivity

Your environment may not allow you to set up policies, because the staff wants to be able to browse the entire network, change their network settings, and edit the registry. But if you can overcome that and implement strong policies, you’ll be generating productivity for yourself and for the company.

As a Microsoft Certified Professional, policies allow you to focus on productivity, streamline downtime on your network, and invest more time with things that really matter—like finding cool polar bear screensavers that work well with NT.

Additional Information

Books

Mastering Windows NT Server by Mark Minasi and Peter Dyson (Sybex Network Press, $59.99, ISBN 0-78212-163-2).
Windows NT Server 4 Professional Reference by Karanjit S. Siyan (New Riders Press, $65, ISBN 1-56205-805-3).

Training Classes

Microsoft Authorized Training Course 803, Administering Windows NT Server, which covers local and roaming profiles.
Course 922, Core Technologies of NT Server, which covers policies.

Knowledge Base Articles
Profiles are covered in these articles: