I had this earlier in the week. Check your configuration profile that escrows your FileVault 2 Keys. I had removed a good portion of the configuration profile to allow for the ability to change the firewall and rebuilt it as a custom configuration profile. Something in the profile broke the escrow process. Specifically around the encryption and decryption of the keys. After rebuilding the profile using the built in payload the keys were escrowed properly.
@adhuston thanks, looking through the Jamf server logs it looks like our FileVault signing cert renewed when we started seeing this problem, the last entry shows the new certificate
2018-10-10 13:00:52,077 [WARN ] [duledPool-4] [RenewalMonitor ] - FILEVAULT2COMM signing certificate needs renewal before 20181109T104533.000-0800 2018-10-10 13:00:52,077 [INFO ] [duledPool-4] [SigningCertificateHelper ] - Creating FILEVAULT2COMM signing certificate 2018-10-10 13:00:52,344 [INFO ] [duledPool-4] [icKeyInfrastructureHelper] - Refreshing pki information 2018-10-10 13:00:52,583 [INFO ] [duledPool-4] [RenewalMonitor ] - FILEVAULT2COMM signing certificate renewal succeeded 2018-10-12 01:00:51,072 [INFO ] [duledPool-6] [RenewalMonitor ] - FILEVAULT2COMM signing certificate valid until 20231011T130052.000-0700
A couple additional notes on this: PI-006374
In our environment any machine that successfully runs the SecurityInfo APNS command will result in a long string. This command is usually associated with a recon, but sometimes a machine will successfully recon and the command will get stuck in Pending, meaning the machine will continue to report correctly.
Great write up on the mechanics of this process, kudos to macblog. https://www.macblog.org/post/how-to-manage-only-filevault-recovery-key-escrow-with-jamf-pro/
One way to fix this is to deploy a new configuration profile, but if a machine has already reported a long string, it seems to need the FV2 rotate script that prompts the user to enter their password. https://github.com/homebysix/jss-filevault-reissue
We are not sure we want to go that route if there ends up being a server side fix that restores the original FILEVAULT2COMM cert on the server, which presumably would fix endpoints at next inventory without running the reissue script. This would involve a way to upgrade the soon to be expiring FILEVAULT2COMM cert without breaking endpoints.