The MSIX Shift. And why you should start preparing for it.

With App-V packages closing to end-of-life (2026), the reality of a transition to MSIX is much closer and many are starting to research the ins and outs of what it entails.
Although we now know that MSIX is not an update to MSI, but a completely new technology, there are still some correlations that we'd like to address.

In this article, we explore the changes brought up by Microsoft in the last two decades, from the origins of MSI to how they're now changing the game with MSIX.

MSI is the most used packaging technology currently, and we chose to focus on this particular one because we believe that the majority of companies will be transitioning using MSI technology as the starting point.

We will be diving into the transition challenges, providing options to overcome them, and doing a core comparison between both technologies.

For starters, let's jump right into the origins.

MSI: From Setup API to Windows Installer

Before the year 2000, Microsoft's only choice to install an application on the system was Setup API. Even at the time, Setup API was pretty limited, as it lacked some of the main features we were used to and reduced its options to performing basic tasks like handling files, registries, and outputting logs.

During that time, many developers didn’t even provide an installer for their applications.
Most of them opted for archiving software like ZIP or RAR, or third- party installer software (some of them already discontinued).

Little by little, Setup API turned into a rudimentary technology, which required Microsoft to step up to the game and provide developers with an enhanced technology to serve the packaging industry.

Innovating with Windows Installer

Fortunately, Microsoft listened and launched Office 2000, which included a new installer technology called Windows Installer version 1.0 - a huge improvement from its predecessor.

Windows Installer version 1.0 offered developers true control on how applications are installed on the system. With it, you could manage everything within the system: files, folders, registries, services, environment variables.

Better yet, you could add installation sequence custom actions - with GUI frameworks, automatic generation of the uninstallation sequence, rollback scenarios, and far better log files.

The installation packages are relational databases structured as COM Structured Storages, and we know them as MSI files.

Back in the 2000s, the technology was so ahead of its time that it left many of us baffled.
The latest version of the Windows Installer was 5.0, released with Windows 7 in 2009, which means that even today, 20 years later, we're using the same technology.

Changing the game with MSIX

As you can imagine, even if the technology was reliable, 20 years is a long time. In 2018, Microsoft announced a new packaging format called MSIX at Windows Developers Days.

As we mentioned above, after the announcement, many saw this as the future of MSI (the X era of MSI). Even the name creates a bit of confusion, as when we hear MSIX, we associate it to MSI technology and assume it is a new version with improvements - sort of the version 10 of MSI.

Surprisingly, this is not the case and it is far from how it works. To put it into context, let's go through each of the challenges I've encountered transitioning from MSI to MSIX.

Transition challenges

Don't get me wrong, MSIX is a great new technology that comes with useful new features:

• Containerized applications (including win32 executables)
• Microsoft Store deployments
• Easy integration within infrastructure management tools like SCCM or Intune
• Reliable installation (99% as Microsoft states)
• Network optimization through downloading only the 64k block

But like every new technology, it comes with some challenges that we need to get to know and overcome.

At least until it's widely adopted and people understand it enough to create workflows and set best practices, you need to account for an adjustment period.

So what are the current challenges for transitioning from MSI to MSIX?

1. Research and Training
2. Choosing the Packaging Tool
3. Certificate handling and mandatory digital signing
4. Going through pilot phases
5. Using Microsoft Store
6. Managing expectations
7. Focusing on Real-life scenarios
8. Planning ahead
9. Considering consultancy

It requires research and training

As it happens with all new technologies, tools, and processes, the first step to take when faced with it is to allocate the time to research it and learn exactly how it works.

Also, when transitioning, you will need to train all the professionals involved in software packaging and deployments.

Keep in mind that MSIX is still an in-development technology, meaning that a simple “Training.doc” shared with others will not cover it.
People will actively have to stay informed of changes, new releases, and updates of this technology.

You can find materials to assist with training on Microsoft Blogs, the Advanced Installer blog, and a user guide we created.

You will need the right tool

As the popular quote says: "A man is only as good as his tools" - Emmert Wolf.

