Closed Penguin2071 closed 3 years ago
Hi @Penguin2071 - it's likely that running two recons may be necessary, due to the way Jamf verifies the key. If that doesn't solve the problem, feel free to reopen this issue with log output from the latest version of the script. Thank you.
Ran your script on a scope of 10.9 - 10.12 computers, and while all the policies are successful, about 1/3 of them still had individual recovery key validation still reporting in JSS as unknown. For additional context: The key redirection profile was delivered via policy, and your script was a postinstall script.
In troubleshooting the 1/3 unknown key so far, unloading /System/Library/LaunchDaemons/com.apple.security.FDERecoveryAgent.plist does not work as the service is not found "Could not find specified service”; killall FDERecoveryAgent does not work as "no matching processes were found". Running a recon after these two steps does not help.
According to https://www.jamf.com/jamf-nation/discussions/18716/filevault2-stuck-escrowing-recovery-key#responseChild117217, it seems that network connectivity drops during the policy could cause this behavior. In one computer so far, I had the user move from WiFi to wired ethernet connection and the 2nd attempt at running the policy resolved.
I was wondering if you came across this type of behavior before. Thanks.