In an organization with tens, hundreds, or even thousands of users, the effective and efficient management of all of these Registries can be unwieldy, if not impossible. Up to this point in the book, all of the changes to the Registry have been made one system at a time. Imagine making all (or even half!) of the changes discussed in this book for 100 systems. The time to do that would be much too great. System Policy Editor allows you to make changes for all the systems on your network at one time. It also allows you to make changes to an individual system. User management is also easier with System Policy Editor. User-based changes can be made for an individual, for groups of users, or for all users on the network. These changes are made from an individual system, an NT server or a Windows 95 system, and then distributed to all the systems at logon.
The changes to be made to the Registries of the systems on the network fall into four categories:
This section will introduce you to one of the most powerful ways to perform system-wide management of the Registries: the System Policy Editor. This allows you to impose updates on systems for user-level and computer-level changes. It requires no user input, and the user has no choice to accept or reject the settings, because the policy automatically overrides any changes the user makes.
The Latin root of policy is the same as for police (politia). Webster's Dictionary defines policy as a "high-level overall plan embracing the general goals and acceptable procedures of a government body." A policy in Windows NT or 95 is exactly the same. As an administrator, you must impose procedures and maybe even restrictions on users on the network. From the System Policy Editor in Windows NT Server 4.0, you can set policies for NT 4.0 systems only. It will not set policies for Windows 95 systems or NT 3.5x systems. The System Policy Editor in Windows 95 will only create policies for Windows 95 systems.
The System Policy Editor for Windows NT is installed during the Server installation. The System Policy Editor for Windows 95 on the Windows 95 installation CD-ROM, and can be run directly from the CD or copied onto the hard disk. The menus, interface, and all functions are the same as the Policy Editor in NT, but the policy file created by the Windows 95 Policy Editor is saved in ASCII, while the policy file created by the NT Policy Editor is saved in Unicode. The two policy files are completely incompatible. The System Policy Editor in Windows 95 can create policies only for systems running Windows 95, and the System Policy Editor for NT can create policies only for NT 4.0. And, unlike Windows 95, the System Policy Editor for Windows NT also allows the use of multiple template files, making the addition of policies very simple.
Even though many of the system settings for NT 4.0 are exactly the same, Windows NT 3.5x doesn't even look for a policy at logon. The existence of a policy file has no impact on NT 3.5x.
NOTE: System Policy Editor does not actually provide policy for the users. It simply is the tool to help you implement the policies you currently have. If you impose a policy that has not been agreed upon, you'll encounter upset people, maybe even an uprising. On the other hand, if policies for your organization are well-defined, implementation is easy, and users accept them. Discuss the policies first, and then implement them.
Because of their similarity, this book will deal with both editors together. Only during the template file discussion will they be separated.
Any policy that you implement updates the Registry automatically at logon. Types of changes include user-specific and computer-specific changes. User-specific changes affect HKEY_USERS, and computer-specific changes update HKEY_LOCAL_COMPUTER.
Examples of user-specific changes include
These settings can be implemented for a specific user, all users, or by groups (as set up in User Manager for Domains).
Examples of computer-specific changes include
Computer-level policies can be set for all systems in general or for specific systems only.
Policies implemented on the system override all other settings that conflict, as illustrated in Figure 28.1. For example, you could set a policy demanding that the wallpaper be the company logo. If a user changed it during a session (using Control Panel | Display | Background), the company logo would reappear as soon as he logged off and back on again.
Figure 28.1. Policies override all other settings at logon.
WARNING: One upset user at a seminar asked me if this is where administrators learn to be God. I hope that is not the case. Excess restrictions on users only make adversaries of them, and productivity suffers.
Not all settings in the Registry are affected by the implementation of a logon script. Similarly, User Profiles do not override everything set by the Registry and the logon script. Policies have ultimate priority. Anything they change overwrites any other settings in the system.
Open System Policy Editor in NT with Start | Programs | Administrative Tools | System Policy Editor. Start the Windows 95 editor by activating POLEDIT.EXE, which is on the Windows 95 installation CD, in the \ADMIN\APPTOOLS\POLEDIT directory. After opening the editor, select File | New Policy, and you will be presented with the screen shown in Figure 28.2. Notice that there is an icon for default computer and another for default user. Any policy settings created for the default computer automatically affect every NT 4.0 or Windows 95 system on the network. Any policy created for default user likewise affects every user on the network that is running NT 4.0 or Windows 95.
Figure 28.2. System Policy Editor in Windows NT 4.0 server.
To create
specific policies for individual systems, click the Add Computer button
or select Edit | Add Computer. Provide the name of the system in the dialog box and
click OK to continue. More detail about working with policies for systems is included
in
Chapter 31, "Managing Domain Computers with System Policy Editor" and
Chapter 33, "Managing Windows 95 Users with System Policy Editor." Adding
a computer to the policy creates an icon as shown in Figure 28.3.
Figure 28.3. Creating a policy specifically for SERVER1, Bob, and the New Users group.
To create policies for individual
users or groups, click the Add User button or the
Add Group button respectively, then supply the name and choose OK to continue. More
detail about working with policies for users and groups is included in Chapter 32,
"Managing Domain Users with
System Policy Editor" and also in Chapter 33,
"Managing Windows 95 Users with System Policy Editor." Adding a user and
a group to the policy creates an icon as shown in Figure 28.3.
Unlike the Registry Editor, the System Policy Editor does not automatically save changes. If you do not save them, changes are lost at exit. To save the policy, select File | Save.
Policy files are stored in the NETLOGON share in a Windows NT network, so all users logging on to the system have immediate access to them. The actual path to the NETLOGON share is %systemroot%\system32\Repl\import\scripts. Any changes to the NT policy are saved there as NTCONFIG.POL for NT systems. NT always looks for a policy named NTCONFIG.POL at logon. If it is not there, no change to the Registry occurs. As long as they are present, any changes activated in the policy overwrite any Registry settings, as shown in Figure 28.4. Likewise, Windows 95 looks for a policy file called CONFIG.POL in the NETLOGON share.
TIP: System Policy Editor also works with networks other than Windows NT networks. In a Novell network, save the policy file in the PUBLIC directory. For Banyan, Pathworks, and other networks, you must specify for each system where the file is to be found. For stand-alone Windows NT and Windows 95 systems, you must also specify the location. After you set that, all the systems look to that point for the information.
Figure 28.4. Policies overwrite Registry settings at logon.
The policy updates the Registry at logon. Any time the Registry is manually changed,
the policy overwrites the Registry at logon. Regardless of the number of times the
change is made, as
long as the policy is in effect, it forces specific Registry settings.
If, after the change is made, the policy file is removed or the policy is no longer specified, the user can change the setting in his personal Registry without it being overwritten. Returning to the wallpaper example discussed previously, if the user changes his wallpaper and no policy maintains the setting of the logo wallpaper, the wallpaper is not changed back.
Policies that restrict users should be present at all times, regardless of the preferences of the user or any change made by software. An example of such a case is the restriction on common groups. If you disable access to common groups for a particular user, that user can enable access to the groups if he knows where the Registry change is for that setting. Likewise, any Registry change that can be implemented through the Registry is a perfect candidate for a permanent policy.
TIP: A good idea for administrators using the System Policy Editor tool is to always create some way to get back to normal in the event of a mistake. If you ever need to remove all of the settings you have created for users, it's wise to have a backup file that returns all the systems to normal. If you have created a policy file that has all settings specifically turned off, you could simply copy the backup file over the current policy file, and order everyone to log off and log on again to return the settings to their original state.
TIP: I keep a backup that I know functions properly of my last favorite policy file. If I need to return to that point, I copy the file to the NETLOGON share, log off, and log back on again.
After certain policies have written to the Registry, they no longer need to be in effect. An example of such a policy is one that changes IP address settings for the network: After everyone has logged on to the network, that policy need not remain in effect. Another example of such a policy is one that restricts a user from editing the Registry: The user cannot undo such a change, so there is no reason for the policy to remain in effect.
If the setting can change during the session, and if the policy is no longer in place, the policy is defeated by a Registry change.
WARNING: If your NT system uses the FAT file system for your System volume, you may be putting your policy files and logon scripts in jeopardy. The default permissions for the NETLOGON share give everybody Read access. If you share the \WINNT directory or any other in the \WINNT\SYSTEM32\Repl\Import\Scripts tree giving Full Control to everyone, access extends through all subdirectories and files as well as the original shared directory. That means that any user can get to that directory and delete files, including policy files. The best security is with the NTFS file system. With it, you can set specific permissions on individual files, giving everyone but the administrators (who require Full Control) Read access to the policy file and logon scripts.
System Policy Editor allows an administrator to effectively manage a large number of users and systems in an organization from a single location. The opportunities for the direction of change are significant and far-reaching. Used wisely, System Policy Editor can save huge amounts of time and effort in training, troubleshooting, management, standardization, and administration of a network. Used unwisely as a tool for domination and user restriction, it may cause a revolt among your users.
Use caution, concern, and communication, along with training, to implement policies in your organization to meet the organization's needs and agendas.
© Copyright, Macmillan Computer Publishing. All rights reserved.
