If you’ve ever stared at the Discovered Apps report in Intune and wondered how a tool this important could show you only an app name and version — you’re not alone. That report has been quietly limping along for years while admins filled the gap with PowerShell, third-party tools, and manual audits.
That changes with the May 2026 Intune update. App Inventory is now generally available, and it’s a fundamentally different mechanism — not a column or two added to the old report, but a separate agent, a separate delivery channel, and data that’s actually usable for real work.
This guide covers what changed, how to get it running, what the agent is actually doing under the hood, and a few things Microsoft hasn’t put in the docs yet.
What Exactly Changed (and Why It Matters)
The old Discovered Apps report collected data via the Win32_InstalledWin32Program WMI class. That class returns DisplayName and DisplayVersion. That’s it. It updates roughly weekly. It doesn’t tell you whether an app is installed per-user or machine-wide. It doesn’t give you an uninstall string. It doesn’t distinguish between x86 and x64 versions.
The new App Inventory collects data through a dedicated Microsoft Device Inventory Agent, which runs on the MMP-C (Declared Configuration) channel rather than the classic OMA-DM channel. The practical result is a report with 17+ columns, updated multiple times per day, that gives you data you can act on.
Here’s the comparison that makes this concrete: community testing has shown the same device returning 50 apps in Discovered Apps and 828 apps in App Inventory. Same machine. Same day. The gap isn’t a bug — it’s the difference between what WMI exposes and what a dedicated inventory pass across all registry hives and package manager APIs actually finds.
Microsoft has added a deprecation banner to the Discovered Apps report. There’s no published end-of-life date yet, but the direction is clear.
Data Available in App Inventory
The columns worth understanding:
Installed for: Device or User scope. Finally answers the “is this per-profile or machine-wide” question without digging through the registry manually.
User name / User Entra ID / SID: Three ways to identify who installed a per-user app. On shared devices where multiple accounts cycle through, the inventory tracks all users who have ever signed in, not just whoever is currently logged in.
Architecture: x86, x64, ARM64, or Neutral. More useful than it sounds when you’re tracking down a packaging deployment that installed the wrong variant.
Install location: The actual path. Useful for apps that install to non-standard directories and break detection rules.
Estimated size: Helpful for identifying large installs on devices running low on disk.
Uninstall command / Modify command: The actual MsiExec.exe /X{...} string or path to the EXE uninstaller. This is significant. You can use this data to build uninstall scripts for apps that aren’t managed through Intune.
Package name: MSI product code for Win32 apps, package full name for Store/MSIX apps.
Last updated: Timestamp for when the inventory entry was last refreshed, so you know how current the data is.
Prerequisites
Before creating the policy, confirm the device meets these requirements:
- Windows 10 or Windows 11
- Microsoft Entra joined (Hybrid Entra join is supported; pure AD-only is not)
- Enrolled in Intune
- Not in the Microsoft Azure operated by 21Vianet sovereign cloud (GCC High tenants are supported)
App Inventory is Windows-only for now. iOS, Android, and macOS devices don’t receive the policy.
How to Enable App Inventory
The most important thing to know upfront: App Inventory does not auto-collect. Unlike Discovered Apps, which runs whether you want it or not, App Inventory requires an explicit device configuration policy. No policy assigned to the device means no data in the report.
Here’s how to create it:
- Open the Intune admin center and go to Devices > Manage devices > Configuration.
- Select Create > New policy.
- Platform: Windows 10 and later.
- Profile type: Properties catalog.
- Click Create and give the policy a name.
- In Configuration settings, click + Add Properties, then select ApplicationProperties.
- Choose which properties to collect. Seven properties are required and cannot be deselected.
For a first deployment, enable everything. You can trim later, and you won’t know what you’re missing if you haven’t seen the full picture. The additional data overhead is minimal. The agent sends delta updates after the first full sync.
- Assign the policy to your target device groups. Corporate-owned Windows 10/11 devices enrolled in Entra ID are the intended target.
Data doesn’t appear in the report until at least one MMP-C sync cycle has run after policy assignment. On active devices this typically happens within a few hours.
Under the Hood: What the Microsoft Device Inventory Agent Actually Does
This is where understanding the mechanism pays off, because it’s where troubleshooting starts when things go wrong.
The Microsoft Device Inventory Agent (InventoryService.exe) has been present in Windows environments for a while. It was previously used for device hardware inventory. Microsoft is now extending the same agent to handle application inventory. It runs as its own Windows service with its own installation directory and its own log files — separate from the Intune Management Extension entirely.
The agent runs two collection passes and merges the results.
Pass 1: Win32 apps via registry enumeration. The agent walks three registry paths in sequence:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall(64-bit, native view)HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall(32-bit view via Wow6432Node)HKEY_USERS\<SID>\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstallfor every loaded user profile
For each key it collects DisplayName, DisplayVersion, Publisher, InstallDate, InstallLocation, UninstallString, ModifyPath, EstimatedSize, and Language. Anyone who’s written a PowerShell inventory script will recognize this pattern. The difference is a native agent with caching and delta sync built in.
Pass 2: Store and MSIX apps. The agent calls Windows.Management.Deployment.PackageManager.FindPackages(). This is a native Windows API with nothing to do with WinGet. It enumerates MSIX and Store app packages installed on the device.
Both results get merged, de-duplicated, and cached locally in a JSON file and a SQLite database before being uploaded. The cache allows delta updates rather than full inventories on every check-in.
Policy delivery. Properties Catalog policies don’t travel over the classic OMA-DM channel. They use MMP-C (Declared Configuration). Windows receives the declared configuration document and writes policy contents to a registry path. InventoryService.exe watches that path for changes. When the policy lands in the registry, the agent picks it up, runs its collection passes, and uploads the result.
Sync Frequency and Timing
The official guidance says inventory updates run with the MMP-C sync cycle, which is more frequent than the traditional 8-hour MDM cycle — described as “multiple times per day” for active devices.
There’s a wrinkle worth knowing. The agent maintains an internal cache with its own TTL. Even if MMP-C wakes the agent up frequently, the agent doesn’t necessarily re-enumerate the full registry on every check-in. Sometimes it replays its cached snapshot. If you uninstall something and then watch the report for it to disappear, you might be waiting a few hours even if MMP-C fires multiple times in between.
That said, a few hours is categorically different from the roughly seven-day lag that plagued Discovered Apps.
The first sync is a full upload. Every subsequent sync sends only the delta: new, changed, or removed apps.
Troubleshooting When Data Doesn’t Show Up
Two log files matter here. Knowing which one to check first saves meaningful time:
| Log File | What It Tells You |
|---|---|
%ProgramFiles%\Microsoft Device Inventory Agent\Logs\InventoryAdaptor.log | Did the policy arrive on the device via MMP-C? |
%ProgramFiles%\Microsoft Device Inventory Agent\InventoryService\Logs\HarvesterLog.log | Did the agent run, harvest, and upload? |
If InventoryAdaptor.log is empty or silent: The policy isn’t arriving. Check group assignment, device scope, and MMP-C delivery. Confirm the device is Entra joined and that the Properties Catalog policy shows as applied in the device’s configuration profile list.
If InventoryAdaptor.log shows policy arrivals but HarvesterLog.log is silent: The agent isn’t running. Open services.msc and look for Microsoft Device Inventory Agent. If the service is stopped, start it and check the startup type. Look for error events in the Windows Application event log under the InventoryService source.
You can also verify the agent is installed at %ProgramFiles%\Microsoft Device Inventory Agent. If that directory doesn’t exist on a device that should have App Inventory enabled, the agent hasn’t been deployed yet. On first policy assignment the MMP-C sync installs it automatically. If it’s still missing after several hours, something in the MMP-C delivery chain needs investigation.
The 1,000-App Hard Cap
This one isn’t in the Microsoft docs yet. The inventory agent has an internal constant: MaxApplicationCount = 1000.
The agent will only process up to 1,000 apps per device. For most corporate workstations, this won’t matter. For developer machines, shared devices, lab endpoints, or older machines that have accumulated apps over years, it could result in incomplete inventory data.
The error code for hitting this limit is 0x80511001 (E_APPLICATION_COUNT_EXCEEDED). If app inventory looks incomplete on a specific device, search HarvesterLog.log for that error code. Community testing with an 828-app device suggests the limit is closer than most would expect.
Microsoft may raise or remove this limit in a future update, but for now it’s a real constraint for any workflow that depends on completeness.
Practical Use Cases
Shadow software detection. With architecture, install path, install date, and uninstall command all available, you can build meaningful reports around apps that shouldn’t be on devices. Personal tools and unlicensed software that were previously invisible show up clearly when you’re pulling from the full user-profile registry hive rather than a WMI class.
Uninstall automation. The uninstall command field gives you the string needed to remove apps programmatically. Combined with a PowerShell remediation script in Intune, you can detect a specific app version and forcibly remove it without needing a separate Win32 app deployment configured for uninstall.
Per-user vs. machine-wide audit. The “Installed for” column answers a question that previously required logging into a device or parsing registry exports. On shared devices in education or healthcare environments, knowing the scope of each install is operationally significant for compliance and licensing.
Vulnerability prioritization. Pairing app inventory data with a CVE feed gives you a faster path from “this version is vulnerable” to “which devices have it.” That workflow is limited until Microsoft exposes App Inventory data via Graph API, but the admin center view is already useful for targeted remediation.
Current Limitations
No Graph API access. The App Inventory data is only accessible through the Intune admin center. You can’t query it via Microsoft Graph the way you can with Discovered Apps or other device data. This means no custom dashboards and no automated exports today. Microsoft hasn’t committed to a timeline.
Windows only. App Inventory covers Windows 10 and Windows 11 devices. Other platforms are not supported.
1,000 app limit per device. Described above.
Corporate-owned devices only. The Properties Catalog policy required to enable App Inventory targets corporate-owned, Entra-joined devices. BYOD and personally owned devices don’t receive the policy.
Admin center view only. The new App Inventory data shows in the updated device view in the Intune admin center. Devices accessed from reports or other portal areas may still show the old view during the public preview period.
What to Do Right Now
Create a Properties Catalog policy with all ApplicationProperties enabled. Assign it to a test group first and wait for the first MMP-C sync. Check the All Apps tab in the device view for a device in that group. If you see significantly more apps than Discovered Apps showed, you’re collecting data.
From there, scope the policy to your production device groups and start building the workflows that the Discovered Apps data never made possible. The Graph API gap is real, but the in-portal data is already useful for auditing, compliance work, and targeted remediations.
The Discovered Apps report is going away. App Inventory is what comes next. Start enabling it now so you’re not scrambling to catch up when the old report gets removed.