Jamf Pro 11.1 Now Available

Reading through the Deprecations and Removals, this stands out as kind of majorly important.

Functionality to specify the local administrator account for computers in a PreStage enrollment—

In an upcoming release, the ability to specify or modify a local administrator account password in a PreStage enrollment for computers will be removed from Jamf Pro (estimated removal date: January 2024).

I'm assuming this is part of mandating the Jamf LAPS solution, but this seems like a terrible way to communicate that information.  This will affect workflows.  I understand there is now a Jamf created application for retrieving the LAPS account's password, but there still is no GUI way to do it in Jamf Pro directly.  Do you have any update on the roadmap for when the LAPS password(s) will be available through Jamf Pro directly instead of only through API?

"When you enable macOS Onboarding and add the items to be deployed, the onboarding workflow initiates for all computers in your environment. This includes newly enrolled computers and those that were previously enrolled."

This went from "oh useful," to "who would possibly turn this on aside from a new environment?" Can anyone speak to any reason you would want to (re)onboard your whole fleet? Am I missing something?

I was excited about macOS Onboarding until I read that it will run on all of the Macs that have already been enrolled, impacting thousands of users. There is no room for error or testing in this scenario, and it looks like you can't have multiple different onboarding options (such as one onboarding for marketing and a different onboarding for application developers).

I think this will eventually be a great feature, but I'm trying to wrap my head around how to use it in its current state. Anyone planning on rolling this out to your fleet, or are you going to stick with DEPNotify, Setup Your Mac, or something similar?

Hi @McAwesome thanks for reaching out and the feedback!

We've definitely heard a lot of great feedback on our updated LAPS workflow, including wanting more information in the UI. I can confirm that we will not be removing the static password workflow from prestage enrollment until the newer LAPS rotating passwords are accessible via the UI. We are currently targeting early next year (January 2024 from the release notes) and will continue to utilize the deprecation notices and release notes to communicate any changes to the timeline, or completion of the updates.

I have a small dev environment of 5 machines, so I will definitely test macOS Onboarding and see how it does with machines that are already enrolled. I certainly would hope that once this is enabled it doesnt pop up Self Service and run again on already enrolled machines. 

Thanks for reaching out @kfjamf, @Jason33 and @joshuakessel regarding the macOS onboarding workflow. When the SS onboarding feature is enabled, it'll send all configured content under Onboarding in Jamf Pro to machines that has not successfully completed this new Onboarding workflow.  This does include any previous enrolled machines not gone through the onboarding workflow. Once it has been completed, however, a flag is set on the machine and no new content added will be configured.  We are in our initial rollout of the feature so the feedback is really welcomed and I am taking these mentions back the team for opportunity.  Thanks again!

I still would like to hear more about this decision on "onboarding" that others have brought up. 

"When you enable macOS Onboarding and add the items to be deployed, the onboarding workflow initiates for all computers in your environment. This includes newly enrolled computers and those that were previously enrolled." 👎

We'll test this but it really seems like a deal breaker for using this for the issues it could cause.

This is literally along the same lines as the Software Update tool in beta but so far is made non-useful for on-prem because you cannot set an enforcement date unless using a cloud instance of Jamf. 😮

Hey @sara_graves .  Can you give some information on the flag set by the Onboarding workflow?  Is it something that could potentially be scripted to run in advance?  That might be a way to preemptively mark enrolled machines as having "completed" the onboarding without forcing them through whatever policies are configured.  Not an ideal workflow, but could be a good workaround until something gets natively set up to address that situation.

@McAwesome ~/Library/Preferences/com.jamfsoftware.selfservice.mac.plist

The Key is: com.jamfsoftware.selfservice.onboardingcomplete

In that case it sounds like people could run a one liner of something (napkin math) like 

defaults ~/Library/Preferences/com.jamfsoftware.selfservice.mac.plist com.jamfsoftware.selfservice.onboardingcomplete -bool true

as part of a one off policy and that should cover their bases for now as a workaround.

I feel this should be set to be deployed in a Pre-Stage, not something that gets turned on and every device in the environment will get it. I manage a relatively small fleet, but I can only imagine the headache's this could cause for environments with thousands of systems. I'll play around with it in my dev instance, but I'll continue to use DEPNotify in my production environment

The onboarding feature is cool, but seems very half baked.

I could see it being super useful if you could create different onboarding workflows per department, for example.

Having it just mass deploy to the entire environment by default is an absolutely awful idea. Not sure how that managed to get by QA. 

With projects like DEPNotify and Setup-Your-Mac already available and fulfilling this need much more robustly, I don't really know how it made sense to spend resources on an incomplete feature. 

Totally agree, @trevoredwards , and Setup Your Mac Helper makes it even easier to deploy.

@McAwesome 

In that case it sounds like people could run a one liner of something (napkin math) like 

defaults ~/Library/Preferences/com.jamfsoftware.selfservice.mac.plist com.jamfsoftware.selfservice.onboardingcomplete -bool true

as part of a one off policy and that should cover their bases for now as a workaround.

This is helpful info. Will do some testing once we get upgraded this coming weekend.

I agree with others about the limited target instead of being able to scope this. Just limits it use in the real world. 

Setup Your Mac is great, but let's not pretend it was as developed as it is now when it first launched.  It always had some weird issues and oversights that it has since developed past.  The same goes for this Onboarding feature.  It will be refined as time goes on just like those other tools being promoted in here have been. 

@McAwesome you can get the LAPS password in the JSS with this tool https://pro4tlzz.github.io/JamfGetLapsPassword.html

@McAwesome That's not really a fair comparison as there is a different expectation of a tool coming from contributors working in the field in their spare time for free vs. a company that literally is an MDM for Mac devices for profit.

Not expecting perfection out of the gate but a couple of things here really should have been in the released product from the get-go. Checkbox for only applying to new enrollments and able to apply different instances of Onbording to different prestages.

@hunter990 To be clear, I am one of those contributors to Setup Your Mac that you are referring to.  That's part of why I made that point.

What was the thought process internally at Jamf behind saying "applications available in self service are available in Mac Onboarding" but then excluding all applications that come through the Jamf App Catalog/Jamf App Installers?

Genuinely curious why Mac Onboarding isn't compatible with the Jamf App Catalog/Jamf App Installers.

We have upgraded our OnPrem Jamf Pro to version 11.1 and enabled Jamf Remote Access. Now more than 10 Macs have memory saturation and keep prompting to close applications or reboot automatically.
These Macs have a configuration profile called General installed more than 1000 times. Any ideas?

Hey @n_lecchi, we have never seen a behavior like this related to Jamf Remote Assist and expect this is a different issue, but we would like to verify. Could you please start a support case around this issue and include the Jamf Pro logs? Thank you!

Hi lukasz_slodziak, the problem seems to be related to our database, but it was triggered by upgrading Jamf Pro to version 11.1. We are working on fixing the problem, but we don't have a solution yet. 😥

We solved the issue: a Configuration Profile UUID was duplicated in the database.