2

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
  • The ProductPublish step/log entry has an Assignment 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 the ADVERTISE 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)

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 is 0x180 in the failing state and 0x184 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?

1
  • I suggest you download and install the Windows 10 SDK. From there you find WiLogUtl.exe with which you open your MSI log file and then hit "Analyse". As output, the utility will present you if errors were found and what caused them. Like this you could isolate better the root cause of SCCM error. However, I think that the detection method is faulty, try maybe a combination of file/registry instead of MSI-Product Code and stay aware of the bitness flavour of your OS/application. Cheers
    – Shizdenn
    Feb 6, 2019 at 8:40

1 Answer 1

0

As you have mentioned, it tries to advertise the MSI rather than install which is strange.May be you have to relook the script or read it in orca and see.

Did you happen to check the product code which is defined in detection appears in registry also.

32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Product code

or

64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Product code

1
  • The 32-bit key appears irrespective of the install method, the 64-bit key does not. Also - even in the success cases the MSI gets advertised, but in the logging it seems to be flagged in a 'per-machine context' instead of a 'per-user context'. In Orca there doesn't seem to be anything special, beyond ALLUSERS=1 as a property.
    – Pablissimo
    Apr 12, 2018 at 7:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .