Dan Gough rambles on about application packaging and virtualisation

Fix for App-V Sequencer Generated MSI Packages

As you may know, the App-V sequencer also spits out an old-school MSI package by default as part of its output. These are useful not only if you just want to quickly import a package for testing, but also for those using 3rd party deployment tools or Microsoft Intune to manage their packages. I have previously published a couple of .MST transforms to deal with various issues found in the MSI packages that the App-V sequencer creates:

Custom action added to quit if a repair action is detected. Previous versions would wipe out a registry key during repair that prevented the MSI from being uninstalled.

Launch condition added to prevent older version of an MSI being installed over a newer one.

Platform no longer set to x64 on packages created with the 64-bit sequencer. No big deal, just that these packages take longer to fall over as they fail to install rather than get blocked at the very beginning.

Custom actions broken so that MSI will now only install/uninstall from an elevated session!

5.1

Reverted to 5.0 SP2 format!

10.0.14393 (from Windows 10 ‘Anniversary Update’ v1607 ADK)

Launch conditions now use AppSearch and RegLocator tables to look for HKLM\Software\Microsoft\AppV\Client instead of the Sequencer MSI

Current implementation is broken as packages created on 32-bit look under the 32-bit registry area on a 64-bit machine and fail to detect the App-V client.

A new issue has reared its head recently. Up until now, the MSI packages checked for the existence of the App-V client MSI before they will proceed. With the new Anniversary Update v1607 for Windows 10, the App-V client is built in, so this check fails and you are unable to install the MSI packages. The sequencer bundled with the latest ADK resolves this, and Microsoft recently issued an official workaround to remedy existing packages:

However (at the time of writing) this does not work by simply following the steps listed, so here are the additional steps required!

You need to install the Windows 7 SDK, as the msidb.exe tool it relies upon was deprecated since the Windows 8 release. You just need the Tools feature under Windows Native Code Development.

You then need to set an environment variable MSSDK pointing to the install location of this. To do this in your Powershell session type:$env:MSSDK='C:\Program Files\Microsoft SDKs\Windows\v7.1'

In Powershell, the function is not available until you ‘dot-source’ the script:..\Update-AppvMsiPackage.ps1

Whilst the official fix above will make it possible to deploy your MSI on Windows 10, may I present to you an alternative…

The Über Fix

I have updated my MST to fix all of the known issues and bring back the 5.0 SP3 functionality. By creating a base MSI with all of the issues it was possible to create a transform that will apply to all versions; the one exception being to fix the MSIs created by the Windows 10 v1607 x86 sequencer (you cannot add a row and modify the same row within the same transform). There is also a script to apply the changes directly to an MSI, or even a whole folder full of them, so that you don’t have to rely upon the MST being set up correctly during deployment.

Fix Your MSI(s) Before Deployment

Simply run the Powershell script Fix-AppvMsiPackage.ps1, passing a parameter of either an MSI file name, or a folder path that contains one or more MSI packages, e.g:

.\Fix-AppvMsiPackage.ps1'C:\Test\Test.msi'

.\Fix-AppvMsiPackage.ps1'\\appvserver\content'

If you forget to supply this, it will ask for it. If a folder is given, the script will recursively search for all MSIs within, so take care. Any existing MSI will be backed up with the .bak extension (and it will not overwrite these .bak files if it is re-run).

The dependency WixToolset.Dtf.WindowsInstaller.dll needs to be located in the same folder as the script. This library is pinched from WiX, and I must give credit to Laurie Rhodes here for helping me get on the bandwagon with this one. Seriously, if you are interested in writing Powershell scripts that interact with Windows Installer, and Heath Stewart’s Powershell Module doesn’t have you covered, using this library is a hell of a lot easier than using the COM interface!

To make your life easier, simply drag and drop your MSI or folder on top of the Fix-AppvMsiPackage.cmd file. As long as the .ps1 and .dll are in the same location, will process whatever you drop onto it!

I recommend you run this script against all of the template MSI packages found in the sequencer directory, e.g:

This way, any packages you create with the sequencer will have the fixes built in already!

This goes without saying, but this is all provided on a use-at-your-own-risk basis. But if you have any issues, comment below and I’ll do my best to fix them.

Known Issues

It appears that all of these MSI packages fail to install if Powershell execution policy is applied via Group Policy. The installer fails with the message:

Failed to publish the package due to the following error: Windows Powershell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specfic scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted.

This is a benign warning since policy has set the system to Unrestricted, but the installer is treating it as a fatal error. This would require Microsoft to modify the custom action dlls to fix this, unless I bin them all and replace them with Powershell commands. This isn’t a road I’m going to go down, but if this is a show stopper for you, get in touch!

Post navigation

3 responses on “Fix for App-V Sequencer Generated MSI Packages”

Brilliant fix, outside the box! MS should have thought of the MST solution, it’s quick, non-intrusive and only required until the sequencer is fixed or you feel like stepping through all your MSI’s with the repair tool, great job and thanks for sharing (the MS fix doesn’t work, as noted)…

Thank you for this great post! I was hoping you could assist me further. When I try to run the powershell script against my app-v generated MSI, i continue to get the following errors:
I have ensured that the wix.dll is in the same folder as the scripts and even copied the app-v msi i am trying to rectify to work on windows 10 to the same directory as the scripts and dll. Is there something I am missing or doing wrong? Any information would be appreciated. Thanks 🙂

Hi, first of all, try and simply unzip the contents and then drag and drop your MSI onto the Fix-AppvMsiPackage.cmd file. If that works, perhaps you had a file missing or there was something else different about the way that you ran the script.