What, exactly, is the SCCM client doing when it installs an .msi for a system?
- 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".
- 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.
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.