UAC: Vista UAC vulnerabilities

I just found out about an important security update for Vista: KB943078. Betanews published the related article Microsoft acknowledges Vista kernel elevation vulnerability on December 14, 2007 that links to the Microsoft Security Bulletin MS07-066 - Important. Basically, a vulnerability has been found that enables a trojan to elevate itself to full administrator without the user's knowledge, thereby gaining complete control of the system. (This is what they mean when they say that UAC is not a security boundary.)

While we are on the subject of vulnerabilities, here are some other oldies worth knowing about...

PC World published the article Vista's UAC Warnings Can't be Trusted, Symantec Says on February 22, 2007. Basically this is a vulnerability that tricks a user into thinking it is safe to elevate a process. It does this by tricking the system into displaying the trusted green elevation dialog that indicates that the elevation request is coming from a trusted Windows process rather than from an unknown process (that would be displayed with a yellow/orange title bar). You can see samples of the various elevation dialogs here: Getting Started with User Account Control on Windows Vista

That was followed up by eWeek.com on May 16, 2007 with the article Researcher Reveals 2-Step Vista UAC Hack. This article shows that the theoretical vulnerability found by Symantec could actually be exploited. Remember, that this exploit is a weakness in the design of UAC so it won't be patched like was done with the critical security update above. This is a good reminder that your user population should not be given administrator privileges unnecessarily.

While we're on the topic of weakness in UAC design, you will want to have a look at ZDNet's article Hacker, Microsoft duke it out over Vista design flaw posted February, 2007. It points out the compromises made to Vista's elevation procedures when it comes to installing legacy applications. It is important to note that Vista's requirement that you must be admin to install some of these applications is less secure than XP where sometimes you had the opportunity to install products with only basic user rights.

[EDIT 22/01/2008] George Ou who blogs on ZDNet wrote a thoughtful article discussing the link above. He spoke with the two parties involved and got some good insight. Read: What the UAC 'hole' is really about

I also found another article written from the perspective of third party Vista security vendors: Reports of Vista's security weakness 'overblown'
[/EDIT]

UAC: Is Windows Vista secure?

It's the question everyone's been asking. Is Windows Vista secure? The short answer is - "NO". A more fair question is, "Is Windows Vista more secure than XP?". It also happens to be a much harder question to answer.

The short answer is, "Maybe, maybe not.".

Want to watch a senior Microsoft architect attempt to answer that question? This is a one hour interview with Mark Russinovich, Technical Fellow with Microsoft's Core OS team (I have a lot of respect for this guy - he has a lot to teach us.). The Vista security discussion starts at the 18 :45 mark. The topic of rootkits comes up at 31:30. If want to skip the deep architectural discussions or need to cut to the chase quickly, start watching at 39:40.

I have asked the question of security here because it gives me a chance to talk about UAC and Vista security at a more general level before my future articles just deal with individual pieces of technology. There are some important things for you to think about if you plan to deploy Vista in an enterprise.

I should mention that you will want to have some understanding of UAC before reading this article. For a primer on UAC, read my article UAC: An introduction to User Account Control and follow one of the first links.

To be fair, Vista has been built from the ground up with an eye to security. It isn't just User Account Control (UAC) - there are many, many features which combine in an attempt to provide security. Vista has architectural details like the integrity levels that separate the kernel, system, and users or the Address Space Library Randomization (ASLR) which makes system calls harder to find. Microsoft has also added features like Bitlocker and Windows Defender to help protect Vista. Even applications like Outlook and Internet Explorer do their part to lock down the OS.

One of the problems keeping Windows Vista from being secure is that it is the evolution of an insecure product. All new technologies must accommodate the architectures that came before. Vista must remain compatible with past applications developed for XP or risk alienating all of their customers. Not only has Microsoft had to add features like Virtualization and UAC to aid Vista with backward compatibility, but it has had to make fundamental accommodations in its architecture as well. Let's face it, Windows operating systems are general purpose platforms that try to meet the needs of home and enterprise users on countless hardware platforms - the OS must be pliable and customizable in order to make it work in each environment. It is the customizable element of Windows Vista that makes it vulnerable.

I feel strongly that Vista is not where Microsoft wants to be with security. Rather, it is a transitional OS that is leading the industry to where Windows must go. Currently, Vista must allow many program installers administrator access so they can reconfigure the OS. Vista must allow unsigned drivers to execute. Vista is unable to cordon itself off behind security boundaries but must instead put up numerous walls and gates in an attempt to confuse and slow the advance of rogue elements. Although Vista has separated itself between system and user environments, there are few applications that currently respect this division.

Let's expand this last point as an example of insecurity. Microsoft's marketing would have you believe that Vista is secure because it now makes it possible for users to operate without administrator privileges. This may be true someday, but the reality is that it isn't feasible now. While it is true that Vista can run some applications with Standard User rights instead of the Administrator rights required under XP, the truth is that there are still a high percentage of applications that require full administrator rights in order to install - or even function. Every time an installer must be elevated to admin or a user must be given local administrator rights permanently in order to use an application, rogue elements are given an opportunity to flourish. The opportunities may be fewer than with XP, but I think they are still too numerous to make any real difference today. I do expect this situation to improve in the future as applications are redesigned to accommodate the way Vista wants to lock down the OS.

It has been argued that the UAC prompts one receives when the core system is being accessed by a process will limit the power of a rogue element to function within the system. I don't give this argument much credit. I think well written trojans will arrive that can skirt many of these protections. I think a user's ability to know when to disallow elevation of a process will be spotty at best. But the biggest problem that I have is with access to data. All of Microsoft's discussions about security are very much focused on the protection of the OS. Although that is well and good, I can rebuild an OS automagically within hours - my real concern is for my data. UAC will not give me any prompts if an existing trojan begins to send all of my database files on the network to a remote pirate's server.

In my view, it is UAC itself that causes Vista security to lose points to Windows XP. In many cases, UAC requires users to enter their admin credentials (username/password) in a dialog box. The appearance of the elevation dialogs can feel unpredictable to most users. This dialog box can be easily spoofed. If a trojan creates a real looking dialog box and presents it to the administrator at plausible times, it can harvest username and password combinations and send them out to the web. This really wasn't a problem in XP because elevation to an alternate account was much more rare and in those situations it was always a user initiated action with one predictable dialog appearing.

