Overview of Windows Vista User Profiles
In previous versions of Windows the user's profile was largely hidden away and only the more technically-minded of us would ever knowingly delve into its contents. With Windows Vista there seems to have been a significant change in that the profile has been dragged sulkily into the spotlight.
The Windows Vista user profile
The Windows Vista user profile is visible everywhere. It's the very first link in the Start Menu and it appears prominently in Explorer and most Open/Save dialogs. Some dialogs even open directly to this profile location and ignore any Favorite Links. Many people - including myself - initially tried to rebel against this new behaviour and attempted to hide the profile away again. This usually causes its own set of problems when a user who only understands Documents and Pictures suddenly gets a Save dialog with an eyeful of profile. They panic. They blindly click on the root of the C: drive and with brows furrowed in incomprehension they drag the entire contents to the Recycle Bin. Then they pull the power cord out.
Those are the good users. The rest call the helpdesk!
It's much better to embrace the new way of working and provide training around using the user profile to the end users.
Another change in Windows Vista is the ability to independently redirect each of the user profile sub-folders to a network location using Group Policy and Folder Redirection. This can significantly improve logon times in an organisation that uses roaming profiles where users move around lot. A common approach is to redirect the "big hitters" where large files are often stored, such as:
Let's have a look at our Windows Vista profile after we redirect these:
Duplicate infested profile - The Horror!
What's going on here?! What are all these duplicates? Which is the real one? If you thought users panicked when they hadn't seen a profile before then you haven't seen a user when presented with duplicate links! And no, a slightly different icon is never a good enough way to tell the difference. "No, don't save it in the one that looks like a folder, save it in the one that looks like a folder with a document on top of the folder". I think not.
So why does this happen? Well, when redirecting a folder using Group Policy one of the options is to "Move the contents". Unless this option is selected a duplicate link will be left behind - even when that folder is completely empty. The problem is that depending on the way the infrastructure is set up we can't always safely select this option.
Here are some common reasons you might not want to use the "move" option:
If none of the above scenarios applies to you then you are very lucky indeed and can stop reading now. The rest can continue on for a possible workaround...
A Possible Workaround
So, to fix this we need to find a way to automatically remove these duplicate links, let's say on logon. The solution will need to:
Usually I'd use VBScript for something like this, but in order to get the redirected and default profile folder locations we need to use the API call SHGetKnownFolderPath which means writing a custom application in Visual C++ 2008 Express (or the full version if you have it). What? Why don't I just use VBScript and read the registry keys in "Explorer\Shell Folders" and "Explorer\User Shell Folders"? Because Raymond says so, and because Technet says so.
Don't worry about using Visual C++ , it's going to be a tiny program that's pretty easy to follow for a scripter and you'll be able to act smug around the office and throw lines into conversations like: "VBScript, yeah, that's pretty good. I guess. <pause dramatically here> Check out my proper code and cast off your childish ways, mortals!".
The sample code will create a program that can be run as follows (from a login script, logoff script, StartUp group, RunOnce registry key - your choice):
By default, it will move deleted duplicates to the Recycle Bin (safe) but you can force a full deletion using the optional "/norecycle" switch (less safe).
Download the sample code here:
<disclaimer>Remember, this is sample code and you use it at your own risk :)</disclaimer>
A Quick Look at the Code
For the geeks among you let's have a quick look at the code. The main functions are in the "RemoveDuplicateProfileLinks.cpp" file and consist of:
The main two functions wWinMain() and CheckFolder() are shown below so you can see what you are getting yourself into:
The WinMain() function
The CheckFolder() function
That wasn't so hard was it? It's not rocket science after all - it's just brain surgery... Let me know how you get on with this and if you have any other ideas or suggestions.
This post was contributed by Jonathan Bennett a Senior Consultant with Microsoft Services, UK.
>It's much better to embrace the new way of >working and provide training around using the >user profile to the end users.
You have explained how to embrace the new way of working, but have failed to explain why it's better to embrace the new way of working.
Could you compile it and give the exe file. I tried it but i didn't install C++ feature in vs 2008 so cannot test it
Thanks for the article and the work-around. Why can't you just compile the code and post the executable?
I can't really post an exe as that would cause all sorts of testing related troubles for MS. We can provide scripts/sample code but exes are a different beast due to the security implications. Sorry!
I am seeing the same problem with roaming profiles on Windows Server 2008. While I appreciate the workaround (which I intend to try shortly) I was wondering whether this is this a known bug that Microsoft are working on? Is there an KB?