← Back to Blog

MICROSOFT INTUNE • DEVICE MANAGEMENT

Deploying Win32 Applications with Microsoft Intune: A Debugging Deep Dive

SyncNebula Intune • Win32 Apps • Troubleshooting

When "Installation Successful" Doesn't Mean "Application Installed"

Deploying a Windows application through Microsoft Intune sounds straightforward: package the installer, upload it as a Win32 application, configure the installation command, create a detection rule, assign it to devices, and wait for the application to install.

In practice, the difficult part often isn't getting the installer into Intune.

The difficult part is making sure the installer, execution context, installation behavior, and detection logic all agree with each other.

I encountered exactly this while deploying UltraViewer to Intune-managed Windows devices in a Microsoft 365 E5 development environment.

The application eventually installed and worked correctly on both an Azure-hosted test VM and a physical Intune-joined device. However, getting there required debugging three separate problems:

  1. Intune reported that the application was not detected even though installation had apparently completed.
  2. The installer returned exit code 0 but appeared to install nothing.
  3. After fixing the installation, Intune still could not detect the application because the detection rule referenced the wrong executable name.

This article walks through the investigation and the techniques that resolved each problem.

The Lab Environment

The testing environment consisted of:

The objective was simple:

Package UltraViewer as a Win32 application and deploy it silently to Intune-managed Windows devices.

The troubleshooting process, however, revealed several important details about how Intune application deployment actually works.

1. Start With the Installer — Not Intune

Before creating the Intune application, the first thing I should have established was:

These details become extremely important later because Intune does not simply ask Windows to "install an application."

It executes a specific command under the Intune Management Extension and then uses detection rules to determine whether the desired application state has been achieved.

That means an apparently small assumption — such as assuming the installation directory or silent-install switch — can break the entire deployment.

2. Package the Application as a Win32 App

The UltraViewer installer was packaged using Microsoft's Win32 Content Prep Tool. The resulting package had the .intunewin format required for Win32 application deployment through Intune.

The general process is:

  1. Place the installer in a source directory.
  2. Run the Win32 Content Prep Tool.
  3. Select the installer as the source file.
  4. Specify the output directory.
  5. Upload the resulting .intunewin package to Intune.

The important point here is that packaging itself was not the problem. The package successfully reached the device. The problems appeared during execution and detection.

3. Problem One — Installation Succeeded, but Intune Said the App Wasn't Detected

The first major error was:

0x87D1041C

The message indicated that the application was not detected after installation had completed successfully.

At first glance, this was confusing. The installation command appeared to run successfully, but Intune still considered the application missing. This is where detection rules become critical.

What Was the Detection Rule Checking?

The original detection rule used a path based on:

%ProgramFiles%

The expectation was that this would point to the application's installation directory. However, UltraViewer is a 32-bit application and was actually installed under:

C:\Program Files (x86)\UltraViewer

The Intune Management Extension runs as a 64-bit process on 64-bit Windows clients. In this context, %ProgramFiles% resolves to the 64-bit Program Files location rather than the application's actual 32-bit installation directory.

So Intune was effectively checking the wrong location. The application existed. The detection rule simply wasn't looking where the application existed.

The Fix

The detection rule was changed to explicitly target:

C:\Program Files (x86)\UltraViewer

The option Associated with a 32-bit app on 64-bit clients was also enabled so that Intune would evaluate the detection rule using the appropriate 32-bit context.

The uninstall command was also updated to reference the 32-bit Program Files environment variable where appropriate.

Lesson: Do not assume that %ProgramFiles% represents the directory where every Windows application is installed. For 32-bit applications running on 64-bit Windows, verify the actual installation location before building the detection rule.

4. Problem Two — The Installer Returned Exit Code 0 but Installed Nothing

After correcting the detection path, another problem appeared. The application still wasn't being installed.

What made this particularly interesting was that the installer returned:

Exit code: 0

Normally, an exit code of 0 suggests successful execution. But the application wasn't present on the device. A drive-wide search of C:\ confirmed that the expected application files were nowhere to be found.

This meant the problem wasn't detection anymore. The installer itself wasn't performing the expected installation.

5. The Silent-Install Switch Was Wrong

The installation command was initially using:

/S

This was based on vendor documentation and the assumption that /S represented the installer's silent mode.

The problem was that /S is not a universal Windows installer switch. Different installer technologies use different command-line parameters. In this case, the UltraViewer installer was using Inno Setup.

The installer did not interpret /S as the required silent-install instruction. More importantly, it did not fail loudly enough to make the problem obvious. The command could return exit code 0 while still not producing the expected installation.

This is a dangerous situation for automated deployment because Intune can interpret the command as successfully executed while the desired application state has never been created.

6. Reproducing Intune's Execution Context With PsExec

This was the most useful diagnostic step in the entire investigation.

Instead of repeatedly changing settings in Intune and waiting for another deployment cycle, I wanted to reproduce the environment in which Intune actually executes the installer.

The Intune Management Extension executes application installations under the SYSTEM account. Using PsExec from Microsoft's Sysinternals suite, I opened a command prompt running as SYSTEM. From that shell, I manually executed the installer.

Instead of silently installing, the installer displayed its interactive installation wizard. It presented the destination-folder selection interface. That immediately explained what was happening.

The installer was not actually running silently. Under a normal interactive user session, a person could click through the wizard. Under Intune's SYSTEM context, there is no administrator sitting in front of the installation waiting to select a destination folder.

For an automated deployment, that interactive UI is effectively a dead end.

7. The Correct Inno Setup Parameters

The installation command was changed to use the appropriate Inno Setup silent-install parameters:

/VERYSILENT /SUPPRESSMSGBOXES /NORESTART

These parameters were designed for unattended installation and prevented the interactive wizard from appearing.