UAC also has people and process problems that may lead to reduced security. Most of Microsoft's UAC documentation speaks of splitting the user's token between user and admin functions as a way of protecting the system. People can't be faulted if they begin to believe that one account for administrative users will be sufficient - but this isn't the case. Heed Microsoft's warning in Chapter 2 of the Windows Vista Security Guide that discusses the need for admin and user accounts to separate out an administrator's tasks. This is about the only place you will find this discussion. The process problems come when you learn how UAC elevation works. You will find that UAC wasn't really designed with Microsoft's security ethos in mind. UAC can really fight you in some situations when you use a two account model. (There will be lots of future discussion on this.) Functionally, the biggest roadblock is the loss of the Run As context menu action to the "smarter" Run as Administrator context menu action (I'll talk more about this in the future as well).

The thing that I think helps Vista score the most security points against XP, is the support it gets from Outlook and Internet Explorer. These two products are the entry points for the bulk of the attacks against our systems. These products work very hard with Vista to limit the power of rogue elements that come from either of these sources. It is Vista's architecture that makes this possible. But there are problems even here. Outlook and Internet Explorer have become so restrictive that it can be difficult for internally developed scripts to send messages or display html info. In fact, I have seen instances where Outlook and Internet Explorer have been elevated to full administrator status in order for systems to continue functioning - kind of defeats the purpose doesn't it?

In the end, I grudgingly give the security trophy to Vista for three reasons. Vista can be customized to mitigate some of its weaknesses (i.e. forcing CTRL+ALT+DELETE before every elevation). Microsoft will adjust Vista as they learn how we enterprise administrators wish to use it and we'll adapt our security policies and procedures to it as well. But the main thing Vista has going for it is that it is new and there aren't many trojans and spyware programs written to work against it yet. It will be interesting to see what the future holds.

Vista's support for multiple languages

In my article User Files Folders are Bilingual, I talked briefly about Vista's multilingual features. A coworker of mine took a Vista screenshot that I thought I should show you guys. It sums up Vista's support for languages other than English rather nicely:


This Vista OS was installed using the French language. If you view the full size image, you can see that it changes icon labels and things to the French language quite nicely. In fact, it is remarkable how much the root English OS can transform itself into a French looking OS. But presented here are some of the things that betray the underlying English OS.

If you look at the Windows Explorer window, you will see the folders you would expect to see on a French Vista OS - namely Programmes for the Program Files folder and Utilisateurs for the Users folder. But it turns out that these folders aren't really there. Windows Explorer knows to present those names because of the Desktop.ini file that each of those folders contains. The folders have a Friendly Name just like the User Files Folders do (see User Files Folders are Bilingual).

To see the real underlying name, one just has to go to a DOS CMD prompt. The CMD prompt does not interpret the Desktop.ini. You can see from the example provided that the Utilisateurs folder cannot be found but the Users folder can be. I don't know why Microsoft never saw fit to make the CMD prompt smart enough to interpret the Desktop.ini file. But it's probably a good thing they didn't because they also never made the Windows Explorer smart enough to suppress interpretation of the Desktop.ini so that the real file folders could be managed. (This was highlighted as a big issue in my article Folder Redirection: Not to the user's home directory.) It is a shame that the two views of the folders can't be consistent and that we users have to be smart enough to understand what is going on here.

Now the third example in the screenshot is something I really don't understand. Did you notice the Start Menu? When you type "C:\" in the Search Box, the start menu endeavors to show you the files and folders on the C: drive. But it doesn't show you them the way the Windows Explorer shows them to you - it chooses to show them to you the way the DOS CMD window shows them to you - without the Desktop.ini interpretation. I don't know why it does this since I would expect this GUI interface to be very much a user interface - whereas I can forgive the CMD oversight since it is often just used by administrators who hopefully have half a clue.

What's also puzzling about the start menu behaving this way, is the fact that the "Search Box" is supposed to be used to search for stuff on your computer - but it won't find the Utilisateurs folder because it doesn't interpret the Desktop.ini.

Now here's a question... If you are writing a guide for French users, which folder path would you tell users to follow?

1. C:\Programmes\...
2. C:\Program Files\...

The first choice is in the language of your users and is likely the folder name they are used to from the Windows XP days. This folder can be easily browsed to using Windows Explorer. But if the user actually types the path into the Search Box or into a CMD window, the path will be invalid.

The second choice is clearly not in the user's language and not a name they are familiar with. The user can't even browse to it since Windows Explorer doesn't display that folder name. BUT if the user types the path into a CMD window or Search Box or Windows Explorer address box, the path will be valid and succeed.

Which do you choose?

UAC: An introduction to User Account Control

It's high time that I get on with my articles about UAC. I have a lot of good info to share - so come back often to read the latest articles about UAC. Let's try to make sense of it together.

User Account Control is one of the major features of Windows Vista. Vista's UAC feature touches all aspects of the operating system and certainly has a huge impact on the user experience. It changes the way users, administrators and developers work within the environment. If you are going to work with Vista, it is important that you understand this feature.

Because the details of UAC are so diverse, it is not possible to describe them to you in one short article and leave you with a good understanding. Instead I present to you many of the best UAC articles I have found on the web.

In future articles I will build on the general information presented here. I will tackle individual aspects of UAC and discuss strategies for coping with the new paradigm as an enterprise administrator.

You will probably want to read these pages in the order I have presented them. They start with general concept and progress to in-depth analysis:

Wikipedia: User Account Control
Read this. The best introductory article on UAC. It avoids the romp through the UAC feature acronyms and gets down to the business of explaining UAC to you. It should give you a good grounding for the rest of the articles to come.

Getting Started with User Account Control on Windows Vista
This is a very nice Microsoft article that does it's best to describe how UAC manifests itself when a user or administrator wants to go about his daily tasks. It shows the different prompts one would see and provides sample actions that would trigger their appearance. Different UAC configuration choices are also discussed.

Inside Windows Vista User Account Control by Mark Russinovich
Ready for some detail? This article is quite heavy on the technical details, but if you can get through it, you will have a very good understanding of UAC.

Understanding and Configuring User Account Control in Windows Vista
This is a very long Microsoft document aimed at most IT professionals. It gives a tour of many of the UAC features from an administrator's perspective. It covers concepts like Integrity Levels, Elevation Prompts, Admin Approval Mode and Application Compatibility. It attempts to give many of the UAC features context, but often overly simplifies complex paradigms - I consider it the UAC brochure. This document is a very useful resource, but will still leave you scratching your head when you meet real world examples.

