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

I promised some time ago that I will post 100 tips and tricks about Windows 7. Biggest problem I encountered was the fact that some tips were about how Windows7 works internally, while others could be described in 1 line (small tips). I decided that I will call these articles Win7 Inside Out. Part 1 is explaining some details about WinSxS, hope so you will find it interesting.

What is most common complain about Windows 7 or Windows Vista? Based on my investigation, it is mysterious WinSxS folder – most people complains that it is huge and instantly growing.

First, let me answer very simple question – is WinSxS really needed and is it clever solution, or just stupid workaround? My answer is very simple – YES, WinSxS is very clever solution and YES, we really need it in order to prevent DLL hell scenarios that we encountered in the past.

One small mistake Microsoft made while planning and designing SxS technology was that they didn’t think about popularity of upcoming netbooks (who could predict that?) and small but fast SSD drives. Currently, only real complain about WinSxS is the fact that you cannot change it’s location and it must reside on HDD where Windows is installed.

Why do we need WinSxS?

For non-programmers, it can be useful to describe functionality of libraries first. According to wikipedia, a library is a collection of subroutines or classes used to develop a software. To simplify it – if routine to copy one file consists of 50 lines of code, you don’t want to write it over and over again, but you rather create function called CopyFile and call this functions (so you use 1 line instead of 50). This is also very important from security perspective – if you discover bug in your routine, you need to fix it just once and it’s fixed for all programs that are using this routine.

In general, we recognize shared and private libraries – shared library needs to be on system just once, while private library needs to be added to every program that needs it. In past, to reduce size, we preferred mostly shared libraries, where multiple programs use single library:

Centralized approach

Well, that sounds like a brilliant idea – in theory. In real life, this just led to problem called DLL hell – to avoid damage to my brain, I won’t write details about it, I am sure you can find tons of complains on Google (915k results). So IT world turned other direction – from strictly centralized structure to decentralized structure:

Decentralized approach

On one hand, DLL hell issue was solved, or wasn’t it? Well, in fact we end up in situation that could be called DLL Hell 2 – it was hell to keep libraries up to date and from security perspective, it was disaster. Not talking about fact that applications were getting very huge in size – much bigger than our WinSxS folder. In my opinion however, it was still better than strictly centralized  structure.

There were many different workarounds and ideas – using .LOCAL files, manifests files, however WinSxS is truly solution worthy software giant like Microsoft.

Why is it so big?

First, let me tell you something – WinSxS is not that big at all. WinSxS is core of Windows operating system – and on my computer (Windows7), it’s 1.3 GB in size.

Hey, but doesn’t that dialog say that it is 5.76 GB? Answer is little bit more complicated – yes and no. WinSxS is using technology called hardlinks heavily – hardlink is according to Wikipedia

directory entry that associates a name with a file on a file system

You can have multiple hardlinks pointing to same place on file system – what it means is that you see multiple names (files), however they refer to same location.

Very common question is why then explorer doesn’t display real size? Answer is pretty simple – all hardlinks are equivalent (which is difference between hardlink and symbolic link), therefore you don’t have master (source) file and link (target) file. If you want to see details about your hardlinks, I can recommend you utility called Hardlink Scanner (both 32 bit and 64 bit) – there is no built-in tool in Windows to see hardlinks configuration.

Difference between hard links and symbolic links

As you can see in above picture – when we use symbolic links, we always have one “master” and one or multiple “slaves” (imagine that slave in .lnk file and master is .exe file), while with hardlinks all links are masters and changing any one of them will automatically change underlying data for all of them.

What it means when we talk about SxS is that most files in WinSxS folder are in fact stored somewhere else. Based on my experiments, almost 80% of files in WinSxS folder are just referencing to existing location (they are just hardlinks to other files). Talking about size of WinSxS folder, on my computer, 4.8 GB were simply linked files, while 1.3 GB were regular files. What is also very important to mention is that Windows is NOT only product that is using WinSxS – many other applications are also, so with bigger Windows folder, your Program Files size can be reduced. The real benefit of SxS technology is therefore pretty much hidden. Based on quick scan, I can see that there are 500 MB of hardlinks stored in my Program Files (30 GB in size).

Can I reduce it?

Well, that’s pretty hard question. Simple answer is no – mostly caused by the fact that removing files from WinSxS simply won’t give you more space (as long as there is any other hardlink pointing to that specific resource).

Uninstalling language packs

There is however very easy trick how you can reduce size of WinSxS folder – by removing language packs. If you have a look at structure of folders in WinSxS folder, you can see naming pattern there:
proc-arch_name_public-key-token_version_culture_hash

As you can see, part of folder name is culture. When you install Windows 7, you can see that multiple language packs are available as optional download:

Every one of them will add new resources to WinSxS folder – on average, it’s around 300 MB per language package. If you install all of them, it’s around 10 GB of data. So easiest way to reduce size of WinSxS is to simply uninstall additional language packs. Easiest way is to run lpksetup.exe – this will open dialog “Install or uninstall display languages”:

Be aware that it takes some time after uninstallation before WinSxS size is reduced!

My results:

EN + CZ:

Full size: 6.45 GB
Hard links: 4.98 GB
Normal files: 1.47 GB

EN only:

Full size: 6.18 GB
Hard links: 4.80 GB
Normal files: 1.37 GB

Deleting Windows Update cache

Second trick you can use is to delete Windows Update cache of manifest files. This file can be found in C:\Windows\WinSxS\ManifestCache folder – usually it’s not worth it, because it is smaller than 200 MB.

Uninstall some applications

As I explained before, some applications may use WinSxS. Usual recommendation is to uninstall some applications – but question is which ones? You can use Hardlink Scanner that was mentioned before to help you.

First find out which folders are biggest – you can use for example WinDirStat to find them.

Then you run Hardlink Scanner with /F switch against files in that directory. You will see something like this in output:

Scanning directories and files…..

Breakdown for "c:\Windows\winsxs\amd64_1394.inf.resources_31bf3856ad364e35_6.1.7
600.16385_en-us_beafdf583b909e3f\1394.inf_loc"
=========================================================
  Unique ID:     100000000687e
  Hardlink count:            2
  Naive file size:       7,176 bytes
  Unique file size:      3,588 bytes
  Kind of file:         normal
  Filenames:
    \Windows\System32\DriverStore\en-US\1394.inf_loc
\Windows\winsxs\amd64_1394.inf.resources_31bf3856ad364e35_6.1.7600.16385
_en-us_beafdf583b909e3f\1394.inf_loc

 

Important part is Filenames – there you can see that this file is both the one in WinSxS and C:\Windows\System32\DriverStore\en-US\1394.inf_loc. That gives you an idea where is this component being used.

…to be continued -  this was first part of our article. This part describes WinSxS in more user-friendly way. In next part, we will go deeper into SxS – how it works, if you can move it to other disk and how can you work with it.