One of these scenarios is when you are trying to figure out whether or not an outdated application exists on the fleet and which devices have this vulnerability. 

Microsoft knows about this and is about to make the job considerably less painful. So, it’s worth getting ahead of it before it lands in your tenant.

What is changing?

According to the Intune “In development” page, Advanced Analytics is extending its multi-device query capabilities to include Windows app inventory data. 

Right now, you actually can do multi-device querying, but only for hardware inventory. This lets administrators run a single Kusto Query Language (KQL) query across multiple devices at once instead of pulling reports device by device. 

The upcoming change brings that same fleet-wide querying to installed applications on Windows.

In practice, this means you will be able to write one KQL query and get back installed app versions, counts, and locations across your entire Windows estate in a single pass. 

Microsoft is stating that this will ease up compliance reviews, vulnerability tracking, and license tracking, but for anyone doing packaging work, the more interesting use case is a bit different because this turns app inventory into a drift detection tool. 

Instead of manually spot-checking devices to see who is running an MSI version 3.2 when you shipped 3.5 months ago or hunting for machines where competing MSIX packages of the same app that somehow both got installed, you can query for it directly and get a fleet-wide answer. This is quite a big shift from where things stood with the per-device version of this feature. 

We covered that earlier rollout in the article “Intune app inventory now surfaces MSI product codes and MSIX package names for cleaner packaging decisions,” which was genuinely useful for confirming product codes and package identities on a specific machine during troubleshooting. 

But that stopped at the device boundary. What Microsoft is describing now removes that boundary entirely. For packaging teams specifically, this will open up some concrete workflows once it ships. 

You will be able to identify stale MSI or MSIX versions that are still installed weeks or months after a new build went out or catch unmanaged apps where users or scripts installed something outside your Intune deployment channel. You can also build target lists for remediation based on actual fleet data rather than tickets and guesswork. 

It is worth noting that this feature is listed as “in development,” not the usual “what’s new” announcement, so there is no confirmed release date yet and details such as exact schema fields for the app inventory table could still shift before it ships. 

Of course, querying your fleet is only half of the story because once you know which devices have stale or duplicate packages, you still need to clean them so the problem doesn’t go away with a simple report. 

This is where PacKit helps with the automation side by keeping your MSI and MSIX builds consistent and properly versioned as part of your CI pipeline, so the fleet-wide inventory data you will soon be able to query reflects a controlled release process rather than a moving target.

Multi-device app inventory query will not replace good packaging discipline, but it does give you visibility you’ve never really had before: a single query that tells you exactly where packaging drift is happening across the whole fleet, not just on the one machine about which someone happened to file a ticket.

Once it is available, it is worth adding it to your regular cleanup routine along with your existing detection rules and update checks.

This is where tools like PowerShell App Deploy Toolkit (PSADT), Advanced Installer, and PacKit can help.

In a previous article, I tackled migration from PSADT version 3.x to version 4.1 and how that was a game changer in combination with Advanced Installer to overcome limitations.

In this article, I will go over the 4.1.8 release improvements and features (later currently available) for MSP patching.

TL;DR

• PSADT 4.1.8 simplifies MSP patching with automatic logging, multi-product code target matching, aligned parameters, and zero-configuration execution for MSI, MST, and MSP files
• With the upgrade to v4, you gain modular deployment, native SYSTEM context interactive prompts (no ServiceUI.exe) and internal logic automation that eliminates complex custom scripting

PSADT 4.1.8: Key Changes and Use Cases

MSP automatic logging 

Previously, using Start-ADTMsiProcess to install an MSI would automatically generate logs for the MSI installer but not for the patches that are called alongside it unless explicitly defined. 

Now, using the same Start-ADTMsiProcess with the -Action ‘Patch’ parameter will generate the same MSP log without the need to use -AdditionalArgumentList.

Here is an example of applying patches over the well-known Adobe Acrobat Pro:

Start-ADTMsiProcess -Action "Patch" -FilePath "$($adtSession.DirFiles)\AcrobatDCx64Updxxxxxxxx.msp"

Start-ADTMsiProcess -Action "Patch" -FilePath "$($adtSession.DirFiles)\AcrobatDCx64Updxxxxxxxx.msp"

If we go to the default log location C:\windows\logs, we can see all three logs generated there: the PSADT main log, the MSI log, and the MSP log.

Multiple Product Code Support

Before version 4.1.8, when you had a patch that applied for multiple product versions (let’s say a language pack in the form of .msp valid for 2025 and 2026 versions of an application), you would have needed to make sure you had any of the versions present on the machine before applying the patch. Otherwise, the script would return error 1642 and exit the installation.

This would have required a more complex if/else install logic similar to the one below:

$App2025 = Get-ADTApplication -Name 'Demo App 2025'$App2026 = Get-ADTApplication -Name 'Demo App 2026'
If ($App2025) {    Write-ADTLogEntry -Message "Found Demo App 2025. Applying patch..."    Start-ADTMsiProcess -Action 'Patch' -FilePath "$($adtSession.DirFiles)\SecurityUpdate.msp"} ElseIf ($App2026) {    Write-ADTLogEntry -Message "Found  Demo App 2026. Applying patch..."    Start-ADTMsiProcess -Action 'Patch' -FilePath "$($adtSession.DirFiles)\SecurityUpdate.msp"}Else {    Write-ADTLogEntry -Message "No applicable product found to patch."}   

$App2025 = Get-ADTApplication -Name 'Demo App 2025'$App2026 = Get-ADTApplication -Name 'Demo App 2026'
If ($App2025) {    Write-ADTLogEntry -Message "Found Demo App 2025. Applying patch..."    Start-ADTMsiProcess -Action 'Patch' -FilePath "$($adtSession.DirFiles)\SecurityUpdate.msp"} ElseIf ($App2026) {    Write-ADTLogEntry -Message "Found  Demo App 2026. Applying patch..."    Start-ADTMsiProcess -Action 'Patch' -FilePath "$($adtSession.DirFiles)\SecurityUpdate.msp"}Else {    Write-ADTLogEntry -Message "No applicable product found to patch."}   

Now, you can simply use:

Start-ADTMsiProcess -Action 'Patch' -FilePath "$($adtSession.DirFiles)\SecurityUpdate.msp" 

Start-ADTMsiProcess -Action 'Patch' -FilePath "$($adtSession.DirFiles)\SecurityUpdate.msp" 

Why? PSADT 4.1.8 does all the logic internally, searches for any available targetable MSI, and applies the patch. If no base MSI is detected, it will simply skip the patching and add a log entry in the main PSADT log with the return code 0 for the patch action and move forward with the script.

Aligned parameters for MSI and MSP

To clear up the confusion, Start-ADTMsiProcess and Start-ADTMspProcess cmdlets have aligned parameters, and using Start-ADTMspProcess standalone also automatically generates logs.

The complete parameter lists can be found here:

• Click here to see the Start-ADTMsiProcess list
• Click here to see the Start-ADTMspProcess list

Zero-Config Reliability

While this has been introduced since the early release of version 4.1, it was perfected in PSADT 4.1.8, and MSI is well integrated and supported within the script. 

Let’s take an example of a command that needed to be used before:

Start-ADTMsiProcess -Action "Install" -FilePath "$($adtSession.DirFiles)\AcroPro.msi" -Transforms "$($adtSession.DirFiles)\$transform" -Patches "$($adtSession.DirFiles)\AcrobatDCx64Updxxxxxx.msp" -AdditionalArgumentList "EULA_ACCEPT=YES IGNOREVCRT64=1"

Start-ADTMsiProcess -Action "Install" -FilePath "$($adtSession.DirFiles)\AcroPro.msi" -Transforms "$($adtSession.DirFiles)\$transform" -Patches "$($adtSession.DirFiles)\AcrobatDCx64Updxxxxxx.msp" -AdditionalArgumentList "EULA_ACCEPT=YES IGNOREVCRT64=1"

With PSADT 4.1.8, you take the PSADT template, place the .MSI, .MST, and .MSP files in the Files directory and then execute “Invoke-AppDeployToolkit.exe install.” You do not need to edit a single line of code.

Still on PSADT version 3.x? Things to consider when upgrading to PSADT 4.1.8

1. PSADT v4 has moved to a completely modular structure. This means upgrading from one version to another in the future allows you to simply drop in the updated module while keeping your .ps1 scripts, configuration files, and package assets are completely separate and intact.
2. The MSI and MSP commands are only a fraction of what the modern toolkit is capable of. The toolkit’s built-in logic saves you hours of scripting by allowing you to write a single line of code instead of relying on old-fashioned If/Else blocks, custom detections, and manual file searches.
3. No more ServiceUI.exe. If you need to display interactive prompts to a user while an application is deploying in the SYSTEM context (such as via SCCM or Intune), the v4 framework handles the session crossover natively. You no longer need to bundle or wrestle with ServiceUI.exe.
4. PSADT offers a v3 backward-compatibility template, so you don’t have to worry about having to rewrite all your existing v3 packages to work with v4. However, I highly suggest taking the time to modernize your code natively in v4. It will give you a much cleaner script and eliminate technical debt for the future.

Conclusion

PSADT matured well to version 4.1.8. 

The MSP and MSI features proved to be extremely beneficial in the enterprise world, especially for Application Packagers who do high-volume packaging with vendor-provided MSI sources, for Security and Patching teams who deploy patches frequently on large applications, and last but not least, for Level 3 Support and Troubleshooting who encounter incident tickets related to failed application and patch installation.

Did you know our tool PacKit has PSADT version 4.1.8 fully integrated? You can get it from here and try it for free. 

Speaking of PSADT, PacKit comes with a solid set of features built around it:

• Custom PSADT templates
• Digital signing support for PSADT scripts and detection scripts
• PSADT 3.x and 4.x support
• PSADT inline editor

Once a vendor ships a new build, you pull it down, repackage it, bump the detection rule, test it against your ring structure, and push it out before the old version becomes a compliance liability. 

However, in large infrastructures, you don’t have only one app. You have dozens of apps that every organization seems to standardize on, including browsers, PDF readers, communication tools, runtimes, and so on. 

Aside from the multitude of apps you need to constantly repackage, the problem you face is having a version tracking mechanism in place. 

Microsoft has been chipping away at this problem for a while with Enterprise App Management (EAM), which is basically a curated catalog of pre-packaged applications within the Intune Admin Center. 

However, this June, Microsoft officially announced that EAM auto-updates are now generally available, which means that managed apps from the catalog will move automatically from one incremental release to the next, for example, 4.1 to 4.2, without the need for an administrator actually touching a package or a detection script. 

Everything happens automatically in the background, giving your software packagers some room to breathe while also keeping your security in place with the latest updates, which usually cover some security exploits/issues. 

What Changes With EAM Auto-Updates?

Now, the term “auto-updates” gets thrown around loosely, so let’s understand what that actually means. 

EAM auto-updates only apply to applications in the Enterprise App Catalog, not custom Win32 applications that you have built and uploaded yourself. 

When an application in that catalog gets a new incremental update, Intune automatically advances it on your managed devices based on the update settings you’ve configured.

