Over the years, we've received many questions regarding how Custom Actions work with PowerShell scripts in MSI.

Many of us are aware of the importance of securing our applications and how digital signatures are a solid way to avoid security breaches. For those looking into MSIX, you must know that Microsoft enforces digital signature for all packages within this technology. There is no exception.

Your application's installer is the very first direct interaction of users with your product. And, a positive first impression is essential for the success of any software.

Many applications keep settings or configurations in files that later get stored in per-user based locations, such as %appdata% or %localappdata% folders.

In this article, we will explore what happens during a Windows Installer registration and what are the repercussions that appear if you don't register your MSI during installation.

Applications often require different types of permissions to operate smoothly - so adding permissions to files, folders, and registry keys is a standard practice in MSI.

In my experience, CustomActions can be difficult to add and set up, especially in MSI, often requiring reviewing lengthy documentation or dealing with unexpected failures or bugs. If you started your career prior to the App-V and MSIX era, you have probably come across various applications installers that required reverse engineering work.

Up until 2020, Windows Services were not supported in MSIX -- which represented a blocker for organizations looking to transition their applications (that used Windows Services) to MSIX technology.

TL;DR: Let's put it bluntly, you should never set a CustomAction to “Immediate” when you intend to change the system state.

A firewall is a network security system that can be found on any modern operating system. It's purpose is to act as a barrier against network-based intrusions, to monitor and control incoming and outgoing traffic following an organization's predetermined security rules.

Release management and version control go hand in hand when delivering quality software, whether you are a solo developer or part of a development team.

Managing an infrastructure doesn’t only require updating software, creating OS deployments, or applying GPOs (Group Policy Object).

MSIX packages are installed by default per-user, and the option to provision per-machine MSIX applications is possible through SCCM - which is not yet available in Task Sequences.

Application Packaging itself is just a small step within the whole process, starting with the application being requested by the business, and resulting in a finished product that is rolled out to production devices.

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.

On a recent post, we explored how MSIX deployments are done via SCCM, covering the scenario when a per-user installation is needed.

Although it’s a rare scenario - you might run into the situation where you need to continue the installation of a certain application after reboot. We are talking about a silent installation that doesn't require admin rights or any input from the user.

We learned in How does Files Redirection work with MSIX that user data files, either from the project or created by executables, are automatically redirected to: %localappdata%\packages\PublisherName.AppName_hash\LocalCache.

In this article, we go through:

Lessons I have learned from making many mistakes in my enterprise software packaging newbie (and not only) years.