- How Profiles Work
- Design Guidelines for User Profiles
- Deploying Roaming Profiles with Remote Desktop Services
- Profile and Folder Redirection Troubleshooting Tips
- Additional Resources
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.
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.
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.
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.
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.
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.
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.
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.