Before starting to implement anything, it is best to research which of the tools available fully supports MSIX management and select the one that best fits your needs.

Tools help you to organize and simplify the work when transitioning and migrating to MSIX.

To support the newest technology, Microsoft provides a free tool called MSIX Packaging Tool. However, this is limited to MSIX packages.

The first tool to support MSIX, though, is Advanced Installer - who was the launching partner of MSIX technology at Developers Day in 2018.

Certificate handling and mandatory digital signing

While MSI packages could be digitally signed, this step was optional, and often ignored or skipped.

With MSIX, digital signing is mandatory and packages will not install if they are not signed. This is a very important change to keep in mind when transitioning.

The digital certificates need to be created, and they come in three types:

1. Standard Code Signing certificate

Standard code signing certificates undergo standard organization validation.

Applications that are signed with standard signing certificates will need to establish a reputation.

2. EV Code Signing certificate

Among the added benefits of EV Code Signing certificates is that they provide an instant reputation with Microsoft Smart Screen.

EV Code Signing Certificates are SHA256 only.

3. Private Code Signing certificates aka test certificates

You can also use a test certificate to sign an application. The digital signature will be recognized only if the certificate is trusted on the machine.

It is also a common practice for large organizations to implement a private Certificate Authority or CA, internal to the organization, which provides the same features as public CAs, but it is only trusted within the organization.

You can purchase a Code Signing certificate from one of the Certificate Authorities listed below:

• Symantec code signing cert
• Certum EV code signing cert
• Entrust EV code signing cert
• GlobalSign code signing certificate
• Sectigo (formerly Comodo) code signing cert
• DigiCert code signing certificate

Keep in mind that you should discuss how certificates are handled within your company or organization. Some questions to address include: "Will you give the certificate to each software packager and risk a security breach?" or "Will you use Azure digital signing?"

I recommend that software packagers use a test certificate to assess the test packages for quality assurance before a real certificate is used to sign them.

Going through pilot phases

Once the team has completed formal training, it's time to test repackaging applications.

Start with simple applications like Notepad++, VLC Media Player, 7-Zip, etc.

This way, it will be easier for people to understand and get a feel of how MSIX works. This also poses the opportunity for them to encounter scenarios where additional fixups are needed and helps as a learning curve on how to use them. Practice makes perfect and each repackaged application only builds more knowledge to the IT Pros.

Next, add them to the managed infrastructure tool, like SCCM, and start deploying them in small testing groups to see how they work.

Don’t assume that if an application works, the process should be changed for all of them. Test multiple applications and decide which ones are good for MSIX migration in the infrastructure.

Start small and don’t deploy MSIX packages for all of your users, alternatively let them decide if they want to use them.

Using Microsoft Store

Microsoft Store is a great way to distribute your application to the world. And it is also easy to implement in SCCM/Intune.

That allows for a straightforward way to get applications from the Microsoft Store and push them to the infrastructure. With a few simple clicks, you can search for the application, add it to SCCM, create an application in SCCM, and deploy it.

If you don’t want to use SCCM or Intune to deploy Store applications, you can always enable Microsoft Store for Business in your infrastructure to gain control over what applications are available to install from Store.

Microsoft Store applications are already signed by Microsoft, so you avoid the certificate headaches.

Unlike repackaged applications, Microsoft Store applications are guaranteed to work, and no quality assurance is required.
If you need to add any customizations, you can apply modification packages in the infrastructure later.

It's a good practice to perform an audit in the infrastructure to see if there are used applications, or useful alternatives present in the Microsoft Store.
Think of all the time you could save when repackaging if QA and UAT are out of the equation.

If you are a software packager, I wouldn't worry for the moment, I don't think that Microsoft Store and MSIX will entirely replace the MSI technology. The process will take some time and it’s up to the developers to place their applications in the Store.

Managing expectations

With MSI, customers were used to demanding only certain features, specific Start Menu structures, special customization scripts, and other custom requests.

MSIX doesn't support features, start menu structures, drivers, or similar specific options, so it’s important to take customer demands into consideration when starting to work on a repackaged application.

