Export (0) Print
Expand All

Introduction

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Michael Meulemans

ABSTRACT: Windows 95 allows easier user and system management through User Profiles and System Policies. User Profile components include Windows 95 settings (for example, background, font selection, shortcuts), network settings (network connections and shared resources), and application settings (menu/toolbar configurations and application window configuration preferences). System Policies, which supersede any settings that may exist in User Profiles or Hardware Profiles, allow network administrators to manage and modify network policies or user configurations for all networked Windows 95 users. An annotated bibliography at the end of this article lists additional sources of information.

Recent focus group polls conducted by TechNet indicate that help desk managers and network administrators often are justifiably skeptical about allowing users free rein to set up personal PCs on the network. Now, user management tools in Windows 95 allow network administrators to customize the look and feel of networked PCs on the basis of users' preferences or their hardware. As Christine Comaford said recently in "PC Week":

"Windows 95 heeds my call for user safety nets. It will let me set up user profiles and disable portions of the Control Panel. What a feeling of power. I don't want to hear about any more helpdesk calls from users who accidentally uninstalled their printers or set all system colors to be blue and want to know what's wrong with their monitor."

System management tools are not new to Microsoft products; they have been around in various forms in Microsoft LAN Manager, Windows NT, and Windows for Workgroups. While these tools helped network managers control certain aspects of users' PC environments, they were not yet sufficiently developed to allow specific and precise control of user desktops from a central location. In Windows 95, the System Policy Editor (in conjunction with the Registry Editor) has been developed as the network manager's front-line resource for enabling, disabling, and customizing system capabilities. This article examines user profiles and system policies as they relate to the MIS professional, help desk manager, or network administrator.

On This Page

User and System Management Issues
Windows 95 Registry
User Profiles and the Windows 95 Registry
System Policies: Crowd Control Barriers for Novice Users
Before You Implement User Profiles and System Policies
Conclusion
More Information

User and System Management Issues

The Feature Specification for Windows 95 simplified setup and configuration (Plug and Play), provided an integrated and complete protect mode operating system, improved network client, peer server, and workgroup functionality, and established a robust, mobile, computing environment.

Later beta site studies showed that users understood and appreciated these design elements. In addition, testers were surprised to see high marks also for the improved control that Windows 95 gives MIS managers over their users' desktops.

Diagnosing Configuration Problems the Old Fashioned Way

CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, and SYSTEM.INI—artifacts of Windows 3.1 we all would like to forget. However, you know the support song and dance, so let's reflect on configuration management done the old fashioned way:

  • Path statements resembling novellas

  • Information scattered in all locations WINFILE.INI, PROTOCOL.INI, SYSTEM.INI, MSMAIL.INI, private .INI files, private .GRP files

  • Text-based .INI files limited to 64 KB and APIs that allowed only for get/write operations

  • Several hundred different switches and entries, which practically required a Computer Science degree to configure

  • .INI files that couldn't store user-specific information thereby making multiple user access to computers difficult

  • .INI files made local to each system, sans API mechanisms to enable remote administration

The days of tweaking .INI files came to an end with Windows NT and the concept of a Registry. Windows NT's configuration utility, the Registry Editor (REGEDT32.EXE), used in conjunction with the Windows NT Diagnostics tool (WINMSD.EXE) allowed experienced users the ability to view or edit configuration information stored in the Registry. The Registry made systems easier to manage by acting as a single repository of seemingly random configuration information: computer hardware the system used, system software, and the system's users profiles. Furthermore, the Registry alleviated configuration management and support woes by allowing secure, remote access to user- and system-specific information on networked systems.

Windows 95 Registry

The Windows 95 Registry falls somewhere between Windows 3.1's Registration Database, which stores file associations and OLE registration information, and Windows NT's Registry, which stores hardware settings and installed software information, allows other applications to store configuration data, and completely does away with the plain text files that Windows 3.1 uses.

As comprehensive as Windows NT's Registry, the Windows 95 Registry still processes CONFIG.SYS, AUTOEXEC.BAT, and WIN.INI. Why? Primarily because Win16-based applications expect to find and manipulate the WIN.INI and SYSTEM.INI files to add entries or load unique device drivers.

