10 replies to this topic

[Glytzhkof]

I install a per-machine setup using the administrator account on a terminal server. Everything works fine. I then log in as a regular user and invoke the application shortcut. There are a couple of components that install HKCU registry data, so the windows installer kicks in when I click the shorcut. However, instead of performing the self-repair I get this dialog, anybody know what I can do to suppress this dialog?

Edited by Glytzhkof, 07 January 2004 - 08:50.

[Glytzhkof]

After reading up on terminal server remote sessions, there doesn't seem to be a way to perform application self-repair on a per-user basis. Does anyone know anything more about this?

[Glytzhkof]

To prevent this problem it seems you shouldn't write to per-user keys at all for a terminal server installation. I didn't want to change my installer completely so I added the condition (Not TerminalServer) to all components that write to HKCU. Luckily none of them are application critical. I also had to do the same to all files installed to userprofile folders.

[Jim Bassett]

What is the method you used to detect that the application was being installed ona terminal services?

[Glytzhkof]

I conditioned the components that aren't terminal server compatible with: Not TerminalServer

[sjimmerson]

Glytzhkof,

You mentioned that you shouldn't create any per-user registry entries for a Terminal Services installation. Since Terminal Services will copy the HKCU registry entries that are created while Terminal Services is install mode to each user when they log in. Why do you still think that MSI is trying to repair those HKCU registry entries that are copied by Terminal Services?

We are currently running into a simialar situation with our application that installs Office COM Add-ins. The VB Add-in wizard creates HKCU entries that are added to DllRegisterServer whether you like it or not. These Add-ins are core to our application so we have to install them.

Here is a copy of the MSI log file after I ran it through WiLogUtl.exe. This log file contains information on the failed repaired.

Can anyone shed any light on it?

(UNKNOWN) ?=== Verbose logging started: 1/14/2004 15:28:31 Build type: SHIP UNICODE 2.00.2600.02 Calling process: C:\Program Files\Common Files\PPC\Addins\OpenTreeSelector.exe ===
(CLIENT) MSI © (14:30): Resetting cached policy values
(POLICY) MSI © (14:30): Machine policy value 'Debug' is 0
(CLIENT) MSI © (14:30): ******* RunEngine:
(UNKNOWN) ******* Product: {3CFC0D2F-B176-4C0F-AE8E-49D4EFA3C69D}
(UNKNOWN) ******* Action:
(UNKNOWN) ******* CommandLine: **********
(CLIENT) MSI © (14:30): Client-side and UI is none or basic: Running entire install on the server.
(CLIENT) MSI © (14:30): Grabbed execution mutex.
(CLIENT) MSI © (14:30): Cloaking enabled.
(CLIENT) MSI © (14:30): Incrementing counter to disable shutdown. Counter after increment: 0
(UNKNOWN) *** Log Line Missing ***
(UNKNOWN) Info 1640.Only administrators have permission to add, remove, or configure server software during a Terminal services remote session. If you want to install or configure software on the server, contact your network administrator.
(UNKNOWN) C:\WINNT\Installer\19849590.msi
(CLIENT) MSI © (14:30): Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1


NOTE: Look at few lines above for clues on error
(ERROR) MSI © (14:30): MainEngineThread is returning 1640
(UNKNOWN) === Verbose logging stopped: 1/14/2004 15:28:32 ===
(UNKNOWN)

[sjimmerson]

Can anyone explain why an MSI installation will try to repair an application on Terminal Services but not on a multi-user PC?

For example, we install our app with an admin account on TS, log out and log in with a user account through a remote session. When we run the application on the user account our MSI install runs and tries to repair the application, but since the user does not have permission to run the installation, it fails.

Now, on a multi-user PC we try the same scenario. We install our application with an admin account. log out and log in with a regular user account. When the regular user account runs the application the MSI installation does not attemp to repair our application.

I expected that MSI would attempt to repair our application in both scenarios but it is not. Does anyone know why? (See previous post for additional info about our app.)

***New Info****
I have now tried installing our app with an admin account I will call Admin and then logged in with a user account I will call User. As I mentioned before when User runs our app our MSI installation is trying to do some kind of repair. I decided to give User admin rights, logged off User and logged-in User. Now when User (with admin rights) runs our application the MSI installation does not attempt to repair our application. Thinking that maybe something happened while User was logged-in with Admin rights i decided to revoke User's admin rights and switch the account back to regular user rights. Now I logged-in User (now with regular) user ran our application the MSI installation tried to repair our app again.

I am trying to make sense of all of this, but it is just getting more confusing. Does anyone have any insight into this? Any suggestions?

[Zweitze]

On Windows NT 4 Terminal Server, you'll need to execute
CHANGE USER /INSTALL
before installing your software - maybe that's the problem? (On Windows 2000 and higher, this is done automatically).

Look in the Eventlog: it tells you which component needed a repair.

[sjimmerson]

We are installing our app on Windows 2000 Server. I looked at the event log last night and we are in the process of investigating the components listed in the log.

Thanks,
Shane

[Glytzhkof]

Hi Snimmerson. This does indeed sound strange. What I have seen is that terminal servers will correctly populate HKCU settings, but it will NOT correctly install any per-user files (files that go into the %USERPROFILE% hierarchy). I would first verify that there are no such files in your installation. I did succeed in installing our app on terminal server without having any self-repair kick in.

Note that there are a number of cases where self-repair may kick in unexpectedly: http://forum.install...?showtopic=3974

Edited by Glytzhkof, 20 January 2004 - 05:46.

[Zardoz]

There are a couple of main reasons your app is auto-repairing, and some ways to avoid it:
1) simply, HKCU keys are installed by Admin, but TS did not capture them correctly (I have seen this occur sometimes with long reg keys in Office install). This can be rectified by manually inserting the shadow keys. In any case, remove the keypath from the HKCU component and ensure the Directory_ is set to a system folder to prevent auto-repair of that component. Use a transform if need be.
2) %USERPROFILE% files are installed by Admin, but there is no way to autorepair the component on TS. Install the files to the User profile via a login script instead.

Ultimately you can't avoid the error message if an auto-repair is attempted by the User. But you can avoid the actual error by avoiding auto-repair. 1) disable keypaths that can cause autorepair (HKCU or Directory_=>%USERPROFILE%) 2) Always install with ALLUSERS=1. 3) Check that all HKCU keys have been captured by TS during the INSTALL phase (CHANGE USER /INSTALL).

I have never had a problem on TS since following these basic rules.