User Profiles

Profiles represent user settings on Windows Server 2003. They include desktop settings or user preferences for conventional Windows applications. A standard Windows Server 2003 saves these settings for each user in an individual data structure that you can find in the systems folder under \Documents and Settings\< Logon Name >. Each user logon name, and thus each user profile, is unique. If a local logon name and a domain logon name are identical, the domain name is added to the logon name (Logonname.domainname), thus creating two different profiles.

Folder Hierarchy

A user profile s folder hierarchy contains application data, desktop settings, information on the print environment, user files, local settings, neighborhood computers in the network environment, individual start menu expansions, and specific information about installed applications, such as Internet Explorer.

Let us first take a closer look at this folder hierarchy and a typical user profile.

Application Data Hidden folder with application-specific information.
Cookies Internet Explorer cookies.
Desktop Configuration of the graphical user environment.
Printhood Hidden folder for printer configuration.
My Documents Default location to save user files.
Favorites Windows Explorer favorites.
Local Settings Hidden folder containing application data, temporary files, and history.
Nethood Hidden folder containing network information about neighboring computers.
Send To Hidden folder containing links for the Windows Explorer Send To context menu.
Start Menu User-specific files and start menu application links.
Templates Template files.

Windows Special folder for terminal servers, usually containing application- specific configuration and log files.

Note	Some user profile folders are hidden, which means that they are not displayed in Explorer. However, this is no real obstacle to the experienced user and should not be seen as a strict security measure.

Another essential user profile element is a hidden file named Ntuser.dat in the profile directory root. At logon, Ntuser.dat is the data container for individual entries in the Windows Server 2003 registry database. (See also Chapter 6.)

Ntuser.ini, another hidden file, contains the list of files excluded from the user profile. These folders are excluded if the profile is saved centrally on one server. For this reason, it is possible to limit the amount of data transferred to the server. Entries in this file are usually generated through a Group Policy under User Configuration\Administrative Templates\System\User Profiles: Exclude directories in roaming profiles.

So exactly how is a profile generated? When a user logs on for the first time (or after his or her prior profile has been deleted), a new profile is generated using the general Default User template. When the user logs off, the profile and its individual settings are saved under \Documents and Settings\< Logon Name >. At the next logon, the profile is reloaded and provides the settings of the user s previous session.

Roaming Users

A user who normally works with Windows 2000 Professional or Windows XP will arrange views, icons, and links to applications according to his or her personal taste. All this individual information is saved in a local profile and is applied the next time the user logs on.

Administrators of domains with roaming users are aware that these settings are no longer available if the user logs on to another workstation. To get around this problem, the developers of Windows NT created the option to save user profiles in one central location of the network. When a user logs on, his or her individual profile is invoked through a server. The path to the server-based profile can be configured through user administration.

Tip	It is recommended that profiles for roaming users be kept as small as possible, for example, by excluding the temporary directory from the profile and shifting the My Documents and Application Data files to a network drive.

When a roaming user logs on to a terminal server, the server-based profile would become valid for the remote session s desktop. This, however, can result in invalid links to programs installed locally on a Windows XP workstation that are not available in the terminal server session. This in turn leads to problems such as incorrectly displayed icons or error messages on application start.

To avoid these problems, you can enter a special profile path on the terminal server that is not linked to the normal profiles (as mentioned earlier in this chapter). This procedure ensures that a user s profile settings for logon to a terminal server are different from the ones for logon under Windows XP. It also simplifies using different paths to the required applications in a corporate environment.

When a user logs on to a terminal server, profiles are loaded in a predefined sequence, as follows :

If a corresponding configuration was established in user administration, the Terminal Services profile is loaded.
If there is no Terminal Services user profile, the server-based profile for a roaming user is loaded. If a locally cached and current server-based profile exists, it is loaded. Otherwise, the user session loads the server-based profile from the network share.
Only if the user does not have a server-based user profile is the local profile loaded (which is not identical to the cached server-based profile). However, in this case, the user is no longer a roaming user.

