1

Client machines are all Windows 10 Pro (64-Bit).

If we were to have MyCompanyApp.msi installed via SCCM, we found that we could update it successfully using SCCM. Everything normal there.

HOWEVER, if I were to run MyCompanyApp.msi locally either by double clicking on the msi or running msiexec, updating it with SCCM fails. Moreover, SCCM goes ahead and runs an install as if it had never detected the previous installation. When you check Control panel, you see the product listed twice; each having a different version number.

The bottom line is that when I mix manual installation/upgrade with SCCM manual installation/upgrade, I have the problem described above. The table below should summarize things.

enter image description here

ezG
  • 391
  • 1
  • 17
  • 1
    I would guess the upgrade table is not properly authored (so major upgrade fails) or perhaps the new version installs per-user? (user specific install as opposed to a machine-wide registered install). Not sure of all the details since I haven't tested this in ages - I avoid per-user installs. [Perhaps see this list of common problems with major upgrades](https://stackoverflow.com/a/56991527/129130). Or I might make no sense since it is late. – Stein Åsmul Aug 21 '20 at 00:27
  • @SteinÅsmul: I'll check out the link. Thanks – ezG Aug 21 '20 at 00:49
  • 1
    Stein beat me to it. Check out the Upgrade table https://docs.microsoft.com/en-us/windows/win32/msi/upgrade-table . When you package the new version of MyCompanyApp.msi you would use the same UpgradeCode GUID as in your previous version or at least add the previous UpgradeCodes into that table. This tells the MSI engine to uninstall previous versions before installing the new. No need to supersede or do anything extra in SCCM if you do this. If you don't want to use the upgrade table (although I'd recommend it) you can always wrap your install in a script that uninstalls old versions first. – Paul G Aug 21 '20 at 00:50
  • @PaulG I'm curious about something. Are you taking into account the fact that the upgrade IS successful as long as it's SCCM doing it? It only doesn't work if I try to update an SCCM install using manual means such as double clicking on the MSI. I will update the question to make it a bit clearer. – ezG Aug 21 '20 at 00:55
  • @ezG, My advise depends on which one of your descriptions is the actual problem. Please clean up your question a little because your description doesn't match the new table you just posted. 1.) Description = Install manually then SCCM fails to upgrade 2.) Table Picture = SCCM installs then manual install fails to upgrade If the issue is actually (1) then its probably the upgrade table that Stein and I suggested, if its (2) it could be a number of reasons this is happening and there isn't enough information but it could possibly be the user installing it and the ALLUSERS setting. – Paul G Aug 21 '20 at 03:24
  • @PaulG Thanks Paul. I've updated the question. The bottom line is that mixing SCCM and Manual installation/upgrades causes problems for me. Manual + Manual = Good | SCCM + SCCM = Good Other combinations fail. – ezG Aug 21 '20 at 06:02

1 Answers1

2

Logging: Do you have a proper log file? If not, please create it: Enable installation logs for MSI installer without any command line arguments

msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log

Starting Point: I would seach for FindRelatedProducts and check what the log file reads in the sections found.

Debugging: Failed Major Upgrades debugging: WIX does not uninstall older version.

CAUSES? Most likely you have:

  1. An incorrectly authored upgrade table.
  2. A mix of per-machine and per-user installations.

1. Upgrade Table

Check the entries in the Upgrade table. Does it look something like this. There are MANY ways to mess this table up. The most common problem is the VERSION RANGE specified. If it is set incorrectly the version found could be outside the range identified as "valid to remove":

Upgrade

2. Installation Context: MSI does not support "cross context" updates as explained here by Rob Mensching - the creator of WiX. My follow-up comment to him there is a more or less crazy approach I used once to remove some straggling installs in the wrong context: Crazy approach. Instead: check what features SCCM has these days to remove per-user installs?

Per-User Installs: Here is a piece on why per-user installs - as implemented by MSI - are not recommended - in my opinion (and many other MSI users).

You can find the per-user installations on the machine in question like this - note that there could very well be NO per user installations:

Dim i, msi
Set installer = CreateObject("WindowsInstaller.Installer")
i = 1

For Each product In installer.ProductsEx("", "", 7)
   productcode = product.ProductCode
   name = product.InstallProperty("ProductName")
   version=product.InstallProperty("VersionString")
   allusers=product.Context
   
   ' Ignore all per-machine installations
   If(allusers <> 4) Then
      msi = msi + CStr(i) + ": " & productcode & ", " & name & ", " & version & ", " & allusers & vbNewLine & vbNewLine
      i = i + 1
   End If

Next

MsgBox msi

Remove the if section to get ALL installed MSI products. There are limits to how many characters MsgBox can show. Write to a file instead? (see mid-page here) Or use WScript.Echo msi.

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • 1
    This deserves some upvotes/selected as answer even if it doesn't answer your immediate question because this is amazing information! – Paul G Aug 21 '20 at 23:39
  • @Stein Asmul I will be going over this with a fine tooth comb. EXCELLENT information. I will let you know if this works. – ezG Aug 22 '20 at 00:55
  • 1
    @PaulG Yeah, this answer is going into my toolbox for sure. – ezG Aug 22 '20 at 00:56
  • 1
    @Stein Asmul Everything in here was great, but it was the "Installation Context" information that nailed our problem. We simply did not know anything about this. Thank you – ezG Aug 27 '20 at 01:54
  • Yes, that can be a real pain in the neck. I prefer to force per-machine installations for all packages for corporate use, but things have changed and per-user installations seem more popular again. Newer deployment technologies seem to favor them. – Stein Åsmul Aug 27 '20 at 01:58