Finally! Shadow Key Timestamping Utilities from Microsoft

Written on Sep 14 2004 Filed under: Microsoft Remote Desktop 23,840 views, 21 comments

by Brian Madden

Those of you who are current Terminal Server administrators or who have read my past articles about the shadow key area of the Terminal Server registry know of the challenges of bringing new servers or adding hotfixes to production environments. (The new server will have newer timestamps on keys in the shadow area, therefore causing major headaches when existing users connect to the new servers.)

If you have no idea what I'm talking about, read this article first.

In a nutshell, the only solution to this problem was to (a) set the clock back on a server before installing a new application or hotfix, (b) create new servers from images of old servers, or (c) delete the application keys from the shadow area and manually deploy the registry settings to new users.

Thankfully, we now have an option "d" that's better than all of the previous options. Adrian Billingsley and Mark Prigg enlightened me about a couple of utilities from Microsoft called "RDT" and "SDT." (Performing a Google search on these turns up nothing, so I've made both available in the zip file at the top of this page.) I don't know where these files came from, but the version information seems to indicate they're from Microsoft.

When run on a Terminal Server, RDT.EXE (Read Date Time) can be used to read the date and time stamps from all of the various keys in a the server's shadow area. SDT.EXE (Set Date Time) can be used to manually set the datestamps of those keys to any date that you choose! This allows you to manually (or via a script) "dial back" the datestamps of the software keys in a new server's shadow area. In fact, you should probably run RDT after you install any hotfix (or anything that puts the session into "install mode" to ensure that you don't get any surprises when existing users connect to that server.

There are no words to describe how wonderful these two utilities are and how much easier this will make our lives. Thank you Microsoft!

Comments

Guest wrote Opinion: CU keys in HKLM are fundamentally wrong

on Sun, Dec 12 2004 1:50 PM

This message was originally posted by Leo van der Mee on September 15, 2004
Brian,

I do not agree with your assertion that option "d" is a better solution than solution "c". In my opinion storing CU keys in HKLM is fundamentally wrong. It is against the CU LM seperation philosophy. The philosphy that system (os+apps) settings and user settings should be seperated always 100%. Yes it is true that in solution "c" you have to manage the CU keys yourself. But managing everything is exactly what SBC is all about. For companies where there is no ambition or sufficient resources to have complete control over their environment solution "d" might provide a way out of the shadow key problems. Companies that do want complete control over their environment I advise using a hybrid profile solution where all CU keys are _explicitly_ managed.

Guest wrote Awesome Tips

on Sun, Dec 12 2004 1:50 PM

This message was originally posted by an anonymous visitor on September 15, 2004
Thanks Brian! I've been searching for something like this for a long time.

Guest wrote Opinion: Great Job!

on Sun, Dec 12 2004 1:50 PM

This message was originally posted by Mike Theriault on September 17, 2004
Brian, Unfortunately I have always excercised solution c in most of my cases where I have had to override the shadow area by creating custom registry files so the logon script would get called when the user logs in. These were very crude but workable solutions and I would never consider it a best practice under any circumstance; however, there are situations when these types of hacks are necessary.

Great Job on the articles and thanks for sharing the tools!

Guest wrote Good, but not far enough

on Sun, Dec 12 2004 1:50 PM

This message was originally posted by an anonymous visitor on September 29, 2004
I wish regedit could be set to show all hidden data and allow changes to it.

I have been "officially" pushing Microsoft for a tool like this, and I am amazed that it shows up here. It is rather old and limited in functionality, but should help us a lot as we are quite understaffed and underfunded to the point where we can't even get support contracts. One of the best other tools I have found is the Windows Explorer addin called Registry Explorer where dates can be viewed (not changed) in a GUI. Unfortunately, this application is quite unstable and can crash when viewing some keys.

We have had a terrible time with GPO refreshes in this registry area that hoses the user's roaming profiles when they log in, so this SDT tool might alleviate enterprise meltdowns.

Thanks for posting it!

Guest wrote Awesome Tools

on Sun, Dec 12 2004 1:50 PM

This message was originally posted by KD on September 29, 2004
Haven't used them yet, but the "shadow key" date-time stamps are as miserable as you indicated. GPO refreshes can reset them and putting things back together aftwards is ugly. I look forward to trying them out as we build new servers in the farms. We've been asking MS for this kid of tool for over 2 years... I can't believe how well it's been hidden. I will research with MS and see if they know it exists! It's not perfect, but much more than what we had before!

Guest wrote Only BIG downside...

on Sun, Dec 12 2004 1:52 PM

This message was originally posted by Matthias on October 12, 2004
It won't set the date to 2004.... *sob* I thought I had it all sorted out...

Guest wrote That's not a downside

on Sun, Dec 12 2004 1:52 PM

This message was originally posted by Brian Madden on November 2, 2004
So what if you can't set them to 2004? The purpose of SDT is to set the shadow key timestamps BACK in time. I like to set mine all to 1985. This will ensure that new keys are deployed, and current keys are not overwritten.. (Since the "new" keys would be from 1985.)

Guest wrote You're right, of course...

on Sun, Dec 12 2004 1:52 PM

This message was originally posted by Matthias on November 3, 2004
I might have to rephrase that: THEY think it's a downside. "But, Matthias, set the timestamp to the release date of our current WTS build." "But why? It doesn't matter! It's a bad idea even!" "It's neat!" *sob*

Guest wrote Another argument in favor of mandatory profiles!

on Sun, Dec 12 2004 1:57 PM

This message was originally posted by Jacques Bensimon on November 30, 2004
Hi, Brian. Thanks for the tip. The issue it addresses is one that has generally not affected the systems my company (IPM) sets up because our "best practice" approach is to use shared mandatory profiles (with "hybrid" features such as folder redirection and Registry "Grab & Restore" to maintain user settings). In such environments, we can "bullet-proof" (or rather "shadow-proof") the mandatory profile in one of two ways (or both ways, if you subscribe to the belt and suspenders philosophy): (1) Set the LastUserIniSyncTime in the mandatory profile to 10 years into the future, and/or (2) when necessary (such as after installing a new app or creating a new server), "refresh" the mandatory profile by giving its Registry keys brand new timestamps . I'm curious about one thing: prior to these new MS uilities becoming available, why wouldn't the simplest solution (in roaming profile environments) have been to set the LatestRegistryKey value (under HKLM\...\IniFile Times) to a date far into the past following any new installation or server build? This could be done in a machine Startup script to keep things simple. Anyway, thanks again.

Guest wrote RDT/SDT are not redistributable

on Sun, Dec 12 2004 1:57 PM

This message was originally posted by Donald Fens on December 2, 2004
These tools were available from Microsoft Premier Support for some time but are not to be distributed as far as I know (NDA). One problem I see with these tools is that SDT resets the whole shadow area not just single keys. See RegTimeStamp (that is free by the way and can do more) for more information: "http://www.d-fens.net/?go=link&id=RegTimeStamp". Don

Guest wrote Why not just set the LatestRegistryKey value?

on Sun, Dec 12 2004 1:57 PM

This message was originally posted by Brian Madden on December 4, 2004
To me, this is dangerous. The problem is that the individual software shadow keys would still each have their own timestamps from your new install. So while it's true that setting the value to the LatestRegistryKey would cause the server to skip the sync process, all it would take would be one single "slip up" that reset that key and then you'd have chaos.

Guest wrote A possible 'fix' from MS?

on Sun, Dec 12 2004 1:57 PM

This message was originally posted by Chalky on December 7, 2004
*** Resolution *** Nov 24 2001 10:30AM v_micle

RESOLUTION
==========
A solution of using the WTS flags into the following registry location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Compatibility\RegistryEntries

Add a DWORD value:
Microsoft\Office\9.0 or Microsoft\Office\10.0 (Depending on what version of Office
is being ran)

Value: 108

will prevent the comparison of the time stamps for these keys found in this patch
with this DWORD value.

Guest wrote A possible 'fix' from MS? Part 2.

on Sun, Dec 12 2004 1:57 PM

This message was originally posted by Chalky on December 7, 2004
In the last sentence, I believe they mean '...for these keys found in this PATH...'

Martin no wrote Question sdt.exe

on Fri, Mar 11 2005 5:34 AM

This tool was just what I needed, but when I try to set the date to march 11 2005 (command line: sdt.exe 11 3 2005) I get a 'invalid arguments' error.
Whats this?!

sdt.exe 11 4 2003 works, it looks like this tool has a date limit, what use is it then?

Guest wrote gobsmacked!!!!

on Sat, Mar 26 2005 7:12 PM

I have been working on MS Office settings being reset on new MFXP servers for over a week now. Searched google, MS KB etc etc.......finally on your website I have found an article and utils which address my problem to the letter. What I don't understand is why these tools are not standard. Thank you Brian, your website is as much a good read as your book.

Guest wrote It seems that there is registry hack that will cure the issue.

on Wed, Jun 8 2005 3:31 PM

In MS KB I have found a article 186499. At the end it has following

The following compatibility bits control registry propagation. They are located in the following registry subkey (where PathName is the registry path under the key HKEY_CURRENT_USER\Software):
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\RegistryEntries\PathName
Compatibility Bits
• Windows 32-bit application: 0x00000008
• Disable registry mapping for application: 0x00000100
If the "Disable registry mapping for application" bit is set, it adds new entries from the system master registry image when the application is started, but it does not delete any existing data in the user's registry. If this bit is not set, it deletes and overwrites the user's registry data if it is older than the system master registry data.


So no need to delete and manually add anything this registry hack should achive desired result. I do not understand why it is not default behaviour.

Adam Lowery wrote RE: That's not a downside

on Thu, Nov 10 2005 5:23 AM

I have found that my time stamps on the shadow registry keeps on updating with the current date, this is after i have run the SDT utility, is this normal? all the documentation seems to point in the direction of you just having to set them once. I have created a shedule on a test server to run it every 1/2 hour, since then i dont have any problems with personal settings been saved....this seems a bit drastic though?

Adam Lowery wrote RE: Question sdt.exe

on Thu, Nov 10 2005 5:26 AM

Yeah, it is slightly irritating but it will work as long as its set back far enough for it to be earlier and any of your user profiles time stamps, i set mine all to 2002.

Guest wrote Is this a fix? Can someone confirm this

on Mon, Nov 19 2007 1:55 PM

Running into trouble with outlook profiles after I forgot to set back the system time on one single server. Is this sugestion a suitable way to prevent the shadow key to be applied again? And what happens to new created users? Will the key be applied to them

Thanks

Thorsten Kunzi wrote Re: Is this a fix? Can someone confirm this

on Wed, Feb 27 2008 2:41 AM

Yes they will.

A new user will get the "Default User" Profile which does not have any Office or AppXYZ HKCU keys. So he will get the ones from the shadow key.

Tord Bergset wrote re: Finally! Shadow Key Timestamping Utilities from Microsoft

on Wed, Jun 2 2010 5:40 AM

Hmmm...according to support.microsoft.com it might not be a problem on Win 2003. Can anyone confirm that SDT.EXE is really needed on Win 2003?

From the article:

Changes in Microsoft Windows Server 2003

In Microsoft Windows Server 2003, only new registry values are propagated to the users when they log on. As in earlier versions of Windows, the values are propagated if the shadow key time stamp is newer than the time that is specified by the LastIniSync registry entry. However, because of a bug in the way this update is handled, some user values are overwritten by values in the shadow area. This is most likely to occur when the shadow key has no subkey, or when the shadow key has a subkey that has a short name.

Be aware that in Windows Server 2003, existing data is not overwritten, and registry entries are no longer removed. This behavior differs from the behavior of Windows 2000. In Windows 2000, newer registry values in the shadow area could overwrite the users' copies of registry entries.

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.