Do Shadow Keys Still Work in Server 2008 R2?
Shadow keys have been around forever, since way before Terminal Services were renamed to Remote Desktop Services (does anybody use that name?). It seemed they would stay in the OS forever, too. Yet, when installing applications on Server 2008 R2 many people notice that the shadow key area does not get populated. Let us find out why that is the case and if shadow keys still work in Server 2008 R2.
Background
A quick refresher what I am talking about: badly written applications create the registry settings they need to run at install time and only for the user currently logged on. Two capital sins Microsoft tried to work around by creating shadow keys. The main idea is that writes to HKCU during setup are captured and replayed for every user logging on individually.
Terminal Servers operate in two modes: install and execute. In the wild old days one had to manually switch to install mode (using the command change user /install
) before every installation, but for a long time the operating system has been clever enough to do that on its own reliably enough.
If install mode is enabled for a session, any changes to HKEY_CURRENT_USER are mirrored to the shadow key areas HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software
(64-bit processes) and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software
(32-bit processes).
In execute mode during logon, timestamps are compared to determine if application settings stored in HKLM need to be copied to HKCU. This happens for every application key individually.
To sum this up, shadow keys are a mechanism to distribute initial application configuration values to all users on a Terminal Server.
Experiment
In order to find out if the shadow key functionality is still present in Server 2008 R2 I executed the following commands:
change user /install
reg add HKCU\Software\Test /v test /d "test"
change user /execute
This adds a registry key “Test” with a value of “test” in install mode. I checked the shadow key areas mentioned above for the Test key and found – nothing. Looks like shadow keys are gone, right?
Then I tried something else:
change user /install
tcmd757a.exe
change user /execute
This runs the installer for Total Commander. The installer creates the key HKEY_CURRENT_USER\Software\Ghisler. I checked the shadow key areas for the Ghisler key and found – an exact copy of the key in HKCU. Apparently, shadow keys are still functional.
But why did my first experiment fail?
TSAWARE
With the help of my new free tool IsTSAwareApp I found that reg.exe
has the flag TSAWARE (i.e. a special bit in the header of the executable is enabled). This means that the developer of reg.exe
says it is aware of terminal services. The installer for Total Commander, on the other hand, does not have the TSAWARE flag.
The conclusion is that shadow keys are enabled only if an executable is not marked as Terminal Services aware. To prove my conclusion I used the Visual C++ tool editbin
to remove the TSAWARE flag from reg.exe
– and, bingo, I could use the modified reg.exe
to create shadow keys during install mode.
The reason why the shadow key areas in the registry are often empty today: most modern applications have the TSAWARE flag which tells the operating system they work correctly on Terminal Servers without crutches like shadow keys.
Windows 8
Is the shadow key functionality still present in Windows 8? I have bad news for some of you: nothing was changed. Shadow keys work the same way in Windows 8 (Beta) as in Server 2008 R2.
Further Reading
Brian Madden: How Applications use the Registry in Terminal Server Environments (Part 2 of 3)
8 Comments
I always enjoy your posts, Helge.
For another article on the subject, see http://www.vmwareinfo.com/2010/11/discovering-terminal-server-aware-flag.html
For another utility that can both display and flip the TS-aware flag, see the link to “TSFlag” at http://www.vmwareinfo.com/2011/10/taming-chameleon-applications.html
By the way, I’m not sure that reg.exe was ever a good test of shadow key behavior in install or execute mode — I think most of the standard registry editing tools (certainly regedit.exe and regini.exe) had certain TS compatibility flags pre-defined in the Registry that turned off the shadow key-related mechanisms for those specific executables — they might otherwise accidentally trigger the copying of shadow entries when the user merely “looks” at some parts of the Registry using those tools.
If you’re ever in New York, I and some colleagues would love to buy you a couple of drinks. :-)
Jacques.
Good info! And thanks for the offer ;-)
The offer is still open :-), but in the meantime I have another (unfortunate) behavior to report on this topic and am curious to see if anybody has a solution:
Besides the logon-time propagation of shadow keys which can occur on the basis of certain timestamp comparisons (a behavior I always considered dangerous since it could accidentally overwrite users’ Registry settings, and therefore disabled in my mandatory profiles by setting their “last sync time” Registry entry to an Epoch date far in the future, i.e. profile always wins), another much more useful behavior was the *execution-time* propagation of Registry entries when they were *missing* from the user profile (the behavior which the TS-aware flag in the executable’s header disables). This involves no timestamp comparison and is (was) a simple and reliable way for an admin to provide initial program settings for an application by putting them “manually” under the shadow keys (i.e. without the help of a setup program running in install mode) — they’d all wind up under HKCU as soon as the program tried to access just one of them (while in execute mode, of course).
Well, although I can still reproduce this behavior with test programs under old Windows 2003-based Terminal Servers, it seems to have disappeared from 2008 R2 RDS servers, at least on the several builds I’ve tested (admittedly all mine! :-)). In other words, 2008 R2 seems to be treating *all* executables as if they have the TS-aware flag. Can anybody confirm or deny this? Am I accidentally turning off this beneficial behavior with some silly policy or setting?
Jacques.
Danke fuer den Artikel. Wenn Du mal nach Darwin kommst, geb ich Dir auch ein paar bierchen aus :-)
Sehr gerne. Mal schauen, wann das klappt ;-)
Thank you. Very helpful and relevant to what I do.
Aaron: you started a nice blog. Keep going!
It is very helpful post. But I have a question. A legacy program needs to use reg keys under HKEY_CURRENT_USER but those keys are not mirrored by Windows 2008 R2 server. I have set up the install mode. I think the problem is because the install package is a Windows installer package and Windows installer is TSAWARE? Is there a way to force Windows to mirror the keys?