Visualizing the Impact of Folder Redirection – Start Menu Search

This is the third in a series of articles on folder redirection by Aaron Parker, Helge Klein and Shawn Bass.

Previously on this Series

If you have been following this mini-series you know that after explaining the basics in part one we got to the juicy bits in part two, where Aaron Parker presented videos that vividly show that folder redirection indeed speeds up user logons considerably, but at the price of potentially horrible user experience during the session. In this third part we are going to explore that in more detail.

Start Menu Search

For obvious reasons the start menu is one of the places accessed most often on a Windows desktop. Its search functionality makes it fast and convenient to hunt for the application or document required at any specific moment. Just press the Windows key (or click Start), type the first few characters of the application name you are looking for and hit enter a few hundred milliseconds later when the search result materializes. At least that is the way it is supposed to be.

Folder Redirection to a Busy File Server

With folder redirection enabled a few hundred milliseconds can easily turn into twenty seconds as the following video demonstrates:

file server 99 percent cpu - small-fr-startmenu - small profile, folder redirection including start menu

What is happening here? Why is it taking so long?

Some files required by Start Menu Search reside in one of the redirected folders on a very busy file server. Bringing those files in is what makes the search unbearable slow. The thing to keep in mind is that the search is slow every single time as long as the file server is busy.

With a single super-simple search for locally installed Event Viewer taking about 20 seconds – what is the setup? We kept it deliberately simple and the profile small:

  • User with a small roaming profile (114 files, total size 4.7 MB)
  • File server CPU 99% (deliberately not 100%!)
  • Folder redirection enabled for: AppData, Desktop, Documents, Pictures, Music, Videos, Favorites

Folder Redirection to a Busy File Server but Start Menu Redirected Back to Local Disk

As we explained in the first article when you redirect AppData you also redirect the Start Menu, among other things. So we wondered what would happen if we redirected the Start Menu back to its usual location on the local disk – would Start Menu Search be fast again? See for yourself:

file server 99 percent cpu - small-fr-startmenu - small profile, FR but start menu back into local user profile

Not really. As broken as before.

By the way, the fact that it is less slow than in the first video is probably due to minimal changes in file server load. The point being that it is slow.

Folder Redirection to a Busy File Server but Without AppData Redirection

Next up in our experiments we left everything as in scenario one but did not redirect AppData. The change is obvious:

file server 99 percent cpu - small-fr-noappdata - small profile, folder redirection excluding appdata

Without AppData redirection Start Menu Search is consistently fast even with a very busy file server.

This is just one of many situations where an application is totally dependent on certain files expected to be on fast (local) storage. If those files cannot be accessed quickly the application is slow.

Citrix Profile Management with Streaming

We looked at Citrix Profile Management as a potential alternative to folder redirection. With streaming enabled files from the user profile are brought in asynchronously on-demand. In other words: whenever an application tries to access a file, Profile Management copies the file from the server to the local disk. Let’s see the effect this has on Start Menu Search:

file server 99 percent cpu - large-cpm - large profile, CPM streaming

The result is interesting: initially search is slow, but that is only true for the very first search. After that all files reside on the local disk and search is consistently fast!

By the way, we even used a large profile (2,334 files, 33.7 MB) in this video to make sure that it stays fast in realistic scenarios.

Conclusion

Folder redirection, especially AppData redirection, can totally kill application performance. Even if your file server is only busy for a minute at a time hundreds or even thousands of users are bound to notice, leading to support cases of “unexplicable” application slowness nowbody can put a finger on.

At the end of the day “Citrix” gets blamed for natural oscillations in file server performance. Nobody wins.

7 Responses to Visualizing the Impact of Folder Redirection – Start Menu Search

  1. Joe Nord November 12, 2014 at 20:02 #

    Hey Helge. Citrix Profile Managemer streaming enable or disable by default is supposed to be a dynamic question. On environments where profile streaming has value, it is enabled by default. On environments where it is not useful, it is disabled by default. So, pooled gets enabled and dedicated desktop, disabled. In either case administrator can override and specify enable or disable. Least this is how it was planned when we were writing the code. If not happening that way, well I have some heads to bang.

    • Helge Klein November 12, 2014 at 21:48 #

      Thanks for the comment, Joe. You made me check again and it turns out I was wrong. The Profile Management documentation states If Profile streaming is not configured in Policy or INI file, Profile Streaming is enabled.

      I just checked this on a Server 2012 R2 machine with the XenApp 7.6 VDA (and Profile Management 5.2) installed. The profile management log file says PSEnabled set neither in policy nor in INI file. Defaulting to: <1>. So the documentation is correct.

      It is good to see that it is now turned on by default.

      BTW I could not find any indication that streaming is disabled on dedicated desktops by default.

  2. Stefan November 16, 2014 at 19:50 #

    Thanks for sharing!
    and good to know :)
    Did you have a look at UE-V ? we are going to test that feature/app soon, hopefully

  3. Mikw November 16, 2014 at 20:32 #

    Hi Helge, great post! I feel like MS has completely abandoned users of redirected folders :) and we can only rely on the community resources, like your blog!
    My users also experience the issue with slow Start Menu search, once they are on a high latency link to the server hosting redirected folders. And the only folder redirected is Documents, we don’t touch AppData. I know the correct approach would be playing with slow link mode settings (but sometimes it’s not possible as our slow links are intranet ones).
    Now inspired by your post I’ll try to run procmon to try identifying the bottleneck, but any ideas would be welcome!

  4. Kevin Wilson November 24, 2014 at 19:06 #

    We are a large (maybe largest) folder redirection enterprise. You are showing some good stuff, but I want to add a few things to kinda explain some behind-the-scenes things to the readers. This is a realm where you have to understand Windows Search (scopes, grep search versus indexed search) and how it behaves against remote locations in order to make sense of things.

    What you are seeing when redirecting the Start Menu is Windows Search trying to search the Start menu for Program Shortcuts from both the user and All Users sections – a part of the standard Windows Search scope. This is done via Windows Search Protocol to the Windows Search Service on the overloaded File Server. The delay is not from reading the data, it is (probably) from the delayed response from the Windows Search Service, which has already indexed the metadata and will respond to the request based on data from the index.

    When you bring the Start menu back local, you still have the “user pinned” taskbar shortcuts and Library files (.library-ms) redirected. Again, the user-pinned items and Library files are a part of the standard Search scope. Delays are (probably) based on protocol / response / read-the-index delays instead of I/O delays.

    Folder Redirection planning has to take into account Windows Search and Indexing as a part of the total picture. There are two options for indexing remote files – 1) put them on a Windows file server with Windows Search Service enabled, or 2) put them on a NAS device (or Windows file server) and enable Offline Files, where they are indexed by the local service from within the offline files cache. You did a good job of showing that option 1 can bite you if the file server becomes overloaded. Please note that Option 2 1) ensures consistent performance against Windows file servers, 2) enables Windows file serves to run without the Windows Search Service enabled, and 3) enables Indexed Search against NAS storage devices.

Leave a Reply