Microsoft frames this as a way to shrink the window of exposure to known vulnerabilities between full version upgrade cycles, which is a fair way to think about it. 

If you spend less time on mechanical repackaging, and an application spends less time sitting in an outdated, potentially exploitable build, it’s better for everybody, right?

For teams that maintain large Win32 catalogs in large enterprises, this slightly changes the calculations on what deserves in-house packaging efforts and what doesn’t. 

If an application support is in the EAM catalog and its packaging needs are generic, there is a decent argument for letting EAM handle it entirely and redirecting your packaging time toward the applications that actually need human judgment. 

When we talk about generic versus human judgment applications, I mean that in enterprise environments, applications must usually come already configured to the user. There are many applications where the auto-update feature is not simply disabled via an MSI Property, or there are extra configurations that the business expects to be already included in the package so that the overall infrastructure has a common ground in terms of configurations. 

Unfortunately, generic applications are simply applications with standard silent install switches, no custom transforms, and no special configuration layered on top, whereas the others are usually line-of-business software or anything that requires an MST or custom MSI properties, applications with dependencies that don’t detect cleanly out of the box, or anything where the organization-specific configuration doesn’t match the Microsoft default catalog build. This is where EAM doesn’t help anymore because the vendor install default is not good enough for your environment. 

Even in a world where EAM is absorbing more generic applications, tools like PacKit earn their keep. This tool won’t replace EAM’s zero-touch model, but it does cut down the manual overhead of the applications that stay under your control. 

PacKit reuses the silent install command line from the previous version when you are updating a package, so a new version bump doesn’t mean redoing switches from scratch, and it handles the .intunewin generation and actual push to Intune or SCCM from the same workspace, rather than being a separate manual step after packaging.

It also has its own WinGet-backed app catalog for the genuinely generic applications you don’t want to hand-build from scratch, which is a useful middle ground between fully automated with EAM and fully manual in-house for teams that want to keep everything in one deployment pipeline instead of splitting workflows between EAM and their own tooling.

PacKit recently introduced Package Manifest, which addresses a version tracking problem that is separate from EAM but similar in spirit: keeping the package metadata from drifting apart across systems. 

Instead of having detection rules, silent switches, uninstall commands, and deployment requirements scattered across installer files, spreadsheets, or internal wikis, PacKit stores that metadata as an open format alongside the package source in a “.packit” folder that acts as a single source of truth. 

It is also built to be used outside of PacKit through the free PowerShell module, so the same package definition can feed CI/CD pipelines, Intune workflows, or an internal repository without typing the same install parameters in five places. 

For a team maintaining a large catalog, structured and portable metadata is the more direct answer to less version-heavy packaging than auto-updates alone.

Three Things You Should Know Before Leaning on EAM:

There are some things that are maybe worth mentioning in this article. 

First, EAM is not free.

It is licensed per user and is separate from the base Intune subscription. It is worth checking current pricing before you plan around it, as Microsoft has been restructuring how these add-ons are packaged. 

As of July 2026, EAM and Endpoint Privilege Management will be integrated into Microsoft 365 E5, changing the cost equation for organizations sitting on E5 licensing but leaving it as a genuine line item decision for anyone on an E3 or standalone Intune plan.

The second is that Microsoft controls the catalog, not you. 

Applications are added to the Enterprise App Catalog, but some apps also may get removed from it, sometimes at the vendor’s own request.

That is a useful reminder that a catalog is a moving target over which you have no control and that any app your organization depends on heavily is worth a periodic sanity check against the current catalog list rather than assuming that “it’s in EAM.”

The third is that EAM is not the only solution for this. 

Patch my PC has been offering automated third-party update management for Intune for years, complete with its own catalog, customization options for pre and post scripts, and MSI transforms. 

Patch my PC is priced per device rather than per user. 

Patch My PC is the natural comparison point if you are evaluating whether to lean on the Microsoft catalog or keep more control in-house.

Why Packaging Still Matters

None of this eliminated the need for packaging. 

Versioning still matters for anything outside the EAM catalog, and it arguably matters more for the applications you keep in house, since those are now the exception rather than the rule and deserve a deliberate reason for staying that way. 

Detection rules still need to be accurate and specific, and rollback planning doesn’t go away just because updates are automated. 

Even for EAM-managed apps, keeping a ring-based rollout and knowing how to pin or hold a version if a release causes problems is still worth incorporating into your process.

Conclusion

EAM auto‑updates reduce the repetitive packaging workload for generic, catalog‑based apps, but they don’t eliminate the need for software packaging in enterprise environments. 

Auto‑updates keep popular apps current and secure, but they are limited to Microsoft’s catalog and have licensing, catalog‑control, and coverage limitations.

Packaging still matters for everything outside that catalog, such as apps requiring custom configs, transforms, dependencies, or organization‑specific behavior. Tools like PacKit remain essential for version tracking, metadata consistency, and streamlined Win32 update workflows. 

While EAM shrinks the generic workload, deliberate in‑house packaging continues to be the backbone of maintaining a reliable and predictable enterprise application ecosystem.

In this article, you’ll learn how to build a customized Oracle Client installation using a response file and how to implement it step by step.

What Is a Response File?

A response file is a configuration file that contains predefined answers to installation prompts. Instead of manually stepping through the graphical installer, you can use this file to automate the process.

The Oracle Universal Installer reads values from the response file and uses them to complete the installation either silently or with minimal interaction. When using the -silent option, installations can run without displaying GUI screens.

Why Should You Use a Custom Response File?

Creating a custom response file gives you full control over how the Oracle Client is installed. Rather than relying on generic installation switches, you can define:

