Packaging a Windows application for Intune can feel finished the moment the silent install works. The installer ran without a prompt, the files landed under Program Files, and the app opened. Wrap it in an .intunewin file, paste the command into the admin center, and move on.

That gets an application onto one test machine. It does not prove that Intune can manage it.

I recently packaged PDFgear 2.1.20 as a Win32 application, and the install command was the least interesting part of the work. The decisions that mattered were how to prove the app was installed, how to remove it without user interaction, and what should happen when 2.1.21 or 2.2 eventually replaces it.

Start with the installer, not the portal

Before creating anything in Intune, I tested the exact installer on a disposable Windows device. That meant recording its SHA-256 hash, checking the digital signature, identifying the installer technology, and running both the silent install and silent uninstall locally.

For the tested pdfgear_setup_v2.1.20.exe, the important facts were:

Item Validated result
Installer technology Inno Setup
Install context System, machine-wide
Install location C:\Program Files\PDFgear
Installed version 2.1.20
Registry view 64-bit
Silent install exit code 0
Silent uninstall exit code 0
Restart required during testing No

The production install command became:

pdfgear_setup_v2.1.20.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-

The uninstall command was:

"C:\Program Files\PDFgear\unins000.exe" /SILENT /NORESTART

Those switches are documented Inno Setup behavior, but that does not make them universal defaults for every EXE installer. The reason I was comfortable putting them into Intune is that I ran those exact commands, waited for the processes to finish, checked the exit codes, and verified the resulting filesystem and registry state. Microsoft requires Win32 applications to install without user interaction; the packaging work starts by proving that the vendor’s installer can actually do that.

Detection is the real deployment

Intune does not decide that an application is installed because the setup process returned 0. It evaluates the detection rule afterward. A perfect installation paired with the wrong detection rule becomes a failed deployment—or an application that Intune tries to install again.

PDFgear 2.1.20 registered this uninstall key during testing:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{7DACF63A-4EE4-4837-9AF9-C65D4509FFB4}_is1

For a version-locked 2.1.20 package, I used a 64-bit registry detection rule that checks whether DisplayVersion equals 2.1.20. That rule answers one precise question: is the version represented by this Intune app installed?

The precision is useful, but it has a consequence. If another trusted process upgrades PDFgear to a later version, exact equality becomes false. If the old 2.1.20 app is still assigned as Required, Intune can decide that it is missing and offer the old installer again. Detection is not just a technical checkbox; it expresses the lifecycle policy for the application.

There are two valid models:

  • Exact-version detection works when every release gets its own Intune app and versions move forward through supersedence.
  • Minimum-version detection works when 2.1.20 or later should satisfy the assignment, including a newer version installed through another trusted process.

The second model needs a carefully tested script that discovers PDFgear in both uninstall registry views, parses DisplayVersion, compares it as a version, exits with 0, and writes output only when a qualifying install is found. That last detail matters: for a custom Win32 detection script, Microsoft documents that Intune needs both exit code 0 and data on standard output before it reports the application as detected.

That GUID is not an MSI product code

The uninstall key looks enough like an MSI product code to invite the wrong assumption. PDFgear 2.1.20 was packaged with Inno Setup, not Windows Installer. Inno Setup derives the uninstall key name from its AppId and adds _is1.

That means the key is evidence about the installer I tested, not a promise about every future PDFgear installer. It should remain stable only while the publisher retains the same Inno Setup AppId and registry view. A future release could change the key, architecture, display name, install path, or uninstaller.

Copying the 2.1.20 detection rule into the next package without inspecting the next installer would turn a validated fact into a guess.

Package the version you actually tested

The source folder for the Microsoft Win32 Content Prep Tool should contain only the files that belong in the package. The tool packages the entire folder, so logs, older installers, the prep tool itself, and unrelated scripts do not belong beside the setup file.

I also kept the version in the Intune app name: PDFgear 2.1.20. A generic name can look cleaner in the app list, but a versioned name makes package ownership, reporting, supersedence, and rollback much easier to reason about. The user-facing presentation can still be handled deliberately; the administrative object should tell me what it actually contains.

Design the second deployment during the first

The first version of an app has no supersedence relationship. It still needs an upgrade plan.

For the next PDFgear release, I would treat the new installer as unknown until testing proves otherwise:

  1. Validate its hash and signature.
  2. Test a clean silent install and uninstall.
  3. Install it over 2.1.20 and confirm whether it performs an in-place upgrade.
  4. Reinspect both uninstall registry views.
  5. Create a new versioned .intunewin package and Intune app.
  6. Build detection from the new observed state.
  7. Configure it to supersede 2.1.20 and pilot the upgrade.

If the new installer upgrades the old version cleanly, Microsoft’s supersedence guidance says to leave Uninstall previous version off and let the new installer perform the update. Turning that option on changes the workflow into a replacement: Intune removes the old app before installing the new one. That is appropriate only when testing shows the application must be removed first.

What I would not do is silently replace the .intunewin content and leave the old command, metadata, and detection rule behind. The package, install behavior, and detection logic describe one release together. Updating one of them without the others is how an app that looked healthy in the portal becomes unpredictable on devices.

Pilot the whole lifecycle

A successful install is one checkpoint. My pilot also needs to prove that:

  • PDFgear launches for a standard user.
  • Intune reports the app as installed after another sync and a restart.
  • The required PDF functions work under the organization’s security controls.
  • A newer release upgrades the installed version as expected.
  • The uninstall action removes the application when the deployment design requires it.

That is the difference between packaging an installer and managing an application. The first gets files onto a device. The second gives Intune a truthful way to install, detect, update, and remove them over time.

The full runbook

The exact packaging layout, registry rule, optional minimum-version detection script, Intune field values, pilot checks, and troubleshooting steps are in the knowledge base:

→ PDFgear Intune Win32 Deployment Runbook — part of my MSP Microsoft 365 knowledge base on GitHub.

The tested values in that runbook apply to PDFgear 2.1.20. The reusable lesson is the process: validate what the installer really does, make detection match the lifecycle you intend, and never assume the next version behaves like the last one.

Primary references