Why was 9.97 Pulled

This is what I heard from JAMF Support:

We had discovered a product issue which requires immediate attention and is currently being addressed.

I just hope people hear about it before they install. The silence from JAMF is deafening on the issues.

This is what I get from our JAMF Buddy..

All of our dev team is currently working relentlessly to fix the issue. I believe there will be an official communication soon. Apology for the inconvenience, this is unfortunately all the information I can gather internally. Thank you for your understanding,

Doesn't quite put me at ease......

So what for those of us who have deployed 9.97 and are about to hit a week and a half vacation?

another discussion on this

[https://www.jamf.com/jamf-nation/discussions/22512/how-has-9-97-been](link URL)

I was told 9.97 was pulled because of issues related to FV2. I experienced this myself after updating: our machines stopped checking in, all manual efforts to recon, enroll, remove/re-enroll failed with "unknown error." Computer details of machines that do not check in cannot be viewed in JSS. The few machines that do check in do not report accurate information, including FV2 status.

ahhhhh. Our cloud instance was updated early to help with slow laggy page responses... nooooo

@dshepp33 That's exactly what I'm wondering. I was told in November to update to 9.97 when it was available to fix another issue I was having, well now this... especially with break.

We have released a communication regarding the Jamf Pro 9.97 release and product issue here to consolidate the topic. We are working diligently on a solution. Please reference that discussion for future updates.

Looks like for Institutional keys only? Whoooo - I am safe

"9.97 temporarily pulled was related to communication of computers encrypted with FileVault Institutional keys. We've seen that the inventory records will fail to load in the JSS GUI, there have been communication issues between the JSS and enrolled clients with an institutional key, and re-enrollments on these machines have been failing."

Ive got it with Individual keys..

FWIW we have a Jamf cloud hosted JSS so we got upgraded to 9.97 this past Saturday. We are using individual keys for FV2, and we have not seen any issues with checking in, or doing anything with FV2 and keys. So far so good for us.

We're on a self-hosted JSS (in AWS, so kind of like jamfcloud in a way) and have machines with a mixture of FileVault 2 Individual and FileVault 2 Institutional keys… reconning is fine, inventory records display normally, smart group membership has not been impacted. (fwiw) ¯_(ツ)_/¯

we are 100% institutional FV2 keys and have been grounded since yesterday afternoon. Considering downgrading back to 9.96, make sure you have backups!

Lol.. I guess I am stuck with it for the time being... Wonder if it has anything to do with failure to enable MDM upon enrollment?

This is the error that occurs in our log:
Error processing communication content - org.springframework.dao.InvalidDataAccessApiUsageException: Unknown ordinal value [4] for enum class [com.jamfsoftware.jss.objects.computer.Computer$FileVault2ValidStatus];

from my chat with support, the JSS has 4 values for FileVault 2 Key Valid status: Valid, Invalid, Unknown, and N/A. For some reason, when looking at devices, it's trying to access these by the index, but using the ID

@discounteggroll We are having the exact issue in our environment, about 80 percent of our fleet have not checked in or sent inventory since the 9.97 upgrade, the other 20 percent are older Macs with individual FV2 keys and they check in just fine. Our JAMF tech advised against a downgrade to 9.96, something about Macs receiving the wrong binary, so I am in a holding pattern until JAMF comes up with a solution.

@dshepp33 wrote:

So what for those of us who have deployed 9.97 and are about to hit a week and a half vacation?

Lesson learned? :)

We always test new releases in our QA environment, and wait a couple/few weeks before rolling out to production environment.

Going on vacation after upgrading JSS might not be such a great idea. That's a good way to get fired. ¯_(ツ)_/¯

Agreed. In our environment, we do test but haven't yet rolled out FV2 and thus, didn't include it as part of our testing strategy. So, with that said, 9.97 is running just fine for us.

P.S. Part of our hesitancy with rolling out FV2 are the seemingly constant serious issues in managing it. Not to say that it's a jamf thing, last time it was Apple's issue with AD bound FV2 units. Fortunately, we don't bind to AD either!

Here's my testing google doc (pretty specific to our clustered windows VM environment), but sharing in case may help others. I didn't test 9.97, but FV keys are on the list to check for in the testing env

Shared google doc

pretty sure this got us back up and running, YMMV

mysql> use jamfsoftware;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

mysql> UPDATE file_vault_2_computer_key SET individual_key_verified=3 WHERE institutional_key_present=1 AND individual_key_verified=4;
Query OK, 412 rows affected (0.00 sec)
Rows matched: 412 Changed: 412 Warnings: 0

mysql> quit;
Bye

Hey all, in regards to the mysql workaround above, we do not recommend running this as it may cause unintended consequences in future releases. Our team is working hard to get a new release out as soon as possible that will address the issues posted here: jamf pro release 9.97 status updates

A fix has been released. Version 9.97.1482356336 We have installed it. Seems to have resolved the issue.