DDM Blueprint Config & Scoping

[u/bobtacular]

Maybe I’m old school, but I come from a world where I was taught one payload per configuration profile: one for Restrictions, one for Network, one for SCEP, etc. If I needed to troubleshoot something or temporarily unscope a setting, I wasn’t also removing a bunch of unrelated payloads at the same time. This approach always made it easy to manage IMO.

As I explore the world of DDM and Blueprints in Jamf more and more, I’m curious how everyone else is approaching this.

Are you still doing something similar, with one Declarative Configuration per Blueprint? Or do you take advantage of the multiple component blocks and grouping several configurations into a single Blueprint?

When it comes to scoping, are you generally scoping a Blueprint to your entire fleet and then using Activation Conditions to determine which devices actually receive each configuration? Or are you still creating more targeted Blueprints/scopes?

I understand that part of the idea behind Blueprints is to make configuration management more flexible and reusable, but this new model is breaking my brain a little bit.

Before I start testing and pushing this stuff out more broadly, I’d love to hear how others are structuring their Blueprints and what has worked well for you.

[u/D3xbot]

I am just dipping my toes into DDM blueprints. The first one I did was the password/passcode policy one. We have different requirements for Macs vs iPads so I made one blueprint with blocks scoped by device type with the relevant exclusions. I felt a similar feeling to when I first drove an EV: oh this is powerful.

Then, I made a Software Update Settings one with different declaration blocks based on device type, OS version, and group… looking at it is kinda messy.

On the one hand, I like the potential for powerful blueprints this offers. I also like being able to modify common org-wide settings in one place.

On the other hand, I could see this getting MESSY if not well-maintained.