Remko Weijnen's Blog (Remko's Blog)

About Virtualization, VDI, SBC, Application Compatibility and anything else I feel like

Archive for the ‘Windows XP’ Category

ClickOnce is a Microsoft technology that enables an end user to install an application from the web without administrative permissions.

That’s great isn’t it?
While ClickOnce may sound great to developers it’s actually a nightmare for Enterprise administrators because they try to prevent users from installing software themselves.

ClickOnce also incorporates an Automatic Updates mechanism which means that users might run different or not tested/approved versions…

Virtual Environments
It get’s even worse in virtual environments such as VDI and SBC where machines are often non-persistent. Each time the users starts the application they will see a screen similar to the one below while they actually download and install it over and over again:


If the environment is persistent, it’s not guaranteed that the user works on the same machine each day. This means that the application will be installed on every box the user ever logs onto…

How does it work?
In order to understand how we can best treat ClickOnce applications we need to understand how they work since MSDN documentation does not describe this in detail.


I was troubleshooting an unattended installation of a particular application. The install seemed to hang right away so I figured it was presenting some kind of message (error?).

Using a Window Spy tool I made the setup process visible and saw the following message:


The unattended install was supplied by the vendor and apparently they use InstallAware.

The setup tries to create a Tray Icon, probably a setup progress indicator, but this fails because there is no shell running (the installation is pushed from a deployment server).


The case of the missing audio

Yesterday I was asked to investigate a problem with a presentation pc. Even though the volume was set maximal there was not audio output.

The machine was used to connect to a Citrix XenApp desktop and RES Workspace Extender was used to integrate local applications in the XenApp desktop.

The local sound volume control was published as a subscribed application so I launched that and verified that the volume was set to Maximum:


I decided to launch the local explorer shell and noticed that there were two volume control icons in the Traybar:

Volume Controls


Replacing WFP Protected files

imageOn Windows 2000, XP and Server 2003 a mechanism called Windows File Protection (WFP) is used to protect system integrity.

How does WFP Work?
Inside SFCFILES.DLL a list of files is kept that are monitored for changes. When a monitored file gets deleted, modified or overwritten WFP will restore the original from one of the following locations:

  • Cache Folder (%systemroot%\System32\DllCache)
  • Network Installation Path
  • Windows CD (or i386 folder on harddisk)

But what if we need to replace such a file? You could write a batch file that copies the modified file to the cache folder, installation path and destination. And this may work if it’s quick enough.

A more reliable method is to use an undocumented export from sfc_os.dll called SfcFileException (only exported by ordinal #5).


Remote Registry from 32 to 64 bit

imageYesterday I needed to set a few registry keys remotely from a 32 bit windows machine to a 64 bit machine.

I used reg.exe to set the key but even though it returned success the key wasn’t altered.

As I suspected the key was written to the Wow6432Node. In the help I couldn’t find any switch to force reg.exe to use the 64-bit view.

On a 64 bit machine this is not a problem since both 32- and 64 bit versions of reg.exe exists. The 32 bit version of reg.exe defaults to the 32 bit view and the 64 bit version defaults to the 64 bit view.

But luckily reg.exe has a switch (that is not listed in the help) to force the View:

In the previous parts (part 1 part 2) i’ve described the theoretical part and implementation problems. So, now we can write the code:

1) In case we login the user, we just call LsaLogonUser to get the token:

In part 1 I’ve described the theoretical parts needed for a custom autologon application implementation.

But there are some practical problems which I will describe here.

1) I use the LsaLogonUser function to log in the user. However, if I do not pass not null for the LocalGroups parameter, msgina.dll fails to process the logon.

Why? Because it looks for the SE_GROUP_LOGON_ID SID and treat it as logon SID. So we have to add the logon SID manually:

Windows XP introduced the ability to use Fast User Switching (FUS from here on), which is implemented using Terminal Services.

But in some cases (i.e. when FUS is not enabled, or when you connect to the console in Windows 2003 server), the Winlogon process in an RDP session needs to transfer credentials to Session 0.

Although not documented in MSDN, the process of transferring credentials is described by Keith Brown in the June 2005 issue of MSDN magazine: Customizing GINA, Part 2.

WlxQueryConsoleSwitchCredentials and WlxGetConsoleSwitchCredentials are used in the transfer with the semi-documented WLX_SAS_TYPE_AUTHENTICATED SAS code constant.

Internally, winlogon.exe uses a Named Pipe, \\.\Pipe\TerminalServer\AutoReconnect, to implement both of these functions.

The pipe format is described in this structure:

Windows XP Cmd Prompt Patch

A few days ago I needed to test a few things on a Windows XP Workstation running under a regular user account.

I wanted to verify if some files and registry keys existed but Group Policies were in place that denied me access to the command prompt and regedit.

While this may be a good thought to secure the pc it is not very convenient if you need to verify some settings.

For that purpose I created patched versions of the Windows Server 2003 command prompt and regedit utilities.

They are patched to ignore the Group Policy settings and I usually place them in some share, secured by NTFS permissions.

You can read about it in my post: Registry editing has been disabled by your administrator (not anymore!).

However due to kernel differences you cannot use the Windows 2003 cmd.exe on Windows XP (you can do it the other way round btw). So I decided to create a patched version of the XP version as well.

I thought it might be interesting to show you how it’s done so here we go:


  • 1 Comment
  • Filed under: Windows XP
  • As you may know, Fast User Switching (FUS) is not available (disabled) on Windows XP computers joined to a domain, Microsoft confirms this in kb280758.

    However, Microsoft doesn’t tell us there’s an undocumented registry value that allows us to have FUS when joined to a domain!

    To enable FUS you need to set the DWORD registry value HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceFriendlyUI.

    It can also be set by Group Policy at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

    When the value is set to 1, and LogonType key is also set to 1, it allows you to use a Friendly UI on a computer joined in a domain: