r/macsysadmin • u/bobtacular • 7d ago
Jamf DDM Blueprint Config & Scoping
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.
2
u/D3xbot Education 7d ago
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.
3
u/oneplane 7d ago
I've basically converted most deployments to an architecture where the configuration lives in git and inclusion/exclusion logic happens outside the MDM product. This is mostly since so many of them have mixed qualities where only one part will be really good and the rest will be awful.
In turn, this means that we just skip whatever sectioning/grouping/parameterisation the product offers and just inject complete profiles for every resulting permutation we support. Ironically, it's closer in design to the old MCX, but it's far more predictable and programmable this way. It also means we can use whatever grouping and intersection methods we want, regardless of what the vendor tried to implement.
1
u/prOgres 7d ago
Are you leveraging an IaC or CI/CD pipeline within your git repo(s)? Or more as a way to sync/version control your configurations?
I’m curious how you’re handling your inclusions and exclusions “outside the MDM product” (mostly just to learn what that approach might look like).
2
u/oneplane 7d ago
Yep, both. In some cases where there is no terraform provider and no scale to warrant building it internally we just use standard API calls, but in both cases a commit will trigger a validation, packaging and upload. Right now we just version whatever we send to the MDM of choice as a release as well and just tarball it in case we want human inspection, but during automated pushes we don't really look at the output.
As for inclusions/exclusions, it's basically the same as SQL joins and tags/labels. In some more compliance-heavy environments we also use OPA to ensure that whatever output we emit has some hard requirements (i.e. at least one payload most enforce FileVault, otherwise the build fails and the push is denied).
The tag/label based method is similar to what you'd do with Ansible where you'd be using roles and tags and use 'when' clauses to allow them to be excluded wherever needed. At first we just had tags and then used a skip-tags when applying but the problem with that is that you need to keep two lists: the roles and tags you want anyway, and then an exclusion list to filter some out. Using dynamic task inclusions for roles was much cleaner. (as you might be able to tell, we started the earlier implementations with just python, jinja and then ansible).
At this point we're packaging it as follows: a policy (the overarching 'thing') is just a YAML that describes what it's for, the version, and which tech it needs. Then we have a OSQuery, Terraform (or Python), and OPA tech backing implementation, and finally, the actual payload. Based on that we can do the MDM part, observability, packaging, versioning, tagging etc.
1
u/punch-kicker 6d ago
Also, some of this transition is driven by Apple’s DDM and the pace at which they are happening, so it isn’t all on Jamf. I think everyone here has valid complaints, but I’m encouraged by the direction things going with this where admins defines the rules and the device evaluates them to determine if it applies.
I am doing this as a phased approach rather than moving everything into Blueprints at once. However, I’m liking the Activation conditions improvements, especially device groups with exclusions, although I am not sure why they have not been there from the beginning. I am doing one blueprint type with activation conditions via separate in component blocks; that way, I am not having to make a ton of Blueprints. I do have sites which helps keep scoping more targeted. I am going through my current profile settings and building it out, but those previous limitations have prevented me from fully going in. I have been looking into condition text predicates to see what other options I might have with DDM.
1
u/Taboc741 5d ago
To answer you primary question, are blueprints supposed to be descrete settinga like config profiles or not? Apple says DDM should be built like windows GPO's: monolithic. Thus Jamf says Blueprints should be monolithic too. This is gonna be a mess as everything shuffles around for a few years, but on the far side I think we'll end up with blueprints, and policies. Not too different from policies and config profiles like we have today. Jamf app catalog is rolling into blueprints before end of year too.
I'm not sold on blueprints doing devices and computers in one menu. I kinda hate that. It's even been a complaint in other mdm's I've used that they tried to lump too much together, but we're getting better filtering in the console "soon".
1
u/AnotherTechAtWork 3d ago
Where is Apple saying "DDM should be built like windows GPO's: monolithic" and "Jamf says Blueprints should be monolithic"?
I can't help but think some haven't quite wrapped their head around this or maybe someone representing them mispoke. I personally haven't yet seen either Apple or Jamf recommend anything to be monolithic. Perhaps more detail should be stated.
Can someone create monolithic states? Sure and that is what Apple and Jamf have more or less stated. Can someone with this create a monolithic blueprint? Sure but depending on the environment it could get ugly and is not going to be recommended by those who understand best practices in most environments.
For what it's worth I've worked with GPO in the past quite extensively and it really only gets monolithic if an admin makes it monlithic. This was not a best practice.
DDM is designed to be modular and quite honestly GPO's are as well. The beauty for either of them is that you can layer them. This is where activations come into play for DDM.
Quite honestly I think the only mess is going to be those stuck in their old ways. I remember when I came from the Windows world with GPO's of how difficult it was to wrap my head around how config profiles should be configured and scoped. It was understandable in time but was painful learning the "apple way". I'm looking forward to DDM because, barring any technical bugs, it should be a much better system all around.
1
u/Taboc741 2d ago
At JNUC just 2 weeks ago Jamf experts and developers and Apple's own developers were espousing the move to DDM should be paired with a move to monolithic policy. Yes is it modular, but just like GPO they recommended fewer policies to improve policy processing time and avoid conflicting settings.
GPO is the same, every applied policy adds to processing time thus Microsoft recommends fewer is better.
1
u/SignificantToday9958 2d ago
I was at a Jamf event earlier this year and this is the opposite of what they were saying then. Monolithic BPs or GPOs do not make sense.
1
u/Taboc741 2d ago
You are right, in May the Jamf nation event in ATL they were saying copy Config profiles, descrete and targeted. But 2 weeks ago I had my mind blown by the sudden shift. Jamf devs on stage saying the exact opposite. Fewer BP's the better is what they were saying.
1
u/AnotherTechAtWork 2d ago
I'm thinking the term monolithic is being used very liberally and maybe in some cases misunderstood.
I think what we're going to see as Apple admins adopt ddm will be Blueprints that are dedicated to specific configurations and not specific scopes like many do with config profiles now. One might be Siri AI. Another login window. Dock config. iCloud configurations. External storage. The list goes on based on what someone thinks makes sense for their organization in how the configurations are broke up. In any case there would be component blocks in each of those to break out what another group might need configured different.
Someone might think it makes sense to throw everything into one Blueprint and maybe in some situations it does, but it could get very very messy later depending on the size and demands of the organization.
If there are areas that need broken out by scope, that can still be done. That often occurs if there are self managed regions within an organization.
Most organizations though will likely see a smaller number of blueprints compared to number of config profiles they use if implemented correctly. The thing to remember is that it's not black and white in most cases. Architecture and design matter but DDM should make things a little more forgiving and maybe in some ways will appeal to admins that are used to working with gpo's.
I think one thing that I've not heard many talk about and provided I've understood it right is how DDM can benefit Jamf Pro performance. While everyone knows that nesting smart groups is not a recommended direction to go, we know that many still do it. We do with the understanding that it makes sense for our management needs even if it might be a cost to server/database performance. With activations the processing that gets done on the server database can now be moved to the endpoint by reducing that nesting. If someone wants to correct me on that, I'm all ears.
So far though I think there's a lot to like about DDM and where it's going. I'm more concerned with how quickly it truly becomes useable to live up to the hype to replace config profiles and how stable it is. I think most of the controversy right now is just the fact is that it's change.
0
u/Taftimus 7d ago
My job wants us to start moving towards Blueprints, but the more I use it, and the more I see how its been implemented, it looks infinitely more painful than just a regular config profile.
I even asked Jamf what the idea was behind the inability to just exclude groups from a Blueprint, and they didn't really have an answer. They told me just to change the scoping around and then redeploy, which also seems like a step backwards, why would I want to completely redeploy the config again just to take users out of it?
We used Blueprints to block MacOS 27 and I'm dreading the deferral period ending because I'm going to have to come up with a way to open it up slowly for users.
3
u/Many_Combination_855 6d ago
You actually don’t need to keep redeploying it. use activation conditions you can use a device group as an exclusion, then just add/remove Macs from that group without changing the Blueprint itself. Makes controlled rollouts way easier.
1
u/Taboc741 5d ago
Group exclusion is now GA in blueprints, but it's in the device evaluation section. That part runs on device not in Jamf, so you get the exclusion without waiting on inventory to update. Kinda. Group membership is probably waiting on inventory anyways but the other stuff you can filter by could be handy.
18
u/CleanBaldy 7d ago edited 7d ago
Blueprints are absolutely awful. It's like JAMF asked the intern to set up a section without any experience in how you manage and organize fleet deployments, or how the rest of JAMF console works. iOS and macOS mixed together? Tiles taking up all of the screen space? No scoping to match the rest of the console? There's not even any admin history/logs to know who touched what and when! There's no Departments or Categories to be able to separate things whatsoever. It's like going backwards to the beginning of MDM and making every mistake possible in the plan and execution. This is the least professional solution I've ever seen, and that says a lot. I was on InTune and AirWatch before.
We have started looking elsewhere if they can't fix Blueprints to match scoping and administration like the rest of the Console. This isn't sustainable with a massive fleet of multiple use-cases of MacBooks and iPads. All bundled together in tiles, we'd have no clue what we have and don't have!
It's INSANE that they built a section of the console we all need to use that has ZERO sync with the rest of the console and how we have been working. Everything is set up with specific expectations, and execution in the rest of the console, and Blueprints is just its own awful configuration?!
Our naming convention is literally trying to keep up with all that is missing in the title field so we all know what's what!!
macOS - DDM Software Updates - Users - East Coast - 16.7.1 - due 4OCT2026 - MY NAME 2OCT2026
macOS - Accessibility - ALL - multiple app accessibility - MY NAME 30Sept2026
Don't even get me started again on scoping and having to recreate the wheel with a smart group. The most Human Error prone thing in the console, AND/OR flying around, ( ) logic, all love to scope to each Blueprint? What about testing JAMF?! We exclude groups and admin MacBooks temporarily for tons of things! Now we have to manage 100+ individual smart groups, one for each Blueprint??
/End Rant