Intune Win32 App Packaging Tools Compared: Robopack, Patch My PC, Advanced Installer and PSADT (2026)

This comparison is for Intune admins who have to turn installers into working .intunewin Win32 apps, and keep them working when version N+1 ships. It covers four ways of doing that: Robopack, Patch My PC, Advanced Installer (with PacKit) and the free PSAppDeployToolkit v4 plus IntuneWinAppUtil.exe route.

The scope is Windows devices managed by Microsoft Intune, with apps delivered by the Intune Management Extension (IME). It assumes you already know how to create a Win32 app in the admin center. It is a decision framework built from vendor documentation, Microsoft Learn and operating experience, not a lab benchmark: no install-time or release-speed figures below are measured.

Packaging is two jobs, not one

Teams that buy a packaging tool often discover they bought half of what they needed. There are two separate jobs:

• Getting the first package right. Silent switches, prerequisites, transforms, the right install context, a detection rule that matches what the installer really writes.
• Keeping it right for the next 18 months. A new version every few weeks, a vendor that changes its installer, a detection rule that quietly stops matching.

Catalog tools (Patch My PC, Robopack) are strongest at the second job for apps they know. Repackaging tools (Advanced Installer) are strongest at the first job for installers nobody else has seen. PSADT sits in the middle: it gives you complete control over both and does neither for you.

Most estates end up with a mix, usually a catalog tool for the commodity apps and a scripted or repackaged path for the awkward 10 to 20 percent. The comparison below is about where each tool earns its place in that mix.

The short answer

Comparison at a glance

1. LOB packaging versus catalog packaging

The first question is not "which tool", it is "what kind of installer is this?" There are three kinds, and they need different tools.

Vendor-supplied MSI or EXE with documented silent switches. Chrome, Zoom, 7-Zip, Acrobat. This is catalog territory. A curated or automated catalog tool knows the switch, the process list and the detection rule. Hand-packaging these is how teams end up owning 150 packages that all need updating every month.

Vendor installers with quirks. Needs a prerequisite, writes to the user profile, shows a first-run dialog, or is an EXE bootstrapper wrapping an MSI. These still package fine with a wrapper script, which is where PSADT earns its keep: a pre-install step to remove the old per-user copy, a post-install step to write a licence key, a clean log.

Legacy in-house LOB setups. A setup.exe built in 2009 by a contractor, no silent mode, copies files to three places, writes COM registrations, expects an interactive finish button. This is the one case where a repackaging tool is the right answer. You capture the install on a clean reference machine, review what it changed, and build an MSI or MSIX you control.

Where each tool lands

• Robopack and Patch My PC handle the first kind best and the second kind well through script templates and transforms. Both accept custom uploads, but neither is a capture tool, so an installer with no silent mode is still your problem.
• Advanced Installer is the only tool here that fixes the third kind. Its repackager and the PacKit workspace turn an interactive installer into a deterministic package. PacKit's freeware edition can generate .intunewin files; the paid editions add the editing and transform tooling.
• PSADT can wrap the third kind, but only by scripting what the installer does. If the vendor installer cannot run unattended, a wrapper can drive a response file or the UI with tricks, and that is fragile.

A warning on repackaging: a captured MSI records what happened on one reference machine. If the reference machine already had a runtime installed, the capture may skip it, and the package fails on a clean device. Always capture on a minimal, snapshot-restored VM, and test the resulting package on a machine that has never seen the app.

2. User experience and process deferral

Closing a running app is the part that generates tickets. The failure modes are well known: Outlook is killed with an unsaved draft, Chrome is closed mid-form, or a Teams call drops because the update script force-closed ms-teams. The mitigation is not a tool feature, it is a policy you encode in the wrapper.

PSADT v4 gives you the primitives. In Invoke-AppDeployToolkit.ps1, the pre-install phase calls Show-ADTInstallationWelcome:

# Pre-Install phase of Invoke-AppDeployToolkit.ps1 (PSADT v4)
$saiwParams = @{
    AllowDefer              = $true
    DeferTimes              = 3
    CloseProcessesCountdown = 600
    PersistPrompt           = $true
    CheckDiskSpace          = $true
}
if ($adtSession.AppProcessesToClose.Count -gt 0) {
    $saiwParams.CloseProcesses = $adtSession.AppProcessesToClose
}
Show-ADTInstallationWelcome @saiwParams