After the server-based profile has been loaded from the network, it is cached locally on the terminal server s hard drive. All changes to the user profile are managed through the local copy. When the user logs off, these changes are transferred to the corresponding, centrally managed profile. Under certain circumstances, it is recommended that the local information be deleted as soon as the user logs off. One such circumstance is if several load-balanced terminal servers provide sessions for a large group of users. In the course of time, all user profiles are collected on all terminal servers without necessarily representing the most current status. Required disk space is quite large without really being advantageous ”the user profiles probably have to be transferred time and again from the central server. With voluminous profiles and low network speed, logon takes a lot longer when copying a complete profile instead of accessing locally saved ones.

The most effective way to avoid getting cached profiles is to delete them through a Group Policy as soon as the users log off the terminal server. The central version of the profiles should be saved on a file server with sufficient hard-drive space. You access the file server through an exported directory. One condition is, however, that it be integrated into the domain. Furthermore, the terminal servers must be configured largely the same in terms of operating system and applications to share profiles.

Mandatory Profiles

A mandatory profile is a variant of the server-based profile. You just need to rename the Ntuser.dat file of an existing profile to Ntuser.man. This type of profile can now be allocated to one user or even a group of users. The data contained in a mandatory profile is loaded from the server when the corresponding users log on. However, they cannot change the mandatory profile data when they log off. This means that all individual changes made during a user session are lost on logoff .

What does this concept have to do with terminal servers? It can help solve a problem that occurs quite frequently in larger terminal server environments: if one or two terminal server farms are set up with different sets of applications, profile conflicts are sure to follow. When a user with a single server “based profile logs on to one terminal server on each of the two farms, the individual settings on both servers might be modified. When the user logs off the first terminal server, the related profile is saved on the profile server. When the user logs off the second, differently configured user session, this profile is saved as well ”and might overwrite some of the data changed in the first user session. Therefore, the easiest solution is a mandatory profile that contains all information relevant to both server farm configurations. To avoid losing individual setting changes (for example, changing the default printer), logon and logoff scripts must manage all corresponding data.

Using mandatory profiles and script mechanisms for differently configured server farms is one of the less trivial tasks of an administrator. This type of concept requires thorough planning and implementation. You will find further information on this topic in Chapter 6, Chapter 7, and Chapter 11.

Ini Mapping and Temp Mapping

The profile folder structure comprises another folder that is essential for using Terminal Services. This folder is named WINDOWS and contains user-specific versions of ini files that are mostly used by 16-bit and older 32-bit Windows applications. A terminal server session prompts this type of Windows application to load its configuration data from the user profile WINDOWS folder. If the data is not there, it is loaded from the usual place, the system directory (normally C:\WINDOWS for Windows Server 2003). The configuration that was changed during a Terminal Services client session is always saved to the user s profile folder. The original ini file never changes. Thus, ini files are individualized even though the corresponding application was not developed for a multiuser environment.

Important

The procedure described above is referred to as ini-mapping and is an effective method for making older applications usable for multiple users. The default path to the ini files can vary in the available Microsoft operating systems. The applications usually invoke it through the %WinDir% environment variable for installation procedures and all ini file accesses . Nevertheless, ini mapping and the resulting user profile access lead to a slightly different behavior in terminal servers. The path in %WinDir% is used only when the application is installed and first used.

This type of user-specific ini file administration is maintained under Windows Server 2003 using the % Temp % and % Tmp % variables . In a terminal server s %Temp% folder, you will never find the wild mix of all the users temporary files, as in Windows NT 4.0. Starting with Windows 2000, temporary files have been managed by the user profile and its \Local Settings\Temp folder. The complete temp path for a user who is an administrator might therefore be C:\Documents and Settings\Administrator\Local Settings\Temp. Depending on the terminal server s configuration, the temporary directory path may be supplemented by a session ID. This allows a user to log on several times and use temporary files for each individual session.

Important

Setting up individual temporary directories is very important if you want to run standard applications securely. For instance, the documents loaded last by Microsoft Office Word can be rebuilt from the temporary data after a runtime error. If it were possible to inadvertently access other users temporary files on a terminal server, the documents would end up with the next user who logs on and not with the actual document owner.