App Upload

The App Upload tab lets you publish an app that isn’t in the WinGet catalog by uploading its installer directly. The portal packages the installer, builds a detection rule, and creates a Win32 app in Intune through the same pipeline the App Catalog uses. An upload is a new install; assignment and availability are configured afterward in App Management, exactly as they are for catalog apps.

Supported Upload Types

Type	Notes
.msi	The portal reads the MSI Property table to pre-fill the name, version, and publisher, and to build the detection rule.
.exe	No metadata can be read automatically, so you enter the app details and supply the silent install switch.
.zip	An installer plus its supporting files. Treated as an IntuneWin source folder (see below).

The maximum upload size is 5 GB. Transforms (.mst) and patches (.msp) are not supported.

How a ZIP Is Packaged

A .zip is treated the way IntuneWinAppUtil treats a source folder: the installer sits at the root of the archive, and everything alongside it is packaged as supporting payload. This is how you upload an app that ships a setup file plus data files, configuration, or transforms.

• Put the primary installer (.msi or .exe) at the root of the ZIP.
• Place any supporting files alongside it, at the root or in subfolders. They are packaged as-is.
• If the root contains more than one installer, the wizard adds a step for you to choose the primary one.
• Installers below the root are treated as supporting files, not as candidates.

Uploading an App

1. Go to Admin > App Upload.

2. Select Upload a custom app to open the wizard.

3. Complete each step:

   • Upload. Drop or browse for a .msi, .exe, or .zip. The portal stages the file and inspects it automatically, reading what it can.
   • Choose Installer. Shown only when a ZIP has more than one installer at the root. Select the primary installer.
   • App Information. For an MSI, the name, version, and publisher are pre-filled and editable. For an EXE, enter them yourself. The description is optional and is shown to end users in the catalog. You can also add an optional icon (PNG or JPG under 1 MB), shown in Intune and the catalog.
   • Program. Choose PSADT (recommended) or Raw packaging. For an EXE, enter the silent install switch (for example /S or /silent); for a raw EXE, also enter the uninstall command. The wizard shows the install and uninstall commands it will use.
   • Detection. Review the auto-generated detection rule. See Detection Rules below.
   • Review + Create. Confirm the summary, then select Publish to Intune.

4. Track packaging progress on the Activity Log page or in the notification drawer. When the job completes, the app appears in App Management, ready for you to configure assignment and availability.

Raw vs PSADT

The Program step offers the same packaging choice as the App Catalog:

• PSADT (recommended). Wraps the installer with the PowerShell App Deployment Toolkit for standardized logging, exit codes, and pre and post install hooks. This is identical to the WinGet path.
• Raw. Packages the installer directly, without a wrapper.

For an EXE, the silent install switch you enter is used in both modes. If you leave it blank, the portal defaults to /S /silent. For a raw EXE, also enter the uninstall command: an EXE uninstaller can’t be derived reliably, so provide the vendor’s silent uninstall invocation. In PSADT mode, PSADT handles uninstall, so no uninstall command is required.

For a Raw MSI, the portal adds verbose logging (/L*v) to the Intune Management Extension Logs folder (C:\ProgramData\Microsoft\IntuneManagementExtension\Logs), which Intune collects automatically when you gather logs from the console. PSADT does its own logging and is not modified.

Detection Rules

The Detection step mirrors the Intune “Detection rules” step, with a Rules format choice:

• Automatically detect (recommended). The portal generates an Add/Remove Programs (ARP) rule that detects the app by name and publisher, at any version. An upload is a new install, so it checks presence only; a version-gated rule would report the app as not installed on any device running an older build. This works for most MSIs, including those that set ARPSYSTEMCOMPONENT=1 (that flag only hides the app from the Programs and Features list; detection reads the registry directly and still matches). To roll out a newer version later, upload it and use a version-based rule (see below) so devices on the older build are targeted.
• Manually configure detection rules. Add one or more rules, exactly as in Intune:
  • MSI: product code, with an optional product version check (operator and version).
  • File: path, file or folder name, and a detection method (file or folder exists / does not exist, date modified, date created, string version, size in MB), with an operator and value where the method needs one, plus a 32-bit-on-64-bit option.
  • Registry: key path, value name, and a detection method (key exists / does not exist, string / version / integer comparison), with an operator and value where needed, plus a 32-bit-on-64-bit option.
• Use a custom detection script. Provide a PowerShell script (paste it, or load a .ps1). The app is detected when the script exits with code 0 and writes to standard output. Optional toggles: run the script as a 32-bit process on 64-bit clients, and enforce a signature check.

EXE apps often don’t register a matching Add/Remove Programs entry, so Manual or Custom script is the reliable choice for them.

After Publishing

The app is created in Intune without assignments. Configure assignment, visibility, and availability from App Management, the same as for a catalog app. An upload is a new install; to roll out a newer version later, upload the new version and give it a version-based detection rule so devices on the older build are targeted. (The App Updates tab automates upgrades for WinGet-catalog apps only.) Custom-upload apps are identified in App Management and the Activity Log so you can tell them apart from WinGet-sourced apps.