Jamf Pro 10.32.2 Release

I literally just updated to 10.32.1 yesterday.

Right! Seems like a lot of oops sorry we need to add one more thing to our product recently... Dont get me wrong I love that jamf is releasing patches, but a little more time could be spent testing pre-production?

Me too! An update a day keeps the boredom away. 🙄

I literally just updated and just kept the update train going.

Again?!?! Do you realize how much prep-work and paperwork each update and service outage entails for your larger customers with change control and internal communication requirements?!? 

Please step up your QA game!

Yup--me too!

What happened to inventory preload? Where did it go? 

Did someone remove all Q and A keys from the keyboards at Jamf?

Sure seems to be a lot of "Hot Fix's" this time around. It really doesn't make the product look good! 

Yep, same thing here as well...we've just gone through the process of change control, upgrading Staging and then Production only to wake up and see that there's a new patch 😅

Would the issue around these tables explain why I can't distribute Mac App Store apps via the Self-Service any more? "Pending - All licenses are in use or the license is not assigned yet" - and no, the licenses are not in use...

mschroder: Check if you have any computers or mobile devices with blank serial number in Jamf Pro - Search Inventory. If so, that could be the cause. It was in our case.

Thanks for the hint. I have removed some devices with a blank serial number. That revived some searches (in fact I had to do the search for these devices directly in the DB, it did not conclude via the MDM), but it did not solve my app installation issue..

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.

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...

I'm surprised a fix for the long "Change Management" step at start-up wasn't worked into this release.

Thanks for releasing this as a hot fix and not making us wait for 10.33.0. No bugs would be great, but when they do happen, I appreciate the option to patch them quickly.

It's Monday 9/27/2021 6:55am EDT and our jamfcloud server is unavailable. Still being updated?

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 @kaylee_carlson, could you/your documentation team update the Linux system requirements for Jamf Pro 10.32.0/2 to reflect the 150GB of minimum freespace, at least when using jamfproinstaller.run?

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.

Hi @seabash, thank you for sharing this feedback. "Disk Space Check Added to Jamf Pro Installer for Linux" was documented in the Jamf Pro 10.31.0 Release Notes. Note that 150 GB is a recommendation, not a requirement.

Please let us know if you have other questions. Thanks!

@seabashWe run our Jamf on RHEL and were able to power past this message. I don't remember the exact language of the warning but I think it gives you a choice and you can continue despite the amount of available disk space. Worth trying! 

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...