This is the whole manual route, start to finish, for one application. It is worth knowing even if you never do it again: every packaging tool automates exactly these steps, and when a deployment misbehaves this is the list you debug against. Budget 45 to 90 minutes the first time for an app you have not packaged before; the common estimate in the Intune community, and about right.
1. Get the right installer
- Find the vendor's download page and look for an enterprise or offline installer. An MSI beats an EXE; a standalone installer beats an online stub that downloads the real thing at install time (stubs fail behind proxies and cannot be hashed).
- Pick the architecture (x64 for a modern fleet, ARM64 if you have Surface or Copilot+ devices) and the scope: a per-machine installer, not per-user.
- Record the SHA-256 (
Get-FileHash .\setup.exe) and compare it with the vendor's published hash where there is one. You are about to run this file as SYSTEM on every device you own.
2. Work out the silent switches
Identify the installer toolkit and use its silent switch; the switch reference covers MSI, Inno Setup, NSIS, Burn, InstallShield and the rest. Then test it the way Intune will run it, from a SYSTEM shell on a clean VM:
psexec -s -i cmd.exe msiexec /i "C:\pkg\app.msi" /qn /norestart /l*v C:\pkg\install.log echo %ERRORLEVEL%
Note the exit code, check the app opens, then test the uninstall command the same way. Write both down; you will type them into the wizard and nobody tests the uninstall later.
3. Build the .intunewin
Microsoft's content prep tool wraps the installer (and anything else in its folder) into an encrypted .intunewin file.
IntuneWinAppUtil.exe -c C:\pkg\source -s app.msi -o C:\pkg\out -q
-cis the source folder: put only what the install needs in it, because the whole folder is packaged and downloaded by every device.-sis the setup file inside that folder. For an MSI the tool reads the product code, version and default install command into the package metadata, which the wizard then prefills.- Rebuild the file for every new version; the package is tied to its content.
4. Create the app in Intune
In the Intune admin center: Apps → Windows → Add → app type Windows app (Win32), upload the .intunewin, then the wizard's pages:
App information
Name (put the version in it), description, publisher, app version, category, a logo. The name is what users see in Company Portal and what you will search for in six months.
Program
- Install and uninstall commands from step 2.
- Install behaviour: System for per-machine installers, User for per-user ones.
- Device restart behaviour: usually "Determine behaviour based on return codes".
- Return codes: 0 success, 1707 success, 3010 soft reboot, 1641 hard reboot, 1618 retry. Add vendor-specific codes from the documentation or your test log.
Requirements
Operating system architecture and minimum Windows version at least; disk space, memory and a requirement script if the app needs them. A requirement that is not met makes the app "not applicable" rather than failed, which is the right outcome for an x64 package on an ARM device.
Detection rules
The rule that proves the install worked: MSI product code, registry version or file version, per the detection rules guide. Get this wrong and every device reports failure after a successful install.
Dependencies and supersedence
Dependencies for runtimes the app needs first. Supersedence pointing this app at the previous version, in Update or Replace mode, so devices with the old version move to this one; see the supersedence guide.
Assignments
Required, Available for enrolled devices, or Uninstall, each to Entra groups, optionally narrowed by assignment filters. Start with a pilot group. Set end-user notifications and, for large packages, delivery optimisation.
5. Watch it land
- The app's Device install status report in the admin center shows installed, failed, pending and not-applicable counts, with the error code per failed device.
- On a device,
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\holds the extension logs: the download, the install command's exit code and the detection result, in that order.AppWorkload.logon newer agents carries the app details. - Expect a day for a required assignment to reach most of a fleet; devices check in on their own schedule.
6. Do it again next month
Every vendor release repeats steps 1 to 5: new installer, re-check switches (they do change), rebuild the .intunewin, a new app object with a new detection rule, supersedence to the previous one, move the assignments, retire the old app. For a fleet of fifty apps that is the full-time job this process quietly becomes.