Devices loosing configured intune policy

[DWilson1997]

Hi all,

 

Bit of an odd one...

 

We have a fully Intune-managed estate which has been working well for several years. Starting this week, we've seen a small number of devices randomly lose their policies and apps. In some cases all policies disappear, while in others only specific policies seem to be affected.

 

For example, on Monday three devices lost policies:

• One device lost all Intune policies.
• One device lost all Intune policies except the Microsoft Edge policy.
• One device lost only the Wi-Fi and wallpaper policies.

 

Today, another device lost all policies except the Microsoft Edge policy.

 

Intune reports that all policies are successfully installed, the devices are syncing correctly, and everything appears up to date. Interestingly, Intune also reports that there are no managed apps on the affected devices.

 

We've looked through the logs, Event Viewer, and the Intune Management Extension logs, and we're seeing entries such as:

 

MDM ConfigurationManager: Command failure status.

Configuration Source ID: (3248DC4F-F03B-43CD-8CA6-C1533722889C),

Enrollment Type: (MDMDeviceWithAAD),

CSP Name: (LAPS),

Command Type: (Clear: first phase of Delete),

CSP URI: (./Device/Vendor/MSFT/LAPS/Policies/PasswordLength),

Result: (Unknown Win32 Error code: 0x86000002).

 

What's particularly strange is that if we simply rename the device, it immediately starts receiving all policies again, usually within five minutes. While that's a workable fix, I'd like to understand the root cause before the issue becomes more widespread.

 

Has anyone seen anything similar or got any ideas on where to look next?

 

Thanks,

 

D

[mjhardisty]

Got around 520 devices - haven't had any reports of these issues.

 

If you have an X account, the Intune Support Team usually respond pretty quickly - run it past them:

 

 

Edited July 2 by mjhardisty

[psydii]

My first thought is certificate renewal. I recall various MVPs banging the drum over this (separate to the Secure Boot Certs) "recently"-ish.  But I never went deep into that beacuse our estate seems to have dodged that issue (I think?)  This is definitely one of those problem it's easy to get lost in. Not sure how the intune MVPs ever got their head around it.

 

 

Anyway, to lean on their work via Copilot's "think deeper":
 

Quote

This is interesting — and the rename fixes it within ~5 minutes detail is the bit I’d focus on. My read is: this does not smell like policy assignment logic. It smells more like a client-side MDM/CSP state problem, or a device identity / enrolment-state mismatch, where the Intune service still thinks everything is fine but the Windows MDM client has lost, hidden, or failed to reconcile parts of its local policy state.
 

0x86000002 is commonly interpreted as a CSP node not found / node missing style failure. Rudy Ooms has written about this error in the context of Windows MDM CSP tree issues, where the expected CSP node is missing locally even though Intune is trying to act on it. [call4cloud.nl]

 

 

While the referenced article is about an incident over a year ago, I wonder if there has been a recent update that has recreated theses conditions.

Copilot gave a couple of pages worth of background and investigation paths to follow up on, might be worth a conversation  with it to see if there are any additional logs on your impacted machines that would help narrow down the root cause. 

Edited July 2 by psydii