Our recommended practices for setting up the Microsoft MSIX Packaging Tool (or other installation capturing tools) include the following:

OS Image

• When capturing installers to repackage into MSIX, there is a high degree of compatibility when deploying to different operating systems as long as these recommended practices are used.  Traditionally, there was advice to either only capture on the same OS that the package will be deployed to, or to package on the oldest OS that you intend to deploy to. Today, we find that with a well-prepared OS image/snapshot, we can capture on any Windows 7, 10, or 11 version and successfully deploy the package to any of those OSs as the target, in both the forward and reverse direction.

This is in part due to the isolation technology in MSIX, but also with changes as to how Microsoft changes the OS in these versions.  But a good initial image is vitally important also.

• We recommend starting with a base OS image straight from Microsoft.  Often, organizations are tempted to use their existing corporate image, however this is a mistake.  

The capturing process only captures file and registry changes made by the installation and customization of the app.  Many installers contain common dependencies, and the installer will check for the dependency and install the dependency only if not present.  Your corporate image likely contains many common applications, such as anti-virus software, that also add common dependencies. 

This means that on capturing against the corporate image those dependencies are not included in the package.  And while your package may be fine on all deployment systems today, because they are also using the same corporate image, over time you may update the standard corporate image, and the new image might not include a dependency because either you changed out vendors or the vendor's new version no longer uses that dependency.  When this occurs, your existing packages will suddenly start failing on systems using the new corporate image.

• A recommended image practice is, with special exceptions, to not install anything that adds dependencies to the base image.

See the separate section on this document about DotNet Frameworks, DotNet Runtimes, and VC Runtimes.

• Another recommended image practice is to, as is best practical, disable software in the OS that updates things in this image. 

This includes both Windows Updates and App Store updates.

• Another recommended image practice is to not install anything in this image that may cause changes to the system without the user requesting it. 

This includes pushy agents like the SCCM agent.  Exemption from Management Systems that externally push out software is also recommended.  This often means also either not joining the system to the domain (or Entra) or ensuring that the instance is placed in a special OU that is exempt from such changes.

• Before taking the snapshot, ensure that the updates are disabled and that the NGEN queues are flushed. 

Unfortunately, disabling the Windows Update service does not keep it disabled any more.

Things added to the system that have .NET Framework components, including the .NET 3.x or 4.x Frameworks and monthly security updates to them pushed out by Microsoft, will routinely install the files and queue up the binary compilation.  If these are not completed prior to taking the snapshot, they may end up being compiled while you are in monitoring mode and end up in your package.  Or in all of your packages.  TMurgent has a convenient free PowerShell module named PassiveInstall that has a commandlet to flush these queues (there are up to 4 queues on your system).  And yes, it is safe to install PassiveInstall on your image as it adds no dependencies.

 

Snapshot with OS shutdown or running?

In most cases, either is fine, so there is no recommendation.  Obviously, you avoid some boot time by taking the snapshot with the OS running.

The exception that exists is that some third-party software that automates remote packaging might require the snapshot to be taken with the OS shut down.

 

Domain Joined or Not?

This is up to you and your environment.  If you can join the domain and control the things mentioned in the OS Image section, it is OK to be Domain Joined.  It can be convenient as you are typically needing to access file shares at least twice (one to get the installer and another to store the package), and possibly again during the installation and customization of the app.  Being domain joined could avoid a lot of prompts for passwords.

But if in doubt, don't join the domain.  This is the common practice is most organizations.

 

DotNet Frameworks, DotNet Runtimes, and VC Runtimes

These are dependencies that you may or may not want inside your package.  When inside your package, the package size is larger, but the app will probably work on every system.  On the other hand, these dependency components are frequently being updated (typically each month) for security updates.  Keeping them out of your packages ensures that if a CVE against them is fixed in the future, you only have to patch the OSs once and you don't need to worry about patching the applications.

