Happy Halloween!

I think my team is starting to get Vista on the brain. Take a look at our submission for this year's pumpkin carving contest:



We were so proud of our first place finish that we marched it right over to the Microsoft offices. For a limited time it is on display in the lobby of the Ottawa Microsoft office in the World Exchange building!

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.

Blog: One month anniversary!

It's been one month since I posted my first welcome message - and what a month it has been!

I've managed to exceed my target of 2 posts a week and the readership has been fantastic. Despite having no external links, we are creeping up on 1,000 page views. The google searches that have brought people here are telling me that I am providing some much needed information. I hope to expand on the few articles I have and make this a place worth visiting on a regular basis.

My only regret is that people aren't checking out the advertisers and aren't engaging in discussions. Post a comment! Let me know if you are finding the information you need or if I am missing the mark. Do you know something about Vista that you'd like to share with the rest of the world?

I'm wrapping up my posts about Folder Redirection with two more articles. Later I will write an article on the Encrypting File System (EFS) - I need more information from Microsoft first.
Speaking of Microsoft, this blog has received quite a bit of attention from them. It looks like Microsoft employees from around the world are responsible for about a third of the page views on this blog. I've also received an offer to have Microsoft review some of the articles and provide some feedback - it will be interesting to see where this leads.

My next series of articles will be about a Vista feature getting all of the attention - User Account Control (UAC). I might as well jump on the bandwagon :-) Actually, I've got about 20 UAC articles in me - so that should give me enough posts to get us through to Christmas.

Thanks for reading and making my first month such a success,

Gordon

Folder Redirection: Not to the user's home directory

I remembered a problem I had during the development of my Folder Redirection solution that I think you should know about. It's a problem that you might not notice during testing but that can really get you once you roll out to many users.

For those of you just joining us, you will want to be familiar with User Files Folders (Introducing the User Files Folders!). Some other useful background reading from my site is User Files Folders and the Desktop.INI and Folder Redirection: Specifying a target share. I will be building on some of the lessons learned in those articles. Now let's get started...

In my past articles I discussed how to redirect User Files Folders to a target, but I didn't really talk about what target to choose. I think it was typical for most of us in the XP days to redirect the My Documents folder (which was the parent Personal Folder) to the root of the user's network drive - H: in my case. The inclination will be for you to want to do the same thing in Vista. This inclination is further re-enforced by Microsoft who provide you with the Redirect to the user's home directory GPO. This GPO basically redirects the Documents folder to the user's Home Path specified in AD without any further configuration details required. -- I'm here to tell you not to use this GPO!

If you try using that GPO, everything will look like it works just fine and your tests will tick along beautifully. But try redirecting folders for multiple user accounts whose Home Paths exist in the same network share (i.e. \\server\share\FRTest & \\server\share\SRDTest01). Then take a look at the share that houses these Home Paths. In my example I had a third account called SRDTest02 for whom I did not configure folder redirection. When I browsed to \\server\share, this is what I saw:


Twins! The two users who received Folder Redirection to their Home Path got the folders renamed to Documents! There isn't even a unique identifier like "(1)" after the name - I have two folders named Documents. Now imagine how you would handle seeing 500 of these side-by-side.

Have you figured out what happened yet? Do the green icons give you a clue? It's the Desktop.INI doing its job folks! By implementing the GPO, you have specified that the user's home folder will be the documents folder. The redirection brought along all the Documents folder files - including the Desktop.INI which specifies that the folder is to be named Documents - and so it is.

Because the Desktop.INI is specifying a "Friendly" name, Vista is quite happy to show you 500 aliases with the same friendly name - there is no need for it to add unique identifiers because the underlying folder is unique. But this causes us admins a bit of a problem doesn't it. Here's a little test for you. See if you can figure out what the real underlying name of the folder is? I have not found any GUI interface (Explorer, etc.) that is willing to show me anything other than the friendly name. Viewing the properties or browsing by typing in real paths does not reveal any secrets. The only method I have found is to look at the folders from a CMD prompt. The CMD prompt does not interpret the Desktop.INI. - Here's what I saw:



Finally some information I can use!

