We’re excited to announce that Windows Server 2008 R2 Remote Desktop Service Resource Kit, by Christa Anderson and Kristin L. Griffin (ISBN 9780735627376; 720 pages) is now available for purchase!
In today’s post, please read an excerpt from Chapter 5, “Managing User Data in a Remote Desktop Services Deployment,” which describes 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.
Chapter 5 – Managing User Data in a Remote Desktop Services Deployment
· How Profiles Work
· How Virtualization Complicates Profiles
· Design Guidelines for User Profiles
· Using Roaming Profiles with Remote Desktop Services
· Setting Standards with Mandatory Profiles
· Profile and Folder Redirection Troubleshooting Tips
· Additional Resources
Thus far we’ve discussed how to set up a single RD Session Host server or a simple Microsoft 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. Since profiles weren’t originally designed for remote work environments this can sometimes be tricky. RDS ISV partners have developed some products to help fill the gaps between the in-box profiles and a highly flexible system for complex environments. This chapter, however, shows you how best to configure profiles and folder redirection using the tools in the box.
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 both Windows Server 2008 R2 and Windows 2003 severs, or Windows 7 and Windows XP VMs.
How Profiles Work
Apart from being the thing you see when you look at someone who’s facing 90 degrees away from you, 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 may be stored on the desktop or in one of the folders associate with the user account (e.g., My Documents). The profile also includes user specific settings, such as:
· Changes you make to application layouts; adding buttons, changing the layout, adding a default signature
· Changes to system settings that are unique to your user experience; changing your desktop background, screen saver, 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 granular collection of settings. The NTUSER.DAT file is stored in the root of each user’s profile folder. Mandatory profile settings are stored in NTUSER.MAN; they may be shared among multiple users because they are read-only.
Note: Super-mandatory profiles label the folder where they’re stored with the .MAN suffix, like this: \\servername\sharename\mandatoryprofile.man\. Super-mandatory user profiles are similar to normal mandatory profiles, except that users who have super-mandatory profiles cannot log on when the server that stores the mandatory profile is unavailable. Users with normal mandatory profiles can log on with the locally cached copy of the mandatory profile. Only use super-mandatory profiles when you want to have absolute control of the user profile—so much so that you can’t take the chance that a cached copy might be out of date.
Figure 5-1 – Parts of a user profile; data folders and registry file
While a user is logged in, the NTUser.dat file, is temporarily loaded 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. . We will talk 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 the user made) will be written back to the local hard disk and overwrite the previous version of the file.
Local profiles aren’t a good fit for most remoting scenarios because they’re stored on a single computer. Personal desktops and single RD Session Host server deployments are possible exceptions to this, but pooled VMs and RD Session Host sessions in a farm larger than one server will quickly find that local profiles lead to an inconsistent user experience. This is because the user would have a unique local profile on each machine they log into.
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, come to that) 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 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 aren’t written back to their storage location at logoff—all changes to the profile are just discarded.