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.
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:
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.
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.
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.
There are three major considerations/trade-offs when deploying user profiles in a Remote Desktop Services environment:
Central management of user data and settings
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
-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
-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
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.
Lockdown with mandatory profiles:
Remote Desktop farm considerations:
RD Virtualization Host:
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:
Any comments on my article? Or further explanations why the functionality was added?
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).
L’équipe Technique Terminal Services (alias Remote Desktop Services ) vient de publier un
Thanks for the explanation. I have updated my blog post (see above) accordingly.
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?
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!
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
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.
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.
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?