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.