While customers don't need to know first-hand about the possibilities available within the technology, it's important to go through some key expectations and knowledge sharing about MSIX.
Each technical limitation must be clearly communicated to make sure time is not wasted on emails and calls on why something is no longer possible as it was in the past.

Focusing on Real-life scenarios

Pay attention to what happens in real life. For example, MSIX packages do not uninstall MSI packages. So what can you do about it?

Your first thought is to do a massive required uninstall rollout on all the machines to get rid of a former MSI and push the MSIX later on, right?

You could be right, but at the end of the day, it’s known that 100% compliance (especially in big tech companies) could never be achieved.
So you will end up with <1% of users with an outdated MSI application that could lead to a security breach. How do you address that?

The alternatives to massively switching to MSIX by pushing rollouts for the users are to consider an approach in batches or let the user choose when he needs a specific application.

You are the only one that has a comprehensive overview of the environment, access to the history of the app implementations, knowledge of the specific needs of each user or user profile, and first-hand understanding of business and operational objectives.
So, take into consideration all these factors and tailor your transition scenario to the one that best suits your unique situation.

Planning ahead

There are three possible solutions on how you can get an MSIX application:

1. The vendor does not provide an MSIX application

This involves taking the original sources, repackaging them, testing them, signing, and deploying the application in the infrastructure.

2. The vendor provides MSIX application separately from the MS Store

This is an easier scenario where all you have to do is create an Application in SCCM and push it to the users.

Also, check if the certificate used by the vendor to sign the package is also deployed in the infrastructure, otherwise, the application will not install.

3. The vendor provides the MSIX application in the MS Store

This is the simplest scenario of all because all the applications are digitally signed by Microsoft and the certificates are present on each Windows machine. The only steps are performed in SCCM to get the application and deploy it in the infrastructure

In either of the three scenarios, you have to have a plan on how to handle each request. If the customer does not specify or know if the application is in the Microsoft Store, it's a good idea to first have a look there to save time.

Considering consultancy

While in small companies, an audit and technology change is easier to perform, tech giants should consider third-party consultancy companies.

It’s hard to find that technical lead candidate that will learn, inform, and perform all the necessary tasks to handle the MSIX migration. In some cases, it may be best to talk with packaging consultants that have been in this industry for years and know their stuff.

Consultants have been working with MSIX since the very beginning, and have first-hand knowledge of possible issues and roadblocks as well as the most logical solutions to address them.

These are just some of the challenges I have either encountered myself or have seen my colleagues deal with. There are probably many others out there depending on the type of company and its needs.

In my ideal world, every vendor should test their application in MSIX and publish a notification on their website to let everybody know if it’s compatible or not. This will not only make things easier for the IT community but will also show the values of a company that adopts cutting edge technology and is open to sharing what they've learned with the rest of us.

Now that we've gone through the operational transition challenges, let’s get a bit more technical and make a core comparison between the MSI technology and the new MSIX.

MSI and MSIX: The Essentials

Managing MSI and MSIX concurrently will be the normality. It's time to get used to it.

MSI Outline

As previously mentioned, MSI packages are relational databases. Because of that, you have to follow strict rules and logical structures to ensure the success of a package installation.

If we start to deconstruct all the MSI technology, it would take a while - we have been working on our user guide for years in order to explain how everything works. So for the purpose of this article, we're going to analyze some of the core functionalities.

Identifying MSIs

MSI packages are identified using a unique PackageCode. Windows Installer does not allow two different MSI packages with the same Package Code to be installed on a machine.

The ProductCode is used to uniquely identify a particular product release. Windows Installer allows only one program with a given product code to be installed on a computer at a time. It prevents the installation of a second MSI with the same Product Code.

The ProductVersion combined with the ProductCode allows us to upgrade the packages and keep an upgrade logic.

Data placement

Moving from detections and identification of specific MSIs, let’s jump to the actual installer logic.

MSI packages are built on Features and Components. Everything that is performed in an MSI (except Custom Actions) should be present on a Component, which in turn should be included on a Feature.

