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

Deploying Roaming Profiles with Remote Desktop Services

This section discusses managing roaming profiles in an RDS environment, including the following.

• Creating roaming profiles

• Converting an existing local profile to a roaming profile

• Creating a default network profile

• Using Group Policy to set up the roaming profile storage area automatically

• Implementing a Group Policy infrastructure that supports these policies, including security filtering and loopback policy

• Managing roaming profiles cached on the RD Session Host servers

Creating a New Roaming Profile

To implement roaming profiles, you will need to

1. Create a network share in which to store the roaming profiles.

2. Configure the user accounts (through Active Directory Users And Computers or Group Policy) to use roaming profiles.

3. Have each user log on and create the roaming profile.

First, create a shared network location to store the roaming profiles. On the file server, create a new folder and set the appropriate NTFS and share permissions, using the guidelines in Table 5-5.

Table 5-5 Recommended Share and NTFS Permissions for an RDS Roaming Profiles Storage Folder

When you’ve set up the profile location, configure the user account to use roaming profiles. This process varies slightly for profiles used with RD Session Host servers and for profiles used with pooled and personal VMs. You will see these differences as you step through this process. It’s easiest if you configure this via Group Policy, but you will also see how to do it on a per-user basis.

Remote Desktop Session Host

To configure a user account to use roaming profiles, perform the following steps.

1. Open Active Directory Users And Computers, right-click a user’s account, and choose Properties.

2. For Remote Desktop Session Host situations, navigate to the Remote Desktop Services Profile tab and type the Profile Path location using the format \\servername\share name\%username%.DomainName, as shown in Figure 5-6.

The variable %username% inserts the user account name into the profile path, so you don’t have to customize the path for each person when adding new accounts manually or through a script. You don’t need to add the .V2 extension to this path, either; it will be added automatically because the profile will be a 2008 version profile. The next time the user logs on to the RD Session Host server, he will use the roaming RDS profile.

Figure 5-6 Enter the Remote Desktop Services profile path.

Virtual Machines

Pooled and personal VMs do not use Remote Desktop Services profiles. A pooled or personal VM is really a virtualized client desktop and acts accordingly—that is, it uses regular profiles. For these VM scenarios, enter the profile share’s UNC path on the Profiles tab of the user account Properties dialog box, shown in Figure 5-7.

Figure 5-7 Specify the profile used for pooled and personal VMs on the Profile tab, not the Remote Desktop Services Profile tab.

When the user is configured to use roaming profiles, it’s time to create the profile. This happens when the user first logs on to the RD Session host server (or the pooled/personal VM). When the user first logs on, the following happens.

1. The User Profile Service creates a profile folder for the user in the specified path.

2. The User Profile Service copies the default profile on the RD Session Host server or VM to give the user a profile.

3. When the user logs off, the User Profile Service copies the profile to its storage location in the specified network share. The user will be the owner of the folder and therefore will be the only one to have access to the folder and its contents.

Although a user profile folder is for the user, if Administrators also have permissions they can delete a corrupted profile or perform other maintenance easily. To permit this, give the Domain Admins group Full Control NTFS rights to the parent folder, and pre-create roaming profile folders for each user in the roaming profiles share. Make sure that the user has full control of his profile folder, subfolders, and files and that the user is also the owner of the folder. The simplest way to do this is to use Group Policy; if you keep your RD Session Host servers or pooled VMs in their own organizational unit (OU), you can also create a computer Group Policy object (GPO) with Loopback Processing enabled and give administrators access to profile contents by enabling the following GPO setting.

• Computer Configuration | Policies | Administrative Templates | System | User Profiles | Add The Administrators Security Group To The Roaming User Profile Share

For more information on Loopback Processing and using Group Policy to create and manage RDS roaming profiles, see the section entitled “Using Group Policy to Manage Roaming Profiles” later in this chapter.

Icacls.exe //<profile root>/%username%.%userdomain%.v2 /grant
   <RDS Admins group>:
F /T /Q

Converting an Existing Local Profile to a Roaming Profile

Sometimes you will want to convert existing local profiles to roaming profiles. This can apply if you are converting a traditional desktop deployment to an all-RDS deployment, and you are willing to risk that the local profile settings are appropriate for the remote work environment.

Converting local profiles to roaming profiles is really simple. Configure all user accounts to use roaming policies as described earlier, and specify that cached copies of the profile should be deleted. When users log on to the server where their local policy resides and then log off, their local profile will be copied to the network share that you specified. The cache on the server will be deleted and only the roaming profile in the network share will remain.

You might have done this conversion in Windows Server 2008 using the Copy To button in the User Profile Properties dialog box. This is no longer possible on a server running Windows 2008 R2 or a client running Windows 7—the button has been disabled.

The removal of this functionality doesn’t prevent you from converting local profiles to roaming profiles or even overwriting one user’s profile with another’s. Removing the functionality prevents you from overwriting the default user profile with another user profile. People often overwrote the default user profile with a customized one from another user to deploy customized profiles to new users. As described in the Direct from the Source sidebar entitled “Why the Copy To Button Is Disabled,” doing this was unsupported (although popular) as far back as Windows XP, because although this “worked” for many people, it actually was not a clean process. It could lead to problems if that profile had been used at all, and it would also “tattoo” the profile with inappropriate settings and naming, such as the following.

• A list of that user’s frequently run programs.

• The user’s documents folders will be incorrectly called Administrator’s Documents.

