MDM WINS OVER GPO
Question
Hi Experts,
What is the best practice to use MDM WINS OVER GPO configuration profile over all devices groups or all users groups?
Need to know the best results on the basis of devices and users.
I can explain more if required.
Answers ( 3 )
We recommend avoiding deploying group policies to Intune-managed devices. Try blocking the inheritance of policies in Group Policy to avoid conflict scenarios and deploy all the policies from Intune.
This setting doesn’t work for any custom GPO out of ADMX like Edge etc.. & it may likely be depreciated in the future is what I understand from MS.
More Details on this post -> https://www.anoopcnair.com/mdm-wins-over-gpo-group-policy-intune-policy/
We have already gone through with the suggested link after that only I asked the said question here with you all experts. we also know about the limitation of this configuration profile and taking further steps to overcome however still we want to know the best practice to deploy this configuration profile method. Device or Users which will be more suitable here and if there are any pros and cons?
There will be pros and cons for both Device Vs. Users. But Intune can handle both according to the latest conversation that we noticed on Twitter by the product team
Gabe Frost.
So it’s the question is which one works for you and your organization – Use that method!
Just an example for Windows Update for Business:
1.Intune currently levers different parts of WUfB behind the curtains. It uses traditional WU client policies for deferral rings which is the only option (currently) for deploying monthly QU.
2.It uses the new Deployment Service (via Graph) for approval/scheduling FU deployments inc. Gradual Rollouts, Expedited QU, and (soon) approval/scheduling Drivers & Firmware.
3. Deployment Service only operates on AAD device IDs. It doesn’t know anything about AAD users. If Intune lets you target users, the app is dereferencing user devices and telling WU (via Graph) to target devices.
4. For deferral-based rings (QU or FU), Intune uses MDM protocol rather than Graph. This is also a device concept. Works like this: i) Intune sets WU policy on client, ii) client passes deferral policy metadata when it scans WU, iii) WU considers deferral before offering content.
5. On the Windows device, the Update stack that scans WU runs even when a user is not logged in. If it were to run in a user session, critical patches wouldn’t get deployed on those pesky devices that aren’t logged in. It’s device-based (session 0), not user-based (session 1+)
6. So you see, OS updates are a device concept from an infra perspective. If Intune lets you target users, that is an abstraction. It’s a nice abstraction. But conversion is happening to map user to device. If that is feeling wonky somewhere, it’s the handling of that abstraction
7. For Expedite in particular, Intune calls into the Deployment Service (via Graph) to target the QU to a list of AAD device IDs. So Intune would convert users to devices before calling Graph.
8. Then, Deployment Service sets stuff up in WU to offer the chosen QU, gets devices set up to transiently ignore policy that would block or slow download/install/reboot, and triggers devices to scan now.
9. Here’s a closer look at how Intune and any other apps call into Deployment Service: https://docs.microsoft.com/en-us/learn/modules/manage-windows-updates-cloud-devices/
10. So very long story short, most robust is to create and target Device Groups. I can’t speak to the User targeting abstractions Intune employs to target Windows Updates, but @UpdatedavidM is a good place to start, and the OG on our Expedite feature 🙂
Orginal Post – https://twitter.com/goodmane/status/1547327671926984705?s=20&t=tArwoQpUS7Hqk8JW2d43Hw