Interpretation
How do you interpret the customer's words?
An IT admin has Macs that sit pre-enrolled in inventory on an old MDM token, then get their real first setup months later when handed to a user. On macOS 14 and 15, that delayed first-login flow sometimes leaves the user without a Secure Token and without APFS volume ownership. Without volume ownership, the user can't authorize OS updates, and the admin has seen it take two to three full disk wipes (Apple Configurator revive doesn't fix it) before ownership is finally granted. The admin has no visibility into which hosts are affected until a user reports a broken update — there's no query they can run across the fleet to check ahead of time.
What's Fleet missing?
There's no table or MDM command that reports per-user Secure Token / volume owner status. Fleet's apfs_volumes table reports volume-level attributes (encryption, filevault, role) but nothing about the crypto users tied to a volume. The only way to get this today is running diskutil apfs listCryptoUsers <volume> (or sysadminctl -secureTokenStatus) by hand or via a script pushed to every host — there's no native osquery table for it, in Fleet or upstream.
What does the customer's ideal workflow look like?
The admin writes a Fleet policy like SELECT 1 FROM <table> WHERE volume_owner = 1 and scopes it to their macOS 14/15 hosts. Any host with zero volume owners shows up as a failing policy in the Fleet UI/API, so the admin can proactively re-enroll or wipe the device before the end user hits a blocked OS update — instead of finding out from a help-desk ticket.
re: https://fleetdm.unthread.io/dashboard/inbox/all/conversations/647c6e07-2bfe-402f-997e-a81190072d28
Interpretation
How do you interpret the customer's words?
An IT admin has Macs that sit pre-enrolled in inventory on an old MDM token, then get their real first setup months later when handed to a user. On macOS 14 and 15, that delayed first-login flow sometimes leaves the user without a Secure Token and without APFS volume ownership. Without volume ownership, the user can't authorize OS updates, and the admin has seen it take two to three full disk wipes (Apple Configurator revive doesn't fix it) before ownership is finally granted. The admin has no visibility into which hosts are affected until a user reports a broken update — there's no query they can run across the fleet to check ahead of time.
What's Fleet missing?
There's no table or MDM command that reports per-user Secure Token / volume owner status. Fleet's
apfs_volumestable reports volume-level attributes (encryption, filevault, role) but nothing about the crypto users tied to a volume. The only way to get this today is runningdiskutil apfs listCryptoUsers <volume>(orsysadminctl -secureTokenStatus) by hand or via a script pushed to every host — there's no native osquery table for it, in Fleet or upstream.What does the customer's ideal workflow look like?
The admin writes a Fleet policy like
SELECT 1 FROM <table> WHERE volume_owner = 1and scopes it to their macOS 14/15 hosts. Any host with zero volume owners shows up as a failing policy in the Fleet UI/API, so the admin can proactively re-enroll or wipe the device before the end user hits a blocked OS update — instead of finding out from a help-desk ticket.re: https://fleetdm.unthread.io/dashboard/inbox/all/conversations/647c6e07-2bfe-402f-997e-a81190072d28