Forum Discussion
Device restrictions conflict
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.
- hiteshJCopper Contributor
Have you found any solution with the conflict state for 'Time to perform a daily quick scan' ?
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
- RonaldvdMeerIron Contributor
The issue also happens with fresh enrolled devices. Is there any logging were i can look at?
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.
- SinceVanillaCopper Contributor
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.
- RonaldvdMeerIron Contributor
- Michiel_SingorCopper Contributor
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.
- Alexander_AnhaltCopper Contributor
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?
- Thomas HallerCopper Contributor
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.
- SinceVanillaCopper Contributor
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 @
- DegerlundenBrass Contributor
RonaldvdMeer
Same problem here as well. Hope Microsoft notices this thread and propose a solution.
//Markus- Christian_HemkenCopper Contributor
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
- Paul McDonaldCopper Contributor
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
- DegerlundenBrass Contributor
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- RonaldvdMeerIron Contributor
- DegerlundenBrass Contributor
Glad to hear that you got the solution last week while I still had my clients as "In conflict" until a couple hours ago. Maybe the bitlocker error blocked the devices somehow, who knows.
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: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
- hiteshJCopper Contributor
It seems the problem is resolved for users in same time zone. All users from different location and time zone still shows conflict.
- RonaldvdMeerIron Contributor
- Deleted
hiteshJ We still have the issue. Devices are in different time zones. All Windows 10 PC's are up to date on build 1909.
- DegerlundenBrass Contributor
The problem persist, all clients are back at status "Conflict" without any changes made since they were in status "Compliant devices".
//MarkusHey Degerlunden,
they actually re-introduced the bug in service release 2002 in Intune. But an follow up fix was rolled out so it should be fixed again. Maybe not all tenant received the fix due to staged rollout procedure but they actually fixed the intermediate re-introduced bug.
best,
Oliver
- DegerlundenBrass Contributor
Oliver Kieselbach
Hi,
Thanks for the information. I'll ignore the conflict for a few more days and then check in again and see if it's solved.
Br,
Markus