- Join Windows 11 to an Active Directory domain - Thu, Jun 1 2023
- Change Windows network profiles between public and private - Wed, May 24 2023
- How to map a network drive with PowerShell - Wed, May 17 2023
For many years, MSI has been the standard format for installation packages on Windows. However, many applications also come with an EXE setup. With the Microsoft Store, Microsoft has introduced APPX packages that developers use to deliver their UWP applications.
Additional complexity due to multiple formats
This diversity has some disadvantages. For example, admins must package EXE installers as MSI for distribution via GPO. In addition, Win32 applications that are available as EXE or MSI cannot be distributed via the store. The Desktop Bridge should solve this problem, but it requires access to the source code of the programs and is therefore aimed at developers to repackage their applications.
MSIX not only establishes a common format for all types of applications (Win32, UWP, WPF, and Windows Forms), it also takes advantage of the achievements of modern packaging and deployment that Microsoft introduced with APPX and UWP.
Separation of app and operating system
In particular, one such achievement is that applications are no longer installed in the conventional way; instead, they run in a container. This container virtualizes the registry database and parts of the file system so that the installation and execution of software does not change the state of the OS.
One advantage of this approach is that applications can be installed at a higher success rate (Microsoft speaks of 99.96 percent) and removed without leaving any traces. In addition, shielding applications from important OS components increases security.
If the MSIX concept reminds you of App-V, you are not entirely wrong. It's easy to imagine MSIX as the next generation of application virtualization. The two formats have in common that not all applications can be packaged in this way. This is especially true for those who want to install a driver.
Differential updating
Since MSIX is focused on distributing software over the cloud, another requirement was to keep bandwidth consumption low. Therefore, this format allows differential updates that are limited to the changed blocks. In addition, apps can share files so that they only have to be stored once.
Installation per user
As with store apps, the installation is preferably on a per-user basis. End users therefore do not need administrative rights to install MSIX packages. However, an app can be integrated into the system image before Windows is installed to speed up deployment.
This approach also has some disadvantages, though. For instance, apps cannot easily be started in the context of another user (with elevated rights) via runas. If the app for the other account has not been installed, the execution will fail.
In addition, MSIX is officially compatible with mechanisms for whitelisting, such as Windows Defender Application Control or AppLocker. However, it is common practice to block executables launched from the user profile. User installers are opposed to this because these applications will no longer run if a path rule for %userprofile% is set.
Migration of existing applications
To increase acceptance of MSIX and accelerate its distribution, Microsoft is lowering the hurdles for converting existing applications. Unlike the repackaging of Win32 programs as APPX with Desktop Bridge, access to their source code is no longer required.
Applications can be published as MSIX by the developer or subsequently converted into this format
Instead, Microsoft offers its own MSIX Packaging Tool to repackage MSI, EXE, App-V, or your own setup scripts as MSIX. In addition, manufacturers such as Flexera or Advanced Installer offer their own more powerful products for this task.
Repackaging of applications with the MSIX Packaging Tool, in this example of Notepad++
As a further measure to increase adoption of MSIX, Microsoft upgraded older versions of Windows to support this format. On the one hand, the required subsystem can be installed on Windows 10 1709 and 1803 (although this should no longer be important because of their limited life cycle).
On the other hand, Microsoft released a slimmed down version for Windows 7/8.x and Windows Server called MSIX Core. It lacks the container feature, and as expected, no apps that use specific functions of Windows 10 will run on it.
Distributing MSIX
Microsoft provides a whole range of options for distributing applications as MSIX in organizations. These include classic tools for this task, such as SCCM (now called Endpoint Configuration Manager) and Intune.
Since MSIX is part of Microsoft's strategic concept of "modern management," traditional software distribution no longer plays a major role. This is also reflected in the fact that MSIX packages can no longer be installed via group policies.
Like the mechanisms of modern PC management in general (Autopilot, MDM), MSIX also reduces dependency on a local Active Directory. This is especially true for the self-service options for MSIX installation.
This naturally includes app stores such as the Microsoft Store or the Store for Business. In addition, companies can simply set up a web server and register the MIME types application/msix or application/msixbundle. You can then offer to download the apps via an HTML page, where the URIs in the links must begin with ms-appinstaller:?source=.
Such a solution is ideal for BYOD scenarios where companies usually cannot install an agent for a client management system on the end device. In this context, the app containers from MSIX also prove to be particularly advantageous because the operating system remains unchanged and the apps can be completely removed.
Installing Notepad++ via the MSIX installer after migrating to the new format
Additional options for the MSIX installation, which are primarily aimed at admins, are DISM (for offline OS images) and winget. The latter is Microsoft's new tool for package management, which currently only offers a client for the command line.
Loading applications dynamically into the OS with App Attach
The separation of the applications from the operating system by the MSIX container is a feature that specifically meets the requirements of Remote Desktop Services. Incompatibilities arise primarily if programs write their configuration data to unsuitable areas of the registry or the file system.
Since programs do not store their configuration in the OS as in a conventional installation, you can also use MSIX to load applications dynamically into the system during runtime. This is the idea behind App Attach, which is included in Windows 10 2004 as a preview.
This feature stores apps in a virtual drive, similar to how user profile disks and FSLogix do for user profiles. These can be mounted in the running system as needed, so that the app contained in it is immediately available.
This feature is currently implemented in a prerelease version of Windows Virtual Desktop; you can also use the multiuser edition of Windows 10 for this purpose. So far, it is unclear whether MSIX App Attach will also be included for the Remote Desktop Services in the next version of Windows Server.
Conclusion
With MSIX, Microsoft tries to establish a uniform package format that decouples applications from the operating system. This should ensure higher success rates during installation and complete removal.
The execution in a container and the installation per user, which does not require elevated rights, are also important prerequisites for software distribution following the model of mobile devices. The new format also benefits the virtualization of desktops, where programs can be dynamically integrated with MSIX App Attach.
Subscribe to 4sysops newsletter!
The ability to migrate existing applications with the free Package Manager removes a major hurdle for switching to the new format. Admins should therefore expect to encounter more and more MSIX applications in the near future.
Is there more information on using MSIX with RDS/Citrix? I know the runas thing has burned me a few times already, and I absolutely hate that part. I am constantly running with two accounts (my login & a powershell session with my admin account).
And the managing the apps in RDS is a big deal – I want to be able to install them for all users and prevent users from installing their own, but the MSIX so far doesn't seem to offer much of a way to handle this. I can do a pretty decent job locking them down, but the fact is it's virtually impossible to *really* lock it down all the way (at least not without basically breaking most functionality).
Thanks!
David F.
but it failed. no one adopted it. not even microsoft did. microsoft has a lot of "friends", including the Chrome peeps, Spotify and Adobe. They couldn't even get them on board. why would anyone else use msix if not even microsoft is?
well said, thanks for this information.
Microsoft wanted to force developers to adopt archane ways of installatiin. Its always been a great OS except you needed high amounts of skills to make installers that in the end 99% really just copy a bunch of files to a folder and run it. Aweful from day one till today. Make MSIX make up for your past and fix this crap.
How can an operating system be great if the most important purpose of an OS, that is, the installation of applications, is technologically such a mess? The last good installer MS delivered was with MS DOS. Then came the Registry mess and with Windows 8 Microsoft somehow managed it to make it even worse. It remains to be seen if MSIX can clean up the mess that MS engineers created over the last decades.