MSIX – Using the Bulk Conversion Scripts

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  VMs on my laptop, but it is also a possibility to use remote machines to do the heavy lifting.

A benefit of using 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:

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

Enabling is not that much more difficult.

Via Control PanelPrograms 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:

Signing Certificate

I need to sign the newly created MSIX packages with a , 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 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)


All done.

The host machine, my laptop, is prepared!


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:localhostClientTrustedHosts -Value
    (Don't forget to replace  with the actual name or IP address of the remote machine.)

Some VMs

Now I am ready to create some 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.


Top of the list you find MSIX Packaging Tool Environment


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.


After going through the region and keyboard choices, I went for Domain Join instead, and created a 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.



Now I 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, HOSTRepositoryinstallers 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  be executed, reaching the installers should be no problem this way.


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

Let us get to work on those Batch Conversion .

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

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



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.


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.


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

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:MSIXSigningNameOfYourCertificate.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 = “PathToYourInstallerYourInstaller.msi”;
PackageName = “YourApp”;
PackageDisplayName = “Your App”;
PublisherName = “CN=YourCompany”;
PublisherDisplayName = “YourCompany”;
PackageVersion = “”
InstallerPath = “PathToYourInstallerYourInstaller2.msi”;
PackageName = “YourApp2”;
PackageDisplayName = “Your App2”;
PublisherName = “CN=YourCompany”;
PublisherDisplayName = “YourCompany”;
PackageVersion = “”
InstallerPath = “PathToYourInstallerYourInstaller3.msi”;
PackageName = “YourApp3”;
PackageDisplayName = “Your App3”;
PublisherName = “CN=YourCompany”;
PublisherDisplayName = “YourCompany”;
PackageVersion = “”

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

$conversionsParameters = @(
InstallerPath = “host.b77.ingmaro.netRepositoryinstallersRDCman.msi”
PackageName = “RDCman”;
PackageDisplayName = “Remote Desktop Connection Manager”;
PublisherName = “CN=Contoso Software (FOR LAB USE ONLY), O=Contoso Corporation, C=US”;
PublisherDisplayName = “Microsoft”;
PackageVersion = “”
InstallerPath = “host.b77.ingmaro.netRepositoryinstallersDynamics365-USD-”
PackageName = “Dynamics365USD”;
PackageDisplayName = “Dynamics365USD”;
PublisherName = “CN=Contoso Software (FOR LAB USE ONLY), O=Contoso Corporation, C=US”;
PublisherDisplayName = “Microsoft”;
PackageVersion = “”
InstallerArguments = “install Shortcut=n /S”
InstallerPath = “host.b77.ingmaro.netRepositoryinstallersPBIDesktopSetup_x64.exe”
PackageName = “PowerBIDesktop”;
PackageDisplayName = “Microsoft PowerBI Desktop”;
PublisherName = “CN=Contoso Software (FOR LAB USE ONLY), O=Contoso Corporation, C=US”;
PublisherDisplayName = “Microsoft”;
PackageVersion = “”
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.


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


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

Below is the result after the changes.


Save the file after making the changes.


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.


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


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.

Al 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


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.


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 OutMSIX.

Happy converting! Let me know how it went!

Ingmar Oosterhoff and Matthias Herfurth


This article was originally published by Microsoft's Entra (Azure AD) Blog. You can find the original article here.