MSIX Package Installations

Some general principles apply to all forms of MSIX deployments.

Upgrades and Downgrades

MSIX identifies packages via the package family name field of the package Manifest. For packages which use the same family name, the version string is also used for identification.

The MSIX installation process recognizes upgrades of newer versions, and will remove the older version when present automatically as part of the installation.

Originally MSIX did not support downgrades, however this was added to the OS support, and packages may now be similarly downgraded. To better understand this behavior the following table will illustrate some key points.

The first scenario in the table illustrates what would happen if the application needed to be re-installed in place. This sometimes happens to fix applications and is a supported action.

The next scenario shows an upgrade skipping application versions in-between. With MSIX the application upgrades do not need to be applied in sequence to upgrade an application.

In the next line we see the first consideration for changing the bitness of the application from 32-bit (x86) to 64-bit (x64) as a reinstall. This sort of upgrade or downgrade scenario is not supported as an reinstall. The new version of the application would be considered a completely new application installation that must be installed separately. The line below illustrates how the upgrade is possible between bitness but versions can also be skipped.

The last two lines illustrate the downgrade behavior, versions can be skipped in a downgrade plus bitness changes to the application are also supported.

Per User Installations

At the target system, MSIX package installations are performed on a per-user basis. This differs from traditional MSI and Exe based installers which supported the concept of either per-user or per-system installations.

Even though all installs for MSIX are per-user, MSIX does have something equivalent for the system level installation. MSIX packages may be pre-provisioned on a system-wide basis. This adds all of the package assets onto the system without performing the per-user integration aspects, and then registers a trigger that will complete the remaining installation integrations for the user whenever any user logs in. Such pre-provisioning is appropriate for adding MSIX packages to a standard image deployed to desktops.

Standard User Installation

Due to the isolation of the MSIX format and strict control over installation activities, including not allowing MSI Custom actions, MSI installs may normally be performed without elevation by a user with standard access rights.

The exception to elevation occurs if certain special actions are requested, exposed through the Capabilities settings of the AppXManifest. Currently only the inclusion of Windows Services requires this elevation.

When elevation is not required, all of the local system interfaces used to install the MSIX packages that are available to end-users, including PowerShell and the App Installer App, do not prompt for elevation.

While this simplifies software installation activities when using manual methods, it may also be of concern in the enterprise which depended upon authorized installations to ensure compliance with vendor licensing agreements, or to keep certain apps from only being accessed by authorized personnel that need access to the data exposed by the app.

Organizations making use of open file shares as part of the deployment processes may need to review and update their deployment procedures accordingly.

Machines can use Group Policy to restrict the installation of applications to only be from the Windows Store. Starting with Windows 10 1703 the policy resides in the following location:

Administrative Templates\Windows Components\Windows Defender SmartScreen\Explorer\Configure App Install Control

Beggining with Windows 10 2004 this setting moved to its current location: Administrative Templates\Windows Components\Windows Defender SmartScreen\Explorer\Configure App Install Control

To configure the policy, simply open a Group Policy editor and navigate to the policy and after opening it follow the instructions below:

• Enable the policy
• Select how strict to enforce Store apps
• Click OK to accept the changes.

Intune supports this configuration and would be best configured using a device restriction configuration profile. To access it go to the Endpoint manager console location.

When creating a new configuration profile be sure to create a device restriction profile using the following procedure:

• Change the platform to Windows 10 and later
• Edit the Profile field to be Device restrictions
• Click Create

In the App Store portion of the profile there is a setting labeled Apps from store only. Use the drop down menu to configure the Smart Screen settings for applications.

While this setting is helpful for locking down the application installs on the device it has an effect on administrator rights that may not go over so well in a production environment. By using this setting, the administrator of the device cannot install traditional Win32 applications if the configuration is set to Store Only.

For Intune managed devices starting with Windows 10 2004, the device can be configured to only allow local administrators to perform application management tasks. The user can still install from trusted sources such as the Windows Store or the Intune Company Portal app. A custom policy can be built in the Intune console for turning on this behavior.

To enable this configuration you will need to navigate to the Endpoint Manager console for Windows device policies.

Once there, you can create a custom policy to configure the setting.

• Change the Platform to Windows 10 and later
• Edit the Profile field to be Custom
• Click Create

After you have created the policy and supplied a name for it you can move on to the settings. When using custom policies there is the potential for error since many of the settings need to be manually inputted. As you can see with a new policy the contents are empty. Click Add to add settings to the profile.

To configure the custom setting follow the steps below.

• Give the setting a name
• Put in the OMA-URI (this is case sensitive) ./Vendor/MSFT/Policy/Config/ApplicationManagement/BlockNonAdminUserInstall
• Set the Data type to Integer
• Set the value to 1
• Click Save when complete

For more information on the BlockNonAdminUserInstall setting see the following Microsoft document.

Application Package Signing

Each MSIX package that you want to distribute must be signed with a code signing certificate that is trusted by the device or the installation will fail. This behavior (set by design) is meant to prevent untrusted code from being installed. While we covered the details on how to sign packages in the Digital Signing section of the Fundamentals chapter, those involved with deployment still need to be involved with digital signatures.

In particular, if you have a business requirement to distribute an MSIX package to people outside of your organization, make sure you obtain a code signing certificate for your package from a major certificate authority.

Otherwise, you can use your existing certificate server infrastructure to issue a code signing certificate from your issuing certificate authority.

It takes a lot of work to set up a code signing process for your applications and that can pose a significant problem when you prototype MSIX applications and need to be more agile. While signing your packages is the recommended best practice, there is another way to install MSIX applications without code signing.

In Windows 10, you can enable developer mode on the device which allows you to install unsigned MSIX packages. Many enterprise environments will not enable developer mode on production systems as a security precaution, so you may have to request a security policy exception to use developer mode on a device.

The key point is that there must be a valid code signing certificate that the device will use to trust the application. The application must then be signed using the same certificate to complete the chain of trust.

Ideally, in-house packages will be signed with a digital certificate that will be distributed to all appropriate organizational computers either as part of the base image or applied via PKI. MSIX Packages obtained from reputable third party vendors will most often be signed using a certificate obtained from a public Certificate authority, which might automatically be trusted by your PKI.

When the certificate is not trusted, it is still possible to add the certificate signature thumbprint to a system by right clicking on the MSIX file for properties. From the Digital Signatures tab it is possible (using elevation) to view and install the certificate on your system. The certificate must be placed in the “Trusted Root Certification Authorities” store of the Local Machine.