• The user might have access to Administrative Tools (this is incorrect for regular users).

• Windows 7 libraries will be broken.

Customizing a Default Profile

Customizing the default profile is one way to ensure that all new RDS users start with the same settings. The only supported method for customizing the default profile is to use the Sysprep.exe tool (built into Windows 7 and Windows Server 2008 R2) to overwrite the default profile with the profile that you are logged onto when you run Sysprep.exe. Here are the steps.

1. Log on as an administrator and customize the profile as needed. This is the profile that will be copied over the default user profile.

2. Create an Unattend.xml file and add a line of code to it to tell it to copy the profile of the user logged on over the default profile when the system reboots. The line you add is

   <CopyProfile>true</CopyProfile>

   The following is example code for a 64-bit version Unattend.xml file with the extra line of code added.

   <?xml version="1.0" encoding="utf-8"?>
   <unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="specialize">
   <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64"
   publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
      xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <CopyProfile>true</CopyProfile>
   </component>
   </settings>
   <cpi:offlineImage cpi:source="catalog:e:/clg files/64-bit/install_windows 7
      ultimate.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
   </unattend>

3. Save this Unattend.xml file to C:\Windows\System32\Sysprep.

4. After you have the Unattend.xml file in place, open a command prompt and type the following command.

   sysprep.exe /oobe /reboot /generalize /unattend:unattend.xml

After you run this command, the server will reboot. When it comes back up, the default profile will be overwritten with the one that was logged in when you ran Sysprep. Now you can highlight the default profile and use the Copy To button to copy the profile to a network share to be used for roaming profiles.

Creating a Default Network Profile

You have already learned (in the section titled “How Profiles Are Created” earlier in this chapter) when a network default user profile would be used to create new user profiles. Using a default network profile to create new roaming profiles might benefit your roaming profiles implementation because it ensures that when new profiles are created, they all stem from the same source.

Assuming that you can use a network default profile for all your scenarios, on Windows 2008 (and Windows 7) you can copy a local default profile to the NETLOGON share on a domain controller, following these steps.

1. Log on to the server with an admin account.

2. From the Run box, browse to the domain controller: \\DOMAIN CONTROLLER\ NETLOGON

3. Create a folder in the NETLOGON share and name it Default User.v2.

4. From Server Manager, click Change System Properties, navigate to the Advanced tab, and then click the Settings button in the User Profiles section.

5. Select the Default Profile from the list of profiles stored on the server and click Copy To.

6. Browse to or type the network path \\DOMAIN CONTROLLER\NETLOGON Default User.v2.

Using Group Policy to Manage Roaming Profiles

You’ve seen how to dictate who uses roaming profiles by settings this up on a per user basis in Active Directory Users And Computers. If you have more than a few users, it’s easiest to create a GPO that dictates the RDS roaming profile location for everyone who logs on to a farm. This section explains how to do this and how to set up the Group Policy infrastructure that you’ll need.

The single most important part of successfully using roaming profiles with RD Session Host servers is to set up the RD Session Host server environment OU and create the GPOs correctly. Group Policy has many different uses, but it all comes down to making changes to many computers or many users all at once.

There are two broad categories of Group Policy: computer settings and user settings. Computer settings are applied at boot time, or on an RD Session Host server (see Chapter 2, “Key Architectural Concepts for Remote Desktop Services,” for more details), when a session starts (to apply the settings to the session). User settings are applied when the user logs on to the session. Because settings are applied to users at logon, they don’t have to be saved as part of a user’s account properties. Because they’re applied second, settings applied to a user will control when there’s a conflict.

Because of the order in which user and computer Group Policy is applied, when managing RD Session Host server settings, you’ll almost always use an additional GPO to enforce loopback policy processing. In short, loopback policy reapplies the user-specific settings that are placed on the OU where Loopback Processing is enabled after the normal user GPOs are applied. The result is that settings placed on the RD Session Host server OU will always take precedence in case of a conflict. If you have blocked GPO inheritance on the RDS OU, then only the user policies that you place on the OU will be implemented for your users. You’ll find out more about loopback policies in the section entitled “The Ins and Outs and Ins of Loopback Policy Processing” later in this chapter.

There’s some overlap between the computer- and user-specific settings in Group Policy, but you’ll generally find that you’ll need both to configure the users’ working environment. When setting up an RD Session Host server environment, where it’s important not just that you are logging on but that you’re using an RD Session Host server, you’ll definitely need both.

Controlling Group Policy Processing for an RDS Environment

When you have multiple users working on one computer, you need to control the environment as much as possible. The easiest way to do this is to perform the following steps.

1. Put RD Session Host server farms and all VMs pools into their own OUs.

2. Block inheritance of all GPOs that are not specifically enforced. (You might not have this option, depending on company policy.)

3. Place computer and user GPOs on these OUs to specify the settings to be implemented for each pool and farm.

Here’s how to do all this.

Organize Farms and Pools Into Ous

First, create an OU for each RD Session Host farm or VM pool. (Because all members of a farm or pool are homogenous, they should all be in the same OU.) Open Active Directory Users And Computers, right-click the domain, and choose New, Organizational Unit. Name it after the farm (for example, RDSH Farm1) and then drag all computer objects in the farm or pool into the OU (see Figure 5-8).

Figure 5-8 Create OUs for your RD Session Host server farms and VM pools.

Block GPO Inheritance