• installation type (Administrator, Runtime, Instant Client, or Custom)
• installation directories (ORACLE_HOME and ORACLE_BASE)
• components and features
• system configuration preferences

Furthermore, once created, the same response file can be reused across multiple machines, making it ideal for enterprise deployments.

Step-by-Step: Creating a Custom Response File

1. Launch the Installer Manually

Start by running the Oracle Client installer (setup.exe) in interactive mode. This allows you to configure all installation options through the graphical interface. 

During this step, select your preferred installation type, paths, and components.

 2. Save the Response File

When you reach the Summary screen in the installer, click on “Save Response File”, name it something meaningful, such as Oracle19Client_Install.rsp. Save the file to your installation directory (e.g., C:\Downloads\Oracle19c_64bit\client).

This file will contain all the configuration choices you made during the setup process.

 3. Exit the Installer

After saving the response file, cancel and exit the installation wizard. You don’t need to complete the installation at this stage because your goal is to capture the configuration.

 4. Create a Silent Install Script

Next, create a command script to execute the installation using the response file.

For example, if you use the PowerShell Application Deployment Toolkit, your command line should look like this:

Execute-Process -Path "setup.exe" -Parameters "-silent -nowait -noconsole -waitForCompletion -ignoreSysPrereqs -ignorePrereqFailure -responseFile `"$dirFiles\Oracle19Client_Install.rsp`""

Execute-Process -Path "setup.exe" -Parameters "-silent -nowait -noconsole -waitForCompletion -ignoreSysPrereqs -ignorePrereqFailure -responseFile `"$dirFiles\Oracle19Client_Install.rsp`""

How PacKit Can Help You In This Process

While response files make Oracle Client installations easier, managing them across multiple applications, versions, and environments can quickly become complex. 

PacKit can be very useful in this situation.

PacKit is designed to help IT professionals manage, organize, and deploy application packages from a centralized interface. It bridges the gap between packaging and deployment, allowing you to standardize workflows and reduce repetitive tasks.

All you have to do is define the install and uninstall command lines:

Once that’s completed, you can use PacKit’s PSADT and Intune integrations to wrap your installer in PSADT, convert it into an .intunewin file, and upload it to Intune with just a few clicks.

Conclusion

By capturing your configuration once and reusing it, you can dramatically simplify deployments while maintaining consistency across environments.

Whether you’re managing a handful of clients or a large enterprise infrastructure, response file-based installations provide a reliable, scalable, and efficient solution for Oracle client deployment.

Final Takeaways

• A response file is a configuration file that contains predefined answers to installation prompts. Instead of manually stepping through the graphical installer, you can use this file to automate the process.
• The Oracle Universal Installer reads values from the response file and uses them to complete the installation either silently or with minimal interaction.
• Creating a custom response file gives you full control over how the Oracle Client is installed. 
• Rather than relying on generic installation switches, you can define installation type, installation directories, components and features, and system configuration preferences
• Steps on creating a custom response file: launch the installer manually, save the response file, exit the installation wizard, then create a silent install script
• PacKit can speed up the process: just define the install and uninstall command lines, then use the PSADT and Intune integrations to wrap your installer into PSADT, convert it into an .intunewin file and upload it to Intune

But in this article I want us to focus on something more fundamental: how WinGet gets into the OS and how to install it.

Installing WinGet on supported Windows versions

Before we jump into any kind of installation steps or instructions, we should note that WinGet is not a simple standalone executable you just download and run once. 

WinGet ships as part of the App Installer package, a system component that Microsoft maintains and updates through the Microsoft Store on desktop editions of Windows and regular Windows Updates on Windows Server 2025. This matters because it explains why WinGet might sometimes appear as “missing” even on systems that should support it and why the fix is rarely a traditional installer. 

WinGet is preinstalled as part of the App Installer component in Windows 11, a modern build of Windows 10, and Windows Server 2025. 

The minimum supported baseline is Windows 10 version 1809, which means that most machines today should have it the moment a user signs in because Microsoft Store registers the Windows Package Manager during that first login.

That registration part is probably what people misunderstand, and if you open a fresh VM, log in, and try to run WinGet directly, it will not work because the registration process has not finished yet. This takes place asynchronously in the background. 

If you don’t want to wait for that registration process, you can trigger it manually using PowerShell:

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe 

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe 

There is also a slim chance that App Installer is not already installed on your device. In that case, you can download it from the Store, which will also install the WinGet component.

However, there is another version of WinGet known as the “preview version” that is technically directed towards developers. 

This is basically the “Insider” program, which allows you to test new features before they reach general availability. You can get that version in two ways: either you install the latest WinGet preview version directly, or you sign up with your account for the Windows Insider Program.

WinGet is not available from the start for the Windows Sandbox feature. The whole purpose of Windows Sandbox is to offer a light desktop environment to safely run applications in isolation. However, that means it lacks a few things, one of which is WinGet. 

Microsoft offers a simple PowerShell script that you can run to install WinGet in a Windows Sandbox:

$progressPreference = 'silentlyContinue'Write-Host "Installing WinGet PowerShell module from PSGallery..."Install-PackageProvider -Name NuGet -Force | Out-NullInstall-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-NullWrite-Host "Using Repair-WinGetPackageManager cmdlet to bootstrap WinGet..."Repair-WinGetPackageManager -AllUsersWrite-Host "Done."

$progressPreference = 'silentlyContinue'Write-Host "Installing WinGet PowerShell module from PSGallery..."Install-PackageProvider -Name NuGet -Force | Out-NullInstall-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-NullWrite-Host "Using Repair-WinGetPackageManager cmdlet to bootstrap WinGet..."Repair-WinGetPackageManager -AllUsersWrite-Host "Done."