UAC - What. How. Why.
Do you have an hour? Watch this video! Microsoft's Jon Schwartz, UAC Architect, and Chris Corio, UAC Technical Program Manager, discuss in detail, the development history and architecture of UAC. This video will give you great insight into what the developers were thinking and what problems they were trying to solve. They almost get you thinking that UAC is a desirable feature ;-) The attached viewer Q&A is also very educational.

Teach Your Apps To Play Nicely With Windows Vista User Account Control by Chris Corio
Although aimed at application developers, this article is a valuable read for everyone. It is written by UAC's Technical Program Manager and provides valuable details about how and why UAC does some of the things it does.

The Long-Term Impact of User Account Control by Dr. Jesper M. Johansson
Aimed at anyone who is concerned about security, this article tells you exactly what UAC is and IS NOT from a security perspective. The points made in the article are accurate and can't be stated strongly enough. UAC is not a security boundary - use the best practices suggested to protect yourself.

Windows Vista Application Development Requirements for User Account Control Compatibility
(Also available as a downloadable Word document)
This is a very long Microsoft document aimed at developers. It takes them on a tour of UAC by covering such topics as Access Control List (ACL) Settings, User Interface Privilege Isolation (UIPI), Virtualization and UAC Architecture. It covers many of the UAC features and is therefore a very useful resource. However, despite it's length, it only just touches most topics and does not give the reader enough of an appreciation of how the features will impact their development work.

In-depth analysis of Vista UAC and the creation of CreateProcess...Elevated() APIs by Thomas Hruska
A must read for application developers and some scripting admins. This article looks at how to elevate applications that require full administrative access to the system. It discusses the ShellExecuteEx() with the undocumented "runas" verb and the much talked about manifests. You will understand the UAC Virtualization feature after reading this article. This is a very detailed in-depth article - not for the faint of heart.

PsExec, User Account Control and Security Boundaries by Mark Russinovich
Aimed at the extremely technical administrator, this is an extremely well-informed article. It discusses the UAC security model and how Integrity Levels relate to it. You will know you have a good understand of UAC if you are able to follow this article. BTW, if you are unfamiliar with PSExec, look into it - one awesome tool!

Had enough? Go forth into the world and play with UAC. See how you like it. I think you will quickly find that UAC impacts your life in some rather unexpected ways. As an enterprise administrator and scripter I have bumped into many of these undocumented "features" and behaviours.

I have learned to overcome some limitations and cope with others. In some cases I am still struggling. Perhaps we can work together to achieve workable environments that include UAC. Check back often for many upcoming articles about UAC. (I hope to continue writing two articles per week.) Feel free to ask questions or comment on any of the upcoming articles... now where should I start....

Offline Files: Doesn't sync files modified while offline

One of my most popular articles for Google searches has been Folder Redirection of database files causes corruption! Well, it turns out that the Offline Files feature isn't finished providing us with surprises.

The Offline Files feature is supposed to cache network files locally so that users still have access to them when the network is unavailable. This is invaluable for Laptop users who may wish to work on projects while traveling. Users are able to modify the documents in their local cache and have them synchronize automatically when they return to the office and connect to the network. -- That's the theory at least. 90% of our laptop users have reported failures synchronizing their files. The Sync Center reports "Access Denied" for some files and refuses to sync them.

Further investigation revealed that Offline Files was able to sync newly created files but was unable to sync pre-existing files that were modified while offline. This was traced to yet another bug in the Offline Files feature. Here is Microsoft's KB article for the bug:

http://support.microsoft.com/kb/935663

The Offline Files feature won't be usable until you incorporate the hotfix described in the article. The hotfix is expected to be part of SP1. (It's starting to look like SP1 will fix a lot of Vista bugs after all - Bravo!)

Vista deleting user profiles and data!

It's been an interesting week full of bug fixes and data loss for me. The most exciting case was when I started getting calls from various Vista users claiming that they had lost all of their user settings.

Investigation revealed that users were in fact losing their entire user profiles. All trace of their local profile was completely gone - including all of the user's local folders and files. If we hadn't been using Folder Redirection all of these users would have lost all of their data. Disastrous.

Microsoft was able to quickly find the cause of the problem. It turns out that there was a bug in the GPO "Delete user profiles older than a specified number of days on system restart". The GPO is supposed to delete user profiles from the Vista computer that have been unused for a set number of days. It turns out that the GPO simply deletes the user profiles the set number of days after the user profile was created - whether the profile is being used or not. I guess the logic picked the wrong date to look at.

Two days after resolving my problem, Microsoft posted this KB article:

http://support.microsoft.com/kb/945122

I'm glad to see them react so quickly to such a critical issue. I strongly recommend that you get the hotfix described in this article to prevent the GPO from wiping out your user's data. The fix should be released as part of SP1 - I certainly hope it is.

Folder Redirection: Misbehaves after target move

[EDIT 01/13/2008] Please note that this article has been rewritten to accommodate changes found in Vista Service Pack 1 (SP1 RC1). For those revisiting this article, all references to hacking the registry with a mapped drive letter have been modified. Now the correct value to use is "%HomeShare%%HomePath%" - the attached script has been modified accordingly (although it could be further simplified to ignore drive letter verification now). [/EDIT]

This is a follow-up to my article Folder Redirection: Duplicate User Files Folders II where I suggest the use of the Folder Redirection GPO setting "Move the contents of ______ to the new location". This setting is important to prevent duplication of User File Folders, but can have other undesirable effects. It turns out that this setting can cause all sorts of bad folder redirection behavior when a user's redirected folders get moved from one network share to another. In this article I will discuss the triggers for the problem and possible solutions. I will also be providing a sample script that can help you avoid the problem entirely.

This article is only necessary if one uses the Folder Redirection GPO setting "Move the contents of ______ to the new location". If this setting is disabled, the problems described here don't occur. However, I think I made a very good case for using this setting in my previous article. This setting provides the valuable service of moving user data stored in local User File Folders to the new network locations defined in the Folder Redirection GPOs. Now one might think that Vista has a very sophisticated way of determining when it needs to move data - but in fact, it is really quite simple. Vista looks at registry keys in "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Documents" There is one key per User File Folder that records it's storage location (i.e. Documents = "C:\Users\SRDTest5\Documents"). When Vista kicks off the folder redirection feature at logon time, it simply looks at the keys. If the storage location defined in the key is different than the one defined by the Folder Redirection GPO, Vista knows there has been a change. If the move setting is set, then Vista knows that it must move data from the old location specified in the registry to the new location specified by the GPO.