Next, if possible in your organization, block GPO inheritance for this OU. This ensures that only computer settings set by GPOs linked to this OU will apply to the computers in this OU. It also ensures that with Loopback Processing enabled, only user settings set by GPOs linked to this OU will be applied to users logging on to the computers in this OU; other GPOs set at the domain or site level will not be applied.

To block inheritance for a farm or pool OU, open the Group Policy Management console (GPMC; do this by clicking Start, Programs, Administrative Tools, and Group Policy Management), right-click the RD Session Host server’s OU, and choose Block Inheritance. If possible, also do this for your pooled VM OUs. Personal VMs can be controlled like this, but more likely they will act as regular desktops in your environment and will treated as such in the case of Group Policy processing.

Create GPOs for User and Computer Settings

There are multiple ways to set up policies, but it is usually easiest if you separate computer-and user-specific settings into different policies. Although one policy might contain both user- and computer-specific settings, it’s simplest to isolate the two types of settings unless your environment is very small or your user base is very homogenous. This allows you to create a consistent model of RD Session Host server management while still allowing you the flexibility to apply different policies to different groups of users and computers (that is, using a GPO on multiple OUs if the functionality is needed in multiple places). Create two different types of GPOs: a computer GPO and user GPOs, as shown in Figure 5-9.

Figure 5-9 Create separate user and computer GPOs for the RDS environment.

To create the GPOs, open the GPMC (by clicking Start, Programs, and Administrative Tools). Right-click the Group Policy Objects folder in the left pane, found under your domain folder, and choose New to open the dialog box shown in Figure 5-10.

Name the computer policy something descriptive, such as RDS Computer GPO, and then click OK.

Figure 5-10 Create an RD Session Host server computer policy.

Next, create another policy that will hold user-specific settings, naming it something like RDS User GPO. Click OK, and you will be back in the GPMC, with a list of available policy objects that includes the ones you just created, as shown in Figure 5-11.

Figure 5-11 Create computer- and user-specific GPOs.

Next, ensure that each GPO is specific to one type of settings—computer or user. This is optional, but this will give you more control over your RDS environment.

Click the Details tab in the upper portion of the right pane. Here, there’s a GPO Status drop-down list with four options: All Settings Disabled, Computer Configuration Settings Disabled, Enabled, and User Configuration Settings Disabled. For your computer-specific GPOs, make sure that no user-specific settings will be applied by setting the Status to User Configuration Settings Disabled. Follow the same process to create a new user-specific GPO. For the User GPO, navigate to the drop-down menu on the Details tab and set the GPO Status to Computer Configuration Settings Disabled.

The Ins and Outs and Ins of Loopback Policy Processing

Outside an RD Session Host server environment, you often apply Group Policy based on the persona of the user logging on. If you don’t want Adam Barr to open Control Panel, for example, you probably feel much the same way about this whether Adam Barr is logged on to his desktop computer or his laptop. Similarly, if you don’t care whether he is running Control Panel, then you continue not to care whether he’s logged on to his desktop or his laptop. It’s his space—let him mess it up. (The Help desk might feel differently about this, but that’s another matter.)

As discussed in “Using Group Policy to Manage Roaming Profiles” earlier in this chapter, the computer policy will always be applied first, then the user policy. If a user policy and a computer policy conflict, the user policy will “win,” because it’s applied last. Any Group Policy stored locally on the computer is applied first. Next, policies placed at these levels are applied in order (local, Site, Domain, OU), as shown in Figure 5-12.

In case of conflicts, the policy applied last wins. For example, computer policies set on a computer OU will override conflicting policies set at the domain level. And user policies will overwrite computer policies in conflicting situations (some settings can be set for a computer and also for a user) because they are applied after computer policies.

Figure 5-12 Group Policies get applied from the top down.

On a personal computer, it’s perfectly acceptable to have the identity of the person logging on define the final settings for Group Policy. But RD Session Host server farms and pooled VMs are location-specific or context-specific situations in which where you are matters even more than who you are. For example, you might decide that it’s acceptable for users to use clipboard redirection when connecting to personal VMs, but for security reasons, you don’t want them using clipboard redirection when connecting to an RDS server farm hosting sensitive data. You need policies applied based on which computer you are logged on to. In this case, you will apply loopback policy processing to tell the Group Policy engine to apply the user GPOs that are applied to a computer OU (for example, to an RDS farm OU) after applying the user GPOs that are normally applied during logon. With loopback policy processing enabled, GPO processing will now work as shown in Figure 5-13.

Figure 5-13 Loopback Processing changes the effective Group Policy results.

When the RD Session Host server starts, computer GPOs are applied. When the user logs on to the RD Session Host server, the User GPOs are applied to the session. Then, because loopback policy processing is enabled, User GPOs that are applied to the RD Session Host server OU are applied last. In addition, if you have blocked inheritance, it’s possible that the only GPOs that will be applied are computer and user GPOs that are placed specifically on the OU.

To enable Loopback Processing, right-click the Computer GPO applied to the RD Session Host server OU and choose Edit. The Group Policy Management Editor opens the GPO. Go to Computer Configuration, Policies, Administrative Templates, System, and Group Policy and find the User Group Policy Loopback Policy Processing Mode node in the pane on the right. Double-click it and you will see the dialog box shown in Figure 5-14.

Figure 5-14 Enable loopback policy processing from the User Group Policy Loopback Processing Mode Properties dialog box.

Fine-Tuning GPOs with Security Filtering

