Deploy Win32 Apps Using Intune – Step-by-Step .IntuneWin Packaging & Deployment Guide (2026)

What Is a Win32 App in Microsoft Intune?

A Win32 app in Microsoft Intune is a traditional Windows desktop application (.exe, .msi, or script) converted into an encrypted .intunewin package. Intune uses the Intune Management Extension (IME) to securely download, evaluate custom detection rules, and silently install or uninstall the software in System or User context.

How to Deploy Win32 Apps in Intune (Step-by-Step Summary)

Deploying a Win32 app to enterprise Windows devices follows a standardized 5-step workflow:

1. Prepare Source Content: Place your setup installer and dependencies in a dedicated directory.
2. Generate .intunewin Package: Run Microsoft’s IntuneWinAppUtil.exe tool to package and encrypt your source folder.
3. Upload to Intune Admin Center: Navigate to Apps > All apps > Add > Windows app (Win32) and upload the .intunewin file.
4. Define Install & Return Codes: Specify silent install/uninstall switches, device reboot behavior, and assign execution context (System vs. User).
5. Configure Detection & Requirements: Define file, registry, or custom PowerShell script rules so Intune accurately verifies installation status.

Why Win32 App Packaging Matters for Enterprise IT

When people talk about modern Application management, they often jump straight to MSIX or Microsoft Store apps. In reality, most organizations still depend heavily on traditional Win32 applications. These are the classic Windows desktop apps that come as .exe , .msi , or custom installers built years ago. Here we will talk about how to Deploy Win32 apps using Intune.

Think about applications like:

VPN clients
Finance and ERP tools
Engineering software
Printer utilities
Firmware and driver tools
In-house business apps

Almost all of these are Win32 apps.

Using Microsoft Intune, administrators can package and deploy these apps remotely, without visiting devices or asking users to install anything manually. When Win32 deployment is done correctly, it becomes reliable, silent, and fully manageable at scale.

This blog explains how to deploy Win32 apps using Intune, starting from packaging and ending with Deployment or remediation and troubleshooting using real-world logic, not just theory.

How Win32 Apps Actually Deploy Inside Intune (Behind the Scenes)

When you deploy a .intunewin package, the client orchestrates the rollout in 5 distinct phases:

1. Content Download & Staging: The device downloads the encrypted payload into the local IME staging cache at: C:Program Files (x86)Microsoft Intune Management ExtensionContentIncoming.
2. Decryption & Extraction: IME unpacks the content into a temporary staging GUID subfolder before executing.
3. Pre-Install Detection Check: Detection rules evaluate whether the application already exists to avoid redundant executions.
4. Execution in Target Context: The silent install string triggers under NT AUTHORITYSYSTEM or the logged-on user token.
5. Post-Install Verification: Detection rules run again. If validated, success is reported back to Microsoft Graph.

💡 Senior Engineer Tip:
Intune never executes installations directly from the cloud. All delivery and monitoring flows through the local Intune Management Extension agent. For comprehensive troubleshooting, bookmark our complete guide to Intune Management Extension log files.

Intune App Types Comparison: Choosing the Right Deployment Method

Before jumping into Win32 packaging, it’s important to understand why Win32 is usually the best choice.

MSI Apps

MSI apps are simple and straightforward. Intune already understands how MSI installers work. However, MSI deployments have limitations:

• Limited customization

• No dependency handling

• No supersedence

• Detection tied to ProductCode (which can change)

MSI apps are fine for very basic deployments, but they quickly become restrictive in enterprise environments.

Win32 Apps

Win32 apps are the most flexible and powerful option in Intune.

With Win32 apps, you can:

• Use EXE, MSI, or script-based installers

• Control install and uninstall logic

• Define advanced detection rules

• Handle dependencies automatically

• Replace older versions using supersedence

• Deploy silently in System context

This flexibility is why Win32 apps are the preferred method for enterprise app deployment.

Microsoft Store Apps

Store apps are easy to deploy but limited:

• Less control

• Dependent on Store availability

• Not suitable for many business apps

Line-of-Business (LOB) Apps