With AllowDefer and DeferTimes, the user gets to postpone the update, and PSADT tracks the deferral count so it does not nag forever. When the user defers or the prompt times out, the toolkit exits with 60012. That is the exit code you need to map in Intune (section 5).

Two limits apply whatever you build:

• PSADT cannot know a call is in progress by process name alone. Closing ms-teams while someone is presenting is the failure you are trying to avoid. Use the prompt countdown and the deferral count as your protection, and check what busy-state helpers your module version ships with Get-Command -Module PSAppDeployToolkit.
• Microsoft does not support interactive installs through Intune. Learn says applications must install silently, and that techniques forcing interaction with the signed-in session are unsupported. PSADT's prompts are a toolkit-level mechanism that works in practice in SYSTEM context, but you are outside Microsoft's support boundary when you rely on it. Test it on your build and keep a silent fallback for when no user is signed in.

Robopack builds this behaviour for you: the Apps to Close field on each app feeds the PSADT Welcome dialog. Patch My PC exposes it as per-app conflicting-process handling with proceed, auto-close, skip, or notify options, and a default 300-second notification timeout. In both, a deferral surfaces to Intune as a non-success exit, which is the retry loop covered below.

Advanced Installer does not solve this. An MSI can ask Windows Installer to use Restart Manager to close files in use, but there is no deferral prompt. If you repackage with it and need friendly closure, you still wrap the result in PSADT or rely on an Intune assignment window.

3. Detection and requirement rule accuracy

A package that installs perfectly and is reported as failed is the single most common packaging ticket. The signature is exit code 0 followed by a detection failure. In ConfigMgr and co-managed estates that is 0x87D00324 in AppEnforce.log; in Intune it surfaces as 0x87D1041C in the IME logs. The error code lookup lists the causes and fixes for both.

The usual causes, in order of how often they bite:

1. Wrong registry view. An x86 installer, or an x64 installer launched from a 32-bit PowerShell, writes under HKLM\SOFTWARE\WOW6432Node. The detection rule reads the 64-bit hive and finds nothing. The Intune setting is Associated with a 32-bit app on 64-bit clients, and the same trap exists for file rules and for script rules (Run script as 32-bit process on 64-bit clients).
2. Exact version match. The installer writes 1.4.0.0, the rule says 1.4. Or a self-updating app moves on and the rule pinned to the old version fails.
3. Reused MSI product code. Most vendors issue a new product code per release.
4. A STDERR line in a detection script. Learn is explicit: any data written to STDERR makes the result "not installed", even if STDOUT has data and the exit code is zero.

The 32-bit trap is worth dwelling on, because it is the one packaging tools quietly cause. Learn notes that calling powershell.exe in an install or uninstall command launches a 32-bit instance, and gives the Sysnative path to force 64-bit. A PSADT wrapper started that way will write registry values to WOW6432Node even though the application is 64-bit, and your detection rule will never see them. Log the process bitness in your pre-install step:

Write-ADTLogEntry -Message "64-bit process: $([Environment]::Is64BitProcess); OS 64-bit: $([Environment]::Is64BitOperatingSystem)"

How each tool helps:

• Robopack and Patch My PC generate detection for catalog apps from vendor metadata, which is usually right. For custom uploads, you own the rule.
• Advanced Installer has a structural advantage: an MSI you built has a known product code and version at build time, so MSI detection is deterministic.
• PSADT and IntuneWinAppUtil give you nothing. The toolkit installs; it does not write the detection rule. Generate a script with the Intune Win32 detection script generator, which lets you set an explicit 32-bit or 64-bit registry view, and test it as SYSTEM.

For the ConfigMgr-to-Intune version of the same problem, read ConfigMgr app content vs detection before moving to Intune.

4. Supersedence and update rings when version N+1 ships

Version N+1 arrives 14 days after you shipped N. What happens next depends on the tool.

Catalog tools (Robopack, Patch My PC) treat the new version as an update to an app they already manage. For the apps they know, the new package is built, detection updated, and the ring schedule applies. The effort is mostly approval. The exception is custom uploads: neither tool can fetch an internal installer you own, so you supply the new binary and verify the detection rule again.