This may sound just fine -- it works great if we have local data that must get up to the network -- but Vista uses this same thought process if we are moving user data from one server to another. In this case the move setting isn't so good. The problem is that I don't know any self-respecting network administrator who would change the target location for the Folder Redirection GPO from a target such as \\ServerA\ShareA\SRDTest5\Documents to a target such as \\ServerB\ShareB\SRDTest5\Documents and then sit back and wait for Vista to move the data.

The Vista GPO seems to expect an administrator to follow this scenario:

1. An administrator would leave the old target alone.
2. Create an empty folder in the new location and set user permissions to it.
3. The administrator would set the new target in the Folder Redirection GPO.
4. The administrator would then wait for the user to eventually log on.
5. The user finally shows up and logs on.
6. Vista's Folder Redirection feature notices that the GPO target doesn't match the old target specified in the registry and springs into action!
7. Vista holds up the logon process while it moves all data from the old location to the new location (How long does it take to copy a few hundred megabytes in your environment?).
8. Eventually the data finishes copying and the user can get on with his life. (Somewhere in here the Offline Files feature will create a new partnership with the new target and sync up all the data as well.)
9. A few weeks later our administrator checks on the user and sees that he has logged in and that the data has been moved. He then proceeds to remove the user's permissions from the old location -- and decommission the server if that was what he was planning.

Now take the above scenario and imagine having 100 user accounts on one server that needs moving or the regular churn that requires the relocation of some user's data on a weekly basis. The scenario above is completely unworkable, but it is what Vista is demanding.

I now present the scenario we would all expect (and which this article will help you attain):

1. The administrator moves the user's folders from the old target to the new target.
2. He sets the permissions on the new target and removes them from the old one.
3. He tells the Folder Redirection GPO where to find the data (sets the new target).
4. The administrator walks away and never gives the issue another thought.
5. The user shows up weeks later and logs in without a care in the world. (Maybe he is particular bright and notices that the target path changed, but I doubt it.)
   

I think we can agree that this is the way an administrator would choose to work. Unfortunately, if you do it this way, Folder Redirection makes some incredibly horrible decisions when that move setting is set. Folder Redirection will notice that the data has been moved and will attempt to follow its orders to move the data. Unfortunately, the old location will not be available and the move will fail. Folder Redirection will react to this error condition and refuse to redirect to the new location - preferring to remain pointed to the old location. But because the old location is unavailable, it decides that the best course of action is to go into Offline mode and rely on it's locally cached copy of the files. This seems to work for Vista. It doesn't tell the user about any of this and goes on with life. Unfortunately this is a devastating turn of events.

The user never receives any error messages at all. The best Vista does is to put errors in the application event log:


If the user is very aware, they might notice the Offline status being displayed at the bottom of each folder in Explorer - but I doubt they will. How long will the user work before noticing that their user files are no longer getting stored on the network and getting backed up properly? - a week? - a year? Perhaps only after their hard drive crash.

Want to see some other symptoms? Try implementing DFS where the target goes from pointing to the real physical UNC path to a aliased UNC DFS Link. In this case the data doesn't change location but Folder Redirection will be fooled into thinking it did. In this case Folder Redirection will attempt to copy files to themselves and error out again. Folder Redirection will again stay pointed to the old location. In this case it will be a valid path, so files will get stored on the network. But the Offline Files feature decides to disable itself for some reason. This becomes an interesting trap since an administrator will feel he can safely move servers hidden under a DFS link at any time without notifying the user community since they would never notice - but in this case Folder Redirection would break all over again as in the first scenario, but this time the user wouldn't have an Offline cache to fall back on. NASTY!!

What to do to avoid this problem...

I've already mentioned disabling the move feature to avoid the whole mess it creates. But that creates other problems equally problematic. I don't recommend this option.

It turns out you can turn off the Offline Files feature to avoid the problem. For some reason Folder Redirection is willing to adopt the new target location even when it encounters errors - so long as Offline Files isn't in the mix. Of course, laptops absolutely rely on this feature and I'm sure you will have many other valid reasons to want to keep Offline Files.

This leaves us with only one solution. It's cludgy, but it works. Trick Folder Redirection so it never notices the target change.

Remember how Folder Redirection recognizes a data move? It compares the target in the GPO against the target it has stored in the registry. Remember how in my article Folder Redirection: Specifying a target share we learned how to setup Basic Folder Redirection so we never have to change the target values in the GPO but rather just change paths in user AD profiles? Well, we can use the same trick on the registry! Let's use the Documents folder as an example... The GPO has a target set to "%HomeShare%%HomePath%Documents". Set the registry key to the exact same string. If you give a user's AD profile a new Home Path like "\\ServerB\ShareB\SRDTest5", the GPO will determine that the new target is "\\ServerB\ShareB\SRDTEst5\Documents" - the GPO will then check the registry to see if the target had changed since last time - but since the registry is now using the same variables, it will return the same path of "\\ServerB\ShareB\SRDTest5\Documents". Folder Redirection will have no clue anything happened. It won't attempt a move of the data - no errors will occur and no strange coping decisions will be made. Life will be calm and beautiful.

(I know this article has been a long one already.... please bear with me for a long explanation and a long script.)

You may feel that this doesn't offer much of a solution because you can't find or visit the registry of every affected user on every machine they may have a profile on in order to make this change. It turns out there is a nice labour saving trick if you lay the cards out right...

The main thing to do is to make sure that every user has a Home Path defined - as I described in Folder Redirection: Specifying a target share. You can put the variables in the various Folder Redirection registry keys like so: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Documents" = "%HomeShare%%HomePath%Documents"

Substituting variables for the UNC path is a simple generic change that can be made to all users at logon time through a logon script. Folder Redirection will continue to function during the user's session because the variables and real UNC path agree with each other and point to the exact same location.

Here's a sample VBScript that you can incorporate into your logon script. It will pull off the trick just discussed. It will run in any domain with any Folder Redirection scheme. It does assume that a drive letter and UNC path have been defined as the user's Home Path in his AD User Profile - if this is not the case then you will need to adjust the script.

(This script should be largely unreadable here, but if you highlight it, you can copy and past it into a text editor and save it as a .VBS file.)

'********************************************************************
' Vista Logon script by GordonPMartin@gmail.com, November 2007
'********************************************************************

' User Files Folders are redirected to the Home drive UNC path in Windows Vista
' To improve the user experience and solve an Offline file problem, the redirection must be
' reset to a drive letter at every logon...

' First we need to connect to Active Directory to collect information about the user's AD Profile...

Set objSysInfo = CreateObject("ADSystemInfo")
strUserDN = objSysInfo.UserName
strUserDN = Replace(strUserDN, "/", "\/") ' Microsoft AD uses "/" as a delimiter - any occurrances of it must be prefaced by a "\"
Set objLDAPUser = GetObject("LDAP://" & strUserDN) ' This is our LDAP handle to AD info about the current user

' Time to collect information about the user's home paths.

blnHomeDrive = False ' Flag tracks if we have a valid home drive
strMessage = "No Home Drive defined in the user's AD profile." ' Default error message

If objLDAPUser.HomeDrive > "" then ' The user has a home drive defined
strHomeMapping = ""
strHomeDrive = UCase(Left(Trim(objLDAPUser.HomeDrive),1)) ' Here is the home drive's letter
strHomeDirectory = UCase(Trim(objLDAPUser.HomeDirectory)) ' Here is the UNC path of the user's home directory
strHomeFolder = strHomeDrive & ": = " & strHomeDirectory

' Let's ensure that any Home Folder that has been defined in AD was actually mapped...
Set objFSO = CreateObject("Scripting.FileSystemObject")
For Each objDrive In objFSO.Drives ' Let's look at all mappings to find the one that we need...
if objDrive.DriveLetter = strHomeDrive then
' wscript.echo objDrive.DriveLetter & objDrive.DriveType & objDrive.ShareName
if Ucase(objDrive.ShareName) = strHomeDirectory then
   blnHomeDrive = True ' The mapped U: drive matches the defined one!  (yay)
else
    strHomeMapping = objDrive.ShareName ' It isn't mapped correctly - record the current path so we can report it
end if
end if
Next

If blnHomeDrive Then
strMessage = "Valid home folder: " & strHomeFolder & vbCRLF & vbCRLF
Else
strMessage = "Missing Home Folder: " & strHomeFolder & vbCRLF
strMessage = strMessage & "It is currently: " & strHomeDrive & ": = " & strHomeMapping & vbCRLF& vbCRLF
End If
End If

' If we have a valid home drive mapping, we can proceed to work on the Folder Redirection paths...
If blnHomeDrive then
strKey = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" ' The area of the registry to play in

' Load an array with the 13 User Files Folders that might be getting redirected...
' (0 = display name, 1 = registry key, 2 = desired folder path)

 Dim arrUserFolders(16,2)
 ' (0,x) has been intentionally left blank  ;-)
 arrUserFolders(1,0) = "AppData Roaming"
 arrUserFolders(1,1) = "\AppData"
 arrUserFolders(1,2) = "AppData"

 arrUserFolders(2,0) = "Contacts"
 arrUserFolders(2,1) = "\{56784854-C6CB-462B-8169-88E350ACB882}"
 arrUserFolders(2,2) = "Contacts"

 arrUserFolders(3,0) = "Desktop"
 arrUserFolders(3,1) = "\Desktop"
 arrUserFolders(3,2) = "Desktop"

 arrUserFolders(4,0) = "Documents"
 arrUserFolders(4,1) = "\Personal"
 arrUserFolders(4,2) = "Documents"

 arrUserFolders(5,0) = "Downloads"
 arrUserFolders(5,1) = "\{374DE290-123F-4565-9164-39C4925E467B}"
 arrUserFolders(5,2) = "Downloads"

 arrUserFolders(6,0) = "Favorites"
 arrUserFolders(6,1) = "\Favorites"
 arrUserFolders(6,2) = "Favorites"

 arrUserFolders(7,0) = "Links"
 arrUserFolders(7,1) = "\{BFB9D5E0-C6A9-404C-B2B2-AE6DB6AF4968}"
 arrUserFolders(7,2) = "Links"

 arrUserFolders(8,0) = "Music"
 arrUserFolders(8,1) = "\My Music"
 arrUserFolders(8,2) = "Music"

 arrUserFolders(9,0) = "Pictures"
 arrUserFolders(9,1) = "\My Pictures"
 arrUserFolders(9,2) = "Pictures"

 arrUserFolders(10,0) = "Saved Games"
 arrUserFolders(10,1) = "\{4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4}"
 arrUserFolders(10,2) = "Saved Games"

 arrUserFolders(11,0) = "Searches"
 arrUserFolders(11,1) = "\{7D1D3A04-DEBB-4115-95CF-2F29DA2920DA}"
 arrUserFolders(11,2) = "Searches"

 arrUserFolders(12,0) = "Start Menu"
 arrUserFolders(12,1) = "\Start Menu"
 arrUserFolders(12,2) = "Start Menu"

 arrUserFolders(13,0) = "Videos"
 arrUserFolders(13,1) = "\My Video"
 arrUserFolders(13,2) = "Videos"

 ' That takes care of the main 13 folders that get redirected.  Now here are some more that seem relevant...

 arrUserFolders(14,0) = "Administrative Tools"
 arrUserFolders(14,1) = "\Administrative Tools"
 arrUserFolders(14,2) = "Start Menu\Programs\Administrative Tools"

 arrUserFolders(15,0) = "Programs"
 arrUserFolders(15,1) = "\Programs"
 arrUserFolders(15,2) = "Start Menu\Programs"

 arrUserFolders(16,0) = "Startup"
 arrUserFolders(16,1) = "\Startup"
 arrUserFolders(16,2) = "Start Menu\Programs\Startup"

' Process each of the User Files Folders in the array...

Set objShell = WScript.CreateObject("WScript.Shell")

for intFolder = 1 to 16
strCurrent = objShell.RegRead (strKey & arrUserFolders(intFolder, 1)) ' Get the path from the registry

If Left(strCurrent, 2) = "\\" then ' We have a UNC path!  The folder is being redirected!
' Do the drive letter substition...
' strSubstPath = strHomeDrive & ":\" ' This is the pre-SP1 version where we substituted a drive letter
strSubstPath = "%HomeShare%%HomePath%" ' This is the post-SP1 version where we substitute variables that get evaluated at logon time
If Right(objEnvProcess("HomePath"), 1) <> "\" then strSubstPath = strSubstPath & "\" ' We need one backslash at the end (no more, no less)
objShell.RegWrite strKey & arrUserFolders(intFolder, 1), strSubstPath & arrUserFolders(intFolder, 2)
'     wscript.echo strKey & arrUserFolders(intFolder, 1) & vbcrlf & strHomeDrive & ":" & arrUserFolders(intFolder, 2)