A GPO works because by default, anyone in the Authenticated Users group can use it, and Authenticated Users means “anyone who is logged on to the domain.” (Computers also log on to the domain, so they’re also members of Authenticated Users.)

If you have groups of users with specific needs controlled by Group Policy, you can create a User Policy for each user group and then use Security Filtering to apply each User GPO to a specific user group. For example, this technique could come in handy if you give access to multiple applications in one farm but only have licensing enough for a subset of users. You could block certain users from running that application, thus meeting software licensing compliance requirements. To narrow the scope of to whom (or to what) these policies will apply, double-click the GPO in the Group Policy Objects folder and navigate to the Scope tab in the right pane. In the Security Filtering section on this tab, modify Security Filtering to include the specific users group for which you want settings in the GPO to apply, as shown in Figure 5-15.

Figure 5-15 Add users to the GPO Security Filtering section of the ASH TS Users Policy.

Using Group Policy to Define the Roaming Profile Share

After you have a Group Policy infrastructure set up, you can create a policy to create roaming profile folders in the proper folder share location automatically.

The Group Policy setting to set the path for RDS roaming profiles is a computer setting. Right-click your Computer Policy GPO and choose Edit. Expand the GPO to Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles. In the pane at right, double-click Set Path For Remote Desktop Services Roaming User Profile, shown in Figure 5-16.

Figure 5-16 Set the path for Remote Desktop Services Roaming User Profile storage.

Select the Enabled option and type the RDS roaming profile share location in the Profile Path text box. If you use Group Policy to set the RDS roaming profile path, then the profile folders that are created take the form of username.domainname.V2; you do not need to add the %username% variable, the domain name, or the .V2 extension. This is in contrast to defining the path to the Remote Desktop Services profile folder by editing the user account properties through scripting or through Active Directory Users And Computers, where you must specify the username and domainname variables to create the folder properly.

If the profile folders are created automatically when the user logs on, then the user gets sole access to the profile and is also set as the owner of the profile folder. To permit administrators to access the profile, enable the following GPO setting: Computer Configuration | Policies | Administrative Templates | System | User Profiles | Add The Administrators Security Group To Roaming User Profiles. With this GPO setting enabled, the following permissions are placed on newly created user folders.

• User Full Control, owner of folder

• SYSTEM Full Control

• Administrators Full Control (This is the local administrators group of the server where the profiles are stored, which also contains the Domain Admins group.)

You can also pre-create user profile folders and set permissions as required. For more information about profile folder permissions, see the section entitled “Converting an Existing Local Profile to a Roaming Profile” earlier in this chapter.

With this GPO setting configured, users accessing the RD Session Host servers in this OU now have a roaming profile created and stored in the designated share.

Configuring Roaming Profile Paths for VMs

Pooled and personal VMs will run client operating systems. Setting an RDS roaming profile path on these machines simply won’t work. They are client machines, and for the most part, they should be treated as such. To configure the roaming profile path for client machines, use this GPO setting: Computer Configuration | Policies | Administrative Templates | System | User Profiles | Set Roaming Profile Path For All Users Logging On To This Computer.

Enter the share name where your profiles are stored and add the %username% variable to the end of the path so that each user gets a unique profile folder, as follows.

\\servername\sharename\%username%

Speeding Up Logons

One of the biggest challenges that IT professionals face in an RDS environment is to provide a user experience that feels as much like a local computer as possible. Users want to log on quickly, work steadily, get their job done, and get out. If they find that they have to wait longer to log on than they like, the Help desk will hear about it, or people will look for ways to circumvent the data center.

Roaming profiles are usually the best choice for RDS. Centralizing the profile on a network share makes it possible to always have the same experience no matter what RD Session Host server or VM a user is logged into—even new ones that were just added. Centralizing also simplifies backups. However, if you don’t take steps to avoid it, profiles grow over time. By default, a profile contains not only configuration data but also user documents. Assuming that a user saves files to the folders there for that purpose, the profile will grow. Big profiles slow down logons and logoffs due to the massive amounts of data that must be copied to the remote location.

There are several things you can do to speed logons.

• Take advantage of the new behavior of Group Policy caching among servers in a farm to reduce the time needed for the first login.

• Enable Folder Redirection.

• Manage policy caching.

• Limit profile size.

Let’s start with the one that requires no configuration.

Roam Group Policy Cache Between RD Session Host Farm Servers

Group Policy is cached on a computer to speed up logon times. The first time someone logs on to an RD Session Host server, her Group Policy settings won’t be cached there. A new feature of Windows Server 2008 R2 copies the Group Policy cache to all servers in a farm. That way, once a user has logged on to one member of the farm, her GP cache will be available on all servers in the same farm.

Enable Folder Redirection

When a user logs on to an RD Session Host server, his roaming profile has to be copied to that RD Session Host server. When the user logs out, the changed profile must be copied back to the roaming profile storage location. Note that you are writing the entire profile back, not just the changes to the profile. Imagine if one of your users saved 30 GB of data in his Documents folder. He would log on to the RD Session Host server and then go get a cup of coffee (or even go to lunch) while waiting for the profile to copy itself to the server. Now imagine if all your users had that much data stored in their Documents folder. If they all come in at 9 A.M. and try to log on to the RD Session Host server, logons could quickly consume all your network bandwidth. Soon the water cooler or break room would be very popular, and no one would get any work done.

