6 replies to this topic

[nitinp]

Hello guys,
We have an install which has a deferred custom action that launches a dll within a web browser. The dll is in a virtual directory. The problem here is that on certain machines running Windows 2003 and are domain controllers, the msiexec process runs this custom action dll under the local system account and when it does that the install rolls back. It is because local system account doesn't have enough rights to authenticate against IIS and run this ISAPI dll within the web browser. Its happening on some of our customer systems. We reformatted and built up the domain again properly and the msiexec process runs this custom action under the logged in windows user account which is the right way. Now my question is, is it possible to make the msiexec process run this particular deferred custom action under the windows user account always instead of local system account? If this can be done, we can save lot of time instead of reformatting the machine and building up a domain from scratch.

Any help in this matter will be appreciated.

Thanks,
Nitin

[Zweitze]

About these particular systems, do they have Terminal Services installed? Try adding the flag msidbCustomActionTypeTSAware to the custom action type.

See also http://msdn.microsof...ion_options.asp

[Glytzhkof]

I am almost positive that Zweite is right. It seems that terminal server computers always run deferred custom actions in system context.

[nitinp]

This is already being tested at a customer site. So changing the custom action type and giving the new msi is going to be a bit difficult. Are you guys sure that terminal services being installed on that machine can be causing this problem? I can just ask them to uninstall terminal services and then try this again. Its a windows 2003 Domain Controller. If it works then great

Thanks,
Nitin

[Zweitze]

I can think of different scenarios, but I'm sure you would have mentioned a hint pointing in the right direction. For example:

1. The software is not installed using its UI, but using a (system) Software Installation GPO. When rebooting the DC, the software is installed. The complete installation is installed using the SYSTEM account of the DC, because... nobody is logged in yet!

2. The software is installed by a non-admin user, and the 'InstallElevated' policy is set for both the DC and this user. Further, you set the flag msidbCustomActionTypeNoImpersonate in the CA type.

Either way, the Terminal Services explanation seems much more plausible.

[nitinp]

You guys are awesome. Ya, the customer tried installing the software locally on the machine with terminal services installed. Even then it worked fine. But now the problem is that they said they have many customer locations where they need to install this software thru terminal services. Is there a way we can do something to the custom action so that it doesn't run under the localsystem account and runs under the windows user who logged in? I read from your replies that adding the msidbCustomActionTypeTSAware might do it. Do you have any more suggestions that might help?

Thanks a ton !!!

Nitin

Edited by nitinp, 26 July 2005 - 15:49.

[Zweitze]

Sure...

First, the account used for installation can actually be configured. It is the account used by the Windows Installer service, so if you change that account, all should be well. Obviously, the account should have sufficient priviliges.
The easiest solution is the flag, but it was introduced in Windows Installer 3.0. I don't know for sure what happens on earlier versions of Windows Installer (my guess: it is ignored).
The real solution is rewriting the CA so it can work in this situation, eg. have it impersonate a valid user (ask for credentials in UI), before doing the job.