' Check the registry again to ensure that the new setting is there
strCurrent = objShell.RegRead (strKey & arrUserFolders(intFolder, 1))
End If

' Report the paths to the user
strMessage = strMessage & arrUserFolders(intFolder, 0) & " directed to " & strCurrent & vbcrlf
Next
End if

wscript.echo strMessage

I should mention that this script will only modify User Shell Folders that have been redirected to a UNC path. It will not affect users who have local User Files Folders. You can safely deploy a version of this script to all users in your organization.

Obviously the ideal solution to all of this is for Microsoft to fix the Folder Redirection feature. It wouldn't take much. I think a simple addition of one more setting in the Folder Redirection GPO would do the trick. The GPO should have a setting to determine how to treat new accounts or local data - something like "Move local User File Folders to the network". If the current move setting was to only apply to UNC path changes where both paths are network paths, it would fix everything. We could use the local setting to make sure we get all user data up to the network (avoiding duplicate folders) but at the same time choose to have no data moved when a server-to-server data move occurs. Are you listening Microsoft?

Thanks for slogging through this long article with me. Please share any interesting behaviours you may encounter.

Vista: Even the packaging needs instructions

Windows Vista is so complicated that instructions are needed just to open the box - no joke!

http://windowshelp.microsoft.com/Windows/en-US/help/2e680b8d-211e-41c5-a0bf-9ccc6d7e62a21033.mspx

Now for the jokes from my team:

"Doesn’t surprise me - What surprises me is that opening the product package actually works."
"Knowing Microsoft, they provided the scissors - but INSIDE THE BOX"
"Ya, but they are probably battery operated and have a laser guide... Batteries not included."
"But you have to buy an extra CAL to be able to use the scissors... with EA."

I just couldn't resist...

Folder Redirection: Duplicate User Files Folders II

Duplicate folders appearing in Vista have become an obsession if my Google hits are to be believed - and for good reason. I am amazed at how many different ways Vista and Folder Redirection can cause duplicate or extra folders to appear. If this article doesn't match your situation, take a look at my article Duplicate Folder Problems? Talk to me! which will lead you to my other articles on the subject.

Did you just configure user(s) for Folder Redirection and end up with duplicate User Files Folders like this?:


Or maybe you got lucky and can tell the duplicates apart because of the Offline Files sync icon like this:


The problem is likely caused by the Folder Redirection GPO setting "Move the contents of ______ to the new location" which can be set for each of the 13 User Files Folders. If the setting is disabled, you will get the duplicates shown above.

Here's what happens... The User Files Folders are subfolders displayed under the user's name (SRDTest5 in this case). But the user's name actually represents the parent folder C:\Users\SRDTest5. Any subfolders located in this directory location are displayed. (You will sometimes see even more folders if the user chooses to see hidden and system files.) The folder will also display any redirected folders (wherever they are stored) as if they are located within C:\Users\SRDTest5. When User Files Folders are redirected to a network location, the folders are still displayed as if they are stored locally. However, if the setting to move contents to a new location was not set, then the original folders were not moved and will still exist locally -- and will also be displayed. This gets you your duplication.

You now have a slight problem on your hands. The only way to tell the folders apart is to check out the properties of the folders which will tell you the real storage location. The folders stored on the network are the only legitimate folders, but the local folders are the only ones storing any user data!

You will need to find a way to merge these two folders and delete the illegitimate one. If this situation just occurred and the user hasn't stored anything in the new redirected folder, you may have an easy solution. Look into unlinking the Folder Redirection GPO from your affected user(s). Once Folder Redirection is cancelled and each user has logged in at least once with local folders, you can set the move contents settings described above and relink your GPO to the affected user(s). Vista should think that it is redirecting folders for your user for the first time and move the data to the new folders.

To ensure that no new Vista users (and particularly migrated ones) end up with duplicate folders, you should leave the Folder Redirection GPO set to "Move the contents of ______ to the new location" at all times. This will ensure that the local User Files Folders do not remain local. This also has added benefit for those of you who have been using Vista for a while without Folder Redirection. In your case you are likely to have users who have logged onto multiple Vista computers and left multiple Local User Profiles lying around. With this settings, a user's Redirected Folder will hoover up any local user files left in the various local User Files Folders. This will ensure that all of the user's files are safely stored on the network.

Now that we have all that cleared up, come back for my next article where I tell you to do exactly the opposite.

Folder Redirection: Back to talk about Settings

Well, not a single article posted about UAC and I'm back talking about Folder Redirection again. Is it possible to become a consultant that specializes in nothing but Folder Redirection?!

I have written a number of articles about Folder Redirection configuration choices, management headaches and problems (check my archives if you are curious). But until now I haven't mentioned the settings tab of each folder's redirection GPO -- here it is:


The reason I haven't talked about it is because I didn't want my blog to become a Microsoft brochure like so many other books have. I'd rather leave the generic education to them and deal with the bits where the rubber hits the road. The tricky bits that don't behave as advertised but which still must function at the end of the day. Many of the options on the Folder Redirection settings tab are well explained elsewhere and are usually set as a reaction to one's own environment.

Unfortunately it is time to talk about this tab! The property called "Move the contents of ______ to the new location" deserves special attention for its ability to behave in unpredictable ways -- two articles worth! This option sucks big time. I loath it.

Come back soon for the first article in the series!

Let's talk Roaming User Profiles

Regular readers of my blog will know that I have written a lot of articles about Vista's User Files Folders and the Folder Redirection feature. Folder Redirection is beneficial because it moves all of the User Files Folders to a network share. Not only does this make user data accessible from any workstation on the network and facilitate data security, it also offers some wonderful benefits for Roaming Profiles.

User profiles are made up of the User Files Folders, local AppData folders and the user registry settings. By redirecting the User Files Folders to the network, the largest part of the user's profile is taken off of the local machine. The resulting lean User Profile can then be made to roam quite effectively.

A Roaming User Profile:

