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.


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.


In order to find out if the shadow key functionality is still present in Server 2008 R2 I executed the following commands:

  1. change user /install
  2. reg add HKCU\Software\Test /v test /d “test”
  3. 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:

  1. change user /install
  2. tcmd757a.exe
  3. 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?


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)
Nicholas Dille’s three articles about shadow keys

, ,

8 Responses to Do Shadow Keys Still Work in Server 2008 R2?

  1. Jacques March 21, 2012 at 04:01 #

    I always enjoy your posts, Helge.

    For another article on the subject, see

    For another utility that can both display and flip the TS-aware flag, see the link to “TSFlag” at

    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. :-)


    • Helge March 21, 2012 at 09:21 #

      Good info! And thanks for the offer ;-)

      • Jacques Bensimon March 6, 2016 at 02:57 #

        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?


  2. Clemens March 23, 2012 at 05:59 #

    Danke fuer den Artikel. Wenn Du mal nach Darwin kommst, geb ich Dir auch ein paar bierchen aus :-)

    • Helge March 23, 2012 at 13:31 #

      Sehr gerne. Mal schauen, wann das klappt ;-)

  3. Aaron Tan April 17, 2014 at 05:36 #

    Thank you. Very helpful and relevant to what I do.

    • Helge Klein April 17, 2014 at 21:24 #

      Aaron: you started a nice blog. Keep going!

  4. David Liu July 17, 2014 at 04:54 #

    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?

Leave a Reply