MSI/MSP Handling within WSUS

Default properties used by MSI handler

When invoking MSI handler, WU/MU will set the following public properties in addition to the ones that are set by the application:
  • " REBOOT=REALLYSUPPRESS";
  • " MSIRESTARTMANAGERCONTROL=Disable";
  • "ALLUSERS=1";
  • "TRANSFORMSSECURE=1";
  • "PATCH=\"";
  • "TRANSFORMS=\"";
  • "MEDIAPACKAGEPATH=\"";
  • "MisSetInternalUI=<5\"
  • Note: MSI installations are handled via the Windows Installer API, and not by calling the msiexec command line!


MSP Handler command line arguments

The Windows Update Agent uses the Windows Installer APIs to install an MSP. It does not use the msiexec.exe.

The API used is MsiApplyMultiplePatches. The arguments passed are patches to install, the target product code and the command line. The command line used by client is “REINSTALL=ALL REINSTALLMODE=OMUS REBOOT=REALLYSUPRESS” + additional arguments specified in the metadata.

The client also calls (prior to MsiApplyMultiplePatches) the MsiSetInternalUI API. The arguments are either INSTALLUILEVELNONE or INSTALLUILEVELSOURCERESONLY. Which one gets chosen depends on some custom logic for binary and full file fall back.

This means that the only UI that will be shown to users is the one that prompts for location of source. No other UI is ever shown for MSP updates.


Best Practices for MSIs

  • Minor upgrades that don’t change product code should be MSPs
  • Major upgrades should be MSIs that have a new product code.
  • No reboot in the middle of setup
  • Any configuration related information should be passed in command line format (ie don’t store it in INF files that you send your installer to find)
  • Do not use Admin Images
  • Apps should be installed as per-machine. WU/MU does not support per-user installations.
  • Installs should be silent without any UI being shown to user.
  • Higher version MSI updates should always supersede previous (lower) versions. This will help prevent two potential problems:
    • If multiple higher versions are published, only the highest one (assuming it supersedes all its lower versions) will be offered for installation.
    • In case the machine has a higher version installed, its lower version will not be offered for un-installation (if superseded by higher version) when it is deployed for uninstall via WSUS.


Best practices for MSPs

  • MSP should be standalone and not require bootstraps to help determine Product IDs (ie build your MSP to target Product IDs).
  • Unique Patch codes: Use unique patch codes when creating binary delta and full file patches. Though they patch the same vulnerability, they are in effect two different patches and should have unique codes. In the instances that a binary delta fails, the failover to the full file will also fail because the patch code is the same.
  • Full file versus binary deltas:Figure out your N-1 support plan and determine how to detect appropriate versions in the binary deltas. Prefer QFEs to be full file and SP to have both binary deltas and full files
  • MSPs (and product MSIs) should be built using MSI 3.0 or higher.
  • Cabbed MSPs: MSPs cannot be published as-is. They must be cabbed. MAKECAB.exe is one among several utilities that can be used to cab the MSP. The name of the cab must be the same as the MSP.The cab must be signed. The MSP itself need not be signed.
  • WU/MU can only patch per-machine applications. Per-user patching is not supported.

Last edited Aug 10, 2009 at 6:59 PM by rhearn, version 1

Comments

No comments yet.