FileVault Policy marked as failed but encryption is enabled successfully

[skeb1ns]

Hi,

I've got an Interesting situation with some random machines that get imaged in Casper 9.82, OS X 10.11.3.

There is a separate policy configured with the trigger enrollment complete, to deploy our FileVault configuration with an Institutional Recovery Key. I discovered that this policy fails sometimes according to the policy result.

However after checking the affected machine I see that the encryption is enabled successfully so I'm not sure why this results in a failure.

The log results for a successful run is normally like this:

Executing Policy Configure FileVault 2
Fixing Permissions...
Fixing ByHost files...
Flushing System Caches...
Flushing User Caches...
Verifying Disk mounted at '/'
Result of disk verification:
Started file system verification on disk0s2 Macintosh HD
Verifying file system
Using live mode
Performing live verification
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
The volume Macintosh HD appears to be OK
File system check exit code is 0
Finished file system verification on disk0s2 Macintosh HD
Adding institutional recovery user from keychain.
fdesetup: adding user 'local-admin' to FileVault.
......................
FileVault is Off, but will be enabled after the next restart.

The failed result reports this:

Executing Policy Configure FileVault 2
Fixing Permissions...
Fixing ByHost files...
Flushing System Caches...
Flushing User Caches...
Verifying Disk mounted at '/'
Result of disk verification:
Started file system verification on disk1 Macintosh HD
Verifying storage system
Checking volume
disk0s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
Logical Volume Group 69702427-3079-4304-9948-7AF723A84DB0 on 1 device
disk0s2: Scan for Metadata Volume
Logical Volume Group has a 24 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 2 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify E51CCCFD-9B79-48A3-9F9B-1BA8F5F6954C
Load and verify C9A4354B-7C22-423B-B258-CDE8D9B298EA
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 69702427-3079-4304-9948-7AF723A84DB0 appears to be OK
Storage system check exit code is 0
Verifying file system
Using live mode
File system check exit code is 0
Finished file system verification on disk1 Macintosh HD

So apparently the policy quits logging after the Hard Drive check, sends it back to the JSS, the result is missing crucial "success" information and gives a failure.

Any idea what's going on here?

Thanks in advance!

[mikeh]

By any chance, are the storage systems on the failed systems Fusion Drives?

The error message you posted looks exactly like the log from Disk Utility when it verifies a Fusion Drive.

[edit] The only reason I mention this is that I wonder if preparing Fusion Drives for File Vault might need extra steps. We just done done with an institutional-wide roll-out of FV2 on laptops. We didn't run into Fusion Drives, naturally, but that's my initial suspicion.

[skeb1ns]

No, we don't use fusion drives. 99% of the devices are rMBP's and a few older iMac's with regular HDD's. We do use different models in our environment (mostly late 2013 & mid 2015) but it occurs on both models now that I'm comparing a few machines.

[skeb1ns · Accepted solution]

This problem is resolved as far as I'm concerned, there is something fishy going on with the enrollementComplete trigger that is specified in my first boot script. This trigger works fine but isn't updating the policy results in Casper, which results in all enrollment policies running twice.

Not a big of a deal :).