Version 1.39.0 October 21, 2026

Release Date: October 21, 2026

Summary

This release lets you choose which of a requester’s devices an app assigned to devices installs on, and adds a My Devices tab, chargeback reporting, recorded request acknowledgments, read-only API access for managed identities, and Retry for requests that failed. Rollbacks pause automatic updates for the app and can return to the version an app was first published at, and an update or rollback now leaves the app in Intune describing the version it installs. Uninstalls find the app Windows installed, detection tells an app apart from its other architectures and product lines, and packaging reads WinGet manifests the way WinGet does. Store Health shows only figures App Store measures and adds checks for rollback package protection, Microsoft Graph permissions and apps that can’t deliver. Fixes include Teams notifications, deployment groups created with Auto-create group, group member removal, and apps deleted directly in Intune. Two changes are intentional and can affect you: only a native ARM64 installer reaches ARM64 devices, and Swagger is off unless you turn it on. See Important Notes.

New Features

Device targeting for apps assigned to devices. On the Assignment step of App settings, choose which of the requester’s devices the app installs on: Let the user choose (the default, and what every existing app is set to on upgrade), The device they are using, Their primary devices, or Both. Identifying the device in use needs the browser to be signed in to Microsoft Entra ID, which Microsoft Edge does on a joined or registered device, and Chrome and Firefox do with Windows SSO; other users are asked to choose a device. The request dialog names the device the app will be installed on, and lists only devices that are managed, can receive apps, run the app’s platform, and, for a Windows app, have a processor the app’s Intune requirement serves. A device being retired or wiped, or one Intune has only discovered, is never targeted.
My Devices. A My Devices tab shows each user the devices they’re the primary user of in Intune, with manufacturer, operating system, ownership, category, and whether the device can reach company resources. It’s off by default; turn it on under Store Administration > Storefront. With its check-in setting on, a Check in now button asks the device to check in with Intune, the same as Sync in the Company Portal app. The button needs the optional DeviceManagementManagedDevices.PrivilegedOperations.All permission; without it, selecting the button reports that the permission is missing.
Chargeback reporting. A chargeback report shows what each department owes for the software its people have been granted, by department and by app, for the current quarter, the last 90 days, or any date range, with a CSV export of one row for each entitlement. Totals use each app’s current Cost. The price when each entitlement was granted is recorded in the CSV as Cost When Granted and isn’t added to the totals. An app with no price is reported as unpriced, not as free.
Compatible apps filter. The store can open filtered to the kind of device someone is browsing from, with a second setting that controls whether they can look past the filter. It’s off by default and set under Store Administration > Storefront.
Read access to the API for managed identities. Automation such as an Azure Automation runbook can call seven read endpoints of the App Store API with its own managed identity, using an app registration with an application role named AppStore.Automation.Read. Enter the Application ID URI in Workload API audience (optional) when you deploy, or in the App Service setting AzureAd__WorkloadApiAudience. Access is off until that setting has a value. A managed identity can’t approve or reject a request. See Call the API from Azure Automation.
Request acknowledgments are recorded. Each request for an app that requires acknowledgment writes a Request.Acknowledged entry in Reports > Analytics > Audit Trail, with who acknowledged, when, and the acknowledgment text as it was when the request was submitted. Select Multiple can now request apps that require acknowledgment: the dialog lists each one with its text, and one checkbox covers them all.
All Requests and Retry. Administrators find every request, including failed ones with their technical reason, on the new Approvals > All Requests page, and the request email links to it. A request that failed before it was delivered can be delivered again with Retry, once its app can deliver. Each retry is recorded in the audit trail. See Retry a failed request.

Product Enhancements

