pre-empt immediate SA with admin CA

[Kelter]

I have a CA that needs to run with admin privs, but it needs to run before InstallValidate. The standard practice is to run CAs that require elevated privs as Deferred in System Context, but tha makes it impossible to pre-empt InstallValidate, which runs in the Immediate sequence.

There isn't a problem when doing an uninstall. I notice that the "Uninstall" button on "Programs and Features" has the little shield icon on it, but repair and change do not. I don't understand why this should be the case.

Is there a way to make any action (change, repair included) require admin privs up front?

[Kelter]

Upon further discussion with my colleagues, this seems like an unreasonable limitation of either MSI or IS in general. There must be a way to require administrative priveleges on modify and repair.

Any reaction from macrovision folk on this?

[MichaelU]

Where permissions are available is part of the design of Windows Installer, so there's not much we can do but work with it (trying to work against it has this odd pattern of causing surprise agony down the road when someone tries things differently). What do you need to tweak before InstallValidate? There might be a way to either do it without privileges, or to do something differently later when you do have privileges.

[Kelter]

Thanks Michael! I'm very interested in your judgement on this.

During InstallValidate, on uninstall or modify, the install tries to stop a service that we install if it is running. It does a pretty choppy job of doing it, so i have CA to handle it, but that CA calls some functions from one of our dlls. These functions should only be called from a process that already has elevated privs.

Obviously you can't pre-empt an Immediate-Execution CA wit ha Deferred-Execution action.

Here's what gets me about this MSI behavior: Uninstall will run everything (including immediate CAs) elevated. You can do an Uninstall from the "Change" button typically. You can uninstall various features with the Modify option. If a feature might require elevated privs ot manipulate, why not always require elevated privs, or at least make that an option?

Thanks again!

[MichaelU]

I think if we were to ask Microsoft, they would consider it a bug that non deferred-in-system-context actions are getting run with elevated privileges in the uninstall scenario. Why it happens is not surprising when you know the architecture involved (uninstalls run without UI; MSI without UI cannot prompt for elevation, thus running uninstall will launch msiexec already elevated), but it is still not the ideal model. Primarily because it leads to inconsistencies like this (change has a UI so it doesn't need to be pre-elevated, thus immediate CAs run in the limited user context).

So you've said what you're trying to do (stop a service), but not so much of why - is it because the "choppy" way InstallValidate does it causes problems, or is it that the service doesn't stop so uninstall cannot remove it without a reboot? If the latter, can you insert an early deferred-in-system-context action which stops the service when REMOVE="ALL" (or similar) to address this?

[Kelter]

The prompt that comes up by default (automatically close and attempt to restart, or do not close) is somewhat misleading, and confusing since we can't specify what information is presented to the user when asking the question. Also, when dealing with the dialog mentioned above, occasionally it has caused a hang. We obviously want to be able to handle errors and such gracefully. Also a direct customer may have used our SDK to write new services for thier customers, and our runtime needs to handle the case of terminating services that are unknown to the installer...yadda yadda yadda.

An early Deferred-In-Sys-Context would still execute after InstallValidate, since InstallValidate runs in Immediate sequence.

I appreciate your insite. I see what you mean by MS considering the existing automatic elevation as a derived requirement given the UI limitation of the quiet uninstall.

[Kelter]

Okay, i just created a wrapper executable which requires elevated priveleges. I can double click on it to launch it and it produces the UAC prompt. I've included a LaunchApplication call to launch this app, yet it fails when running in modify mode (ie, user mode.)

Does this mean I can't even launch an app that elevates privileges itself from the script? I even tried moving it into the UI sequence so that it woudln't have the UI restriction. Is there totally no way whatsoever to do this?

MSI

One wouldn't expect installation technology (technology that is used to modify the user's system) to be sooooooooooo infernally prohibitive when it comes to.......MODIFYING THE USERS SYSTEM!!!!!!!

I'm not mad...it's just 10:00PM and i've been at this for 2 weeks because of the ALLUSERS bug and now this...

And i can't modify whether or not Change and Repair appear in ARP/PAF at installtime, so it's either i don't allow it at all(kill the feature alltogether) or leave the buttons enabled and just accept that they will be broken on Vista machines. Neither option is any good as far as i'm concerned. :mad: Very very dissatisfied right now. Anybody got a solution?

[joshstechnij]

Are you passing the LAAW_OPTION_USE_SHELLEXECUTE flag to LaunchApplication? If so, have you set LAAW_SHELLEXECUTEVERB to "runas" (the default is "open")?

[Kelter]

I owe ya a drink! 🙂
It works!
...Now why didn't i think of that?