7

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"?
alx9r
  • 1,643
  • 3
  • 16
  • 37
  • I suspect this has something to do with msiexec installing for a single user instead of all users. That decision depends on "access privileges of the user, whether elevated privileges are required to install the application, the value of the ALLUSERS property, the value of the MSIINSTALLPERUSER property and the version of the operating system." ([ref](https://msdn.microsoft.com/en-us/library/aa367559(v=vs.85).aspx)). That list of variables combined with the inability to test separately from SCCM is reason enough for me to avoid the MSI Deployment Type altogether. – alx9r Jul 28 '15 at 00:08
  • How do you know the app was successfully install w/ SCCM? Was the return code 0? – MDMoore313 Jul 28 '15 at 19:53
  • @BigHomie I'm fairly sure the msiexec error code was 0. I wouldn't call it "successful". I do know for certain the SCCM install did _something_ permanent because (1) it shows up in the results of `gwmi -Class Win32_Product` and (2) subsequent attempts to (un)install the same msi result in some flavor of "already installed" errors. – alx9r Jul 28 '15 at 19:57
  • When installing .msi files I have made it a habit to ALWAYS write a log file using "/l*v c:\windows\temp\app.log". This would be an easier way to trace what is happening in your two scenarios. – Bin Aug 06 '15 at 20:29
  • @Bin Duly noted. – alx9r Aug 07 '15 at 19:56
  • Not entirely related to the question but I have this product installing fine via MSI, for system with product code detection method using the command line: msiexec /i "AppleApplicationSupport.msi" ALLUSERS=1 /QB! The ALLUSERS switch may explain the odd behaviour your seeing but that doesnt seem likely. As said above, /lv!* can be useful in determining what's going on. – Shovers_ Dec 29 '15 at 10:24

2 Answers2

4
  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.

Community
  • 1
  • This confirms a lot of what I already understood, but it doesn't explain how SCCM manages to install the .msi without it showing up in Add or Remove Programs. – alx9r Jul 27 '15 at 21:54
  • Add or Remove Programs is special - I can't remember why but it has something to do with the WMI classes being regenerated? Is it possible your software installs fine but just doesn't register in Add or Remove Programs? @bighomie - What's your thoughts? –  Jul 27 '15 at 21:59
  • Ah. Disregard. I had it the other way around. I was thinking Win32_Product vs. Win32_AddRemovePrograms. http://blogs.technet.com/b/askds/archive/2012/04/19/how-to-not-use-win32-product-in-group-policy-filtering.aspx –  Jul 27 '15 at 22:02
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.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73
  • I agree with treating all packages equally. [I am also skeptical of the MSI Deployment type](https://serverfault.com/questions/708889/what-exactly-is-the-sccm-client-doing-when-it-installs-an-msi-for-a-system#comment879179_708889). I don't follow your preference for Applications over Packages though. I have yet to encounter an issue whose root cause is a fundamental problem with the Application model. The script installer deployment type seems to work as I expect. Do you have some specific problems with Applications in mind that I should know about? – alx9r Jul 28 '15 at 14:31
  • @alx9r Yeah. There's more than one way to skin a cat... er Application. Apparently. I love the Application-Program model, better detection logic, supercedence, Application Catalog, etc. For crappy (uh "creative") MSI installers I just use the Script Installer Deployment Type and call msiexec directly (or alx9r could use psexec). –  Jul 28 '15 at 17:39
  • @kce I only use psexec for testing package installs to system. This is so that package installation can be validated separately from SCCM. – alx9r Jul 28 '15 at 17:45
  • 1
    @alx9r Sure. Make sense. But if works via psexec but doesn't through SCCM you could do something super hacky and just have the client call psxexec... I may or may not do this... :( –  Jul 28 '15 at 17:59
  • 2
    @kce That idea makes me sad. – alx9r Jul 28 '15 at 18:02
  • @alx9r after reading you and kce's comments and chatting with kce I just realized I tried to inflict my bias onto you, I apologize. I should probably spend more time working with Applications in SCCM ( as with everything else in SCCM) before writing them off almost completely. I do find the concept intriguing, however, but a major factor that turned me away was that I would have to convert all of my packages to applications manually, and I have a lot since we came from SCCM 2007. There's simply not enough time to do that, and it also doesn't make sense to have my apps split between the two. – MDMoore313 Jul 28 '15 at 19:33
  • paging @kce ..... – MDMoore313 Jul 28 '15 at 19:33
  • No apology necessary. I suppose you're chatting elsewhere...I can't seem to find you or @kce on chat.se. – alx9r Jul 28 '15 at 19:42
  • Thanks, I will see if I can dig up more info on what it does during the application deployment type for .msi – MDMoore313 Jul 28 '15 at 19:49