How Applications use the Registry in Terminal Server Environments (Part 2 of 3) - Brian Madden - BrianMadden.com
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.
Brian Madden's Blog

Past Articles

How Applications use the Registry in Terminal Server Environments (Part 2 of 3)

Written on Aug 03 2004 69,783 views, 51 comments


by Brian Madden

In Part One of this series, we looked at the basics of how Terminal Server uses the registry. In this article, we’ll examine at how applications use the registry in Terminal Server environments, mostly focusing on application installation issues.

Installing an application on a Windows server causes it to write data and save settings in both the HKLM and HKCU registry hives. As we learned in the previous article, the HKLM hive stores the system-wide application settings such as file installation paths and installed options, and the HKCU hive stores the user-specific settings such as custom dictionaries, menu settings, and default fonts and colors.

As you’ve probably guessed, Terminal Servers behave a bit differently than regular Windows computers. To understand this, let’s look at an example. Imagine that you’re installing Microsoft Office onto a Windows XP workstation. Besides copying the files, the setup.exe program will write all the necessary Office settings to the registry. In this case, it will write the system-wide stuff to HKLM and it will write the default user settings to HKCU. On a single-user system such as Windows XP Professional, this works fine.

However, on multi-user Terminal Servers, this could cause a few problems. First is the fact that all the application’s new registry settings would be written to the specific HKCU of the actual user account that was used to install the application. This could cause a problem when a regular user logged onto the server and ran the application since their personal HKCU wouldn’t contain any of the application’s settings. (Whether this is a problem or not really depends on the application itself.)

So how does Terminal Server deal with these two problems?

Every user session on a Terminal Server operates in one of two modes: “execute” mode or “install” mode. Execute mode describes regular user session behavior when users are “executing” applications. This is the standard mode of operation and how your user sessions will operate 99.9% of the time.

