Deploy a Windows application with Intune without winget

winget is handy on the command line for installing an application on your own machine. But depending on it for mass deployment via Intune quickly shows its limits: package availability in the repository, network dependency at install time, execution under the system account, versions sometimes lagging behind the vendor's. For these reasons, many teams prefer to deploy the vendor's real signed installer directly, keeping control of the exact version and its behavior.

Microsoft's recommended approach for this is deploying Win32 applications packaged as .intunewin. It gives full control over the installer, the install command, the detection rules and the failure behavior. In return, it requires understanding a few concepts and avoiding two or three classic pitfalls. Let's cover them in detail, with a concrete example and how AuPoint automates the whole journey.

How Win32 packaging works

A Win32 application in Intune is an installer wrapped in an encrypted .intunewin archive, accompanied by precise instructions: how to install it silently, how to detect it is present, and which group to assign it to. Intune downloads the package to the device, runs the install command, then evaluates the detection rule to confirm success.

1. 1Get the official installer (.msi or .exe) and its silent install command.
2. 2Package it as .intunewin using Microsoft's content prep tool.
3. 3Define the silent install and uninstall commands.
4. 4Define detection rules (file version, registry key, MSI product presence).
5. 5Assign to the target group, accounting for architecture (x86, x64, ARM).
6. 6Test on a pilot device before the general assignment.

Detection rules, the heart of the matter

The detection rule tells Intune whether the application is already installed. Poorly defined, it causes reinstall loops or, conversely, installs wrongly treated as successful. For an MSI, detection by product code is reliable and can be generated automatically. For an EXE, you rely on a key file's version or a registry key written by the installer.

The golden rule is to always verify the detection matches exactly the version being deployed. A detection that is too loose ('the folder exists') will treat an old version as up to date; one that is too strict will relaunch the install on every cycle. This is the setting that demands the most care, and the one where mistakes are the most silent.

The architecture trap

This is the most common and most silent mistake. If several installers exist (x86, x64, ARM), you must create one rule per architecture, each with its own detection and applicability conditions. Deploying an x64 binary to an ARM device, or the reverse, fails — sometimes with no clear message. Windows-on-ARM devices are multiplying, so this trap becomes increasingly concrete.

• Check which architectures the vendor actually offers.
• Create one Intune app (or applicability rule) per needed architecture.
• Adapt detection to each variant, since install paths may differ.
• Never assume an x64 installer will cover ARM devices.
• Test each variant on a real device of the corresponding architecture.

A concrete example: deploying a business PDF reader

A team wants to deploy a professional PDF reader to a hundred devices. The vendor provides an x64 .msi and an ARM .msi. The temptation is to package only the x64, since most of the fleet uses it. But five new ARM laptops have just arrived: on those, the install would fail silently, and users would end up without the application while nobody understands why.

The right approach is to create two Win32 applications, one per architecture, each with its product-code detection rule and its applicability condition. You test first on an x64 device and an ARM device, confirm detection, then assign to the full group. The result: all hundred devices receive the correct version, and the deployment leaves no device orphaned.

Managing updates over time

Deploying an application is only the start: you then have to keep it up to date. You publish a new version with an updated detection rule, and Intune sees the installed version is outdated and applies the new one. The point of vigilance is always the same: the detection must precisely target the new version, otherwise Intune will treat the old one as compliant and install nothing.

Clean version management avoids the buildup of outdated applications across the fleet, which is a major source of vulnerabilities. Keeping a direct link to the vendor's official installer, rather than a frozen binary downloaded once, greatly eases this tracking and reduces the risk of deploying a vulnerable version.

Execution context and requirements

Beyond detection and architecture, a few settings determine the reliability of a Win32 deployment. Neglecting them leads to installs that succeed on the test machine but fail in production, across devices with varied profiles.

• Context: install as system for applications meant for all users, or as user for special cases.
• Requirements: enforce a minimum Windows version, an architecture, enough free disk space.
• Restart behavior: handle cleanly the return codes that request a reboot.
• Timeout and retries: Intune retries a failed install, but the command must be idempotent for that to work.
• Available or required: offer the app in the catalog, or push it silently as needed.

How AuPoint automates deployment

AuPoint fetches the vendor's real signed installer, handles the different architectures and performs the .intunewin packaging for you, then assigns the application to devices. No winget is required on the endpoint: it's the official installer that gets deployed. Detection rules are generated automatically, eliminating the main source of error and the trickiest setting.

As with security controls, the preview shows the affected devices before assignment, and everything stays reversible. You can start with a pilot device, validate, then expand — while keeping control of the journey and without touching any command-line tools or manually preparing any archive.

FAQ

Should I abandon winget entirely?

No, winget stays useful for simple or one-off cases. But for reliable, reproducible mass deployment, packaging the real installer as Win32 gives more control and fewer dependencies at install time, especially when the network or the repository are unavailable.

How do I update a deployed application?

You deploy a new version of the app with an updated detection rule. Intune detects the installed version is outdated and applies the new one. You must ensure the detection targets the new version, otherwise nothing installs.

Why does an install fail silently?

Most often, because of a mismatched architecture (x64 on ARM) or an incorrect detection rule. Generating detection automatically and separating architectures, as AuPoint does, removes both of these common causes.

Connect your tenant to AuPoint and test deploying an app to a pilot device in a few minutes — the real installer, packaged, detected and assigned for you. Start free today.