Monday, October 22, 2007

Folder Redirection: Amateur Magician

When I hear the word "redirection" I think of magicians who redirect the attention of their audience in order to prevent them from seeing how a trick is really accomplished. As far as I am concerned, the whole point of Vista redirection is to move data to a network location while letting all participants think it is still in a local user profile on a local hard drive. Unfortunately, I find Vista does not fool enough of it's audience. By audience, I am referring to Explorer, applications, scripts, CMD, etc. Folder Redirection does not provide a consistent experience for each member of its audience.

Folder Redirection does it right when a user uses Explorer to Browse to their User Files Folder. In this case the user sees all of the User Files Folders as if they were stored locally:

(FR Test is the name of the user in today's examples.)

However, if the user was to venture into the local folder that normally stores the User Files Folder (still using Explorer), this is what he would see:

The C:\Users\FRTest folder makes no attempt to fool the user into thinking that the files are still stored there. There may be some very good technical reasons why this is necessary, but it is different from the experience a user would have if no folder redirection was utilized. Our user encounters the same situation if accessing that same location using a CMD prompt:

Also, if the user or application does not fully understand what has happened and stores data in a subfolder such as Documents anyway, it is just left there. Vista makes no attempt to recover that file and add it to the rest of the files stored on the network -- data loss imminent!

This is a good time to bring up another issue about the DOS command prompt windows (CMD). CMD has an environment variable that specifies the location of the user's profile (%UserProfile%) but not a variable pointing to any of the User Files Folders. Without Folder Redirection this isn't a big deal - you just specify a path like %UserProfile%\Documents. However, with Folder Redirection, the directory is gone and there is no variable available to tell scripts or the user where to find it. All the user will receive is an error:

If your organization relies heavily on batch files that utilize User Files Folders, you will want to find a solution to this issue. One option is to employ a VB Script at logon time that creates new environment variables pointing to the User Files Folders you require. VB Script can access the shell to determine the location of the folders (This site provides a great list of Vista shell folders) and assign them to variables like %UserDocuments%. But keep in mind that CMD cannot use UNC paths so any solution will also need to involve an additional drive mapping.

Folder Redirection also holds an interesting surprise for users when they perform the simple act of saving a document from within an application. Mileage varies on this one - you will get different behaviours from various applications. Notepad does very well. If you open notepad and perform a "Save As" you will be presented with a dialog box that defaults to the Documents folder. If you expand the dialog to display folders, you will see that the path to the Documents folder is through the User Files Folder. Perfect.

Now, try the same action with an application like Microsoft Word. Selecting "Save As" will bring up a similar dialog that also defaults to the Documents folder. But expand the dialog to display the folders pane. Where on earth are you? Rather than show the user the Documents folder as if it exists within the User Files Folder, it resolves the full UNC path! It expands the network, server and share that the User Files Folders have been redirected to:

I know I'm not really blowing your socks off with this graphic, but let me enlighten you. My example above shows you but one server and one share in a small test environment - imagine this on the scale of a large organization with hundreds of servers and hundreds of shares per server. I'm sure many of you dread it when your users start venturing into the Network view to discover all of them. We work hard to provide our users with a simple looking environment - why must Folder Redirection under Vista expose our nasty complicated network environment for every basic user to see?

This behaviour of exposing the full UNC path added another complication for our users as well. Despite having data for thousands of users spread across hundreds of servers, our users normally think things are quite simple because they are given only a few drive letters that point to the data they need. Windows XP used to redirect folders to drive letters. Users would see a nice simple path like H:\My Pictures and the path would be nestled above their I:, J:, K: and L: drives that housed the rest of the data they wanted. Where are those drive letters now? For a user to find those letters under Vista with Folder Redirection, they must scroll up past hundreds of servers in the folders pane and then expand the Computer node. I guess you are already envisioning the user training you will need to provide.

I'm really not happy with the way in which my user experience changes because I have chosen to get more sophisticated in the way I protect data. But I think the benefits of Folder Redirection far outweigh these drawbacks. My users will just have to live with the drawbacks and I will have to write more sophisticated scripts and probably provide more user training and documentation.


Johnmen Zhang said...

the CMD does support using UNC name. I tested in both Vista and Windows XP, all working like this:

dir \\server\sharename

It will show me the content of that shared folder.

Gordon Martin said...

Good comment Johnmen, but you are only half right. Some commands like DIR and DEL have been extended to understand UNC paths. But not everything has - not the command shell.

Imagine a typical scenario where you wish to work in a particular folder. Maybe editing documents or deleteing and managing files. Now try doing that.

Maybe type a UNC path just as you would type "H:" to get to a network location - Vista's CMD won't know what you are talking about. Try using "CD \\Server\Share" to get to a network location. Vista's CMD will explicitly tell you "CMD does not support UNC paths as current directories." As I said, CMD does not work well with UNC.

But you are also correct in saying that there is support for UNC since many commands have been extended to understand and refernce UNC. However, if you have a long UNC path, nothing beats a good old fashioned drive mapping to get things done.