Understanding system policies

By John Sheesley

Published in TechRepublic's Windows NT Support Professional

What causes most of the trouble calls on your network? It probably isn't defective hardware, buggy software, or hackers. Chances are, most of the problems that occur on your network are the result of users doing something they shouldn't. Fortunately, you can deploy system policies on your NT server for your Windows 9x and Windows NT Workstation computers. In this article, we'll explain what system polices are and how you can use them to keep your users out of trouble.

Why do you need system policies?

When LANs first became popular, programs were simpler than they are today. Few people had their own workstations, and users rarely traveled from machine to machine. Security was easy to implement, because programs and desktop operating systems were relatively simple. Users couldn't do much damage to machines or the network unless they did it intentionally.

When Microsoft shipped Windows 3.0, things started to change. Windows allowed users to run multiple programs and customize many aspects of their systems. Windows introduced INI files, which contain information about the system's configuration and application settings. Later versions of Windows also implemented a primitive registry database.

In addition to letting users do more with their computers, Windows helped increase the computer's popularity in a network environment. However, this increased popularity and complexity had one major drawback: Users started getting into trouble. If users accidentally deleted INI files or made changes they shouldn't in system files, they quickly found out that they'd done something wrongonce stable systems crashed or became completely inoperable.

To control such meddling, network administrators had to make their own changes to Windows 3.x's INI files. To do so, administrators normally had to visit each machine.

With Microsoft's release of Windows 95 and Windows NT Workstation 4.0, some aspects of workstation management became simpler while other complications arose. Most of the problems with INI files disappeared as 32-bit programs used the system registry to store configuration information. At the same time, however, this file became more complicated and easier to damage.

To help out, Microsoft introduced the concept of system policies and user profiles. By using them, administrators gain greater control and flexibility over system configuration.

What are system policies?

System policies consist of a set of system registry settings that you create and place on workstations as they log on to the network. These registry entries affect machine and user-specific settings on the workstation. System polices control what resources are available to users, based on the way you define the policies.

You can define system policies on a user or group level. Policies can govern such issues as:

• What applications appear on the desktop

• Which applications appear on the Start menu

• Access to basic system areas, including Control Panel or properties for printers and networking

• Access to the command prompt

Don't confuse system policies with user profiles. Profiles merely control the user's interface; they contain such settings as backgrounds, schemes, and icons. System polices complement user profiles by allowing administrators to control what users do as well as what they see.

You also shouldn't confuse a system policy's ability to control what the user can do with other security restrictions you use on your network. System policies modify user- and machine-specific settings only in the workstation's registry. Policies don't affect any file, print, ACL, or other security settings that you may place on your network.

You can create three types of system policies: computer policies, group policies, and user policies. These policy types give you more flexibility over the policy settings that you apply to your network.

Computer policies apply to individual machines. These policies control such things as the ability to shut down the system, change network settings, and access the command prompt. Settings made for machine-based policies affect the HKEY_LOCAL_MACHINE key in the machine's registry.

As the name implies, user policies apply to individual users on your network. User policies control what applications the user can see, programs that appear on the Start menu, Control Panel items, and so on. User policies contain registry settings that affect the HKEY_CURRENT_USER subtree.

Group polices work in a way similar to user policies. Like user policies, group policies affect the HKEY_CURRENT_USER subtreebut, unlike user policies, group policies affect multiple users. Users you've made part of a particular group inherit the group policy that you apply to that group. Because you can use group policies to set controls for multiple users, they can save you a lot of time when you set policies.

How do system policies work?

Although you place system policies on your server, they don't affect the server. Instead, they modify the registry settings of your workstations. The server only stores and distributes the policies to the workstations when they log on.

You can apply system policies only to Windows 9x and Windows NT Workstation clients. If you still have Windows 3.x, OS/2, or Macintosh clients on your network, then you're out of lucksystem policies won't work on these operating systems.

Because of architectural differences between Windows 9x and Windows NT, you must maintain separate system polices for Windows 9x workstations. The system registry is different on Windows 9x than on a Windows NT workstationregistry changes that system policies make for one operating system won't work on another operating system.

Windows 9x systems policies are contained in the file CONFIG.POL. Windows NT gets its system polices from the NTCONFIG.POL file. You create these files using the version of the System Policy Editor that matches your operating system.

After you've created the POL files, you place them on your NT network's Primary Domain Controller. You must put them in your server's NETLOGON share, which is in the \SYSTEM32\REPL\IMPORT\SCRIPTS subdirectory. If the files are named incorrectly or stored in the wrong area, workstations won't be able to find then when they log on.