LOB apps are a legacy method and not recommended for new deployments. They lack modern features like detection rules and supersedence.

Bottom line:
If you want control, reliability, and scalability, Win32 apps are the best option.

Packaging Applications with IntuneWin

Win32 apps cannot be uploaded directly to Intune. They must first be converted into a special encrypted format called .intunewin

This is done using the IntuneWin (Win32 Content Prep Tool).

Creating the .intunewin Package

Step 1: Prepare Your Source Content

Before you begin, you must gather your installation files and the necessary utility.

1. Download your software: Place your installer (e.g., logitech_dfu.exe) in a dedicated folder, such as C:ScriptDFU.
2. Get the Prep Tool: Download the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) from the official GitHub repository.
3. Organize: Keep the tool in a separate folder (e.g., C:IntuneWinAppUtil) to prevent it from being bundled into your application package

   

Step 2: Create the .intunewin Package

Intune cannot deploy raw .exe or .msi files directly; they must be converted into the encrypted .intunewin format.

1. Launch the Command Prompt as Administrator.
2. Navigate to your tool’s folder and run IntuneWinAppUtil.exe.
3. Provide the following inputs when prompted:

    ◦ Source Folder: C:ScriptDFU

    ◦ Setup File: logitech_dfu.exe

    ◦ Output Folder: C:ScriptDFU

    ◦ Catalog Folder: Type N.

The tool will compress and encrypt your files into a single package ready for upload.

What happens here:

• Intune encrypts the source files, Compresses everything into one package and Prepares metadata for Intune

Step 3: Upload and Configure App Information

Log into the Microsoft Intune admin center to register your new package.

1. Navigate to Apps > All apps > Add.
2. Select Windows app (Win32) as the app type.
   

   

3. Upload your .intunewin file and fill in the App Information tab:

    ◦ Publisher: Logitech.

    ◦ App Version: Helpful for future updates.

    ◦ Logo: Always specify a logo to help users identify the app in the Company Portal.

 oStep 4: Define Program and Install Behavior

This step determines how the app executes on the user’s device.

• Install Command: logitech_dfu.exe /available /list /fw_version /wait /pop-up /output c:Script_DFU_Outputuser.txt /upgrade_latest. You may need to find the silent install parameters for different applications by using the vendor website.
• Install Behavior: For apps which installs in logged on user’s profile context (e.g %Appdata%) use User. For Apps which installs in the device or system context(e.g. C:ProgramFiles), use System.
• Device Restart Behavior: Choose No specific action if you want to suppress reboots for MSI-based apps.
  

  

💡 Engineer Tip:
Always test silent switches locally before packaging.

Step 5: Set Requirements and Detection Rules

Detection rules are vital; they tell Intune if the app is already installed so it doesn’t try to reinstall it unnecessarily.

1. Requirements: Specify 64-bit architecture and a minimum OS like Windows 10 1607.
2. Detection Rules: Manually configure a File rule.
    Path: C:

    ◦ File: Script_DFU_Outputuser.txt
    ◦ Method: File or folder exists.

Expert Tip: Avoid using MSI product codes for detection if the software auto-updates, as the GUID may change and trigger a “downgrade” loop.

Step 6: Dependency and Tags

• On the Dependencies tab: Software dependencies are applications that must be installed before this application can be installed. Adjust if needed. Click Next

• Modify the Scope tags if needed

Step 7: Assignments and Monitoring

When assigning the app to groups, consider the Deployment Intent. Always go for UAT testing with few users before scheduling the deployment to all production users/devices.

• Available: Users can choose when to install via the Company Portal. This is highly recommended for firmware tools like Logitech Script DFU to prevent users from losing keyboard input during critical work.
• Required: The app installs automatically.

Click on Create, At this point it will upload the .intunewin file to create our Intune Win32 App.

After deployment, monitor the Device Install Status in the portal to track successes or failures.

Detection Rule Strategies Used by Real Engineers

Choosing the wrong detection method causes most deployment failures.

Best practices:

• Use File detection for firmware or script-based installs

• Use Registry detection for version tracking