Conclusion

Getting WinGet running on a machine is usually simple since it rides along with the App Installer component and registers itself automatically on first login, but the moment you step outside that happy path, whether that’s a sandboxed environment, a locked-down image, or a desire to run preview builds, the process becomes a lot more deliberate. 

Knowing the registration command, the PowerShell bootstrap method, and the difference between the manual preview download and the Insider channel gives you the flexibility to get WinGet working reliably no matter what environment you are starting from. 

In a future article, we’ll look at putting WinGet to work for actual package installs and how it works with tools like Advanced Installer in a broader deployment pipeline.

TL;DR – Final Takeaways

• WinGet is included in the App Installer package, a system component that Microsoft maintains and updates via the Microsoft Store on desktop versions of Windows and regular Windows Updates on Windows Server 2025
• Winget is preinstalled as part of the App Installer component in Windows 11, a modern build of Windows 10, and Windows Server 2025
• The minimum supported baseline is Windows 10 version 1809
• Microsoft Store registers the Windows Package Manager during the first login, so if you open a new VM, log in, and try to run WinGet directly, it will simply fail because the registration process has not yet been completed. If you don’t want to wait for the registration process, you can start it manually with PowerShell
• If App Installer is not already installed on your device, you can download it from the Store, which will also install the WinGet component
• WinGet is not available from the start for the Windows Sandbox feature but Microsoft provides a simple PowerShell script to install WinGet in a Windows Sandbox

In this article, let’s talk about registry-based detection rules and the possible reasons why they fail in some applications.

How detection rules work in IME

Before we get into the reasons, let us first try to understand how things should work in IME. 

After installing a Win32 app, the IME immediately runs the detection logic configured in the portal. In terms of detection logic, it can be a registry check, file or folder checks, or a custom PowerShell script that is placed on each application. And this doesn’t wait. 

Once the installer returns an exit code, IME interprets it as a success or failure based on the exit code and immediately runs detection to confirm if the application is installed or not. 

The result of that detection is what IME reports back to the Intune portal, and if the installer exists cleanly with a return code 0, but the detection returns nothing, the deployment is marked as failed in Intune. 

The application can be fully functional on the device, but Intune will still display a red status because, from its perspective, the detection is the only source of truth.

Another thing to keep in mind is that IME runs in the SYSTEM context, which we will discuss later on in the article. 

Now that we understand how IME and detections work, let’s look at some of the most common reasons for detection failure when using a registry detection rule.

Causes of Intune Registry Detection Failure

Cause 1: The registry has not been written yet

So, keep in mind that for a detection check to run, the installer must pass a successful exit code. It could be 0, 3010, or you can define custom exit codes within Intune that IME will process as successful. 

Once this is done, the IME immediately fires the detection mechanism. However, some installers, particularly those based on EXE, may experience a slight delay. 

If you deploy a standard MSI, you won’t hit this problem because the Windows installer holds the exit code until the entire installation is complete, which includes writing all registry entries containing the Uninstall hive keys. 

By the time IME receives the exit code and runs the detection, everything is already there. 

The problem appears with EXE wrappers because EXE files do not follow any patterns. 

Vendors can ship an EXE that unpacks and launches an MSI or multiple installers in the background before immediately returning an exit code without waiting for the child process to finish. 

From IME’s perspective, the installation is complete, and the detection logic is activated, but the detection keys are missing because the installers haven’t finished processing in the background. 

The same thing can happen with chained installers, where the main executable finishes and the next one starts, and that secondary process is the one responsible for writing the registry keys you are using for detection. 

If you suspect this is your issue, the quickest way to confirm is to run the installer manually on a test machine and check the Task manager for child processes. 

This fix involves either switching to a custom PowerShell detection script with a short delay or finding a cleaner install switch that forces the EXE to wait for all child processes before returning. 

Here is an example of a PowerShell detection delay script:

Start-Sleep -Seconds 10
$key = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\YourApp" -ErrorAction SilentlyContinue
if ($key -and $key.DisplayVersion -eq "1.2.3") {    Write-Output "Detected"    exit 0} else {    exit 1}

Start-Sleep -Seconds 10
$key = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\YourApp" -ErrorAction SilentlyContinue
if ($key -and $key.DisplayVersion -eq "1.2.3") {    Write-Output "Detected"    exit 0} else {    exit 1}

Ten seconds is usually more than enough for a registry write to finish, but if Intune still reports a failed detection afterwards, you know it is not a timing issue and you should look elsewhere.

Cause 2: 32-bit vs 64-bit Registry

In 2026, the majority of the operating systems run on 64-bit hardware. However, it doesn’t mean that all the applications are created as 64-bit. 

32-bit applications do not write to HKLM\Software directly. Instead, they write to HKLM\Software\Wow6432Node, which Windows silently redirects them to via registry reflection. 

If you’re targeting a 32-bit installer and your detection rule points to HKLM\Software\YouVendor\YouApp, you won’t get anywhere, even if the key exists under WOW6432Node. 

When configuring a registry detection rule in the Intune portal, you can look for the “Associated with a 32-bit app on 64-bit clients” checkbox.

So, make sure to properly select the architecture of the application you intend to install. 

Cause 3: The System context issue

As previously mentioned, IME runs as SYSTEM (or NT Authority\System to be more precise). 

If your application has a detection method present in HKEY_CURRENT_USER, meaning this is a per-user installable application, when IME checks the HKCU, it won’t actually be the proper user’s HKCU, but the SYSTEM account’s HKCU. 