"How do I fix this?", you ask. There are two things you can do and they both involve the Desktop.INI. One solution is to simply delete the file so that Vista isn't told to use a friendly name. Another might be to edit the Desktop.INI and hard-code the folder name so that it matches the user's account name and you get to keep the associated icon. Both solutions might fix a current predicament but they are not very practical for the long term. The only real solution is to avoid the problem in the first place. Don't use the Redirect to the user's home directory GPO.

Also, if you are redirecting with other methods such as the Redirect to the following location GPO, ensure that you continue to avoid the root of the user's home path. Pick a more suitable target such as \\server\share\FRTest\Documents. It is important that you never end up with a folder structure where a single folder contains a bunch of redirected Users Files Folders of the same type (i.e. Pictures). There is one thing I have come to terms with for my Vista implementation. It is not possible to give my user an identical experience to XP - changes are coming for my users and they are going to feel it.

That concludes the instructional portion of this article. Feel free to stick around for the geeky analysis portion...

I got to wondering how this problem could occur and how Microsoft didn't notice it before releasing Vista. I think I came up with an answer. Let me know what you think of this theory:

If you remember back to my article, User Files Folders and the Desktop.INI, we know a few things:

• "Documents" is a Friendly Name created on the fly by passing Shell32 a folder ID number.
• XP also understands this number but comes up with the Friendly Name "My Documents".
• Vista no longer adds the "Owner" property to the Desktop.INI like XP did.

I think the whole thing can be traced back to XP where everything was working fine and probably a last minute change to Vista caused it all to fall apart...

Although XP can understand the LocalizedResourceName that holds the folder ID Number for Shell32, we have never seen it actually implemented in XP. If you look at the offending folders above using XP, you will see that it is also willing to show you two "My Documents" folders. Now add a missing XP element to the Desktop.INI. Specify the owner of each folder (be unique). Now look again. Suddenly XP springs to life and shows you unique folders! - namely, "FRTest's Documents" and "SRDTest01's Documents". When XP detects that the current user is the owner of a folder it is looking at, it uses the prefix "My", otherwise it uses the owner's name as a prefix.

Had XP been implementing the LocalizedResourceName, it would have done it correctly. With Vista, the developers have removed the prefix "My" - and with it any chance that Vista will be able to provide any unique friendly names. We are left with a reduced set of options when designing our folder structures. I don't see any easy way out of this problem for Microsoft. I think we are stuck with it. One change that might help a little is if Microsoft was to add an option to Windows Explorer that would allow us admins to "hide the Friendly Name" in much the same way we hide file extensions now. This change would also help me when dealing with users who are using an alternate GUI language -- are you listening Microsoft?

Vista's GPMC: Don't trust it

Vista has seen some dramatic changes to GPOs and the Group Policy Management Console (GPMC) used to manage them. The coles notes version is that Microsoft has introduced ADMX templates which are Vista-specific GPO templates written in a new XML format. To administer new Vista features, such as Folder Redirection, you are required to use these new templates; however, these new templates are not compatible with your existing Windows Server 2003 GPMC. The only GPMC able to manage ADMX templates actually comes installed with Vista!

This is where it gets interesting. To manage Vista GPO settings, you must use a Vista computer. Once you have GPOs based on ADMX templates in your environment you can only use Vista computers to manage them. This basically means that you quickly have to roll out Vista computers to all your enterprise GPO administrators even before you have really locked down the configurations for your Vista computers. In addition, we have been experiencing problems with the Vista version of GPMC.

Throughout the course of our Vista desktop design project, we have been tinkering with various GPO settings. We would often not get the results we were expecting or find that systems were implementing settings contrary to those that we had specifically chosen. After months of head scratching and frustration, we think we now understand what is going on...

Vista's version of GPMC gets confused when you make changes to GPOs and only properly understands what is going on after it is closed/terminated and restarted. Here's what I mean - I now present a series of actions that occur within the Vista GPMC application:

• I target an existing GPO with an existing setting.
  
• I choose to edit that GPO and change a setting to the alternate value (if it was Enabled, I select Disabled, etc.).
• I then click 'Apply' or 'OK' on the edit window to commit my changes.
  
• I wait a few minutes and go to my test computer to see what effect the new setting has - I see no change.What gives?
• I go back to GPMC and run an RSOP specifying my test user and test computer.
• It tells me that my setting change is being applied to that computer correctly. More head scratching.
• I eventually give up and shut things down to go home.
• The next day I get into the lab and suddenly everything is fine - more head scratching.
• I inspect and everything looks fine.
  
