User Profile Design: A Primer

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.

This article tries list the dos and don’ts that need to be considered when creating a user profile design. It focuses on functionality built into Windows. Third-party solutions that replace or complement the operating system’s capabilities will be the topic of future articles.

Choosing the Right Profile Type

You basically have three options:

• Mandatory profiles:
  • Typically one pre-configured profile for many users.
  • Although during a session changes can be made, they are discarded. When the user logs on the next time, the locally cached copy of the mandatory profile is reset (replaced with the network copy).
  • The path to the mandatory profile needs to be assigned to users (see below).
  • Useful mainly for kiosk systems.
• Local profiles:
  • One profile per user per machine.
  • No dependency on the network.
  • Since the profile is available locally, logons are very fast.
  • No configuration is necessary, local profiles are assigned to users automatically.
  • Backing up local profiles is often a challenge, because the profiles are distributed across many machines with potentially slow and/or only intermittent network connectivity.
  • Another difficulty is how to transfer local profiles between computers, which becomes necessary when machines are replaced.
  • Useful for users who do not switch computers often or for computers without permanent network connectivity, like laptops. In terminal server environments local profiles should not be used since users are directed to an arbitrary (the least loaded) server when they launch a new session.
• Roaming profiles:
  • One profile per user.
  • The master copy of the profile is stored on a file server. During logon, it is copied to the local machine, which may slow down logons considerably depending on profile size and network speed.
  • During logoff, changed files are copied back to the master copy on the file server. Since a user’s registry hive is stored in a single file, this approach creates the “last writer wins” problem.
  • The path to the roaming profile needs to be assigned to users (see below).
  • Useful for most setups where local profiles cannot be used.

Profile Versions

So far, Microsoft has implemented two incompatible versions of user profiles.

V1 profiles are used on all versions of NT up to XP and Server 2003. They contain folders specific to the language of the operating system (e.g. “Application Data” in English and “Anwendungsdaten” in German).

V2 profiles are used by Vista and newer versions of Windows. Folders names are not localized, but V2 profiles still contain localized directory junctions for compatibility reasons. Junctions do not roam across machines, though. Instead, they are created on each computer individually.

Please bear in mind that the handling of user profiles has not changed very much over the years, only their directory structure. For example, V2 profiles are affected by the “last writer wins” problem just as much as V1 profiles.

Microsoft lists the differences between V1 and V2 profiles in a white paper. Please note that it contains the following error: The folders “My Music”, “My Pictures” and “My Videos” are not located in the root of V1 profiles, but in the folder “My Documents”.

Choosing the Right Number of Profiles per User

Since a user profile contains not only settings specific to the versions of the operating system and the applications installed, but also to the configuration of OS and apps, profiles cannot be shared across platforms. I define “platform” as the set of OS and applications installed in conjunction with their configuration. For example, the location of the program files folders might differ between platforms or the versions of some applications or even the plug-ins installed for programs like Microsoft Office.

Rules of thumb:

1. Use as few profiles per user as possible, but as many as necessary.
2. Use one profile per platform.
3. Use different profiles for 32-bit and 64-bit versions of Windows. Microsoft does not support profile sharing between x86 and x64.
4. Do not use the same profile on workstations and terminal servers.
5. V1 and V2 profiles are not interchangeable, e.g. you cannot use Vista profiles on XP and vice versa.
6. To overcome the “last writer wins” problem, use one profile per silo in terminal server farms.

Terminal Services vs. “Normal” Profile Paths

Windows uses two different profile paths, depending on whether the computer has terminal services installed or not. On terminal servers, the TS profile path is determined first. If it contains a path (i.e. is not empty), Windows will use that path. If the TS profile path is not configured (i.e. is empty), Windows falls back to using the “normal” profile path, which is solely used on all machines without terminal services. Please note that the profile itself need not exist, only the path to the profile is relevant.

Assigning User Profiles

There two ways roaming profile paths can be assigned to users:

• Using group policies, specifically per-machine settings:
  • “Windows Components\Terminal Services\Terminal Server\Profiles\Set path for TS Roaming User Profile” sets the TS profile path [available since Server 2003]
  • “System\User Profiles\Set roaming profile path for all users logging onto this computer” sets the normal profile path [available since Vista]
• In the attributes of Active Directory user objects. Both the TS and normal profile paths can be set here. These settings are honored at least since Windows 2000.

If profile paths are configured both in the user object and via policy, the settings from the GPO override the user object.

As a general guideline, assigning profiles via policies is preferable. As per the above list, this does not work on terminal servers that run Windows 2000. Neither do Windows XP clients know anything about these settings. If you need to configure roaming profiles for these operating systems, you only have one option: configure each Active Directory user account individually.

To Redirect or not to Redirect

Certain well-known folders can be redirected from the user profile to any location on the network, though the home directory is usually the most sensible target. Once a folder is redirected, each read/write/open request to any file in that folder and all sub-folders will go over the network to a file server. For that reason redirection has the following major drawbacks:

1. Network utilization is much higher.
2. The load put on the profile file servers can be much higher.
3. The latency of file I/O is increased, slowing down applications and potentially making them feel sluggish to the user.

On the other hand,

1. redirecting folders containing large files or even large numbers of small files can greatly reduce logon times in environments where roaming profiles are not cached locally (i.e. most terminal server farms), and
2. the effects of multiple profiles per user are mitigated since folders are typically redirected to a single location per user.

Some More Advice

1. Vista and newer OSs always append “.V2” to the roaming profile path. Not keeping this in mind can be a major source of frustration when debugging profile problems.
2. You want to assign one profile per silo, but there is only one attribute for the TS profile path in the AD user object? Use system environment variables set in each silo differently, and specify the path to the profile like this: “\\FileServer\ProfileShare\%UserName%\%SiloName%”.
3. You need to distribute profiles across file servers to spread the load? Either use DFS namespaces to create a link for each user profile in one single DFS folder, or specify the profile server per user by setting the path in the attributes of each user object appropriately.
4. Useful group policy settings:
   • “System\User Profiles\Add the Administrators security group to roaming user profiles” should be enabled to facilitate support. Otherwise, administrators will have no access to roaming user profile folders.
   • “System\User Profiles\Delete cached copies of roaming profiles” should be enabled in terminal server farms with more than 3-6 servers because the chances that a user gets directed to the same machine twice in a row is the lower, the larger the number of terminal servers. On workstations, this should be enabled only if there is no fixed assignment of machines to users.
   • “System\User Profiles\Do not check for user ownership of Roaming Profile Folders” should be enabled since the permissions (not only ownership!) check that is performed by default increases the probability of support incidents.