HKEY_CURRENT_USER is a redirection of the HKEY_USERS\USER_ID, where USER_ID is one of S-1-5-21-xxxxx-xxxxx-xxxx-xxxx.

In that case, IME will only look in the SYSTEM registry, not the current logged-in user’s. 

The solution is to either switch to an HKLM based detection path if the application writes anything there or to create a custom PowerShell detection script that manually loads the user’s registry hive. 

In the large infrastructure environments, per-user applications are usually repackaged to be targeted on a per-machine basis, and the detection works like a charm. 

However, if auto-updates are involved, switching to a per-machine solution won’t work because the application may not have sufficient permissions to update itself, or worse, install an update on a per-user basis while the per-machine one still exists on the machine. 

There is no “one size fits all” solution here because it all depends on the application’s context.

How to Diagnose Using IME Logs

When a detection fails or you have other errors with your application and can’t immediately tell why, the IME logs are the right place to start. 

You can find the IME logs at:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

This is the main log, and you will find all the necessary information for your application. This will display all the steps taken during the installation, as well as whether it failed or succeeded. 

If there is a registry issue, you will find entries showing exactly what path IME was looking for, what value is expected, and what it actually found or did not find. 

Conclusion

Intune’s detection logic is strict: IME trusts only the detection result, so any delay, wrong registry path, or SYSTEM‑context mismatch can cause a perfectly working app to appear as failed. 

Most issues come from EXE installers returning too early, 32‑bit vs 64‑bit registry confusion, or HKCU detections that IME cannot see. 

Clear detection design and checking the IME logs keep these problems easy to diagnose and avoid.

Final Takeaways

• After installing a Win32 app, the IME immediately executes the detection logic configured in the portal. In terms of detection logic, it could be a registry check, file or folder checks, or a custom PowerShell script that is installed with each application.
• Once the installer returns an exit code, IME interprets it as a success or failure based on the exit code and immediately launches detection to confirm whether or not the application is installed. 
• IME reports back to the Intune portal, and if the installer exists cleanly with a return code 0 but the detection returns nothing, the deployment is marked as failed in Intune.

TL;DR: Causes of Intune Registry Detection Failures and Solutions:

• The registry has not been written yet: if you suspect this is the problem, the quickest way to confirm it is to run the installer manually on a test machine and check the Task Manager for child processes before using a custom PowerShell detection script with a short delay or finding a cleaner install switch that forces the EXE to wait for all child processes before returning
• 32-bit vs 64-bit Registry: when configuring a registry detection rule in the Intune portal, select the “Associated with a 32-bit app on 64-bit clients” checkbox
• The System context issue: switch to an HKLM-based detection path if the application writes anything there or create a custom PowerShell detection script that manually loads the user’s registry hive

These pieces focused on how Intune decides whether an application needs to be installed in the first place. 

In this article, I’d like to also cover another scenario of a separate behavior that some people might not be aware of: what happens when you update the .intunewin file? 

What Happens When You Replace the .intunewin File?

If you are in testing or normal production mode and you have an application deployed and users who already installed it, you cannot simply replace the .intunewin file in the original deployment. 

Why is that?

In theory, you think it should work because Intune should notice that the deployment contents are different, right? Well, that is not the case, and to be honest, it’s the same approach that was with SCCM (MECM). 

The reason comes back to exactly what we discussed in the previous detection rules articles.

When the Intune Management Extension (IME) checks in on a device, it evaluates the detection rule for each assigned application. 

If the rule returns a positive result, indicating that the application is successfully detected, IME marks it as installed and moves on. It does not look at the version of the .intunewin file and does not compare timestamps or file hashes. 

The only thing that matters at that point is whether the detection condition is met on the local machine. 

So, if your detection rule checks for the presence of a registry key or a file path that already exists on the device because version 1.0 is installed, Intune returns “Installed” and does nothing else. 

There is a chance that the deployment with the updated .intunewin file will reach some users. 

However, these are the users who have not yet had the chance to install version 1.0, and if you change the .intunewin file before that happens, those users will receive version 2.0. 

In this case, you will have a bit of a headache because what happens to the detection method? 

If both version 1.0 and 2.0 are successfully detected, it means there is no way to export a report that says which version is installed on each machine. If the detection is different, users who receive the 2.0 .intunewin file will appear as “Failed” in Intune because the detection method will not work.

How to Trigger the Update?

If you continue to update the .intunewin file instead of creating a new deployment, the fix is quite simple: you need to change the detection rule to reflect something specific to the new version. 

This gives IME a condition that is not yet satisfied on devices running the old version, causing it to treat the app as not installed and kick off the installation process. 

In practice, this usually means that if you detect it using a registry value, update the version string your rule is looking for, or if you use an MSI product code, use the new GUID that comes with the updated installer. 

If you are detecting a file, you can point to a file or path that only exists in the new version, or you can check on the file version itself to see if no new files are placed in the updated .intunewin file. 

Once the detection rule change is saved and the devices check in, IME evaluates the rule, finds it unsatisfied on the machines running the old version, and queues the installation, after which the new .intunewin file is downloaded and executed. 

It is worth mentioning that if this is done, Intune will trigger the installation of the updated package on top of the old package (if your device already had it installed). 

If the old package is an MSI or EXE, you rely fully on the vendor logic. If your package is a complex script, you need to rely on the logic defined in your script.

However, keep in mind that Intune has a mechanism that prevents applications from being installed if they fail more than three times. 

If an application fails three times, IME enters a cooldown period before it tries again. There is a lot to discuss in this area, so I suggest you check out the separate article Intune Application Retries and GRS to better understand the mechanics behind it.