• So I try another setting - same odd results when I check my test PC.
• This time I look at the GPO report. It tells me my setting is not applied as I had specified.
• I choose to edit my GPO once again. That interface tells me that the setting is set as I have already specified so there really isn't much more I can do.

Fun eh? It looks like my co-worker has figured out what's happening (I'd love to hear from others about their experiences as well):

• When I apply a setting in GPMC's edit window, it is not properly getting applied.
• The edit window shows my setting as I have requested.
• But the GPO Report I then generate in GPMC continues to show the old value.
• Also, the test PC continues to only receive the old value.
• But running an RSOP in GPMC thinks the setting has been applied.
• Only once I close GPMC, does the test PC receive the setting change.
• When I reopen GPMC, my edit window, new RSOP report and new GPO report all agree with each other!

The lesson here is to close GPMC often and not leave it lying open on your admin PC.

[EDIT] Well so much for that... we had tested the hypothesis above and properly reproduced the results... but today GPMC changed its behaviour. It now updates workstations after hitting the Apply button without the need for a restart. We tried for 2 hours to break the darn thing... Oh well, I guess the headline still holds true - Don't trust it! [/EDIT]

There is one additional bit of GPMC goodness that I would like to direct you too. Microsoft recently released a Windows Vista Service Pack 1 Beta White Paper. In it there is the following text:

Beta testers will find that after installing Windows Vista SP1, they no longer have access to GPMC, and that the new, enhanced version of GPMC has not yet been released. In this case, administrators can continue to edit Group Policy by opening a remote desktop session directly to the server or to a PC running the release to manufacturing (RTM) version of Windows Vista.

I find it interesting that SP1 is removing GPMC before a replacement is even available. This suggests to me that Microsoft is already aware that the Vista version of GPMC has some serious issues. Unfortunately, if you have implemented any ADMX templates in order to support your Vista environment, you have no choice but to continue using Vista's GPMC - so be sure to keep a non-SP1 Vista desktop around until a replacement is made available.

Folder Redirection: Duplicate User Files Folders

[EDIT] Many of you having duplicate folder issues will be more interested in another article: Folder Redirection: Not to the User's Home Directory [/EDIT 05/11/2007]

I've experienced an odd glitch with Vista User Files Folders that I thought you should be aware of. It seems that when I am changing GPO settings that relate to Offline Files, I end up with duplicate folders in the Users Files Folders (see pic):

I haven't determined a trigger for this yet - they just appear after I have been manipulating my Offline Files GPOs. Thankfully it has only happened in my test environment (although more than once) and not in full blown production - but I see that others on the web have not been so lucky.

In this case the folders are easy to spot because they aren't populated with Desktop.INI files and therefore don't display the green folder icon. In fact, the folders are completely empty. But it is important to remove the folders before your users get confused and start saving things in them.

There is rather strange behavior if you attempt to manually delete the folders using Windows Explorer which I will let you experience for yourself. Instead, you can find these extra folders located in the user's local profile directory %UserProfile%. None of the 13 User Files Folders (with the exception of AppData) should be found in this directory when they are being redirected elsewhere. Delete the extra folders from here.

If you are in the uncomfortable situation of having duplicate folders on workstations spread throughout your organization, you need an automated method for cleaning up these folders. The easiest method I can think of is adding some DOS RD (Remove Directory) commands in the logon script. The RD command is a safe approach because it will only remove empty directories and not jeopardize any user data. To clean up my example, I would use the following commands:

RD %UserProfile%\Documents
RD %UserProfile%\Music
RD %UserProfile%\Videos

These commands will work for any user. They will not remove important directories for users who aren't utilizing Folder Redirection. You may even wish to leave these commands in your logon script permanently as insurance against any future accidental duplication of these folders.

An important note about the AppData folder... You probably should read up on this folder that Vista uses in a rather complex way. AppData is part of the user profile and can be redirected to a network location. But there are some local data folders within the AppData folder that can never be redirected and will stay local. This causes an AppData folder to be present in both the Local Profile folder and also on the redirected network target. Also, this folder is not normally visible in the User Files Folder. But it will appear there if the user ever ventures into the AppData folder. This is because the user had to "Show Hidden Files and Folders" in order to access the AppData folder.