Profile caching also suffers if you experience profile bloat. Profile caching saves a copy of the user profile on the RD Session Host server so that, if the network is slow to retrieve the saved profile from its file share, the user can still log on using the cached copy. (When you log on to an RD Session Host server, a copy of your profile is saved there as a matter of course. If you enable profile caching, the profile isn’t deleted when you log off.) However, if the profiles in the cache are too large, the space allocated for them will fill up, and people won’t be allowed to log on because there’s no room to store their profiles. There are Group Policies to remove older data in the cache if room runs out, but it’s better if you can avoid this problem entirely.

The simplest step that you can take to avoid profile bloat is to enable Folder Redirection. Folder Redirection has two advantages: it keeps user data out of the profile to keep the profile smaller, and it allows differential synching (so that if only part of a file is changed, that part will be saved to the central location, rather than copying the entire file). You’ll learn how to set up Folder Redirection in the section “Centralizing Personal Data with Folder Redirection” later in this chapter.

Limit Profile Size

One way to reduce the impact of caching profiles on the RD Session Host servers is to limit the size of the profiles. Although too many profiles can still fill up the hard disk, smaller cached profiles have less impact. To limit profile size, open your RDS User GPO and browse to User Configuration | Policies | Administrative Templates | System | User Profiles. Locate the policy Limit Profile Size and enable it.

If you’re redirecting folders, the size of the profile shouldn’t be a major concern. NTUSER.DAT is a fairly small file. The exact size depends on the profile, but it’s not much; check the size of some representative NTUSER.DAT files to gauge the space needed to allocate space for profiles.

Manage the Profile Cache on RD Session Host Servers

Another way to keep the size of the cache on the RD Session Host servers from getting too large is to delete old copies of the user roaming profiles. You can also limit the profile cache size if you’re concerned about running out of room on the servers.

Programmatically Managing the Cache

You can use two computer Group Policy settings to delete unused cached profiles on RD Session Host servers in the RD Session Host Farm OU automatically. Both policies are located in Computer Configuration | Policies | Administrative Templates | System | User Profiles.

• Delete Cached Copies Of Roaming Profiles Enabling this setting deletes a user’s cached profile when the user logs off. This setting ensures that the loaded profile is always the most recent. However, the cached profile provides a fallback configuration to load if the actual profile isn’t available for some reason. If you delete cached profiles, then if the actual profile can’t be loaded, the user will get a temporary profile and any changes he makes to it will be discarded when the user logs off.

• Delete Unused Profiles Windows Server 2008 R2 has a new Group Policy setting that limits the size of the overall roaming profile cache (located in the %SystemDrive%\ Users directory). If the size of the profile cache exceeds the configured size, RDS deletes the least recently used copies of roaming profiles until the overall cache goes below the quota. The policy setting is found in Computer Configuration | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Limit The Size Of The Entire Roaming User Profile Cache.

Another way to make sure that your servers do not run out of disk space due to an overgrown profile cache is to put a cap on the cache size. If the size of the entire cache exceeds the limit set by this policy, the server will delete the oldest profile in the cache until the overall size drops below the threshold you set. The GPO setting is located at Computer Configuration | Administrative Templates | Windows Components | Remote Desktop Services | RD Session Host | Profiles | Limit The Size Of The Entire Roaming User Profile Cache.

Enable this setting and enter the following numbers.

• A monitoring Interval (in minutes): The interval at which the profile cache size is checked.

• Maximum cache size (in GB): This is the threshold. If the cache grows beyond this number, the oldest profiles start getting deleted.

Deleting Cached Profiles Manually

Deleting cached profiles manually sounds too simple to bother explaining, but it’s more subtle than it might appear. Cached profiles are kept in the %SystemDrive%\Users directory. However, the obvious approach doesn’t work. If you do the obvious—look at the profiles, check the dates, note that some profiles haven’t been used in a while, and delete them—you will prevent the owners of those deleted profiles from being able to log on to the RD Session Host server and load their roaming profiles, at least without some help from you. See the section entitled “The Consequences of Deleting a Profile Folder from Windows Explorer” later in this chapter for more information. For now, let’s see how you can avoid extra work.

The problem is that cleaning up old profiles isn’t just a matter of deleting some old directories. The registry maintains a list of profiles in HKLM\Software\Microsoft\Windows NT\ CurrentVersion\ProfileList. Sort through that key (see Figure 5-17), and you’ll see entries for everyone who currently has a profile cached on the server. Although the keys themselves are identified by the SIDs of the user accounts, you can see the names of the profile paths by examining the contents of the keys.

Figure 5-17 When you cache a profile on a server, it automatically creates a corresponding registry entry.

If you just delete the profile from Windows Explorer, the entries in the registry remain, which confuses the server, as explained in the next section.

The cleanest way to delete unused profiles is to let Group Policy delete the old and unused profiles. You can also delete cached roaming user profiles from the User Profiles section of System Properties on the RD Session Host server. Log on to the RD Session Host server as an administrator. Go to Start, Control Panel, System, and click Change Settings. The System Properties dialog box will appear. Select the Advanced tab. In the User Profiles section, click Settings... to open the User Profiles dialog box, shown in Figure 5-18.

Figure 5-18 The User Profiles dialog box displays the profiles stored on the computer.

Highlight the roaming profile that you want to delete and then click Delete. When you see a dialog box confirming that you want to delete the profile, click Yes and the roaming profile cache is deleted. Click OK.

The Consequences of Deleting a Profile Folder from Windows Explorer