Advanced Installer makes version N+1 a project edit: bump the product version, decide on a major upgrade (new product code and an UpgradeCode that removes the old one), rebuild the MSI, export .intunewin, upload. This is predictable, but still a manual publishing step per release.

PSADT with IntuneWinAppUtil means you do all of it:

1. Replace the files in Files\ and update the version variable in Invoke-AppDeployToolkit.ps1.
2. Re-run IntuneWinAppUtil.exe to rebuild the .intunewin.
3. Decide whether to update the existing app's package file in place or create a new app that supersedes the old one.
4. Update the detection rule if it pins a version.
5. Move the assignment through your pilot, broad and production groups yourself.

On the supersedence decision, Microsoft's rules matter: a supersedence graph is limited to 10 nodes in total, including references to other apps in the chain. A new app per release, each superseding the last, hits that ceiling after nine updates. The fix is to update the package in place for routine releases, and reserve supersedence for replacing a different app or a changed packaging model. Set Uninstall previous version only if the new installer does not upgrade the old version itself.

Ring behaviour is a separate question. Patch My PC Cloud Update Rings are time-based (a delay per ring) rather than success-gated, and Robopack waves can wait for deployment and success thresholds. If rings matter, read the ring section of our third-party patching comparison, which goes through them in detail. With PSADT and Advanced Installer there are no rings at all: your Intune group design is the ring.

5. Licensing and total cost of ownership

"Free" is a licence price, not a cost. The honest comparison is licence cost against the engineering hours the free path consumes.

A back-of-envelope model you can adapt with your own numbers: multiply the number of apps you would hand-package by releases per year by hours per release. For example, 40 apps, 4 releases a year and 1.5 hours each is 240 hours a year. That example is an assumption, not a benchmark. Compare it with the licence cost for your device count, and remember that hours spent on the long tail do not disappear when you buy a catalog tool: custom apps still cost the same.

Two costs that rarely appear in the spreadsheet:

• Framework ownership. PSADT v4 is a PowerShell module with its own versions and breaking changes between v3 and v4. Someone has to own upgrades.
• The cost of a bad deferral. A forced close on a user in a call generates a ticket and a story. A catalog tool's defaults are usually safer than a hurried wrapper.

Diagnosing wrappers: SYSTEM, user context and exit codes

When a packaged app misbehaves, the question is always the same: what did the IME actually run, as whom, and what did it return?

Which context ran it

The Install behavior setting decides it: System or User. Learn notes that, when a device is Entra registered, you should select System, and that user-context installs run with admin privileges only if the signed-in user is an admin. Reproduce the SYSTEM case locally with PsExec rather than guessing:

# From an elevated prompt on a test device, with PsExec from Sysinternals
psexec.exe -s -i powershell.exe

# Then, inside that SYSTEM window:
whoami                                  # nt authority\system
[Environment]::Is64BitProcess           # True means 64-bit
Set-Location 'C:\Packages\MyApp'
.\Invoke-AppDeployToolkit.exe -DeploymentType Install -DeployMode Silent
$LASTEXITCODE

Invoke-AppDeployToolkit.exe is the v4 launcher; the exit codes 60009 to 60011 in the PSADT reference describe it failing before PowerShell starts. If you call the script instead, use the Sysnative PowerShell path so the process is 64-bit.

What the IME logs

On the device, the IME logs live in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. IntuneManagementExtension.log records check-ins and policy processing, and AppWorkload.log carries the app-level install and detection lines. Pull the relevant lines for one app:

