This blog covers a common but often missed misconfiguration: filtering or intercepting traffic to dm.microsoft.com. One small mistake in how traffic was handled broke the linked enrollment process entirely, leaving behind hundreds of lingering broken enrollments and a missing Device Inventory Agent.
Introduction
‘Some issues leave behind a simple error message. Others leave you with 220 enrollments and the 220 corresponding keys in the registry, 170 scheduled tasks in the Enterprisemgt folder, and Device Inventory (Properties Catalog) and EPM agents that never show up. All because traffic to dm.microsoft.com, a core MMP-C endpoint, was silently intercepted by a proxy.
Without successful linked enrollment, the Device Inventory agent and the Endpoint Privilege Management agent never get installed, and there’s no obvious error that the dual enrollment itself failed!
We’ll walk through how this happened, why it keeps happening, and why blocking dm.microsoft.com breaks far more than just one device or one Intune feature.
Device Inventory depends on dm.microsoft.com
To understand why blocking dm.microsoft.com causes problems, you first need to know what MMP-C is.
Microsoft is moving away from the traditional sync-based policy model used by OMA DM. Instead, it’s rolling out a new configuration framework called Declared Configuration (WinDC). This WinDC framework enforces the desired state continuously instead of waiting for the device to check in.
To make this happen, Windows introduces a second enrollment called linked enrollment, in addition to the standard Intune MDM enrollment. This second channel is part of the Microsoft Management Platform Cloud (MMP-C). It’s how components like the Device Inventory Agent and Endpoint Privilege Management are delivered. And as more functionality moves into this model, the importance of linked enrollment keeps growing.
For a solid technical deep dive, check out this explanation: From OMA DM to Declared Configuration
When the Device Inventory Agent doesn’t show Up
Now that we’ve covered some details about MMP-C, let’s revisit how this issue manifested in this case. It started with a device that failed to populate any data in the Resource Explorer tab in Intune. All the configured properties showed no data.
The Device Inventory Agent, which normally gets pulled in automatically, was also missing entirely. When looking closer at the properties catalog that should have triggered the Device Inventory agent to be installed, we noticed that they all got the error: 2147749902
Other devices that didn’t show the 2147749902 error, were stuck in a pending state
The Linked Enrollment Key Reveals the Story
With the properties catalog policy throwing weird errors we decided to look at the registry under HKLMSOFTWAREMicrosoftEnrollments. Why? As EPM and Device Inventory rely on a Linked Enrollment and the first place to start troubleshooting the linked/dual enrollment is indeed the enrollment registry key.
While doing so, the problem became immediately obvious. There were over 220 subkeys, each one a separate enrollment attempt. Each key represented a new attempt with its own GUID.
Looking at the main Intune enrollment key in the registry, a subkey stood out: LinkedEnrollment. That subkey pointed directly at a discovery endpoint hosted at:
https://discovery.dm.microsoft.com
Somehow, it attempted to enroll in MMP-C, and it succeeded for 50%? From there on we opened the registry GUID that corresponded with the LinkedenrollmentID from the picture above.
Looking at the LinkedEnrollment and MMP-C Enrollment, we noticed several things. The KeyContainer number was unusually high. With every new enrollment, that number increases, so it was clear this device had gone through quite a few enrollments in the past. But there were also other signs that something was seriously going wrong.
- EnrollmentState = 4
- Status = Failed to process server enrollment provisioning, rolling back
This wasn’t just a failed enrollment. It was a failed linked enrollment being retried endlessly, never succeeding, and leaving behind an old enrollment every time.
EnterpriseMGT Scheduled Tasks: Bad Gateway 502
The fun extended into Task Scheduler. Under the scheduled task folder MicrosoftWindowsEnterpriseMgmt, there were more than 170 subfolders. Each one matched an enrollment GUID from the registry.
Inside, familiar task names kept showing up: Schedule #1, Schedule #2, and so on. Most hadn’t run successfully. In the few cases where task history was available, the result was always the same:
HTTP 502 Bad Gateway (0x801901F6)
It was clear the system was trying to do something repeatedly and getting blocked with the bad gateway *502 error just before it could finish.
*Error 502: status code indicates that a server was acting as a gateway or proxy and that it received an invalid response from the upstream server.
If those scheduled tasks failed to be executed, one thing is for sure! The Device Inventory agent and its properties catalog policy you configured will never show up on the device!
The Proxy That Broke the Linked Enrollment
I guess the bad gateway 502 error made it all pretty clear that the devices seem to be running behind a proxy. After asking about it, he told me the devices were indeed behind an iBoss proxy. iBoss is a cloud-based web security and filtering solution commonly used in enterprise and education environments. It inspects outbound traffic and enforces policies using a combination of cloud gateways and on-device agents.
The team believed their PAC file was configured to allow all Microsoft traffic, and at a glance, it seemed that way. But a closer look revealed a small typo in the PAC file, which only excluded *.cdm.microsoft.com. The critical *.dm.microsoft.com was missing.
Because of that single oversight, any traffic to the MMP-C platform was either filtered, intercepted, or dropped. That meant the linked enrollment couldn’t be completed successfully. Instead, it would fail, roll back, and try again endlessly. With the linked enrollment failing, the device inventory agent would never be installed.
The Device Inventory Fix
So, what happens when the proxy finally gets out of the way? To confirm the issue, the iBoss proxy was temporarily disabled on one of the affected devices. After kicking off the MMP-C sync (task scheduler), everything changed:
- The linked enrollment was finally completed
- The Device Inventory Agent was installed
- The logs reported a successful provisioning session
- Within 24 hours, the data showed up in the resource explorer
All of it worked once traffic to dm.microsoft.com was no longer blocked.
Why It Matters More Than You Think
This issue wasn’t just about Device Inventory. It was about how Intune is evolving.
The same MMP-C enrollment ( Powered by WinDC Stack) is used for Endpoint Privilege Management. Eventually, Resource Access Policies will also be moved over.
That means if your proxy or SSL inspection still filters or blocks dm.microsoft.com, you’re breaking parts of your device management and not just some new shiny Intune Features.
Want to understand how Resource Access Policies are being re-routed through MMP C? Read this: MDM to MMP-C: Resource Access Policies.
What You Should Do
If you’re using a proxy or a filtering solution, now’s the time to double-check that you’re explicitly allowing traffic to *.dm.microsoft.com. Even when the Official Microsoft documentation does NOT mention anything about this URL being required for Device Inventory to work, believe me, it is required!
Ensure that you don’t have SSL Inspection in place for DM.Microsoft.com, and please exclude that domain from going through your proxy! It will break EPM, Device Inventory, and future policy delivery to your devices!
Conclusion
MMP C is not an optional enhancement; it’s a core part of Intune these days. Because Device Inventory is included in every Intune license, all managed Windows devices are now expected to have a linked enrollment. If communication to dm.microsoft.com is blocked, those devices won’t raise red flags. They’ll silently fail to complete the Linked Enrollment process.
Check your PAC files, inspect your proxy settings, and make sure dm.microsoft.com is explicitly allowed. You don’t want to end up with hundreds of failed linked enrollments.