JSS is losing personal recovery keys

New Contributor

Hey all,

I'm wondering if anyone else is seeing this. I apologize in advance for the wall of text. I'll try to keep it brief.

We're doing a 1-1 deployment and our workflow requires the setting up of 2 accounts (one for "personal" use and another for "work" use). We've been told to try to keep our interference down to a minimum, since the end users are leasing the computers. We're trying to treat it almost like a pseudo-byod style deployment.

Our workflow is that the computer is enrolled via DEP, we walk the user through the setup assistant and they create the initial local admin account.

We have 2 profiles scoped to these computers:

A configuration profile that has a "directory" payload which binds the computer to our AD domain and a "mobility" payload that creates a mobile account on login. We've disabled syncing completely, but we want the users to be able to access the account even when offsite.

Then we have another profile that has the "security & privacy" payload that enforces Filevault and a "FileVault Recovery Key Redirection" payload that is set to "automatically redirect recovery keys to the JSS".

The users will finish the setup assistant, get to the desktop and then we get them to log out. The profile kicks in and prompts for their password (as expected), pops up the recovery key (as expected) and reboots. We prompt the user to take a picture of their recovery key. After they login again, we verify in the JSS that the recovery key is there. So far so good.

Then we prompt them to logout and sign in with their AD credentials. This creates the mobile account. We then have a policy which runs and installs some basic documentation into their documents folder, etc. It also runs a script which assigns the device to the AD user in the JSS and also elevates the AD user to an administrator.

Here's where things start to get weird. I've noticed that on approx. 50% of these computers, if I check the FileVault status in the JSS, it's now flipped back to "not configured" and we've lost the recovery key!!

Since we're supposed to be mostly "hands off" on these computers, we don't enable the management account for FileVault passthrough, since we want to keep it hidden from the login window. I believe this means that we can't use the built in FileVault features in the JSS.

Our current method of dealing with this is to then run an "fdesetup changerecovery -personal", which then requires us to tell the client that they need to delete their old picture and take another picture, etc.

It works, but it doesn't inspire much confidence in the users and it also causes me to question whether the keys will randomly disappear from the JSS again at any given time.

Any advice would be appreciated.


Contributor III

What OS is being used in your workflow?
My first initial thought is that, since it is intermittent (50%), the cause is a chaotic element in the environment. I am thinking that FileVault encryption is not even completing for some reason. if it paused, it may have been unable to resume. In Yosemite, there was an issue (fixed in 10.10.3) where it would not resume due to the CoreStorage volume--the volume who's only function is to support FileVault--being unable to resize.
Speaking of CoreStorage, what is the state of the CoreStorage volume on the affected machines?
@rtrouton provides an explanation of the resize issue (if it is relevant in your case) in [https://forums.developer.apple.com/thread/3839](link URL); I also like it because he provides some useful tips when troubleshooting CoreStorage volume issues.
What do your logs (like /var/log/system.log) say? Also, you can create diagnostic logs with sysdiagnose and csdiagnose (both are in man pages).

New Contributor

I meet the same problem with a small deployment (±100 Mac) I do actually.
First it seems to affect mostly MacBook Air… (Mainly but not scientifically verified.)
Sometimes my Macs are declared Filevaulted BUT in the JSS it appears that there are no partitions encrypted … and no valid FV2 keys too !! In the meantime, the FV2 panel display me an “A recovery key has been sent.” Yes, but to whom?


New Contributor

@SeanA Thank you for replying.
These computers are all brand new, they arrived with 10.11.6.

After the reboot, there is a pop-up indicating that FileVault encryption is paused and will complete when the laptop is connected to power. Do you think this may have something to do with the problem? I may be able to do some testing.

I may be wrong, but I suspect if the FileVault didn't complete, it wouldn't have deferred the key in the first place?

If the key didn't appear at all, I'd honestly be less concerned. I'm more worried that the key appears in the JSS and then disappears again within a couple of minutes.

I haven't done much digging around in the logs (mostly because we're typically dealing with a line-up of clients who are all waiting to collect their new laptops, and the focus is to get the laptops in their hands and move on to the next person in line). However, I have been able to reproduce this problem a few times on our testers, so I'll try to find a bit of time to see what I can dig up in the logs.

Thank you for your suggestions.

@seb This is similar to what we're seeing. Typically, we only get the "No Partitions Encrypted" until the user connects the laptop to power and the encryption completes. Then it changes to "1 of 1 Partitions Encrypted". We also get "Unknown" for the Validation state, and the FileVault 2 status is "not configured".

New Contributor

@yukonluke The problem is now solved for me. You have to complete the process with the power adaptor before the JSS receive the information about FV2 and the valid key… You also need to create this as a policies not directly by yourself on the end user computer.