Intune app packaging: PSADT v4 to .intunewin without another Claude skill

Most Intune shops still treat Win32 packaging as “find a better wrapper.” This week’s Reddit loop is another Claude skill that turns PSADT v4 into a folder—fine as a generator, useless as a substitute for detection, rings, and the SYSTEM vs interactive trap.

Across tenants we assess that already run PSADT and Intune Win32, Intune PSADT intunewin fails in three places—and those are the same places a packaging demo never exercises.

The wrap is a finished folder, not a magic .intunewin button

Intune PSADT intunewin packaging starts after the PSADT v4 package already installs cleanly on a lab device. You point Microsoft’s IntuneWinAppUtil.exe at that folder, name the setup file (for PSADT v4 that is usually Invoke-AppDeployToolkit.exe), and get a .intunewin archive. Upload it as a Win32 app. The tool does not invent detection, choose install context, or decide your rings.

Claude skills and GUIs like WinTuner can spit out a folder faster than a junior tech. They still leave you with a wrap step and a Win32 blade that expects install/uninstall strings and a detection rule you own.

What breaks it:

• Wrap the finished PSADT folder, not a half-built source tree — IntuneWinAppUtil packages whatever you hand it; garbage in becomes a quiet install failure later.
• Setup file = Invoke-AppDeployToolkit.exe — wrapping the wrong EXE or a nested MSI is the classic “upload succeeded, install never starts” ticket.
• Do not drop IntuneWinAppUtil into the payload folder — keep the utility outside the source directory so you do not ship the packager inside the package.

Install, uninstall, and detection are three separate contracts

After upload, Intune needs an install command, an uninstall command, and detection that is independent of “the script returned 0.” For PSADT v4 the install line is typically Invoke-AppDeployToolkit.exe -DeploymentType Install (plus your Deploy-mode flags). Uninstall mirrors with -DeploymentType Uninstall. Detection should be MSI product code, a versioned file path, or a registry value the app actually writes—not “folder exists” and not “exit code was success.”

If you want Win32 packaging, remediations, and Intune app hygiene wired the same way across the fleet—not a one-off PSADT → .intunewin run—start with our M365 Automation Packages. For a fixed-price Intune and Autopilot hand-off, see the Device Management Jumpstart. When packaging failures show up as enrollment or ESP issues, use Managed Windows Autopilot for ongoing care or Autopilot Consulting for Assess and remediation.

What breaks it:

• Detection that always “succeeds” — a path that exists before install, or a rule that matches any version, leaves Intune thinking the app is installed when it is not.
• Uninstall that only kills a process — Win32 uninstall has to reverse the PSADT uninstall path, or supersedence and cleanup never finish.
• Copy-paste install strings from a different PSADT major version — v3 Deploy-Application.exe habits fail against a v4 Invoke-AppDeployToolkit.exe layout.

The door that stays open: SYSTEM context vs interactive UI

Default Win32 install context is SYSTEM. That is correct for silent fleet installs. It is also where interactive PSADT dialogs die: ServiceUI / force-interactive is only for the rare case where a user must see UI. Most packages that “work on my desk” and fail in Intune are waiting on a dialog nobody will click under SYSTEM.

Assignment rings matter more than the packager brand. Pilot a required assignment to a small group, confirm detection flips in the Win32 status report, then expand. A tool-generated folder does not replace that loop.

What breaks it:

• Inventory which packages truly need UI before you enable ServiceUI.
• Keep SYSTEM as the default — interactive under SYSTEM without ServiceUI is a hung install, not a slow one.
• Ring required assignments; do not blast All Users on the first .intunewin from a new generator.

What "good" looks like: the five-move baseline

If you do nothing else this quarter, these five moves dismantle the packaging failures above in order of impact:

1. Finish PSADT v4 locally first — lab device install and uninstall before you touch IntuneWinAppUtil.
2. Wrap with IntuneWinAppUtil — source folder + setup file Invoke-AppDeployToolkit.exe → .intunewin; utility stays outside the payload.
3. Set install and uninstall commands — DeploymentType Install / Uninstall on the toolkit EXE, not a guessed MSI switch.
4. Write independent detection — MSI / file / registry that proves the app version you care about.
5. Default SYSTEM, ring the assignment — ServiceUI only when UI is mandatory; confirm detection in Intune before widening the group.

No new Intune SKU required—just a repeatable wrap and a detection rule your next hire can read.

The uncomfortable question

The pattern across every “AI packaged my Intune app” thread is the same: the folder appeared in minutes, and the outage showed up in detection and context. The question worth asking isn’t “which skill wraps PSADT?” — it’s “would our Win32 status report show this version installed under SYSTEM on a clean Autopilot device with no interactive session?”

If you don’t know the answer, the Intune Win32 app install status blade and the device’s IME logs do.