However, when you install an application onto a Terminal Server, the session you’re installing it from switches to “install” mode. (In the old days, you had to manually put a session into install mode via the command-line switch “change user /install.” You can still do this in Windows 2003, although the server now is smart enough to detect when you’re installing applications and it automatically puts the session into install mode as needed.

So what’s the point of install mode?

Let’s think back to the application installation problem we outlined earlier. When an application is installed on a server, the application usually writes a bunch of settings to the active user’s HKCU hive. In a Terminal Server environment, there needs to be some way to ensure that any application settings written to HKCU when the application is installed get copied to every single user’s HKCU hive when they log in. Otherwise, applications might behave strangely for the users since they don’t have any of the proper registry keys configured.

Therefore, when a user session goes into install mode, the server monitors all the activity of that user’s HKCU hive. Then, any changes to the user’s HKCU\Software key (i.e. from the application installation) are also written to a special Terminal Server HKLM key at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. This key is informally known as the “shadow” key. As such, this shadow key contains all the most recent application installation information that’s needed in each user’s personal HKCU\Software key.

So far, so good, right? The only thing missing is how a Terminal Server knows whether a user who’s logging on needs to receive some settings from the Terminal Server’s shadow area. It does this by comparing timestamps between the two.

When a session is in install mode, each time a “real” HKCU\Software value is echoed to the shadow key location the server updates a timestamp called “LatestRegistryKey” stored in the HKLM\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times. This value of this registry entry is the number of seconds since January 1, 1970.

(As a side note, you’ll also notice a listing of INI files with timestamps in this same registry location since install mode also affects them. However, in today’s world, INI files aren’t really used and we only really care about the registry operations.)

All these timestamp values live in that “IniFile Times” registry key mentioned earlier. One of the lesser-known facts about the Windows registry is that every registry key has its own timestamp that shows the last time it was updated, similar to standard file timestamps. (These timestamps apply to each key, not to each value.)

Anyway, whenever a user logs on to any Windows computer, a process called userinit.exe is used to run programs before the shell loads. In Terminal Server environments, this executable compares the hidden timestamp of the server’s IniFile Times key to a timestamp in the user’s HCKU hive that holds the last synchronization time. (This “per user” timestamp is stored in the user’s HKCU\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\LastUserIniSyncTime.)

In doing so, the system can figure out whether the registry settings in the user’s HKCU are newer or whether the “shadow” settings in the server’s HKLM are newer. If the hidden timestamp of the IniFile Times key in the shadow area is more recent, the system knows that new software must have been installed on the server. Therefore, userinit.exe enumerates all the keys in the Terminal Server compatibility shadow are and compares each one’s hidden timestamp to the corresponding key in the user’s personal HKCU\Software key. If the shadow key is newer, the user’s corresponding key is deleted, and they receive the new key from the shadow area once their sessions starts. (This is known as “Terminal Server registry mapping.”

On the surface, it seems like this architecture is rather ingenious and that you don’t have to worry about anything. However, there is one major problem that can manifest itself in the real world.

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.

Bummer dude!

So what can we do to change this behavior? Unfortunately, there’s no way to disable the shadow key functionality, and Windows 2003 does a pretty good job of ensuring that applications are installed with the user session configured for install mode. Therefore, if we can’t disable it, we’ll have to outsmart it.

This essentially means that we’ll have to ensure that the timestamps on the servers’ shadow area are older than the timestamps of the user’s HKCU hive. There are two ways to do this:

  • Before installing an application, set the server’s system clock back to before the time you installed the application on one of the original servers.
  • Deploy the new server from an image of the old server. (Ghost, sysprep, breaking a hardware mirror, etc.) If you do this, remember that you must use some kind of imaging technology. Unattended installs will not work in this case since they’ll write the current dates to the shadow area.

Alternately, if you don’t want to do either of these, you can simply delete the keys out of the new server’s shadow area. That will ensure that the users’ versions of those keys are not deleted when they log on to a new server. However, if you do this, you’ll have to use a logon script or some other method to ensure that new users get the appropriate keys populated into their own HKCU hive.

That pretty much sums up what you need to know about how the registry is used when you install applications. In the final installment of this three-part series on the registry, I’ll look at all the specific registry keys that are important in Terminal Server environments.

 
 




Our Books


Comments

Guest wrote Microsoft patches
on Sun, Dec 12 2004 1:30 PM Link To This Comment
This message was originally posted by Bluff Rooster on August 3, 2004
Interesting stuff. I'm hoping to find out how important it is to install MS patches in install mode and whether it's best to do the patching when users are off the system. It's a bit of a pain to download each required patch then install each using Add or Remove Programs (for each Win2003 server) first ensuring users are logged off - is this necessary or can we automate the roll out of patches using 3rd party tools while users are active?

How do admins of large farms roll out MS patches (eg MS04-025) - I've been taught that Citrix Installation Manager is unreliable (at least in XP FR2)?

Thanks in advance!
Guest wrote Ooops, forgot to mention...
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Bluff Rooster on August 3, 2004
Page 339 of the official Citrix Windows Server 2003 handbook advises that, when building the system, you should install "updates" (I assume those found on the Windows Update site) using install mode. I guess the same would need to be done after the system has been up some time and needs repatching but doubt this is common practice - maybe 'cos its unnecessary?
Guest wrote Installing Patches
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Brian Madden on August 3, 2004
If a system goes into install mode to install patches, that will only update the timestamp on the IniFile Time reg key if the patch writes to HKCU\Software, which is unlikely. Besides, even if it did, a newer IniFile Times hidden timestamp would only trigger the sync process. In this case the users would be okay because the system will check each key's hidden timestamp one-by-one, and presumably Office keys would not be updated, and therefore not deleted.
Guest wrote Could not have said it better my self...
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Freddie larsson on August 4, 2004
Very good article, very easy to understand.
But even if you feel like there seldom is problems whit the .ini-files mapping now a days I rely think it would bee very interesting if you explained that phenomenon anyway. I think many people would appreciate that.

See ya

/Freddie
Guest wrote Excellent!!!!
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by French Reader on August 4, 2004
Thanks a lot for this article. I work on TSE and Citrix servers for 4 years, and even if a understand that some "hidden" process were doing some configuration on users's hive, i have never really know exactly how. Now, it's perfect.
Thanks a lot again. Go further, it's always good to learn or re-learn (ex: part 1 of this article). :-)
Guest wrote Well Said...
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by MTB on August 4, 2004
Brian - excellent article. I know a lot about the Windows registry, and how it relates to Terminal Services, but this is new to me... Great stuff! Keep it coming...
Guest wrote Can't wait for part 3
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by an anonymous visitor on August 4, 2004
Very interesting article eventhough I've already known what you have said in the article. Setting the server system clock back was exactly what I did to ensure user's setting didn't get revert back. I can't wait for the more detailed explanation in part 3. I bought your book and think your Citrix book is the best out there.
Guest wrote question...
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by an anonymous visitor on August 4, 2004
I'm assuming the example of "out-smarting shadow key functionality" is only applicable if you are using roaming profiles, correct?
Guest wrote Old mechanism?
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Marc Smit on August 4, 2004
Brian, nice to discus this part of SBC technology. This part of terminal server is always difficult to manage, because this whole mechanism is actually meant for 1 terminal server design, but that's another story. I do not totally agree with your story. If I install an application on a windows XP professional (single-user system) the default settings are written to HKLM & HKCU. That works fine you say. But what happens if another person logs on to this system. There is no “Shadow key” present, so where does this person gets the HKCU settings from? I think this mechanism could also do his job on single-user systems. Besides if you look in the registry of a Windows XP Professional system you can see that there is already a HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software key . I don’t know what the purpose of this key is.

Actually we don’t have any problem with this on any given workstation, because we mostly install the application via a msi package. The msi technology has attempted to overcome this shortcoming and uses self healing to configure current user settings for all users of a given workstation. After the application is installed on the system a part of the msi (no binary) is copied to the systemroot\install directory (it’s a system dir, so to see this dir you have to edit the folder view options.)

If we only use msi’s for terminal server, why do we still use this old mechanism?
Guest wrote Alternative timestamp solution
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Kristoffer Johansson on August 6, 2004
There is another solution for the timestamp/multiple server and installation time problem: by using native NT API calls, you can (re)set the timestamp on individual keys. Donald Fens provides a helper dll for this purpose, se http://www.d-fens.net/?idMenu=3&idSub=1 for more information.
Guest wrote Group Policies
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Drew Dubber on August 11, 2004
I would have thought you could do a simple policy addition to set the timestamp key back to what you want? Put all those Office SBC servers into one OU. As we are using a Hybrid profile solution, this would work across the estate. Thanks for the info!
Guest wrote triCerat Simplify Profiles
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by John Byrne on August 12, 2004
We've done a ton of work to make this stuff easy and far more powerful. Shameless plug I know, but we really have simplified this!
Guest wrote Install mode per session???
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Rich Brumpton on August 13, 2004
First off GREAT ARTICLE!!!!! this is one area where ALOT of citrix/TS admins are weak. It's nice to see someone covering such an important fundamental concept.

I do have a question on install mode however. You state that the SESSION is in install mode. It was my impression that the entire server entered install mode. I remember having instances where someone would be logged on while installing software and settings that they changed in their session would affect future users. I have not seen this since TSE, but then again I NEVER install software with users logged on anymore :)

Could we get a clarification on this?
Guest wrote Yes, Install mode is per-session, not per-server
on Sun, Dec 12 2004 1:31 PM Link To This Comment
This message was originally posted by Brian Madden on August 13, 2004
You can confirm this by running "change user /query" from each user session.
Guest wrote great article. where is "1 of 3?"
on Sun, Dec 12 2004 1:49 PM Link To This Comment
This message was originally posted by stuart eggerton on September 9, 2004
Excellent article! Where is (Part 1 of 3) of
"How Applications use the Registry in Terminal Server Environments"
I couldn't find it in the list of previous articles
Guest wrote PerUser specific files.
on Sun, Dec 12 2004 1:49 PM Link To This Comment
This message was originally posted by Naren on September 13, 2004
Excellent article in understanding the registry in TS environment. This article deals with the information of updating the HKCU registry hives for the users who logins to server for using the application through terminal services. How the same works incase of files going to users profiles folders (ex.App data folder, My documents??)
Guest wrote Alternative timestamp solution
on Sun, Dec 12 2004 1:50 PM Link To This Comment
This message was originally posted by an anonymous visitor on September 30, 2004
Hi, there is another method to set a Timestamp
Stop Timeservice W32Time
Set Time
Set Date
Export Registry "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server" to a File e.g. shadow.reg
Delete Registry "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server"
Import shadow.reg (regedit.exe /i /s shadow.reg)

then Set all IniFileTimes to the Same Time

E.G. Use This Skript

XXXX BEGIN OF SCRIPT XXXX
Option Explicit
On Error Resume next
Dim objWSHShell, objRegistry
Dim strKey, strTemp, arySubKey
Const HKEY_LOCAL_MACHINE = &H80000002

Set objWSHShell = WScript.CreateObject("WScript.Shell")
Set objRegistry = GetObject("winmgmts:root/default:StdRegProv")
strKey = "Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times"
strTemp = objRegistry.EnumValues(HKEY_LOCAL_MACHINE, strKey, arySubKey)
For Each strKey In arySubKey
WScript.Echo strKey
objWSHShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times\"+ strKey,1000000000, "REG_DWORD"
Next

XXXX END OF SCRIPT XXXX

Restart Time Service W32Time or doe reboot.

....

hope that helps ;-)

