Device Configurations or Settings Catalog for the Enterprise?
In my time deploying enterprise ready windows builds around the world I have seen some pretty consistent configurations, which take us down a deep deep HOLE! of Group Policy.
Group policy is a familiar tool to everyone in the windows management / admin space. For years we have bet our device security and reliability on Group Policy and all too often taken advantage of all that we can do with it.. Often times finding ourselves in situations where we ask why did this happen, and the common response is "I don’t know! It was there when I picked up this mess" Well I often get asked at what point do I look over existing group policy to model our Enterprise ready build. My answer is Never! Well almost never, we might grab things like drive mappings, and 3rd party applications Reg keys in Group policy preferences, but aside from that STAY AWAY!
The reason for this, is because many admins are scared of what they don’t know, and Group policy is exactly that, there are years sometimes decades of device and user configurations which just keep things running and to disrupt that could sometime mean our jobs. But breaking away from group policy can be a huge opportunity to get to where you want to be and this has been consistent with many of the admins I have worked with that look past fear, and that is the goal of an enterprise ready work station is Secure, and productivity ready! So start there!
As we look at device configuration in Endpoint Manager we have many different options but these really fall into two buckets Device Configurations & Settings Catalog. I often look at these as V1 and V2.
Device Configurations: to me this the first rendition to delivering configurations leveraging OMA-URI strings to call on CSP Configuration Services Providers) in windows. This was great provided an easy strait forward method to deliver user and device configurations to Windows Devices but extremely limited in terms of predefined configurations with limitation like the ones listed below. This was in many ways a step back from what we had in Group Policy and made many of us to believe did we choose not to learn or apply what was already there?
Device Configuration types provided limited configuration.
Configuration would Stamp the machine, many not reverting when policy removed.
Required many customer OMA-URI configurations to meet business needs.
No Parity in GPO (Though I don’t believe we really needed it).
Settings Catalog: The new rendition of configuration management took a different approach but this time not forgetting the where we came from. One of the largest gaps that caught many admins off guard was configurations Tattooing. This was when we pushed configurations and then pulled them back, well tattooing means the configuration stays even after the policy has been revoked. Meaning to undo what you did requires a revert policy to be deployed, ever adding to the complexity of your environment. Settings Catalog or V2 Resolved this problem, providing like features with Group Policy and reverting when the policy is pulled back. On top of that also makes it much easier to make all-encompassing policies rather than man different templates we can have one large settings catalog further simplifying our deployments.
Needless to say I'm a fan of the new settings catalog and look forward to near parity with GPO making adopting to the cloud that much easier and quicker.
A great read for understanding OMA-URI strings and how to deploy using Intune!
Custom Microsoft Intune OMA-URI Policy ins-and-outs – Jeff Gilbert's Cloud
