14 replies to this topic

[aarthi_m]

One of my custom actions fail when executed on Longhorn. The custom action invokes a exe which writes to program files. The custom action executes on the server side (installexec sequence) and has a deffered execution. The CA fails when it invokes the exe. The installer gave a UAC prompt when the install began. So, not sure why the exe fails with lack of privileges message.

If i try to invoke the exe independntly (not from the msi), there is a UAC prompt and the write to program files succeeds.

Any suggestions or reasons for this behavior???

[Stefan Krueger]

Did you also set the NoImpersonate bit for the custam action? See also this blog entry:
http://blogs.msdn.co.../23/768248.aspx

[aarthi_m]

Thanks Stefan, noimpersonate bit worked. Just to clarify my understanding on why this bit needs to be set - Even if the CA is set to deffered execution in system context, it will try to run as standard user unless the noimpersonate bit is set.

[Stefan Krueger]

In my understanding "system contect" in the InstallShield IDE is equivalent to setting the noimpersonate bit. Setting this bit is required to make sure your custom action runs with elevated privileges.

[aarthi_m]

In that case, the custom action should work when set for deffered execution in system context even if the noimpersonate flag is not set. But it did not.

[Stefan Krueger]

Yes that was my understanding. Actually I thought that "system context" *IS* the noimpersonate flag. If this is not the case: which effect in the .msi file does the "system contect" option have instead?

[aarthi_m]

You are right Stefan, setting "system context" is equivalent to the noimpersonate flag.

The custom actions which are after installfinalize, cannot be set to deffered in system context execution. So, if they need to run with admin privileges, how can it be done? Is there a way to run in elevated privilege mode?

[Glytzhkof]

There should be no custom actions at all after InstallFinalize at all - inserting immediate mode custom actions here is a common error. If you need the custom action to access files after they are installed, put a deferred execution custom action in the deferred sequence after the InstallFiles standard action. Alternatively you can insert these custom actions in the UI sequence, but this is most definitely not recommended since they won't be run if the install is run silently.

[aarthi_m]

If there should not be any custom actions(CA) in immediate mode after installfinalize, where should CA that install driver be placed? Keeping in mind that these CA will not have a corresponding roll back action and the recommendation that all CA between installinitialize and install finalize have a rollback action, where is it appropriate to place a driver installation custom action?

Such CA will need admin privilges, what should be done to elevate the privileges?

[Glytzhkof]

I would try to insert the action in deferred mode right before InstallFinalize. Remember that immediate mode custom actions always run in user context, deferred actions run in LocalSystem context.

[elliot]

Regarding putting CA after InstallFinalize:
Sometimes you do not have any other choice, rather than to execute CA after the InstallFinilize action.

From my own experience, this is a must if you have an application that has .NET assemblies that are being installed into the GAC, and you need to "use" these assemblies in the last stages of the installation.

If you will look at the "MsiAssembly Table" help in the MSDN, in the "Remarks" section, you will see an example to a CA which should be schedules after the InstallFinalize (according to Microsoft recommendations).

Igal

[Glytzhkof]

Hi Elliot, that's news to me, but I read the SDK and right you are. I have seen problems in the past where immediate mode custom actions after InstallFinalize have not been run properly when the install is run in silent mode. I guess this problem could be resolved in later versions of the msiexec engine?

[Stefan Krueger]

Yes, but custom actions after InstallFinalize should not modify the target system, so they shouldn't need elevated rights I think.

[aarthi_m]

If actions after installfinalize cannot modify the target system, where should driver installations be put? Before installfinalize? These actions don't have a rollback and so it is not advisable to sequence them between installinit and finalize. What is recommened for driver installations?

[Stefan Krueger]

Why don't they have a rollback action?
For driver installations I would highly recommend using Microsoft's DIFx framework which has custom actions for msi setups.