@cskj I'm experiencing the exact same issue, and my findings are the same as yours. Have you made any headway with this issue yet?

@cskj I have also experienced this. JAMF recently came to my office and I brought this up, but haven't heard back yet.

The only resolution I have found for this was removing the JAMF framework and then re-recon'ing the computer. Once the computer had the FileVault 2 key escrow profile again, it worked.

I have also tested removing the profile (removing the computer from the Configuration Profile scope), then re-adding it to the Configuration Profile scope. Unfortunately, this also did not resolve the issue (and I am not sure why).

I would love a response from JAMF on this.

Unfortunately removing the framework and re-enrolling doesn't work in my environment. I found that decrypting and re-encrypting solves the issue, but this isn't really feasible as a solution for us. We'd also like to get to the bottom of why this is happening in the first place.

@kitzy - That is very interesting. If decrypting and re-encrypting resolves the issue, it implies that the FileVault 2 key redirection profile works, and should have worked all along. That being the case, it sounds like this is probably a relatively complex issue that could be an OS X issue itself.

Hey all,

I've been working on this issue very closely the past week or so and have been able to recreate similar behavior in-house. Introducing network connectivity drops during the policy that reissues a new key and attempts to escrow it to the JSS seemed to then exhibit the behavior on a few test machines. Tentatively, this has been filed as PI-002132 until our product specialists can confirm exactly what's going on. If we're encountering this issue, I strongly urge you to reach out to your JAMF Buddy and create a case.

Thanks!

This is a bug in OS X. We've opened a case with Apple unfortunately I don't have RADAR number to give you. In the meantime you can recover from the issue most times with the below commands or a reboot.

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.security.FDERecoveryAgent.plist (do this until it tells you "Could not find specified service”)

sudo killall FDERecoveryAgent

and then you can issue a new key that will be escrowed.

@iJake - thank you for this, it will definitely help the next time this issue occurs.

@paul.nichols - I'll definitely escallate this up the chain when it occurs next. Thanks!

@iJake That works in my testing as well. Thanks for the tip!

Bumping this thread because apparently it is still an issue in one year later in 2017 with 10.12.6 and JSS 9.100, so it seems likely that indeed it's MDMs fault apart from all those other factors.

In my experience:
• The first changerecovery command works but then any subsequent attempts made will hang.
• Rebooting will cause the the new key to send at startup, even if it was hung during "Escrowing".
• However any additional changerecovery commands will hang, whether rebooting in between or staying up.
• Running WireShark during a hang showed that no outbound connection to the JSS is even attempted.

Running this command once was sufficient to unload FDERecoveryAgent, no killall needed (a big thanks to @iJake )
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.security.FDERecoveryAgent.plist

BTW - we'll see how 10.13 behaves with the new key escrow payload
com.apple.security.FDERecoveryRedirect is being deprecated and com.apple.security.FDERecoveryKeyEscrow is taking it's place (no Jamf Pro 9.100 does not make this MDM payload yet)

@iJake is the kill command a safety net, in case unloading the Launch Daemon doesn't stop the process?

sudo killall FDERecoveryAgent

@brunerd saw the same result, tested on a spare computer and the process disappeared when unloaded.