bye bye
Guest wrote Strange behaviour that...
on Sun, Dec 12 2004 1:50 PM Link To This Comment
This message was originally posted by TSUser on September 30, 2004
... some people uses these comments to post questions (see first comment) while there are tons of good forums available...
My comment of the article is: if you do not use roaming profile you will not have the issue. This seems obvious but important to say though. Thanks for this article!!! Where is part 1 please?
Guest wrote What about TermSvrCopyKeyOnce
on Sun, Dec 12 2004 1:52 PM Link To This Comment
This message was originally posted by Phil Bowman on October 8, 2004
The registry key value TermSvrCopyKeyOnce would seem to be a key issue in rerspect of shadow key replication, having been conceived to deal with aspects of the problem, but surprisingly is not mentioned in your article. This has been mentioned in various places in Microsoft literature, but I have never seen an explicit detailed explanation of how it works.

It was dealt with in a Microsoft document produced by Frank Kim, but when I sent an email asking for more information, he replied that this issue seems to be undocumented!
Guest wrote Limit sessions to the applications installed
on Sun, Dec 12 2004 1:52 PM Link To This Comment
This message was originally posted by an anonymous visitor on October 11, 2004
Lets say I got eight licenses for app. vision, how can I limit only eight sessions to that application.

Thansk
Guest wrote What ever happened to part 3 of 3 ????
on Sun, Dec 12 2004 1:52 PM Link To This Comment
This message was originally posted by an anonymous visitor on October 25, 2004
Guest wrote Part 1
on Sun, Dec 12 2004 1:57 PM Link To This Comment
This message was originally posted by an anonymous visitor on November 26, 2004
http://www.brianmadden.com/content/content.asp?id=219
Allan Harder wrote Excellent topic
on Wed, Dec 15 2004 10:54 AM Link To This Comment
I did a Google on Citrix registry hive because I new about the "shadow" a long time ago but couldn't remember any details on it - including its path.
This is the article that came up in the search. Thanks for covering it.
Bret Collins wrote RE: Install mode per session???
on Tue, Dec 28 2004 11:05 AM Link To This Comment
If install mode is per session is there any reason (other than a required reboot) to put off installing software while users are logged on to a server?
Jeff Pitsch wrote RE: Install mode per session???
on Tue, Dec 28 2004 12:34 PM Link To This Comment
Install/Execute modes are for the entire server. It is HIGHLY recommended to not install software while other users are logged in. You will only create headaches for youself.

