Product Office Hours #6 - OS Readiness and Blueprints *Q&A in thread*

👍 And another good one!

Katie!  🤓

Such a great line up for all these product office hours sessions. Looking forward to it.

When comes blueprints details or troubleshooting inside the gui from Jamf pro?

We’re building Regression Scout and researching how teams validate endpoint changes. For OS readiness, what evidence can Blueprints provide beyond successful configuration delivery? For example, how would you combine its status with pilot checks of sign-in and required apps after an OS upgrade, and use that evidence to decide whether to expand the rollout?

Can you talk about the Configuring the Package Component blueprint? Specifically about how to host the pkg file and the manifest.

Looking forward to another great session!

Product Office Hours recap: OS 27 readiness and Blueprints 

This week's Product Office Hours covered OS 27 readiness and Blueprints, with Katie English (Principal Product Manager) and Mark Buffington (Senior Consulting Engineer). Here's every question asked during the session, pulled from both the live Q&A and the chat. 

Will Blueprints override MCX? We're still supporting MCX-style configuration profiles for now. If you deploy the same preference by both a configuration profile and a Blueprint, then unscope the configuration profile, it should generally work fine, but test it. That's actually part of why the new migration guide exists, this is a good opportunity to test your own migration path. Expect the most restrictive setting to typically win, though results can occasionally surprise you. 

What's the roadmap for using Blueprints for compliance benchmarks? There's likely a future where they merge, since they're conceptually very similar. The catch is that not everything compliance benchmarks does today, including scripted checks, is available as a declaration yet. There's a path here, it's just not immediate. 

Can a Jamf Connect–created user become an MDM user (with user channel) without re-enrolling? This is a real limitation right now. Any user created programmatically at the login window, whether by Jamf Connect or PSSO on-demand, doesn't get OS-level user channel MDM capabilities. Currently, re-enrollment is the only way to get that. Some organizations use a profiles renew command approach, though that gets more complicated depending on whether the user is standard or admin. Others are experimenting with a more unconventional method using the macOS 26 Apple Business/School Manager migration approach (a second server object pointing at the same Jamf Pro instance, moving devices to a new pre-stage, and setting a deadline for re-enrollment). This isn't something to jump into immediately, since every instance behaves differently around enrollment-complete policies. There's no easy button here, so filing feedback with Apple is worth doing. 

With OS 27, Apple has a user-level declaration. How do we migrate people who don't have a user declaration? This mostly comes back to user channel. Simplified Setup for PSSO creates new users during enrollment with user channel capabilities already in place, but for existing users created another way, the same re-enrollment answer above applies. On the declaration side specifically, the privacy settings and app settings declarations are user-channel only, so you're working through the same conundrum for those. It's also worth checking, with the macOS 27 accessibility changes, whether an app you're managing accessibility settings for even needs that anymore, or whether you'd rather use an old-school PPPC profile (which gives a less polished notification) versus asking the user more nicely via the declaration. 

Will more networking 802.1x declarations be coming? Yes, undoubtedly. There's work happening on asset storage for a few different pieces this depends on. It's planned, it's just a matter of resolving what's needed to actually offer those declarations. Worth noting: Apple's own declaration implementation isn't at 100% parity with configuration profiles yet, so expect more declarations from Apple over time, not just from Jamf. 

The Platform API was supposed to interact with Blueprints, but the production release doesn't show any way to grant Blueprint permissions. Is that feature still in beta? It should be fully available. This sounds like a specific workflow gap rather than a beta limitation, Katie asked for more detail to dig into it directly. 

Within Blueprints, will there be a way to see deployment status on individual devices rather than just broad numbers? Also, if a smart group's membership changes, does the Blueprint update automatically, or does it need redeploying? 

 Yes to both. Additional reporting options are in progress, including per-device visibility. And if your smart group is your scoping mechanism and its membership changes, the Blueprint's deployment changes with it automatically, no redeploy needed. 

Are new controls coming to Blueprints for the macOS 27 platform SSO features? Specifically interested in testing native Entra ID login and account creation from the login screen. Yes, that's coming in the next few weeks. One caveat: your identity provider needs to support the relevant pieces too. In the meantime, a couple of OS 27 benefits don't require any IdP changes: requiring Touch ID or Apple Watch auth as a secondary factor at FileVault or the login screen. To be clear, that's a second factor on top of a password, not a passwordless setup. 

If you scope a configuration to macOS 26 but set an activation condition of 26.4, does the reported scope change to reflect only devices that meet the condition? No. Scope and deployment counts don't reflect the activation condition; the declaration will show as delivered and valid once it reaches devices broadly, but it only actually activates once a device meets the condition (e.g., updates to 26.4+). There isn't currently a UI view showing which devices have activated versus just received the declaration, though per-device Blueprint reporting may surface that down the line. 

