Each application for MS-DOS and Windows needs its own configuration file; however, Windows NT centralizes program initialization variables and settings parameters in the Registry (a special-purpose operating system database). Again, even Windows NT 4.0 and 3.x have multiuser capabilities, since part of the Registry is user-specific and is referred to as a “user profile.”
User profiles can specify machine settings.
By using user profiles, an administrator can control each user’s desktop, environment, and access permissions whenever a user logs on to the domain from any workstation, whether virtual or real. To create a profile for a particular user, the system administrator must log on as the user or create a “default” user account. For example, if I want to change the wallpaper to circles for some but not all of my users, I create an account named “default” and log on as default. Then I change my wallpaper to circles and save the current environment as a profile named “circles.usr” or “circles.man.” After logging off, I log back on as the administrator and assign the appropriate users the profile “circles.man” or I copy “circles.usr” to a profile named “username.usr” (since a per-sonal profile should be unique to each user).
The ability to create profiles is a huge improvement over the Windows 3.x and Windows for Workgroups days, but it has a major drawback: the profiles don’t allow the administrator to capture environment settings without being logged on to the environment. For example, if I want to change user Jane’s environment so that she has no wallpaper, there is no “switch” in the User Profile Editor to allow this. Likewise, I can’t remove icons from her desktop without either logging on as Jane or logging on as my default profile and changing my desktop (deleting the icons and so on) and then resaving the profile and assigning or copying it to Jane’s profile. The process is rather cumbersome.