The Cleaner Approach

Regardless of whether you have a small or large infrastructure, the best approach is creating the new version as a separate application entry in Intune entirely rather than editing the existing one. 

This results in a clean deployment object that you can test against a small group first, validate, and then expand. 

You can also use the old version as a prerequisite or set the old deployment group as an exclusion on the new one, which prevents any device from accidentally receiving both versions at the same time. 

Once the rollout is complete and you have confirmed that the new version is installed, you can retire the old application in Intune and clean up.

Conclusion

The key takeaway is this: the `.intunewin` file is just the payload. Intune’s decision on whether to deliver that payload is driven entirely by the detection rule. 

Swap the file without touching the rule, and nothing changes for devices that already have the app installed. Change the rule to reflect the new version, and the update rolls out on the next check-in cycle.

It is one of those behaviors that makes complete sense once you understand how IME evaluates apps end to end, which is exactly why we covered that foundation in the earlier articles before getting here.

Final Takeaways

• When the Intune Management Extension (IME) checks in on a device, it evaluates the detection rule for each assigned application
• If the rule returns a positive result, IME marks the application as installed and moves on. If your detection rule checks for the presence of a registry key or a file path that already exists on the device because version 1.0 is installed, Intune sees “Installed” and does nothing further
• The fix is simple: you need to change the detection rule to reflect something specific to the new version
• Whether you have a small or large infrastructure, the best approach is to create the new version as a separate application entry in Intune instead of editing the existing one
• You can also use the old version as a prerequisite or set the old deployment group as an exclusion on the new one

Fortunately, the Intune Management Extension (IME) provides detailed client-side logging that helps understand exactly where an application deployment is failing.

The IME service logs every stage of the Win32 deployment workflow, including content download, decryption, installation, and compliance reporting. Understanding this client-side process is one of the most effective ways to troubleshoot Intune Win32 app deployments.

This guide walks administrators through the entire troubleshooting process for the Intune Win32 app and explains the most important log entries.

Understanding the Intune Management Extension Workflow

The Intune Management Extension is responsible for processing Win32 app deployments on managed Windows devices. 

During deployment, the IME handles:

• Detection rule evaluation 
• Applicability checks 
• Content download 
• Hash verification and decryption 
• Package extraction 
• Application installation 
• Post-install detection 
• Compliance state reporting 

The primary logs are stored in:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Detection Rules Evaluation

Intune Win32 apps use detection logic very similar to the SCCM (MECM/ConfigMgr) application model. Detection rules determine whether an application has already been installed before installation begins.

In this example, the detection rule uses an MSI product code. If the product is not detected, the log records:

This indicates the application is not currently installed and deployment should continue.

Detection failures are among the most common causes of Win32 deployment issues. Incorrect MSI codes, registry paths, or file detection logic often cause Intune to report a failed deployment, even if the application installs successfully.

Check Applicability

After detection rule processing, Intune performs applicability checks against the deployment requirements configured in the Win32 app.

The typical log entries include:

If any requirement fails, the application installation will not proceed.

Applicability checks are useful when troubleshooting situations in which applications never begin downloading or installing.

Content Download

When applicability checks succeed, the Intune client starts downloading the Win32 package content.

Downloaded content first arrives in the Incoming folder as an encrypted .bin file:

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming

The Incoming folder serves as a temporary download location before further processing begins.

After the encrypted package has finished downloading, the IME moves the content into the Staging folder.

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Staging

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Staging

Inside this folder, the package appears as a ZIP file:

This stage prepares the content for hash verification and decryption.

After decryption completes, the IME extracts the application files into the IME Cache folder.

The extracted installation files are now ready for execution.

Once extraction is complete, temporary content in the Staging folder is automatically removed. This cleanup helps to reduce unnecessary disk usage on the client device.

Application Installation

The next phase is the actual application installation.

During this stage, Intune:

• Sets the installation working directory 
• Launches the installer 
• Tracks process IDs 
• Monitors timeout values 
• Collects installation results 

Example log entries include:

If the installation fails, administrators should focus on:

• Incorrect install commands 
• Missing silent switches 
• Installer exit codes 
• Timeout settings 
• SYSTEM context compatibility

For EXE and MSI installers, we recommend setting log parameters. If the app is wrapped with PSADT, the default log directory should be “C:\Windows\Logs\Software”.

You can also check out this article: Top 10 Windows Installer Package Errors and How to Fix Them. 

Detection Rules After Installation

Once installation is complete, Intune reruns the detection rules to confirm the application installed successfully.

This final detection determines whether Intune reports the deployment as successful.

If the installer succeeds but detection fails, Intune may incorrectly display the deployment as failed.

Compliance State Reporting

After successful detection, the client sends compliance state information back to the Intune cloud service.

Example entries include:

Once the state message is processed, administrators can view the final installation status in the Intune portal.

If enabled, users may receive a toast notification confirming successful application installation.

Conclusion

Troubleshooting Intune Win32 apps is much easier once administrators understand the IME client-side workflow. 

The Intune Management Extension fully logs every deployment stage, including detection rules and applicability checks to content download, decryption, installation, and compliance reporting.

Administrators can isolate where deployments are failing and resolve issues more quickly by carefully reviewing IME logs and understanding the process behind them.

When packaging applications, important information is often spread across multiple systems:

• Installer files
• Detection rules
• Installation and uninstall commands
• Deployment requirements
• Documentation (Word, Excel, SharePoint, etc…)

As packages evolve, keeping all of this information synchronized becomes increasingly difficult.

The PacKit Package Manifest, aka fragment, addresses this problem by storing package metadata directly alongside the package source, in a folder called “.packit”. You can create this folder using the free edition of PacKit or the free PowerShell module.