Jeff
Brian Madden wrote RE: Install mode per session???
on Tue, Dec 28 2004 1:31 PM Link To This Comment
While I agree with Jeff that it's bad to install software when other users are logged on, I completely disagree about install mode being per server.

Install mode / user mode is per server, not per session.

You can test this yourself. Log on to a server and type "change user /install" to change the session to install mode. You can type in "change user /query" to verify that the session is in install mode.

Then, log in to another session and type "change user /query" and you'll see that that session is in execute mode, even while the other is in install mode.

Brian
Jeff Pitsch wrote RE: Install mode per session???
on Wed, Dec 29 2004 10:06 AM Link To This Comment
Heh, I tracked this down. It's about Windows 2003 but I think it proves the point:

http://support.microsoft.com/default.aspx?scid=kb;en-us;186515

In particular, "Do not run the system in install mode (except to install applications). This disables user registry and .INI file mappings, which means each user running an application would share the same .INI file or registry entry, instead of having them on a per-user basis. The Terminal Server computer should always be run in execute mode. "

Jeff
Guest wrote RE: Install mode per session???
on Thu, Dec 30 2004 3:34 PM Link To This Comment
Thanks for url - I am looking for documentation so I can present it to my boss - he is always having me install updates or new software in the middle of the day. He says I'm being paranoid and/or difficult if I tell him we should wait. What is the rule regarding things like windowsupdate or system patches? If I install a new MDAC version should that be run in install mode? It's not an application that the users will directly access? Thanks for the help.
Brian Madden wrote RE: Install mode per session???
on Thu, Dec 30 2004 4:21 PM Link To This Comment
I would never ever install updates while live users were on the system, and I think this document should explain why.

