win_pkg: msiexec parameter does not allow MSP patch files to be applied

[morganwillcock]

When creating a package definition, setting "msiexec: True" forces the msiexec option "/i" for installs, or "/x" for uninstalls. This prevents the use of the "/p" which is used to apply a patch to an already installed MSI package. A patch may increase the version number and so is potentially equivalent to a package upgrade.

• "msiexec /i /p" is not a valid combination of switches so you cannot override "/i" by setting "/p" in the install_flag string
• setting "msiexec: False" and using "msiexec.exe" as the installer will result in cache_path not being set so you cannot reference a cached patch file in the install_flags string. It also means the cache_dir parameter cannot be used (since there is no inferred salt:// installer path)
• setting "msiexec: True" and applying a patch with "/update" or "PATCH=" requires a fully qualified path to the patch files, which isn't available as a core grain or environment variable

As a workaround, without resorting to hard-coding paths or running batch files, you can glue together the fully qualified location of the minion cache and reference that to apply a patch:

{% set minion_cache_path = (opts['cachedir'] ~ '\\files\\' ~ saltenv ~ '\\win\\repo-ng\\my_app') | replace('\\','\\\\') %}

my_app:
  '5.5.3':
    full_name: 'My App'
    installer: 'salt://win/repo-ng/my_app/MyApp.msi'
    install_flags: 'ALLUSERS=2 /update {{ minion_cache_path }}\\MyApp553.msp /qn /norestart'
    uninstaller: '{C7AD892D-4D6C-4444-B6D7-30AFA6147466}'
    uninstall_flags: '/qn /norestart'
    msiexec: True
    cache_dir: True

...but this doesn't look too pretty when all that was required was to run msiexec /p MyApp553.msp /qn /norestart. It also results in the whole directory being re-hashed since both the original installer and the patch file must be referenced.

I would like to suggest the addition of an extra package definition parameter, which when set would imply the msiexec option "/p" in-place of option "/i", e.g. "msiexec_patch: True".

Tested on Salt version 2015.8.8.2

[jfindlay]

@morganwillcock, thanks for the report. Ping @TheBigBear, @twangboy.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[damon-atkins]

ping me @damon-atkins

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[sbarnden]

Was encountering this issue but the workaround described of setting a minion_cache_path was not working as it was not picking up the saltenv correctly.

I was running with a saltenv=test and the msi install files were being cached at:
c:\salt\var\cache\salt\minion\files\test\win\repo-ng\
However the minion_cache_path being generated was always pointing to:
c:\salt\var\cache\salt\minion\files\base\win\repo-ng\
Which was empty. Could not figure out how to get this path to be generated correctly but did stumble on a different solution that relies on the fact that the msi is run from the cache directory and msiexec is called using cmd. Created a repo definition of:

MyApp:
  '1.0':
    installer: 'salt://win/repo-ng/MyApp/MyApp.1.0.msi'
    full_name: MyApp
    install_flags: '/qn '
    uninstaller: 'MsiExec.exe'
    uninstall_flags: '/X{B5B5868F-23BA-297A-917D-0DF345TF5764} /qn'
  '1.1':
    installer: 'salt://win/repo-ng/MyApp/MyApp.1.0.msi'
    full_name: MyApp
    install_flags: '/qn /update "%cd%\\MyApp.1.1.msp" '
    uninstaller: '{B5B5868F-23BA-297A-917D-0DF345TF5764}'
    msiexec: True
    cache_dir: True
    uninstall_flags: '/qn'

The %cd% will resolve to the current working directory, which according to the minion log file was:
c:\salt\var\cache\salt\minion\files\test\win\repo-ng\MyApp
The installer now seems to work and apply the MSP file correctly in my case. Of course this only works so long as the MSP and MSI files are in the same directory and cached together.

[KjellComputer]

This approach does sadly not work with Microsoft Monitoring Agent and it's .msp-patches, it is probably something with how the msi is packaged, and will result in a broken install with a error message like '"Error 1923 Service '@C:\Windows\system32\AdtAgent.exe,-500' (AdtAgent) could not be installed. Verify that you have sufficient privileges to install system services."'.

One approach that did work for the installation it self was to create one package installer for the main installation, then another installer for the patch with the example from @sbarnden using the /update-parameter. Doing this will install both the msi and msp successfully for Microsoft Monitoring Agent, but Salt pkg.install will not see that the installation with the .msp-patch was successfully, even tho it was.

pkg.install stage 1 (msi install)

momagent:
  '1.0':
    full_name: 'Microsoft Monitoring Agent'
    msiexec: True
    installer: 'salt://win/repo-ng/salt-winrepo-ng/momagent/MOMAgent.msi'
    install_flags: '/NoRestart Use_Settings_From_AD=0 MANAGEMENT_GROUP="{{ MgmtGroup }}" MANAGEMENT_SERVER_DNS="{{ MgmtServer }}" NOAPM=1 ACTIONS_USE_COMPUTER_ACCOUNT=1 USE_MANUALLY_SPECIFIED_SETTINGS=1 SET_ACTIONS_ACCOUNT=1 AcceptEndUserLicenseAgreement=1 /qn'
    uninstaller: '{CEB9E45B-2152-4C10-A022-0825B53B632F}'
    uninstall_flags: '/qn /norestart'

pkg.install stage 2 (msp install)

momagentpatch:
  '1.0':
    full_name: 'Microsoft Monitoring Agent Patch'
    msiexec: True
    installer: 'salt://win/repo-ng/salt-winrepo-ng/momagentpatch/MOMAgent.msi'
    install_flags: '/update "%cd%\\KB5025123-AMD64-Agent.msp" NOAPM=1 AcceptEndUserLicenseAgreement=1 /qn'
    uninstaller: '{CEB9E45B-2152-4C10-A022-0825B53B632F}'
    uninstall_flags: '/qn /norestart'
    cache_file: 'salt://win/repo-ng/salt-winrepo-ng/momagentpatch/KB5025123-AMD64-Agent.msp'

Event Log in Windows confirms installation and patching was successfull, but pkg.install for msiexec interpret the output from the msiexec patching as failed, so it will need to be changed to correctly interpret the output as successful.

ID:
momagent
Result:
 Succeeded
Name:
installed
State:
 momagent
Function:
--
Duration:
1m 25s
Ret code:
2
Comment:
The following packages were installed/updated: momagent
Changes:
{
  "momagent": {
    "new": "10.19.10014.0",
    "old": ""
  }
}
ID:
momagentpatch
Result:
 Failed
Name:
installed
State:
 momagentpatch
Function:
--
Duration:
15s
Ret code:
2
Comment:
The following packages failed to install/update: momagentpatch
Changes:
{
  "momagentpatch": {
    "install status": "success"
  }
}