This is a bit of a problem I've encountered and I'm close to just re-encrypting the machines but thought i'd try here first.
About 30 or so of my OSX devices seem to be missing their individual recovery keys in the JSS, they certainly used to have this info but now are showing as Encrypted, individual key validation is unknown and disk encryption configuration is blank.
My management account is not a filevault user so i can use that and i don't use and institutional key.
I have the key redirection config profile enabled to the jss but generating a new key with fdesetup changerecovery -personal is not posted to the jss.
Any one got some inspiration for me?
We're using this through Self Service to reissue FileVault 2 keys. It will prompt the user and then attempt to issue a new recovery key, escrowing it in the JSS during the process.
I have a question about this post... did anyone discover or address WHY recovery keys, that were in the JSS, were suddenly blank?
We have experienced this very issue when a user had a problem, our tech went to the JSS to get the Key and the field was blank.
We then dug out an archived backup of the JSS from 65 days before, restored it to a new VM, logged in with the local Admin account and... Voila!... the key was there.
So now we are looking at all our computer records to see what other keys are 'missing'.
My co worker was looking at the SQL and found the 'hide key' attribute (in the backup instance)... flipped it and missing keys reappeared.
We haven't dug much deeper into the production instance yet. We need to determine which machines are encrypted but have a 'missing' or 'unknown' key and find and fix this.
What really concerns me is that data that existed in the database at one point is either deleted or hidden.
Why is this happening?
I want to know why they are disappearing... not some script to make them come back if you discover they're gone.
In all the data that is collected and stored by JAMF -- the recovery key, stored is a database, for use if the machine needs unlocking is, arguably the MOST important piece of data in a computer record.
To have it inexplicably disappear is completely unacceptable.
@brodjieski having the same issue. even after flipping the deleted status, individual key appears and still shows unknown. a few keys in database read as "empty set," which doesn't allow me to flip the deleted status. been working with support to issue new recovery keys and find the root cause.
@brodjieski and @ginakung we've been having the same issue. Would you be able to post the mysql commands you're using to verify the status of the key on a specific device (and potentially flip it if incorrect)?
We have also recently found this occurring on machines freshly enabled for FV which seem to have encrypted but have not stored the key in the jss. I have then:
Added a FileVault Recovery Key Redirection config profile to the machines in question
Turned off filevault manually
Turned back on filevault manually, whereby I'm prompted to store the recovery key in the jss
I then do this, and the key appears to store correctly in the machine record in the jss.
I'm curious as to why this is happening as our filevault enabling scripts/policies have not changed recently. The machines in question are older machines and are running 10.12.
Has anyone got a solution for filevault 2 showing as not configured under the management tab, i have tried running the script linked in this post and it consistently returns:
Username is not on the list of FileVault enabled users
sudo fdesetup list
and the user im running the script as is in the list of filevault enabled users.
Any suggestions would be great.
We have submitted a ticket as well. This seems to be an ongoing problem. We had this issue back in September right before 10.9 came out. So now it's happening again right before 10.10 is released (cloud). The last time it fixed itself after the upgrade but I would like to see a solution before that gets done because I don't want it happening again when 10.11 comes out.
Sorry to re HASH an old thread, but has there been a resolution to this issue? We appear to be experiencing the same, and I need to find a solution to re issue a new individual FV2 recovery key and have it escrowed in the JSS. The script referenced above runs cleanly with a return code of 0, but never escrows the key in JAMF.
So after reaching out to JAMF support - they suggested the following:
Which I have tested in our environment - and it works.
The only change I made was to publish the policy out to Self Service - to let our users run when they are ready.