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

  • 12/8/2010
Contents

Design Guidelines for User Profiles

Each of the following affects how you save user-specific configuration settings and data for use with RDS.

  • Local profiles generally aren’t suited to deployments of more than one RD Session Host server because the user experience will be different on every RD Session Host server.

  • Large roaming profiles can increase logon and logoff times. The User Profile Service must copy the files to the endpoint and then copy them back to the profile when storing files on a personal VM can complicate backups and restoring data.

  • Rollback reverts all changes to a pooled VM to the state when you took the snapshot.

  • Profile settings are stored as a flat file written back to the profile storage location at logoff.

The following sections explain how these facts affect your design.

Balance Flexibility and Lockdown

Local profiles aren’t a good fit for RDS deployments larger than a single server. Storing local profiles on RD Session Host servers in a multi-server environment will cause the following problems.

  • It leads to an inconsistent user experience and can create problems that are hard to troubleshoot because they’re linked to logging onto a specific RD Session Host server.

  • It fills up an RD Session Host server hard disk with duplicate copies of a profile (that is, the profile will be stored on each RD Session Host server that a user logs on to).

  • It requires that you back up the RD Session Host server because it now holds user data.

You have two remaining choices: roaming profiles and mandatory profiles. Neither choice is always appropriate. The option that you pick depends on the amount of control you want and have authority to implement.

Roaming profiles can be freely edited by their owners within the limits defined by Group Policy (discussed in Chapter 6, “Customizing the User Experience”). That is, if you’ve defined the wallpaper for a user group via Group Policy, that will be the wallpaper every time anyone in that user group logs on. If you haven’t specified the wallpaper using Group Policy, anyone is welcome to change the wallpaper when connecting to the RD Session Host server. Like local profiles, roaming profiles store user configuration data in NTUSER.DAT.

Mandatory profiles differ from roaming profiles in that their owners can edit them, but any changes that they make will not be saved to the profile. This can speed up logoff times because nothing is written back to the network share where you’ve stored the mandatory profiles. More insidiously, mandatory profiles don’t save any data to folders stored within the profile folder. You must use Folder Redirection if using mandatory profiles, if you want users to be able to save data to their personal folders. In fact, that’s worth highlighting in a cautionary note.

CAUTION

If you use mandatory profiles or pooled VMs with rollback enabled, you must configure Folder Redirection to allow users to save files to their personal folders that are part of their profiles.

The core choice between mandatory and roaming profiles is the tradeoff of flexibility versus control. Mandatory profiles eliminate the chance of a user making a bad change that can’t be fixed by logging off and logging back on again. Mandatory profiles also speed logoff times because they don’t need to be written back to the share.

However, mandatory profiles don’t allow users the degree of personalization that many people have come to expect from Windows. In addition, mandatory profiles don’t allow other applications to save data to the profile either. This means that some security applications that require giving users a private key [such as the encrypted file system (EFS)] don’t work with mandatory profiles. The choice will depend on your corporate culture, your need to use applications that require private keys, and the ability of the IT department to control the desktop.

ON THE COMPANION MEDIA

One solution to the choice between roaming profiles and mandatory profiles is not to choose. Use mandatory profiles and combine them with a mechanism that allows users to save selected settings and have them applied at logon. Windows Server 2008 does not include this functionality, but several RDS ISVs or consulting partners do. You can find an example of this functionality—a tool named Flex Profiles—from the following link on the companion media: http://www.immidio.com/flexprofiles.

Use Folder Redirection

Whether you’re using roaming profiles or mandatory profiles, it’s best practice to use Folder Redirection with sessions or pooled or personal VMs.

If you’re using roaming profiles, Folder Redirection will ensure that the profile stays small. A large profile will slow both logon and logoff times. The fastest approach is to use local profiles, but for reasons already discussed, you don’t want to combine local profiles with RD Session Host servers.

If you’re using mandatory profiles, then use Folder Redirection selectively. Any folders stored in the profile folder will become read-only. For some folders, this is very bad news because people won’t be able to save their documents or pictures in their personal folders. But for some folders, this is exactly what you want. For example, if you don’t want people to remove icons from the Start menu permanently, leave the Start Menu folder in the profile folder. See the section entitled “Centralizing Personal Data with Folder Redirection” later in this chapter for how to implement Folder Redirection.

Compartmentalize When Necessary

It is generally best practice to maintain different profiles for different environments because different types of virtualization can have different user configuration requirements. Don’t go crazy creating different profiles for every possible occasion, but make sure your profile plan supports the various ways people use RDS. Compartmentalizing can also help avoid accidental overwrites.

  • You might need V1 profiles to access terminal servers running versions of Windows earlier than Windows Server 2008, and V2 profiles to access RD Session Host servers.

  • Implement roaming profiles for use with VM pools to keep the user experience consistent and avoid losing profile changes to rollback.

  • Personal VMs can use a local profile for faster logons.

  • To avoid the Last Write Wins problem, avoid users opening the same profile on multiple machines at the same time.

Prevent Users from Losing Files on the Desktop

There are a couple of cases where it’s really important to prevent users from saving files to the desktop.

Users can lose, or misplace, data when using RemoteApp programs if you’re not careful about Folder Redirection. Here’s why: The Desktop folder contains everything that you can see on the desktop—files and shortcut icons. Many users are used to saving documents to the desktop. This is acceptable if you’re actually seeing the full desktop, but if you’re using RemoteApp programs, users don’t see their desktop in the RD Session Host server session. Users could save data to the desktop and then not know where that data actually is because they can’t see it. (They could open a document if they moved to the Desktop path when opening a file, but just double-clicking a document on the session desktop is not possible in this scenario.) To prevent users from saving files to the desktop, you can make the desktop read-only and trigger an error message if the user tries to save files to the desktop. To do this, you’ll need to do the following.

  • Redirect the Desktop folder to an external share.

  • Set the permissions on this external share to read-only.

