App-V 5 Recipe for SQL Server Management Studio 2016 or SSMS 17.x

The legal stuff first: Use these instructions at your own risk. I cannot guarantee that they will always function well and I accept no responsibility for any damages. However I would appreciate any feedback concerning problems in order to help others in the community.

You can find here the Recipe for 18.5: https://www.andreasnick.com/105-sql-server-management-studio-18-5-ssms-app-v-recipe.html

Notice: If you would like to support me and this blog, then purchase my App-V 5 book (written in German): https://www.amazon.de/Softwarevirtualisierung-mit-App-V-Ein-Praxisbuch/dp/1544717318

A few days ago I held a workshop on packaging for App-V together with one of our best Citrix specialists and coauthor of the Rheinwerk book for XenDesktop 7.x, Jan Hendrik, (Jan Hendrik's Blog excelent Citrix Blog) as well as with his colleague Tobias. Especially we talked about applications for which packaging had not functioned. This included, among others, the SQL Server Management Studio 2016 and SSMS 17. Even with the App-V recipe for SSMS 2014 it still did not allow packages to be made.
Upon attempting to sequence SQL Server Management Studio 17 and to save it, the following error occurs: HRESULT: 0x8007139F. Apparently the App-V 5 sequencer does not function with some of the components in the package (@Microsoft – this is a bug in the sequencer). Furthermore it is no longer possible to download Visual Studio Shell 2015 (Isolated) separately from Microsoft. In the Rorymon blog there is only a notice that Microsoft does not (any longer?) support Management Studio (SSMS 17) for App-V. I think that the lack of manufacturer's product support is the case for many applications. Therefore we simply tried it ourselves (it does represent quite a challenge).
When one takes a closer look at the problem with the Process monitor, one quickly sees which component it is that causes the HRESULT:

This text describes how Microsoft App-V can be used to do a fully automated conversion of an entire collection of MSI packages to App-V packages.

The prerequisite for this is, alongside a functioning virtual sequencer, a VMware ESXi environment with vSphere and PowerCLI:

https://www.vmware.com/support/developer/PowerCLI/

This example can easily be adapted for Hyper-V.

Microsoft offers the possibility to automate packet creation with Windows PowerShell on the sequencer. The use of this module is simple. However must ensure the sequencer is installed on the environment according to the best practice for the selected environment. As a rule the automated packaging will be controlled from the outside, so use a sequencer in a Hyper-V or VMware environment and reset it automatically before each use.

Import the sequencer PowerShell extension:

With Folder2MSP you can create MSI packages and MSP patches from directories in the simplest manner possible. There is no excuse anymore to complete such a task using a script. MSI and MSP are the standard for software distribution. Our tool Folder2MSP will enable you to take advantage of this. Read further for details about using the tool and where to download it.

First the legal information:
EXCLUSION FROM LIABILITY: USE OCCURS AT YOUR OWN RISK. NICK INFORMATIONS UND ANDREAS NICK ARE NOT LIABLE UNDER ANY CIRCUMSTANCES FOR DAMAGES TO HARDWARE OR TO SOFTWARE, LOST DATA OR OTHER DIRECT OR INDIRECT DAMAGES THAT RESULT AS A USE OF THIS SOFTWARE. Please test thoroughly any patches and MSI packages created with this tool. In the cases of long patch sequences, problems can occur. Solutions to this problem are described in the text below.

A Windows installer patch (MSP file) is a package file that contains updates for a certain application and describes which version of an application can be patched. The advantage of an MSP is that it contains only files that then become an MSI. MSPs are generally used for minor releases or small updates. I myself have a tool up my sleeve that can distribute binary differences for extremely small patches (to be released soon).
The patch contains, among other things, a product code and a patch code for the application to be changed. If the product code matches with the installed application, patching is possible. It is practical then to be able to determine this code before an installation in order to optimize a software distribution. I'll show you two solutions how to do so with PowerShell.
How do I find out the product code? One variant is found at Codeplex: MSI Powershell Module.