I am looking for a solutions to get the recovery key in my JAMF console for those mac devices recovery key is missing, but user should be interrupted. I can see it has happened for both personal and institutional key. What is the main concept of personal recovery key validation, some time it is showing invalid or unknown but recovery key is there, strange! Please help to understand and also with a perfect resolution I am looking for. BTW device is getting encrypted by a config profile and to escrow the key in JAMF.
We're also seeing some machines that have had new FV recovery keys (PRK) issued followed by a recon, which does update it in Jamf. Fast forward a week or so and those same machines are back on the list of "unknown" with some of them not having the key available once again while others just have the status of "unknown".
Still nothing that I've seen or heard of yet. Seems like there is definitely something up but perhaps we'll see some of a resolve as we begin upgrading to Ventura.
Not sure if anyone else has seen the same issue on any Ventura machines yet?
Just replying to say, we’ve finally gotten Escrow Buddy implemented in our environment and it’s truly been a lifesaver when it comes to those FV recovery keys!
Thanks to Elliot Jordan here from the forum and team for creating that tool, it’s been outstanding
@Asifahmed, elliotjordan gave the answer so you should be all set. I can chime in with a few points. I have not used Escrow Buddy but FV Reissue PRK script and profile that is mentioned above. I think Escrow Buddy forgoes the need for a config profile not sure, would have to look at it. What I have noticed in my travels, when rolling out a new Jamf Pro, there are no Macs yet enrolled so there are Invalid PRKs, and if I am not mistaken, I believe in some later version of Jamf Pro 10x and 11, Jamf now has this built in as part of a FV enabling config profile, it now has an Escrow PRK (I think that feature has been there for a bit, but there may be something new with regards to PRK ). So any Mac that gets (ADE I would think, why any other way) enrolled, and has a FV enable requirement is going to FV enable and escrow the key and show as "Valid", so you are good. When we inherit a Jamf Pro environment and FV is involved, for sure we are going to see FV enabled, but the PRK is "invalid", hence we need a Smart Group that shows "Invalid", and scope something like Escrow Buddy to these Macs. I think Escrow Buddy does not invoke a window and a corresponding user password entry, which is great. It's just transparent. And about Recovery Partition and FV, not related really. But there is no Mac I have seen where macOS installed correctly and there is Recovery Partition, in other words in macOS is booting / working, there by definition is a present and functioning Recovery Partition. Another thing about macOS Recovery Part. Have you noticed for Apple silicon, Macs there is no situation where when you "Erase Mac" you wind up with zero Recovery Part. On Intel Macs, when one Erase a Mac, of deleted / erased the main Volume in Disk Utility, there is nothing to boot from, and hence you would see the "spinning Globe", which you are booting from Apple's AIR server. With Apple silicon Macs, even with Erase Mac, Disk Util erase volume, the Recovery Partition is always there, cannot be deleted, not sure how Apple did this, some boot volume that can never be deleted. I for one am grateful Apple finally did this.
Some say a reboot makes Valid stick. Run the PRK Re-issue policy again, user enter password, but this time the Mac reboots. So a reboot somehow makes "Vaild" stick...This seems to be working on some of the Macs / users that I have worked with...
I was told by support that this is "expected behavior because the process that Apple uses to grab that key can be inconsistent." And Jamf support said that I should run a recon after the reissue key policy runs. I already have a recon as part of that policy, but was told that isn't enough.
So sadly this is still happening and I have not yet found a real solution or explanation.
Hi all! I'm the maintainer of the jss-filevault-reissue workflow referenced above, and I've got a quick update that may be of interest to you.
My team has published a new tool called Escrow Buddy, which regenerates FileVault keys at the loginwindow, thus avoiding the need to prompt users for their password later. It should be suitable as a drop-in replacement for my previous jss-filevault-reissue workflow at most organizations.
You can read more in this announcement on the Netflix Tech Blog, and this post on my site specifically covers migrating from my old workflow to Escrow Buddy. Escrow Buddy's source code and installer are available on GitHub.