We are having a really strange file vault issue here. We have some machines that encrypt with our config, everything looks fine then, out of the blue, the personal recovery will report as invalid and shows as invalid when I check on the client with fdesetup. Then sometimes, it will resolve itself. Ive even compared DB backups to see if the recovery key changes and it stays exactly the same.
I hope someone might have some ideas because this could lead to some major issues.
Are you using Sites? I've found on my deployments that if you are using Sites and you have the web interface set to a specific site, they you can not see the keys when requested and you get the Invalid error. However, if you switch to Full JSS then you can see the keys and there is no invalid error.
I'm having a similar issue. The "fix" seems to be booting to the Recovery Partition, unlocking the disk with Disk Utility, running a repair disk (which typically shows no errors to be fixed), and repairing permissions. On reboot and subsequent recon, all is peachy. I say "fix," because well, it's not a fix. I have yet to find a pattern other than it seems to be more common with users that only sleep their computers as opposed to doing an actual reboot. However, it's not exclusive to those people.
Sorry to re-ignyte an old thread, but we are seeing similar behavior. Everything was OK with all of these units. The drives are encrypted and when that occurred, the keys reported as valid. Out of ~400 units encrypted, the number of invalid keys has been creeping up, now to around 15.
FileVault 2 Partition Encryption State:Encrypted
Individual Recovery Key Validation:Invalid
Institutional Recovery Key:Present
Has anyone else seen this issue and know of a fix?
I just wanted to put my hat in the ring. We just started encrypting our fleet of 300 macs. While encryption seems to be going smooth we have now 70 computers that are showing INVALID keys. And this number is slowing increasing each day. Computers that used to be fine are now having issues.
JAMF Support has recommended rebooting, running first-aid, and also trying out their ReissueKey script.
While these options make it work when you try them, those computers just return to an INVALID after a couple days.
If anyone has found any type of solution I'd love to hear it.
@danshaw In our experience, invalid doesn't necessarily mean it doesn't work. Something may have been interrupted, the machines haven't re-booted in a while, or some other reporting issue...
But, we have put the reissuekey script in place and it's great. Even better if your management account is a fv2 user on the machine - then it can be done in the background. I wouldn't sweat it though - keep track and maybe fine one that's stayed in there for a few days and just try validating the key that jss has.
Thanks @koalatee - That makes me feel better. Unfortunately our management account isn't a user and we don't have an institutional key in place. So we are pretty dependent on these key's working. If they don't, then we can't access any data if we don't have the users password.
In a few computers I have tried validating the key using fdesetup and they all have come back false.
When you say that you have put the script in place, what you exactly mean? Do you do it in the background using your management account? I've put this script in Self Service for users to use, but it requires them to put in their password and reboot their computers. Neither of which they really enjoy doing.
@danshaw Our management account isn't a user either, we force the users to do it - but only ones that don't actually have a key (since encryption happened before JSS was implemented). It shouldn't require a reboot though - but I assumed you were calling this reissuekey.sh
You just need to make sure you have a profile deployed to redirect FV2 keys to JSS.