Recent Releases

The most recent releases are listed below. For older versions, see the release archive.

Version 1.38.0 August 25, 2026

Release Date: August 25, 2026

Summary

This release adds tags and richer categories for organizing the catalog, and cleans up day-to-day app management. Apps can now carry admin-applied tags and belong to more than one category, and categories stay in sync with Microsoft Intune in both directions. Editing an app happens in one place, the App settings wizard, which is also where you set the app icon, and you can control how many category rows the store home page shows. Store administration is reorganized into focused nodes, retiring the single Settings tab and moving each setting onto the surface it configures. App Management gains a Delete from Intune button that removes an app from Intune, deletes its requests, and removes it from the portal in one step. Reliability fixes cover bulk publishing, upgrades on the stable channel, categories kept across an upgrade, and the store category filter.

New Features

App tags. Apply tags to apps to organize and filter the catalog. An app can have up to 10 tags, reused from a shared list with type-ahead as you apply them. Give tags colors under Store Admin and they appear as colored chips on catalog cards, app detail, and the admin app list, and you can filter both the catalog and the admin app list by tag. Tags are applied by administrators and are separate from categories: a category is the shelf an app browses under and is shared with Microsoft Intune, while a tag is a portal label for organizing the catalog.
Delete an app from Intune. Opening an app in App Management now shows a Delete from Intune button. It removes the app from Intune, deletes the app’s associated requests, and removes the app from the portal. For an app the portal published with its own deployment group, a second prompt asks whether to also delete that group and its assignment; choose No to keep the group for reuse. The button is hidden for apps with no Intune app to remove.

Product Enhancements

Categories stay in sync with Microsoft Intune, and an app can have more than one. An app can belong to several categories instead of one. Set them as chips in the App settings wizard’s Visibility and Store step, the same way you set tags. Categories reconcile with Microsoft Intune in both directions: categories set in App Management reach Intune on the next sync, categories set in Intune appear in the portal, and each sync compares both sides against the last synced state, so a change on one side is not overwritten by the other. The category picker now lists the full set of categories from your Intune tenant, not just the ones already in use.
App settings are edited in one place. Editing an app now opens the App settings wizard, the same wizard the other property sections use, instead of a separate dialog. The app icon (upload a custom image, choose one from the icon library, or reset to the Intune default) is set in the wizard’s Visibility and Store step, alongside categories, tags, and cost. The standalone Edit App dialog has been removed.
The number of category rows on the store home page is configurable. A new Categories on Home Page setting on the App Catalog page, in the Catalog Settings panel, controls how many category rows the home page shows. The default is 3.
Store administration is reorganized into focused nodes. The single Settings tab is retired. Store Administration now reads Permissions, Categories, Tags, Branding, Deployment, Integrations, Communications, System, and License, one node per domain. Settings that have a working surface moved onto it: catalog sourcing and storefront display are on the App Catalog page, update cadence is on the App Updates page, the help-desk cost-per-ticket ROI input is on the Analytics report, the require-manager-approval default is in the Approval Workflows builder, and dark mode is under Branding. The Setup Wizard is now a top-level Getting Started entry.

Bug Fixes

Resolved bulk publishing failing partway through on GitHub rate limits. Publishing many apps at once could exhaust the GitHub request budget and leave some apps unpublished. Publishing now works from the published catalog index and completes without rate-limit errors.
Resolved a deployment or in-place update on the stable channel failing to start with a 503. A promoted build could report a version whose package was not on the stable channel. Stable builds now carry the correct version and point at a package that exists on the channel, and the app confirms the package is reachable before switching to it.
Resolved categories set in the app store being lost on upgrade. An upgrade could clear categories that existed only in the portal. The portal now keeps those categories on upgrade and adds them to Intune on the next sync.
Fixed the store category filter listing empty categories. Only categories that have at least one visible app now appear in the filter.

Version 1.37.0 August 5, 2026

Release Date: August 5, 2026

Summary

This release adds two ways to target work more precisely. Group Automations, a preview feature, keeps a Microsoft Entra device group in sync with the devices that have a given app installed, refreshed daily from BI for Intune, so you can aim an app update at only the devices that need it instead of everyone. Reusable approval workflows let you define an approval process once and share it across apps, with a tenant default that new apps inherit automatically. The release also stops repeated sign-in prompts in the admin console and makes the App Catalog load more reliably.

New Features