Workstations get the system policies from your server when users first log on to the system. After the user enters a user ID and password, the workstation checks the NETLOGON share for the POL file that corresponds to your workstation's operating system. If your server doesn't have a POL file in the NETLOGON share or if the workstation can't find it for some reason, then your server won't apply any policies on the workstation.

If you have more than one server in your domain, be sure the policy exists in the NETLOGON share of all of your servers. A workstation obtains the policies from the server that validated it on the network, so the polices should be identical on all servers. (The only exception to this rule is the Group Policy, when applied to Windows 9x workstations. Windows 9x workstations always obtain group policies from the PDC, even if they validate using a BDC.)

Applying user policies

If the workstation finds a POL file, it first searches the file for a user policy specific to the user that logged in. If it finds such a user policy, it applies the proper registry settings to the workstation's HKEY_CURRENT_USER subtree and looks for computer policies. (If a user has a specific user policy, the workstation won't look for group policies.)

Applying group policies

If there are no specific polices for a user, the workstation searches the POL file for a default user profile and applies that, if it exists. Then, the workstation searches the POL file for group policies to which the user may belong. If it finds group policies, the workstation applies these changes to the HKEY_CURRENT_USER subtree.

When you create group policies, you must assign them a priority number. Workstations apply the group policies in reverse order, starting with the lowest-priority groups and overlaying higher-priority group settings. This process ensures that high-priority group settings overwrite and take precedence over lower-priority group settings.

Unlike it did with user policies, Microsoft didn't make provisions for a default group policy. If you don't have group policies, the workstation immediately begins to search for computer policies.

Applying computer policies

Finally, the workstation searches the POL file for computer profiles specific to the machine the user is logging on to. If it finds a computer-specific policy, it applies the proper changes to the HKEY_LOCAL_MACHINE subtree. As with user policies, if you don't have a computer-specific policy, the workstation searches for a default computer policy. If such a default policy exists, the workstation uses it; if not, the workstation continues the boot process, as normal.

Watch out

As you can imagine, anything that makes changes to a complex area like the Windows system registry can't be too simple. You must be very careful before you install system policies on your networktake time to plan the policies completely. You also need to perform a few tasks in advance and watch out for potential pitfalls:

• Create an administrator group policyWhen you design your system policies, be sure you include a special group policy for your administrators that undoes all the changes other policies implement. If you don't take this step, you may find yourself locked out of important areas of your workstations. You'll quickly find that your attempts to restrict your users have backfired!

• Install Service Pack 3 on NT WorkstationsWhen you implement policies on your Window NT workstations, be sure you've loaded Service Pack 3 or later on your workstation. Versions of NT Workstation without this service pack won't use global group policies: They'll go straight to the default user policy.

• Verify that your PDC is working for Windows 9x logonsIf you use group policies with a Windows 9x workstation and notice problems with policies, check your PDC. Even if your Windows 9x workstation validates its logon with the BDC, it still looks to the PDC for its group policies. If the Windows 9x workstation can't contact the PDC, it will apply the default user policy.

• Watch for double negativesWhen you're setting up policies in the System Policy Editor, read the options carefully: Some of them are stated in a very confusing manner. Sometimes you must click Disable to turn on a negative statement, meaning that you must say "no" when it seems that you mean "yes."

• Location, location, locationBe sure the POL files are located in the right place on your servers. You should put the policies in the NETLOGON share, which is in the \SYSTEM32\REPL\IMPORT\SCRIPTS subdirectory. If you put the files in the wrong directory on your server, the workstations won't find them. Also remember that workstations load the policies from the domain that users log on to, not the domain where the workstations are physically located. This can get confusing if users log on to domains at some place other than their physical locations.

• Check for directory replicationEnsure that all servers within the same domain are properly replicating their directories among each other. If they aren't, it's possible that workstations may obtain out-of-date policies or miss policies altogether.

• Track effective policiesRemember the order workstations use to load policies. If your policies don't seem to be working the way you planned, it's probably because a policy loaded later and overwrote a setting you weren't aware of. Check your group policy preferences and the settings in the group policies to see what the effective policy setting is for a user after all settings have been loaded.

Conclusion

As computers become more complicated, users have more chances to inadvertently do things that can get them into trouble. Fortunately, you can deploy system policies on your network to control users' actions. In this article, we took a look at what system policies are and how they work.

Additional Information

For more information or to subscribe, go to the TechRepublic web site at
https://www.techrepublic.com .

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.