XenApp 5 Feature Profile: Special Folder Redirection

Now that the early adopters have had their fun with XenApp 5, the path has been cleared for the wait-and-see crowd to get their hands a little dirty in the sandbox. Citrix has announced over 50 new features and enhancements, and we're going to take a look at a few of the bigger changes one at a time.

Now that the early adopters have had their fun with XenApp 5, the path has been cleared for the wait-and-see crowd to get their hands a little dirty in the sandbox.  Citrix has announced over 50 new features and enhancements, and we're going to take a look at a few of the bigger changes one at a time.

Today we're going to explore a feature called Special Folder Redirection. In Microsoft parlance, Special Folders are the ones that are presented to users in such as way as to hide the absolute file path, such as My Documents, My Computer, or Desktop. Special Folders have been around since Windows 95, and while some names have changed (Such as Documents and Computer in Vista/Server 2008), the concept remains the same.

So what is Special Folder Redirection?

Special Folder Redirection (SFR) allows for the automatic redirection of server-side Special Folders to their client-side equivalents. When a user clicks on the Documents folder in their XenApp 5 session, the folder that opens will actually be the local Documents (or My Documents) folder. When SFR is used, all file operations such as opens and saves will take place in the client-side folder.

Note: Special Folder Redirection is only available when XenApp 5 is installed on Windows Server 2008. I tried to find out information as to why, but I couldn't unearth anything. If you happen to know why or care to speculate, please feel free to leave a comment. SFR also requires version 11 of the XenApp Plugin (client).

How do I turn it on?

SFR is installed by default, but still needs to be enabled. Of the three access methods (XenApp Web, XenApp Services, and Program Neighborhood), SFR is only supported on XenApp Web (formerly Web Interface) or XenApp Services (formerly PNAgent). SFR can be enabled on one or both methods, and is as simple as a few checkboxes.

To enable SFR on XenApp Web

In the Access Management Console, browse to the Web Interface site for which you want to turn on SFR.

Right click on the site and select "Manage Session Preferences."

Under Remote Connection > Local Resources, in the Special Folder Redirection section, check the "Provide Special Folder Redirection to all users" box.

If you want the users to be able to decide whether or not to use SFR (user control?  weird), you can check the "Allow users to customize Special Folder Redirection" box.

If you chose to let the users control their SFR usage, each user will need to change a setting in their Web Interface preferences. This can be done after the users logs in, and is a single checkbox to use SFR.

At this point, you might be thinking "Wow...those configuration options are pretty limited, and there's not much in the way of centralized administration."  You'd be right, but hang in there.  A little later we'll talk about ways to bring the control back to the admins.

To enable SFR on XenApp Service

In Access Management Console, browse to the XenApp Services site for which you want to enable SFR and ig one level deeper to select the config.xml file for that site.

Right click on the config.xml item and select "Change Session Options."

In the Special Folder Redirection under Local Resources, you see the same two checkboxes as before. Once again, to enable SFR for this site, check the "Provide Special Folder Redirection to all users," and to allow the users to decide whether or not to use SFR, check the "Allow users to customize Special Folder Redirection."

As with XenApp Web, if you allow the users to control the SFR usage, he or she will need to configure a setting on their local machine.  To do this, right click on the Citrix XenApp icon in the system tray and select Options.  Then, in the Special Folder Redirection section under Session Options, check the box that says "Use My Documents and Desktop folders."

Centralized Administration

Left alone, the above options leave a little to be desired. Most importantly, you can only turn it on or off for everyone from a centralized location. And if you leave it up to the users to decide, the users themselves will have to enable SFR before they can use it.

To take back some control, you can use a XenApp policy to control SFR on a more granular level. This is an automatic #1 on the list of SFR best practices, since it's hard to imagine a situation where you'd want everyone to use SFR.

The policy allows you to turn off SFR, not turn it on, so you'll need to enable it using one or both of the methods above. When enabling SFR for use with policies, however, you should not check the box to leave the decision up to the users. After all, that's what we're trying to get control of. You can still allow the users to decide if you want, it just adds another layer of complexity.

To configure the policy, start the Citrix XenApp Advanced Configuration application (Sigh.  The CMC, or the PSMC, or the Crazy Java Console. Even the installation file is still called CMC.MSI...) and create a new policy.

In your new policy's properties, browse to Client Devices > Resources > Drives > Special Folder Redirection and select "Enabled."

You can now apply this policy to your users or devices just like any other Citrix policy. For instance, you could exclude IP ranges that reside on the WAN so that people aren't pulling large files from their local machines over slow WAN links to the server. Conversely, you could deny SFR to users at the same site as the servers since they probably have their files stored in a network location as opposed to their local machine.

Again, using policies should be automatically included in your SFR implementation.  Without them, you'll end up spending lots of unnecessary time managing clients and users.

Important Considerations

There are a few key things to think about as you consider rolling out SFR:

  • You should not use SFR for users who connect to the same session simultaneously from multiple devices. SFR users who require the ability to use multiple devices should log off of one device before moving to another, rather than simply logging on at the new device and taking over the session.  his is the only way to refresh the mappings to the local client device.
  • In order for SFR to work, the path back to the client hard drive must be unblocked. You'll need to ensure that:
    • Local hard drive mapping has not been disabled at the ICA connection
    • "Do Not Connect Client Drives at Logon" is unchecked in any connection policy that you might have.
    • "Full Access" is selected when connecting via XenApp Web.
  • When accessing published or seamless desktops, only the Documents folder is redirected.  When accessing published applications, both the Documents and the Desktop folder is redirected.

