Managing User Data in a Windows Server 2008 R2 Remote Desktop Services Deployment

• How Profiles Work

• Design Guidelines for User Profiles

• Deploying Roaming Profiles with Remote Desktop Services

• Profile and Folder Redirection Troubleshooting Tips

Thus far in this book, you have learned how to set up a single Remote Desktop (RD) Session Host server or a simple Microsoft Virtual Desktop Infrastructure (VDI) deployment. Those deployments aren’t yet production-ready, though: No applications are available, the connections aren’t secured, you haven’t yet defined the devices and experience to redirect, and the profiles and Folder Redirection aren’t yet set up.

Properly configured profiles and Folder Redirection go a long way toward a good user experience for users working via remote connection to the data center. Because profiles weren’t originally designed for remote work environments, this can sometimes be tricky. Remote Desktop Services (RDS) independent software vendor (ISV) partners have developed some products to help make a highly flexible system for complex environments. This chapter, however, shows you how best to configure profiles and Folder Redirection using the tools that come with Windows.

The basic elements of a user workspace are the configuration settings in the user’s profile and the default locations to save data. After reading this chapter, you will understand the following.

• How roaming, local, and mandatory profiles work

• Why virtualization can complicate implementing profile strategies

• Best practices for storing and managing profiles

• How to use Folder Redirection to unify user default locations between local and remote applications

• The benefits and drawbacks of using mandatory profiles to maintain a consistent look and feel

• How to secure the desktop to prevent users from saving files to it and why this is important

• How to support profiles across servers running both Windows Server 2008 R2 and Windows Server 2003, or Windows 7 and Windows XP virtual machines (VMs)

How Profiles Work

A profile is a collection of settings and documents that define a user’s work environment, sometimes referred to as a user’s “personality.” A user’s profile includes both configuration data and personal data such as documents and pictures. Personal data in the profile can be stored on the desktop or in one of the folders associated with the user account (for example, My Documents). The profile also includes user specific settings, such as the following.

• Changes that you make to application layouts, such as adding buttons, changing the layout, and adding a default signature

• Changes to system settings that are unique to the user experience, such as changing your desktop background, screen saver, and keyboard layout

Machine-wide settings such as firewall settings are not stored in the user profile.

Documents and supporting files that are part of your profile are stored in a unique user profile folder (and subfolders). Local and roaming profile settings are stored as a single file (called NTUSER.DAT), not as a collection of individual settings. NTUSER.DAT is stored in the root of each user’s profile folder. Mandatory profile settings are stored in NTUSER.MAN; this file can be shared among multiple users because it is read-only.

While a user is logged in, the NTUSER.DAT file is loaded temporarily into HKEY_CURRENT_ USER (HKCU) in the registry of the computer that user is logged on to; the documents are stored in the subfolders within the profile folder, as shown in Figure 5-1. You will find out in detail about the parts of a profile—both the registry and the data folders—later in this chapter. But first let’s examine the different types of profiles.

Types of Profiles

As alluded to in the previous section, there are three types of profiles: local, roaming, and mandatory. Local profiles are stored on and used from a single computer and store data in NTUSER.DAT. Roaming profiles are stored on and used from a network share, so they’re available to any computer that can access that particular network share. They also store data in NTUSER.DAT. Mandatory profiles are often centrally located like roaming profiles, but whereas local profiles and roaming profiles are read-write, mandatory profiles are read-only. They store their settings in NTUSER.MAN.

Local profiles are usually fast to load because they are stored on the computer the user is using. When a user logs on, the local profile will load from its local location on the hard drive and populate HKCU. When the user logs off, the contents of HKCU (including any changes that the user made) will be written back to the local hard disk and overwrite the previous version of the file.

Roaming profiles afford the most flexibility in a remoting environment because they’re stored in a central location accessible to all VMs and RD Session Host servers. They’re also read-write, so users can adjust their settings. When a user logs onto a session or VM (or a computer, for that matter), the roaming profile will load from its network location and populate HKCU in the registry. When the user logs off, the contents of HKCU (including any changes that the user made) will be written back to the network location and overwrite the previous version of the file.

Mandatory profiles are loaded to HKCU when a user logs on, just like a roaming profile, but they aren’t written back to their storage location at logoff—all changes to the profile are just discarded.

How Profiles Are Created

