Skip to content

Version 1.36.0 July 16, 2026

Version 1.36.0 July 16, 2026

Release Date: July 16, 2026

Summary

Section titled “Summary”

This release expands custom app upload beyond MSI. You can now upload an EXE or a ZIP (an installer plus its supporting files), add an app icon, and pick Raw or PSADT packaging, all through a guided wizard. Detection and update targeting were rebuilt to match how WinGet recognizes an installed app, so apps detect reliably and an update never turns into a fresh install on a device that never had the app. Raw is now the default packaging mode, the App Catalog shows real app icons served entirely from your own tenant, and installing an app no longer upgrades a device that already has an older version outside a maintenance window.

New Features

Section titled “New Features”
  • Custom app upload now accepts .exe and .zip installers in addition to .msi. A ZIP is treated as an IntuneWin source folder: put the installer at the root, with any supporting files alongside it, and everything is packaged together. When a ZIP contains more than one installer at the root, the wizard prompts you to choose the primary one. Because an EXE has no metadata to read, you enter the name, version, and publisher yourself.
  • Custom uploads now offer the same Raw or PSADT packaging choice the App Catalog provides. Raw (the default) installs the installer directly with its native command; PSADT wraps the installer for standardized logging, exit codes, and pre and post install hooks. For an EXE you supply the silent install switch, and the wizard shows the install and uninstall commands it will use before you publish.
  • App Upload is now a step-by-step wizard that mirrors the Intune Add App experience: upload, choose the installer when needed, confirm the app information, set the program and packaging, review the detection rule, and publish. The file is inspected automatically as soon as you select it, and you can add an optional app icon shown in Intune and the App Store catalog.
  • The Detection step now matches the Intune Detection rules experience. Choose a rules format: automatic Add/Remove Programs presence detection (the default), manually configured MSI, file, or registry rules, or a custom PowerShell detection script. This makes EXE uploads, and apps that do not register cleanly in Add/Remove Programs, reliable to detect.
  • Both publishing paths now offer an advanced, optional “Configure additional requirement rules” section matching the Intune Requirements experience, with File, Registry, and Script requirement rules. It is collapsed and empty by default. A requirement no device meets makes the app Not Applicable everywhere, so leave it empty unless you have a specific reason.
  • The App Upload wizard now has the same Requirements step the App Catalog has: OS architecture, minimum operating system, disk space, physical memory, and the optional requirement rules.

Product Enhancements

