The what is now online? The Epoch Information Center. Okay, so what is an epoch
and why should I care in a Terminal Server environment?
What is an epoch?
Epoch has many
definitions. The definition we're interested in is the UNIX definition.
The UNIX definition specifies that the epoch is January 1, 1970 at midnight (UTC)
(a.k.a. 01-01-1970 00:00:00). This Date/Time value can be considered "Time 0". The
epoch is used as a beacon to measure time in many computer programs (such as the
Windows registry). Time can be measured as the number of seconds since the epoch
or before the epoch (returning a positive or negative offset). This also allows
you to compare Date/Time values.
Why should I care about an epoch in a Terminal Server environment?
There is one main reason you should care about the epoch offset in a Terminal Server
environment. That reason is the shadow registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Terminal Server\Install\Software). Brian Madden has written an
excellent article on the shadow registry key and how it's used. I've used his article
and the Epoch Information Center
to manipulate the shadow registry's "LatestRegistryKey"
value in a couple of scenarios.
Usage Scenarios
Scenario 1 (setting the LatestRegistryKey back in time):
The first usage scenario is addressed in
Brian Madden's article. This scenario involves
setting the "LatestRegistryKey"
value back in time.
Quote from
Brian Madden's
article:
. . .
Imagine that you have multiple
Terminal Servers or Citrix servers that are all running the same application, such
as Microsoft Office. If you're like most companies, you probably installed Office
on those servers a several months or even years ago. Since Office was originally
installed via a user session operating in install mode, the server's shadow key
was created and timestamped with the original install time. Any users who did not
have the appropriate Office settings in their own personal HKCU key received them
when they logged on to the server for the first time.
Now, fast forward to today.
What happens if you want to add more capacity to your server farm? Most likely you’d
build a few more servers, install Office on them, and load-balance them with your
existing servers.
Can you see the problem here? The timestamp on the shadow key
area of the new Terminal Servers will be current, and in fact much newer than each
user’s individual HKCU last update timestamp. Therefore, upon logging on to one
of the new servers, userinit.exe will start comparing the key-by-key timestamps
of all the HCKU\Software keys to the server’s shadow area software keys. Since the
server just got a fresh install of Microsoft Office, those timestamps will be much
newer than any of the user’s personalized settings in their own HKCU. The result?
Mass deletion of all the Microsoft Office-specific keys in the user’s HKCU\Software
hive.
From the user's standpoint, it will appear as if all of their Office settings
reverted back to the defaults, all because they were randomly load-balanced to a
new Terminal Server. . .
Brian suggests a couple of solutions to address this exact
problem. Another solution you could use is go to the Epoch Information Center, grab
an epoch offset earlier than the other existing servers in the farm, and plug that
offset in to the "LatestRegistryKey"
value. See below:
Note: be sure to select decimal when
inserting the new value.
Scenario 2 (setting the LatestRegistryKey to the current
time):
Imagine that you wanted to add a registry key to each user's HKEY_CURRENT_USER\Software
registry hive. You could write a logon script to do it, or you could add the registry
keys to the shadow registry, use the Epoch Information Center to get the current
(or future) epoch offset, and plug the epoch offset into the "LatestRegistryKey"
(thus
emulating the server install mode). The advantage of doing it without a login script
is that you don't have to come up with some logic in your script to figure out if
this setting has already been applied, Windows takes care of that part for you.
Anyway, I hope you find the Epoch Information Center useful. The reason I put it
online is because I've needed to get an epoch offset in the past and I thought some
of you might find it useful as well.
http://www.jasonconger.com/epoch/