User Profiles on Windows Server 2008 R2 Remote Desktop Services

User Profiles on Windows Server 2008 R2 Remote Desktop Services

Rate This
  • Comments 29

Introduction:

This blog post contains a high-level overview of different types of profiles, considerations for choosing a profile solution for your deployment, highlights of new profile features in Windows Server 2008 R2, and a best practices recommendation for deploying roaming user profiles with folder redirection in a Remote Desktop Services environment.

Terminology

Below are some basic definitions for background understanding of different types of profiles and folder redirection.

· Local user profiles

A local user profile is created the first time a user logs on to a computer. The profile is stored on the computer's local hard disk. Changes made to the local user profile are specific to the user and to the computer on which the changes are made.

· Roaming user profiles

A roaming user profile is a copy of the local profile that is copied to, and stored on, a server share. This profile is downloaded to each computer a user logs onto on a network. Changes made to a roaming user profile are synchronized with the server copy of the profile when the user logs off. The advantage of roaming user profiles is that users do not need to create a profile on each computer they use on a network.

· Mandatory user profiles

A mandatory user profile is a type of profile that administrators can use to specify settings for users. Only system administrators can make changes to mandatory user profiles. Changes made by users to desktop settings are lost when the user logs off. Mandatory profiles can be created from roaming or local profiles.

· Temporary user profiles

A temporary user profile is issued each time an error condition prevents the user's profile from loading. Temporary profiles are deleted at the end of each session, and changes made by the user to desktop settings and files are lost when the user logs off. Temporary profiles are only available on computers running Windows 2000 and later.

· Folder redirection

Folder redirection is a client-side technology that provides the ability to change the target location of predetermined folders found within the user profile. This redirection is transparent to the user and gives the user a consistent way of saving their data, regardless of its storage location. Folder redirection provides a way for administrators to divide user data from profile data. This division of user data decreases user logon times because Windows downloads less data. Windows redirects the local folder to a central location, giving the user immediate access to their data when they save it, regardless of the computer they are using. This immediate access removes the need to update the user profile.

There are two primary benefits to Folder Redirection as it applies to profile data:

  1. When used with roaming profiles, it can significantly reduce the size of the portable profile data carried around by users for logon/logoff. Since these folders are redirected to network shares, you trade local I/O impact for network/remote I/O impact. This can be very helpful on disk-constrained deployments.
  2. Using Folder Redirection with mandatory profiles allows users to have some control/persistence of customization such as application configuration settings (AppData) or IE Favorites.

Highlights of what’s new in Windows Server 2008 R2

RD farm logon performance improvement

First logon to a machine in a server farm is typically slow because of synchronous Group Policy processing, and subsequent logons are faster when Group Policy is asynchronous. In WS08 R2, the GP cache is roamed between the servers of the farm so users should only experience the delay during first farm logon and get a faster logon experience for subsequent logons to all members of the farm.

Roaming user profile cache management

An RDS environment can potentially have hundreds of distinct users. Whereas caching of roaming user profiles is enabled for a better user experience, this profile cache can grow very large and may potentially overrun the available disk space on the server. Controlling the cache size of individual user profiles may not be effective on the RDSH server, because there can be hundreds of new, distinct users.

