For anyone that has ever worked with XenApp or XenDesktop you know that user profiles can be one of the most difficult things to get right.  This was one of the driving forces behind Citrix including a profile management solution as a standard component of all editions of XenDesktop.

I am not going to go into the details of the various types of profile strategies nor the reasons a more robust strategy than standard roaming profiles is required.  The need for a solution more robust that standard roaming profiles is already well understood and documented.  What I am going to cover in this article are some of the best practices for properly configuring the Citrix Profile Management solution.  The focus of this article will be configuring Citrix Profile Management for non-persistent Windows 7 VDI workloads.

All too often I have been on projects with customers, partners and co-workers where our Citrix Profile Management solution has been installed and simply enabled.  It seems like many people think that merely installing and enabling Citrix Profile Management will fix or improve their user profiles.  However, this could not be farther from the truth.  In fact, if you simply install and turn on Profile Management with the default settings, all you have basically done is give yourself a roaming profile. In fact, many times, you will have actually made things worse than a standard roaming profile!

Folder Redirection

At the heart of any good profile strategy is folder redirection.  This is a standard Microsoft feature that has been fully supported via Group Policy since the Windows 2000 days and is even something that has been done through custom registry changes since the NT 4.0 Terminal Server days.  Folder redirection is really the key to any successful profile solution.  Whether you are using standard roaming profiles, Citrix Profile Management or a third party solution such as Flex Profiles or AppSense, you must still enable folder redirection.

With Windows 7 Microsoft has significantly improved the folder redirection engine to include more folders.  By default you can know redirect the following folders using the built-in Group Policy engine in Windows:

  • AppData(Roaming)
  • Contacts
  • Desktop
  • Documents
  • Downloads
  • Favorites
  • Links
  • Music
  • Pictures
  • Saved Games
  • Searches
  • Start Menu
  • Videos

As part of any well designed profile solution, you should beredirecting all of the folders listed above. The only exceptions that should be made are for folders that you have no intention of persisting for the user. For example, some companies have no desire to allow users to keep Saved Games, so in that case you would not redirect the Saved Games folder and you would add a policy to exclude the Saved Games folder from synchronization or roaming.   By doing this, the Saved Games folder would only exist on the local VM and if the VM is non-persistent, it would be blown away at logoff/reboot.

One thing that you want to make sure that you enable in your folder redirection policy is the setting to move the contents to the new location.  The sample screen shot below illustrates the settings that I recommend customers select with folder redirection.

Folder Exclusion

Adding a policy to exclude the redirected or unwanted folders from roaming or synchronization is a common thing that is often overlooked.  When using Citrix Profile Management, there is a GPO that can be specifically configured to block folders from profile synchronization.  You should be adding all of the redirected folders to the folder exclusion list and you should also at a minimum add the following additional folders to the exclusion list: “AppData\Local”, “AppData\LocalLow”, and “Local Settings”.

Why should a folder be excluded if it is redirected? It needs to be excluded because you can still end up with orphaned folders that stay in the profile after redirection. Additionally, quite often poorly coded applications will still write to the non-redirected path, which causes the profile to bloat.  This is seen quite often when a programmer hard codes a path using %userprofile% instead of reading the shell folder value.

I cannot count how many times I have seen a programmer hard code their application data path as the following:

%userprofile%\Application Data\CrappyApp

If a developer hard codes using the %userprofile% variable, then it does not matter if AppData has been redirected, the application will still write to the local profile folder.

What they should do is code their application to use the %AppData% variable as follows:

%AppData%\GoodApp

By adding an exclusion rule for “Application Data” and for “AppData\Roaming”, you will prevent these poorly coded applications from bloating the profile.

To reiterate, you should be redirecting ALL folders available in the default Microsoft GPO and you should be excluding ALL those folders from profile synchronization.  Doing this will keep your profiles quite small, thus improving performance and significantly reducing IOPS.

Application Data

I know what some of you are already thinking, redirecting AppData can cause issues with some applications. Also, putting an exclusion rule to kill data written to %userprofile% might cause users personal settings to be lost.  Let’s face it, whether an application is coded correctly or not, users want their personal application data to persist between sessions.  There are easy ways to get around all of these issues; Folder/File Inclusion lists and Application Streaming. Let’s first see how inclusion lists can address some of the AppData issues.

Folder and File Inclusion Lists

Let’s pretend we have an application called CrappyApp.  The application developer made the rookie mistake of hard coding “%userprofile%\Application Data\CrappyApp” as the folder where user application data is stored. By redirecting the AppData folder and adding the exclusion rules to prevent “%userprofile%\Application Data” from roaming or synchronizing to the profile, any data that the application writes to the “%userprofile%\Application Data” directory will be lost when the user logs off.  If you are doing your job as an IT professional, you will identify this issue during testing before you roll out into production. If you do not catch it, it will not take long for users to call and complain that their CrappyApp settings are not being saved between logons.  This is actually a good thing, because now you know that you have a poorly coded application.  That means you can open a ticket with the application vendor or with the programming team if it is an in-house developed application so that you can get them to fix it.  I have run into this issue many times with 3rd party applications and with applications developed in-house by my customers. After explaining the situation to the programmers, they often acknowledge their mistake and fix it.  If they will not fix it or the fix will take too long, then you simply conduct an analysis to determine what files are being written to “%userprofile%\Application Data\CrappyApp” and which of those files should persist.  If the directory is small and does not contain much data, then you can create a folder inclusion policy to add the CrappyApp folder back to the profile for synchronization.

If the folder is large and has lots of files in it, then you should take a close look and figure out what exactly the application is writing and whether or not it really needs to persist. Since we already know that it is a poorly coded application, it is often not surprising to see temporary files or other junk being written to the folder that really does not need to persist. Often you will find that there is a small DAT file or a few INI files that contain all the user personalization settings that are important.  In this case you would create file synchronization rules that only copy the needed files back into the profile. This can be accomplished using wild card rules to synchronize “Application Data\CrappyApp\*.dat, *.ini”. By adding only the required files back to the profile via synchronization, we allow the poorly coded application settings to persist, but we still keep the profile small.

An application that requires this type of synchronization is Google Earth.  Google Earth writes its data to the “AppData\LocalLow\Google\GoogleEarth” folder.  By default, the AppData\Local and AppData\LocalLow folders are automatically excluding from Microsoft roaming profiles and we should also be adding these as excluded folders in the Citrix Profile Management policy.  Microsoft calls them “local” folders for a reason; they should not be on the network by default! For Google Earth it will store the cache file and other temporary data here.  The cache file is quite large and contains temporary data that does not and should not persist.  However, Google Earth also stores the user’s My Places and their KML files in this directory. These are small XML files with user personalization settings that should persist.  So if Google Earth is used, we add a file inclusion rule for “AppData\LocalLow\Google\GoogleEarth\*.kml”, so that these files persist without having to synchronize or roam the entire directory.  This keeps the user happy and keeps the profile small.

In addition to Google Earth, there some key Microsoft features that need this synchronization as well.  These include PKI certificates and Office tool bars.  For more information on the required file and folder inclusion rules for these features refer to the following CTX articles:

http://support.citrix.com/article/CTX130665

http://support.citrix.com/article/CTX124948

Application Streaming

Now that we have dealt with the applications that don’t put their data in a redirected folder by default, what about applications that just don’t like having their AppData folder redirected to a network share? Sometimes applications will crash or just not function correctly when the AppData folder is on a UNC path.  Older versions of Adobe products were notorious for this.  On a positive note, I can say that over the past couple of years this issue occurs less and less.  Most major application vendors are now familiar with redirected AppData folders and they code and test their applications against this scenario.  It is now very rare that I run into this issue. However, it still does occur.  I recently encountered a Java application at a customer that would crash every time it was run with a redirected AppData folder.  So how did I overcome this issue? Enter Citrix Application Streaming to the rescue!

By virtualizing or Streaming the Application with XenApp, we are able to isolate the application and issue new variable and path locations when the application is launched.  It is import to note that I am referring to the Application Streaming function of XenApp where the application is still executed on the Windows 7 virtual desktop. I am not referring to hosting the application on a XenApp server.

So how does Application Streaming help in this situation?  When a Streamed Application is launched we can specify a pre-launch script that executes first.  By modifying the isolated AppData location in a pre-launch script, we can change the AppData location for the streamed application without affecting other applications.

As an example, I have profiled the Office 2003 application suite.  Probably not the greatest application to use for this illustration since Office 2003 is fully compatible with redirected AppData, but I will use it nonetheless.

On the properties screen of the streamed application profile, you can assign a pre-launch script. Since we only want to modify the AppData location for our streamed application, it is important to run the script isolated.  See the screen shot below:

As you can see from the screen shot, I have specified that a script named setappdata.cmd will be launched in the isolation environment before any applications from the profile are launched.