Besides solving the proliferation and system-wide distribution of .INI files, the Windows 95 Registry simplifies setting system switches, plays a pivotal role in Plug and Play implementation, and, because many of the Win32 Registry APIs use the remote procedure call (RPC), allows remote access to Registry information. In addition to helping placate MIS managers, network querying of information with RPCs enables the custom development of industry PC management mechanisms like Simple Network Management Protocol (SNMP) and Desktop Management Interface (DMI).

User Profiles and the Windows 95 Registry

The Windows 95 Registry is a hierarchically-structured data store of system, user, and policy information organized into two .DAT files: SYSTEM.DAT (PC-specific information) and USER.DAT (user-specific information). When you establish network, hardware, and security parameters, the HKEY_LOCAL_MACHINE portion of the Registry is updated and it in turn updates SYSTEM.DAT. When you establish desktop settings, such as application preferences, screen colors, and security access permissions, the HKEY_CURRENT_USER portion of the Registry is updated and it in turn updates USER.DAT.

When user profiles are enabled, Windows 95 creates a folder for each user in the Windows Profiles directory. Each user profile folder contains a USER.DAT file, a backup profile file, a Desktop folder, a Recent folder, and a Start Menu folder. Windows 95 subsequently creates a separate user profile for each user who logs onto the computer. All of this is performed painlessly by Windows 95 and requires no additional modification or setup; user profiles need only be enabled once.

Note: Because of the Registry's complexity and its central role in the Windows 95 desktop system, it is recommended that changes and settings be established by experienced network managers or help desk staff.

SYSTEM.DAT and USER.DAT Location

You can use the Registry Editor locally or remotely (Figure 1) to read and write values contained in the Registry's User Profile and Hardware Profile. If you want to manage a user or workgroup's PC environment remotely, you can move USER.DAT and SYSTEM.DAT to a server. This also makes it possible to run Windows 95 on a diskless or remote initial program load (RIPL) workstation.

Cc751314.aa0dj(en-us,TechNet.10).gif

Figure 1: : Windows 95's Registry Editor

You can also put SYSTEM.DAT on the PC's local drive and USER.DAT in the user's logon directory on a network server. Remember that if you want to make user profiles available on the network you must ensure that a network home directory exists for each user. This enables users to maintain their network connections and desktop configurations from wherever they log on to the network. In both this case and the first case a copy of USER.DAT and SYSTEM.DAT remain locally in the Windows 95 Profiles folder of the computer. Also, Windows 95 automatically synchronizes both user profile copies each time users log on and off the system.

Finally, you can put the Registry and all other system files on a local hard disk to allow multiple users, with unique logon usernames and user profiles, to share a single Windows 95 PC.

User Profile Settings and Benefits

Enabling user profiles through the Passwords option in Windows 95's Control Panel lets you establish:

  • A custom background and desktop layout

  • Network connections, preferred server, and shared resources

  • Menu, toolbar, and window configuration preferences

When you enable user profiles you click the option Users Can Customize Their Preferences And Desktop Settings in the User Profiles tab. To describe what ought be included in the user profile you check or clear two User Profile Setting options:

  • Include desktop icons and Network Neighborhood

  • Include Start menu and program groups

The first option determines whether desktop shortcuts and the Network Neighborhood are included in the user profile; the second, whether custom settings for the Start menu and the related program groups are included. If you check these boxes, your desktop directory and Start menu will follow you around a network when you logon to different computers. These check boxes modify the SYSTEM.DAT file of the user profile.

If user profile files are established on a network, users can log in from anywhere in the network on any Windows 95 user profile-enabled PC, and bring up their custom-tailored, pre-established desktop environment. The username and logon password trigger Windows 95 to automatically reconfigure the desktop. If specified in the USER.DAT file, Windows 95 also establishes previously-stored network and print resources, and implements directory sharing capabilities on the Windows 95 machine.

For more information on setting up user profiles on Windows NT and NetWare networks, check out two sections in Chapter 15 of the Windows 95 Resource Kit: "Setting Up User Profiles on a Windows NT Network" and "Setting Up User Profiles on a NetWare Network."

