Revenera Documentation site will be unavailable on July 2nd due to scheduled maintenance. For more information see the status dashboard.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
frobledo
Level 4

Chained MSIs don't work when logged in through Remote Desktop

I recently started a thread about a problem when using chained MSIs function (see http://community.installshield.com/showthread.php?t=184624).

I think that the problem occurs when connecting to a remote PC using Remote Desktop. It only happens when connecting to a XP or Server 2003 box; the problem doesn't seem to happen when connecting to Vista/2008.

When logged in physically to the PC, the chainer executable gets called as a child of the msiexec service process.

When the user logs in through Remote Desktop, a separate session is created for the remote user, while the Windows Installer service (msiexec) is running in another session. In this case, the chainer executable gets invoked under the remote user's session, thus not in the same process tree as msiexec. Documentation of the MsiJoinTransaction API says that "The installer verifies that the process requesting ownership [i.e. the chainer executable] and the process that currently owns the transaction share a parent process in the same process tree.", so my guess is that, since msiexec is running under one process tree and the chainer runs in another, then the MsiJoinTransaction -and the whole installation for that matter- fails.

What I noticed on Vista is that the process tree is organized in a different way than in XP, and the msiexec service doesn't run under the console session process tree, but in a separate process tree so it doesn't matter if you are connecting through RD.

Neither the MSDN nor InstallShield's documentation seem to be aware of the Remote Desktop situation. Is there a way to make it work?
Labels (1)
0 Kudos
9 Replies
Mike_Marino
Level 6 Flexeran
Level 6 Flexeran

I have an email in to Microsoft about this. I will post the information that I get.
0 Kudos
Nio_the_Champ_2
Level 6

Hi Everybody,

Has anyone got some more information on the issue. I have been facing exactly the same issue.
0 Kudos
deecole
Level 4

You must use mstsc /console on Windows XP SP2 or Windows 2003, or use mstsc /admin on Windows XP SP3 or Windows 2008 or later to start Remote Desktop Connection when using chained .msi packages.

The easiest way to do this is simply edit the shortcut to add the appropriate option. We added code to our install and uninstall to detect this and issue a warning message, but you'll certainly want to make this clear in your readme or other install info.

Regards,

David
0 Kudos
Nio_the_Champ_2
Level 6

Thanks David, i have been using the same as suggested. However it would be great if you could tell me how are you detecting the /console mode. Is there any msi property or you are using something else.

Thanks in advance
Nio
0 Kudos
deecole
Level 4

Nio,

It's just a matter of checking to see if the sessionId is greater than zero. Calls to GetCurrentProcessId() and ProcessIdToSessionId() will get you the sessionID. (Done within a custom action, of course.)

Cheers,

David
0 Kudos
P_Duncan
Level 4

David,

Did you do this in VBScript? Do you still have the script lying around?

Thanks,
Paul
0 Kudos
P_Duncan
Level 4

Never mind -

I'm realizing that you can't get session 0 on Windows 2008 Server with RDP because of the new security model.

I'm throwing out Chained MSI and finding another solution.

Paul
0 Kudos
Nio_the_Champ_2
Level 6

This issue is with Win2k3 systems only. For win2k8 you need not figure this out. I have used msi chaining recently. The feature is great however a lot has to be done by MS to make it really usable. If you have reboots to handle, different checks for parent and child install and if you want to make the msi's loosely coupled, you would have to spend lots of time in writing customcode and testing.
0 Kudos
P_Duncan
Level 4

Thanks for the reply on this Nio.

I hadn't actually tried it yet on Windows 2008 Server, just assumed it would work (or not work) the same. Silly me!
0 Kudos