Below is my script:

My script actually calls another script that I have hosted on a file server.  The reason I did this is so that it is easy to make updates to the script.  Whenever you put a script into a streamed application profile, it can be cumbersome to make changes to the scripts. So as a best practice, your script simply calls a master script from a shared location so that if updates are required, you do not need to open and modify the streaming profile.  For more details on this refer Joe Nord’s blog articles on scripts:

/blogs/2011/01/21/app-streaming-introduction-to-scripts/

/blogs/2011/02/04/app-streaming-global-scripts/

If we look at my script on the file server that gets called, you will see that it launches a VBS file.

Now let’s look at VBS file which does the real work.

The VBS script sets four registry keys within the isolated registry of the application:

  • It sets two AppData shell folder keys to point AppData back to %userprofile%
  • It sets two %AppData% environment variables back to %userprofile%

What we have done with this script is basically trick the streamed application into thinking the AppData folder was never redirected.

So now let’s see it in action.  The screen shot below shows my Windows 7 non-persistent desktop with a Streamed copy of Word 2003 running with my prelaunch scripts. I selected Open from the file menu and entered %AppData% as the directory to open.

As you can see from the screen shot, the AppData variable for Word 2003 resolved to %userprofile%\AppData\Roaming, which is on the C: drive.

Another way to see where the AppData variable resolves from the Streamed Application is to launch a command prompt from the Streamed application.  With Word, you can do this through the backdoor by creating a hyperlink to cmd.exe.  The screen shot below shows this.

I launched the CMD prompt from the Streamed Word instance so that the CMD prompt would also be isolated. Take note how the AppData variable points to the user profile path on the C: drive.

Now look what happens when I launch a CMD prompt from the local OS outside the isolation environment:

As you can see from the screen shot above, the local OS is still using a redirected AppData folder.  By using our pre-launch scripts, we were able to successfully redirect AppData back to the local C: drive without affecting other applications!

Since by default we should be excluding %userprofile%\AppData\Roaming from profile synchronization, anything that the Streamed Application writes to this location will be lost at logoff.  However, as we discussed in the previous section, if there are files or folders that do get written that you want to persist for the user, then you could simply add a synchronization rule so that this data is persisted for the user.

By properly leveraging Application Streaming and the folder/file synchronization rules that I have described here, there is absolutely no reason that you should avoid redirection of AppData. Any compatibility issue that you encounter with redirected AppData can easily be overcome!

Before I move on, I’d like to take a second to address some of the concerns that some people raise about application performance when redirecting AppData to a network path. First, let’s remember that we are talking about Virtual Desktops running on a Hypervisor.  In this scenario, the file share that is used for AppData folder redirection should be co-located in the same data center and should be highly connected to the virtual desktops. If you are a large enterprise, there is no excuse for connecting your file server or NAS to the network at less than 10 Gig or at the very least with multiple aggregated 1 Gig links.  When you properly design your file services infrastructure, you will NOT have any performance issues.  To put things into perspective, we use Provisioning Services to deliver the entire C: drive for the Windows 7 desktops over the network from a Windows server. When properly designed, nobody complains about performance issues having the entire C: drive mounted over the network. In fact, I have a production customer that is hosting the C: drive for 1500+ concurrent Windows 7 VDI VMs from a single Windows Provisioning Server VM, and there are no performance issues.  Check out the following article:

/blogs/2011/07/30/virtual-provisioning-server-%E2%80%93-a-successful-real-world-example/

So, if you are having performance issues redirecting a few folders for AppData over the network to a Windows or NAS server, you are doing something wrong.

Profile Streaming and Active Write Back

Profile streaming is a feature where the files that are part of the profile (files and folders NOT redirected) are copied down either in the background or only when actually accessed by the OS or applications as needed.  This can speed up the logon process. This can also reduce the total data downloaded because if a file is not actually used, then it is never fully copied down to the local profile directory.

This feature has some value; however, I too often see it used as a crutch for poorly architected Profile Management policies.  As we discussed in the previous sections, you should be redirecting ALL available folders, including AppData.  If you are following the guidelines that I laid out, then your UPM profile directory will actually be quite small.  In fact, if you have implemented Profile Management correctly, your UPM folder will most likely be less than 10 MB.

Here is a screen shot of what you should see in a properly configured UPM profile folder.

Take note how there are only 14 files, 27 folders and less than 1.2 MB of total data in this UPM folder. This is because all of the folder redirection and exclusion rules have been properly implemented. In this example, the user has Google Earth KML files and PKI certificates that must be saved / synchronized to AppData and the profile folder is still extremely small!