The other problem that you have is that things like MSI's will always be installed via install mode automatically, so you can't trick the system in to not doing it.

Brian
Lee Buskey wrote Re: RE: Install mode per session???
on Thu, Feb 3 2005 11:57 PM Link To This Comment
Brian,

Regarding you statement on launching .mis's above, my experience has been contrary to those facts. While trying to get Hummingbird Exceed to work, we found out that that particular application BREAKS if you install it in install mode. It has to be installed in execute mode. (It has its own mechanism for dealing with HKCU keys) As the install was an .MSI, we found your above statement to be true only if you launch the msi from the Explorer shell. If you launch your msi install from a MSIEXEC call from the command prompt, the server stays in execute mode ( I checked it during the application install, so if this is not the case, than the change user /query command lies) After installing Exceed from the command line in execute mode, the program works like its supposed to.

Lee H Buskey
Guest wrote RE: Install mode per session???
on Fri, Feb 18 2005 7:08 AM Link To This Comment
Could someone point me to the location where this setting is stored. I'm having the problem that my session, even after resetting my profile, starts in install mode.

Jeroen
Shawn Bass wrote RE: Install mode per session???
on Fri, Feb 18 2005 10:03 AM Link To This Comment
ORIGINAL: Guest

Could someone point me to the location where this setting is stored. I'm having the problem that my session, even after resetting my profile, starts in install mode.

Jeroen


The profile has nothing to do with the install/execute mode other than HKCU registry settings are mapped into HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install. Well that and the INI file mapping, etc. In general, executing the Change user /execute should place the server back into Execute mode. If that's not happening on your server, issue a reboot request as the server will always come up in Execute mode.

Shawn
Tom Howarth wrote What ever happened to part 3 of 3
on Fri, Feb 18 2005 10:34 AM Link To This Comment
Brian, what ever happened to part 3 of 3 for this article, I have been waiting with bated breath ;-)
Shawn Bass wrote RE: What ever happened to part 3 of 3
on Fri, Feb 18 2005 10:38 AM Link To This Comment
Brian,

