Wednesday, September 26, 2007

User Files Folders are Bilingual

-- Multilingual actually.

Before reading this article, you might want to read my previous posts: Introducing the User Files Folders!, User Files Folders and the Desktop.INI. Those posts will prime you so that you can fully understand this post.

Remember that there is a new layer of abstraction of the Friendly Name for the User Files Folders? The LocalizedResourceName in the Desktop.INI represents the Friendly Name with a number. This abstraction makes it possible for Windows Vista to display the folder's name in the language of the GUI. Remember how -21790 represents the name of the "Music" folder? Well, if Vista is using an English GUI, it will display the name "Music", but if Vista is using a French GUI, it will display the name "Musique".

This versatility is one of the nicer features I have found in Vista. It solves problems that Windows XP has when trying to support a multi-language organization. Working for the Canadian federal government, I often find myself supporting bilingual staff who use French and English systems interchangeably. In the XP world I would install either a French or English OS according to a user's preference; however, the user's data and Personal Folders are usually redirected to a share on the network. What would happen is that the user's English OS would create the "My Music" folder on their H: drive and they would listen to tunes quite happily. Then the user would need to spend time at another workstation that happens to have the French OS. The French OS creates a "Ma Musique" folder on the H: drive and thinks it will function quite happily. Unfortunately, the user doesn't realize the switch has been made - all he knows is that Windows Media Player can't find his favourite Alanis Morissette tunes and he calls the help desk. In addition, when the user returns to his usual PC, he finds his tunes once again, but loses the others he downloaded while away and also has a bunch of extra folders in his H: drive.

The abstraction of the Friendly Name handles this in a much smarter way for Vista. I can redirect Vista's User Files Folders to any location I wish. I could redirect the Music folder to H:\MP3s. As long as the Desktop.INI folder is there, specifying that the folder has the name -21790, Vista will know it is the Music folder. When the user chooses a French GUI (did I mention that Vista can change its language through the Control Panel? - very nice), Vista will happily tell the user that he is looking at the "Musique" folder. When the user saves things to H:\Musique, Vista will happily store the file in the only folder it has - H:\MP3s. Very slick.

The only time this doesn't work so well is when the user uses a command prompt window. The DOS window isn't into reading the Desktop.INI - as a result, it will have no idea what to do if the user specifies H:\Musique - the only folder it sees is H:\MP3s. This is only a slight annoyance since most users have no need to use a CMD window.

The only disappointment I have with this feature is that it locks me into using the default names that Vista associates with -21790. When first transitioning to Vista, I was considering redirecting the Users Files Folders to the old XP Personal Folders on the network so the users would have a familiar experience and know where to find things. This would have meant forcing the name of the Music folder to "My Music" (the old XP name). Unfortunately, to do that, I would have had to do away with -21790 and its abstraction features. This would mean that my French users would also see "My Music" rather than "Ma Musique". This would force me back to a French specific OS and the same folder issues I had with XP. I have no desire to go back to that, so I am forced to live with the folder names Microsoft has chosen for Vista.

A more mature version of the Friendly Name feature would allow me to specify multiple names in the Desktop.INI - one for each language I wish to support. Perhaps this is something we will see in future versions. Until then, I must remain with default names and ignore all the apparent flexibility of Vista.

Sunday, September 23, 2007

User Files Folders and the Desktop.INI

File this story under "Interesting Tidbits". The information I provide below will probably seem rather academic, but it will have important repercussions for things like Folder Redirection which I will be describing later.

If you look back at the picture I attached to my previous article titled "Introducing the User Files Folders!", you will notice that most of Vista's 11 User Files Folders are represented by unique icons (Favorites has a star, while Music has a note, etc.). Most people aren't aware how this trick is done and are surprised when these icons sometimes revert back to a plain, vanilla file folder. Just as in XP, Vista puts a hidden Desktop.INI file in each User Files Folder it creates. Windows Explorer later reads this file to determine how it should label a particular folder and what icon it should associate with it. That's it - that's the whole trick. If a folder eventually reverts back to a plain folder icon, you can bet that it's because the Desktop.INI file got accidentally deleted.

Here is a sample Desktop.INI file from an XP system for the "My Music" folder:

[DeleteOnCopy]
Owner=GMartin
Personalized=13
PersonalizedName=My Music
[.ShellClassInfo]
InfoTip=@Shell32.dll,-12689
IconFile=%SystemRoot%\system32\shell32.dll
IconIndex=-237


A desktop INI folder can hold a great variety of values and be formatted with different sections, but this simple example will do for our purposes. What I would like to point out is that the Desktop.INI file does specify the icon to display for the folder - it is the IconIndex -237 from the IconFile Shell32.dll.

Did you notice earlier that I mentioned that the Desktop.INI file tells Windows Explorer how it should label the folder? This is important - it's that innocent looking value called PersonalizedName that is assigned "My Music". This may not seem interesting since it appears to hold the value of the folder name - but you can change it. If you change it to some other value like "My MP3s", the user will see this new folder name when browsing the Personal Folder rather than its real name of "My Music" as it is actually stored on the hard disk - the user is fooled into seeing a folder name that doesn't really exist. Lately publications are calling this fake name the Friendly Name.

Do you remember that we are still only talking about XP? Also, please notice that the Desktop.INI folder has an Owner value that has been assigned my login name - this seems unimportant doesn't it.

Time to move on to Vista's Desktop.INI file - here is a sample Desktop.INI file from a Vista system for the "My Music folder:

[.ShellClassInfo]
LocalizedResourceName= @%SystemRoot%\system32\shell32.dll,-21790
InfoTip=@%SystemRoot%\system32\shell32.dll,-12689
IconResource=%SystemRoot%\system32\imageres.dll,-108
IconFile=%SystemRoot%\system32\shell32.dll
IconIndex=-237
[LocalizedFileNames]
Sample Music.lnk=@%SystemRoot%\system32\shell32.dll,-21806

Notice that we still have IconFile and IconIndex and they basically still hold the same values (i.e. -237). The Music folder is still specifying the icon to be displayed in the same way.

But notice that there is no PersonalizedName value. It turns out that LocalizedResourceName serves this function in Vista. At this point I want you to ask "Gord, how can this be? I don't see the value 'Music' listed there?". Great question! You now just see a number like -21790 and the file Shell32.dll. Well, it turns out that if Windows Explorer asks Shell32.dll what -21790 means, it will be told that it means "Music". Vista has added an extra layer of abstraction for the friendly name. I want to leave you wondering why Microsoft might have done this.

Please also notice that the Owner value is no longer listed in Vista's Desktop.INI.

It's now time to reward you for reading this article for this long and surviving the boredom... The experienced LAN admins among you might now be getting worried about your mixed environments. What if you are redirecting the User Files Folders/Personal Folders to a network share and your users might access them from either a Vista box or an XP box. If the Desktop.INI files of each OS use different formats and different values, what will happen to the folders? It turns out everything works out just fine! Here is a test I conducted:

  • I redirected Vista's Music folder to a folder called "Audio" on a network share.
  • I was able to confirm that the Desktop.INI file was doing its job because when I browsed to it with Windows Explorer I still saw the folder as "Music" (there's that trickery again).
  • I then used an XP system to browse to that same folder - what I found was a "My Music" folder - no problem!
But how can this be?? The only possible explanation is that the LocalizedResourceName is even supported by XP but that it just wasn't leveraged before.

The story's not over, but it is enough for today. I've got two more Desktop.INI articles coming before we move onto more interesting topics like Folder Redirection, User Access Control (UAC) and Logon Scripts. If you'd like to learn more about the contents of the Desktop.INI, I've included a link to a wonderful site at the bottom of this page.

Saturday, September 22, 2007

Introducing the User Files Folders!

I thought I'd kick things off with a series of articles describing the Vista User Files Folders. (I happen to have a lot of info about this already so I won't need to do tons of additional research for these articles.)

What was referred to as Personal Folders in XP is now referred to , by some publications, as the User's Files Folder in Vista (You can find S's applied differently to various words in this name, so mix it up when performing Google searches).

In XP the folder was listed in Windows Explorer as My Documents. In Vista, it is listed as the user’s AD display name (“FR, Test” in this example):

In XP, the My Documents folder was considered the parent folder that housed the various personal folders such as My Music or My Pictures. This is no longer the case. Vista's Documents folder is simply a peer of the other 10 folders that comprise the Users Files Folders (this is an incredibly important detail).

Vista has also done away with all the “My” prefixes to shorten the names to such things as Music and Pictures.
(This interesting detail will be covered in a future article - look for it.)

