[THIN] Re: What happens if you leave server in "Install Mode"

  • From: "Rick Mack" <ulrich.mack@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Tue, 19 Jun 2007 05:45:24 +1000

Hi Neil,

Your answer is, as always, perfectly correct.

I thought it would be worth adding that install mode can cause issues if
you're not careful, specifically what can happen when the shadow key gets
modified in a non-controlled fashion.

Back in the early days of Windows Server 2003 there was an interesting bug,
now fixed which left an admin's logon session in /install mode. If ctfmon
was running in an admin's session, then userinit never closed, and while
userinit is still running, an admin is in /install mode.

Try and picture a scenario where you've got 5 or 6 admins who were using
their admin accounts for normal day-to-day functions, running outlook, word,
excel etc. Every change they made to their own applications were written to
the shadow key, and those changes were then propagated to any users logging
on to the servers.

Non-admin users were quietly going crazy because their application settings
kept changing whenever they logged on. Not to mention application errors
because of recent files, temporary file folders changing to c:\documents and
settings\admin_user where they didn't have write access.

The immediate action once we worked out what was going on was to stop people
using admin accounts for normal computer usage, which is a damn good idea in
any event. You may have put a huge amount of effort into locking everything
down on your servers, and an single admin can log on to a server and totally
screw things up for you when they open an outlook attachment with a new
unrecognized worm or trojan.

Anyway, we had to re-establish a consistent environment across the server
farm, so the first thing that had to go was the shadow key on all the
servers. We could have copied the same shadow key values to all servers and
set a consistent time/date stamp on the shadow key values. The issue here is
that while in a single server environment, the shadow key can be really
useful for propagating settings for new applications, which is why the
functionality was there in the first place.

But maintaining shadow key consistency in a large farm can be a never-ending
headache, so using scripts and group policies to apply application settings
is the only viable answer.

The easiest (and most expensive) way to do this is to use products like
Powerfuse, Appsense Environment Manager, Scriptlogic and so on. The next
most common approach is custom scripting along the lines of the early
application compatibility scripts. If you design your login scripting
environment around the concept of application user groups, doing application
specific scripting is actually quite slick and easy.

The alternative is to write your own group policy templates (for
non-Microsoft apps) using tools like regshot, regtoadm etc to figure out
what needs propagating. I like using group policies because you've got an
easily documentable and very structured end result, but it does take a while
to set up.

Luckily there's a really easy way to mimic the shadow key functionality with
group policies. You get hold of the free Desktop Standard Policy extension
tool that lets you configure an application the way you want and import the
application setup values into a tunable group policy. That puts you in

I don't want people to think install mode is bad or unnecessary. The windows
installer uses install mode to make sure that application components go to
the right places. But a legacy application install that copies DLLs etc to
%windir%\system32 or fonts to %windir%\fonts can really screw up your day
when %windir% is an admin's %homedrive%%homepath% instead of $systemroot%.
Non-accessible system fonts, as an example, can cause some interesting
performance issues.

But you DO need to manage the shadow key functionality.



Ulrich Mack
Commander Australia

Braebaum, Neil <Neil.Braebaum@xxxxxxxxxxxxxxxxx> wrote:

Well indeed, but it will only be whatever is done within that session,
as opposed to all the other sessions on the server at the same time.

I'm not suggesting it's a valid idea, what I am suggesting is that doing
so, forgetting to do a change user /execute, then logging off, will have
the same affect, because the mode is only active for the session in


Other related posts: