Device restrictions conflict

Iron Contributor

We have a conflict in our device restrictions after we change another setting in that profile.

In the Windows Defender settings we have set 'Time to perform a daily quick scan'.

After setting a another setting in the device restrictions this setting resulted in a conflict.

After reviewing this intune shows that there only one profile with conflict.

We have no other settings with this specific setting. So there no logical reason for a conflict.

 

Schermafbeelding 2019-12-11 om 23.09.07.png

31 Replies

Hi @RonaldvdMeer,

 

this is more brain storming and not a fact, not a verified answer but maybe helps for further troubleshooting... you may have configured the value before with a different policy and then unassigned this policy, which might left the setting behind (tattoo) and then the new policy finds this leftover and tells conflict. The back end service (Intune) can't show a conflict as the original policy is not assigned anymore, so it only shows the current one. 

 

best,

Oliver

@Oliver Kieselbach 

The issue also happens with fresh enrolled devices. Is there any logging were i can look at?

@RonaldvdMeer 

Oh this is strange. I would open a support case for this. I don't have any idea how to solve this from the client side. I think you need some info from service side why it is flagged as conflict.

@RonaldvdMeer We started experiencing the same issue, on thousands of devices for this very configuration item. We have no conflicting MDM configuration profiles, or GPO. We have on occasion edited existing MDM profiles instead of creating new, and re-assigning groups. 

@SinceVanilla 

 

That what we did too. Just edited an existing configuration profile

@RonaldvdMeer @SinceVanilla 

Same Issue here.

 

Added a few Exclusions into our Defender Device restrictions Policy last week now its reporting conflicts on every device.

 

Made sure there are no conflicting settings as described here under the section "Type of system scan to perform". Still reporting conflicts.

 

@Michiel_Singor @RonaldvdMeer @SinceVanilla I'm having the same issue aswell. I had to raise a support request this morning as this one thing is pretty much preventing us moving over to Intune at the moment. The quick scan isn't even being done automatically. I can do it manually, so there must be some backend configuration issue that needs addressing. The security intelligence updates are scanning and updating fine

Really hope this is resolved soon

@RonaldvdMeer @Oliver Kieselbach 

Hey all, we have the same Problem. I created a support request  by MS-Intune-Team. That is now closed, becouse it looks like a "Windows-Issue" (endpoint and not Intune-Case). Now I should create a new request for Windows-Enpoint Team.... Now is the ouestion @Oliver Kieselbach,  did you created some request by MS?

We have the same issue in all our tenants as well (without even editing anything). Would be interested as well if someone knows more about this - we don't have open tickets yet.

@RonaldvdMeer

Have you found any solution with the conflict state for 'Time to  perform a daily quick scan' ?

 

I have a case opened for this problem. We have MDM only managed, Hybrid AD Joined devices. No conflict issue with GPO, or Device Configuration profile was identified. This appears to be an issue on the service end. I'd say open a case with Microsoft if you're experiencing the issue, as your problem maybe different than ours. @RonaldvdMeer @

@RonaldvdMeer 

Same problem here as well. Hope Microsoft notices this thread and propose a solution.

//Markus

I see the same situation at one of my customers. Has anyone tried not to use the gui, but work directly with the Defender CSP via Custom policies? I am not sure, if its a bug on the backend or something wrong with the csp that are underlying. 

Kind Regards,

Chris

@Christian_Hemken I've worked with MS on this for quite a while now and we've tried all sorts (GUI, Custom CSP, PowerShell), still not resolved as we speak

I was told a fix for this would be in the 2001 service release, it wasn't. Still seeing a conflict

@Paul McDonald Thanks a lot for the answer. I will also open a call with MS to (hopefully) increase the pressure.

Best,

Chris

@Christian_Hemken The is was fix last evening

Device Restriction policy setting reports may be inaccurate
IT202581, Microsoft Intune, Last updated: January 31, 2020 10:57 PM
Start time: December 16, 2019 1:00 PM, End time: January 31, 2020 8:45 PM
Status
Service restored
User impact
Admins may have received inaccurate data from their Device Restriction policy setting reports.
 
Is this post helpful?
 
Latest message View history
Title: Device Restriction policy setting reports may be inaccurate User Impact: Admins may have received inaccurate data from their Device Restriction policy setting reports. More info: Policy settings delivered to devices were applying as expected. This issue only impacted reporting. The inaccuracy may have occurred in the "Type of system scan to perform" setting in Device Restrictions. The policy may have appeared to fail even when it successfully applied. Final status: We've confirmed with a subset of affected users that the Device Restriction policy setting reports are now calculating data correctly. Users will have to wait for their device to check-in before Device Restriction policy settings reports are calculated correctly. Admins can force a check-in and recalculation by modifying the title of the Device Restriction policy and point protection policy, then saving these changes. Scope of impact: Your organization was affected by this event, and any admin may have noticed that their Device Restriction policy reports were inaccurate. Start time: Monday, December 16, 2019, 1:00 PM (12:00 PM UTC) End time: Friday, January 31, 2020, 8:45 PM (7:45 PM UTC) Root cause: A recent update introduced a code regression in the affected environment, which was causing policy setting reports to return inaccurate results. Next steps: - We're reviewing our update procedures during our development and testing cycles to better identify similar issues with policy report calculation in the future. This is the final update for the event.

Hi again.


I'm not sure if Microsoft have done any changes since yesterday evening (12 hours ago) but now my clients starts to get the status "Compliant devices" instead of "Conflict"


The change that might have fixed this.
This morning I've changed the bitlocking encryption from xts-aes 256 to xts-aes 128 due to that no device got encrypted with xts-aes 265 and was categorized as "Devices with errors".I checked cmd with the command "manage-bde -status" and it revealed that all devices was encrypted with xts-aes 128. After the change I get the status "Succeeded" one device after another. The devices that got the new status also got released from "In conflict" for 'Time to perform a daily quick scan" and is now compliant.

Hope that this can help anyone out there with the troubleshooting to solve the problem.

Markus Degerlund
Mercuri International Group

@Degerlunden 

 

If you have read my last reply you would have know that it was fixed last week

Hey @Degerlunden,

 

The problem was mitigated in the meantime. I guess your tenant has all relevant updates and start to behave correct again. See Twitter post from the Intune PG:

 
From Twitter:
ConfigMgrDogs @ConfigMgrDogs 

Today we fixed an issue with two Defender AV settings reporting Conflict or Error in the #MSIntune / #MEM console. Thanks for those who reached out to report the bug. Happy to say it's fixed & devices should return to green on their next check-in.

The two settings affected were 'Type of system scan to perform' and 'Time to perform a daily quick scan', found in the WDAV section of our Device Restriction profile.

 

best,

Oliver