The benefits of using user profiles are obvious:

  • Users on the move, like support specialists, help desk managers, or corporate technicians can log onto the network from any Windows 95 32-bit, protected-mode client, and feel right at home on any PC. There is no need to establish new connections to corporate support servers or regain access to normally restricted applications.

  • User profile maintenance is painless. If the User Profile option is enabled, changes to a user's USER.DAT file are maintained automatically whether the user profile is stored locally or remotely.

  • Users who habitually map network directories to the wrong letter, change the 3-D corporate logo background, or forget specific print shares will no longer be support nightmares.

Mandatory User Profiles

You can force users to use specific settings by creating a mandatory user profile, a USER.MAN file, placing it in the user's network directory, hiding the file, and making it read-only. (On a Windows NT network, the network directory is the user's home directory; on a NetWare network, it's the user's mail directory.) When located to the server, USER.MAN settings are downloaded to the user's Registry at logon rather than USER.DAT file settings. Network administrators have the option to enable user override capabilities.

System Policies: Crowd Control Barriers for Novice Users

"PC Computing" editor Matthew Lake suggested that system policies are like:

"...crowd control barriers that keep individual users from wandering off the main road into tech-support wilderness."

System Policies give network administrators comprehensive control over users' Windows 95 PCs. System Policy settings are established in a CONFIG.POL file that is located on a logon server, not a local computer. Settings established in the CONFIG.POL file are maintained on a network server and then copied to a user's local Registry on logon, overwriting settings contained in the USER.DAT and SYSTEM.DAT Registry sections.

Note: Both Windows NT and NetWare networks are supported as network servers; however, consult the section "Preparing to Use System Policies on the Network" in the Windows 95 Resource Kit for information on support for automatic and manual downloading of these files.

To understand system policies it's important to realize how they differ from mandatory user profiles (USER.MAN):

  • System policies are much more comprehensive than mandatory user profiles in that they allow an administrator to mandate both user-specific and computer-specific settings; mandatory user profiles control all user-specific settings only.

  • System policies are much more flexible to use because they allow an administrator to establish a subset of user settings to control and allow the user to control the remaining settings. Mandatory user profiles control every user-specific setting.

Both system policies and mandatory user profiles are ways to mandate user settings. A network administrator may choose to employ both methods. See the "Appropriate System Policy and Mandatory User Profile Use in Windows 95" section of this article to understand when to use either or both methods.

Using the System Policy Editor (POLEDIT.EXE) an administrator can seamlessly set a user's system policies through an intuitive GUI (Figure 2). The editor is located on the Windows 95 compact disc in the \ADMIN\APPTOOLS\POLEDIT directory.

Cc751314.aa1dj(en-us,TechNet.10).gif

Figure 2: : Windows 95's System Policy Editor

The target computer must have user profiles enabled to use system policies and for settings to be established. Take a look at the following system policy settings overview to understand the set of policy options available in Windows 95. These are just some of the system policy settings.

Sample User-Specific Restrictions

Option

Examples

Restrict access to control panels

Hide the Display Control Panel, Network Control Panel, and Passwords Control Panel

Restrict printer settings

Disable deletion of printers and hide the General and Details property sheets for the printer

Define desktop settings

Wall paper and color scheme are predefined

Restrict access to network settings

Disable file and print sharing

Restrict access to shell settings

Hide Start menu subfolders and custom Start menu, remove Run and Find commands, disable Shut Down command, and hide Network Neighborhood

Restrict access to system settings

Disable Registry editing tools, only run allowed Windows applications, and disable MS-DOS prompt

Sample Computer-Specific restrictions

Option

Examples

Enable user-level security

User-level access control through pass-through validation by a Windows NT or NetWare server

Establish custom logon banner

Type values for a caption and text displayed in a logon banner

Microsoft client for Windows networks

Enable participation in Windows NT domain or workgroup

Password settings

Disable password caching and require alphanumeric Windows password

Dial-up Networking

Disable dial-in connections to the computer