The best way to avoid getting these into your packages is to include them in the OS Image of your capture snapshot, and to update that snapshot regularly.

The DotNet Frameworks (3.x and 4x) are typically pre-installed and kept out of the package.  Some organizations with very old applications might allow the capture of .Net 1.1 or .Net 2 Framework in the package because they do not want it regularly installed prefer to keep it in the isolation container. 

The DotNet Runtimes (5, 6, 7, 8, 9, ...) seem to be fine either inside or outside.  We don't find that there is a consensus on how to handle them, but most organizations default to external.

The VCRuntimes are generally kept outside of the package in organizations that are more concerned with security. 

The MSIX Schemas allows for some, but not all, of these dependencies to be marked as dependencies in the AppXManifest schema.  In some delivery scenarios, this will trigger the standard Microsoft Framework package to be installed on your system when the package is installed.  But in other delivery scenarios you may need to manually track the dependency. 

One challenge with this is that you need to know you have a dependency to add it to the AppXManifest, and by pre-installing those dependencies in the snapshot you probably won't know about the dependency.  When it comes to the VC Runtimes specifically, some organizations don't add them to the snapshot, in which case TMEditX will detect their presence in the package and offer to remove them and replace with the AppXManifest dependency.

 

Anti-Virus / Anti-Malware

Third-part anti-malware/virus software might interfere with the capture process.  Between changes made by those vendors, and improvement in exemption listing for the capturing tool, this is now considered rarely to be a problem.  If you stick with the Windows Defender software that comes in the base OS image, we know it does not cause an issue and by not installing the other third party vendor you don't add all of their dependencies, which we mentioned was a bad thing in the OS Image section above.

 

VFS Capture or Not

The Microsoft MSIX Packaging Tool (and sometimes others) offers a chance for you to add the path that the application installer will use.  It is not required that you do so.  In fact, we recommend that you do not fill in that field.