The logic behind it is: If you offer multiple features for your users, the users can choose which feature of the application they want to install on the system. Every feature will have its components. Information including files, folders, registries, etc, can't be placed on features, only within the components.

Components can contain files, folders, COM components, registries, and shortcuts. Each component can be seen as a unit, and Windows Installer can't install just a part of a component, it has to be installed as a complete unit.

MSI packages also rely on Key Paths. Like in any other database, you can pinpoint what file or registry is critical for each component. When you launch an MSI-based application, Windows Installer checks the existence of the key paths on the machine, and if something doesn't match, the related feature is reinstalled. We call this feature self-healing.

Execution

MSIs have specific sequences on how they change the system and there is a specific order for operations. You can always change/add/remove operations, but by default, every MSI should have a defined order of operations.

To simplify things, we can divide the operations into two phases, the user interface phase and the execute phase.

In the user interface phase, the user gets the installation wizard GUI and basic queries are made on the system. These queries are usually detections for older products (e.g. detecting if the product is already installed).

The GUI offers the user the possibility to change options that affect the MSI during the execute phase. This can include feature selection, target directory, EULA acceptance, and other custom dialogs that can be added.

The execute phase starts when the user clicks the install button. At this point, the user should have customized the installation to fit specific needs, and all the information is sent back to the Windows Installer, to select the features/components that need to be placed on the system.

The execute phase only displays a progress bar and executes in two steps, immediate and deferred.

When placing custom actions or system changes, these should not be set during the user interface phase because the MSI can be installed silently, which bypasses this phase. Also, the user interface sequence runs with user privileges, not elevated.

Custom Actions

There are many cases when the standard operations can't deliver what the developer intends to, or further changes need to be made to the OS. For that reason, Microsoft added the ability to use Custom Actions, so you can interfere in the sequences.

Custom Actions can be DLL, EXE, VBScript, JavaScript, or Powershell. They can be executed anytime during the installation sequence, both in the user interface phase and the execution phase.

However, Microsoft does not offer a rollback solution for them, so additional Custom Actions might be needed in the scripts. To put it into context, if an installation fails or the application is uninstalled, the packager will need to implement an additional Custom Action to delete the copied file.

Transform files

To avoid changing the original MSI database, you may want to generate a transform file to contain the performed changes.

IT Pros use transforms to avoid any direct changes on vendor MSIs. The GUIDs and logic of the installer must remain as close as possible to the vendors in order to not break essential installation logic. Keep in mind specially that installation logic is crucial during an upgrade process.

The transforms are files that tell the original MSI exactly what needs to be changed during the execution.

Transform files can't be installed separately from the MSI, as they are still dependent on the native MSI package - they will need to always be present during the installation.

Here is an example of how a transform file should be called:

Uninstall Cleanup

During uninstall, MSI removes all the files and folders that are defined inside of it. But application files from AppData and registry entries the app created during its lifetime are left on the machine.
This is the standard setting unless the IT Pros decide to use custom actions to clean the system (which in most cases doesn’t happen).

This characteristic could be a downside of the MSI since it is considered that it pollutes the system with “garbage” and doesn’t have a good cleaning mechanism.

ICE validators

Such a complex technology as MSI makes room for human mistakes that can lead to the inability to install or uninstall a specific application.

For that reason, Microsoft provided a set of Internal Consistency Evaluators (ICE) used to detect potential issues inside an MSI database.

To sum up MSI specs

MSI is a great technology provided by Microsoft that stood the test of time. With Windows Installer, you can perform any change you want on the system, but there is a huge learning curve.

With the explanations above, we haven’t even scratched the surface of Windows Installer technology, and if you are new to the business, we really recommend going over our user guide to get a broader overview of how everything works.

MSIX Outline

In 2018, Microsoft presented MSIX as an improved version of the AppX packages (initially used only for UWP apps). This technology is meant to better support traditional desktop applications on Windows 10 and brings along the knowledge from MSI, App-V packages and the Desktop Bridge program.

So what are AppX packages?

AppX packages are an installer format that was introduced with Windows 8 in 2012.

