Did you ever have to share a Windows 3.1 computer with another user? If you did, you probably were involved in a mini-war over whose desktop configuration would prevail. The scuffle probably included icon and window arrangement, application filenames and locations, and screen colors. The worst case scenario is using someone else's PC. You never know what you'll find or which folders will contain familiar icons, and frequently you grind your gears while getting oriented.
All that frustration went away with Windows NT. When you log on as a user on NT, you automatically access your personal desktop configuration in the form of a profile that NT updates specifically for your user ID. As you see in Table 1, the profile stores the information that defines your working environment, from windows and icons to control panel settings and application preferences. With this setup, all computer users have their own profiles, and no one steps on anyone else's toes.
This article will take you on a tour of user profiles as NT 4.0 implements them. Along the way, you will learn about the types of profiles, how you create and manage them, and how they interact.
Types of User Profiles
All NT computers, even isolated ones, support user profiles. Local
profiles let multiple users share the same workstation while letting them
regain their desktop settings when they log on. NT maintains local profiles
automatically, and the software requires little administrative oversight. When
you connect an NT computer to a network, you can establish roaming profiles
and mandatory profiles, both of which are stored on a network server.
Roaming profiles let you do something really cool: You can take your environment with you. If your computers are connected to a network, they can share the same profile stored on a network server. No matter which computer you log on to, you can pull down your profile and work in the warm, fuzzy environment of your desktop.
Alternatively, administrators can set up mandatory profiles that strictly conFigure users' desktops. That's just the ticket when you want to establish a uniform environment for a large number of data entry clerks, or when you want to reduce support calls because someone has deleted an icon or messed up a setting.
Even after you establish a network profile, NT maintains a profile locally on the workstation, letting the user establish a familiar desktop when the network is unavailable. When you log off the network, NT synchronizes your network and local profiles with copies of the current desktop configuration. Some people refer to this local profile as a locally cached profile.
User Profile Database Structure
The root folder for local profiles is %SystemRoot%\Profiles. After a newly
created user logs on for the first time, NT creates a profile folder structure
for the user in the %SystemRoot%\Profiles folder. You can store network profiles
in any folder. Screen 1 shows an example of a %SystemRoot%\Profiles folder. NT
assigns users subfolders, named to match the username. Additionally, there are
two special profiles named Default User and All Users, which I'll discuss later.
To show all the contents of a user profile folder, I prepared Screen 1 after configuring Explorer to display hidden files and file extensions. The various folders in the profile directory store shortcuts and application preferences that define the user's desktop. Table 2 lists the folders and the settings stored in each. Be aware that some applications may create additional subfolders, which NT includes in the user's profile.
When users log on for the first time, they do not yet have a user profile (unless an Administrator has copied one into the user's profile folder). So where does a user's initial working environment come from? When a user first logs on, NT creates a personal profile folder and initializes the user's environment from the Default Users profile. Consequently, all profiles begin as a copy of the Default Users profile. When the user logs off, NT stores desktop changes the user makes in the user's personal profile.
The All Users profile defines settings that NT assigns to all users who log on locally to this computer and has only two folders: a Desktop folder, which contains desktop shortcuts that appear for all users, and a Start Menu folder, which defines common program groups and their shortcuts. Common program groups and shortcuts are the ones that appear below the line that subdivides entries in the Start menu. (Under NT 4.0, a common program group is simply a group that is stored under Profiles\All Users\\Start Menu. NT 3.51 users are familiar with creating common program groups by declaring the type when the program group is created.)
The folders in the profile store much of the data that constitutes a user profile, but a profile includes other personal settings that a user establishes in the Control Panel. NT stores these settings in the Registry, so you need a different mechanism to include the settings in the user's profile.
User Profiles and the Registry
While a user is working on an NT computer, NT stores the user's personal
settings in the Registry under the HKEY_CURRENT_USER root key. (For an
informative examination of the Registry see Mark Russinovich, "Inside the
Windows NT Registry," April 1997.) Six root keys anchor the six data trees
that make up the Registry. NT stores nonvolatile Registry data in a series of
hives, a term that describes how Registry data is organized.
Each hive consists of two files: a log file and a data file. NT uses the log file as a transaction log when users update the data files, and you can use it to roll back incomplete updates that might corrupt the Registry. The data file for the HKEY_CURRENT_USER hive is Ntuser.dat, and the transaction log file is ntuser.dat.LOG. You will find an Ntuser.dat file in each user's profile directory. You will also find the associated log file, named ntuser.dat.LOG. In Screen 1, hidden files are visible to show you the Ntuser.dat and ntuser.dat.LOG files in the example user's profile.
When a user logs on to NT, the data in Ntuser.dat initializes the HKEY_CURRENT_USER Registry subtree. When the user logs off, Ntuser.dat is updated from HKEY_CURRENT_USER. This point is important and bears repeating: Ntuser.dat is updated only when the user logs off. As you will observe later, this behavior results in a couple of problems where roaming profiles are concerned.
A complete user profile consists of a folder structure in a Profiles folder with numerous shortcut and other files, and the Ntuser.dat Registry hive file caps it off. The Ntuser.dat file has a crucial role in determining how profiles will function once they are stored on the network.
An important point is that some Control Panel settings stored in the Registry are hardware dependent. An example is video display resolution. Consequently, only computers with similar hardware characteristics can share profiles. For instance, you probably would not be comfortable using the same profile on your 21" desktop monitor and your notebook. If computers will be sharing profiles, when you design the profiles you must consider the common capabilities of the workstations that you will use the profiles on.
Moving User Profiles to the Network
Connecting a workstation to the network is a prerequisite to supporting
network profiles, but it isn't the only requirement. First, create a folder on
the server where you will store users' network profiles. Next, create a share
for the profile folder. Finally, conFigure users' accounts with a profile path.
A user's profile folder can be on any network server. You can create one or more profiles folders. This approach is often the best. Storing profiles for groups of users lets you distribute profiles across multiple volumes and servers if necessary. You can store network profiles in the server's profile directory, %SystemRoot%\Profiles. In this case, users who are authorized to log on locally to the server will use their network profiles as local profiles. Or you can store each user's network profile in his or her network home directory, an approach that is complicated by the need to establish a network share for each profile directory.
To demonstrate network profiles, let's use a separately created profiles folder named c:\profiles. After creating the folder, grant the group Everyone Change (RWXD)(RWXD) permission for the directory. This permission lets users create and update their profile.
In this example, users share the profile directory with the share name Profiles$. The $ character is optional, but you can append it to the share name to prevent it from being advertised through network browsers. Users have no reason to connect to this share except through the profile mechanism. The $ doesn't provide any real security, but it prevents confusion that users might have by casually picking the share from a browse list.
The next step is to conFigure the user's account with the profile path. Go to User Manager for Domains, User Properties, and click on Profile. This step takes you to the User Environment Profile dialog box, shown in Screen 2. The universal naming convention (UNC) for the profile path specifies the server, share, and the name of the user's profile directory (e.g., \\nts1\profiles$\Buster).
You can specify the user's profile directory by name, but an alternative is to use the system variable %Username%. This variable is especially useful if you are defining profile paths for multiple users, and it lets User Manager for Domains supply the username for each user account that you're configuring.
Logging On to a Network User Profile
If you perform the steps I mentioned to enable network profile support for a
user, the events that take place when the user logs on depend on whether the
user has previously logged on to the domain. First, if the user has never logged
on, neither a local nor a network profile exists. The sequence of events is as
follows:
If the user has previously logged on to the network, things proceed a bit differently. The distinguishing factor is that a local profile has been created for the user on the local computer. Consequently, in Step 2, NT initializes the user's environment from the user's local profile.
OK, now the user has logged on and has created both a network and a local profile. Which profile will NT use the next time the user logs on? The answer depends on which profile is more recent, as determined by the "last write time" stamps of the Ntuser.dat files. If the network profile time stamp is the same as or more recent than the time stamp of the local profile, the network profile will be used to initialize the user's environment. If the time stamp of the local profile is more recent, the local profile will be used.
The above procedures are all that NT requires to establish a roaming user profile. As you can see, the network administrator does not need to explicitly create the profile folders and files. However, the administrator must create the shared profiles folder, establish the required security, and add the path to the properties of the affected user accounts.
More Than One User Profile
Profile confusion occurs because NT can associate a given username with more
than one profile. NT identifies a user account not by the username, but by a
numeric security ID (SID). Each time NT creates a user account, it assigns the
account a unique SID.
Now let's consider the following scenario. An administrator assigns Buster's computer to a workgroup, and Buster diligently creates a profile that suits him to a T. His company decides to implement NT Server, and the administrator assigns Buster a domain account, equipped with a roaming profile. Buster logs on to the domain and gets his default profile, not the beautiful profile he has labored over. What happened?
The problem is that Buster's workgroup and domain accounts, although they share a username, have different SIDs. As far as NT is concerned, they are distinct accounts with distinct profiles. If Buster logs on to the domain, he gets his domain profile; if he logs on to the workgroup, he gets his workgroup profile. When an administrator creates Buster's domain user account, the SID for the domain account is different from the SID for the workgroup account. Consequently, when Buster logs on to the domain for the first time, NT Server says, "Hmm, a new user. He doesn't have a profile, so he gets the default." NT initializes Buster's desktop using the local Default User profile.
You can observe a user's various profiles in the System applet of the Control Panel. The User Profiles tab, shown in Screen 3, lists the user profiles on this computer. The Name column identifies the domain or workgroup the user belongs to. The Type column shows whether the profile is Local (stored on this computer) or Roaming (stored on the network). We will return to this utility several times in the remainder of this article.
Incidentally, although any user can view profiles in the System applet, standard users see only their own profiles. Administrators see all profiles stored on the local computer.
In Screen 3, notice that the Administrator and Buster have two profiles each. Buster's INFOWORKS profile is a domain profile, and his NTW1 profile is a local profile maintained on the local computer. Because the Administrator account has not been assigned a network profile, this account uses the local profile. Users who have multiple profiles access the appropriate profile depending on whether they are logging on to the domain or to the local machine.
Roaming off the Network
The time stamp issue comes into play if you work on a computer that is
isolated from the network, either because of a network outage or an intentional
disconnection. Suppose that your NT notebook is connected to the network and you
are conFigured to use a roaming profile. You log off, disconnect the computer,
and take a trip, during which NT uses the locally cached profile to set up your
desktop. When you return and connect to the network, your local profile will
have a time stamp that is more recent than the network profile. Which profile
will the system access when you log on?
To find out, let's look at the complete sequence of events. Mabel fires up her notebook in her hotel room. She wants to use her familiar network profile, so in the Logon Information dialog box she logs on to the office domain. Here's what happens:
While working in the hotel (step 4), if Mabel looks at the User Profiles tab of the System Control Panel applet, she will see that NT is accessing her domain profile from the local copy.
WAN Issues
In general, NT profiles do not work well over slow WAN links. In fact,
Microsoft does not recommend using roaming profiles across a slow network link.
Not only does the profile maintenance traffic chew up scarce bandwidth, but
local and roaming profiles can become unsynchronized.
In one scenario, a user logs on via a WAN link that is slow enough to cause NT to time out. Then NT uses the local profile or initializes the user from the default profile if necessary. If the remote server becomes available when the session ends, NT uses the local profile to update the roaming profile.
If users change locations frequently and want to use roaming profiles, Microsoft recommends that you store copies of the roaming profiles on servers at each site. You can use NT Server's directory replication capability to keep the various profile directories synchronized. Alternatively, you can switch users to mandatory profiles, which do not suffer from WAN update trouble because users cannot update them.
Although you log on successfully through a slow link, such as a WAN or a RAS connection, you want to switch from a roaming profile to a local profile. This switch economizes bandwidth utilization and eliminates synchronization errors. To switch to a local profile, go to Control Panel, System, and select the User Profiles tab. Select your roaming profile, and click Change Type. A roaming profile will revert to a local profile. This change appears in the Type column. You can switch back to a roaming profile at the end of the session to update your network profile.
Administrator-created Roaming User Profiles
Suppose you want to provide new users with predefined profiles. You could
visit each workstation in the organization and modify the user's profiles, but
you can establish the user profile locally by copying a predefined profile to
the new user's network profile directory.
The first step is to create the profile that you will distribute. To perform this step, create a separate user account specifically for profile maintenance--I call mine Profile Admin. Log on with this account to a workstation that has profile-dependent hardware characteristics compatible with the computers on which the profile will be used. Then design the profile. Log out to save the profile.
While designing a profile, take care to ensure that any special files--such as wallpapers, screen savers, and applications targeted by shortcuts--you incorporate into the profile are present on the target computer. System files aren't usually a big deal because NT knows where to find them and installs most of them by default.
Applications are a different matter. If the profiles you distribute include shortcuts to applications, the shortcuts must point to valid folders and files. Consequently, you need to ensure that organization standards specify how and where to install applications.
The profile you create will be a local profile. After you design the profile, copy it from the profile administrator's folder to the profile folder of the target user. The procedure to copy a profile is as follows:
You can use this procedure to modify the Default User profile on any workstation. But don't try to update the All Users profile, which has a different structure and serves only locally logged-on users. To modify the All Users profile, use NT Explorer to create folders and shortcuts under the All Users folder.
When you copy profiles for active users, the time stamps can get you into trouble. Suppose that you copy changes to Harold's profile while Harold is logged on. When Harold logs out, NT will save his profile, overwriting the profile you have copied.
Now, suppose that you update Harold's profile while he is working on his PC, but he is not connected to the network. The profile you copy will be time stamped when NT saves it. Harold is working with a locally cached profile, which is time stamped each time he logs out.
Harold returns to the office and connects to the network. His local profile is now more recent than the network profile, and he will probably select the local profile, ignoring all the changes you put in his network profile. To prevent this sequence of events, you may need to update the time stamp on the profile you want to have precedence. You can do so with the Touch utility, which Microsoft includes with the Microsoft Windows NT Resource Kit.
Sharing Roaming User Profiles
In one word, the guideline for sharing roaming user profiles is "Don't!"
Yes, sharing roaming user profiles is possible, but all sorts of confusion can
arise. Any user sharing the profile can change the environment, and this
capability is confusing enough. If you have ever shared a Windows 3.1 computer
with someone who loved to mess around with the desktop, you know how much pain
and suffering sharing can entail.
To complicate matters further, suppose Buster and Harold log on simultaneously with the same roaming profile. Buster logs out first. Because Harold still has the profile open, any changes Buster has made to the profile cannot be saved. When Harold logs off, only his changes are written to the profile. Given the issues that can arise, imagining a solid reason for sharing a roaming profile among multiple users is difficult.
Mandatory User Profiles
The user cannot permanently modify mandatory profiles. Although users can
change their environment after logging on with a mandatory profile, NT does not
save the changes when the user logs out. Consequently, each time the user logs
on, NT will use the same profile.
Because users cannot modify mandatory profiles, they can share these profiles. Mandatory user profile sharing is a great way to establish a standard desktop for many users, perhaps for dozens of employees who take telephone orders. Simply assign the users the same mandatory profile in their user account properties.
Setting up a mandatory profile is embarrassingly easy. First, create a profile, as described earlier in the article, and copy it to the directory you want it in. In the Permitted to use field, specify the user or a group of users who may use the profile. Then, use your favorite tool, such as NT Explorer, to rename the Ntuser.dat file to Ntuser.man.
Windows 95 User Profiles
Although Windows 95 supports profiles, they are incompatible with NT
profiles and are considerably less capable. Win95 profiles include only shortcut
(.lnk) and program information files (.PIFs). Win95 profiles are also less
robust than their NT relatives because they have no fault-tolerance mechanism
similar to the one that the ntuser.dat.LOG file provides. A file named
user.da0 provides a redundant copy of the user.dat file, which is the
primary profile repository, but this file does not provide fault tolerance
through transaction logging and is used only when user.dat is lost or corrupted.
Win95 clients running the Microsoft network client or the Client for NetWare can access roaming user profiles, but these profiles must be stored in the users' home directories. The User Profile Path property of the user account is not used. Although mandatory profiles are supported for Win95 clients, mandatory profiles cannot be shared. You must create a separate profile for each user. To create a mandatory Win95 profile, rename the user.dat file to user.man.
NT's user profiles let administrators conFigure the user's network environment. This feature is helpful if security dictates complete or partial control, or if users are not quite up to speed with their system. NT helps ensure that users will log on to the correct desktop configuration every time.
