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.
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:
- Q142682—”How to create
and copy roaming user profiles in
Windows NT 4.0.”
- Q146192—”How Windows NT
chooses between roaming and local
profiles.”
- Q154120—”Debugging User
Profiles and System Policies in Windows
NT 4.0.”
Policies get coverage
in these articles:
- Q159936—”Using the Windows
NT 4.0 or Windows 95 System Policy
Editor.”
- Q143164—”INF: How to Protect
Windows NT Desktops in Public Areas.”
- Q151176—”Policy registry
entries (Default User).”
- Q151177—”Policy registry
entries (Default Computer).”
|
|
|