Failed requests say why. The store says what happened to each request as soon as it’s sent, including requests made with Select Multiple, and warns before you request an app that can’t be installed right now. My Requests shows the reason for a failed request and a request ID. A request that can’t be delivered is never shown as installed.
Requests made for you appear in My Requests. A request someone made on your behalf appears in your My Requests, with who made it, and its emails are sent to you. Only the person who made a request can cancel it.
A rollback pauses automatic updates for the app. The version you rolled back from is declined. App Updates shows Auto-deploy paused (rollback) on the app’s row, and Resume Auto-Deploy ends the pause after a confirmation. Nothing else ends it. Deploy Update still deploys a newer version, and Deploy anyway deploys the declined version after a confirmation.
Rollback offers only versions it can restore. You can roll back to the version an app was first published at. Roll back to previous version offers the same versions as Version History, names the version it restores, and says why when no earlier version can be restored. One rollback of an app runs at a time. Number of rollback versions to retain counts only versions you can roll back to.
A rollback made while an update is packaging stays rolled back. A rollback stops the updates still packaging for newer versions, and Packaging Jobs shows each stopped job as failed with the reason. A failed rollback says what was written to Intune, and rolling back again repairs it.
An updated install app describes the version it installs. After an update or rollback, App Store sends the version, setup file, install and uninstall commands and detection rule to Intune again, reads them back, and compares them with what it sent. If they don’t match, the update or rollback fails, and Update Deployments shows Needs attention with Retry packaging job.
Updates keep the app’s requirements. An update carries the Minimum Operating System, Disk Space Required and Physical Memory Required the app was published with, and its update app gets the install app’s Operating System Architecture as Intune holds it. Before, an update app always applied to x64 and x86 devices running Windows 10 1903 or later.
App Updates shows what is happening. Check Now reports an update it finds and offers Deploy Update, or says the check failed or the version was declined. The Update Rings card reads Not set until a deployment style is saved, and the page says when automatic deployment is waiting for one. Deployment history names the administrator who deployed an update. Update panels show why App Store refused an action. Halt rollout says what it does, and a halted rollout reads Stopped.
Uninstalls find the app Windows installed. An EXE app published without PSAppDeployToolkit (PSADT) carries an uninstall script that finds the installed app with the same rule as the app’s detection rule, runs its quiet uninstall command or adds the silent switch for its uninstaller type, waits for it to finish, and returns its exit code to Intune. PSADT-wrapped apps, including NSIS apps such as Mozilla Thunderbird, get the silent switch for their installer type. MSIX and APPX apps are uninstalled with Remove-AppxPackage. The publish and upload wizards preview the uninstall command App Store sends.
Detection tells an app apart from its siblings. Detection for an EXE app ignores hidden entries, entries for another architecture or product line, and names that differ by a + or #, so the x86 Microsoft Visual C++ Redistributable no longer counts as the x64 one. An x64 app whose 32-bit installer registers it in the 32-bit part of Add or Remove Programs, such as ApSIC Xbench, is detected when the program file shows it’s a 64-bit program.
Packaging reads WinGet manifests the way WinGet does. Packaging uses exactly the version you chose and checks the installer against the catalog’s published hash. It prefers a machine-wide installer, refuses a package that offers only per-user installers, and uses the silent switches for the installer type. It reads a nested installer named under each installer, reads manifest-wide settings only from the top level of the manifest, reads quoted values and values followed by a comment correctly, and detects an MSI inside an archive as an MSI. A vendor that blocks automated downloads is named in the job’s message.
Publishing from the App Catalog sends what you enter. Name, Publisher and App Version are read-only and match the package. Information URL, Privacy URL, Featured app in Company Portal, Developer, Owner, Notes and Logo reach Intune, and Category puts the app in the Intune category of that name. The wizard fills Description and the URLs from the package’s manifest, offers the package’s architectures, and describes the installer that will be packaged. A published app appears in App Management, hidden, as soon as packaging completes.
Already Published means this App Store published the package. An app with the same name that this App Store didn’t publish no longer blocks the publish, and App Store refuses to publish a package twice.
Custom WinGet repositories are used everywhere. When Catalog Repository URL names your own repository, the App Catalog lists every package in it and packaging downloads manifests from it. Sync catalog now refreshes the catalog on demand, Store Administration > System shows the last refresh and its result, and a failed refresh is tried again.
One version order. App Store orders versions the way WinGet does, except that a number inside a pre-release or letter suffix counts as a number, so 4.0beta44 is newer than 4.0beta9. A version with a suffix, such as 2026.8.5-1, is older than the same version without one.
Store Health shows only what App Store measures. Store Health shows system health with each check’s latency, request figures and errors, for the last hour, 6 hours, 24 hours or 7 days. It adds checks for Rollback package protection, Microsoft Graph permissions, apps that can’t deliver a request, apps nobody can approve, and apps deleted in Intune. The Database check reports Unhealthy when App Store can’t reach the database.
App Store recovers from a Microsoft Graph token without its permissions. When Azure issues the managed identity such a token after a restart, App Store uses its other Microsoft Graph token, and Store Health says so.
Approvers decide in App Store. Approval emails and Teams cards link to the request on the new Pending Approvals page, where the approver selects Approve or Reject. Approval emails no longer carry Approve and Reject buttons.
Approvers in nested groups are notified. Approval emails, reminders, Teams cards and escalation emails go to every user in a group, nested groups included. A Linear stage that names only a group notifies that group. The escalation email opens the request in All Requests for administrators, and carries the request details for other recipients.
Group Automation notifications are sent. The three Group Automation options on Communications email the App Store administrators and the administrator who created the automation, and message them through the Teams bot when it’s on.
The person who deploys App Store can administer it straight away. The deploying account becomes the initial administrator on the first start, and Admin Group members administer alongside that person. Administrators are never locked out by the User Access Group, which now applies to every API address and only to people.
Store Administration gains a Storefront node. Storefront holds maximum featured apps, categories on the home page, the hero app, the compatible apps filter, and the My Devices tab with its check-in setting. Catalog sourcing moves to Store Administration > System, and the App Catalog page no longer has a Catalog Settings panel.
App Store checks the package it runs. App Store confirms its package against the published checksum for its release channel and pins itself to that version. An installation upgraded from 1.38 records its package on its first start.
Times show in your own time zone. Pages show times in the viewer’s time zone, and times in emails and Teams cards end in UTC.