• Avoid volatile paths like Temp folders

For complex enterprise applications where simple file-existence checks fail (such as validating a minimum semantic version or multi-tier registry flag), enterprise engineers use a Custom PowerShell Detection Script. Intune evaluates a script detection as Successful if the script outputs anything to STDOUT and exits with code 0.

# Custom Intune Detection Script (Registry & Version Check)
$regPath = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"
$app = Get-ItemProperty $regPath | Where-Object { $_.DisplayName -like "*Enterprise App*" }

if ($app -and [version]$app.DisplayVersion -ge [version]"2.5.0") {
    Write-Output "Installed" # STDOUT signals to IME that detection succeeded
    Exit 0
} else {
    # No output and exit code 1 tells Intune the app is missing
    Exit 1
}

Common Win32 Packaging Mistakes That Break Deployments

• Packaging unnecessary folders

• Missing silent install switches
  Using incorrect install context
  Detection rules pointing to user profile paths during System installs

• Ignoring exit codes like 3010 (soft reboot)

Troubleshooting Common Issues

If an installation fails, use these tools to find the root cause:

• Log Collection: Use the Collect logs feature in the Intune portal.
• Drill down into the Managed Apps for the failed system

  Go To Devices -> All Devices -> Select the computer failed and then select Managed Apps
  Click on collect Logs and enter the path %temp%/xlog_logitech In a few minutes, the log file will be ready to download.

  

• Log Paths: Check C:ProgramDataMicrosoftIntuneManagementExtensionLogs for the AppWorkload.log (Win32 specific) and IntuneManagementExtension.log.
• Standard Intune Return Codes & Reboot Behavior:
  

  Exit Code	Standard Meaning	Intune Action / Resolution
  0	Success	Installation completed successfully with no reboot.
  1603	Fatal error during installation	Generic MSI failure. Check individual installer logs or System permissions.
  1707	Success (No action)	Install was already completed or skipped gracefully.
  3010	Soft Reboot Required	Intune flags success but displays a restart prompt to the user.
  1641	Hard Reboot Initiated	The installer initiated an immediate system restart.

If you are deploying Win32 applications during zero-touch device provisioning, beware of Enrollment Status Page (ESP) timeout blocks. For resolving OOBE identity and MDM enrollment failures, review our complete guide on Fixing Autopilot Device Preparation Error 80180003. For script-driven packaging examples, see our case study on Deploying and Updating ZeeDrive with Intune and PowerShell.

Conclusion

Win32 app deployment remains the most powerful and reliable way to manage enterprise Windows applications in Intune. Once you understand packaging, detection rules, and Intune Management Extension workflow, deployments become predictable and scalable.

Mastering how to deploy Win32 apps using Intune gives you full lifecycle control over enterprise software delivery.

FAQ – Win32 App Deployment in Intune

1. What is a Win32 app in Microsoft Intune?

A Win32 app in Intune is a traditional Windows desktop application, usually delivered as an EXE or MSI installer. These apps are packaged into a intunewin file so Intune can install them silently, track installation status, and manage them across devices.

2. Why should I use Win32 apps instead of MSI apps in Intune?

Win32 apps give you much more control than MSI apps. With Win32 deployment, you can use custom install commands, run PowerShell scripts, handle complex installers, and define advanced detection rules. This makes Win32 apps the better choice for most enterprise applications.

3. What are detection rules and why are they important?

Detection rules tell Intune how to check whether an app is already installed on a device. If the detection rule is wrong, Intune may keep reinstalling the app or mark it as failed even when it works. Correct detection rules are the key to reliable Win32 app deployment.

4. Where can I find logs when a Win32 app fails to install?

When a Win32 app fails, logs are stored on the device at:
C:ProgramDataMicrosoftIntuneManagementExtensionLogs
The IntuneManagementExtension.log and AppWorkload.log files usually explain exactly why the installation failed.

5. What is IntuneWinAppUtil?

It’s Microsoft’s Win32 Content Prep Tool used to convert EXE or MSI installers into the encrypted .intunewin format required by Intune.