The manifest acts as a single source of truth for the package and contains information such as:

• Application identity and publisher
• Installer configuration
• Silent installation parameters
• Uninstall commands
• Detection methods
• Platform requirements
• Additional deployment metadata

PowerShell PacKit Module

Although the manifest is currently used by PacKit, it is intentionally stored as an open format within the package structure, 100% under your control via de free PowerShell Module – https://github.com/Caphyon/open-package-manifest

This means the same package definition can be consumed by:

• PowerShell automation
• CI/CD pipelines
• Intune deployment workflows
• Configuration Manager integrations
• WinGet publishing tools
• Internal application repositories

The goal is to make package information portable, version-controlled, and accessible from any environment.

In-house Developers

Do you have in-house developers who package the apps without talking to admins? Just ask them to generate a .”packit” package manifest next to their setup and your Intune admins will have all they need to automate their deployment.

They can use the PowerShell PacKit module to build it no matter what tool they used to build their MSI or EXE setup.

Watch the webinar recording to learn more about the Open Package Manifest (OPM)

Looking forward

This is only the first step.

By keeping package definitions in a structured, portable format, organizations gain greater control over their application lifecycle and open the door to richer automation scenarios in the future.

We look forward to seeing what the community builds around the .packit package manifest.

Intune sends the app, the device installs it, and that’s where the story ends. However, the actual behavior is not as simple as you might think, so understanding it can save you from future headaches. 

So let’s jump into the article and learn about the behavior of the Win32 applications.

How Win32 App Installation Works in Intune

When Intune evaluates a Win32 app on a device, it follows a structured sequence managed by the Intune Management Extension (IME). 

The Intune Management Extension is not something found natively on every Windows OS. When the device is enrolled into Intune during the AutoPilot phase, Intune checks if the device has any policies to be applied. 

The MDM service then sends a command to download and install the IME, which happens silently in the background during the Enrollment Status Page (ESP) and is listed as IntuneManagementExtension under Services in the Task Manager. 

The IME installs the following features:

• PowerShell scripts
• Remediations
• Discovery scripts for custom compliance
• Win32 apps
• Endpoint analytics
• Remote Help
• Managed Installers in Intune
• Update Windows BIOS using configuration MDM policy

In terms of the sequence that IME follows, the unpopular but logical first step is to check if the application is already present on the device, which means that the Detection runs first. If this is already present, then there is no point in running an installer for software that’s already installed. If the detection rule is met, Intune marks the app as Installed in Intune and stops. During this stage, no installation command is executed and no requirement rules are evaluated. 

If the app is not detected, IME will then check the requirement rules. This is logical because we now need to evaluate the rules and check if any custom scripts, registry checks, disk space requirements, etc., are needed for the application’s installation. If any of the requirements are not met, the installation will stop.

The third step is to finally run the installation command. During this phase, the IME waits for the execution’s output code within a specific time frame.

Once the installation is complete, it is time to run the detection again to see if the installation was successful. This determines whether the app ends up marked as Installed or Failed in the portal.

This four-step flow is why a common scenario trips people up: if you create a new version of the app and deploy it, but the detection rule matches the old version that is already on the device, Intune will consider the application as installed and skip the whole process altogether. 

Even worse, your new application will be marked as Installed in Intune, which will make identification even more difficult. 

This is why it is important to think carefully about what your detection rule is actually checking. If you use a simple rule such as a presence of a registry key or folder without validating the version number, it will match both old and new installations equally. So, if you want Intune to distinguish between versions, your detection logic needs to reflect that.

Also, Intune distinguishes between “available” apps and “required” apps. Even if you update an app marked as available but the user has already installed the previous version, Intune will mark it as installed without actually pushing the new version. 

What is the solution? Have an updated version of the app as required, but include a requirement rule (old version must be present), and then deploy it to all devices or the specific group that was initially targeted by the “Available” app. 

Packaging tools that allow you to fine-tune detection scripts and requirement rules make this much easier to get right from the start.

PacKit, for example, is built around this kind of precision and lets you define exactly what constitutes a valid installation, ensuring that your deployment logic holds up in practice.

Conclusion

Intune’s Win32 app deployment follows a strict IME‑driven sequence where detection, requirements, installation, and post‑detection determine the final outcome. 

Because Intune always evaluates detection first, poorly designed detection logic can cause new versions to be skipped entirely and falsely marked as installed. Real-world application deployment requires precise packaging and version-aware detection rules to be reliable and predictable.

Final Takeaways

• When Intune evaluates a Win32 app on a device, it uses a structured sequence managed by the Intune Management Extension (IME)
• When the device is enrolled in Intune during the AutoPilot phase, Intune determines whether any policies should be applied. During the ESP, the MDM service sends a command to download and install the IME, which is then listed as IntuneManagementExtension under Services in the Task Manager.

Here’s the typical four-step workflow:

• Check to see if the application is already installed on the device, in which case the Detection will run first. If this is already present, there is no point in running an installer for previously installed software
• If the app is not detected, IME will check the requirement rules, and if any of them are not met, the installation will terminate
• Run the installation command. The IME waits for the execution’s output code within a specific time frame
• Run the detection again to ensure that the installation was successful, as this determines whether the app is marked as “Installed” or “Failed” in the portal

The Solution:

• Have an updated version of the app as needed, but include a requirement rule (the old version must be present), and then deploy it to all devices or the specific group that was originally targeted by the “Available” app
• Use PacKit, which is built around this level of precision and allows you to define exactly what constitutes a valid installation, ensuring that your deployment logic works in practice