Home / server / Questions / 708889
In Process
alx9r
Asked: 2015-07-28 12:57:58 +0800 CST

What, exactly, is the SCCM client doing when it installs an .msi for a system?

  • 772

I've been working with a particular .msi (AppleApplicationSupport.msi). I have installed it two different ways which I thought would be equivalent. However the results differ as follows.

PSEXEC -i -s cmd

Installing using a psexec -i -s cmd command prompt and running msiexec /i AppleApplicationSupport.msi results in the outcome I want:

  • "Apple Application Support (32-bit)" shows up in "Add or Remove Programs"
  • "Apple Application Support (32-bit)" can be uninstalled

MSI Deployment Type Installed by SCCM Client

Creating an MSI Deployment Type and installing it using the SCCM client yields the following results:

  • nothing shows up in "Add or Remove Programs"
  • SCCM does not detect that it has installed
  • "Apple Application Support (32-bit)" app can be found using gwmi -Class Win32_Product, however, running $app.Uninstall() does not uninstall it.

What is the difference?

I thought that an MSI Deployment Type installed for a system was equivalent to running msiexec from a psexec -i -s cmd command line. Evidently, they are not the same.

  1. What, exactly, is the SCCM client doing when it installs an MSI Technology deployment type for a system? Can I replicate that operation without SCCM involvement?

  2. Is the SCCM client's execution of a Script Installer deployment type's installer really equivalent to a call to msiexec from psexec -i -s cmd? In other words, for script installer deployment types should I expect parity between msiexec run by the SCCM client and msiexec run from psexec -i -s cmd?

Added after kce's answer:

  1. How does SCCM manage to install the .msi without it showing up in "Add or Remove Programs"?
sccm

2 Answers

    1. What, exactly, is the SCCM client doing when it installs an MSI Technology deployment type for a system? Can I replicate that operation without SCCM involvement?

    As far as I am aware, the SCCM client is running whatever installation string was specified in the Deployment Type, however it is executing it under the context of NT AUTHORITY\SYSTEM. You can approximate but not duplicate the installation by executing the same installation string from an account that is a member of BUILTIN\Administrators. MSIEXEC can be run as either a 32-bit or 64-bit process depending on whether or not you check the box that says "Run installation and uninstall program as 32-bit process on 64-bit clients".


    1. Is the SCCM client's execution of a Script Installer deployment type's installer really equivalent to a call to msiexec from psexec -i -s cmd? In other words, for script installer deployment types should I expect parity between msiexec run by the SCCM client and msiexec run from psexec -i -s cmd?

    Hmmm. Good question. The client should just run the installation string but it would not be terribly surprising to me if it did some deeper, darker magic. The only thing I can think of in your situation that might be causing the difference is the bit-ness of process you are running the installer under. I think the SCCM client almost always uses 64-bit but cmd.exe is 32-bit right?

    Take a look at my answer here for other general advice in dealing with software install issues.

    Best of luck.

    • 4

  2. In addition to this work of art answer by @kce, the only meager, simplistic things I have to add are

    • I treat all packages equally

    In general I avoid "Applications" unless I'm forced to deal with them, which is usually when I'm creating a App-V deployment. Otherwise, I stick to packages, they are less of a headache as you have seen or will see.

    In SCCM I created a package for my .msi files the same as I would for any other installer. like kce said it's installing under the system account, however when I create a package vs. using it's default msi handler, I have finer control over the install string it runs, for example msiexec /i "my.msi" /qb /v vs. whatever the default is. My applications essentially always showed up in Add/Remove where they would have showed up had I installed manually. In theory, yes, the SCCM Application deployment type for .msi should work fantasically, but in practice using something different may give you better results. Since Applications are new to this version of SCCM, there are likely some kinks to work out.

    Bonus

    If you really want to find out if this is related to the install account, use the psexec switch for running the command under the system account.

    • 2