Sharing

Disable file and print sharing

The Enable User Profiles option is especially useful. It allows you to set user profiles on a number of networked Windows 95 PCs without going to each PC individually by creating a system policy that can be downloaded automatically when the initial Windows 95 installation is complete—a huge time-saver. Check out the Windows 95 Resource Kit for a complete list of system policy options.

Appropriate System Policy and Mandatory User Profile Use in Windows 95

To understand when to use mandatory user profiles, system policies, or both, we'll examine a number of scenarios.

A configuration in which you want to impose restrictions on many similar nodes is one in which system policies are appropriate. Suppose you're the network administrator of a university with 25,000 student nodes. Maintaining a single, global CONFIG.POL file to enforce network-wide system or user restrictions would make sense. Unlike user profiles, system policy restrictions make available such facilities as removing the Run command from the Start menu, which prohibits users from running applications using the Run command in the Start menu, and Hide All, which prevents users from making any changes to Control Panel or Printer settings. In such a scenario, you could create one policy file for each group of users, even if some of the client computers in the group didn't have group policy support enabled. When creating system policies for groups of individuals, you must ensure that GROUPPOL.DLL, which supports group policies, has been successfully installed on each client computer. See the "Creating Policies for Groups" section in Chapter 15 of the Windows 95 Resource Kit, for further information.

System policies make it easier to maintain an extremely secure, customized, enterprise-wide environment from one central location. For example, five Add Custom options available in system policies (Add Custom Desktop Icons, Add Custom Programs Folder, Add Custom Startup Folder, Add Custom Network Neighborhood, and Add Custom Start Menu) offer administrators an opportunity for customization by defining a program group containing corporate applications, applications that run at system startup, a custom Network Neighborhood, or a custom Start menu with standard choices. The system policy restrictions Disable File and Printer Sharing, Disable Registry Editing tools, and Disable Dial-up Networking are standard safety precautions for most corporate environments unavailable in maintaining just a mandatory user profile.

Mandatory user profiles provide certain functionality that is difficult to establish when using system policies. For example, it is much easier to configure and store Win32 application options like Tool Tips, default formatting options, or other menu options with mandatory user profiles. Using system policies typically means working from a default template, ADMIN.ADM. Unless you custom design your own .ADM template, you are restricted to the default template's functionality. Other Registry keys such as disabling the Online Registration option or the Welcome Screen are much easier to control with mandatory user profiles.

Note: For some specific settings you would have to use Registry Editor against a current USER.DAT, then save the configuration to USER.MAN.

Because you can modify every aspect of a user's desktop with a mandatory user profile, whereas you can only modify a subset of USER.DAT contents with system policies, training or guest accounts might be uses for USER.MAN.

Using both methods helps to address the limitations of implementing one by itself. For example, you could use a CONFIG.POL file together with a USER.MAN to disable the Registry editing tools and change dial-in server support in conjunction with configuring a Win32 application's environment options. Both policies and profiles are designed to be used together so that system managers can deal with special cases and needs.

A thorough needs analysis prior to implementation will help you decide whether to use one method or both. If you decide to use only one method, figure out which involves the least customization to satisfy your needs. Authoring .ADM files or tweaking .INFs can be risky business, even for an experienced Windows 95 user.

Another important limitation to consider is that the System Policy Editor is only available on the compact disc version of Windows 95 and not on the floppy diskette version. Administrators who purchase the floppy version for their site will not obtain other administration tools or help files.

The next section outlines some questions you may want to ask yourself before implementing either of these methods.

Before You Implement User Profiles and System Policies

Now, before you start mandating that all your networked users use MYDOGSPIKE.BMP as a default system background you might want to consider the following issues.

If you're thinking about implementing user profiles:

  • What user-specific or system-specific settings do you need to maintain a secure, supportable PC environment? You don't want users thinking you're Big Brother.

  • Do you want to use system policies for user settings instead of mandatory user profiles? Remember, to use system policies, user profiles must be enabled on the computer. Also consider the scope of control and customization you're looking for.

  • Are traveling users an important reason for user profile implementation? Besides having 32-bit, protected mode network clients, each roving user must have a home directory on the network where user profile files, like USER.DAT, are kept.

  • If you choose to use user profiles, establish whether mandatory user profiles are necessary. A mandatory user profile requires an administrator to copy the necessary files to each user's network directory.

