I've got an MSI created by WIX that can be run locally as an administrator without error. But when deployed via SCCM as an Application Deployment imported from the MSI shows in Software Center as having failed with code 0x87D00324
. In either case the actual installation succeeds (in that files and registry entries are created as expected and the application loads).
The SCCM error suggests that the product isn't detected after installation. If installed manually using the same command line as SCCM is configured to use (msiexec /i [msi goes here] /qn
), Software Center shows the application as Installed, indicating the detection rules are correct - detection is setup to look for the installed product code. AppEnforce.log
traces suggest that the above's what's happening:
- SCCM installs the MSI with no errors
- Post-install tries to detect the MSI
- Fails to detect, marks the deployment as a failure
The MSI is configured to install for all users (ALLUSERS=1
as an MSI property, not on the command line) and requires elevation to run. The SCCM job is configured as 'Install for System' and 'Only when no user is logged on', and targets specific machines and not users.
With machine-wide MSI logging enabled, there are some differences in the logging output that I guess may be contributing:
- SCCM-issued install has a log entry:
PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'
though it's unclear what's causing this- This happens even if ALLUSERS=1 is supplied as a command-line argument to
msiexec
- as 'Adding ALLUSERS...' then 'Deleting ALLUSERS...' a few lines later
- This happens even if ALLUSERS=1 is supplied as a command-line argument to
- The
ProductPublish
step/log entry has anAssignment
value of 0 when installed via SCCM (equivalent to Per User, according to documentation) but 1 when installed manually (equivalent to Per Machine) - The SCCM install causes three MSI logs to be created, not a single log like the manual case
- One showing the MSI being called with
ADVERTISE
action - One that doesn't appear to call
msiexec
at all but is perhaps the remainder of theADVERTISE
action's logging in a different file for some reason - MSI called with a blank action (which down the log appears as an action of
INSTALL
)
- One showing the MSI being called with
Post-install, Get-WmiObject -Namespace root\ccm\CIModels -Class CCM_MSIProduct
has different output for the two install methods:
- Installed via SCCM, there's no entry for the new application - I'm guessing this is why SCCM thinks the application isn't installed
- Installed by hand, the new application appears with the correct details
Both methods show the application as installed when querying via wmic product get
.
Client: Windows 10 Enterprise, SCCM client 5.0.0.8577.1115
Server: SCCM 1710 (5.0.0.8577.1115)
Update 12 Apr 2018, additional info:
- The SCCM job works on some machines, but there's no obvious commonality between them
- The SCCM job can be permanently fixed on a given machine by using
pstools
to run the MSI as SYSTEM - if done once, uninstalling the MSI by hand then reinstalling via SCCM works and detects correctly (this is obviously pointless, but an interesting result) - Logging on the failing machines indicates things being done in the user context, not per-machine context
Using cached product context: User assigned for product: 6176BC215761514458869E9B9ABB08BC
- Logging on the failing machines shows multiples of the line above, while logging on the working machines seems to be hitting many multiple product codes all in the machine context
- Once installed via SCCM in the failed state, the only obvious registry difference is against
HKLM\Software\Classes\Installer\Products\[[Product Code]]\AdvertiseFlags
, which is0x180
in the failing state and0x184
in the passing state - Our ops team suggest that the failures started when supersedence was turned on for the job though I can't confirm if that's the case for all of the failures
What could cause the difference in behaviour between the SCCM job and a manual installation? What could cause the SCCM job to run in user context even though it appears to be running as SYSTEM and is configured to Install for System?