This was the turning point. The installer could now execute without requiring user interaction, and the application was actually placed on the device.

8. Problem Three — The Application Was Installed, but Detection Still Failed

At this point, the deployment appeared to be working.

UltraViewer was physically present on the machine. The application launched correctly. It could also be accessed remotely, confirming that the installation itself was functional.

Yet Intune continued reporting a detection failure.

This meant we had moved back to the detection stage. The installation was no longer the problem. The detection rule was.

9. The Executable Name Was Wrong

The detection rule was configured to look for:

UltraViewer.exe

However, the installed application actually contained:

UltraViewer_Desktop.exe

The difference was small enough to be easy to overlook but significant enough to make the detection rule fail every time.

From Intune's perspective:

"I checked for the file you told me to check for, and it isn't there."

From the administrator's perspective:

"But the application is installed and working."

Both statements were technically correct. The detection rule was simply looking for the wrong file.

The Fix

The detection rule was updated to target the actual executable:

UltraViewer_Desktop.exe

Once this was corrected, Intune could correctly identify the application as installed.

10. The Three Problems Side by Side

Problem Actual Cause Fix
Detection failed after installation Detection checked 64-bit Program Files instead of the 32-bit installation directory Use C:\Program Files (x86)\UltraViewer and enable the 32-bit app detection option
Installer returned success but application wasn't installed Incorrect silent-install switch Use the installer's actual Inno Setup silent parameters
Application was installed but detection still failed Detection referenced UltraViewer.exe instead of the actual executable Detect UltraViewer_Desktop.exe

The important point is that none of these problems required changing Intune itself. The deployment mechanism was working. The assumptions around the application were wrong.

11. The Intune Logs That Actually Mattered

When debugging Win32 application deployment, Intune generates a significant amount of logging information. Two logs — both under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ — were particularly useful for this investigation.

AppWorkload.log

This was useful for understanding:

When the application was installed but Intune continued reporting it as missing, this was one of the most useful places to investigate.

AgentExecutor.log

This was useful for examining the actual command execution. It helped answer questions such as:

What About IntuneManagementExtension.log?

The main IntuneManagementExtension.log can be useful for general troubleshooting, but in this particular investigation it contained considerably more general synchronization and extension activity than the two logs above. The most useful approach was therefore to focus on the logs closest to the actual application workload and command execution.

12. Useful PowerShell Checks

PowerShell made it much easier to verify what was actually happening on the device rather than relying solely on the Intune portal.

For example, the installation path could be tested directly:

Test-Path "C:\Program Files (x86)\UltraViewer"

The contents could then be inspected:

Get-ChildItem "C:\Program Files (x86)\UltraViewer"

To watch an Intune log while a deployment was being processed:

Get-Content "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log" -Wait -Tail 50

The same approach can be used with AgentExecutor.log:

Get-Content "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log" -Wait -Tail 50

During testing, the Intune Management Extension service can also be restarted to trigger another processing cycle: 

Restart-Service IntuneManagementExtension -Force

These commands don't replace proper Intune monitoring, but they provide much faster visibility into what is happening directly on the endpoint.

13. Don't Rely Entirely on Company Portal

Company Portal is useful because it provides an end-user-facing view of application deployment. However, it should not be treated as a real-time diagnostic tool.

The status shown to the user depends on the device's communication and check-in state. During troubleshooting, it was far more useful to combine:

Company Portal + Intune admin center + endpoint logs + direct filesystem verification

rather than relying on any one source. For example:

That combination tells a much more useful story than the Company Portal status alone.

14. A Better Deployment Workflow

The biggest lesson from this lab is that several hours of troubleshooting could have been avoided by validating the application before creating the Intune deployment. A better workflow is:

Step 1 — Install the application manually

Determine:

Step 2 — Identify the installer technology

Determine whether the application uses something such as:

Do not assume that a silent-install parameter from vendor documentation applies to every installer.

Step 3 — Test the silent command manually

Run the exact command that will eventually be used by Intune. Verify that:

Step 4 — Test under SYSTEM

Use a SYSTEM-context shell such as PsExec to reproduce the environment used by the Intune Management Extension. This is particularly important for installers that behave differently depending on:

Step 5 — Build the detection rule from reality

Do not build detection rules from assumptions. Use the actual:

that you observed on the endpoint.

Step 6 — Package the application

Create the .intunewin package and upload it to Intune.

Step 7 — Deploy to a test device

Use a controlled test group before broad deployment.

Step 8 — Validate from multiple perspectives

Check:

This workflow makes troubleshooting significantly more systematic.

15. The Bigger Lesson

The three failures looked unrelated:

Wrong path → wrong silent switch → wrong executable name

But they all came from the same underlying problem:

Assumptions were being made about how the application installed instead of verifying how it actually behaved.

This is particularly important when deploying third-party Win32 applications through Intune. Intune can only work with the information it is given.

If the installer command is wrong, Intune cannot magically correct it. If the detection path is wrong, Intune cannot know that the application is actually present. If the executable name is wrong, the detection rule will continue to fail even though the application is functioning perfectly.

Conclusion

Win32 application deployment through Microsoft Intune is not simply a matter of uploading an installer and selecting a deployment group.

A successful deployment depends on three things working together:

Installation command → Actual application state → Detection rule

If any one of these is incorrect, the deployment can produce confusing results.

The most valuable lesson from this troubleshooting exercise was simple:

Never trust assumed defaults for a silent installation. Verify them.

Install the application manually first. Find the real installation path. Identify the real executable. Determine which installer technology is being used. Test the exact silent command. Then reproduce that command under SYSTEM before deploying it through Intune.

Doing this up front can turn an apparently mysterious Intune deployment failure into a straightforward configuration problem.

Intune Win32 Apps PowerShell PsExec Device Management