As forewarned by
Apple, Richard Purves and recently one of my dataJAR colleagues Richard Mallion, Apple is making a change to APNs on March 31, 2021.
As detailed within the
dataJAR blog post, this change is between MDM servers and Apple and not managed devices.
Jamf Pro 10.23.0, there has been a toggle to enable this change to HTTP/2 for APNs communication.
Jamf Pro 10.28.0 release earlier this week, Jamf Pro will default to HTTP/2 and if you’re self hosting Jamf Pro this release will flip over the APNs communication to use HTTP/2.
If you’re Jamf Cloud, then this change has already been made for you.
So, this short post is just to bring attention to this change for those that need it.
And if you’d like to know more, for more info see the aforementioned
blog post on the dataJAR blog.
dataJAR, I recently worked with a customer which wanted to make use of Jamf Pro’s Enrollment Customization option.
However, with everything setup, we were presented with the message
“Error <kCFErrorDomainCFNetwork:303>” whenever trying to load any of the defined PreStage Panes.
I reached out to Jamf Support, but they hadn’t see this issue & searching the
macadmins Slack didn’t bring up anything either.
Long story short (& in an attempt to not create my own
DenverCoder9 moment), we discovered the issue to be down to the environments ingress controller being configured with HTTP/2 support by default.
As soon as we disabled HTTP/2, everything worked as expected.
Hope this helps someone else too.
With the release of Jamf Pro 10.20.0, Jamf has fixed
[PI-007508]. This is the PI for DEP Sync failing due to TLS changes being needed for on-prem installs & one which I blogged here.
The fix from Jamf forces TLS1.2 for connections to Apple for DEP/Automated Device Enrollment.
So, if you made a change to your TLS settings as I mentioned in my
previous blog post, you can remove those changes.
dataJAR, we’ve been running all datajar.mobi deployments with no TLS settings enforced via our setenv.sh for a couple of weeks now & all is syncing as expected.
few posts here & during our JNUC 2019 talk, James & I detailed how we at dataJAR deal with managing 100+ Jamf Pro & released a few repos with various items we use day-to-day.
This blog post is concerned with one of those repos, which is titled:
The repo can be accessed via the hyperlink above.
This repo contains a list of messages which can appear in the JAMFSoftwareServer.log, with a note as to what action might be required due to the messages being generated.
For more details see below, else click the link & PR’s are welcomed to expand the repo.
Tonight, Apple released macOS Catalina.
See below on how to block this upgrade with Jamf Pro.
A week after the recent updated
Terms & Conditions, we saw DEP sync errors reappear in our datajar.mobi deployments.
Below is some detail on what has caused these new sync errors & how to resolve.
Last night, Jamf released Jamf Pro 10.13.1 & 10.15.1. These were released due to
This PI is noted as a “critical security vulnerability” which “does not pose a risk to private data or managed devices. It does have the potential to impact the integrity and availability of your web server” but “impacts versions of Jamf Pro 9.4 and later”
As Jamf Pro 10.15.0 was only released 19 days ago,
10.15.1 is the 10.15.0 release with PI-007507 having been patched.
However, for organisations that are still on Jamf Pro 10.13.0 or below due to the move to
Java 11 needed for Jamf Pro 10.14.0+, Jamf have released 10.13.1, which is also patched.
Please read the following
Jamf Nation post for more information, & if you’re not on a recent Jamf Pro release please also see this post before any upgrades are attempted.
Recently we updated all our
datajar.mobi instances to Jamf 10.7.1, for Mojave support.
All went well. Except for a couple of instances where their
Jamf Infrastructure Manager was being used as an LDAP Proxy.
Well, turns out this was a change to
Java 8 Update 181, which we updated to at the same time. And, that this is an issue not just with Jamf Infrastructure Manager, but could be with LDAPS in general.
Below details these changes, & overcoming this issue.
With Jamf Pro 10.6.0, Jamf changed the default storage engine from
MyISAM to InnoDB.
Jamf also released a tool to convert the tables with the release of
However, as the Jamf supplied tools are
not available currently available as a standalone download for those of us that do manual installations & as we host our datajar.mobi instances on Kubernetes… we went the manual route.
Below is how we performed these conversions.
On day 3 of JNUC 2017, I gave my third & final talk of the conference:
“Securely Managing Identities Across Mac and G Suite with JumpCloud”
This talk should show just how easy it is to get started with
JumpCloud. Along with an overview of how at dataJAR we’re leveraging JumpCloud to integrate G Suite within our Jamf|MSP platform (datajar.mobi), as well as bridging authentication across various other cloud systems & bring 2FA to our Macs.