Looking for tips on how to best handle Windows Installer MSI minor/small upgrades/updates (vomus) for Application objects in SCCM 2012 ? Really hoping Microsoft has started to support their own Windows Installer MSI techniques better.

Some background about scenario we are trying to solve. If we leave SCCM out of the picture and do this manually it would look like this. Get the MSI install media files (MyApp v1.0.0), run 1st time install:
msiexec.exe /i MyApp.ini /qb-! ALLUSERS=2
A new minor upgrade appears for MyApp, upping ProductVersion to v1.0.1 (ProductCode GUID same, PackageCode changed). But not a major upgrade with changed ProductCode GUID. To save processing/time (not full uninstall /x and then /i), we install it by doing a command-line reinstall/repair. Two variants possible with identical result:
msiexec.exe /i MyApp.ini /qb-! ALLUSERS=2 REINSTALL=ALL REINSTALLMODE=vomus
msiexec.exe /fvomus MyApp.ini /qb-! ALLUSERS=2 REINSTALL=ALL
Works fine. As long as the MSI is authored correctly. The biggest hitch has always been that you cannot, as far as previous history goes, have identical command-line for 1st time install of MSI and possible succeeding reinstall/repairs. Meaning, you have to detect if MSI/ProductCode is installed already, then decide what command-line to use. This behavior is 100% part of Windows Installer MSI logic (Applying Small Updates (or Minor Upgrades)).

In the past in SCCM (Package Model) we have either had wrapper/passthrough utilities before msiexec.exe that performs a check. Or had different advertisements/collections depending on MSI already installed or not on machine. In those cases, we just updated the source path contents for package, updated DP's, re-run advertisement. Then it got executed with correct command-line.

Now we have SCCM 2012 and Application Model. How do we handle this scenario most correctly/efficiently ?

We have tried to research in a test environment. But only way we seem to get it to work is to create a separate new Application object for v1.0.1, then supersede the v1.0.0 Application object. But it feels like total overkill and a waste of time. It should be possible in some way to update existing MSI deployment type in Application object. Then force some action that results in a "re-run" of command-line on clients, with correct reinstall/repair (vomus) depending on MSI installed or not.

Early days for us and SCCM 2012, so really hope we have overlooked something :-) Any pointers in correct direction would be appreciated. Even if it is a confirmation of SCCM 2012 still not supporting this core Windows Installer MSI technique.

Were you able to get some direction for this?  As you mentioned, the only way I could think of was to create two applications and set the first time install detection to just the product code and the update to the product code and the version.  This way when the update runs it won't trigger the full install to backlevel.  I wasn't sure about the supersedence as that might uninstall the entire product?

How are you to run an update MSI in the application model when only an install and uninstall is possible to define?

Hi,

I know this is an old post but I have run into a similar issue, however in my case there are fewer options as the installations requiring updates are small updates.  This means the Product Code and Product Version are identical.  The only differing property is the Package Code that is contained within the Summary Information Stream as the Revision Number.  Unfortunately, SCCM 2012 does not include the Package Code as a property option for a Windows Installer Detection Rule.

My solution to the problem allows for a single SCCM Application without the need to uninstall the base package requiring an upgrade.  Steps as follows using the example taken from the original post:

1. Create an SCCM Application
2. Create a Windows Installer deployment type that performs the repair, e.g. msiexec.exe /fvomus MyApp.msi /qn ALLUSERS=2 REINSTALL=ALL
3. Assign the Detection Method of that deployment type to either a File System or Registry type, not Windows Installer type.  The File System or Registry change must be something that the MyApp 1.0.1 installation does that MyApp 1.0.0 does not, e.g. a newer version of a file.
4. Assign a custom requirement to that deployment type that detects either version of the MSI is installed, e.g. check for Product Code
5. Create a second Windows Installer deployment type that performs a full install of the latest package, e.g. msiexec.exe /i MyApp.msi  /qn
6. Apply the same detection to the second deployment type as was assigned to the first
7. Save and deploy

The trick is in the detection method and requirement set on the first deployment type.  If a client has MyApp 1.0.0 installed then the first deployment type will be triggered and a repair will patch the installation to 1.0.1.  If a client doesn't have MyApp installed at all then the second deployment type will trigger and a full installation of MyApp 1.0.1 will occur.  All other clients will return as already having MyApp 1.0.1 installed and nothing will happen.

Hope if helps.