Just in case you decide to try deleting a profile folder from Windows Explorer, here’s what will happen. If you delete an unused profile folder from Windows Explorer, the next time that user with that folder logs on, he will be unable to load his roaming profile. A temporary roaming profile will be created for him, profile changes that he makes will be discarded at logoff, and Event ID 1511 is logged in the Windows Application event log stating that Windows cannot find the local profile and is logging him on with a temporary profile.

Deleting that directory caused a problem because you didn’t clean up the cached profile completely. For each cached profile stored in %SystemDrive%\Users\%UserName%, the User Profile Service creates a registry entry for this profile at HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList, shown in Figure 5-19. This registry key is named according to the user SID.

Figure 5-19 The RDS roaming profile cache registry entry for user Adam Barr

The ProfileImagePath key in this folder indicates the cache location, which by default is %SystemDrive%\Users\%UserName%. (The network location where the roaming profile is stored is in the CentralProfile key.)

If you delete the user’s locally cached profile folder and that user starts a session on that RD Session Host server, he will get a temporary profile. The registry entry corresponding to the user’s cached profile is renamed. The SID part stays the same, but it is given an extension of .bak, as shown in Figure 5-20.

Figure 5-20 The old registry key for the profile that was deleted incorrectly now has a .bak extension.

In addition, a new key is created in its place. The newly created registry entry is named after the user SID just as before. However, the ProfileImagePath key inside the new folder now points to %SystemDrive%\Users\TEMP, as shown in Figure 5-21.

Figure 5-21 A new registry entry is created, but the ProfileImagePath key points to %SystemDrive%\Users\TEMP.

Therefore, the entry that used to work now has a .bak extension and is not usable, and the profile actually being used is a temporary profile. When the user logs off, his temporary profile is not copied back to the central profile storage location on the fileserver.

Deleting the profile from the System Properties dialog box User Profiles section no longer works either. Most likely, the profile will not even be listed in the dialog box. If it is, it most likely means that the user has not logged off completely. If you do manage to select it and click Delete, you get an error message: “Profile not deleted completely. Error – The system cannot find the file specified.”

To rectify this, you must manually delete the abandoned registry entry that has the .bak extension. You might also need to reboot the server. Only then can the user log on to the RD Session Host server and have his roaming profile correctly cached once again on the server.

Centralizing Personal Data with Folder Redirection

The single biggest thing that you can do to affect profile size, simplify backups, and speed logons and logoffs is to redirect user-specific storage out of the user profile. By default, user data folders such as Documents are in the profile, but they don’t have to be. Instead you can create a pointer to a network share where the data actually lives. Users will still store files in their personal folders, but the user data won’t be roamed, so it will not affect the time required to load the profiles at logon.

Folder redirection is fundamentally very simple. If you go to HKCU\Software\Microsoft\ Windows\CurrentVersion\Explorer\User Shell Folders, you’ll see every folder in your profile and the current location of that folder. If Folder Redirection is not turned on, then all entries will look like this: %USERPROFILE%\Music. The goal is to get rid of the %USERPROFILE% variable and replace it with a new location.

You can’t redirect all folders, but you can redirect the ones with the biggest impact on profile size. These folders are

• AppData(Roaming) Contains a user’s application settings that are not computer-specific and therefore can roam with the user

• Desktop Contains any items a user places on his desktop

• Start Menu Contains a user’s Start menu

• Documents Contains documents saved to the default location

• Favorites Contains a user’s Internet Explorer favorites

• Music Contains a user’s music files saved to the default location

• Pictures Contains a user’s pictures saved to the default location

• Video Contains a user’s video files saved to the default location

• Contacts Contains a user’s contacts saved to the default location

• Downloads Contains a user’s downloads saved to the default location

• Links Contains a user’s Favorite links from Internet Explorer

• Searches Contains a user’s saved searches

• Saved Games Contains a user’s saved games

Before you redirect these folders, you need a place to redirect them to. Create a shared folder on the server where you want to store the redirected folders and set permissions on this folder according to the user profile folder permissions that were described in Table 5-5.

To redirect the folders to this share, open the GPMC, create or select an existing user GPO, right-click it, and choose Edit. Go to User Configuration | Policies | Windows Settings | Folder Redirection, as shown in Figure 5-22.

Figure 5-22 Set the Folder Redirection policy.

Right-click the AppData(Roaming) folder and choose Properties to open the dialog box shown in Figure 5-23.

Figure 5-23 AppData(Roaming) Folder Redirection properties dialog box

To specify the location of the AppData(Roaming) folder, choose between two options in the Setting drop-down menu.

• Basic Redirect Everyone’s Folder To The Same Location This means just what it says; all AppData(Roaming) folder data for every user will go to the same location.

• Advanced Specify Locations For Various User Groups To store user data in different locations based on user group membership, choose this option.

The menu contents will vary depending on the type of folder redirection you choose. If you choose Basic, then you get a Target folder location drop-down menu with three choices.

• Create A Folder For Each User Under The Root Path Choose this option to put each user’s profile data into a folder under the root path named according to the user name. In the Root Path text box, specify the location of your designated Folder Redirection share. In most cases, this is the best option.

• Redirect To The Following Location Choose this option to redirect all user data to the same location. You’d do this if you wanted all users to use the same Desktop or Start Menu folder. Choose this option only if you want everyone to write to the same user-specific folders.

• Redirect To The Local Profile Location Don’t choose this option. Your profiles roam, and you want your profile folders redirected to the network share.

Click the Settings tab, as shown in Figure 5-24.

