In case you are administrator of either terminal servers or Citrix\XenApp servers, I am sure you know small life-saver called UPHClean – User Profile Hive Cleanup service. To explain problem that was there since Windows 2000 server:

it happens quite often that driver or application leaks registry\file handles (it opens handle, however doesn’t properly close it afterwards), therefore profile cannot be unloaded. This leads to situation where you have tons of similar profiles (MZugec, MZugec.000, MZugec.001…) and user experience is that their settings are reset to default (because new profile is loaded for them).

This was major pain with roaming profiles – because profile is not unloaded correctly, it cannot be copied back to central profile storage. Microsoft released utility called UPHClean to solve this situation – it was real life saver.

You can read KB from Microsoft with details about that problem: http://support.microsoft.com/kb/837115/en-us.

Now, some mythbusting Problem with profiles that were not unloaded is very common. Also very common recommendation from almost every SBC consultant is – always install UPHClean. However that’s not completely true.

Always install UPHClean if you are running Windows 2003 Server or OLDER operating system.

Since Windows Vista\2008 and newer, we have UPHClean 1.6 included in operating system – it is part of User Profile Service service.

There are however still issues that are not solved by ProfSvc as far as I know – for example hgfs.dat file from VMWare or hsperfdata from Sun (it’s not bug, it’s a feature ). I tried to contact Robin (creator of UPHClean) regarding his future plans, I will share those details with you once he replies.

Therefore, UPHClean is now officially dormant. There are many other changes to user profiles in Vista\7, I would like to share them with future (like using Win32_UserProfile to migrate profiles from workgroup to domain).

Do you still have issues with profiles not being unloaded at logoff? Share it with us in the comments.

Martin Zugec

If you ask regular administrator that got experiences with scripting about his favorite scripting utilities that he is using even in combination with PowerShell today, I guess that many people will reply "Robocopy and PsTools of course". I am one of them – even though I don’t use pstools anymore, robocopy /MIR is one command whose equivalent is simply missing in Powershell.

There are few different versions of Robocopy though:
1.) XP010 – version from Resource Kit that is being used by most administrators
2.) XP026 – updated version, however it’s not easy to get it
3.) XP027 – new version built-into Windows Vista
4.) XP027 – new version built-into Windows 7

Have you noticed something strange? Points 3 and 4 are the same, so why are they mentioned?

Even though version number is the same, Windows 7 version of Robocopy contains some improvements – /MT parameter. Default value is 8, maximum allowed is 128.

With /MT, you can specify how many threads will robocopy use to copy files. I was really curious about these results, so I decided to give it a try and test how different versions of Robocopy compares. For each test I decided to do combination of following variables: files count, files size and number of threads.

First, let’s compare versions 10, 26 and 27. On horizontal, you can see amount of files (100, 1000 and 3000). Lower number is better (amount of time needed to copy those files).

 

As you can see, new version of robocopy was faster in most cases (expect copying 3000 x 1MB files).

Increase of speed is caused by multiple threads running – this is especially useful if you copy multiple small files.

Ok, so we have 8 threads now, does that mean that if I will increase them to 128, it will be fastest? Of course not Below you can find few graphs that I just run today – every line here represents different number of threads (8, 15 and 40):

As you can see, performance is not very stable and different combination of factors sometimes favors more and sometimes less threads. Therefore my recommendation – don’t mess with threads (unless you got static jobs that you run over and over) and simply enjoy the fact that it is faster

Suddenly, one scenario that could really benefit from multi-threading is not supported yet In robocopy, if file is locked and cannot be overwritten, robocopy will retry it over and over – by default 1.000.000 times with delay of 30 seconds between those retries. You would expect that in case of multi-threaded copy one thread will try it over and over and the rest would simply continue, however whole robocopy will hang. It would be nice to have additional switch to support this mode.

It’s also important to mention disadvantages\bugs of all versions of robocopy:

XP010 – too old There are some bugs related to mirroring security settings for example and of course performance was greatly improved in recent versions.
XP026 – NO ERRORLEVEL. There is bug in this version that doesn’t return correct errorlevels (it’s always 0). Not fixed as far as I know.
XP027 – runs only at Windows Vista. You cannot copy it over to XP\2003 server and use it there anymore
XP027 (Win7) – runs ONLY at Windows 7 – even if you try to copy it over to Windows Vista machine, it won’t help you at all (I will talk about this in detail in upcoming Win7 Inside Out article).

Don’t forget that graphs included in this post are just informative – I didn’t rerun them few times over and over, I just wanted to get quick idea how different is performance between versions.

Martin Zugec

Tip no. 2 from Win7 Inside Out can be categories as myth busting. “GodMode” in Windows 7 is currently very popular myth and I don’t like myths at all

Trick is very simple – just create folder called GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} anywhere on your system and you will get access to secret folder with many different options.

In reality, you DON’T get access to any new options or features.

In Windows 7 (and also previous version), you could create easily links to shell folders. Idea is very simple – you see folder XXX in explorer and using that folder, you can access features. Probably most known folder of this type in Windows 7 is folder called Libraries – that’s true, it is just folder and libraries themselves are just XML files (more details later on).

These folders are identified using GUID and can be found in registry key HKLM\HKEY_CLASSES_ROOT\CLSID. As a rule of thumb (doesn’t always apply), you can say that if key contains ShellFolder subkey AND property LocalizedString, you can use it.

To access such folders from your computer, simply create folder in format FolderName.GUID. For example try to create following folder on your desktop:

SecretLogon.{0142e4d0-fb7a-11dc-ba4a-000ffe7ab428}

As you can see, as soon as you hit enter it turned out automatically to folder with name SecretLogon and icon changed also:

When you try to click on it, secret backdoor that allows Microsoft employees to logon to your computer will appear (just kidding – it’s simply link to Biometric from Control panel):

 

Well, so called “GodMode” is nothing else than accessing already existing entries from control panel. Not sure how about you, but I prefer instant search to searching through tons of configuration options.

Just for reference, below are some GUIDs that you can also use.

Fingerprint – {0142e4d0-fb7a-11dc-ba4a-000ffe7ab428}

Power options – {025A5937-A6BE-4686-A844-36FE4BEC8B6D}

Libraries – {031E4825-7B94-4dc3-B131-E946B44C8DD5}

Wifi – {1FA9085F-25A2-489B-85D4-86326EEDCD87}

Computer – {20D04FE0-3AEA-1069-A2D8-08002B30309D}

There is however something I learned today myself SkyDrive Explorer that was mentioned by Dennis recently is also implemented through shell folders. So if you don’t want to access it through Computer, but want to help link somewhere else, simply create folder SkyDrive.{0016CE0E-728C-4FC9-98E5-D0B35B384597}

UPDATE: Complete list of control panel items that are accessible can be found here: http://msdn.microsoft.com/en-us/library/ee330741(VS.85).aspx

 

Martin Zugec