What is wrong with using the Jamf script?  It appears to be working great on 10.14.x Macs up to and including Big Sur here...interested to know why you don't want to use it.

it does work great, however, the whole point of the configuration profile is to enable + escrow the recovery key(?)
If I onboard someone remotely, I have to inform them the prompt is legit and rely on them to respond to it.

Understand...which is why I branded it for my clients with company icon...

For just initial FV2 enable/escrow, the profile only works fine.  Only using the script for missing keys in Jamf.

Yeah hoping to get the profile working more than fine so I have the initial personal recovery keys. Alas. 

One last ? - are you using the login or logout option?  I had a discussion with someone and they had to change to login to get it working OK...I'm using logout at the moment.

I am using login

Maybe give the logout option a shot...best of luck.
Also, make sure (seen this a bunch of times) that there is no other profile with FV settings in there that can be causing troubles...it can get hard to keep track so each profile here is a unique setting and no more.

I am seeing this same exact behavior (seems like ever since around September 2021. Now it seems almost all new enrollments have their key missing inside Jamf. Using a script to re-issue keys isn't a solution. The config profile is supposed to work, but doesn't.

@greenabundance  Did you ever solve this in your environment?

I am now seeing this happen on a lot of my machines, did anyone find a solution to why the config profile doesn't work?

Hi All i have the same problem in a lot of my machine, did you find something ?

I have this happen to about 50% of my machines on enrollment, which is way too frequent. I didn't know about Jamf's reissueKey.sh script so that will help a bit. However, this shouldn't be a problem in the first place, so I'm very curious as to the source of the issue.

This is my thought as well. We are still seeing this happen but cannot determine a root cause. The machines are all setup exactly the same, but this issue happens randomly to some. The re-issue script does work, but it shouldn't be needed in the first place.

Possibly splitting hairs, but I'm trying to see the difference between using this reissueKey.sh script and using a Disk Encryption Policy that issues a new recovery key.  https://docs.jamf.com/10.24.1/jamf-pro/administrator-guide/Issuing_a_New_FileVault_2_Recovery_Key.html 

I'm not sure if this is the same issue. All of our Mac's successfully escrow the personal recovery key when they are enrolled. But we have another policy that is scoped to a smart group ("FileVault 2 Individual Key Validation" is not "Valid" AND "FileVault Enabled" is "On") and every once in a while it seems that some Mac's for whatever reason suddenly falls into this category.

It appears that when this happens, the Personal Recovery Key is actually still there, but "Personal Recovery Key Validation" reports as "Unknown".

I have been seeing this lately as well.  Is it possibly a bug or something with Jamf?  From what I have seen, when the device is first enrolled, it grabs the recovery key. But if we would every turn off filevault, re enable via self service policy, logout (forces it back on) and login, it turns it back on but the recovery key says "unknown".  Very weird.

the FileVault 'valid' 'not valid' issue has been around for.. a while.. think there was something about it being fixed recently.. one of the many PIs .. You can mitigate with policy / smart groups / extension attributes.. but Escrow Buddy.. does it better.. 

Is the escrow buddy config profile just the jamf profile that has it built in or is it a custom profile created?  I was confused by that on the git hub page

the config profile is the one you've already setup.. the binary does some MDM calls that get that to renew.. and this is called by writing out a plist via policy. 

I ran into the same issue. This might be a Bootstrap token issue. Where the current user isn't the Volume owner.