Bug Fixes

Resolved a requester being able to approve their own request. The requester, and the person a request was made for, can never decide it.
Resolved Teams notifications not being delivered since 1.33.0. Notifications and Test now send as the bot, and the bot sends its welcome message once.
Resolved making an app visible with Auto-create group removing the group it created, so approvals added nobody to a group.
Resolved removing a device or user from a Microsoft Entra ID group failing every time, which stopped Group Automations from removing stale members.
Resolved requests for apps assigned to devices never adding the device to the deployment group.
Resolved bulk requests treating apps assigned to devices as assigned to users.
Resolved an app deleted directly in Intune staying in App Management. App Store checks every hour, removes an app it holds nothing for, and labels an app it holds groups, updaters, history or requests for Deleted in Intune.
Resolved Delete from Intune removing App Store’s records when Intune refused to delete the app.
Resolved a publish reporting success when Intune refused the assignment.
Resolved changing an app’s deployment group leaving the old Intune assignment in place.
Resolved Featured App in App settings not reaching Intune.
Resolved settings saved during an Intune sync being undone when the sync finished.
Resolved the setup wizard resetting settings it doesn’t show.
Resolved the release channel on Store Administration > System not being saved.
Resolved Auto-deploy updates when detected not being saved.
Resolved Publish to Intune sending earlier values instead of the ones on the Requirements step.
Resolved looking up a package clearing its popularity rank and category, or renaming its tile, in the App Catalog.
Fixed Install Failed in Reports > Analytics counting requests that were never delivered.
Fixed the Reassign dialog opening its search results below the window.
Fixed the BI for Intune connection appearing empty for up to five minutes after Save connection.
Fixed the license banner staying on the page after the license was saved.
Fixed an app’s name being hard to read at the top of its page in App Management and App Updates.
Fixed browsers showing the previous version’s pages after an update.
Fixed sign-in on a managed device waiting about 20 seconds before redirecting.
Fixed Terms of Service written as plain text losing their line breaks.
Fixed CSV exports so that a value starting with an equals sign isn’t run as a spreadsheet formula.
Fixed signed storage addresses and package encryption keys being written to the application logs.
Fixed app suggestion emails including what users typed as HTML.
Fixed help text and messages that described the Admin Group, approvers, custom domains, the Teams app installation, the GitHub token and Getting Started incorrectly.
Updated System.Security.Cryptography.Xml to 8.0.5, System.Security.Cryptography.Pkcs to 8.0.2, DOMPurify to 3.4.17 and React Router to 7.18.4, which address published security advisories.