[EDIT] I've got a new blog article up that talks about User Files Folders: What's with all these extra folders? - It provides great details about the AppData folder and Junctions. [/EDIT 06/11/2007]

Folder Redirection of database files causes corruption!

My blog articles so far have to do with User Files Folders and using Folder Redirection to move them to servers. If you are considering doing this in your environment, there is something you should know -- redirecting a database file and then modifying it will corrupt it. This is a current phenomenon that is very easy to reproduce:

1. Put a database file in a redirected folder (that has Offline Files enabled by default).
2. Modify the database.
3. Witness the corruption.
   

Microsoft is aware of the problem and a fix is to be included in Service Pack 1 (SP1). If you wish to implement Folder Redirection before SP1 is scheduled for release (December timeframe), contact Microsoft and request a custom patch that includes the required fix. It should be easy to get because I have already made that request and received my patch.

Time for a rant. If ever there was proof that Vista was rushed out the door, this is it. If ever there was proof that there is slow uptake of Vista by enterprise clients, this is it. Let me explain...

Typically when Folder Redirection is used, Offline Files is also used since it is the default configuration. Offline Files maintains a local cached copy of the redirected data files. This ensures maximum reliability and speed but requires that the local cached copy be synchronized with the network copy. Under Windows XP, database files were excluded from the synchronization process due to their likely large size and were forced to remain on the server only. This caused problems for laptop users who counted on the Offline Files feature to give them access to their network files while away from the network. Vista introduces a new feature of Offline Files called "Bitmap Differential Transfer" (BDT). BDT allows Vista to support the synchronization of all file types, including databases, because it does a block-by-block synchronization and it no longer needs to synchronize an entire file every time. Here is one Microsoft site promoting the feature. Here is a blog that discusses the feature as well. The problem is that the feature just doesn't work - at least it didn't work at my client site and Microsoft support easily reproduced it as well. I was able to witness the corruption by simply creating an Access database in a redirected folder and then modifying it by moving a button control on a form. Within minutes I had Access spitting out all sorts of random error messages. In my book, if a new product's "feature" just doesn't work (no strange arrangement of bits required), then it was rushed to market.

Now here's the bit that has shocked me. I found a glaring problem. It was easily reproduced. There has been no mention of it on the internet that I can find. When I got the early release of the patch destined for SP1, I was told by Microsoft that I would be the first client trying it. This was September. How is it possible that the product has been out for eight months and no one is reporting it or receiving support to fix it? I can only surmise that Folder Redirection is being used only by the larger clients who are having trouble with the implementation of Windows Vista - they have yet to deploy the product to users who might think of putting a database in one of the redirected user folders and attempt to modify it.

Folder Redirection: Specifying a target share

Now that the User Files Folders have been covered, it's time to get fancy and start discussing Folder Redirection. In short, Folder Redirection is a feature which redirects the locally stored User Files Folders to a network share. I touched on Folder Redirection in a previous blog article titled Introducing the User Files Folders!.

I have no plans to give you a complete education on Folder Redirection. Rather, my intent is to highlight issues that I have encountered in order to save you gobs of time configuring your environment. If you are unfamiliar with Folder Redirection you should read the Microsoft primer on Folder Redirection and Roaming Profiles. It has the most detail Microsoft has ever provided on the topic - it turned out to be my bible. For purposes of this article, you will want to pay close attention to the section titled Basic Redirection and Advanced Redirection. For those of you without a large network who wish to configure workstations individually, you need to know about Manual Folder Redirection.

Now that you have read the articles mentioned above, we need to talk about specifying a target network share for your redirected folders. Here is the most important bit of this entire article - you can only provide a UNC path when specifying a target. This may not sound like a big deal to those managing a small environment, but it was devastating to us.

As a large, distributed organization we have almost 50 servers hosting user-specific shares. Naturally, we expect to redirect the User Files Folders to a location within a user's personal share space. In the XP days we simply mapped the H: drive to the user's share wherever it might be and then simply redirected the 'My Documents' folder to H:\. Simple.

