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 4 and 3 and type the answer here:
  • Post
  • Hi Samuel,

    Please see blog here for info on creating a default profile:  http://blogs.technet.com/deploymentguys/archive/2009/10/29/configuring-default-user-settings-full-update-for-windows-7-and-windows-server-2008-r2.aspx

    Olga

  • I am setting up remoteapps and plan to use the rdweb for customers to access them over the internet.  My question is do I need rdgateway as well?

  • To provide access over internet you would also need to configure RD gateway unless you already have VPN, Direct Access or some other solution setup to let clients from internet to access internal company sites/shares/etc.

  • I am sorry this is still not clear to me.  I believe, if the RDweb has an external ip mapped to it and I could access it over the internet, I would not need RDgateway.  Is there another reason for RDgateway, say for security, is RDweb secure in of itself?  All the documents for RDgateway seem to be written with remote desktop in mind and not remoteapps.

    Thank you for your quick response.

  • Yes, RD Web Access is secure. You can use form-based authentication to connect to RD Web Access and acces both desktop and applications.

    -Janani [MSFT]

  • RDWeb only delivers RDP files and an activeX client, it does NOT provide a secure tunnel to a RSDH or VDI host.  Without RD Gateway, you'd need to open 3389 to eacdh RDP host, and have a public IP for each.  Bad idea, and RD Gateway is free.

  • > 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.

    Sorry, I think I din't get it. Say we've implemented Roaming user profiles enterprise-wide. Is it okay for a user to be simultaneously logged on into his laptop and desktop?

    I fully understand that only one version of a roaming user profile can be stored/written at the same time. So if I log off my laptop and log off my desktop in five minutes then only the set of profile customizations made on my destkop will be present when I log on anywhere next time.

    But keeping in mind this limitation I believe that simultaneous log on into different computers with the same roaming profile is supported. So what's wrong if one of these computers is RD Server?

  • Hi Artem,

    As you mentioned that when you share a profile across laptop, desktop, you will lose customizations made on whichever machine you logged off first (since only last write will be saved). Same will apply if that first machine you log off of is the RD server - if you make any customizations during your session, you will lose them when you log off your 2nd machine later. This is very confusing to users (imagine you spent quite a bit of time customizing your Word defaults like font size, colors, etc. in your RD session and then you lose them if your roaming profile is shared with your physical desktop on which you didn't even use Word). The situation would get even worse if for some reason you didn't redirect your documents folders via FR.. users would then lose data.

  • Hi Artem,

    As you mentioned that when you share a profile across laptop, desktop, you will lose customizations made on whichever machine you logged off first (since only last write will be saved). Same will apply if that first machine you log off of is the RD server - if you make any customizations during your session, you will lose them when you log off your 2nd machine later. This is very confusing to users (imagine you spent quite a bit of time customizing your Word defaults like font size, colors, etc. in your RD session and then you lose them if your roaming profile is shared with your physical desktop on which you didn't even use Word). The situation would get even worse if for some reason you didn't redirect your documents folders via FR.. users would then lose data.

  • Okay, I think I finally got the point.

    If we aren't supposed to make (or reliably keep) any profile customizations there's no real problem to be simultaneously logged on into multiple computers (whether they are RD servers or not). But in this case there's nearly no value of centrally stored profiles at all. We could achieve a similar result by just copying the same default profile to all the computers or something like that.

    If we expect the profile changes to be saved and want to log on into multiple PCs simultaneously then it's becoming too complex and too hard to educate a user that first he/she needs to log off all the computers but the one from which he/she wants the profile to be finally saved. And new background profile upload feature (which is certainly a good thing) makes this even more complex.

  • I have a simple RDP server with about 25 users that does not run active directory.  Since I can't run active directory I am having trouble finding a way to create profiles for connections to this server using RDP.  When I ask I am always told just use active directory but I can't.  Is there a way to do this without using active directory?

  • Does anyone know how to lock down roaming profiles for Remote Desktop Services.

    profiles are stored on a network drive, and currently if a authenticated user browses to that UNC, they can see everyones profiles. ideally i would like for someone to only see their folder.

    Cheers

    Dennis.

  • Do you have any PS1 command which we can use to uncheck the option 'Deny this user permissions to logon to Remote Desktop Session Host Server' for bulk users from Remote Desktop Services Profile tab. This is bit urgent!! When option is selected users are not able to connect to terminal server when using citrix and wanted to remove the option...

  • how can we enable or disable 'Deny this user permissions to logon to Remote Desktop Session Host Server' for bulk users from Remote Desktop Services Profile tab. Also, how do we generate report based on this?

Page 2 of 2 (29 items) 12