FileVault 2 Key showing long string of characters instead of 24 characters key

Hello @rmakkapa .  I've dealt with this also and it's totally fixable.  

First, there's a couple things you could do.  1) Not sure if you're on prem vs. cloud, but you "may" be able to contact Jamf Support and see if they can help you run some commands against the database to make the key appear again. I've heard (not seen) that this might be an option in some situations.  2) There is a script you can run which will prompt each customer it's scoped against to enter their password and then a new key is issued and you're done.  

I've done this, currently tracking some remaining users who need new keys and it works.  I would suggest though, since you have to prompt customers for their passwords, it may take a little thought and prep by crafting an email addressing the fact that you'll be prompting customers for their PWs and that you're legit.  Below is a link to the script I used recently to accomplish this.  I hope this helps.  Good luck.  

https://github.com/jamf/FileVault2_Scripts/blob/master/reissueKey.sh 

Hi @steve_summers. Thank you for your response. We are using cloud instance and raised this with jamf, waiting for their response. 

Tried executing the script from https://github.com/jamf/FileVault2_Scripts/blob/master/reissueKey.sh and new key was issued. However, the new key is also encrypted and consists of multiple characters whereas we need the recovery key of 24 characters.

@steve_summersDid you ever get a solution from JAMF support for this?  We are having the exact same issue.  I opened a case with JAMF last week and so far have received no working solutions yet.  Hoping you found or received one yourself?  Thanks.

Hey.  So, I got a solution, but frankly, I had to kinda figure it out myself.  I mean, they guided me to some documents which I had read before, but I had to put a workflow together and test it, then retest it and finally push it out.  I've left it in place, actually, to ensure keys stay current and we don't get into this situation again.  But this is totally fixable, actually easy but there is some pain in the process.

I suggest you go here and get familiar with this GitHub repo: https://github.com/homebysix/jss-filevault-reissue 

There, they have a script which I've used in two orgs (changed jobs....same prob's in both) and it works.  The "reissue_filevault_recovery_key.sh" is the one to look at.  You basically set it up in a policy, and then it will prompt the end user for their login password, and they get a new key.  Boom...done.  But, that's not the pain in this process.  The pain comes from having to do the leg work to let end users know that they will be prompted for their password, why it's needed AND that it's legit. 

In the script, you can make it look pretty official, use company logo's, it works pretty well.  You'll need a smart group to target.  I can't upload the screenshot of mine, but if you're on Slack, hit me up and I can share it with you.  

Let me know if I can help further.  Glad to assist.  (don't sweat it..you got this!)

@RickR we have recreated the file vault configuration and re-deployed to all Macs. Post that able to retrieve the recovery key.

Issue occurs if we try to copy the configuration profile from one instance to another instance.

Do you encounter this problem after the solution? I have the same problem.

@gaoyajing0810 , after you have a solution in place and know it's working (You see the keys going from invalid to a valid key), it's possible to continue to see keys become invalid, yes. Here's why: if a machine is nuked and paved to help fix a problem, when the Mac rejoins the Jamf server, if the computer record isn't deleted, it will prompt for a new key since the old key isn't valid any longer.  

Like I mentioned in the previous post, I leave this key re-issue policy active targeting all end users who have an invalid key.  That way, the situation manages itself and I don't have to do much.  

I hope that helps.  If not, let me know and we can chat further.  Thanks. 

Encryption is enabled by policy, and the returned key is normal. Long string problems occur with description file encryption. The decryption certificate expires. After communication with Jamf, we can release a new key return description file after canceling the problematic description file. But I haven't had time to test it yet. Thank you very much for your help. I have uploaded the script to my Jamf environment for use.

worked with the script for me.

Thank you very much for having solved it in the way you provided. Thank you very much