A user does not start with a user profile. The profile is created the first time that a user logs onto a machine. Mandatory profiles are the exception to this, and even the mandatory profile, which is used by multiple people, has to initially come from somewhere. To fully understand profiles, you need to know how profiles are initially created. This will come in handy later in this chapter, when you learn how to create a mandatory profile and also how to customize a default profile.

All profiles are created from a “default profile.” Each RD Session Host—actually, every computer—has a local default user profile (located at C:\Users\Default in Windows Vista and later) for this purpose. Depending on which type of profile will be used and how you have implemented the profile strategy, the process of making user profiles varies slightly.

If your users will use local profiles (for instance, if you have only one RD Session Host), new user profiles will be created by making a copy of the local default profile located on the computer that the user logs on to. This copy will go into a new folder labeled by the login name of the user.

If your users will use roaming profiles, when a new user logs on to a server for the first time, a new profile is created for him by making a copy of a default user profile. Domain joined computers will first look for a network default user profile (stored in the netlogon share on a domain controller and replicated to other domain controllers). If it does not find one in the network share, then it will use the local default profile located on the computer to which the user logged on.

User Profile and the Registry

The registry is organized into sections called keys, which align with a particular configuration option. For example, computer-wide settings are stored in HKEY_LOCAL_MACHINE (HKLM), whereas user-specific settings are stored in HKEY_CURRENT_USER (HKCU). As with all versions of Microsoft Windows NT since it was first released, Windows Server 2008 R2 and Windows 7 maintain user-specific settings in HKCU for each user logged on to the computer.

You can see how HKCU works and reflects changes to the user environment by following the process outlined in the following How It Works sidebar, “Observe How Changes to the Environment Are Reflected in the Registry.”

In Windows Server 2008 R2 and Windows 7, HKCU contains the subkeys described in Table 5-1. Even if you’re logging on to a Windows Server 2008 R2RD Session Host server from an earlier operating system such as Windows XP, the profile in the RD Session Host session corresponds to the server platform. These are still the registry keys that apply to the session, not the client computer operating system. There might be additional subkeys in this section; it depends on which applications you have installed. For example, if you install Microsoft Outlook, you’ll see an Identities key.

Table 5-1 Subkeys of HKCU in Windows 7 and Windows Server 2008 R2

Subkey	Description	Maps to
AppEvents	Sounds played on system events.	Control Panel\Sounds
Console	Command window settings such as window size, colors, and buffer size.	Command Prompt\Properties
Control Panel	User desktop appearance settings, mouse and keyboard settings, power policy, and accessibility.	Control Panel
Environment	Environment variable definitions.	Control Panel\System\Advanced
EUDC	Customized characters that users install for viewing and printing documents when standard fonts don’t support them. Applies to East Asian font sets.	Control Panel\Fonts
Keyboard Layout	Edits the keyboard layout. Useful if your operating system is displaying in one language but you want to use the keyboard layout of another one (for example, displaying in English but arranging the keyboard as though you were in Germany).	Control Panel\Regional and Language Options
Network	Network drive mappings and settings.	Control Panel\Networks
Printers	Printer connection settings.	Control Panel\Printers
Remote (Remote Access in Windows 7)	Contains settings to be applied to remote sessions (for example, ClearType or wallpaper) for each session. The subkey corresponds to the Session ID.
Session Information	Information about the current session, such as how many applications are open.	Not stored—populated during the session
Software	Personal settings for all software installed for that user.	Individual applications
System	Contains the current control set for that user (drivers and services to run at startup).	Not stored—populated on startup
Volatile Environment	Environment variables for the current logon session.	Not stored—populated for each session

Data is stored in HKCU only for the duration of the session, while data stored in HKLM persists until the reboot. Most pieces of the registry are saved in files called hives and are loaded as necessary. When a hive file is opened, it’s reloaded into the registry. Therefore, HKCU is stored as a hive in a file called NTUSER.DAT that is loaded at user logon. Each user logged on to an RD Session Host server sees his or her own version of HKCU.

How does this data get loaded? When you log on to a computer, the User Profile Service loads the hive file from the location specified in your user account properties and populates HKCU for that session. When you log off the computer, the hive file is written back to its storage location as NTUSER.DAT. If you happen to be logged on to more than one computer at a time, two copies of your profile will be open, populating the contents of HKCU on each computer.

In addition to loading HKCU with the contents of your profile, logging on to an RD Session Host server updates two parts of HKLM, the computer-wide section of the registry. HKLM\ Software\Microsoft\Windows NT\CurrentVersion\Profile List (Figure 5-2) contains a list of all profiles cached on the computer. It also lists the profiles used by the System account, Network Service account, and the Local Service account. As you can see, machine accounts have profiles just like user accounts do.

