App Upload

The App Upload page (Apps > App Upload in the admin area) 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. You must be an App Store administrator to upload 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	App Store can’t read an EXE’s name, version or publisher, so you enter them. It identifies the installer engine and pre-fills a suggested silent switch for you to review.
.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. In the admin area, select Apps > 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, shown in Intune and the catalog. It must be a PNG or JPEG file of 1 MB or less, because Intune accepts only those formats.
   • Program. Under Packaging mode, choose PSADT or Raw. Raw is selected by default. For an EXE, review the Silent install switch (for example /S or /silent); for a raw EXE, you can also enter an Uninstall command. The wizard previews the commands. For an MSI, the uninstall uses the MSI’s product code. Intune is known to accept commands of up to 2,048 characters. The step doesn’t continue while the raw EXE install command with your silent switch, or an uninstall command you enter, is longer than 2,048 characters, and its message gives the command’s length and the limit. The upload API refuses such a command with 400.
   • Requirements. Set Operating System Architecture, Minimum Operating System (Windows 10 1607 by default), and optional disk space and memory. Operating System Architecture offers only what the installer allows. For an MSI, it follows the platform in the MSI’s Template summary property: an x64 MSI offers x64; an Intel (x86) MSI offers x64 and x86, which you can narrow to x64; and only an MSI built for Arm64 offers ARM64. For an EXE, it starts on x64, and you can choose x64 and x86 for a 32-bit installer; check the vendor’s documentation. ARM64 is available only when the EXE’s file header names ARM64, which shows it’s a native ARM64 installer. An MSI whose platform App Store can’t tell also starts on x64, and an MSI whose summary information can’t be read is still uploaded. A 32-bit Arm installer is refused. If a ZIP has more than one installer and you choose a different one, the requirement goes back to that installer’s starting value, and an EXE chosen that way isn’t offered ARM64. An app published with x64 or x64 and x86 isn’t offered to ARM64 devices, and an app published with ARM64 applies to ARM64 devices only. The app’s architecture, which names its deployment group, comes from the file, not from the requirement you choose. See why only a native ARM64 installer reaches ARM64 devices.
   • 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 Reports > Activity Log, in the notification drawer, or under Packaging Jobs on Apps > App Catalog, where its source is Upload. When the job completes, the app appears in App Management, hidden, ready for you to configure assignment and availability.

Raw vs PSADT

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

• PSADT. 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 (the default). 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, enter the vendor’s silent uninstall command in Uninstall command if you know it, and App Store uses it as you typed it. If you leave it blank, App Store packages an uninstall script that matches the Name and Publisher you enter on the App information step against Add or Remove Programs, so enter both exactly as Windows shows them under Settings > Apps > Installed apps. The Program step previews this as powershell.exe -NoProfile -ExecutionPolicy Bypass -File AppStoreUninstall.ps1. If App Store can’t identify the installed app, it uses the app’s uninstall command from the registry instead. The script logs to %ProgramData%\PowerStacks\AppStore\Logs\AppStore-Uninstall.log on the device when it runs as SYSTEM, which is how Intune runs it, and to %TEMP% otherwise. The Uninstall command box can also come filled in with a suggested command when App Store recognizes the installer engine; check it before you publish. The script isn’t signed, so a tenant that enforces the AllSigned execution policy needs your own uninstall command. 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). For an MSI, App Store detects the app by its UpgradeCode, or by its product code when it has none. For an EXE, it generates an Add/Remove Programs (ARP) rule that matches the app’s name and publisher and ignores entries that Windows hides from the installed apps list. Either way it detects the app 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. If an EXE hides its Add/Remove Programs entry, use manual rules or a custom script. 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.) Uploaded apps show Upload in the Source column of Packaging Jobs. In App Management they’re listed under the Store source, with catalog apps.