Pilot Ready MSI Deploys in Intune: SYSTEM Tests, Log Paths, Checklist

Use Win32 (.intunewin) packaging for production MSI deployments that need detection, dependencies, or custom install behavior. Use the Win32 Content Prep Tool to create the package, then configure detection rules and silent msiexec arguments in Intune. Before you touch the console, confirm the MSI supports a silent install and note its product code: both determine almost everything that follows.

TL;DR:

• Ensuring MSI supports silent installation and noting its product code is critical, as these determine detection accuracy and install success.
• Use the Win32 Content Prep Tool to package only the MSI and necessary files, then verify the package contents before upload.
• Detection rules should reliably use the MSI product code, and installers must be tested with silent switches like /qn and /norestart to avoid false failures.
• Always validate the silent install command and detection rule in SYSTEM context before expanding the deployment to a larger pilot group.
• Collect and review Intune diagnostic logs within 15 to 20 minutes after a failure to identify common issues such as detection mismatches or environment interference.

Table of Contents

• Check your prerequisites before you package anything
• Package the installer with the Win32 Content Prep Tool
• Upload the app in Intune and configure its settings
• Set detection rules and install commands that actually work
• Diagnose failures with Intune logs and diagnostics
• Run this checklist before you expand the pilot
• Why tested installers and local processing matter
• Pilot LawtonPDF through your existing Intune workflow
• FAQ
• Sources

Check your prerequisites before you package anything

A failed MSI deployment almost always traces back to something skipped at the start. Before you open the Win32 Content Prep Tool, confirm these basics on a test machine.

• Devices need the Intune Management Extension installed and checking in, since Win32 apps depend on it to run installs and report status.
• Confirm the installer supports unattended installation and note the exact silent switches the vendor documents.
• Decide between LOB and Win32: LOB works for a plain .msi with one command-line argument, but Win32 app management in Microsoft Intune is the better route whenever you need custom detection logic, dependencies, or multiple arguments.
• Win32 packages have a size limit per app, and large packages should be staged on a fast, reliable network share before upload, per the same Win32 documentation.

Skipping any of these checks tends to surface later as a mysterious install failure, so it's worth five minutes now.

Package the installer with the Win32 Content Prep Tool

Once your prerequisites check out, stage the installer and convert it into an .intunewin file.

1. Create a single source folder containing only the MSI, any transform (.mst) files, and configuration files the install needs.
2. Download and run IntuneWinAppUtil.exe, the tool Microsoft provides for preparing a Win32 app for Intune.
3. Run the tool with -c pointing to your source folder, -s pointing to the MSI file, and -o pointing to your output folder; add -q to run unattended.
4. Confirm the tool produced an .intunewin file containing both the packaged content and the metadata Intune reads during upload.
5. Verify the package by renaming the .intunewin extension to .zip and extracting it to confirm the Contents and Metadata folders are present and intact.

If the vendor's installer doesn't produce verbose logs on its own, wrap it in a simple logging script before packaging. That one addition saves hours later, since Intune Management Extension logs only capture what the installer itself reports.

Pro Tip: Keep a copy of the unpackaged source folder alongside the final .intunewin file so you can rebuild quickly if you need to change a switch or add a transform.

Upload the app in Intune and configure its settings

With the .intunewin file ready, create the app entry in the Microsoft Intune admin center under Apps, then All apps, then Add, selecting Windows app (Win32). Choose Line-of-business only when the installer is a simple .msi with no custom detection needs; otherwise, Win32 is the safer default.

• Set the install and uninstall commands exactly as they will run at the command line, including all switches.
• Define return codes if the installer uses nonstandard exit codes for success or soft reboot.
• Set requirement rules for operating system version and architecture so the app only targets compatible devices.
• Choose an assignment type: Required pushes the install automatically, Available lets users self-install from Company Portal, and Uninstall removes the app from assigned devices.

Scope tags help you control which admin groups can see and manage the app, which matters once you have more than a handful of packages in the tenant.

Set detection rules and install commands that actually work

Detection rules decide whether Intune reports the app as installed, so getting them wrong causes repeated install attempts or false success and failure states, as Microsoft's Win32 app guidance explains. For MSI packages, a Product Code detection rule is usually the most reliable option, since it checks the same identifier Windows uses internally. File and registry checks work too, but only when the install reliably creates a specific file or key every time.

You can find the MSI Product Code without any vendor tooling by opening the file's properties in Orca, or by querying it with PowerShell using Get-WmiObject -Class Win32_Product on a test machine, though that cmdlet is slow and best reserved for one-off checks rather than production scripts.

• Use /qn to suppress the installer UI entirely during silent installs.
• Add /norestart or set REBOOT=ReallySuppress to stop the installer from forcing an automatic reboot.
• Include ALLUSERS=1 when the application needs to install for every user on the device rather than just the current profile.

Pro Tip: Test your exact install command locally using PsExec with the -s flag to run as SYSTEM, since that's the context Intune uses by default and it can behave differently than an interactive admin session.

Diagnose failures with Intune logs and diagnostics

When a Win32 app fails in the field, start with Collect diagnostics from the device's record in the Intune admin center. The bundle typically comes back in about 15 to 20 minutes and gives you a downloadable snapshot of the device's install state.

1. Pull the diagnostic bundle or connect to the device directly and open C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
2. Review IntuneManagementExtension.log for the overall install sequence and any error codes returned by the installer, as described in Microsoft's Win32 troubleshooting guide.
3. Check AppWorkload.log and AppActionProcessor.log for details on how the install command executed and whether detection passed or failed afterward.
4. Compare logs across a few affected devices to spot a pattern: SYSTEM versus user context mismatches, architecture mismatches, missing dependencies, antivirus or EDR interference, and pending reboots account for most repeat failures.

Reproducing the issue with PsExec in SYSTEM context on your own test device usually surfaces the same error faster than waiting on a live device to fail again.

Run this checklist before you expand the pilot

A short checklist catches the mistakes that otherwise surface during a wide rollout.

• Confirm the silent install command works cleanly when run as SYSTEM, not just as an interactive admin.
• Validate the detection rule against the final installed state, not an intermediate step in the install process.
• Add antivirus or EDR exclusions for the installer process if scans are slowing or blocking silent installs.
• Start with a small pilot group and monitor install status daily for the first few days.
• Keep the uninstall command tested and ready so you can roll back quickly if a problem surfaces.

Why tested installers and local processing matter

We lean on runbooks for a reason: a packaging step skipped once tends to repeat itself across every device in a rollout. Testing in SYSTEM context and pulling Intune diagnostics before a wide push catches most of what otherwise turns into a help desk ticket storm. Our mass deployment runbook walks through the same sequence we use internally.

— Lawton

Pilot LawtonPDF through your existing Intune workflow

We ship LawtonPDF as a Windows MSI, which means the packaging and deployment steps in this guide apply directly: stage the installer, confirm silent switches, set a Product Code detection rule, and assign to a pilot group. All document processing runs locally on the device, so there's no cloud dependency to account for in your rollout plan, and our deployment runbook for desktop software covers the specifics for IT teams rolling out PDF tools at scale.

• Review plan options on our pricing page before committing to a tier.
• Check the full document and PDF processing toolset to see what a pilot group will have access to.
• Reference our license management guidance if your rollout includes offline activation.

Pro Tip: Run your LawtonPDF pilot through the same SYSTEM-context test and detection-rule validation you'd use for any other MSI, since the packaging steps don't change just because the app is ours.

Start a pilot on a handful of devices, confirm detection reports correctly, then expand assignment once you're satisfied with the results.

FAQ

What's the difference between LOB and Win32 MSI deployment in Intune?

Line-of-business deployment uploads a plain .msi file with only one command-line argument, while Win32 packaging supports multiple arguments, custom detection rules, and dependency handling. Most production deployments benefit from the extra control Win32 provides, even for a simple installer.

How do I find an MSI's Product Code for detection rules?

You can open the MSI's properties in a tool like Orca, or run a PowerShell query against the installed application on a test machine. The Product Code is the most reliable detection method since it matches the identifier Windows itself tracks for the install.

Why does my Win32 app show as failed even though it installed?

This usually points to a detection-rule mismatch rather than an actual install failure, often because the rule checks for a file or registry key before the installer finishes creating it. Review the Win32 troubleshooting steps and validate the detection rule against the installer's final state.

What msiexec switches avoid unwanted reboots during deployment?

Use /qn to run the install silently and either /norestart or REBOOT=ReallySuppress to prevent an automatic reboot after install. These switches keep the deployment from disrupting a user's active session.

How long does Intune's Collect diagnostics take to return results?

Diagnostic collection for a failing Win32 app typically returns within 15 to 20 minutes of the request. The bundle includes device-level logs useful for pinpointing the failure.

Recommended

• Deploy Desktop Software to Users: IT Admin Guide
• 300 Device Tool Mapped Runbook to Mass Deploy Windows Software for IT
• How to Deploy PDF Software Across Your Organization
• Software License Management Best Practices for Windows Teams