As discussed, when you have poorly coded applications or applications that do not work properly with redirected AppData, the folder and file inclusion rules will cause the AppData folder in the UPM profile to become larger in size.  I am actually a production user on one of my customer’s systems where I spend a lot of time onsite helping them with their implementation. Needless to say, I have properly implemented Profile Management and Application Streaming into the XenDesktop environment.  As part of my regular job duties, I use Internet Explorer, Adobe Reader, Outlook, Word, Excel, Lync, and several other applications. I have PKI certificates for email and web site identification and plenty of other things in my profile. For my profile, which is almost one year old and used on an almost weekly basis, my UPM directory contains 67 files, 71 folders for a total of 5 MB of data.  5 MB for a profile that is used regularly and almost one year old is excellent!  In most properly designed environments, the UPM Profile should rarely be larger than 10 – 15MB.  This is such a small amount that it should be of no concern from a logon/logoff perspective.

So using myself as an example, do you think I should enable Profile Streaming?  The answer is NO! Why should I care about 5 MB of file data being loaded at logon?  That will not cause any performance issues whatsoever.  So, if you have properly designed and implemented Profile Management, the Streaming Feature will be of little value and is not required.

With that being said, there are some limited situations where even with a properly designed Profile Management environment, you might still get some value from the Profile Streaming feature.  As discussed, if you have an application that is poorly coded or not compatible with AppData redirection, then you must add file/folder synchronization rules to allow some of the specific AppData folders to synchronize at logon.  If you end up having an application that writes a lot of data that needs to be synchronized, the Profile Streaming feature can reduce logon time and can reduce the total amount of data downloaded since the data will only be downloaded on demand when the application actually tries to use the files.

If you run into this situation, then feel free to enable and use the Profile Streaming feature.   One of the cool things about this feature is that it can be enabled for only specific user groups.  So rather than needlessly turn it on for everyone, when you have an application that can benefit from it, you should put those users into a group and only enable the feature for them.

The Active Write Back feature should be viewed in the same light as the Streaming Profile feature. If the profiles are large, then it can add value.  However, if you have implemented Profile Management correctly, then your profile should rarely have more than about 10 MB of data that needs uploaded at logoff, so Active Write Back is typically not needed.

Base Line Policy

Now that we have covered the basics of what you should be redirecting and configuring for Profile Management, I figured I would give you a sample GPO with the baseline policy settings I configure in regards to Profile Management and Folder Redirection.  For the sake of simplicity, I have rolled everything into one GPO.  Of course, these would need to be tuned and changed in order to be specific for a given production environment, but it will give you a good idea of what you should be configuring as a baseline.

You can download the GPO HTM report from the following link:

https://citrix.sharefile.com/d/sd561c6331d24ff9b

Additional References

Make sure that you rename the default INI settings file after installing Citrix Profile Management. You should be controlling UPM through Group Policy and not allow unknown settings to be applied via the INI file. You will find the INI file at:

“%ProgramFiles%\Citrix\User Profile Manager\UPMPolicyDefaults_V2Profile_all.ini”

Don’t forget to enable and add the Cookies folder to the Folders to Mirror policy and enable the processing of the Cookies at logoff.  Refer the following for more information:

/blogs/2011/01/25/notes-on-synchronising-internet-explorer-cookies-using-profile-management/

http://support.citrix.com/proddocs/topic/user-profile-manager-sou/upm-manage-cookies.html

If your users have PST files with Outlook, then make sure that you create policies that force the PST file go to the redirected AppData folder.  This keeps the PST out of the profile and eliminates the need to try and synchronize the PST file at logon or logoff.  You should not be using Citrix Profile Management synchronization or the Streaming Profiles feature with PST files. With the release of Outlook 2010, Microsoft fully supports placing the PST on a highly connected CIFS share.  And even though it is not “officially” supported, I have customers who have successfully been placing PST files on highly connected CIFS shares since the Outlook XP/2003 days without issue.

I hope you find this article useful and that it helps you get the most out of Citrix Profile Management!

Update – August 5 2012: I got a lot of requests to go into more depth on how to architect and scale file services for Citrix Profile Management and Folder Redirection, so I decided to make this a three part series.  You can find Part 2 at the link below:

/blogs/2012/08/05/citrix-profile-management-and-vdi-doing-it-right-part-2/

Cheers,

Dan Allen