Also, these were the first type of applications that could be published to the Windows Store. In order to publish, the developers must reserve the name, list advanced features of the application, and specify the selling details (price).

An MSIX package is very similar to an AppX or App-V package, structure-wise. It is basically a zip package that contains your application files and some configuration XML files.

The main difference MSIX brought is its extended support for Win32 applications, i.e., the standard desktop applications that are still used today.
This allows you to package a normal desktop application and publish it to Microsoft Store or simply offer it for download from your website while leveraging all the advantages from the modern Windows APIs.

Like with MSIs, we can talk about MSIX for a long time, but let’s make a short description of how they actually work.

Identify MSIX

Unlike MSI, MSIX does not come with a PackageCode or PackageCode. All the information is stored in the AppxManifest.xml.

This XML file is the package manifest and has to be present in any package. It contains the information defining the application and its features.
All of this information is used by the system to install/uninstall, update, and control the app’s behavior during its lifetime.

This file is usually generated automatically by the tool building the MSIX package, be it MSIX Packaging Tool, Visual Studio, Advanced Installer , or others. You can also create it manually, but it is not recommended.

The contents of the file should follow the schemas imposed by the OS , but these may differ between major Windows 10 updates, therefore it is very important to know what OS versions you’re targeting with your app, otherwise, you might end up with using features that are not available for all users.

MSIX identification is done by setting a package Name, Publisher, Version, and Architecture.

For example, two packages with the same Name, Publisher, and Version can be installed if the architecture is different.

However, once a name and a publisher have been selected for the package, they cannot be changed - otherwise, an upgrade of the previous version will not be detected and will not be applied.

Data placement

MSIX can be seen as a zip file that contains all the files, folders, and registries necessary for the application, but also additional files that define how the application works.

The above image shows a common and minimal MSIX package layout . You can see these resources if you extract the package using makeappx.exe or tools like 7-zip.

Assets As the name implies, this is where you will find all the app’s graphics assets.

VFS This folder normally contains the app’s binaries, DLLs, EXEs, config files, and so on. Read this article for more details. The VFS and Assets folder is also known as the app payload.

Registry.dat This file stores the HKLM registry entries of the app. Some packages also have per-user registry entries, and these can be found in User.dat or User.Classes.dat.

Resources.pri This file contains app resources, like localized strings and paths for additional resource files. Packages contain one file per language. Read more.

AppxManifest.xml This XML file is the main resource from the package, as detailed in the chapter above. It contains all the info required by the system to identify, install, and run the application.

AppxBlockMap.xml This is a file automatically generated that contains a list of all the app’s binaries and their hashes. The system uses it for integrity checks and when performing differential updates (lowering bandwidth usage by downloading only the changed files).

AppxSignature.p7x This file stores the digital signature information for the package contents.

[Content_Types].xmlThis contains information about the types of content in an MSIX package, used by the system at the time of installation.

Unlike MSI, you will not find any features or components to place the files, and the user has no control over them during the installation process.

The files, folders, and hash information are kept into individual files that are read during the launch of the application.

By default, files are stored in %ProgramFiles%\WindowsApps. Inside that folder, you will find subfolders for each app installed on the machine, including the OS built-in apps. All folder names follow the same pattern:

PublisherName.AppName_AppVersion_architecture_hash

To change the default location, check out the PowerShell cmdlet in our article here.

The registry is not placed directly into the system, because the app runs in a container like other virtualized applications. Instead, when the applications are launched, the MSIX registry is merged with the system registry in order for the applications to work.

To inspect a registry hive, you can use a specific PowerShell cmdlet , or use our free tool called Hover . Check out Registry in MSIX container- the quick way to inspect a registry hive to read more about it.

Keep in mind that unlike in MSI, drivers cannot be installed with MSIX.

Recently, Microsoft added support for services in MSIX.

Execution

While the MSI technology offered a way for the user to customize the installation, and maybe the application behavior (if the developers added custom dialogs), MSIX doesn't support this behavior.