$dir = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs"
Select-String -Path "$dir\AppWorkload.log","$dir\IntuneManagementExtension.log" `
  -Pattern 'exit code|ExitCode|detected|0x87D1041C|1618|1603|3010|60012' |
  Select-Object -Last 40 Filename, LineNumber, Line

On a co-managed device where Configuration Manager owns the apps workload, read C:\Windows\CCM\Logs\AppEnforce.log instead and look for the same exit code, then the discovery result.

How the IME interprets exit codes

Intune maps the exit code to a code type. Per Learn, the entries added by default are 0 and 1707 as success, 3010 as soft reboot, 1641 as hard reboot and 1618 as retry. Anything you have not mapped is a failure. A retry code makes the agent attempt the install three times, waiting five minutes between attempts.

On the 60001 entry: it is easy to assume it is a retryable condition. The PSADT reference describes it as an error in the deployment script, and it should stay a failure. If you map it to Retry, Intune re-runs a broken script three times and then reports it anyway. Map 60012 to Retry, leave 60001 as Failed, and consider mapping any code that means "wait for the user" to Retry deliberately rather than by default.

Be aware of the interplay: retry attempts five minutes apart will burn through three deferral prompts in about fifteen minutes. If you let users defer for hours, rely on PSADT's own deferral counter and interval (DeferTimes, DeferDays and DeferRunInterval in v4), and do not expect the Intune retry to space prompts out.

For stuck states that are not exit-code related, such as content that never downloads, work through the Win32 app stuck at Waiting or Pending guide.

When not to use each tool

• Do not use Robopack to fix an installer that has no silent mode. It wraps and publishes; it does not capture. Also plan for the fact that metadata such as Owner, Notes and Categories is not preserved when it updates an app.
• Do not use Patch My PC if your estate is mostly internal installers. The Custom Apps limits (100 on Plus, 500 on Premium) and the minimum commit mean you pay for a catalog you barely use.
• Do not use Advanced Installer to repackage a clean vendor MSI. You add a build step, a new product code and a support question without gaining anything, and you lose the vendor's own upgrade logic.
• Do not use PSADT alone if the plan is hundreds of apps updating monthly and nobody owns the framework. It is excellent as a control layer and expensive as a catalog replacement.

Pilot checklist

• Classify your top 50 apps as vendor-silent, vendor-quirky or legacy LOB
• Choose the tool per class, rather than one tool for everything
• For every PSADT wrapper, log process bitness and confirm the install command uses the 64-bit PowerShell path or the .exe launcher
• Map 60012 to Retry in the Win32 app's return codes, and leave 60001 as Failed
• Test every custom detection rule: not detected before install, detected after, not detected after uninstall
• Run each wrapper as SYSTEM with PsExec before you assign it to a ring
• Define the deferral policy (count, interval, countdown) and test it on a device with Outlook and Teams open
• Decide for each app whether N+1 updates the package in place or supersedes, and keep supersedence chains short
• Capture the IME or AppEnforce.log lines and the PSADT log for one success and one failure
• Cost the 12-month hours for the free path against the licence for your device count

Rollback

Plan rollback as containment. A package that has reached a device is not undone by any of these tools.

1. Stop the assignment. Remove the broad group from the Required assignment, or pause the tool's ring or wave.
2. Limit who got it. Pilot groups do most of the work here; a bad package that stopped at ring 0 is an inconvenience.
3. Ship a fixed N+1 in place rather than adding another supersedence node, unless the packaging model changed.
4. Use an Uninstall assignment only for apps whose uninstall command you have tested. An untested uninstall is a second incident.

Final recommendation

• Most Intune estates: a catalog tool for vendor apps, PSADT v4 for custom logic and user prompts. Start with Patch My PC if you also run ConfigMgr, or Robopack if you are cloud-only and want PSADT wrappers generated for you.
• Estates with legacy in-house installers: add Advanced Installer with PacKit for the handful of packages that need capture and transforms, and do not buy it for anything else.
• Small teams with engineering time and a short app list: PSADT v4 with IntuneWinAppUtil.exe, as long as someone owns the framework and the detection rules.

Whichever route you take, the biggest risk is not the tool. It is a detection rule nobody has tested as SYSTEM in the right bitness, and a deferral policy nobody has tried on a user in a call.

Primary Sources

• Add and assign Win32 apps to Microsoft Intune
• Prepare Win32 app content for upload
• Add Win32 app supersedence
• Troubleshoot Win32 app issues
• Intune Management Extension for Windows
• PSAppDeployToolkit v4 exit codes
• Patch My PC pricing
• Robopack pricing and Robopack FAQ
• Advanced Installer IntuneWinAppUtil guide

Related Reading

• Best third-party patching tools for Intune (2026)
• Intune Win32 detection script generator
• Intune and ConfigMgr error code lookup
• ConfigMgr app content vs detection before Intune
• Intune Win32 app stuck at Waiting or Pending
• Intune vs SCCM/MECM