How TermSrvCopyKeyOnce Influences Shadow KeysPublished on 12 Nov 2007
Tags #Registry#Shadow Keys#TermSrvCopyKeyOnce
Windows Server with Terminal Services usually runs in execute mode to serve applications. Whenever a new application is being installed, this must be done in install mode for Windows to monitor write operations affecting
HKEY_CURRENT_USER. Switching between install and execute mode is performed by
change user as described in MS KB 186504 - Terminal Server Commands: CHANGE. All changes to
HKEY_CURRENT_USER are then shadowed to
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install, hence the name shadow keys. These keys are copied to a user’s
HKEY_CURRENT_USER hive during logon.
Whenever a shadow key is added, removed or modified, Windows saves the timestamp of the change in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times\LatestRegistryKey:REG_DWORD. During the logon process, userinit.exe compares the key
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\LastUserIniSyncTime:REG_DWORD to determine whether any shadow keys need to be copied to the users registry hive.
So far, this does not come as a surprise as this is well-known. This is documented in MB KB 297379 - Programs can revert to the default settings on Terminal Server which describes an infamous issue: After a terminal server has been reinstalled, the timestamp stored in
LastRegistryKey is newer than the one found in the user’s
LastRegistryKey. If this is the case, Windows recursively traverses all shadow keys and checks the timestamp stored for every registry key and decides whether to copy the corresponding shadow keys to the user’s registry hive overwriting the previous settings. This behaviour can be avoided by backdating the timestamps on all shadow keys. Documentation of this can be found in Shadow Key Time Stamp and Finally! Shadow Key Timestamping Utilities from Microsoft.
There is a very scarcely documented feature concerning shadow keys which prevents these keys from being copied to a user’s registry hive. Suppressing these keys to be shadowed is accomplished by creating a registry value called
TermSrvCopyKeyOnce of the type
REG_DWORD and setting it to
0x1. This indicates to Windows that all values located directly under this key (not recursively!) are not to be copied even if the corresponding timestamp is newer.
The following list describes the possible situations which you may be well aware of:
A user logs on to a system and a new profile is created. In this case, Windows determines that shadow keys have never been copied to the user’s registry hive and reproduces the shadow keys to provide the user with a basic configuration.
An existing user logs on and shadow keys remain unaltered. This is also a trivial case in which no keys are copied to the user’s registry hive.
An existing user logs on and there are changes in the shadow keys. Windows will only copy those shadow keys which have been created or modified.
An existing user logs on and the server has been reinstalled. As the timestamp in the
LOCAL_MACHINEhive is newer than the timestamp in the user’s hive, all shadow keys are copied. This results in at least some user configuration to be overwritten.
There is a difference in behaviour when a user logs on and there are new or modified shadow keys with
TermSrvCopyKeyOnce set to
0x1: shadow keys are not copied if the user already has a copy. The values may even be removed from the registry (either manually or by some kind of automation) without being written back to the user’s registry hive because
TermSrvCopyKeyOnce prevents this to protect the user’s configuration.
At the time of this writing, there are only three hits in the Microsoft KB.
Introduction to Shadow Keys by Brian Madden: How Applications use the Registry in Terminal Server Environments (Part 2 of 3)
Microsoft Systems Journal Dezember 1998: Run Your Applications on a Variety of Desktop Platforms with Terminal Server