The users are identified by security identifiers (SIDs), but you can distinguish them by browsing the keys. The values show the path to both the local cache (the ProfileImagePath key value shown in Figure 5-2) and to the roaming profile folder share (the CentralProfile key value shown in Figure 5-2), so it’s not hard to map user names to profiles.

When you log off an RD Session Host server, the two keys with your SID are locked. They don’t actually go away, but if you attempt to open the key associated with a user who is currently logged off, you’ll get an error message telling you that the system cannot find the file specified. Log on again, and the key with the same SID will be repopulated.

Although loading a profile adds two keys to the registry that never go away, most of the time it doesn’t matter. As discussed in the section entitled “The Consequences of Deleting a Profile Folder from Windows Explorer” later in this chapter, it does matter should you choose to delete a profile. Deleting the file doesn’t delete the registry keys associated with it. Therefore, always use the correct tools to delete profiles; otherwise those users won’t be able to load their profiles properly when they log on again.

How Profile Changes Are (Not) Merged

The operating system loads the contents of NTUSER.DAT into HKCU at logon and saves back to NTUSER.DAT at logoff, in the same way that you might open a Microsoft Word document when you log on, type in it for a while, and then save the document when you log off. This has some important implications for a remote environment.

As an example, imagine this scenario: You are logged on to two different computers and you open a new Word document in each session. In Session 1, you type “Every Good Boy Does Fine.” In Session 2, you type “All Cows Eat Grass.” You save the file in Session 1 as Myfile. docx. Next you save the file in Session 2 as Myfile.docx in the same location, confirming that you want to overwrite the old file when prompted.

The next time you open Myfile.docx, the file will say only “All Cows Eat Grass.” The phrase “Every Good Boy Does Fine” has been overwritten. In short, the files are not merged; they’re written back to the save location, and the version last written to that location is the only one you’ll see.

So it is with profiles, which are just another type of file. If you log on to two sessions, each of which is using the same roaming profile, you will have two copies of your profile open. If you make changes to the open profile, you’ll see them at the time, but they won’t be saved into NTUSER.DAT until you log off. (Unlike the Word .docx file, the file system won’t ask if you want to overwrite the profile file.) As in the previous example, if you have a profile open in Session 1 and in Session 2, log off Session 1 and then log off Session 2, only the changes made to the Session 2 copy of the profile will appear when you log on again and reload that profile. The only difference from the document scenario is that the operating system won’t ask you if you want to overwrite the previous version.

You might be wondering whether opening two RemoteApp programs from a single RD Session Host server opens one or two copies of your profile. The answer depends on the version of Windows Server hosting the session, and how you’re starting the applications. On a terminal server running Windows Server 2003, you could create a Remote Desktop Protocol (RDP) session that would open a single application instead of displaying the entire desktop. (As noted in Chapter 1, “Introducing Remote Desktop Services,” not many people did this because the experience wasn’t very user-friendly, but it was possible.) If you presented individual applications this way, then each time a user opened an application on the same server, he would open a separate session and therefore a separate copy of the profile.

Windows Server 2008 improved on this design in two ways. First, it introduced RemoteApp programs. All RemoteApp programs started from the same server by the same user account run in the same session, so they open only a single copy of your profile. Second, when deciding where to route incoming connections to an RD Session Host server farm, the RD Connection Broker will check to see if a user already has an open session on an RD Session Host server in the farm. If it does, then the user will be routed to the same session to start the application. So, what is the result? You have preference to the server where you already have an open connection, and, so long as you’re connecting to only a single server, only one copy of the profile will be open because all RemoteApp programs will run in the same session.

Profile Contents External to the Registry

Not all parts of a profile are stored in HKCU. The same folder that contains the NTUSER.DAT file also contains other folders that contain user data as well as application-specific data. In Windows Vista and Windows Server 2008, the profile includes the folders listed in Table 5-2. (More folders might be available, depending on which applications you have installed.)

Table 5-2 Folders Associated with a Windows 7 or Windows Server 2008 R2 Profile

Folder	Description
AppData	Default root location for user application data and binaries.
Contacts	Used to store contact information and is also the address book for Windows Mail, the successor to Microsoft Outlook Express (Windows Mail is not included in Windows 7 or Windows Server 2008 R2).
Desktop	All items stored on the desktop, including files and shortcuts.
Documents	Default root location for all user-created files (spreadsheets, text documents, and so on).
Downloads	Default location for all files downloaded using Windows Internet Explorer.
Favorites	Bookmarked Uniform Resource Locators (URLs) in Internet Explorer.
Links	File and folder shortcuts; these show up under the Favorites menu on the left side of an Explorer window.
Music	Default root location for all music files.
Pictures	Default root location for all image files.
Saved Games	Default location for saved games.
Searches	Default location for saved searches performed from the Search Programs And Files input box on the Start menu.
Videos	Default root location for all video files

Beginning in Windows Vista and Windows Server 2008, the profile structure changed from Windows XP and Windows Server 2003. (Windows 7 and Windows 2008 R2 retain this new profile structure.) The new structure uses more folders to organize the data.

Notice that Windows XP and Windows 2003 were not mentioned in Table 5-2. This is because profiles have evolved over time and the structure of profiles has changed. Windows XP and Windows Server 2003 profiles are called version 1 (V1) profiles; profiles using the structure of Windows Vista and Windows Server 2008 and later are called version 2 (V2) profiles. A V2 user profile folder is distinguished from its predecessors by an added .V2 extension.