NOTE

For instructions on how to create a read-only desktop, read the section entitled “Creating a Safe Read-Only Desktop” later in this chapter.

If you keep the Desktop folder in the profile folder and use mandatory profiles, then people can save files to the desktop . . . as long as they are logged on. When the user logs off, however, no changes are saved, including saved files on the desktop. The same thing will happen to users of VM pools with rollback enabled; anything saved by the user to the VM during each session will be discarded once the VM snapshot is invoked.

In both cases, redirect the desktop to a folder so users can save data there without it being discarded at logoff.

NOTE

For instructions on implementing Folder Redirection, see the section “Centralizing Personal Data with Folder Redirection” later in this chapter.

Upload Profile Registry Settings in the Background

NTUSER.DAT is updated only when a user logs off. A user who does not log off isn’t saving changes. This can lead to data loss. A new policy in Windows Server 2008 R2 enables this file to be uploaded while the user is logged on, as follows.

  • Computer Configuration | Administrative Templates | System | User Profiles | Background upload of a roaming user profile’s registry file while user is logged on

Configure the setting to upload NTUSER.DAT on a set schedule (at a certain time of day) or at a set interval, designated in hours.

NOTE

This setting does not upload any other profile data, just the contents of HKCU.

Speed Up Logons

People are sensitive to the amount of time it takes to log on to a session. If it takes too long, you’ll have problems with people leaving their sessions open rather than logging off. This is a security risk, has the potential to lock files that more than one person might need to edit, and keeps processes open on the RD Session Host server. You can disconnect and terminate sessions forcibly using Group Policy, but this has other drawbacks.

To encourage people to log off, make the logon process as painless as possible. You’ve already learned about using Folder Redirection to minimize the size of a profile. To speed things up, you can also employ Group Policies to do the following.

  • Cache roaming profiles.

  • Limit the amount of time an RD Session Host server or VM will try to load the user profile before using a temporary profile.

  • Set an upper limit on the size of a user profile.

  • Process group policies asynchronously.

New to Windows Server 2008: Speeding Up Logoffs

Speeding up logons is important, but when it’s Friday afternoon and you want to get out of the office, logoffs are just as important. There are two ways in which Windows Server 2008 and later help logoffs take less time.

You can limit the size of a profile using Group Policy (and help this limit by redirecting the folders out of the policy). This policy, Limit Profile Size, is set per user and is located in User Configuration | Policies | Administrative Templates | System | User Profiles.

Prior to Windows Server 2008, there was a nasty catch when it came to profile quotas: Windows was serious about enforcing this limit. If you made your roaming profile larger than Group Policy allowed, Windows would prevent you from logging off until you made the profile smaller. In Windows Vista and later, you can log off, but if the profile is larger than the size permitted by Group Policy, the profile changes won’t get written back to the roaming profile storage area.

Before Windows Server 2008, another issue that could delay logoffs (or prevent you from unloading your roaming profile altogether) was applications or drivers that left handles to the registry open (in other words, they started to use it but never broke the connection). Microsoft had a separate tool called the User Profile Hive Cleanup Service (in an application called UPHClean) that checked for these open handles and closed them so users could log off. In Windows Server 2008 and later, UPHClean functionality is handled by the User Profile Service.

Caching Roaming Profiles

To reduce the time that it takes to log on to an RD Session Host server, the server will cache the roaming profiles. Ordinarily, RD Session Host servers attempt to retrieve the roaming profile from its central location. In cases when the network connection to the profile server is too slow or not working, however, being able to log on with a locally cached copy of your profile can at least speed things up. Caching stores a copy of the profile on the RD Session Host server. This profile cache isn’t used if the original roaming profile is available, but it can speed up logons in the case of slow or absent network connections.

Caching profiles is not without its drawbacks. It consumes hard disk space on the RD Session Host server. It can also prevent new users from logging on if the space allocated to cached profiles gets filled up. If you do cache profiles, make sure that you’ve got sufficient space for your user base and use Group Policy to delete profiles that aren’t being used.

CAUTION

Don’t delete user profiles from the RD Session Host server using Windows Explorer or the delete command-line tools, because this does not clean up the registry entries associated with the profile and can affect the user’s ability to log on again. Configure the RD Session Host servers with Group Policy to delete any profiles unused for a given period.

Process Group Policy Asynchronously

Caching user profiles also means that you can use asynchronous processing of Group Policy, a policy processing model introduced in Windows Server 2008. You can apply Group Policy synchronously or asynchronously. If you apply it synchronously (the default model for a server), logon doesn’t complete until the Group Policy settings that apply to that user are applied. If you apply Group Policy asynchronously (the default action for a desktop), the user can log on while Group Policy is being applied. Asynchronous processing can lead to changes in the user environment after users have logged on but will speed up logon times if Group Policy processing is slowing things down. For a review of the connection process, see Chapter 3, “Deploying a Single Remote Desktop Session Host Server.”

Allow asynchronous Group Policy processing by enabling the following Group Policy setting.

  • Computer Configuration | Policies | Administrative Templates | System | Group Policy | Allow Asynchronous User Group Policy Processing When Logging On Through Remote Desktop Services

This policy works only when logging on to an RDS session host. It’s not needed when logging on to desktop pools, because a desktop operating system already processes Group Policy asynchronously by default.

Save to your account

This chapter is from the book