We have a few MacBooks where Hexnode shows an old last check-in time even though the devices are powered on and connected to Wi-Fi. One password reset action is stuck in Pending because the Mac has not checked in for a few hours. Another Mac is actively used but shows a last check-in from months ago.
FileVault is enabled on these Macs. In one case, the user forgot the password and restarted the device. We need to avoid wiping the Mac, but we also noticed that the FileVault recovery key is not available in Hexnode.
When a Mac with FileVault enabled is restarted and remains at the FileVault pre-boot authentication screen, macOS has not fully loaded the user session. In that state, the device may not be able to complete MDM communication with Hexnode, even if it is powered on and connected to a known network. This can cause the last check-in time to appear outdated and remote actions, such as password reset, to remain pending.
For recovery, the key point is whether the FileVault Personal Recovery Key was escrowed to Hexnode before the user was locked out.
Check the FileVault policy applied to the Macs:
Go to Policies and open the FileVault policy applied to the devices.
Click Manage > Modify.
Enable Escrow Personal Recovery Key.
Save the policy.
This ensures that Hexnode is configured to store the Personal Recovery Key for devices that enable FileVault after receiving the updated policy.
However, enabling this option does not automatically retrieve keys from Macs that are already encrypted with FileVault. For existing encrypted Macs, the Personal Recovery Key must be rotated on the device. Run the following command on each Mac:
1
sudo fdesetup changerecovery-personal
After the key is rotated, perform a Scan Device action from Hexnode so the new recovery key can be uploaded and escrowed in the portal.
If the Mac is already locked at the FileVault login screen and no recovery key was previously escrowed or saved elsewhere, Hexnode cannot retrieve the old key from the encrypted system at that point.
That explains the pending password reset. We were assuming the Mac would still check in as long as it had Wi-Fi, but it sounds like FileVault pre-boot is the blocker after restart.
If I enable Escrow Personal Recovery Key in the policy now, will it disturb the Macs that are already encrypted? We have a large number of MacBooks and don’t want to trigger unexpected prompts for everyone.
Enabling Escrow Personal Recovery Key in the FileVault policy should not disrupt Macs that are already encrypted. It configures Hexnode to escrow recovery keys going forward.
The impact depends on the current FileVault state of each device:
– Already encrypted Macs: The existing key will not be escrowed automatically. Rotate the key using sudo fdesetup changerecovery -personal, then run Scan Device in Hexnode.
– Unencrypted Macs: If the policy enforces FileVault, users may be prompted to enable FileVault after restart or login, depending on the policy configuration. Once FileVault is enabled through the policy, the recovery key can be escrowed.
If you want to enforce FileVault enablement for users, verify the FileVault policy option that controls whether users can skip FileVault enablement at login. Setting the skip option to 0 prevents users from bypassing the prompt. This is separate from escrowing keys for Macs that are already encrypted.
What's new 
70 Views