Note: This is another one of those pieces of information where details were hard to come by.  Again, if anyone cares to speculate, post your thoughts in the comments.

  • "Public" folders are not redirected.  If your users store anything in their local public folders, they will not be able to access it via the server-side public folders using SFR.
  • Finally, XenApp Plugin (client) version 11 is required

For the nerds

While researching SFR, I came across this document from Citrix that details the mapping process, which looks like this:

  1. Upon application click, Citrix XenApp plug-in checks whether SFR is enabled
  2. Client gathers SFR data and builds mapping structure for VDCDN40N.dll
  3. Server acquires SFR data from client drive mapping (CDM) data header
  4. Server checks IMA for permission to run SFR in users‟ context
  5. Server determines special folder location using logic in SFRhook.dll
  6. I/O for special folders during session handled via CDM with SFRhook.dll

Wrap up

So what do you think?  Will you be using SFR at all in your environment?  I can think of some use cases for traveling users and remote sites, but those cases come with the risk of large files having a derogatory effect on the user's experience and the WAN link.  Local users should be saving their documents to the network, and if that is well-enforced, SFT shouldn't be needed for them.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

In theory, its what every user has always wanted. However, its all about bandwidth. I can see myself having to explain why a users 50mb PowerPoint presentaion is taking 10 minutes to open.

Perhaps with the correct policies based on IP subnet this could work in some environments


As to why SFR is only available in XenApp 5.0 for Windows Server 2008: There is not real XenApp 5.0 for Windows Server 2003 (blogs.sepago.de/nicholas2008/09/29/where-is-my-xenapp-50-for-windows-server-2003/">blogs.sepago.de/.../where-is-my-xenapp-50-for-windows-server-2003). Citrix marketing has only renamed Presentation Server 4.5 to leverage the new name.

It would be nice to see a service pack add all features to PS 4.5 which are already present in XA5 on W2k8. This would even justify a new name.

The current situation only irritates customers because they are not told that there is no point to migrate if they are not plannung to introduce W2k8. There should be a clear and official statement about the the naming disaster.

I totally agree with what Paul write in the previous article and have expressed my concerns before (blogs.sepago.de/nicholas2008/05/05/followup-delaware-test-drive/">blogs.sepago.de/.../followup-delaware-test-drive). First, you need to be aware of the bandwidth implications and, second, in many situation it is not desirable to have users (especially from external partners) access their personal files of the client device because of security policies. Personal documents of internal users are usually located on a central network share which is also mapped in terminal sessions, either directly or a spart of folder redirection.


Nicholas, blogs.sepago.de/nicholas.


Nice write up Gabe.  As far as the feature, despite having policy control over who/what it's applied to, I really think that special folder redirection will end up as one of those barely used features.  Why do I say this?  Because it's really only practical to use in high speed environments.  As mentioned, you don't want someone unaware that they've just sucked down a 50MB ppt across the WAN.  And if you try to control it through policy to not apply when they're remote, then you've created a very confusing operations set since the user never knows when their MyDocs is local or remote, etc.  What Citrix/MS truely should have done is enumerate the special folders on the client and inject a dynamic shortcut into the server side MyDocs/Desktop, etc.  That way the user would have total control and quick access to the remote special folders.  Automatically doing it is going to be a mistake for most shops.



That's a good idea, Shawn.  You know, when I first looked at the feature set, I really thought SFR was cool, but by the time I got to writing this post I could only think of a few cases where it could be used headache free.  It started as a "check out this feature!" post, and ended up being a "use with caution" post :)

I guess I was just swept up by the romance of not having to teach users to find their V: drive, browse to documents and settings, yada yada.



Right!  Which is exactly why the shortcut approach is so attractive.  Citrix has complete access to the ICA Client's registry, so they could easily query the UserShellFolder entries and build a dynamic shortcut to V:\Documents and Settings\%username%\Desktop or something like that and have it resolve to the true user shell folder.  While an admin could attempt to do the same thing, you don't know that you're really getting into the proper %userprofile% location, especially if it's external clients where the %username% may not match.  However, Citrix could have done this via shortcuts and IMHO would have been the best way to do it.  Oh well, I'm apparently not the brain trust over at MS and Citrix so....



Many of our users do have My Documents redirected to a network share.  The politics/culture are such that we can't really expect them to be willing to learn much of anything about looking for the V: drive, remembering that Z: is the same as My Documents, etc.  I can see us using this for local clients so that they are not mystified about how to get to My Documents when in a Citrix session.  Does anyone have any idea if/how SFR would work if My Documents is redirected?  Would it route through the client and back to the network again, or is the logic built in for it to route directly to the file server?



I don't know how that would work - redirecting the local My Docs and using SFR to access it.

Question is - why not just apply the same policy that you used to redirect My Documents on the client side to the server side?  Then no matter where the users are logged in, group policies will take care of the mapping.  Presumably that will keep all the data transfer localized (server to server), too, and you won't end up in a situation where you're transferring large bits across the network from the server to the client, and then right back to the file server.  Talk about killing a WAN!