How to Provision and Remove MSIX Packages Per Machine?
In our IT Pro world, the best practice we have in place regarding app deployment is that all applications are installable per machine. No matter if it’s an MSI, EXE, or other custom types of installers.
The reason behind this practice is that it makes it easier to administer an infrastructure. If you want to enforce an application for all your users, you make it installable per machine and target the user viaSCCM, Intune, or other infrastructure management tools.
Of course, there are many other reasons to make our installations per machine, but this article focuses on the practical side of the process.
Compared to MSI, MSIX is designed to be deployed per-user. Though, with some PowerShell workarounds, you can achieve a per-machine installation for an MSIX package.
How to Provision Your MSIX
Unlike a typical MSI package, you cannot just add a property (like ALLUSERS=1) and install the application per machine.
With MSIX, you have different Powershell cmdlets that you can take advantage of. You can find the most used ones in one of our articles here.
Let’s take, for instance - Add-AppProvisionedPackage. This is an alias for the old Add-AppxProvisionedPackage.
Transposed to MSIX, this command should look like:
Add-AppProvisionedPackage -path “C:\YourApplication.MSIX”
But it will fail. Add-AppProvisionedPackage does not work like Add-AppPackage; the parameters for this cmdlet are a bit different.
Here, the -path parameter "Specifies the full path to the root directory of the offline Windows image that you will service" as stated in Microsoft documentation.
To provision an MSIX per machine, this is the command to use:
Add-AppProvisionedPackage -online -packagepath "C:\temp\Sample App-x64.msix"-skiplicense
You might ask why the -online parameter?
Well, the -online parameter "Specifies that the action is to be taken on the operating system that is currently running on the local computer", according to Microsoft documentation. If you don’t use this parameter, you have to use the -path parameter and specify the location of a mounted Windows image
Also, when you provision a package, this cmdlet will inform you that a license must be specified. If you don’t have a license, you can use the -skiplicense parameter.
This cmdlet only works when running it from an elevated command.
After you provision an MSIX package, this will appear on all users after the first sign-in on the machine. If a user is signed in while you provision the package, he does not have to sign-off and sign-in again, the package will be provisioned instantly.
How to Remove MSIX for All Users
So now that we have managed to provision MSIX for all users, how do you get it down for all of them?
Let’s say that you need to move away from your legacy antivirus software. Or you just installed the wrong app to a test group of users. Or your group policy doesn’t allow anymore a certain software product in your network. You need to remove it asap.
The process is a bit simpler because the Remove-AppPackage cmdlet has a parameter called -AllUsers.
Now that we have provisioned our sample package for all the users, we can remove it using:
Remove-AppPackage -AllUsers -package "AdvancedInstaller.SampleApp_22.214.171.124_x64__r21n0w1rc5s2y"
The removable package name is composed of Vendor.AppName_Version_Build_Hash, where Build can be neutral or X64.
A few things to consider
While the above methods might work and can help you provision/remove your package on a per-machine basis, there are some things you should consider before going on this route.
Let’s assume you have multiple users on one machine. There is the risk that the user who received the package decides to delete it. If a user deletes the package, the above provision command doesn’t cover the pushing the package again for the user.
In order to get the package back to the user, you have to execute the Add-AppPackage command, which installs the package only on that particular user.