Maybe I'm just missing something, but is there any way to know what article a particular comment is made on? Anyway to force the forum poster to have the hyperlink in the article?

Shawn
Guest wrote RE: Install mode per session???
on Fri, Feb 18 2005 10:57 AM Link To This Comment

ORIGINAL: sbass

ORIGINAL: Guest

Could someone point me to the location where this setting is stored. I'm having the problem that my session, even after resetting my profile, starts in install mode.

Jeroen


The profile has nothing to do with the install/execute mode other than HKCU registry settings are mapped into HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install. Well that and the INI file mapping, etc. In general, executing the Change user /execute should place the server back into Execute mode. If that's not happening on your server, issue a reboot request as the server will always come up in Execute mode.

Shawn



That's just the issue. The server reboots nightly and when I log in (after the reboot) with my (admin) account, my session starts in install mode, which is a bit of a problem for the other users on this server. Is there a poilicy or registry or other setting which can explain this behavior.
Shawn Bass wrote RE: Install mode per session???
on Fri, Feb 18 2005 11:16 AM Link To This Comment
ORIGINAL: Guest

That's just the issue. The server reboots nightly and when I log in (after the reboot) with my (admin) account, my session starts in install mode, which is a bit of a problem for the other users on this server. Is there a poilicy or registry or other setting which can explain this behavior.


The only thing that I'm aware of that can cause that is an application installation that triggers automatic install mode on the server. There's an example of it here (but it only applies to Win2003 per Microsoft): http://support.microsoft.com/default.aspx?scid=kb;en-us;826821

Are you running Win2003?

Shawn
Guest wrote RE: Install mode per session???
on Fri, Feb 18 2005 11:34 AM Link To This Comment
ORIGINAL: sbass
ORIGINAL: Guest
That's just the issue. The server reboots nightly and when I log in (after the reboot) with my (admin) account, my session starts in install mode, which is a bit of a problem for the other users on this server. Is there a poilicy or registry or other setting which can explain this behavior.

The only thing that I'm aware of that can cause that is an application installation that triggers automatic install mode on the server. There's an example of it here (but it only applies to Win2003 per Microsoft): http://support.microsoft.com/default.aspx?scid=kb;en-us;826821

Are you running Win2003?

Shawn

We are running Windows 2003 Standard. Other admins don't seem to have the problem. Thanks for the KB article.
Brian Madden wrote RE: What ever happened to part 3 of 3
on Fri, Feb 18 2005 1:44 PM Link To This Comment
It's on my list of things to do.

I need to write some code that detects whether you're in the article forum (by looking up the forumId associated with the current message) and then if so looks up the messageID in another table to find the article number, and then looks up the article information based on the number.

So it's easy to do, just a bit involved. Let me see if I can get to that this weekend.

Brian
Jim Vierra wrote Re: RE: What ever happened to part 3 of 3
on Thu, Mar 31 2005 6:43 PM Link To This Comment
Yeah - what happened?
It's an anti-climax.

I just ordered you book on TS from Amazon. You are the only source that actually read the info from MS on the differences in WS2003 memory management. Even the MS techs wanted to impose incorrect 2000 tunings on TS2003 causing us to go from bad to worse. I used you approach (before reading your white-paper) and now everything works well.

Thanks post knowledge. I wish I had found you book two months ago.
Guest wrote 3 of 3
on Thu, Apr 21 2005 8:14 AM Link To This Comment
http://www.brianmadden.com/content/content.asp?ID=238
Guest wrote Each user Must Install
on Fri, Mar 3 2006 12:32 PM Link To This Comment
We have 3 servers running Window Terminal Server 2003. I installed MS Office XP (2002) on all 3 at the same time using the same method. On 2 of the servers everything runs great. On one server everytime a new user logs in and tried to run a program it says they must install it. But of course they can't since they are not administrators and the Office disk in not in the drive.
 