11 Folders!: Look at them. You now have folders for Videos, Saved Games and Downloads. I guess Microsoft noticed XP applications creating a myriad of folders under My documents for various purposes and decided to pre-create some of the more popular ones. You should note that you are stuck with these 11. You cannot eliminate these folders - and in many ways, you cannot add to them. (I'm sure this was done so that applications would know that the Downloads folder would always be a valid folder if it was designed to save things there.)

The Documents folder is just a peer!: Take a look at where the Documents folder is. It is buried down with the rest of the User Files Folders. It is no longer the parent that possesses the others. This is a HUGE change that impacts things in some surprising ways. In the XP days, applications created folders such as "My Videos" under the "My Documents" folder and you would have found them along side all of the other folders. Now with Vista, if you use an old XP application, it will keep putting the folder under Documents - only now that is buried one level deeper and won't be found along side these 11 default folders. As you replace your applications with ones designed for Vista, I am sure they will begin to use the default folders provided. You might think that an application will want to create a folder along side the default 11 folders, but I think you will find this not to be the case - this is because of folder redirection.

Changes to Folder Redirection!: This topic deserves an entire article or two - so watch for them. In the mean time, let me whet your appetite... Most self-respecting LAN admins like to redirect the My Documents folder to a network drive. This coaxes data off of local PC hard drives and greatly improves the odds of data being backed up. In XP you would redirect the My Documents folder to a network share and your work was pretty much done since all data folders basically fell under it (it is the parent after all). This is no longer the case in Vista. Vista does not allow you to redirect the parent folder any longer ("FR, Test" in the example above). Instead, you must redirect each of the 11 folders individually (+2 other folders if you want to redirect the whole user profile). Here's a cute bit... If a user or application puts a file or folder in the root User Files Folder (i.e. "FR, Test\Financial"), there is no way to redirect that folder. The folder would stay local and would not be backed up. Does this sound dangerous to you yet? (It pissed us off.) Now luckily Microsoft has provided an optional GPO that prevents users from being allowed to write to the root of this folder; however, it only blocks them in the GUI - it does nothing if they access the folder's C: path directly or if they use a CMD window. User retraining will be required so that they understand what to do when they can no longer save files to the usual root location.

This new structure has also presented me with all sorts of challenges having to do with user migration, folder redirection and network storage - but I don't think it adds anything beneficial. There is some implied flexibility, but my experiments revealed that only the default approach was even remotely valid. And this new structure does nothing to help most applications. Take Microsoft's own Visio product as an example. It likes to create a "My Shapes" folder under the Documents folder. This behavior will continue since it can't create a folder along side the other 11- the documents folder will remain polluted by all sorts of mysterious folders that will often have little to do with a user's actual documents.

Welcome to the User Files Folder. I've got a ton of related articles planned for this subject so please keep an eye out!


Welcome to my Vista Blog

As I mention in the header, I have spent this year working on the implementation of Vista for a large organization. We had the Microsoft consultants in giving Vista presentations during the weeks leading up to the official Vista launch. We had teams dedicated to product engineering the minute the official copies landed in our hot little hands. We have leveraged our premier Microsoft support and kept our co-located Microsoft consultant busy with our questions and complaints.

During this process I have seriously felt the bleeding edge. I have spent countless hours researching solutions by piecing together hints and fragments found under widely scattered rocks. I have come to realize that it is time for me to give back to the web and to put more of the stuff in my head on paper before I forget it all.

I have seriously gotten in-depth with a few aspects of Vista. The details of which could drown this page in text. In an attempt to compartmentalize, I will be writing a series of articles where a number of them may relate to one technology, but each article will be narrowly focused on one specific aspect of that technology. I hope this format works. I am hoping that these articles will give you a more complete picture of a technology and maybe tie together some of the fragments you have found elsewhere. Now, I'm not getting paid for this and I don't have oodles of time to give to this effort, but I will do my best to be complete and I will update these posts as people
point out the flaws.

At the risk of ruining the punchline at the end of this series of articles, I would like to warn you of my bias. I am no longer a fan of Vista. I have spent a lot of time getting to know this product. It is pretty. It has some nice features. But it is not ready to be used. There are a couple of impressions that I am often left with when looking at this product. It seems like it was rushed out the door. (Plenty of features were developed but they don't seem to have been developed to full maturity.) It seems like the master architect was often on holiday. ( I was frequently impressed by a specific feature, only to realize that it doesn't integrate with other features properly, or that it wasn't designed in a way that I would like to use it.) I know these comments are vague and hard to imagine after 3+ years of Vista development, but I will provide fine examples in future articles.

My conclusion is that you shouldn't give Vista to your general population until SP1 (or maybe SP2) has been released. Your users definitely shouldn't see this OS until the applications you rely on have been released specifically for Vista. This being said, my client is committed to Vista and is pressing forward so that when the OS is ready, we will be ready. I, being the client-focused consultant that I am, am all too happy to help. So read the articles, leave some comments, and maybe we can all find our way to delivering some great Vista implementations for our companies. Oh, and Welcome!