When you add that installation location in the wizard, any files written to or below that folder will be added directly to the root of the captured package.  Any files outside that area (or any files when you don't fill the field in) will be captured under the appropriate VFS path.  Those who performed App-V packaging will remember this as VFS versus PVAD style capture.

The Recommended Practice is to use VFS style capture for MSIX.  Although there were a handful of applications that required PVAD packaging for App-V (see Apps Needing PVAD – Confessions of a Guru), we have yet to identify any for MSIX.  Furthermore, we know that the Package Support Framework works best with VFS style packaging.

 

Application Installation Practices

The installation and customization of the captured application also has some recommended practices.

• Avoid Advertised Shortcuts from MSI based installers.

The purpose of an "Advertised Shortcut" is to allow the app to instantiate a self-repair.  In MSIX the package files are both isolated and immutable (meaning they cannot be changed), thus the app can't break in a way that that would trigger the self-repair, and the self-repair will itself fail to be able to act.  Furthermore, tooling like TMEditX cannot fix certain issues with Advertised Shortcuts are present. 

You can always add the parameter DISABLEAVTSHORTCUTS=1 to the msiexec command line of the install, whether or not the installer has any.

• Install all apps into "Program Files", or "Program Files (x86)" if at all possible.

Most installers will allow you to direct the installation into a folder under these. 

Some installers default to install to the user's profile - primarily so that end-users without admin credentials may install them, or background updates can occur without elevation.  We never need software to install into the user's profile as the primary folder for the application.  And those updates are a problem too.  Recommended Practices are to find a way to disable application updaters when possible.

Some installers default, or may even be hard-coded to, install to a folder off of the C: drive directly.  When possible, change this install location also.  Some PSX Fixups may have issues if you do not.

• Do you Launch the app in monitoring mode?

There is no Recommended Practice here.

For applications that contain license protection software that locks itself to the OS it is installed on, these tend to perform the locking on first launch.  So for those apps you cannot run the app while monitoring.

For some applications, it can be desirable to launch in order to perform things like accepting the EULA on behalf of the user, or making some configuration changes.

My personal recommendation is to not launch, but handle the personalization via scripted configuration.  This requires test-installing and configuring the application and then determine where (in the registry or file system) those changes are stored.  You then have your script perform the same actions directly to the registry or filesystem, possibly by exporting a file you keep with the installer to apply during monitoring mode after installing the application.

 

Make changes in the Capture Tool or TMEditX?

There are times that you have a choice of making a change to how the installer did things.  You can make the changes while in monitoring mode of the capture tool, in an editor provided by the capture tool before saving off the package, or in TMEditX.

The Recommended Practice is to, when feasible and reasonable, make the change as early as possible.  Making the changes in monitoring mode is usually the best.  Especially if you script the change so that it is automated for the next time.  When you routinely script both the installation using silent or passive installation techniques, and script the post-install pre-configuration and customization, going back to adjust the script and repackage takes very little time.  It is also instantly documented.  You do document this stuff, right??? 

 

What about Package Cleanup?

Package cleanup is an absolute must when repackaging into MSIs, but not as much when repackaging into MSIX due to the isolation and how the MSIX install works.

Still, the Recommended Practice is to clean up common things that are not needed.  This keeps the package smaller and prevents TMEditX from trying to fix broken things that some from background activity that might have been accidentally captured.

The Microsoft MSIX Packaging Tool (and most such tools) include customizable exclusion lists for file and registry paths.  TMEditX has one also, and this is normally the first thing done when you start fixing the package. 

It can be challenging to keep the MSIX Packaging Tool list up to date.  Part of it is that you always revert back to the snapshot.  The other is that with multiple packagers you can't really export/import if you also have the tool sign the packages.  So letting the packaging tool do a partial first pass and keeping the up-to-date master list in TMEditX is a better way to do this.  TMEditX is normally not placed on the packaging VM but on another persistent image, such as the packager test system for the "smoke test".  It also has an export/import function that is independent of the code-signing configuration.

Microsoft is constantly making changes to the OS in Widows 10 and 11 that change the location of background activity, so updates to the list are often needed every time you patch of capture OS image.  In TMEditX you can right-click on a file or registry item and add it to the removal list, and then remove the item from this package.  If you have multiple packagers, after completing the package remember to export the updated list and share with other packagers.

It is a Recommended Practice that everyone in your organization that is packaging use the exclusion same list!

 

Do I have to use the Microsoft MSIX Packaging Tool for TMEditX to fix it?

You need to use a tool supported by TMEditX...  No, I don't have a formal list.

It is important that the incoming package be formatted similarly to how Microsoft does it.  Some third-party vendors use the Microsoft tool behind the scenes so with those you are OK.  Some others we partner with, so we have them covered as well.  We can even handle packages from Advanced Installer, although we generally have to rip out their PSF and add ours in.

 

MMPT Capture Tool Configuration Recommendations

Configuration changes we recommend for the Microsoft MSIX Packaging Tool include:

• Uncheck the "Enforce Microsoft Store requirements" checkbox.

This enables you to use all four fields of the package version.  Microsoft reserves the last field only for packages to be uploaded to the Microsoft Store, and we are guessing that you are NEVER going to do that!

• Add your code signing to the configuration.  The exception would be that if you plan to run every package through TMEditX without testing first, then you can skip signing in the capture tool.  We personally think running them all through makes sense as the default, but some customers disagree.
• Service Exclusions:  We aren't messing with them yet.
• File Exclusions:  Make sure "Local AppData" isn't excluded.  You also might want to remove "Personal" if you package anything that drops files into the Documents folder that you need captured.

 

Specifying the Installer in the Wizard

We recommend not typing in the installer and arguments for the application installation into the MMPT Wizard.  Just get into monitoring mode and browse to the installer or command prompt.

It is also generally not necessary to copy the installer to the local system to install.