Important Notes

[Action Required] Grant Device.Read.All to the managed identity. The App Service’s managed identity needs the Microsoft Graph Device.Read.All application permission. Without it, a request for an app assigned to devices is approved, but the device never reaches the deployment group, so nothing installs. If you already use Group Automations, the managed identity has it. Grant it to the managed identity, not to the app registration. See Grant Microsoft Graph permissions.
Optional: grant DeviceManagementManagedDevices.PrivilegedOperations.All if you want users to have Check in now on My Devices. A new grant can take up to a day to reach App Store. Stopping and then starting the App Service applies it sooner; restarting doesn’t.
[Action Required] Set an Admin Group if your installation has none. An upgrade doesn’t take administrator access away from anyone. If your installation has no Admin Group, every signed-in user can still administer App Store after the upgrade, as before, until you save an Admin Group; redeploying doesn’t end this. To set one, go to Admin > Store Administration > Permissions, choose the Admin Group, and select Save. From then on, only Admin Group members administer App Store. See Store Administration.
New installations use a different administrator model. A new deployment makes the person who deployed it the initial administrator, and Admin Group members administer alongside that person. Other signed-in users aren’t administrators. Deployments run by a service principal or a managed identity have no initial administrator and need an Admin Group.
[Action Required] Check catalog packaging if you use a custom WinGet repository. The upgrade turns on Verify manifest integrity against Microsoft’s signed index once, even if it was off. If you turn it off again, it stays off. While it’s on, a package that isn’t in Microsoft’s WinGet community index, such as one only in your own repository, is refused with “Manifest integrity check failed”. To package such apps, turn the setting off under Admin > Store Administration > System > Catalog Sourcing.
The tenant approver group becomes workflows. In a store that had an approver group, the upgrade writes it down as a workflow named “Migrated from tenant approver group” on each app that relied on it, so the same people approve the same apps. Review them under Automations > Approval Workflows.
[Action Required] Turn on rollback package protection. An in-place upgrade from 1.38 doesn’t turn on blob versioning or soft delete. In the Azure portal, open the App Store storage account, go to Data management > Data protection, and turn on 30-day soft delete for blobs and for containers, and versioning for blobs. Store Health’s Rollback package protection check shows what’s missing. See Disaster Recovery.
[Action Required] Review approval stages that have more than one condition. Until you save the workflow again, such a stage from 1.38 ignores its conditions and applies to every request. Automations > Approval Workflows, the app’s Approval Settings and the Approval step of App settings name the stages. Check the order of the conditions, select Keep this order, and save. See After an upgrade from 1.38 or earlier.
[Action Required] Set up approval for apps marked Approval not set up. In a store that had no approver group, an app that requires approval refuses new requests until a workflow can decide them. Choose a workflow for each app, or create a default workflow. Requests that were waiting during the upgrade appear under Approvals > Pending Approvals > All Pending Requests; select Reassign to choose who decides each one.
[Action Required] Deliver requests that 1.38 approved but didn’t deliver. App Store restores the deployment groups that 1.38 removed and marks those requests Failed with the reason. In Approvals > All Requests, select Retry on each one you want to deliver.
Breaking change: only a native ARM64 installer reaches ARM64 devices. Every app App Store creates names its allowed architectures: x64 for an x64 installer, x86 and x64 for an x86 or neutral installer, and ARM64 for a native ARM64 installer. All architectures is no longer offered, and a 32-bit Arm installer can’t be published. Apps you already published keep their requirement and assignments, and their updates keep the requirement. An update or rollback that would put another architecture’s installer under the requirement is refused. Approvals and Retry leave out devices the requirement doesn’t serve.
Breaking change for API callers. osArchitecture on POST /api/packaging/jobs and POST /api/admin/app-upload/publish accepts x64, x86 and arm64, in any letter case, or no value. x86 now means x86 and x64 devices. All is refused with 400, and arm64 is accepted only with the package’s native ARM64 installer.
Breaking change: Swagger is off unless you turn it on. The Swagger UI at /swagger and the OpenAPI description at /swagger/v1/swagger.json are off. To turn them on, set the App Service setting AppSettings__EnableSwagger to true. See The OpenAPI Spec.
Logos and icons must be PNG or JPEG. Files in other formats are refused when you upload them, and files aren’t converted. A custom app icon can be up to 1 MB.
Updates and rollbacks change the app’s existing install app. An update replaces the install app’s content in Intune and keeps its assignments, and a separate updater app carries the update to devices that already have the app. A rollback restores the earlier version’s package into the same install app.
Existing apps keep their uninstall command and detection rule until their next update. An app that isn’t getting updates keeps its old uninstall command, and so does the uninstall phase of a PSADT-wrapped app. To uninstall such an app, in the Intune admin center select Apps > Windows, select the app, select Properties, select Edit next to Program, and enter the vendor’s silent uninstall command in Uninstall command. App Store replaces it at the next update or rollback.
The uninstall script isn’t signed. If your tenant enforces the AllSigned execution policy for Windows PowerShell, the uninstall script is blocked and the uninstall fails. Set your own Uninstall command on those apps.
Rolling back apps published with 1.38. The next update keeps the package of the version it replaces only if the packaging job that published that version is still listed under Packaging Jobs on the App Catalog page.
Some apps are offered an update once. Because of the new version order, an app at a version with a suffix, such as 2026.8.5-1, is offered the plain version, and an app can be offered an update from a pre-release to its release.
Packaging jobs stuck before the upgrade are picked up shortly after App Store starts. A job nothing has worked on for more than a day is marked Failed; retry it if you still need it.
Packages that are still refused. A package whose installer is a portable app inside an archive, or an archive whose manifest doesn’t name a file to run, is refused. Use Custom app upload for these.
Known issues. These issues are known in this release. Each has a workaround.
- A rollback shows no progress, and a second click replaces the result. Roll back to previous version can take about a minute, shows no progress, and stays available. A second click is refused, and its “Nothing was rolled back” message replaces the card’s text although the first rollback succeeded. Nothing is rolled back twice. Select the button once and wait. If the card says nothing was rolled back, refresh the page and read Current Version before you try again.
- App Updates doesn’t show the result of an action. After Resume Auto-Deploy, Deploy Update, Check for Updates or Dismiss, the page shows no confirmation, and a failed Check for Updates or Dismiss shows no error. Read the table after the action: after a resume, the row’s pause text is gone; after a check, Last checked changes. Reports > Analytics > Audit Trail records each action.
- A restart during publishing can leave the job Failed. If the App Service restarts while an app is being published, the packaging job can end as Failed instead of resuming. Nothing reaches Intune, and no duplicate is created. Select Retry on the failed packaging job.