0

I have authored an MSI that requires an account and password to be supplied to install and start a Windows Service, so I've added a couple of properties to my 'Product' element for that. I have a requirement that these properties should not need to be resupplied to perform an upgrade and since one of those properties is a password I don't want to persist it's value to the registry (or anywhere). I have achieved this with 

<MajorUpgrade ... Schedule="afterInstallExecute" />

Now I'm authoring an exe bootstrapper to bundle this MSI with it's prerequisite, similarly the exe will need to receive values for the properties and pass them to the MSI, so I've added some 'Variable' elements to my bundle and passed them to my 'MsiPackage' element with child 'MsiProperty' elements. And this works great during first install when the values are supplied, but now when I want to upgrade the bundle without supplying values for the properties the bootstrapper passes empty values to the MSI. Something equivalent to...

msiexec /i MyMsi.msi ACCOUNT= PASSWORD=

Which breaks the upgrade. The new version of the Windows Service is attempting to start with an empty value for account and password.

Is there a way to conditionally pass variable values to MSI's as property values?

What happens when both the 'Variable' element attributes 'Hidden' and 'Persisted' are set? Will the password really be hidden?

Is there another pattern I don't know about / haven't thought of?

Something like this doesn't feel like it should require a custom action.

Russell Horwood
  • 1,015
  • 1
  • 11
  • 19

1 Answers1

1

On upgrades you can disable the <InstallServices> standard action.

In one of the products I work with I have the following:

<!-- http://stackoverflow.com/questions/15965539/how-to-only-stop-and-not-uninstall-windows-services-when-major-upgrade-in-wix don't change service config on upgrade -->
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>            
<InstallServices>NOT WIX_UPGRADE_DETECTED OR V6INSTALLED</InstallServices>

Because I didn't want to reset the start types of the services is the user has decided to start them manually instead of automatically (it's an option in our product to set this).

By doing this, it should leave the service already installed as is when upgrading instead of trying to re-add it with empty parmeters for the login user/pass

An alternative is to make a salted hash of the password and store the user and salted&hashed password into the registry. On upgrades you can read these values decode the password and use those values.

Brian Sutherland
  • 4,698
  • 14
  • 16
  • Ok. That works for the situation I've described. But I also have a very similar situation with a WebAppPool as well as a Windows Service. How can I achieve the same thing for that? And why is Wix so damned inconsistent!?! – Russell Horwood Sep 06 '16 at 16:28
  • And the problem with storing a salted & hashed password in the registry is that the account password might be changed by Windows or Active Directory in-between installation and upgrade. – Russell Horwood Sep 07 '16 at 08:15
  • 1
    I finally found that I could use WIX_UPGRADE_DETECTED to solve the AppPool issue. Your answer resolved the issue in the question so get's the points. – Russell Horwood Sep 07 '16 at 10:29