We suffered this issue as well, we did a in place upgrade to 10.12.6, I believe this is a bug in the os. We did come up with a answer on this.
Sorry it's not a more helpful response!
This started happening with us on macos 10.13.2. Prior to that, as long as we used both institutional and individual recovery keys it worked. The bug in this case appears to be related to a number of other issues with FV that is on apple to fix as is indicated by apple's own tools not working as expected with FV. For instance using apple's built in tools you cannot add a user account to the machine from the terminal and have it be added to FV anymore. If you change a user's password from the terminal using apple's built in tools, FV is not updated with the new password. All of those worked in <= 10.13.1. JAMF might be able to figure out a work-around, but I wouldn't hold your breath.
What OS are you seeing this on? There's been some massive changes with 10.13... le sigh
must be with 10.13, looks to me that the JAMF crew doesn't test enough when new macOS are released.
I don't 100% pass the blame to JAMF on this. I see 10.13 as a step away from enterprise and towards consumer only from Apple. There are a number of things, FV2 being one, that being enrolled in an MDM doesn't help, not even DEP. Some things have to be done via GUI and can't be done via automated processes. Sure. Great. Definitely more secure, however, it sort of defeats a lot of things that I've put in place over the last few years.
Seeing something similar to this in our environment. No machines on 10.13. We have a policy that is set to run an authenticated reboot immediately if a user is logged in. We get as far as:
Blessing i386 macOS System on /...
Creating Reboot Script...
And then the machine just sits there and does not reboot unless hard reset by the user. Anyone else seeing this behavior?
Found the Issue.
Apple Lied, anything Pre 10.12 we have found, requires a reboot to start the FileVault Encryption, and until then you cannot add extra users.
As filevault is not actually enabled until next boot the reboot script wont work so you need to authenticate on the first reboot, rubbish and totally contrary to the APple documentation, but thats what we have found across our estate.
Machines that cant take 10.12 are being done very carefully, those that can are being upgraded to Sierra before FV2 is enabled.
Anyone have any luck with this lately? I'm still struggling getting it working. Tried 10.10 and 10.13 OS and neither works with the checkbox in the policy.
I have two authenticated reboots that occur during enrollment (macOS 10.12 is our production) and have only seen this occur when corestorage isn’t enabled. After making sure corestorage is enabled it seems to function just fine.
I even have it working with 10.13 non-apfs volumes...that securetoken is giving me issues at the moment.
