The old Discovered apps report had one fundamental problem. It refreshed on a seven-day cycle. By the time data reached you, it was already stale. Decisions made on week-old software inventory are decisions made with incomplete information, and in environments where applications install and change constantly, a week is an eternity.
That is the core issue the enhanced app inventory in the All Apps tab addresses, released as generally available with the May 2026 Intune update
Why Discovered Apps Was Never Enough
Discovered apps was never a real-time inventory tool. It gave you a tenant-wide count of what was installed across enrolled devices, refreshed slowly, and collected only a basic set of data. You could see that an application existed. You could not see where it was installed, when it arrived, how big it was, or how to remove it without going to the device directly.
The data source behind it is the WMI class Win32_InstalledWin32Program. You can query it directly on any device:
Get-WmiObject -Class Win32_InstalledWin32Program | Format-List -Property Name, Version, ProgramId, Vendor, Language
That returns Name, Version, ProgramId, Vendor, and Language per installed program. ProgramId is the store-level identifier. Language maps to the supported languages field. What Discovered apps always lacked was the additional properties that sit outside this class install path, install date, uninstall command, size on disk, architecture, and per-user scope all require additional WMI queries to collect. The old report simply did not collect them.
On shared devices the problem was worse. Inventory only captured data for the user who was currently signed in. Any app installed under a different user profile was invisible until that person logged back in. On machines that multiple people share, the inventory was never accurate.
There was also nothing useful in Discovered apps for actually acting on what you found. If you spotted an unauthorized application and needed to remove it, you still had to go find the install path and uninstall command yourself. None of that was in the report. And there was no way to configure any of it. Discovered apps ran on all supported devices automatically. You could not scope it to a subset of machines or turn it off for specific groups. It was all-or-nothing.
What Changed in the April update with SR2605
Microsoft changed both the upload model and the underlying data platform. The new app inventory is built on the same modern data platform that device inventory introduced. That platform was designed for continuous, high-frequency data collection, which gives it more capacity and lower latency than what Discovered apps ran on. The result is that data arrives in the portal faster and the infrastructure can handle the volume of a constantly updating fleet without degrading.
On top of that, the agent now uploads only what changed since the last sync rather than sending a full snapshot every cycle. Both things together — the new platform and the delta upload model — are why multiple updates per day per device is now possible without generating proportionally more traffic.
Active, healthy Windows devices now get inventory updates multiple times per day. The agent does not wait for the regular MDM check-in, per the policy refresh interval documentation. App inventory uploads run on their own separate schedule through the inventory channel.
The data collected per application has also grown. For each app, the agent now collects the following, as long as Windows registered the information at install time:
- Install path
- Install date
- Uninstall command
- Estimated size on disk
- Architecture (x86, x64, ARM64)
- Per-user install scope
- Store-specific identifiers
- Supported languages
Per-user install scope tells you whether an app was installed for all users on the machine or just for one specific user profile. That matters when you plan a removal action, because the approach is different depending on scope.
Supported languages and store identifiers were not in Discovered apps at all. They are useful when you need to audit which locale versions of software are running across the fleet, or when license compliance depends on store identity.
The Shared Device Problem Is Fixed
The old inventory only looked at the signed-in user. Any app installed by someone else on the same machine was missing from the picture until that person came back. On shared workstations, kiosk machines, or lab devices, this meant the inventory was always incomplete.
The new agent collects app data across every user who has ever signed in to the device, not just the current one. If three people use the same machine and each installed something under their own profile, all three show up in the inventory at the same time.
That matters for shadow IT scenarios specifically. The gap where a user installs something unauthorized, logs off, and the next inventory cycle misses it because a different user is now signed in, that gap is gone.
How the Pipeline Works
If you have read the earlier posts on how device inventory flows through MMP-C and how to set it up with Resource Explorer, app inventory runs on the exact same infrastructure. Knowing the pipeline matters for troubleshooting, so it is worth going through.
You create a Properties Catalog profile in the Intune admin center and assign it to devices. Intune then hands it off to MMP-C (Microsoft Management Platform – Cloud). MMP-C wraps the profile as a Declared Configuration document (WinDC) and queues it for delivery on the next device sync.
This is not the same as how standard MDM policies are delivered. The Declared Configuration model works on desired state. The device gets a document that says what state it should be in and works toward that state. There are no back-and-forth commands. This is the same channel that delivers hardware inventory policies and the same one that Endpoint Privilege Management uses.
When the document lands on the device, it installs the Microsoft Device Inventory Agent if it is not there yet. The agent lives at C:\Program Files\Microsoft Device Inventory Agent and runs as a Windows service called InventoryService.
The agent uses WMI queries to collect application data and writes everything into a local SQLite databases at C:\Program Files\Microsoft Device Inventory Agent\InventoryService\ You can open that database directly if you want to check what the agent has collected before it uploads.
The first harvest runs after a random delay. That is by design. Without it, rolling out a Properties Catalog policy to a large fleet at once would cause thousands of devices to upload simultaneously. After that first harvest, everything is incremental.
Uploads go to manage.microsoft.com. You can watch this in Fiddler if you want to confirm the agent is actually sending data. Once the data reaches the Intune backend, it shows up in the All Apps tab per device.
App inventory vs Discovered Apps
These two views are not the same thing and they come from different data sources.
Discovered apps is the tenant-wide aggregate. It shows total counts of application versions across enrolled devices. It is still useful for fleet-level questions, like how many devices are still running an old version of something.
App Inventory is the per-device view. It is where the faster, richer data lands. For each device you get a full list of both managed and unmanaged apps, with all the metadata listed above. This is the view you use for incident response, investigating unauthorized software, and device-level compliance work.
Discovered apps can be exported to CSV and is accessible through the Microsoft Graph API. The enhanced All Apps data is not yet available via Graph. Microsoft has indicated that Graph support is planned hopefully later in 2026, but it is not there now. Until it is, the All Apps view is portal-only and cannot be pulled into external tooling or automation workflows directly.
App Inventory is clearly where Microsoft is investing. The “In development” documentation confirms that more platforms will follow after Windows. Discovered apps is not going anywhere yet, but over time All Apps replaces what it does and then some.
What You Need to Configure
You need a Properties Catalog device configuration policy assigned to corporate-owned Windows 11 devices enrolled in Microsoft Entra ID. Devices must be either Microsoft Entra joined or Hybrid joined.
Go to Devices > Windows > Configuration, click + Create > New Policy, select Windows 10 and later as the platform, and pick Properties Catalog as the profile type.
Click Next, give it a name and click Next. Click on + Add properties
Now here we have the extended properties available for applications, advise here is to add all the properties available. Nothing is enabled by default. Every property is off until you turn it on. Select the application inventory properties you want to collect. Enable the app-related entities from the catalog.
Add scope tags and assignments like any other configuration policy. Assign to a test group first before rolling it out to the full fleet.
Once the policy reaches a device and the agent finishes its first harvest, data starts showing up in the All Apps tab on the next check-in. There is no policy status report for Properties Catalog. You will not see a green success indicator like you would for a settings catalog policy. You have to look at the device directly in All Apps or Resource Explorer to confirm that data is coming in.
If you delete the Properties Catalog policy later, the last collected data stays visible in Device Inventory for up to 28 days before it clears.
Intune Admin experience
When going to a device in Intune (new device view experience), click on Tools and reports
Click on All Apps
This will give us the new App Inventory view where we can search, add extra columns.
Troubleshooting
The app inventory pipeline is the same as hardware inventory. The troubleshooting steps are the same too.
Start with linked enrollment. MMP-C requires dual enrollment. The device has to be enrolled in both Intune and MMP-C. Without that, the Declared Configuration documents never reach the device and the agent never installs. Check the registry for the LinkedEnrollment key to confirm it is in place.
Check the agent is installed and running. Confirm the folder exists at C:\Program Files\Microsoft Device Inventory Agent and that the InventoryService Windows service is actually running. If the folder is there but the service is stopped, try starting it and look at the logs immediately after.
Check that the Declared Configuration policies landed on the device. If the profile came down correctly, the declared policy documents will be visible in the registry. Use the SyncML tool and trigger an MMP-C sync to check whether the documents are arriving. If they are not arriving, the problem is before the agent, not in the agent.
Read the agent logs. Logs are at C:\Program Files\Microsoft Device Inventory Agent\Logs. These are the main source for understanding what the agent is doing and where it breaks. You can also pull them remotely using the Collect Diagnostics action from the Intune admin center, so you do not need to be at the device.
Check the SQLite database. If the logs show the agent running but nothing appears in the portal, open the database file directly. If it is empty or zero bytes, the agent has not completed a harvest yet. If the database has data but the portal shows nothing, the upload to manage.microsoft.com is failing, and that will show up in network diagnostics.
MDM diagnostic logs for MMP-C communication problems. If Declared Configuration documents are not arriving on the device at all, collect the MDM diagnostic logs and look for errors connecting to MMP-C. A device that cannot reach MMP-C endpoints will never get the policy regardless of what the Intune sync says.
One specific error to know: SQLite Error 1: 'no such table: InventoryEventCollector' in the agent logs means the agent installed but the inventory adaptor component did not. The InventoryAdaptor subfolder will be missing from the agent directory. This usually fixes itself after a clean sync once the linked enrollment is confirmed healthy.
Conclusion
More frequent inventory changes what questions you can answer with confidence.
With a seven-day cycle, an unauthorized application could be installed, used, and removed before inventory ever captured it. You would never know it was there. With multiple updates per day, the window between installation and detection shrinks from days to hours. That is a real difference for incident response and compliance auditing.
The extra metadata changes what you can do with that detection. If you find an unauthorized app, the uninstall command is already in the inventory. A remediation script can use it immediately without needing to probe the device for that information first. The install path matters for application control policy audits and antivirus exclusion reviews. Knowing the install scope tells you right away whether a removal needs to target the machine or a specific user profile.
The multi-user collection matters most on shared devices. Environments with hot-desking, shift work, shared labs, or kiosk machines were always a weak spot for inventory accuracy. That is no longer the case.
This is Windows only for now. Microsoft has said more platforms will follow, but no date has been given. The agent infrastructure for hardware inventory already exists on the Apple and Android sides, so app inventory on those platforms is a question of timing, not whether the architecture supports it.