You won't see any mention in the lengthy Microsoft articles I linked to, but the fact is that this simple implementation is no longer possible in Vista. You can only specify a drive letter as a target if the drive is a local device. If it is a network device, a UNC path must be used. The explanation from Microsoft is that Folder Redirection occurs much earlier in the logon process - before any drive mappings are established. I suspect this is because Vista can now redirect the Desktop and Start Menu so it must find its way back to the network locations that store that data as early as possible.

Remember I mentioned 50 servers for user shares? That translates into 50 UNC paths! Microsoft expects me to abandon Basic Redirection and happily sign on to Advanced Redirection. The way Advanced Redirection works is that you list all the possible UNC targets and associate a security group with each one. This is, of course, assuming I have already grouped my thousands of users into 50 individual groups - if not, it's time to get to work.
Not crazy enough for you yet? Try this next bit of math... In the XP days I basically had one folder to redirect, the 'My Documents' folder. Vista now has 11 User Files Folders - plus 2 additional folders in the user's profile - which must be redirected individually. There is absolutely no way to redirect a single parent folder like you did in XP. We now have 50 X 13 (650!) folder redirection UNC targets that we must specify. Can you say 'nightmare'? Can you imagine the maintenance headache if you ever choose to change one of those UNC paths in the future?

I decided to attack the problem from a different angle. Decide for yourself if it is better, but so far I am happy with the results...

If you read Microsoft's primer you might have overlooked the small note that they inserted which says 'Folder redirection only supports %USERNAME%, %USERPROFILE%, %HOMESHARE%, and %HOMEPATH% environment variables.'. This note is accurate - and key to my solution! It turns out that %HomeShare% is a valid UNC path for the Folder Redirection GPO! If your user's H: drive isn't mapped to an individual user share, then %HomeShare%%HomePath% is an equally valid UNC path. By utilizing these environment variables, it is possible to revert back to Basic Redirection and have only one UNC target per folder - 13 UNC targets definitions in all. -- phew.

What? You say those variables don't return any values? I now need to show you how to populate them with valid UNC paths. For those of you who do get UNC paths out of those variables, this concludes my first article on Folder Redirection. Much more nastiness to come - so check back often!

Alright you nul variable bums, now that we have gotten rid of those lucky UNC laden admins, let's finish the rest of this ugly tale.


The %HomeShare% and %HomePath% variables pick up their values from each user's profile properties in AD (see pic). The Home Folder path is split into those two variables. The server and share specified in the path make up the UNC path stored in %HomeShare% and remaining folders in the path are put into %HomePath%. The choice to use a Local Path or Connect to a specific drive letter is yours and doesn't affect Folder Redirection (hence the reason for this article :-)

Now I know what some of you are thinking "But Gord, we abandoned that setting years ago in favour of more modern ways of mapping - like GPO logon scripts." Trust me, I did to. But it is necessary to go back if you want to save yourselves loads of work. I even had Microsoft support argue with me on this one until he realized what he was asking for. In fact, you will also notice from the attached screen cap that I have also reverted back to launching the logon script from the AD profile rather than from GPO. This is another Vista necessity that I will cover in a future article.

Now, before you start thinking that modifying the path for thousands of user accounts leaves you no further ahead than using the Advanced Redirection option, I need to remind you about LDAP queries. I won't teach you about LDAP queries, but a short reminder is in order. DO NOT modify all your user accounts individually/manually. Active Directory Users and Computers (ADUC) allows you to perform LDAP queries/searches which enable you to target the objects you need so that you can make changes en masse. You can filter users on almost any property you wish such as group or OU membership. When you get a resultant list of users, you can simply highlight all of the objects and make one change.

Now, you may be worried that this won't be possible for you since each user's path must include the user's name. ADUC also happens to behave well in this regard. The path I have specified in my example '\\Server\Share\GMartin' is not the path I had provided. Instead I had provided the path '\\Server\Share\%Username%. ADUC automatically substituted the appropriate username for each user object (thank goodness it didn't put my name in all the paths).
LDAP is also the feature you will rely on to manage these paths in the future when changes are necessary. In the future you can do a search for all users who use a specific share and then change them again en masse - so learn LDAP!

That is all. Have I failed to anticipate one of your questions? Drop me a message and I'll do my best to improve it.