Version 2 profiles generally use more folders than those of Windows XP, but V1 top-level folders such as NetHood and PrintHood were moved inside the AppData folder beginning in Windows Vista. Table 5-3 (adapted from the Microsoft document “Managing Roaming User Data Deployment Guide” located at http://technet.microsoft.com/en-us/library/cc766489(WS.10).aspx) shows the differences in the default root profile folder structure between V1 and V2 profiles.

Table 5-3 Profile Folder Structures of V1 and V2 Profiles

V2 Profile Folders (Windows Vista and Later)	V1 Profile Folders (Windows Xp and Windows Server 2003)
Now AppData\Roaming	Application Data
Contacts	Not Applicable
Desktop	Desktop
Downloads	Not Applicable
Favorites	Favorites
Links	Not Applicable
Documents	My Documents
Music	In My Documents
Pictures	In My Documents
Videos	Not Applicable
Saved Games	Not Applicable
Searches	Not Applicable
Tracing	Not Applicable
Now in AppData folder	My Recent Documents
Now in AppData folder	NetHood
Now in AppData folder	PrintHood
Now in AppData folder	Send To
Now in AppData folder	Start Menu
Now in AppData folder	Templates
Now in AppData folder	Local Settings
Now in AppData folder	Cookies

As you might have noticed in Table 5-3, the Local Settings folder from V1 profiles does not exist in V2 profiles, and many V1 profile folders are now consolidated under the AppData folder in V2 profiles. Why does this reorganization of data matter?

One big accomplishment of the V2 profile reorganization is that machine-specific data is now separated from user-specific data. V1 profiles kept machine-specific and user-specific data scattered through the profile. V2 profiles sort this data and do a better job of separating user-specific data from data that is either too large to roam with the user or is specific to a particular machine and therefore should not roam.

In V2 profiles, the AppData folder now has three subfolders that separate this kind of data.

• AppData\Roaming Data that is user-specific and should roam with the user profile

• AppData\Local Data that is either machine-specific or too large to roam with a user’s profile folder, for example, an Outlook .OST file

• AppData\LocalLow Data for “low-integrity” apps (such as browser-based apps) to store data

Table 5-4 (which was adapted from the Microsoft “Managing Roaming User Data Deployment Guide”) shows where certain V1 profile data is stored in the V2 profile structure.

Table 5-4 Data Storage Reorganization from V1 to V2 Profiles

V2 Profile Data Locations	V1 Profile Data Locations
...\AppData\Local	Local Settings\Application Data
...\AppData\Local\Microsoft\Windows\History	Local Settings\History
...\AppData\Local\Temp	Local Settings\Temp
...\AppData\Local\Microsoft\Windows\Temporary Internet Files	Local Settings\Temporary Internet Files
...\AppData\Roaming\Microsoft\Windows\Cookies	Cookies
...\AppData\Roaming\Microsoft\Windows\Network Shortcuts	NetHood
...\AppData\Roaming\Microsoft\Windows\Printer Shortcuts	PrintHood
...\AppData\Roaming\Microsoft\Windows\Recent	Recent
...\AppData\Roaming\Microsoft\Windows\Send To	Send To
...\AppData\Roaming\Microsoft\Windows\Start Menu	Start menu
...\AppData\Roaming\Microsoft\Windows\Templates	Templates

Because V1 profiles and V2 profiles are so different, you can’t use the same profiles for Windows Server 2008 R2 RD Session Host servers that you did for terminal servers running Windows Server 2003or Windows XP VMs. The structures of the profiles don’t match.

You’ll learn later in this chapter how to allow Windows Server 2003 and Windows Server 2008 profiles to coexist. (See the section entitled “Sharing Folders Between Windows Server 2003 and Windows Server 2008 R2 Roaming Profiles” later in this chapter.) This is important both for supporting mixed deployments of terminal servers running Windows Server 2003 and Windows Server 2008 R2 RD Session Hosts, and for supporting Windows 7 VM pools and Windows XP VM pools. (The changes to the profile structure between the operating systems are one reason why you should not combine Windows 7 and Windows XP VMs in the same pool.)

Introduction to Folder Redirection

Although these data folders are stored by default in the user’s profile folder, they don’t have to be. In fact, in most cases, it’s best if some of them aren’t. Here’s why.

First, keeping user data within the profile folder increases the profile size. Assuming that you’re storing profiles on a central share instead of on individual RD Session Host servers (and, for reasons you’ll see shortly, this is a good assumption), this can slow logons. A large profile increases the time that it takes for users to log on and log off (because the data in the profile must be cached on the RD Session Host server). In Windows Server 2008 R2, if the profile cache on a server exceeds the quota allocated to the profile cache, it will delete the most recently used profiles, but there’s still no reason to fill the cache with user data.

Second, if you’re using mandatory profiles and you don’t redirect folders outside the profile folder, users will not be able to save files to the standard personal folders such as Documents. The files will look like they’re saving, but they won’t be retained. This will cause users a great deal of grief and bring you many unsolvable calls to the Help desk.

The third reason applies to VMs, whether pooled or personal. In the case of a personal desktop, saving files locally preserves them, but it complicates file restore because the files are stored in the VM. To restore the files saved on the local VM, you’d need to restore the VM from backup. Saving the files separately makes it easier to restore them, and the easiest way to do that is to enable Folder Redirection. In the case of pooled VMs, Folder Redirection is essential. As with mandatory profiles, saving files to local folders on a pooled VM can lead to lost data. As discussed in Chapter 4, “Deploying a Single Remote Desktop Virtualization Host Server,” the most common configuration for pooled VMs is to roll back changes at user logout so the VM remains pristine. That rollback means that any documents saved to the VM would be lost. (Some ISV solutions actually delete the VM on each use and re-create it, which has the same effect.)

For these reasons, it’s good practice to use Folder Redirection with RDS, whether connecting to VMs or sessions. You’ll learn how to do this in the section entitled “Centralizing Personal Data with Folder Redirection” later in this chapter. For now, just know that redirecting profile folders means just that: storing profile subfolders and the data within them, outside the main root profile folder.

How Virtualization Complicates Storing User Configuration and Files

This topic will be discussed a lot in this chapter, but to begin, you need to be very clear about why virtualization complicates user profiles and the way users store data. Fundamentally, it’s because profiles were originally designed for logging into one place at a time, and when using RDS, you might be logged into more than one remote session.

RDS supports five remoting work scenarios.

• RemoteApp programs running from an RD Session Host server and displayed alongside locally running applications

• RemoteApp programs running from a VM (most often a Windows XP VM)

• A full desktop session on an RD Session Host server

• A pooled VM, which might be running any version of a Windows client operating system

• A personal VM, which might be running any version of a Windows client operating system

Figure 5-3 shows the intricate matrix of user profiles and redirected folders for users who access multiple desktop and RDS environments.

So what does it mean to have all these virtualization environments available?

Using more than one or two types of virtualization can lead to profile proliferation. It’s relatively simple if you use one type of virtualization. For example, if you normally work from a desktop running Windows 7 and use RemoteApp for Hyper-V to run a couple of Windows XP applications as RemoteApp programs, then you will have two profiles—one for the RemoteApp session and one for local use. Add a session to that and you could potentially have three profiles to manage. Similarly, the more server farms that a person will need to access to run RemoteApp programs, the more likely that she will have multiple copies of her profile open at once. This is a good argument against farm proliferation.

Operating systems that use V1 profiles can technically use the same V1 profile (and the same goes for operating systems that use V2 profiles). Whether this is a good idea depends on whether the settings in the profiles are appropriate to both local and remote sessions. Also, keep in mind that if you have a copy of your profile open in two sessions, then you might lose changes if you edit both copies.

Storing Profiles

By default, when you log on to a computer running Windows 7 for the first time (unless you’ve set up roaming profiles), you’ll create a new profile in its local profile directory (%SystemRoot%\Users). This profile directory will have your name as a logon alias; it will contain your folders and NTUSER.DAT (which is a hidden file, so you won’t see it unless you’ve enabled viewing hidden files). If left alone, thereafter you’ll store everything in that location. Documents will default to Documents, images will default to Pictures, and where music is stored by default is left as an exercise for the reader. All will be well . . . so long as that’s the only computer you use. If it’s not the only computer you use, however, life gets somewhat more complicated.

Thus far, you have learned how to set up only a single RD Session Host server. However, to provide redundancy and better scale, you’ll need to have multiple RD Session Host servers organized into a farm. When a user logs on to an RD Session Host server farm, the connection is passed from an RD Session Host server to the RD Connection Broker. If the user trying to connect has no current sessions, the RD Connection Broker picks the RD Session Host server with the lowest number of active sessions and sends the user there, as shown in Figure 5-4. Each time a user connects, the RD Connection Broker decides anew which server the user should connect to, based on the number of connections that each server is actively supporting and whether the user already has a session open somewhere. The user connects to the server with the fewest active connections or the one where the user already has an open session. It is likely (and highly recommended) that users will log off when not using their RD Session Host server session, so if you use local profiles for RD Session Host server sessions, then over time, a user will have a local profile on all the servers in the farm.

This might not sound so bad. The user’s logons will occur quickly because the profile isn’t loaded from the network but rather from the local computer. But when the user makes a change here and there, over time, her desktop will look completely different depending on which RD Session Host server (or pooled VM) she logs on to. (If user data is part of the profile—if you haven’t redirected profile folders—the user will be even more confused because the data that she saved in one local My Documents folder won’t be in another one.) If she makes a bad change, that change could well lead to a Help desk call that can be tricky to figure out until you determine to which RD Session Host server she is connected. This is especially true because the problem might vanish if the user logs off and then logs back on and the RD Connection Broker sends her to a different RD Session Host server.

To avoid this scenario, all the RD Session Host servers should use the same copy of the profile, which means that you need to use roaming (or mandatory) profiles stored on a network share. When a user logs on, the User Profile Service looks at the user account properties to see where the profile reserved for RD Session Host server sessions is kept and loads it from there.

When a user logs off, the profile is either deleted from the RD Session Host server or retained in the local cache, depending on the Group Policy settings applied to the RD Session Host servers. For faster logons, cache the profile. Just ensure that there’s enough space on the hard disk holding the cache to support everyone who might need to cache their profile there.

Providing a Consistent Environment

The ways in which you can provide applications to users has grown, and keeping the user experience consistent across these different environments has become even more complicated. Now you must design and implement a profile strategy that takes into account the following.

• Users can use more than one endpoint type at the same time.

• Microsoft VDI can include both V1 (in Windows XP) and V2 profiles (in Windows Vista and later).

• One user can have multiple profiles.

Expect Multiple Profiles

As you offer more ways to present applications to users, delivering user configuration data in the profile gets more complicated. For example, instead of having users logging onto a single desktop and doing all of their work on that local machine, you can now offer full desktops in a session, RemoteApp programs, personal VMs, pooled VMs, and even RemoteApp programs from VMs. Each of these application delivery solutions has a unique environment, and therefore, when using the RDS, we recommend implementing different user profiles for each of these unique environments. The problem with this is that users expect to have the same experience wherever they log on. This is not really possible when users have multiple unique environments.

The Last Write Wins

The benefits of having multiple profiles far outweighs the profits of not having them. Implementing a unique profile for each environment helps to overcome the “Last Write Wins” problem. This is exactly what it sounds like: If a user logs on to multiple places (multiple RDS farms, for example) and those farms have all been set up so that the user utilizes a single roaming profile, then that single roaming profile gets overwritten each time the user logs off each farm. Each time the profile used in a session is copied back to the roaming profile share, it overwrites what was previously there.

The user profile is made of both folder data and registry data. You might not experience much data getting overwritten in the folder areas because you can open only certain files in certain environments (as shown in Figure 5-5). However, the user profile stored in HKCU is all contained in one file: NTUSER.DAT. As Figure 5-5 shows, if the user has a profile open in two different sessions, the second logoff will overwrite any changes saved to the profile at the first logoff.

For this reason, we recommend creating multiple farms only when necessary.