In the past, with MSI, you never knew in an enterprise what specific customizations a user-selected during installation.
This led to complicated scenarios where IT Pros had to customize the software according to customer demands and install it silently for the users in order to have a grip on how the software should behave or how it should be installed.

With MSIX, these tasks are not directed to the IT Pros. All the customizations, EULA accepts, or any other tasks should be done during the first launch of the application.

Alternatively, those settings should be placed directly into the package, thus reducing the time it’s needed to find how different settings are implemented into the package via the dialogs page or custom actions.

While MSIX has an installation GUI, this is a minimalist one that only offers basic information and an Install button.

With MSIX, you do not have sequences, and cannot control how different steps are performed during the installation.

Custom Actions

The addition of custom actions was a big deal with MSIs because the user had full control of what to do with an installation package.

However, with MSIX, custom actions are no longer present and not available to add in the package during specific sequences.

While you can't add them in the MSIX package per se, in the latest Package Support Framework , Microsoft added a script support that allows IT Pros to customize the app dynamically for the user environment.

The Package Support Framework is a set of tools, libraries, documentation, and samples for creating runtime fixes (also called fixups). These are used to sort compatibility issues that enable Windows desktop applications to be distributed and executed as MSIX packaged apps.

Unlike in MSI, these scripts cannot be placed in a certain install sequence order , they can only run before or after the execution of the packaged exe present in the package. In short, these are not executed during installation - only when you launch or close an application present in your package.

The scripts are added to the config.json file which is present in the package.

The only type of scripts you can add are PowerShell scripts, and to allow these PowerShell scripts to be executed, the execution policy must be set to Unrestricted or RemoteSigned. This must be performed on both x64 and x86 PowerShell executables.

In Advanced Installer, you can add custom scripts to your MSIX package by navigating to the AppCompat page. Have a look at our tutorial about this.

Transforms

Modification packages are the equivalent of MST files (MSI transforms) from the old days. However, a modification package is not directly tied to a certain version of your main app, this means that you can update the main app and still use the old modification package.

It will allow IT folks from enterprises to customize MSIX packages they receive from ISVs or the ones they generate from older installers and prepare them for mass deployment . To fulfill this, you can use tools like Advanced Installer or the MSIX Packaging Tool.

A modification package has the same file extension as an MSIX package, but with slightly different content, you will find the biggest differences in the AppXManifest.xml file.

Note that it should have the same signature (CN) as the target package, or it will fail to install.

A modification package can't define app entries inside its manifest, it can only add new binaries as well as new registry entries to the main/target package.

Modification packages are not directly listed in “Apps and Features”, but you can find them if you access the “Advanced options” link for the target app.

Unlike MSI, modification packages appear separately, and the main MSIX is not needed.

Uninstall Cleanup

MSIX packages simplify the install and uninstall process by reducing machine clutter.

Due to its containerized model, uninstalling an MSIX package will also remove any files the app has created while running (under its AppData folder), including all the app files installed under %ProgramFiles%WindowsApps from the system.

The same thing will happen with the registries created by the app. This helps to maintain a clean machine state much easier and avoid known Windows Rot (aka Registry Rot).

Keep in mind that if the app also creates files in other non-standard (not recommended) locations on the machine, those files will not be deleted upon uninstallation.

ICE validators

While MSIX does not offer specific ICE validators like MSI does, Advanced Installer added a set of best practices for ICE that help you to make sure that what you are doing in the MSIX package is done correctly.

To sum up MSIX specs

At the core, MSI and MSIX are two different technologies. Everything from app identification, data placement, execution and other core functionalities are not applicable from MSI to MSIX.

Windows Installer packages are relational databases that operate through tables while MSIX are packages that operate through an XML file. A more practical side-by-side comparison can be found here.

So if the core of the technologies is distinct, what other differences are there for MSIX and what should you look out for when you create packages?

Other differences

Registry in MSIX

As previously mentioned, the registry in MSIX packages is stored in Registry.dat, for HKLM, and User.dat or User.Classes.Dat, for HKCU.

The hives are virtually merged at run-time with the registry found on the OS, to allow the app to “see” the entire registry as a singular unit.

