In my previous posts, I talked about the performance gain when using streamed profiles and how we can confirm the feature is actually working as expected.

Now I’d like to take a step back and discuss the necessity behind this great feature.

Slow logons are one of the more common profile related issues, especially when using standard windows roaming profiles. Folder redirection can make a difference here by seperating the application data which generally makes up a large chunk of the profile and leaving it permanently on a file share, thereby reducing the size of the profile and in turn the logon speed. However, there are pros and cons to this as any app that reads/writes to the %AppData% folder on a regular basis will have to send these calls across the LAN, seriously impacting app performance. Take Application streaming for example, If the per user Radecache is redirected as part of %AppData% then this can cause performance problems for some apps as the RadeSvc.exe needs to read & write files to this location. I’ve worked more then one case in the past where this was an issue. With App streaming you can take some actions to try and reduce app launch and app performance but sometimes you just can’t get past the network impact when folder redirection is used.

Looking at a high level view of the standard profile loading stack on v1 (XP, W2K3) operating systems the problem is clear:

PROBLEM: The user profile needs to load fully before the user is presented with their desktop.

large profile = slow logon = poor user experience = support in the doghouse.

How we get around this issue is quite simply really. When logging in with a Pm managed user profile with the streaming feature enabled only a small portion of the user profile (HKCU & a number of last used files/folders) are loaded which then allows the rest of the logon process to complete. The result being far quicker logon times and a better user experience.

Most of the magic of profile streaming happens once the desktop is loaded i.e. the rest of the user profile contents is fetched on demand. when a user or application requests access to a file in the %userprofile% our filter driver understands that the file is actually just a marker/reparse point and asks the UPM service to fetch the real file from the profile share and pull it down to the managed client. Both applications and users are unaware that the file(s) are not really located in the %userprofile% on the local machine.

One question you might ask yourself at this stage is the following:

Q.If only a small portion of the user profile is actually copied down to the managed client then won’t app performance be affected just like when using folder redirection?

A.The answer here is yes, quite possibly. To get around this issue we have a nice little feature called background streaming/always cache. Enabling this feature via GPO or .ini file allows an administrator to control what portion of the user profile is streamed at logon and what portion is fetched on demand. This allows administrators to find a balance between logon speed and app performance.

Remembering that not all users requirements are the same, admins can even take this further by applying different Pm settings to different sets of workstations in different OU’s. By doing this, an admin can set the balance on a more granular level for different sets of users.

Citrix Support on:
Twitter – @citrixsupport & @citrixreadiness