MSIX – Using the Bulk Conversion Scripts

This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.

 

 

Hello everyone, this is Ingmar Oosterhoff, a Modern Workplace Customer Engineer at Microsoft. In an earlier series of posts we set up our environment to do batch sequencing using App-V. In this blog I will explain how we can set up our machine so we can do batch conversion of our application installers into MSIX packages 

We will be using the Bulk conversion scripts from the MSIX Toolkit. 

 

In my example below I will be using Hyper-V VMs on my laptop, but it is also a possibility to use remote machines to do the heavy lifting. 

A benefit of using Hyper-V VMs on my machine is that the Bulk conversion scripts can utilize the checkpoint functionality, so it nicely reverts the VMs to a clean state to be re-used for the next app. 

 

Let us start by preparing the host machine, my laptop. 

The shopping list: 

  • MSIX Packaging tool 
  • Hyper V 
  • Some VMs 
  • Share containing installers. 
  • Signing certificate. 
  • Signtool.exe 

 

The MSIX Packaging Tool can be installed from the Microsoft Store, so that is an easy step. 

 

Enabling Hyper-V is not that much more difficult. 

Via Control Panel\Programs we go to "Turn Windows features on or off" 

When I scroll a bit down, I can enable Hyper-V on my machine. 

 

After enabling Hyper-V, I needed to restart my machine, and I am good to go! 

 

Turn Windows features onTurn Windows features on

 

 

(I could have used PowerShell to enable Hyper-V) 

 

 

 

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All 

 

 

 

More on enabling Hyper-V: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v 

Signing Certificate 

I need to sign the newly created MSIX packages with a certificate, so on my laptop I've created a folder MSIX on my C: drive, in which I have created a folder Signing, and this folder contains the certificate I am going to use to sign the packages, and signtool.exe, which is part of the Windows 10 SDK. (Have a look at our earlier post on how to set that up) 

bulkConvert3.png

 

All done. 

The host machine, my laptop, is prepared! 

 

Note: 

