How Folder Redirection Impacts UX & Breaks Applications

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

• Part one: this article
• Part two: Visualizing the Impact of Folder Redirection – Logon and Application Launch
• Part three: Visualizing the Impact of Folder Redirection – Start Menu Search
• Part four: Measuring the Impact of Folder Redirection – User Logon

Why Even Talk About Folder Redirection – in 2014!?!

Working in the SBC/VDI space without stumbling across folder redirection is about as easy as travelling from Europe to the US as an IP packet without going through a Cisco router.

The folder redirection technology has been a part of Windows more or less forever, and it solves an important problem: quickly setting up user sessions on stateless machines. Given these circumstances, one would assume that use cases and caveats have been fully understood for at least a decade and that people generally agree on the DOs and DON’Ts. Interestingly that is not the case.

Everybody uses folder redirection but nobody fully understands the consequences.

This series of articles is about what can go wrong, where folder redirection fails and how that affects end user experience.

Why Not Call It Directory Redirection?

There is a reason folder redirection got the name is has and not, for example, directory redirection. There is a – subtle – difference between a folder and a directory: the former is a virtual container in the namespace of the shell. The latter is a container in the file system.

Applications that want to work with (virtual) folders like Documents need a way to find the physical directory a folder maps to. That is where the API function SHGetKnownFolderPath comes in. It looks up a folder’s target in the User Shell Folders registry key:

In the image above some folders point to their default location within the user profile, e.g. History, while others like the Desktop have been changed to point to a file server. That is what is at the core of folder redirection. A simple path change in the registry.

Manual Redirection

If you implement folder redirection by changing the values of the User Shell Folders key directly you are redirecting manually. This absolutely works fine – I have seen it in very large production environments – but it is not 100% clear if it is supported by Microsoft.

Manual redirection has the smallest possible logon duration overhead – after all, only a few registry values need to be set. It allows for the redirection of all folders represented in the User Shell Folders key (21 on Windows 8.1 with Update). But it does not move existing data around when you change a folder’s target.

Redirection Through Group Policy

The official way to redirect folders is to use the corresponding Group Policy CSE, to be found at User Configuration > Policies > Windows Settings > Folder Redirection:

Using this method only 13 folders can be redirected, but that is typically sufficient. Optionally different targets can be specified per user group. Existing files can be moved to the new location when a folder’s target is changed and back to the original location in the user profile when the policy is removed. It is important to note that this file moving happens synchronously during user logon and may increase the total logon duration significantly.

Redirecting to Drive Letters

As tempting as it may be to simply redirect to H: (or whatever the home drive is in your organization): Do not do it. It is not supported. And a bad idea.

The Windows user logon is a very complex process with many things happening in parallel. There is no guarantee that the home drive is mapped before folder redirection kicks in. It may work in your setup – today – but any configuration change may break that. In any case you can only redirect to drive letters using the manual method (writing directly to the registry). Group Policy prevents you from shooting yourself in the foot.

AppData’s Many Children

One thing that is not immediately obvious but that can be deduced from the User Shell Folders image above: when you redirect AppData (the merits of which are highly debatable) you are also redirecting:

• Cookies
• Network Neighborhood
• Recent
• SendTo
• Start Menu
• Templates

Redirecting Documents to the Home Directory Root

Redirecting the Documents folder to the root of the home directory is logical. However, if you do this:

You get this when looking at your home directories in Explorer:

The point being here that you should not use Windows File Explorer as an admin tool. It is not. It shows you a kindergarten view of the world.

Second Home Directory

Often the best place to redirect to is a subfolder of the user’s home directory. In order to configure that using Group Policy we could try to use the option Create a folder for each user under the root path and specify the home directory share as root path like this:

That would have the Folder Redirection CSE use home directory names equalling the user name. However, these days home directories typically have the user’s domain appended to the directory name (when RDS home directories are created through Group Policy that happens automatically). As a consequence we cannot use the option Create a folder for each user under the root path or a second home directory would be created for the redirected folders. Instead, we need to choose Redirect to the following location and specify the full UNC path, replacing the user name with a variable:

Other variables like %USERDOMAIN% may work, too, but do not seem to be supported. According to the latest document we could find on the matter, Microsoft’s Managing Roaming User Data Deployment Guide from the Vista days, “Folder redirection only supports %USERNAME%, %USERPROFILE%, %HOMESHARE%, and %HOMEPATH% environment variables.”

When we click OK to save and close the dialog above and reopen it to check if everything is looking good we notice something strange: Target folder location and Root path are very different from what we configured – but the resulting path shown as an example and used by the CSE is correct:

Logging

Many websites still recommend to turn on logging to a file called Fdeploy.log. Do not do that! It won’t work! At least not with Server 2008 or later, and you surely migrated off Server 2003 a long time ago, didn’t you!?

Beginning with Windows Server 2008 the Group Policy Folder Redirection CSE only logs to the event log. Errors are written to the application event log, more detailed information can be found in Applications and Services Logs > Microsoft > Windows > Folder Redirection.

Part Two

This concludes the first article in this series on folder redirection. Part two can be found here on Aaron Parker’s blog.