Hello Anthony,
The first problem we had is that any messages displayed by the msi (eg: The message we have set up when a custom launch condition fails) are not visible to the user due to the msi running under the local system account.
As you already know, the LocalSystem account is an account with the highest privileges. It is mostly intended for services that require extra privileges.
From what I know, Microsoft advise against a service or an application that runs under the LocalSystem account to display UI or to interact with the desktop. For more information about this, please have a look on the following article:
Interactive Services
In the above article, it is stated that:
Caution
Services running in an elevated security context, such as the LocalSystem account, should not create a window on the interactive desktop because any other application that is running on the interactive desktop can interact with this window. This exposes the service to any application that a logged-on user executes. Also, services that are running as LocalSystem should not access the interactive desktop by calling the OpenWindowStation or GetThreadDesktop function.
Since the Windows Installer is a Microsoft technology, I believe they made this the default behavior for an MSI, although I can not guarantee this (as I could not find anything related to this).
2. Is it possible to return a custom exit code from an MSI installer when a custom launch condition fails, rather than having the generic 1603 (Fatal error) exit code returned.
Unfortunately, I am afraid that this is not possible.
Users (logged in on a local user account) run our bootstrapper program [...]
Could you please give me some more details about this? Is the bootstrapper program a custom one (created by yourself)?
If so, here's what I am thinking about:
Since the bootstrapper is a custom one, unfortunately, it can not access WIndows Installer Properties. By default, we could simply check the installer properties and based on them, show some message boxes.
With that in mind, we need to find another way of letting the custom bootstrapper and the MSI communicate.
First of all, since a launch condition can not return a custom code, I'm afraid we might need to replace this with a custom action.
Most of the time, launch conditions are based on installer properties.
We can get those instlaler properties in a custom action and control everything from there. Here is an article which explains how that can be done:
How to set an installer property using custom actions
Based on those, we can fail the installation by returning a value of 3 (which means fail). Additionally, based on what failed, we can write different values in the registries (values that can be further read by the bootstrapper).
Let's work with the following example:
You have two custom conditions, both based on two properties: PROPERTY_1 and PROPERTY_2. The custom action could look something as it follows:
Code: Select all
var1 = PROPERTY_1
var2 = PROPERTY_2
if (var1 = "false") {
// fail the installer
exit 3
// write the result to the registry
write_registry_value 1
}
elseif (var2 = "false"){
// fail the installer
exit 3
// write the result to the registry
write_registry_value 2
}
At this point we know that if we find "1" in the registries, the first "launch condition" failed, else if we find "2", the second one failed.
You can then use these registry entries to spawn a message to your users.
Hope this helps.
Best regards,
Catalin
