The Profile That Wouldn't Apply
A design firm manages 300 Macs with an MDM. They deploy a configuration profile that sets a Wi-Fi payload, a restrictions payload disabling iCloud Drive, and a FileVault payload requiring institutional recovery key escrow. After a week, help desk reports: (a) 40 Macs show Wi-Fi connected but the profile status is 'Failed'; (b) iCloud Drive is still enabled on 25 Macs that are enrolled but were migrated from an older MDM; (c) FileVault escrow shows 'Pending' on 12 Macs. All devices are supervised and running macOS 14. The MDM admin recently edited the profile to add the FileVault payload and re-pushed it.
1. Explain the likely cause of the 'Failed' Wi-Fi payload on 40 Macs and how you would verify.
Read the worked answer
A profile that bundles multiple payloads can fail as a unit or per-payload depending on the MDM. Common causes for Wi-Fi payload failure on supervised Macs:
- The Wi-Fi payload references a certificate or identity that isn't installed yet (payload ordering/dependency). If the profile installs the cert in a separate profile that hasn't landed, the Wi-Fi payload fails.
- Conflicting Wi-Fi configuration already present (e.g., a manually configured network with the same SSID and different security settings) can cause the install to error.
- The profile was edited and the new version conflicts with a previously installed instance.
Verify: check MDM command logs for the specific install error, inspect sudo profiles show -type configuration on an affected Mac, and confirm the certificate profile installed before the Wi-Fi profile. Sequence dependent payloads into separate profiles with explicit ordering.
2. Why is iCloud Drive still enabled on 25 migrated Macs, and what is the correct remediation?
Read the worked answer
Migrated devices often retain a user-level or device-level setting that the new restrictions payload doesn't override because the restriction is applied at a scope that doesn't cover the existing configuration, or the old MDM left a stale profile. Also, on macOS, iCloud Drive can be enabled per-user; a device-scoped restriction may not remove an already-enabled user setting until the user signs out or the setting is re-evaluated.
Remediation: confirm the restrictions payload is scoped to the correct smart group including migrated devices, remove stale profiles from the old MDM, re-push, and verify with profiles show. If the restriction is correctly applied but the toggle persists, a sign-out/sign-in of the iCloud account or a restart may be required for the UI to reflect the enforced state. Document that enforcement is authoritative even if the UI lags.
3. What should you check about the FileVault escrow 'Pending' state?
Read the worked answer
'Pending' typically means the MDM issued the FileVault enable/escrow command but the key hasn't been returned. Check:
- Whether the device is online and has checked in since the profile was pushed (offline laptops won't respond).
- Whether the FileVault payload uses an institutional key vs. personal recovery key; escrow behavior differs.
- Whether a prior FileVault state (already encrypted with a personal key) prevents re-escrow without a rotate.
- Command queue: look for the specific FileVault command status and errors.
Remediation: ensure devices check in, re-issue the escrow command, and for already-encrypted devices use a key rotation to force escrow. Verify in MDM inventory that the recovery key is present, not just that the profile installed.