If system policies are more appropriate for your network configuration, consider these issues:

  • What types of restrictions are necessary to enforce? Will you jeopardize user productivity by limiting certain options? Limiting access to the MS-DOS prompt will prevent command line file tampering; however, it might also force unnecessary help desk calls because a user doesn't have the ability to perform a basic support operation.

  • What type of network architecture will you be using? How many servers are in use? How many users are supported? What is the typical logon process? Will you be assigning application availability on the basis of a user's membership in a specific company team: marketing, accounting, system support personnel, or administration? Uniform logon procedures for groups of users in addition to users sharing one computer will also impact decisions concerning system and user customization.

  • Do Windows 95 system policies meet your administration needs? For higher levels of administration, consider using Microsoft Systems Management Server.

Templates

After asking yourself these questions you might want to investigate some system policy templates. The System Policy Editor opens a default policy template on startup. Creating custom templates is helpful because they list only specific policies an administrator ought to consider restricting or setting for a given environment. For example, if you were the lead network administrator in your company you could develop three or four template examples for administrators below you to set. These "second-level" administrators would not have to worry about what parameters to restrict or set, only what degree of restriction or access was necessary. For a detailed example of a Maximum- and a Minimum-Level System Policy template, see the online examples provided with the Windows 95 Resource Kit utilities.

Conclusion

Used responsibly and in conjunction with a logical support and systems management plan, user profiles and system policies offer an effective means to minimizing help desk calls and managing PCs throughout a Windows 95 network.

Note: Microsoft doesn't support changes made to the Windows 95 Registry.

More Information

You can read the following documents for more information on the Windows 95 Registry, user profiles, and system policies.

On TechNet

The following resources are all available on TechNet Disc 1.

Document

Location

Windows NT 3.5 Resource Kit

MS BackOffice and Enterprise Systems; MS Windows NT Workstation; Resource Kit Version 3.5

Windows 95 Resource Kit

Personal Systems; MS Windows 95; Resource Kit

Various Knowledge Base articles

Microsoft Knowledge Base

Elsewhere

Document

Location

Microsoft Windows NT Server System Guide

Not on the TechNet CD. Ships with the product.

Introducing Microsoft Windows 95: The Next Generation of Microsoft Windows

Microsoft Press: ISBN 1-55615-860-2

Inside Windows 95

Microsoft Press: ISBN 1-55615-626-X

Inside Windows NT

Microsoft Press: ISBN 1-55615-481-X

"Windows 95: for Deadheads and Suits"

Lake, Matthew, PC-Computing, Dec. 1994, volume 7, number 12, p62(1)

"Microsoft, Keep Out!"

Raskin, Robin, PC Magazine, June 13, 1995, volume 14, number 11, p30(1)

"Managing Win95 Over a Net"

Harper, Eric, LAN TIMES, April 24, 1995, volume 12, number 8, p126(1)

"It's Better Not to Judge a New OS by its Cover"

Comaford, Christine, PCWeek, April 24, 1995, volume 12, number 16, p22(1)

"A Good Product Just Got Better"

Luoma-Hopson, Casey, Data Based Advisor, Feb. 1995, volume 13, number 2, p26(2)

"How to Ride the Win95 Marketing Wave"

Davis, Dwight B., Windows Watcher, Feb. 1995, volume 5, number 2, p1(1)

"Windows 95 Tool Gives Administrators Control"

Harper, Eric, LAN TIMES, May 8, 1995, volume 12, number 9, p103(2)

"Win 95 Scripts"

Watterson, Karen, Windows Sources, April 1995, volume 3, number 4, p161(3)

"Windows 95: A Distributed Computing Platform"

Goulde, Michael A., Distributed Computing Monitor, June 1995, volume 10, number 3, p34(6)

Microsoft TechNet

September 1995
Volume 3, Issue 9

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft