There is in every organization a certain kind of user, universally loathed and dreaded by IS professionals. This user goes by many names: the button pusher, the icon clicker, the program (game) loader, the setting changer, etc. You know who I mean—those pesky users who insist on changing everything you’ve set up so nicely for them. And when they really mess things up, whom do they call? That’s right: you. Don’t get mad and don’t despair. Using a little-known tool included with Windows 95, you can make sure that nothing goes on that you don’t want to happen. Locking down user desktops is only one of the things this program is good at. Read on to find out more.

The tool is called the Windows 95 System Policy Editor. It’s a utility that is capable of creating some big-time savings for you, and it’s included free with Windows 95. You can see it in Figure 1 and Figure 2. As you can see from these figures, allowing or denying user actions is almost as simple as checking a selection box.

Lock ‘Em Down

Using the Windows 95 System Policy Editor, you can lock down your systems in several ways. There are options for controlling system options, setting security, and editing configurations of target computers from a remote location. You can lock down user desktops, prevent changes to system configurations, and limit who can run the MS-DOS prompt. You can also maintain custom settings that follow users around the network, no matter which computer they use, as long as the computer is set up to use policies. Other system options you can control include the ability to display a login banner, set up specific program groups or startup folder and desktops icons, and run a program on the target PC at startup. You can also prevent people from running the Registry Editor and from changing their wallpaper.

You also have extensive control over the security options available through computers that are running system policies. For example, you can lock people out of the Network Neighborhood, restrict access to the Control Panel, and restrict people from

sharing resources such as hard drives on the network. You can require that a valid login to the network be performed before the user is allowed to access Windows on the local level. You can require Windows passwords to be alphanumeric and of a minimum length. You can disable dial-in connections to the computer as well. You can even create a custom Network Neighborhood.

The icing on the cake is that you can do all of these things remotely from the comfort of your chair. Using the Windows 95 System Policy Editor, you can reach across the network and configure many aspects of other computers without being there physically.

It’s a Matter of Policy

I’m going to start by outlining some concepts you need to know when using the System Policy Editor. There are two types of settings that can be controlled using the System Policy Editor: user settings and computer settings. The other thing you need to be aware of is that there are two modes that the System Policy Editor functions in: registry mode and policy file mode.

The registry mode is used to directly edit the Registry of a particular computer, either local or remote. The other mode is used for creating policy files. Policy files are files that contain Registry settings that can be copied down from network when the user logs on. The result of using policy files is a little different than editing the Registry directly, because the policy files can follow users around the network from computer to computer. You can set the policy files to override Registry settings when they’re downloaded from the network.

You also have control over both user settings and computer settings. If you have user profiles enabled on your Windows 95 computer, you can set policies for users. For more information on how to set up Windows 95 for user profiles, see the references at the end of this article. System policies for computers are used to prevent modifications to hardware and other environment settings for the operating system to ensure that your users do not mess up their Windows 95 configurations.

Behind the Scenes

When you set up system policies, certain portions of the Registry on the machines that receive the policies get replaced at login with the values specified in a file called CONFIG.POL. This may sound a little scary, but don’t worry—you can control which sections get replaced.

When the user logs on, the user’s configuration information is checked for the location of the policy file. When the file is found, it is downloaded (keep reading for information on where the file is usually downloaded from) and the information in it is applied to the Registry. If you have user profiles enabled, Windows 95 looks for a policy file that matches the user name of the person logging on. If one is found, it is used to set the policies for the user. If one is not found, a policy file named Default User is applied. If group policy support is enabled, group policies are downloaded and processed for each group that the user belongs to. Groups can be assigned a priority, so if a user is a member of multiple groups, the policies are used in an order that you can control. If the same policy is specified in more than one group, the policy in the highest priority group is used.

Windows 95 also looks for a computer policy file at login. This computer policy file, if it exists, is applied to the user’s desktop environment based upon which computer the user is logging on from. If a policy file for the specific computer is not found, the default computer profile is used. When the default settings are active, Windows 95 will attempt to download the user policies from the PUBLIC directory on a NetWare server and the NETLOGON directory on a Windows NT server.

Example—Disabling the Passwords Applet

To demonstrate how to use the System Policy Editor, let’s deny users the ability to go into the Passwords applet from the Control Panel on their Windows 95 machine. If you decide that you don’t want to use password caching for Client Access/400, you can disable it within this applet and then disable the applet itself, so users can’t turn it back on. This is

just a sample scenario to help you see how the System Policy Editor is used. Of course, you’d probably want to customize things for your environment.

I’d like to give a word of caution. If you aren’t careful with the System Policy Editor, you can accidentally lock yourself out of areas that you may need to go into. You should be sure that when you do implement policies, you leave yourself a method of controlling them. For example, if you make a list of authorized programs that can be run a Windows 95 machine for all users, and you don’t include the ability for administrators to run the System Policy Editor, you could paint yourself into a corner.

The first step is to install the System Policy Editor on the target machine. To do this, go to the Windows 95 Control Panel. Double-click on the Add/Remove Programs icon. Click the Windows Setup tab. Click the Have Disk button. In the next dialogue, browse to find the Windows 95 installation files. The System Policy Editor is in the ADMIN/APPTOOLS/POLEDIT directory of the Windows 95 CD. Once you’ve found this directory, click OK twice. Make sure the System Policy Editor entry is checked and then click the Install button. The necessary files will be copied your hard drive and placed in the System Tools directory under the Accessories folder in the Start menu.

The next step is to start the System Policy Editor. Click on the Start menu, select Programs, select Accessories, select System Tools, and then select System Policy Editor. The program is started and presents you with a blank screen. At this point, you have a choice about whether to directly edit the Registry immediately, or create a policy file that will be applied to the Registry later. To keep the example simple, I will select the option to edit the Registry immediately. Under the File menu, select Open Registry. The screen shown in Figure 3 appears.

Clicking on the icon for the local user will allow you to edit user-based settings. The local computer icon, of course, will allow you to create settings for the local system. Double-click the local user icon. Expand the tree by clicking the plus sign (+) next to the entries until the screen looks like the one shown in Figure 1, where the options for Passwords appear. Selecting or clearing an option on the bottom of the screen will make the appropriate changes in the Registry. For this example, I’m going to select the option to disable the Passwords control panel. Once this is done, I click the OK button and exit the program, saving changes when prompted.

Once the Passwords applet is disabled, any attempt to access it will yield a screen like the one shown in Figure 4. As you can see, if something is disabled by a policy, there is no easy way around it. If you work in an organization that uses high-security procedures, this can be another way of making sure that things are indeed secure.

Client Access and System Policies There are many possible uses for the System Policy Editor and Client Access. Aside from the obvious uses of securing your Windows 95 computers from user tampering, you can also use the System Policy Editor for other Client Access administration tasks.

When you load Client Access on a Windows 95 machine, there are some processes that start no matter if you connect to your AS/400 or not. For example, the services that provide network driver functionality and AS/400 printer functionality are always started on Windows 95 machines by default. If you do not use the services, you can use the System Policy Editor to disable them, thereby gaining back the memory that they use. You disable them by editing the policies for the local computer, expanding the entry for System, clicking the Run Services entry, and clicking the Show button. This series of clicks brings up the screen shown in Figure 5. There are two entries: one for network drives and one for network printers. You can remove them by selecting them and pressing the Remove button. Keep in mind that this is messing around with the internal functionality of Client Access, and things may not go as planned. You should always back up your Registry and other important items before you make these changes.

Be a Policy Maker

As you can see, the System Policy Editor offers to a lot of functionality and control over Windows 95 environments. You can use it for many things, including locking down users and preventing them from tampering with their machines to customizing your Client Access environment in many different ways. This little-known utility may be just the answer to your organization’s setting-changer.

Figure 1: Editing the Local User properties

Figure 2: Editing the system properties

Figure 3: The System Policy Editor in Registry-editing mode

Figure 4: Denied—Users can’t access the things you don’t want them to.

Figure 5: The services that run automatically as part of Client Access

Brian Singleton is former editor of Midrange Computing. He has worked in the IBM midrange arena for many years, performing every job from backup operator to programmer to systems analyst to technology analyst for major corporations and IBM Business Partners. He also has an extensive background in the PC world. Brian also developed a line of bestselling Midrange Computing training videos, authored the bestselling i5/OS and Microsoft Office Integration Handbook, and has spoken at many popular seminars and conferences.

---

MC Press books written by Brian Singleton available now on the MC Press Bookstore.

		i5/OS and Microsoft Office Integration Handbook Harness the power of Microsoft Office while exploiting the iSeries database. List Price $79.95 Now On Sale

Also Read

TechTip: Getting Started with Microsoft Visual Studio Express 2012

TechTip: Troubleshooting Team Foundation Server

TechTip: Installing Microsoft SQL Server 2012 Express on Your Local Machine