During Apple beta periods, we build custom declarations to test since Jamf doesn't have a native setting yet. Once Jamf ships the native version, is there a clean migration path, or do we have to rebuild from scratch? You'll likely need to recreate the object to match whatever ends up in the native UI. The keys can change during beta as Apple adjusts things, and the native object should reflect the most current, correct version. There isn't a clean "flip a switch" migration today. There might be an API-based approach, but be cautious of differences between the beta and release versions. 

Will Blueprints eventually replace configuration profiles entirely? Probably someday, though there's no exact timeline. MDM isn't going away, but there's an ongoing shift away from legacy, imperative configuration profile delivery and toward declarative management. Over time, that likely means most configuration profiles get replaced by declarations. 

When can we build smart groups based on whether a device has a Blueprint applied? This comes back to reporting. The first step is being able to see on a device record whether a Blueprint has been delivered versus actually applied (two distinct states). Once that's reflected properly, being able to group or search on that information (smart groups, advanced device searches) is the natural next step, and it's coming. 

Is DDM Explorer set up to show a status channel view for an individual computer, to help figure out why something failed? Not systemically across your whole fleet, but you can already point DDM Explorer at one specific device if you know it's having an issue. Put its management ID into the settings and refresh to see status channel details (like software update reasons). For declarations specifically you'll see activations, assets, configurations, and management criteria, including edge cases like a declaration showing valid overall while flagging that a particular setting isn't supported on the system channel. Worth understanding: declarations behave differently from configuration profiles. A config profile is only evaluated once, at install, so an unrecognized key gets discarded until the next OS update forces a re-push. Declarations get continuously re-evaluated as things change (new OS version, other updates), the device checks its full "ledger" of declarations on an ongoing basis. DDM Explorer isn't meant to replace fleet-wide reporting in the product, it's built for testing and experimentation on individual devices. 

The Safari Extensions component requires the MDM-managed capable user, but we use LAPS, which takes on that role. Any way around this? Not as currently designed, user channel is required here. Worth filing feedback with Apple on this one. 

We're seeing about 10% of devices fail to complete deadline enrollment and end up needing a reimage into the new MDM. Is that expected? Not expected behavior, please open a support ticket on this so it can be properly investigated. Separately, Apple has made significant updates to software update processes in more recent OS versions, so this may partially self-resolve going forward. 

Will we be able to install Declarations on a PreStage (for things like Setup Manager or Okta settings)? Not yet, but it's coming. In the meantime, Extensible SSO is a profile you can already work with during enrollment. The more specific declarative options for this are still in progress and will also need identity provider support once they land. 

Anything on on-prem Jamf and DDM, or guides for that? DDM functionality on-prem is currently limited to enforced software updates. Everything else requires Jamf's cloud platform capabilities. 

Any plans for Jamf School compatibility with the Jamf Platform API? Also, some endpoints like Device Lock and Clear Passcode aren't in the Platform API yet, still being developed? Long-term, the Platform API is meant to be the one-stop shop for all Jamf capabilities, including School. There's more work needed on the School side before it's available there. 

How do we see specific error details for a Blueprint? Right now status only shows Complete, Pending, or Error, and we need the root cause. Not available yet, this is work in progress. There's already a feature request logged for it if you want to add your voice. 

Any reason the Blueprints layout is so different from configuration profiles? Blueprints run as a micro front-end service, hosted differently from the main Jamf Pro web app, which is part of why the layout differs. That said, this is genuinely valuable feedback, and there's real interest in optimizing the UI. 

Is there a tool to convert existing Configuration Profiles into DDM objects? For example, converting Allowed Apps from iOS configs into the iOS 27 format would save a lot of rework. Not currently planned as a built-in feature, but it's a valuable feature request. Part of the challenge is that functionality doesn't map 1:1 from the older methods, so it's not a simple conversion, but there may be ways to make the process simpler. In the meantime, jamf-cli can already handle some of these conversions. 

Biggest complaint about Blueprints: we can't see which computers have deployed successfully, are pending, or failed. Is that in the works? Worth checking out Jamf Extender in the meantime. There's also a beta build in progress with more detailed reporting. Community tip: a GitHub script called JAMFGetDDMInfo can help in the meantime, it makes seeing scope targets easy, though it doesn't yet cover errors, failures, or pending/system status in detail. 

Is it possible to get a notification in the console when new declarations become available? You can subscribe to the Blueprints release notes directly: Blueprints Release Notes 

hello was this sessions recorded by any chance?

These sessions are not recorded. We do put answers to all the questions asked prior to the event. Those can be seen above.

I just heard about a new Youtube short on “How and why to switch to Declarative Device Management”, thought I’d share that here for folks to check out:

https://learn.jamf.com/r/en-US/training-video-shorts-jamf-platform-services-and-capabilities/How_and_Why_to_Switch_to_Declarative_Device_Management