• is a User Profile that is stored on a network server share.
• is copied down to a workstation at logon time.
• provides all of the user's settings/preferences while using Windows.
• is copied back to the network server share when the user logs off.
• is stored securely on a server and backed up until the next time the user logs on.
  

It is wonderful to have a user's entire collection of settings and preferences follow them from one workstation to another without being stranded on any particular one. Having Folder Redirection shrink the size of the User Profile so that it can be copied down to the workstation quickly at logon time is a godsend.

I haven't planned to write much about Roaming User Profiles because it is very much a "set and forget" kind of thing as far as the configuration options go. The hard work is navigating all the Folder Redirection options and I've already covered that (check the archives in the blog if you want to see those articles).

Here is a very nice document from Microsoft Windows Vista: Managing Roaming User Data Deployment Guide that will get you started. It will tell you how to activate Roaming User Profiles for your users.

The document also talks about cohabitation of Vista with XP. As far as I am concerned, you will have to treat XP and Vista profiles as two completely unique and separate entities. Users who must roam between the two OSes will use a different profile on each OS without settings following them back and forth. After reading my past article Introducing the User Files Folders! I think you'll forgive me if I also declare that you won't be able to share Vista User Files Folders with XP Personal Folders in a mixed environment. They are just too different. If users wish to access the same data from each of the OS versions, they will have to browse to it manually via a network share or mapped drive - the two OSes won't be able to default to the same locations.


A warning... One thing I am discovering about Roaming User Profiles as I deploy Vista in my organization.... it does not appear to be very reliable. I am encountering instances of some user's profiles not roaming - not copying themselves back up to the server at logoff time. There is an interesting array of behaviours and errors that I am investigating at the moment. If I come to any conclusions or discover any universal solutions, you can be sure I will share them with you here.

Duplicate Folder Problems? Talk to me!

A big shout out to all you Vista admins out there with folder duplication problems! Half the queries sending traffic to my site are searches for information about duplicate folders. It is clearly a large problem for many of you.

If you have come to my site because of a similar problem, I would like to direct you to four articles I have posted:

Folder Redirection: Duplicate User Files Folders - This one is rather easy to spot and deals with duplication in the User Files Folder.

Folder Redirection: Not to the user's home directory - This one is less obvious, but it is an important article that describes why you can get what appears to be folder duplication in your network shares.

User Files Folders: What's with all these extra folders - This one talks about Junctions. Junctions can be mistaken for duplicate or dysfunctional folders.

Folder Redirection: Duplicate User Files Folders II - This demonstrates major duplication caused by the "Move the contents of ______ to the new location" GPO setting not being set.

If you are experiencing some other form of duplication not covered by these articles, please send me an e-mail or post a reply to this article. I'd love to help. When sending your request, please be as descriptive as possible and attach screen shots if appropriate.

Thanks,

Gordon

User Files Folders: What's with all these extra folders?

In a previous article, Introducing the User Files Folders!, I showed you the 11 green folders that comprise the User Files Folder for a nice new profile in Windows Vista. With that article and some of the others in this blog I think I have demonstrated how that folder can fill up rather quickly with quite a few others. As it turns out there are a few more subfolders worth mentioning.

Did you know that without adding anything into your User Files Folder you can end up with something like this?!?!?:


It's time to talk about these folders because some of you are coming across them in the wild and don't realize how they got there. Some of you don't yet realize how you made them appear on your own Vista desktops. Still others think they have duplicate folders or even completely dysfunctional folders on their hands.

If you read my article Introducing the User Files Folders! you will know that the Documents folder (formerly My Documents) is no longer the parent folder but merely a peer. But I never really talked about what the parent folder is. The parent folder is listed as the user’s AD display name (“Martin, Gordon” in this example), but in reality it is the user's actual profile folder (C:\USERS\GMARTIN in this example). In the past with XP, the User Files Folder was the "My Documents" folder and it was a little subfolder within the user's profile waiting to get filled with the user's data. Now under Vista, the User Files Folder is the whole user profile! It's already full of junk - it's just hidden from the user.

I guess you know where the rest of this article is going...

I don't know why, but for some reason Microsoft decided that the User Files Folder should allow a user to see every one of their files - even those that a normal user wouldn't want to see. I guess Microsoft decided that if a user is able to figure out how to see their hidden and system files, that they will want to see all those that pertain to them in this folder. (I guess they forgot about us admins that briefly make a user's hidden files visible for technical support reasons and then forget to make them hidden again.) At any rate, you now know the story so let's wrap up with a few final details and griping...

In Vista, basically all system data that pertains to a specific user is stored in the AppData folder. The AppData folder is really king in these parts. It contains the Local Settings, Cookies, Start Menu and pretty much everything else. This folder is hidden - and therefore invisible to the user - until you choose Folder Options… | Do not show hidden files and folders from the Microsoft Explorer's Tools menu. (Can't see the Tools menu? Press the ALT key.)

You may be starting to doubt me here because my picture above plainly shows those folders outside the AppData folder. But trust me, Vista's lying to you - not me. See the black shortcut arrow on the folder icon for a bunch of the folders up there? That is your only clue that those folders aren't folders at all, but rather Junctions. Junctions are a new invention for Vista that fools older XP applications into thinking the folders are where they expect them to be. Meanwhile Vista has squirreled these folders off into the AppData folder. This wouldn't be so bad except that Vista is fooling a good many of us admins as well.