A new Group Policy setting is available for RDS in WS08 R2 that limits the size of the overall roaming profile cache (located in %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 the following location: Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Profiles\Limit the size of the entire roaming user profile cache.

User profile hive cleanup is not needed starting with WS08 and Vista

Prior to WS08 many customers downloaded the UPHClean service to prevent profile corruption problems caused by applications and processes maintaining connection to registry keys in the user profile after logoff.

In WS08 and Vista, there is no need for UPHClean because this functionality (and more) is now performed by the User Profile Cleanup Service that is built into the operating system. Thus you will not be able to find a version of this tool for Vista/WS08.

Profile considerations and trade-offs

There are three major considerations/trade-offs when deploying user profiles in a Remote Desktop Services environment:

  1. Central management of user data and settings:
    • It is important to centrally store user data and settings so that users get a consistent experience regardless of which server on the farm they connect to.

    • Thus it is not advisable to deploy local profiles on a Remote Desktop Session Host, especially if it will eventually be part of a farm deployment.
  2. Performance:
    • Synchronous user Group Policy processing, large profile sizes, large numbers of user Group Policies, and slow links between RDS and profile servers are the most common factors that significantly slow down logon.
      • To avoid the overhead of synchronous user Group Policy processing on every logon, turn on asynchronous Group Policy processing as described below. It can take 2 to 3 logons for new policy settings to take effect.

      • To avoid large profile sizes, we recommend that you configure roaming user profiles for registry settings and folder redirection for all other parts of the user profile. In addition, you can set a policy to limit the profile size.

      • To reduce large number of User GPs, you could re-scope your policies (e.g. apply to a different group or OU) to reduce the number of GPs that apply to the server at user logon.

      • RD Session Host or RD Virtualization Host should have a fast connection to Active Directory and to the SMB share where roaming user profiles and redirected folders are stored (e.g. in same datacenter).
  3. Application compatibility:
    • Some applications may impact logon performance if, for example, they record a lot of data into the registry, bloating the profile size. Thus it is generally recommended to set up folder redirection for the AppData folder as described in the Step-by-step best practices guide below.
      • However, some applications may have issues when they are deployed along with folder redirection. Thus as described below, there are special considerations for redirecting the AppData folder.

    • If a problematic application writes data to outside the standard profile locations or bloats the size of the profile while the AppData folder cannot be redirected, you can use Microsoft Application Virtualization (App-V) to deploy that application.


    Considerations and Trade-Off Summary
     

    Central management of user data and settings

    Performance

    Application compatibility

    User data management method

         

    Local user profiles

    Not suitable for RDS farm scenarios

    Faster logon experience

    Does not introduce app compatibility issues

    Roaming user profiles

    -User data and settings backed up centrally

    -Recommended in RDS farm scenarios

    Roaming profile downloaded over network, can slow down logon/logoff

    Applications may bloat profile size

    Mandatory profiles

    -Changes to users settings not preserved since a standard profile is applied

    -Can be useful in locked-down environments

    Standard profile size ensures consistent logon performance

    Does not introduce app compatibility issues

    Folder redirection

    -User data backed up centrally (but not registry)

    -Used in combination with different profile types

    Can help improve logon speed when roaming profiles are deployed by reducing the size of roaming profile

    Redirection of AppData folder may cause application compatibility issues – details in step 5 below

Best practices for a typical RDS deployment

Step-by-step best practices guide to deploying profiles on RD Session Host:

Configure roaming user profiles for registry settings and folder redirection for user and application data folders to improve logon and logoff performance while centrally managing user data and settings. It is best to keep the size of roaming user profiles small because they are downloaded at logon and uploaded back to the server at logoff, increasing logon and logoff times.

  1. Set up an SMB share on a file server to store roaming user profiles and ACL it correctly as described on page 28 of the Managing Roaming User Data Deployment Guide.
    • For better logon/logoff performance, the file server on which the profiles are stored should be located in the same datacenter as the RDS servers.

    • Ensure that you turn off Offline Folders for shares where roaming user profiles are stored in order to avoid synchronization issues as per this KB article.
  2. Set up RD Session Host roaming profile path
    • Roaming profiles should be configured separately for each RD session farm. They should not be shared between farms or user’s physical desktops since profile corruption and data loss may occur if a user is simultaneously logged into two machines that load the same user profile.

    • Configure the following Group Policy on the RD Session Host:
      • Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Profiles -> Set path for Remote Desktop Services Roaming Profiles
  3. Limit the size of overall profile cache
    • Caching roaming user profiles is recommended to improve logon/logoff speeds. Roaming user profiles are cached by default. Also, a common best practice is to cache profile data on a separate drive to optimize data access speed.

    • In a large deployment with hundreds of users, leaving these caches on the RD Session Host can cause the server to run out of disk space. 
      In WS08 R2, there is a new Group Policy setting for the Remote Desktop Session Host to limit the size of the overall profile cache on the server

    • Configure the “Limit the size of the entire roaming user profile cache” policy under Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host –> Profiles

    • If you enable this new Group Policy setting you should not need to delete user profile caches at logoff.
  4. Configure background upload of registry settings
    • By default, roaming user profiles are saved to the server only at logoff. Thus, to ensure that changes to the user profile are saved back to the server (if, for example, the user does not frequently log off) it is recommended that you enable the following Group Policy which is new in WS08 R2:
      Computer Configuration -> Administrative Templates -> System -> User Profiles -> Background upload of a roaming user profile’s registry file while user is logged on
  5. Configure Folder Redirection for all user data folders.
    • Please follow the instructions in this TechNet article to redirect all user data folders listed on page 7 of the Managing Roaming User Data Deployment Guide.
      Ensure that you set correct permissions on the share as per instructions in this article.

    • Special considerations for AppData\Roaming folder:
      If the AppData folder is redirected, some applications may experience performance issues because they will be accessing this folder over the network. If that is the case, it is recommended that you configure the following Group Policy setting to sync the AppData\Roaming folder only at logon and logoff and use the local cache while the user is logged on. While this may have an impact on logon/logoff speeds, the user experience may be better since applications will not freeze due to network latency.
      User configuration>Administrative Templates>System>User Profiles>Network directories to sync at Logon/Logoff.
      If applications continue to experience issues, you should consider excluding AppData from Folder Redirection – the downside of doing so is that it may increase your logon/logoff time.
  6. Enable asynchronous Group Policy processing
    • Synchronous Group Policy processing may significantly decrease logon performance, thus it is recommended to configure the following policy: 
      “Allow asynchronous user Group Policy processing when logging on through Remote Desktop Services” 
      It is found under Computer Configuration->Policies->Admin Templates->System->Group Policy

Lockdown with mandatory profiles:

  • Use mandatory profiles if you have a locked-down environment (for example, a call center) which does not require preserving user settings. Benefits of this approach are that users will get a fast and consistent logon/logoff performance as well as the same predictable experience when they connect.
  • When using mandatory profiles it is recommended to also use folder redirection for user data as mentioned in step 5 above.
  • To configure mandatory profiles, please follow the instructions on page 30 of the Managing Roaming User Data Deployment Guide.
  • Note: Windows only allows for the entire user profile to be mandatory or roaming. There are solutions available from RDS partners that offer more flexibility.

Remote Desktop farm considerations:

  • As mentioned above, it is recommended that you configure separate roaming user profiles and folder redirection paths for each farm to avoid data loss and corruption issues if there is a chance that a user can simultaneously log onto more than one farm.
  • WS08 R2 has farm logon improvement:
  • First logon to a machine is typically slow because of synchronous Group Policy processing and subsequent logons are faster when Group Policy is asynchronous. In WS08 R2, the GP cache is roamed between the servers of the farm so users should only experience the delay during the first farm logon and get a faster logon experience for subsequent logons to all members of the farm.

RD Virtualization Host:

  • Pooled virtual machines: You can configure roaming user profiles with folder redirection just as in the RD Session host case (see above) to centrally manage user settings and data.
  • Personal virtual machines: Configure roaming user profiles with folder redirection just as in the RD Session Host scenario or manage user data such as on a physical desktop (local user profiles can be used depending on the scenario requirements). Please refer to the Managing Roaming User Data Deployment Guide for more general information on user data management.
Leave a Comment
  • Please add 7 and 8 and type the answer here:
  • Post
  • PingBack from http://asp-net-hosting.simplynetdev.com/user-profiles-on-windows-server-2008-r2-remote-desktop-services/

  • I have written an analysis on the new setting "Background upload of a roaming user profile’s registry file while user is logged on" here:

    http://blogs.sepago.de/helge/2009/04/02/microsoft-tackles-the-last-writer-wins-problem-of-roaming-profiles-in-windows-7-server-2008-r2/

    Any comments on my article? Or further explanations why the functionality was added?

  • Hi Helge,

    The background roaming key was not aimed to solve the last writer wins problem (as you noted in your analysis). It would help some other scenarios though (e.g. user never logs off laptop so their profile is uploaded in the background in order for data not to get lost).

    Thanks,

    ~Olga

  • Hi Helge,

    The background roaming key was not aimed to solve the last writer wins problem (as you noted in your analysis). It would help some other scenarios though (e.g. user never logs off laptop so their profile is uploaded in the background in order for data not to get lost).

    Thanks,

    ~Olga

  • L’équipe Technique Terminal Services (alias Remote Desktop Services ) vient de publier un

  • Hi Olga,

    Thanks for the explanation. I have updated my blog post (see above) accordingly.

    Regards, Helge

  • Hi,

    Just a quick question regarding the appdata\roaming redirection stage.

    If you have an application that uses appdata\roaming quite extensively then you reccommend that it is stored local and not across a network.  (I have some of these apps)

    I'm not overly familiar with the sync option that you state, but if you specify that it should sync those folders at logon/off isn't that in effect the same thing as including it in the profile?

  • Hi Mark,

    One of the major differences between Roaming User Profiles and Folder Redirection technologies is that FR does differential syncing (so if only part of a file was changed, that part will get uploaded/merged) whereas RUP will upload the entire file so you will see faster logon/logoff times with FR.

    If possible, could you provide some more info about your apps - e.g. name of the app, why it writes extensively to app data while user is logged on; any other issues you've experienced with roaming profiles/FR. This will help us in planning for future releases!

  • Hi,

    Thanks for that, so whilst you are saying  that on W2k8 I'm best off using redirected folders and the sync option (if i have app issues).  Logon speed would be the same as for roaming profiles but logoff would be quicker.

    It would be nice if logon only downloaded the blocks that were needed, something akin to the App-V method of streaming FB1 on logon then additional blocks as they were needed by applications / systems.  RTO have something that sounds like this http://www.rtosoft.com/Products/VirtualProfiles/VP.htm

    This would mean that on logon it would download the complete appdata\roaming but on logoff would only upload the blocks that have changed.

    In all honesty the pain point is logon because users don't really care how long it takes to logoff, so based on the KISS policy i'd be better off using full roaming or redirected and not hashing something in between.

    With regards to the app, it was in a previous life, running an Access 2k3 database on W2k3, haven't tried with W2k8

  • Hello,

    This is a great article and it was just the thing I was looking for.  It is hard to find this kind of in-depth information.  I setting up a Server 2008 terminal server test environment with Citrix XenApp 5, Citrix Provisioning Server, App-V, and AppSense Environment Manager for profiles.

    AppSense is a "profile streaming solution" to those not familiar with it.  You basically configure mandatory profiles and it independently captures user personalization data into a database.  I won't go on about it, I am just mentioning it so you know my situation before asking my question.  Between this and provisioning server I have some unusual challenges in my roaming profile design.

    My question is, there is this group policy setting that intrigues me.  It is here:

    CC\AT\WC\Terminal Services\Terminal Server\Profiles\Set TS User Home Directory

    From reading the description, it seems that this would in effect allow you to completely re-locate the "Documents and Settings" (2003) or "Users" (2008) folder.  This was something I always thought to be a "special trick" that Microsoft did not always support.

    I am wondering if this really does what it says it does and what this is typically used for.  My guess is that this is what you would do if you had two physical local disks and you wanted to make user profiles seperate from your OS disk.  Nice ability, but it also allows you to locate it on a network share, which surprises me since you guys are talking about the dangers of just redirecting AppData let alone the whole profile including temporary data.  So I am wondering under what cercumstances one might use this setting.

    I just looked at it and said "I wouldn't think they would let you do that".  Right next to it is the policy I exepected to see "Set path for TS Roaming User Profile" which has the typical behavior of roaming profiles cached locally, etc.  I am assuming you could combine these two settings as well.

    Even so, I am comparing this group policy setting to simply specifying the path per-user as we have traditionally done.  And that leads me to the place where I am now.  There are basically about 10 different ways to do this, what is best?

    Yes, my next step of course is to read "Managing Roaming User Data Deployment Guide" and the other guides and links on this page, but I will take notes as I read to expand on some of these little details that are basically just a little deeper than that details on the different types of profiles described here.

    I just joined this blog and this is my first post, so I don't want to write a book here.  But it looks like you all are the right place to field my dilemma.

    Regards

    Jeff_eot

  • Hi Jeff,

    That policy setting doesn't do what you think it does.  It allows you a central place to configure the user settign Home Dierctory.

    The home directory is the default path for cmd.exe, windows environment settings in a TS environment and is placed in the path.

    It doesn't allow you to specify where the users or documents and settings path is.

  • I am having difficulty understanding what happens when a terminal server user accessing an RDP remote app logs on to the W2k8R2 64 bit server verses what happens when that same user logs on locally to the W2k8R2 server console. Looking at the profile of the TS logged on user all folders are yellow, some create a windows folder some do not while the locally (at the server console) logged on user has virtual folders and the windows folder. An application I am running using remote app behaves differently based on from where the user logged on, it behaves correctly when the user logs on locally (at the server console) and there after from a TS logon but a TS client only logon only causes some features of the application to fail, not the entire application just some features. Any help would be appreciated.

    Clients are XP Pro SP3, Domain is Windows 2K3.

  • What happened to "copy to" for user profiles?  Now the option is greyed out unless you select "default profile".  We use "copy to" to create roaming profiles after setting up the local profile.

    Any ideas?

  • We've been discussing this with thee RDS Team.  It feature is no longer there.

  • Then, how can we customize a default profile for all users to start?  Using file level copy?

Page 1 of 2 (29 items) 12