Section titled “Product Enhancements”
  • Detection now uses the same signals WinGet uses to recognize an installed app. An MSI is detected by its UpgradeCode, the identifier that stays the same across every version, so a device is recognized whatever version it runs, and an update is detected only once the new version is installed. This removes the reinstall loops caused by keying on a product code that changes with each release. For an EXE, detection matches the Add/Remove Programs entry using WinGet’s own name normalization, so a registered name carrying version, architecture, or language text is still recognized (for example, “7-Zip 24.01 (x64)” is recognized as 7-Zip). Detection runs entirely from the registry, with no dependency on WinGet being present on the device, and writes a rotating log to ProgramData\PowerStacks\AppStore\Logs.
  • An app update is now only offered to devices that already have the app installed, keyed on the MSI UpgradeCode. A device without the product line is marked Not Applicable, so an update never turns into a fresh install where the app was never present. For an EXE, which has no such identifier, applicability is matched by normalized name, which is best effort, so the publish wizards flag EXE installers accordingly: verify install and uninstall with a smoke test before releasing to production.
  • New app publishes, from the WinGet catalog and from custom uploads, now default to Raw packaging, which installs the app directly with its native command. PSADT remains available as a one-click choice for standardized logging, exit codes, and pre and post install hooks.
  • A raw (non-PSADT) MSI now uninstalls by its product code, using the correct uninstall verb with a silent, no-restart switch, and no longer carries install-only settings onto the uninstall. This fixes a common case where an app’s registered uninstall command uses the modify or repair form and so does not remove the app when run silently. PSADT-packaged apps are unchanged, and an EXE still uninstalls with the command registered in Add/Remove Programs.
  • When you upload an EXE, the portal identifies the installer it was built with (MSI, WiX Burn, Inno Setup, NSIS, InstallShield, Advanced Installer, InstallAware, self-extracting archives, and others) and pre-fills the silent install switch for you to confirm, instead of leaving it blank to work out by hand. Well-known apps whose switches cannot be read from the file (for example Citrix, Teams, AnyDesk, CrowdStrike, Docker Desktop) are recognized by name and their known switches suggested. This is a suggestion you review before publishing.
  • An uploaded MSI now lists the public properties it lets you set, such as a license key, install directory, or server URL, and flags any that are secrets hidden from logs. You can pass one as PROPERTY=VALUE on the install command from App Management.
  • Raw MSI installs, whether uploaded or published from the WinGet catalog, now write a verbose Windows Installer log (/L*v) to the Intune Management Extension Logs folder. Intune collects that folder automatically, so a failed install is easier to diagnose. PSADT installs are unchanged.
  • The App Catalog now loads from the same daily-built catalog index the PowerStacks website’s supported-apps page uses, so the apps you can browse and package always match what the website advertises. This also fixes cases where the catalog could come up empty or partial, because it no longer depends on a per-instance seed import or unauthenticated WinGet queries that can be rate-limited.
  • The Requirements step’s OS architecture, minimum OS, disk space, and physical memory are now sent to Intune and applied to the published app, from both the App Catalog and App Upload. Previously these values were collected in the wizard but never applied.
  • Catalog cards now show real app icons without your admins’ browsers reaching out to a third party. A curated set of common apps ships encoded in the daily catalog index, so popular apps render a hand-picked icon instantly. For anything else, when an app is viewed the portal resolves its icon once, on the server, and stores the bytes in your own database, served inline from then on. Anything without an icon shows a colored letter tile. A new Settings option, “Resolve catalog icons automatically”, is on by default and can be turned off. The catalog icon is also applied to the published app in Intune and Company Portal.
  • The catalog cards dropped the installer-type badge, the Homepage link, and the description, which came from enrichment that is not available for every app and made the cards taller than needed. Cards now show the icon, name, publisher, package identifier, and version.
  • The Publish to Intune wizard’s Package step now shows the installer type, the install scope (per-user or per-machine), and the Add/Remove Programs display name, read from the WinGet manifest. This is informational and read-only, useful when troubleshooting a deployment.
  • After installing an update from Admin Settings, the updater now waits until the new version is actually serving before reloading, so the version updates on its own instead of showing the old version until a manual refresh.
  • The Detection step’s “Automatically detect” option now describes what it will match for the app being published: an MSI by its stable installer identity across all versions, an EXE by normalized name. Packaging mode no longer labels PSADT as “recommended”, since Raw is a legitimate choice depending on the installer.

Bug Fixes

Section titled “Bug Fixes”
  • Resolved an issue where installing an app could upgrade a device that already had an older version, outside a maintenance window. Install detection was version-gated, so it reported an app as not installed on any device running an older build, and Intune would reinstall (upgrade) it. Detection for an install now checks only whether the app is present, at any version. Rolling out a newer version is the job of App Updates, which deploys on rings and a schedule. This applies to both uploaded apps and apps published from the WinGet catalog.
  • Fixed a case where a PSADT-packaged app could install nothing. The wrapper was packaged with a deployment script the current PSADT version does not run, so on the device it could report success while installing nothing. PSADT wrapping now generates the correct script for the current toolkit version and runs it through the standard launcher, in 64-bit PowerShell. Apps packaged as Raw were never affected. If you previously published a PSADT-packaged app that did not appear on target devices, republish it.
  • Auto-updates now keep the app’s original packaging mode. An automatic update from the WinGet catalog uses the same packaging mode, Raw or PSADT, the app was originally published with, so an app does not silently switch packaging on update.
  • App Catalog publish wizard: the Add requirement rule button now works. It previously did nothing because the wizard step did not refresh when a rule was added.
  • Requirement script rules: a Date and Time or Boolean output value is now sent to Intune in the format it expects (ISO 8601 for date and time, and true/false for boolean), and the editor provides a date-and-time picker and a true/false selector so the value is always valid.
  • App Management: Roll back to previous version is now disabled until an earlier version actually exists to roll back to.
  • App Catalog: a featured app beyond the Maximum Featured Apps limit is now shown in its category section rather than hidden, so the apps you see match the “Showing X of Y” count.
  • App Catalog: an app synced from Intune without its own icon now shows the catalog icon for its package when one is available, instead of a letter tile.