Microsoft thought they were being clever by making these folders hidden system folders. But let's face it, what admin hasn't chosen to show hidden files and Unhide protected operating system files? (BTW, that's done the same way as for the unhiding described above.) Of course that is long forgotten by the time you pull into your personal profile looking for your SendTo folder and find it staring you in the face right were you know it should be (because you are an experienced XP admin). You then click on it. It gives you some strange error about not being available but shows you the contents you requested anyway. You have to be ultra aware to notice that it has transported you off to the real location within the AppData folder. If you happen to be just that aware, you probably went back to that first folder to sniff around and try to figure out what just happened. You might even check the properties of the folder. It won't be any help to you. The only way to know what this folder is, is to key into the fact that there is a little black arrow on the folder icon. Actually, the best way to get info on these folders is to open a CMD window, change to your profile directory and execute DIR /A. Give it a try - I'll wait.....

CMD's DIR /A is the only thing that tells you what is going on. It will tell you which folders are junction points and tell you where you will end up if you dare walk through it. Here is the list it will give you:

Application Data [C:\Users\%UserName%\AppData\Roaming]

Cookies [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Cookies]

Local Settings [C:\Users\%UserName%\AppData\Local]

My Documents [C:\Users\%UserName%\Documents]

NetHood [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Network Shortcuts]

PrintHood [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Printer Shortcuts]

Recent [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Recent]

SendTo [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\SendTo]

Start Menu [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Start Menu]

Templates [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Templates]

Thanks CMD - good info. I wish Vista's GUI could be so forthcoming. Actually, this raises another important point. I have never been driven to CMD so often as I have with Vista. There are a surprising number of things that are best handled through a CMD prompt because there is no alternative in Vista's GUI world. You have just met one example and you will meet more in future articles on this blog.

Folder Redirection: A case study

If you've read my other blog articles regarding Folder Redirection, you know I've analyzed this Microsoft Vista feature to death. I figured I knew how much harder the Vista version was going to be for me to manage and script for and how the users were going to have to adapt to a different experience. I made my configuration choices to provide the best possible solution for my client. The tests and pilots completed successfully, the big day arrived - it was time to deploy to production.

Well, the new feature caused problems I hadn't anticipated. It just so happens that the new Vista Folder Redirection feature breaks (read crashes) an internally developed application. A multi-million dollar application. A mission critical application. Fun eh? This application had been working happily on Vista before I implemented Folder Redirection. It also happened to work perfectly with Folder Redirection under XP. But putting Folder Redirection and Vista together broke this application in two different ways - neither of which I had anticipated.

I thought I'd cover this case here so you could get a good laugh at my expense and so that I could cover two more symptoms of Folder Redirection since that is what my blog has been about so far. I'll cover the more typical problem first...

In my article, Folder Redirection: Specifying a target share I told you about how Vista's Folder Redirection GPO requires a UNC target rather than the drive mapped target that XP used to enjoy. In Folder Redirection: Amateur Magician, I told you how what I would consider to be background details (like the folder's real storage location) manifests itself in the foreground to users and applications. These are the forces at play here. My client's multi-million dollar publishing system relies on an old version of a product called XMetal. At some point XMetal needs to store information in an AppData folder. The software gets the AppData path - but it isn't ready for what it receives. Rather than getting a path with a drive letter it gets a UNC path. This is of course totally new to Vista and Folder Redirection so the application simply trips and falls to the floor.

I tell the application owners to get with the 21st century and support UNC paths! They tell me that they aren't about to spend hundreds of thousands of dollars within the next few days to buy new product and fix a multi-million dollar system just because I feel like upgrading an OS that was working just fine before I fiddled with it. You get the picture - I'm sure many of you have heard similar laments. So, would you like to know what I had to do?

It turns out that there are work-arounds.

The simplest solution and probably most practical is to just stop redirecting the AppData folder and leave it stored locally in the usual location. A local AppData folder will always report a drive letter path rather than a UNC path. There is very little negative impact to this solution. Even though AppData won't follow the other redirected folders, users won't notice this if Roaming User Profiles are also utilized. The Roaming User Profile feature will copy the AppData folder up to the network every time a user logs off and back to the workstation when a user logs on. This isn't so bad for us because our average AppData folder is only 1MB in size and will transfer quickly. But I have heard of AppData folders that are hundreds of megabytes in size, so you may want to judge for yourself.

There is another interesting solution that isn't recommended by Microsoft but holds a lot of promise. It involves modifying the registry entries that control Folder Redirection. The Folder Redirection GPO stores the target path definitions in the registry when the GPOs are applied at logon time. The UNC path for AppData (\\Server\Share\UserDir\AppData) is stored in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder\AppData. Remember that the Vista GPO is unable to use a drive letter because it is applied before drive mappings have been established. UNC paths are necessary if Vista wishes to present the Desktop and Start Menu which are now redirected folders. However, once the Desktop is present and the Logon Script maps any required drives, I see no reason why the registry key above cannot be given a value that does contain a drive letter. It would be a simple matter of the logon script doing a search for the %HomeShare%\%HomePath% in any of the User Shell Folder Keys desired and replacing with the %HomeDrive%. The new path is radically different from the old path but in actual fact points to the exact same place. This is good enough for our multi-million dollar piece of software. I'm just left wishing that Vista's Folder Redirection was a better magician.

[EDIT 01/13/2008] Well, I'm sad to say I just found a reason why the solution outlined above can't be used. The reason is Vista Service Pack 1 Release Candidate 1 (SP1 RC1). It turns out that modifying the registry to point a network drive letter now causes Vista to delete the associated folders right off the network! I have more details in my last article: Service Pack 1 (SP1) for Vista is coming. Sorry for any inconvenience. [/EDIT]

This last solution also provides some other nice benefits. By making this change for all User Files Folders, the user experience will be much more pleasant when performing tasks such as "Save As". The folder pane will open a drive letter a user is used to accessing rather than drilling down into the servers and shares of the UNC path that the user has no interest in (see Folder Redirection: Amateur Magician). It even fixes the problem of CMD not being able to access the redirected User Files Folders when they contain a UNC path (drive letter paths only for CMD). Keeping the AppData folder redirected will also ensure that a Roaming User Profile will get a user logged into the system in the shortest possible time.

I almost hesitate telling you about the second problem that the application had since most of you are unlikely to ever experience the problem - but what the heck... There are many large organizations that ask in-house application development groups to also deploy and support the applications they develop throughout the organization. This is often because the systems must be highly customized to meet individual needs. My client organization is no different. In fact, this application not only needs individual customization, but it also needs frequent and rapid updates. This application group has developed tools that reach out and touch individual workstations and customize them on a per-user, as-and-when needed basis. The problem is that they reach out to the user's Desktop folder to change icons and parameters. But Vista's Folder Redirection moved the desktop to the user's network share for the first time - out of the reach of these application developers! This scenario is quite different from that of a commercial-off-the-shelf (COTS) product, but I'm sure it happens to some of you.

There are a number of ways to solve this problem. Giving developers access to every user's Desktop folder on the server is possible but not practical. Instead, the developers should adapt and deploy their applications differently. The typical recommendation from Microsoft is to divide the installation routine into two distinct parts. One part would be run as an administrator to install the machine specific elements of the program. The other part would be set to be run by the user and would only configure the elements specific to the user. The question is how to get the user part to execute. Choices would include an e-mail request with a link, an entry in the all user's Startup folder or perhaps a trigger in the logon script. I'm sure the best answer will be different for everyone.

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.