Figure 5-24 Grant The User Exclusive Rights To AppData(Roaming) is enabled by default. Clear this check box to let administrators manage the redirected folder.

By default, Grant The User Exclusive Rights To AppData(Roaming) is enabled. If you leave it this way, then the user will own this folder, and only she will be able to access this data. To enable managing this folder, clear this box so that the rights from the parent folder will be inherited. For example, if you give Domain Admins full control of the parent folder, then this group will have access to the redirected user folders as well.

If your users already have these folders before you set up Folder Redirection, then you must set up the existing folders in one of two ways (otherwise, Folder Redirection will fail).

• The user needs to be the owner of the folder and can be granted exclusive rights to the folder.

• If the user does not need to be the owner of the folder, clear this box.

All the folders listed in this GPO section have the same choices to pick from, except for the Pictures, Music, and Video folders. These folders have an extra setting that you can choose for the location of the folder: Follow The Documents Folder. This means that these folders will be stored in the user’s Documents folder, wherever that folder is redirected.

To move the contents of the existing folder to the new folder outside the profile, select the Move The Contents Of “The Name Of The Folder Being Redirected” check box to the new location.

Sharing Personal Folders Between Local and Remote Environments

Because the RemoteApp programs are designed to blur the line between the remote computer and the local computer, it might make sense for you to help this along by using the same folder to store user-specific documents. This eliminates the problem of having to remember whether you were saving a file from a local or a remote application to know where the file would be stored.

Sharing Folders Between Windows Server 2003 and Windows Server 2008 R2 Roaming Profiles

The easiest profile environment to manage is homogenous: All users work only in RD Session Host servers, and all servers of sessions are running Windows Server 2008 R2. However, there are good reasons why you might need to support both V1 and V2 profile structure at the same time.

• Some users work both on the RD Session Host server and on VMs running Windows XP (perhaps because they’re using RemoteApp on Hyper-V).

• You’re migrating to Windows Server 2008 R2 RDS from Windows Server 2003 Terminal Services, and some of the older servers are still in use as you convert.

V1 profiles and V2 profiles are not compatible. Therefore, if you have some active 2003 RD Session Host servers, you will need to keep two sets of profiles for your users—one to log on to the 2003 servers and one to log on to the 2008 servers. And you might need even more profiles if users are also using pooled and personal VMs, and/or RemoteApp programs on Hyper-V. However, Folder Redirection can be used to bridge the gap.

Not all 13 folders that can be redirected in Windows Server 2008 R2 can be redirected in Windows Server 2003, but some can. You can share the data in these folders between the 2003 profiles and the 2008 profiles. On the Settings tab of each folder in the Folder Redirection container is an option called Also Apply Redirection Policy To Windows 2000, Windows 2000 Server, Windows XP And Windows Server 2003 Operating Systems. For some folders, this option is available, but on others (the ones that will not redirect for downlevel operating systems), it appears dimmed and is unavailable. Table 5-6 shows which of the folders can be redirected for Windows 2000, Windows XP, and Windows Server 2003.

Table 5-6 Profile Folder Redirection Capabilities for Various Versions of Windows

Setting Standards with Mandatory Profiles

One issue with roaming profiles is that users can change them. On the one hand, that’s the point. On the other hand, changes can cause problems. If users can change their profiles, they can delete icons, accidentally resize their toolbar so that it disappears, add wallpaper that slows their logon time, and so on.

One way to avoid this is to set policies controlling what users can and cannot do, and Chapter 7, “Molding and Securing the User Environment,” explains how to do this. Another way to prevent users from making permanent changes to their profile is to make the user profile read-only. A user can change settings, but those settings will not be saved when the user logs off the RD Session Host server.

Profiles that don’t change are called mandatory profiles. Mandatory profiles on a central store are copied to the RD Session Host server at logon, but they are not copied back at logoff. Any profile changes that occur are discarded at the end of the user session. Many companies will not implement mandatory profiles because users find them too constricting, but combined with Folder Redirection, they might give your users enough flexibility. Some third-party profile solutions also require the use of mandatory profiles—it depends on how the products are implemented.

Although it’s possible to give every user a unique mandatory profile, it’s not ideal. One of the best things about mandatory profiles is that because the profile will never be changed, all users can use a single mandatory profile, creating much less maintenance work for administrators. If a change needs to happen to the profile, there is only one place to make the change, instead of many if every user had his or her own individual profile.

Mandatory profiles are great in many respects, but you need to be careful when implementing them to make sure each user who logs on will not be susceptible to registry changes from other users. See the Direct from the Field sidebar that follows for more details.

Converting Existing Roaming Profiles to Mandatory Profiles

Setting up mandatory profiles is very similar to setting up roaming profiles using Group Policy. To convert a roaming profile to a mandatory profile, you first need to have roaming profiles working, either by setting the RDS Roaming Profile path in the user’s account properties in Active Directory Users and Computers, or by using Group Policy. For information on how to set up roaming profiles, see the section entitled “Using Group Policy to Manage Roaming Profiles”, earlier in this chapter.

Assuming you have roaming profiles implemented, when a user logs on, her profile is stored in a subdirectory of the designated roaming profile share. To make the user’s profile mandatory, in the user’s profile folder, locate NTUSER.DAT and change its extension to .man (see Figure 5-25). Then change the NTFS permissions for the user from Full Control to Read & Execute (so she can’t change the extension back). The next time the user logs on, she will be using a mandatory profile.

