Hi Jamf Nation,
Today we are making an update for Jamf Pro available to include fixes for the MDM commands table that caused some Jamf Pro server performance issues and prevented apps from updating. A cloud upgrade is scheduled for this weekend, see below for details. Please check your Jamf Nation alerts or the release notes for additional details on this release.
Standard Cloud customers will be upgraded directly to 10.32.2 during this weekend’s scheduled release.
Read the full release notes here.
Cloud Upgrade Schedule
Your Jamf Pro server, including any free sandbox environments, will be updated to Jamf Pro 10.32.2 based on your hosted data region below. Need assistance identifying the Hosted Data Region of your Jamf Cloud instance? Check out this guide to find out how.
|ap-southeast-2||Sept 24 at 1400 UTC||Sept 24 at 2300 UTC|
|ap-northeast-1||Sept 24 at 1500 UTC||Sept 24 at 2300 UTC|
|eu-central-1||Sept 24 at 2200 UTC||Sept 25 at 0800 UTC|
|eu-west-2||Sept 24 at 2300 UTC||Sept 25 at 0500 UTC|
|us-east-1||Sept 25 at 0400 UTC||Sept 25 at 1900 UTC|
|us-east-1 sandbox||Sept 25 at 0000 UTC||Sept 25 at 0900 UTC|
|us-west-2||Sept 25 at 0700 UTC||Sept 25 at 2000 UTC|
For real-time messages about your upgrade, subscribe to alerts.
For information on what's new in Jamf Pro 10.32.2, please review the release notes.
I logged in simply to say "thank you". After getting no quick help from Jamf Support on this urgent issue, your "fix" seems to be working right now. I found one single device with no SN and deleted the device record. Early reports are looking good that this may have started resolving our pending app installs and the VPP logs look clean since the device record was deleted.
Now I'm waiting for Jamf's after-action/post-mortem as to how one singular device (in a fleet of 12,000+) can effectively break our entire instance. Can't wait to hear what they have to say about THAT.
Thank you, this ended up being the problem in our instance. Somehow an iPhone got enrolled without a serial number and all VPP license assignments ceased. I'm a new Jamf admin and was wracking my brain thinking I configured something wrong. Somewhat disconcerting that something so trivial can break a core functionality of the MDM.
I'm curious to hear what you saw in your VPP logs (JAMFSoftwareServerVPP.log or something else?) before that cleanup. And yes, having the whole system break by a few entries without SN is quite strange. I better stop here before getting started on the many java tracebacks triggered by conditions that appears normal and harmless to me...
If this was in response to my reply above: the error that seemed to go away after we deleted the device record with the missing SN was error "9603". No more of those errors popped up in the VPP log after I deleted that device record. Can't say definitely that was the error that was causing our app install issues, but, like I said...that's the one that stopped appearing once the record was deleted. We were still seeing plenty of "9600" errors, but those didn't seem to affect the ability for apps to install.
Hi all - from the Jamf Product team:
Thank you all for your feedback. Releasing two Jamf Pro updates back-to-back like this is definitely outside the norm. These particular releases are important but distinct, addressing a security vulnerability [PI-010111] and significant performance issues [PI-010150], [PI-010151]. Unfortunately, our path to resolve these issues as quickly as possible necessitated this unusual release cadence, and we regret the inconvenience this has caused.
I appreciate everyone who shared their thoughts in this thread; we hear you and we remain focused on improving the way we build and release great products in the future.
This is the first time I've encountered this limit, which stopped the jamfproinstaller.run script outright. We run clustered with Linux instances in our AWS VPC with MySQL running separately on RDS. We're used to seeing the alert about MySQL not running (during install-time on the webapps), but those alerts do not stop the jamfproinstaller.run from running. In this case, the freespace limit (we use 20GB on each webapp instance) stopped the installer outright.
Thanks for the info! Weird that info doesn't persist in subsequent releases. I don't _always_ scan all past release notes before installing later versions. Seems like it should be mentioned in system requirements?
I'll be adding the the `-d` flag per this note in 10.31.0 release notes which @PCalomeni mentioned.
You can bypass the disk space check by executing the installer with the -d flag. Execute a command similar to the following to skip the disk space check:
BTW without specifying anything, this is what I saw last night...
Unfortunately the '-d' only avoids that the script aborts due to the disk space. It does not prevent you from getting the warning and being asked to confirm that you want to continue 😞
So to run the install from a script without user interaction you will have to do some extra hacking to reply to the question...