macOS check-in failed after Migration Assistant transfer from another enrolled MacSolved

Hello @skylar-a ,

Yes, this can happen if a Mac is enrolled first and then data is migrated from another Mac that was also enrolled in MDM.

In this scenario, Migration Assistant may bring over local Hexnode UEM agent state from the previous Mac, such as files under the Hexnode application support directory, cached database files, or stored agent credentials. These files are tied to the old device enrollment and hardware context. When they exist on the new Mac, the agent may appear to sync successfully locally while the portal does not receive a valid check-in.

Common signs include:

• Last checked-in does not update in the Hexnode UEM console.
• Scan Device remains In Progress.
• The local Hexnode UEM app shows “Synced Successfully,” but inventory/compliance does not refresh.
• Logs show multiple device identifiers or old log history from another Mac.
• Credential or key decoding errors after migration.

For a device enrolled through Apple Business/Automated Device Enrollment, try the remediation on one affected Mac first:

1. Confirm the Mac is assigned in Apple Business.
2. In Hexnode UEM, go to Admin > Apple Business/School Manager > Automated Device Enrollment and confirm the Mac appears there.
3. Select the device and run Sync with ADE.
4. On the Mac, run: sudo profiles renew -type enrollment

This renews the macOS MDM enrollment link through Apple’s native MDM client. It does not erase personal files, apps, or user data.

If the local Hexnode agent state is corrupted due to migration, clearing stale Hexnode agent configuration and allowing the agent to reinstall/refresh may also be required. Avoid manually deleting MDM-related files unless you have a tested procedure, because removing the wrong files can affect management state.

Oh now I got it. The device itself was usable, but Hexnode showed it as stale/non-compliant. Restarting, switching networks, and manually syncing from the agent didn’t change anything.

The logs had entries from both the old Mac and the new Mac in the same local Hexnode log location. There was also a SQLITE_NOTADB error shortly after the migration. So it really looked like the migration copied old agent data over.

One more thing to watch for is FileVault reporting. If the Mac cannot complete a clean check-in, the console may show contradictory security or compliance data. For example, FileVault may be enabled locally when checked with “fdesetup status” but the Hexnode UEM console may still show stale or conflicting FileVault information.

Once the ADE sync and enrollment renewal complete successfully and the device checks in again, Hexnode UEM should refresh inventory, compliance, and FileVault status. If FileVault is enabled locally and the relevant policy is still associated with the device, the compliance status should align after the next successful scan/check-in.

Regards,
Simon Scott
Hexnode UEM