For this reason, information like startup applications, file type associations, protocols, firewall rules, context menus, COMs, interfaces, and so on, are now kept into the AppxManifest.xml found in the MSIX package.

It’s not enough for this information to be present in the registry because, upon installation, this information is not seen by the OS and functionalities of the package are lost.

Auto-Updates for MSIX

MSI lacked a unified solution when it came to auto-updates. Companies implemented the checks for auto-updates either in the application itself, or used tools in the package like Advanced Updater.

With MSIX, Microsoft offers two solutions for this:

1. Publish the app on the Microsoft Store which gets updated automatically
2. Enable auto-updates for your MSIX packages without publishing your apps in the Microsoft Store by using .appinstaller files.

With the second solution, Microsoft offers the possibility for developers and IT Pros to specify a custom URL for the application sources and also the frequency of which this check is performed.

AppData Management in MSIX

To tackle the issue of remaining application data upon uninstallation, with MSIX, Microsoft redirects the files and folders which are created in %appdata% and %localappdata% to %localappdata%\packages\PublisherName.AppName_hash.

When an MSIX package is uninstalled, all the user data is deleted: the one that is imported from the package and the one created additionally by the application during its usage.

For a better comparison between appdata management in MSIX/MSI/APPV check out our in-depth article about this.

Active Setup and Advertised Shortcuts

With MSIX, all the AppData is kept in the VFS (Virtual File System) and it’s placed in %ProgramFiles%\WindowsApps\PublisherName.AppName_AppVersion_architecture_hash.

When you create a package with Advanced Installer, upon launching an application, the AIStub.exe present in the package copies the necessary appdata to the redirected locations mentioned earlier.

With this feature, there is no need to use the ActiveSetup or Advertised Shortcuts methods to deliver a file or registry to all the user profiles.

In the past, with MSI technology, these methods led to issues where the MSI sources were needed and were not accessible, leading to workarounds that had to be implemented by the IT Pros in order to fix this.

Shortcuts

In general, shortcuts are .lnk files that contain the path to the target, and optional arguments. These can be placed anywhere you want, but in general, with MSIs, these are placed in

        %ProgramData%\Microsoft\Windows\Start Menu\Programs.

However, a standard for shortcuts placement was not implemented for MSIs, and due to the fact that Microsoft gave vendors the option to place them however it was needed, this led to a disordered and cluttered Start Menu.

In MSIX, the notion of shortcuts is gone and these are now called Applications, which include an Application ID.

Applications are placed directly into the Start Menu, custom folders cannot be created like in MSIs, and the Start Menu entries are now managed via AppxManifest.xml.

You can read more on this topic in our article How to approach a Start Menu entry in your MSIX package? And what challenges are there?

Digital Sign

As consistently brought up in this article, Windows Installer technology did offer the possibility to digitally sign the packages, however, it was optional.

With MSIX all application packages must be digitally signed. There is no exception.

This brings an added layer of security which we can all agree is crucial nowadays. If the application is published to the Microsoft Store, it is automatically signed by Microsoft.
But, if this is made available on third-party websites or in infrastructure, the first step is to sign the MSIX application using a certificate from a trusted CA.

Read more on this topic in the article MSIX Digital Signing.

Conclusion

In conclusion, MSI and MSIX are very different technologies, and nothing you learned from MSI can be applied to MSIX packages.

They also serve a different purpose, because MSI actively modifies your system and installs applications natively on it, while MSIX is designed to run each application in its own container while not changing anything on the system.
So, in the end, MSIX is a containerized technology that can be better compared to a virtualized technology like App-V, rather than MSI.

But MSIX is still at its beginnings, and development is still in progress. While you cannot use drivers with MSIX, Microsoft did add services support in the latest Windows build (20H1).

There are many other differences that we didn’t cover in this article, but if you want to read more about MSIX and get a piece of more in-depth knowledge, check out our 24 chapter guide to MSIX article.

Also, subscribe to our blog to get application packaging industry news, and check our comprehensive user guide for updates.

Are you starting to research MSIX? Has your organization started to adopt it? Let us know in the comments.