Group Automations (preview): device groups that follow installed software. Group Automations keeps a Microsoft Entra device group in sync with the devices that have a given app installed, refreshed once a day from BI for Intune. Point an App Update or a ring deployment at that group and only the devices that actually have the app receive it, instead of targeting All Devices or All Users. A new Group Automations tab holds a one-time BI for Intune connection (the Power BI workspace and semantic model IDs, with a Test connection button) and the list of automations. Each automation includes a device when its installed apps match all or any of a set of conditions on application name, publisher, and version, and targets an Entra group you create or reuse. A live preview shows how many devices match, listed by device name, before you save. Reconciliation runs once a day, tenant wide, one automation at a time; it adds and removes only the difference rather than rebuilding the group, and a run that matches zero devices or errors is skipped, so a data glitch cannot empty a group. As a preview feature it may change before general availability, and may be withdrawn if it does not meet our quality, performance, and scale expectations, so we do not recommend depending on it for critical production workloads yet. Requires BI for Intune with populated app inventory on a Power BI Pro workspace, App Store’s managed identity added to that workspace with Build permission, and the managed identity granted Device.Read.All (or Directory.Read.All) in Microsoft Graph so it can resolve a matched device to its Entra object.
Reusable approval workflows. An approval workflow can now be defined once and shared across apps, instead of configured on every app. A new Approval Workflows page lists reusable, named workflows and lets you create, edit, set a default, and delete them, with a count of how many apps use each. One workflow is the tenant default, so any app that requires approval uses it automatically. Each app’s approval settings offer three choices: use the default workflow, use a specific shared workflow, or define a custom workflow just for that app. When a request is submitted, the effective workflow resolves in that order: the app’s custom override, then its selected shared workflow, then the tenant default, then a single approval stage using the global approver group.

Product Enhancements

A new Automations area in the admin navigation groups Group Automations and Approval Workflows together, and the one-time BI for Intune connection now lives under Settings.
The App Catalog is served from the published catalog index without a per-package GitHub sweep. The proactive enrichment that fetched a manifest for every catalog package on startup and daily refresh was redundant with the index and the packaging-time fetch, and could hit GitHub rate limits, so it is now off by default. It can be re-enabled with the Winget:GitHubEnrichmentEnabled setting if the index ever needs supplementing.

Bug Fixes

Resolved repeated sign-in prompts in the admin console. When a page opened several requests at once and the access token had expired, each request could start its own sign-in, so you were prompted more than once in a row. Interactive sign-in is now handled a single time, so only one prompt is shown.
The App Catalog seed import no longer fails when a package lists its installer as a single object instead of an array. One such entry previously aborted the entire seed import and left the catalog empty on first start; the import now accepts either shape.

Version 1.36.0 July 16, 2026

Release Date: July 16, 2026

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

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

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

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.

Version 1.35.0 July 2, 2026

Release Date: July 2, 2026

Summary

This release focuses on how App Store for Intune delivers and updates itself. In-place updates now install to a specific version on your schedule instead of moving to a new build unexpectedly, an optional Preview channel lets you validate early-access builds before they reach production, and custom app upload works reliably on the current platform.

Product Enhancements

The portal now updates to a specific version only when you choose to, and a routine restart no longer moves it to a newer build. Upgrades happen on your schedule.

New Features

Added an optional Preview release channel. Point a portal at Preview to try early-access builds before they reach the Latest channel, then switch back to Latest for production. Set this under Store Administration → Settings → Release Channel.

Bug Fixes

Fixed an issue where uploading a custom MSI could fail, including large installers. The portal reads the installer to populate the app details and build an Add/Remove Programs based detection rule.
Resolved an issue where the selected release channel did not persist when settings were saved.
Resolved an issue where a new installation loaded an empty catalog until the first background sync completed.

Important Notes

[Action Required] Portals installed before version 1.35.0 check for updates from a release feed that has been retired, so Check for Updates will not offer this release. Moving an existing portal to 1.35.0 is a one-time manual step. Contact PowerStacks and we will walk you through the update for your environment.

Version 1.34.0 June 8, 2026

Release Date: June 8, 2026

App Store for Intune is now certified by Microsoft and available in Azure Marketplace. It runs entirely inside your own Azure tenant and gives users a self-service way to request applications while administrators stay in control of what gets deployed.

Highlights

Self-service requests. Users browse a catalog and request the apps they need. An administrator approves, and the app deploys through Intune.
A large catalog, plus your own apps. Search the full WinGet community catalog of more than 12,000 applications, or upload a custom MSI for anything that is not in it.
Hands-off packaging. Requested apps are wrapped with PSADT, converted to the .intunewin format, and deployed to Intune for you.
Approvals that fit your process. Route requests to admin or approver groups, with per-app control over who signs off.
Phased rollouts. Release updates in rings instead of to everyone at once.
Teams notifications. An optional Teams bot keeps requesters and approvers up to date.

Built for your tenant

Everything runs in your Azure subscription. Compute, data, and identity stay with you, and nothing is hosted by PowerStacks.
Deployment uses a single Entra ID app registration and a managed identity for Microsoft Graph access. There is no client secret to paste or store.

We are adding to it regularly, and new release notes will appear here as updates ship.