I've tried to uninstall it and reinstall it using the change user /Install but it has not helped. Now I'm getting ready to upgrade to Office 2003 and I want to make certain the same thing does not happen. How can I do this?
 
heather.cox@restortelecom.com
 
Scott Vickrey wrote Part 3?
on Wed, Apr 26 2006 11:10 AM Link To This Comment
Brian,
How can we encourage you to post part 3 of this article series? It's mighty good readin'.

Thanks,
-Scott
Guest wrote [Deleted]
on Wed, Nov 15 2006 1:53 AM Link To This Comment
Guest wrote Install Mode vs. Active Setup
on Tue, Jun 5 2007 1:54 PM Link To This Comment

First let me say that was an excellent read.  I found the article in my quest to understand the relationship between Install Mode and Active Setup.  Reading between the lines, I have come to the conclusion that Install Mode makes Active Setup redundant.  Is this a safe assumption?  Can it be possible to see an application, published in Install mode, still create subkeys in the ...\Active Setup\Installed Components area of the Registry?

Pls forgive any naiveté, I am first an formost a server guy and our Citirx guy left a few weeks ago.  It has become my job to determine whether or not Active Setup keys should be purged when apps are installed in "install mode".

Thx DS

Guest wrote Microsoft changed the rules for udating key's
on Tue, Sep 11 2007 1:12 AM Link To This Comment

This artikel made many things clear for me but i had the problem that new userkeys were added, but userkeys would not be updated.  in this artikel from microsoft at the and is explaned that for version 2003 keys are only aded en not longer updated or deleted. http://support.microsoft.com/?kbid=297379

I think it is a rude method for dealing with a bug. And i am not happy because i have 20 users and i have to updated the program for each user by hand.

Good luck

Peter 

 

 

Guest wrote LastUserIniSyncTime
on Sat, Apr 26 2008 3:50 PM Link To This Comment

Hi, hope you can help with this.  I suspect that we may have this exact issue but what I would like to find out is how widespread it is in our environment before I implement a fix.

I have found out what date the shadow keys are set to using the rdt.exe, what I would like to know is there anyway of finding out for each of the users their last synchronization time? Is there something in HKU that I can search for?

Guest wrote Registry mapping on a workstation?
on Thu, Jun 5 2008 2:03 PM Link To This Comment

<em>As you’ve probably guessed, Terminal Servers behave a bit differently than regular Windows computers. To understand this, let’s look at an example. Imagine that you’re installing Microsoft Office onto a Windows XP workstation. Besides copying the files, the setup.exe program will write all the necessary Office settings to the registry. In this case, it will write the system-wide stuff to HKLM and it will write the default user settings to HKCU. On a single-user system such as Windows XP Professional, this works fine.</em>What if another users logs on to the XP workstations explained above? Isn't this user also missing the registry settings in HKCU for the installed application? I don't see the difference between XP and Terminal Server in the case.

Guest wrote Part 3?
on Tue, Sep 16 2008 4:24 AM Link To This Comment

Really nice article.Is part 3 of this article still coming or am I missing something here?

tabularasa138 wrote re: How Applications use the Registry in Terminal Server Environments (Part 2 of 3)
on Fri, Jul 15 2011 9:48 AM Link To This Comment

Are there any changes to this process in Server 2008?  What are the ramifications of installing applications in install mode with a bunch of users logged into the system?  How about installing in a console session VS an ICA/RDP session?  

geetarboy wrote re: How Applications use the Registry in Terminal Server Environments (Part 2 of 3)
on Wed, Apr 4 2012 3:06 PM Link To This Comment

If W2K3 automatically puts the server into install mode when an install is run, why does chgusr /query return EXECUTE mode everytime I try it during an install?  If it is reporting falsly, that might also mean that getting a return of execute in other sessions is not accurate.

(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.

Trackbacks

inconsistant proxy settings | keyongtech wrote inconsistant proxy settings | keyongtech
on Fri, Apr 3 2009 10:07 AM

Pingback from  inconsistant proxy settings | keyongtech