If I want to use remote machines, the shopping list would be a little longer, as I would have to enable PowerShell Remoting, and, if the remote machine is not in the same domain as my machine, or just in a workgroup, add the name(s) or IP address(es) of the remote machine(s) to WinRM Trusted Host. 

  • To enable PowerShell remoting, run PowerShell as an admin and execute the following command:

    Enable-PSRemoting -force 
  • To add the remote machine to WinRM Trusted Host, run PowerShell as an admin and execute the following command:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value <RemoteMachineName>  
    (Don't forget to replace <RemoteMachineName> with the actual name or IP address of the remote machine.) 

 

Some VMs 

Now I am ready to create some Virtual machines on my laptop. 

 

I would recommend using the Hyper-V Quick Create "MSIX Packaging Tool Environment" template to be used, as it is already pre-configured to meet all requirements. 

To do so, start the Hyper-V Manager, right click on your machine name, and click Quick Create…  

If you are not going to use the Quick Create template, make sure to install the MSIX Packaging Tool driver. 

 

 

bulkConvert4.png

 

 

 

Top of the list you find MSIX Packaging Tool Environment 

 

 

bulkConvert5.png

 

 

The default name of this VM (virtual machine) will be MSIX Packaging Tool Environment, but since I want to utilize multiple machines for my batch conversion to speed thing up, I am renaming this first one to MSIX01 by clicking More options and changing MSIX Packaging Tool Environment to MSIX01 in the Name field. 

Once the first one has been created, repeat these steps to create another VM. This one I am naming MSIX02. 

It will not download the image again, instead re-use what was downloaded earlier and creates the second VM. 

Memory wise my machine would not be able to run more than 3VMs at the same time, so I am going to do the conversion using 3 machines. 

Every time Quick Create is ready with creating the machine, it shows the window above. 

Click Edit settings… and uncheck the box in front of Use automatic checkpoints 

Here you can also change the amount of memory the VM will use. I am going to leave that as it is. 

Click Ok to save your changes, and click the blue Connect button.  

 

The window of your VM shows up, and you can start the VM by clicking the start button. 

 9.png

 

After going through the region and keyboard choices, I went for Domain Join instead, and created user (Larry) and a password (kensentme). (definitely going to delete these machines afterwards) 

 

I am setting up all 3 VMs the same, running Windows Updates, rebooting the machines until they are all good to go. 

Installers 

Right! 

Now have the VMs ready, it is time to prepare a location where the VMs can get the installers from. On my file server I have created a folder named Installers, to store the installers I want to convert. 10.png

  

Open File Explorer on the 3 VMs, and go to the created folder, \\HOST\Repository\installers in my example. Windows Security will prompt for name and password, which I will enter, and I am making sure to check the box to remember my credentials. 

When the Batch Conversions scripts be executed, reaching the installers should be no problem this way. 

 

11.png

 

VMs: check! Installers: check! Signing Certificate: check! Sign tool: check! 

Let us get to work on those Batch Conversion scripts. 

The Scripts 

In the MSIX folder I created earlier on the C: drive, I've created a folder BatchConversion, and created the 4 PowerShell files that are shown in the toolkit at https://github.com/microsoft/MSIX-Toolkit/tree/master/Scripts/BatchConversion 

(I have created the files with Visual Studio Code, and copy pasted the contents into those files.) 

 

12.png

 

 

Batch_convert.ps1 

Contains the functions that will create the template for the MSIX packager to execute, and the conversion jobs. No changes are needed to this file. 

 

Entry.ps1 

This file contains all the parameters for the conversion jobs. 

We will start on line 10 by specifying the names of the VMs we have created. 

 

13.png

 

 

 

 

 

 

 

 

 

Since I am not going to use remote machines, I have uncommented line 15. 

 

Line 18 to 43 contains conversion parameters. 

This holds all the info of the applications you want to convert. Out of each entry a template is going to be created, which will be execute by the MSIX packaging tool. A great description of the different parameters can be found at 

https://docs.microsoft.com/en-us/windows/msix/toolkit/msix-toolkit-msixbatchconversion#conversionsparameters 

 

The one that seems the most challenging to fill is the PublisherName parameter. The documentation states: 
PublisherName = "CN=YourCompany"; Certificate Publisher information - must match signing certificate 

A straightforward way of getting the exact PublisherName is by PowerShell. 

 

 

 

 $certfile = "C:\MSIX\Signing\NameOfYourCertificate.cer"  (Get-PfxCertificate $certfile).Subject

 

 

 

We can now turn our attention to the ConversionParameters. 

We can now modify the examples In the entry.ps1 script to what we need. 

The example reads: 

 

 

 

$conversionsParameters = @(      @{          InstallerPath = "Path\To\Your\Installer\YourInstaller.msi";          PackageName = "YourApp";          PackageDisplayName = "Your App";          PublisherName = "CN=YourCompany";          PublisherDisplayName = "YourCompany";          PackageVersion = "1.0.0.0"      },      @{         InstallerPath = "Path\To\Your\Installer\YourInstaller2.msi";         PackageName = "YourApp2";         PackageDisplayName = "Your App2";         PublisherName = "CN=YourCompany";         PublisherDisplayName = "YourCompany";         PackageVersion = "1.0.0.0"      },      @{         InstallerPath = "Path\To\Your\Installer\YourInstaller3.msi";         PackageName = "YourApp3";         PackageDisplayName = "Your App3";         PublisherName = "CN=YourCompany";         PublisherDisplayName = "YourCompany";         PackageVersion = "1.0.0.0"      }  ) 

 

 

 

After changing this to the installers I want to run, and providing the additional parameters it reads: 

 

 

 

$conversionsParameters = @(      @{          InstallerPath = "\\host.b77.ingmaro.net\Repository\installers\RDCman.msi"          PackageName = "RDCman";          PackageDisplayName = "Remote Desktop Connection Manager";          PublisherName = "CN=Contoso Software (FOR LAB USE ONLY), O=Contoso Corporation, C=US";          PublisherDisplayName = "Microsoft";          PackageVersion = "1.0.0.0"      },      @{         InstallerPath = "\\host.b77.ingmaro.net\Repository\installers\Dynamics365-USD-4.1.1.1397-amd64.exe"         PackageName = "Dynamics365USD";         PackageDisplayName = "Dynamics365USD";         PublisherName = "CN=Contoso Software (FOR LAB USE ONLY), O=Contoso Corporation, C=US";         PublisherDisplayName = "Microsoft";         PackageVersion = "1.0.0.0"   InstallerArguments = "install Shortcut=n /S"      },      @{         InstallerPath = "\\host.b77.ingmaro.net\Repository\installers\PBIDesktopSetup_x64.exe"         PackageName = "PowerBIDesktop";         PackageDisplayName = "Microsoft PowerBI Desktop";         PublisherName = "CN=Contoso Software (FOR LAB USE ONLY), O=Contoso Corporation, C=US";         PublisherDisplayName = "Microsoft";         PackageVersion = "1.0.0.0"  InstallerArguments = "-q -norestart ACCEPT_EULA=1 INSTALLDESKTOPSHORTCUT=0"      }  ) 

 

 

 

As you can see, I am using the UNC paths to the installers that I have placed into the Installers folder earlier. 

For the MSI installer I do not need to specify any additional install switches. For the .Exe file I have added the InstallerArguments parameter, so I can provide the correct switches for a silent install of the application during the conversion. 

Save the file after making the changes. 

 

RunJob.ps1 

This file contains the actual conversion action. 

Line 8 ,9,16,17,18 and 19 are commented out, but this is the part that creates the checkpoints, and makes sure the VM rolls back to the clean snapshot, prior to execution a conversion job on the VM 

 

14.png

 

Removing the #'s from these lines brings this back into action. 

Below is the result after the changes. 

 

 15.png

 

Save the file after making the changes. 

Sign_deploy_run.ps1 

This file contains the signing part of the batch conversion. 

In this file we need to specify the path to the signing certificate, and signtool.exe. 

 

16.png

 

Change line 5 and 8 to point to your certificate, and the location of the signtool.exe.  

 

17.png

 

As you can see, I've also added /p "notreallythecertificatepassword", as the signtool needs the password to be able to use the certificate for signing. 

Save the file after making the changes. 

 

All the changes have been made, let’s start the Batch Conversion. 

Open a PowerShell window, and change to the BatchConversion folder in which we have created the PowerShell scripts. 

Then. Run .\entry.ps1 

 

18.png

 

You will be prompted to enter the credentials to use for the VMs. Enter them and click OK 

The first Job will now commence by creating a check point of the VM, and then start the conversion of the first app. 

 

19.png

 

Once it is done, it will create an "after" snapshot of the VM, using the name of the job, roll back to the "before" snapshot, and inform you that the job is done. 

(Press any key to exit this window should read hit enter to close this window, as that only seems to work) 

 

Once all installers have been converted, the MSIX packages are going to be signed, and the packages are added to my machine so I can test the results. 

The created MSIX packages are stored is a subfolder Out\MSIX. 

 

Happy converting! Let me know how it went! 

 

Ingmar Oosterhoff and Matthias Herfurth 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.