Microsoft has added native Windows Registry Inventory to Microsoft Intune with the July 2026 Service Release 2607, giving IT administrators a built-in way to collect selected registry data from managed PCs without writing and maintaining custom PowerShell discovery scripts. For Windows estates that use registry values as the real proof of application state, security configuration, and policy delivery, the change closes a long-standing visibility gap in Intune.
The new capability is delivered through Intune’s existing Properties catalog and surfaces results in the Device Inventory page. Microsoft’s Intune team says administrators can define the registry locations they need to inspect, assign the inventory profile to managed devices, and receive the discovered key path, value name, value type, and value data as devices check in.
That is a modest description for a feature with potentially outsized operational value. The registry is still where a remarkable number of Windows settings, installer records, security controls, feature flags, and vendor-specific application states ultimately live. Intune could show that a configuration profile was assigned, but assignment has never been the same thing as confirming the endpoint actually reached the intended state.
Microsoft’s announcement, published through the Microsoft Tech Community, frames Registry Inventory as a way to validate a machine’s actual configuration, rather than just the policy targeted at it. That distinction matters most when a deployment appears successful in the admin center while a device is still missing a setting, has a conflicting local configuration, or is affected by a third-party installer that changed the registry after Intune applied policy.
Until now, an Intune administrator wanting tenant-wide evidence of a particular key often had to build a detection script, deploy it via Remediations, write the results somewhere useful, and then maintain that solution across Windows versions and application changes. For a single one-off issue, that can be reasonable. For recurring checks involving security baselines, application configuration, or patch-adjacent troubleshooting, the scripting overhead adds up quickly.
The reaction in the Intune administrator community illustrates why the announcement landed so well. A highly upvoted Reddit discussion described the feature as a “game-changer,” primarily because it removes the need to use custom scripts or Proactive Remediations merely to answer basic configuration questions. That is not an official benchmark of the feature’s impact, but it accurately reflects a familiar frustration among endpoint teams: data collection has often required almost as much engineering effort as the remediation itself.
Registry Inventory is a reporting and verification feature, not a registry-management replacement. It does not write values, repair drift, or automatically turn discovered data into a compliance decision. Those jobs still belong to Settings Catalog policies, configuration profiles, scripts, Remediations, application deployment logic, and other Intune controls.
For the registry configuration itself, an admin supplies a registry key path and, where applicable, a value name. Microsoft supports three initial collection patterns:
After a Windows device receives the profile and checks in, the collected material appears under Device Inventory. Microsoft documents that initial inventory collection can take up to 24 hours, a meaningful caveat for incident response and troubleshooting workflows. This is inventory telemetry rather than a real-time remote registry console; administrators should not expect a newly changed value to materialize instantly after a user or technician alters a machine.
The initial version is also intentionally constrained. Microsoft says Registry Inventory supports HKEY_LOCAL_MACHINE only, excludes other hives such as HKEY_CURRENT_USER, caps individual collected values at 6 KB, and limits registry collection to 100 keys per device. Those limits make sense as guardrails against indiscriminate data collection, but they will shape how organizations design profiles.
A practical implementation will favor focused questions over broad sweeps: “Is the Secure Boot servicing status present?” “Which version of this line-of-business agent registered?” “Did this hardening setting land?” “Which endpoints have the expected install state?” The feature is not designed to ingest the entire Windows registry into Intune, and treating it as one would create noise as well as potential privacy and security problems.
Microsoft specifically notes that the feature can help teams validate compliance and investigate security posture. It also includes logic intended to detect potentially sensitive or confidential registry values and prevent them from being collected. That protection should not be read as permission to inventory indiscriminately. Registry paths can contain user details, tokens, software configuration secrets, and product-specific operational data; endpoint teams should still apply data-minimization discipline before selecting a key for collection.
The HKLM-only limitation reinforces that boundary. It restricts the feature to machine-level information, which covers many enterprise configurations but leaves out user-context settings that may matter in heavily personalized or multi-user environments. Administrators who need to verify HKEY_CURRENT_USER values will still need a user-context script, a remediation package, an application-specific reporting mechanism, or another source of telemetry.
There is also an important difference between discovering a problem and operationalizing the answer. The community discussion around the release quickly raised requests for registry-derived inventory to become usable in device filters, assignment targeting, and Graph-based automation. Microsoft has said it plans to expand registry data access into more reporting and exploration experiences in coming months, but Device Inventory is the starting point. As of the initial rollout, organizations should plan for manual review or their existing reporting processes rather than assume the new values can immediately drive dynamic deployment logic.
Common examples include validating the presence and version state of an enterprise agent, confirming a hardening toggle deployed by a separate management mechanism, checking specific Windows configuration outcomes, or investigating an application whose installer records success differently from what Intune’s native app reporting reveals. It can also reduce the gap between a help desk report — “this one laptop behaves differently” — and an answer grounded in the device’s configuration data.
For co-managed environments, the feature may be especially useful during the long transition away from Configuration Manager-era inventory patterns. Microsoft’s documentation says Properties catalog collection supports Intune-managed devices, co-managed devices, Microsoft Entra joined devices, and Microsoft Entra hybrid joined devices. That provides a common route to inventory selected signals while organizations have mixed management histories and uneven application packaging.
The feature is included with Microsoft Intune Plan 1, so it does not appear to be positioned as a premium Intune Suite add-on. That matters because registry visibility is foundational endpoint-management functionality, not a specialist luxury. It should be available to the broad base of organizations that already use Intune to manage Windows devices.
Admins should therefore verify both portal availability and actual device results before retiring existing scripts. Build a narrowly scoped Properties catalog profile, deploy it to a test group, wait for the initial collection window, and compare its output with a known-good local registry query. That comparison will expose path errors, value-type assumptions, access limitations, and misunderstandings about how a vendor’s software records state.
It is also worth retaining any remediation that has a corrective purpose. A discovery script made redundant by Registry Inventory can likely be retired after validation. A Remediation package that detects and fixes a broken condition cannot: the new Intune capability tells an admin what is there; it does not change what is there.
Microsoft has finally provided the native evidence-gathering layer many Intune teams have wanted. The next test is whether it broadens Registry Inventory beyond the Device Inventory view — into reporting, query, automation, and policy targeting — without sacrificing the focused safeguards that make this first release manageable.
That is a modest description for a feature with potentially outsized operational value. The registry is still where a remarkable number of Windows settings, installer records, security controls, feature flags, and vendor-specific application states ultimately live. Intune could show that a configuration profile was assigned, but assignment has never been the same thing as confirming the endpoint actually reached the intended state.
Intune Moves From “Policy Sent” to “State Observed”
Microsoft’s announcement, published through the Microsoft Tech Community, frames Registry Inventory as a way to validate a machine’s actual configuration, rather than just the policy targeted at it. That distinction matters most when a deployment appears successful in the admin center while a device is still missing a setting, has a conflicting local configuration, or is affected by a third-party installer that changed the registry after Intune applied policy.Until now, an Intune administrator wanting tenant-wide evidence of a particular key often had to build a detection script, deploy it via Remediations, write the results somewhere useful, and then maintain that solution across Windows versions and application changes. For a single one-off issue, that can be reasonable. For recurring checks involving security baselines, application configuration, or patch-adjacent troubleshooting, the scripting overhead adds up quickly.
The reaction in the Intune administrator community illustrates why the announcement landed so well. A highly upvoted Reddit discussion described the feature as a “game-changer,” primarily because it removes the need to use custom scripts or Proactive Remediations merely to answer basic configuration questions. That is not an official benchmark of the feature’s impact, but it accurately reflects a familiar frustration among endpoint teams: data collection has often required almost as much engineering effort as the remediation itself.
Registry Inventory is a reporting and verification feature, not a registry-management replacement. It does not write values, repair drift, or automatically turn discovered data into a compliance decision. Those jobs still belong to Settings Catalog policies, configuration profiles, scripts, Remediations, application deployment logic, and other Intune controls.
The Properties Catalog Becomes the Collection Engine
Administrators configure Registry Inventory when creating a Windows Properties catalog profile. In the Intune admin center, that means selecting Windows 10 and later, choosing Properties catalog as the profile type, and adding registry properties alongside other inventory categories such as application data, TPM information, BIOS details, encryption signals, and hardware data.For the registry configuration itself, an admin supplies a registry key path and, where applicable, a value name. Microsoft supports three initial collection patterns:
- A single named value under a defined key can be collected for a targeted device.
- All values directly under a key can be collected, without recursively traversing deeper subkeys.
- The same named value can be collected across the immediate subkeys of a given registry location.
After a Windows device receives the profile and checks in, the collected material appears under Device Inventory. Microsoft documents that initial inventory collection can take up to 24 hours, a meaningful caveat for incident response and troubleshooting workflows. This is inventory telemetry rather than a real-time remote registry console; administrators should not expect a newly changed value to materialize instantly after a user or technician alters a machine.
The initial version is also intentionally constrained. Microsoft says Registry Inventory supports HKEY_LOCAL_MACHINE only, excludes other hives such as HKEY_CURRENT_USER, caps individual collected values at 6 KB, and limits registry collection to 100 keys per device. Those limits make sense as guardrails against indiscriminate data collection, but they will shape how organizations design profiles.
A practical implementation will favor focused questions over broad sweeps: “Is the Secure Boot servicing status present?” “Which version of this line-of-business agent registered?” “Did this hardening setting land?” “Which endpoints have the expected install state?” The feature is not designed to ingest the entire Windows registry into Intune, and treating it as one would create noise as well as potential privacy and security problems.
Security Visibility Comes With Deliberate Boundaries
The security use case is perhaps the clearest reason to welcome the feature. Registry keys frequently indicate whether a defensive control is enabled, whether a product component exists, whether a mitigation has been applied, or whether a known configuration has drifted. A device-level record inside the management platform can make it far easier to resolve cases where policy status and lived reality do not match.Microsoft specifically notes that the feature can help teams validate compliance and investigate security posture. It also includes logic intended to detect potentially sensitive or confidential registry values and prevent them from being collected. That protection should not be read as permission to inventory indiscriminately. Registry paths can contain user details, tokens, software configuration secrets, and product-specific operational data; endpoint teams should still apply data-minimization discipline before selecting a key for collection.
The HKLM-only limitation reinforces that boundary. It restricts the feature to machine-level information, which covers many enterprise configurations but leaves out user-context settings that may matter in heavily personalized or multi-user environments. Administrators who need to verify HKEY_CURRENT_USER values will still need a user-context script, a remediation package, an application-specific reporting mechanism, or another source of telemetry.
There is also an important difference between discovering a problem and operationalizing the answer. The community discussion around the release quickly raised requests for registry-derived inventory to become usable in device filters, assignment targeting, and Graph-based automation. Microsoft has said it plans to expand registry data access into more reporting and exploration experiences in coming months, but Device Inventory is the starting point. As of the initial rollout, organizations should plan for manual review or their existing reporting processes rather than assume the new values can immediately drive dynamic deployment logic.
Where It Will Save the Most Time
The strongest early use cases are likely to be routine but high-volume support and assurance tasks. An Intune team can target a small collection policy to a pilot group, validate results, then extend it across an appropriate device population without bringing a new script into production.Common examples include validating the presence and version state of an enterprise agent, confirming a hardening toggle deployed by a separate management mechanism, checking specific Windows configuration outcomes, or investigating an application whose installer records success differently from what Intune’s native app reporting reveals. It can also reduce the gap between a help desk report — “this one laptop behaves differently” — and an answer grounded in the device’s configuration data.
For co-managed environments, the feature may be especially useful during the long transition away from Configuration Manager-era inventory patterns. Microsoft’s documentation says Properties catalog collection supports Intune-managed devices, co-managed devices, Microsoft Entra joined devices, and Microsoft Entra hybrid joined devices. That provides a common route to inventory selected signals while organizations have mixed management histories and uneven application packaging.
The feature is included with Microsoft Intune Plan 1, so it does not appear to be positioned as a premium Intune Suite add-on. That matters because registry visibility is foundational endpoint-management functionality, not a specialist luxury. It should be available to the broad base of organizations that already use Intune to manage Windows devices.
The First Release Is Useful, Not Complete
There are signs that the rollout will require patience. Microsoft’s broader Intune release process can take several days to reach all regions, and individual capabilities can take longer to appear across tenants. Early community comments include at least one report of a tenant showing the Registry category but not yet exposing the expected configuration controls, though that remains anecdotal and may reflect staged availability or an interface issue rather than a general product defect.Admins should therefore verify both portal availability and actual device results before retiring existing scripts. Build a narrowly scoped Properties catalog profile, deploy it to a test group, wait for the initial collection window, and compare its output with a known-good local registry query. That comparison will expose path errors, value-type assumptions, access limitations, and misunderstandings about how a vendor’s software records state.
It is also worth retaining any remediation that has a corrective purpose. A discovery script made redundant by Registry Inventory can likely be retired after validation. A Remediation package that detects and fixes a broken condition cannot: the new Intune capability tells an admin what is there; it does not change what is there.
Microsoft has finally provided the native evidence-gathering layer many Intune teams have wanted. The next test is whether it broadens Registry Inventory beyond the Device Inventory view — into reporting, query, automation, and policy targeting — without sacrificing the focused safeguards that make this first release manageable.
References
- Primary source: Neowin
Published: 2026-08-01T13:52:01+00:00
Loading…
www.neowin.net - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: support.nhs.net
Loading…
support.nhs.net