Figure 5-25 To convert a roaming profile to a mandatory profile, change its extension.

No changes that the user makes to the profile will be saved. But combining mandatory profiles with Folder Redirection will give users some control over their session and allow them to change their Favorites, Documents, Desktop, and other settings without compromising the configuration data loaded in HKCU.

Creating a Single Mandatory Profile

If you have many users, you probably won’t want to convert each roaming profile to a mandatory one—that would negate one of the main reasons to implement mandatory profiles: less configuration and maintenance. To give everyone the same experience, you can create one mandatory profile for everyone to use. Here are the steps to do so.

1. Create a network share to store the mandatory profile (for example: //Colfax/ASH-Mandatory-Profile). Make sure to configure the permissions on this folder correctly. Table 5-7 and Table 5-8 outline the necessary share and NTFS permissions that need to be set on this folder.

   Table 5-7 Share Permissions for a Mandatory Profile Storage Folder

   User Account	Share Permissions
   Administrators	Full Control
   Authenticated Users	Read

   Table 5-8 NTFS Permissions for User Accounts for a Mandatory Profile Storage Folder

   User Account	NTFS Permissions
   SYSTEM	Full Control, this folder, subfolders, files
   Administrators	Full Control, this folder, subfolders, files, Owner
   Authenticated Users	Read & Execute, this folder, subfolders, files

2. Create a folder within the folder created in Step 1, name it something appropriate to indicate it is a mandatory profile, and append the .V2 extension (for example: ASH.RDS.MAN.V2).

3. Because using the Copy To button now works only for the Default user profile, this is the profile you will copy to the share you created in Step 1. On the RD Session Host server, from Server Manager, click Change System Properties and select the Advanced tab. In the User Profiles section, click Settings. Highlight the Default User, and click Copy To. In the Copy To dialog box, type or browse to the shared folder location that you created in Step 1. Click Permitted To Use, add Everyone, and click OK.

   NOTE

   If you choose to create a customized mandatory profile, use Sysprep to overwrite the Default User profile on the machine that you will copy from. For more on customizing the default user profile and using the Copy To button, and how to use Sysprep to customize the Default User Profile, see the sections earlier in this chapter entitled “Converting an Existing Local Profile to a Roaming Profile” and “Customizing a Default Profile”.

4. Rename NTUSER.DAT in the resulting profile (in the file share created in Step 1) to NTUSER.MAN. You will need to change the folder options to show hidden files and folders to see this file.

5. Create appropriate GPOs by doing the following.

   • Edit the Computer GPO setting as follows: Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Set Path For Remote Desktop Services Roaming User Profile to point to the share created in Step 2, for example: //colfax/ ash-rds-mandatory-profile/ASH.RDS.MAN). Do not include the .V2 extension.

   • Enable the Computer GPO policy setting as follows: Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Use Mandatory Profiles On The RD Session Host Server

   • Enable the Computer GPO settings as follows: Computer Configuration | Policies | Administrative Templates | System | User Profiles | Add The Administrators Security Group To Roaming User Profiles

6. Apply the GPOs to the RD Session Host Server OU (in Group Policy Manager on a domain controller).

7. Reboot the RD Session Host servers and test by logging in as a regular user.

Creating a Safe Read-Only Desktop

One curious side effect to not being able to save anything to a mandatory profile is that any folders remaining in the profile (that is, not redirected) will not save changes either. For example, if you do not redirect the Desktop folder and if users save files to the desktop, those files will be discarded when they log off. There won’t be any error, and the file will be on the desktop during the session, but the files won’t be there when the users log on again. To put it mildly, this could be confusing. However, if you’re using Remote App programs, you don’t really want people saving files to the desktop because not being able to see the desktop will make those files hard to find.

To keep the desktop read-only but make sure people know it is read-only, redirect the desktop to a read-only folder as described in the section entitled “Centralizing Personal Data with Folder Redirection” earlier in this chapter. This will both prevent users from saving files to the desktop (which you want) and alert them to the fact that they can’t save files to the desktop (which you also want). If they try, they will get an error. They still can’t save anything to the desktop, but at least they will know that they can’t.

Decrease Logon Times with Local Mandatory Profiles

The main reason to house a mandatory profile on a network share is to make it easier to update when you have a farm environment. But it’s also worth noting that logon times can be decreased significantly by keeping a mandatory profile local to the server because the profile doesn’t get pulled down from the network share when the user logs on.

Maintaining local mandatory profiles is more work, because any changes to the mandatory profiles will need to be made to the mandatory profile on each server. But the increase in logon speed might make this worthwhile to you, especially if you have only a few RD Session Host servers in a farm or you don’t often need to change the profile. Again, testing this fully in your environment will tell you if it makes sense for your setup.

To use local mandatory profiles, perform the following steps.

1. Create a folder on each machine called something like “Mandatory_Profile.V2” and set the appropriate NTFS profile folder permissions as specified in Table 5-8.

2. Copy a default profile to the new Mandatory Profile folder, giving Everyone permission to use it when you perform the copy.

3. Convert this local profile to a mandatory profile by changing the extension of NTUSER.DAT to make it NTUSER.MAN.

4. Enable the GPO setting as follows: Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Use Mandatory Profiles On The RD Session Host Server.

5. Enable the Computer GPO setting as follows: Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Set Path For Remote Desktop Services Roaming User Profile. Point to the local mandatory profile location, such as C:\Mandatory_Profile. Do not include the .V2 extension.

6. Do this on each machine in the farm or pool.