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:

• Applying Dynamic Config To App-V 5 MSI Packages
• Fix For MSI Packages Created With App-V 5.0 SP1

The format of these MSIs has changed slightly through the releases:

• 5.0
  • Initial release.
• 5.0 SP1
  • MSI packages broken and fail to install!
• 5.0 SP2
  • 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.
• 5.0 SP3
  • Custom action modified to automatically import DynamicConfig.xml file.
  • 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:

https://technet.microsoft.com/en-us/itpro/windows/manage/appv-release-notes-for-appv-for-windows

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.

Download Links

• Direct Download:
  • https://github.com/DanGough/Fix-AppvMsiPackage/archive/master.zip
• GitHub Repo:
  • https://github.com/DanGough/Fix-AppvMsiPackage

Contents

• Fix-AppvMsiPackage.mst - This contains the bulk of the fixes.
• Fix-AppvMsiPackage_1607x86.mst - This contains just the small change necessary to allow Windows 10 v1607 x86 MSIs to install on x64 clients.
• Fix-AppvMsiPackage.ps1 - A Powershell script to apply the transforms directly to an MSI.
• Fix-AppvMsiPackage.cmd - A helper script companion to the .ps1 file to allow drag and drop operation.
• WixToolset.Dtf.WindowsInstaller.dll - Dependency of the Powershell script.
• Base.msi - The base MSI used to create the MST file. If you wish to modify the MST yourself, you should do so against this package otherwise you may lose elements of the transform upon save.

What Does It Do?

• MSI packages can now install with the App-V client built into Windows 10 v1607.
• MSIs will now automatically apply DeploymentConfig.xml (using 5.0 SP3 method)/
• You can now install packages just by double clicking on them as UAC elevation now works properly.
• You can also uninstall and repair from Add/Remove Programs. Repairing will now add / publish the package if it was removed, and will repair extensions to bring back deleted shortcuts etc.
• The ‘change’ option has been removed from Add/Remove Programs, since they have no features to select.
• Packages now have an App-V icon in Add/Remove Programs, making it easy to tell which apps are virtualised.
• Packages are prevented from installing over a new version.

How Do I Use It?

There are a couple of ways:

Apply MST Dynamically During Deployment

Specify the TRANSFORMS property on your msiexec command line to apply the changes at install time without modifying the MSI, e.g:

msiexec /i <PATH TO MSI> /qn TRANSFORMS=Fix-AppvMsiPackage.mst

If you are deploying MSIs created with Windows 10 v1607 x86 on an x64 client, you will need to layer on the additional fix:

msiexec /i <PATH TO MSI> /qn TRANSFORMS=Fix-AppvMsiPackage.mst;Fix-AppvMsiPackage_1607x86.mst

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'

Or:

.\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, it will process whatever you drop onto it! You can also run this script against all of the template MSI packages found in the sequencer directory, e.g:

.\Fix-AppvMsiPackage.ps1 'C:\Program Files (x86)\Windows Kits\10\Microsoft Application Virtualization\Sequencer'

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!