Time Machine and MDMs don't mix very well. I would highly discourage using restoring from a Time Machine backup to an MDM enrolled computer. At the very least, do not restore the Library folder, only Document folders, which kind of defeats the purpose of making it so developers from having to set up their environment again.
Do you have to wipe the computer? Why not just unenroll from AirWatch, upgrade the computer to Monterey, and then re-enroll in to Jamf? If you want to ADE enroll, assign the serial numbers to a Prestage in Jamf and run the command sudo profiles renew -type=enrollment to force an ADE enrollment without having to wipe the computer. That way the user keeps his profile and data intact.
I would look to verify the keychain and also reset and create a new one. This removes traces of the old password from the Time Machine backup, and you can start fresh. Ensure your setting are correct with Okta, we use Azure, and then try to sync with the newly created local password.
Time Machine and MDMs don't mix very well. I would highly discourage using restoring from a Time Machine backup to an MDM enrolled computer. At the very least, do not restore the Library folder, only Document folders, which kind of defeats the purpose of making it so developers from having to set up their environment again.
Do you have to wipe the computer? Why not just unenroll from AirWatch, upgrade the computer to Monterey, and then re-enroll in to Jamf? If you want to ADE enroll, assign the serial numbers to a Prestage in Jamf and run the command sudo profiles renew -type=enrollment to force an ADE enrollment without having to wipe the computer. That way the user keeps his profile and data intact.
We wipe the computer so that it enrolls via DEP. We gain more functionality using DEP enrollment vs User Initiated.
I would look to verify the keychain and also reset and create a new one. This removes traces of the old password from the Time Machine backup, and you can start fresh. Ensure your setting are correct with Okta, we use Azure, and then try to sync with the newly created local password.
I'm leaning more towards the keychain as well. Going to circle back to troubleshooting that and see if creating a new one will remove any traces of the old Time Machine Backup.
We wipe the computer so that it enrolls via DEP. We gain more functionality using DEP enrollment vs User Initiated.
That is what the profiles command does as well. It will attempt to enroll the computer via DEP outside of setup. I would give this a shot, it might be a better solution than wiping and setting up the computers again.
That is what the profiles command does as well. It will attempt to enroll the computer via DEP outside of setup. I would give this a shot, it might be a better solution than wiping and setting up the computers again.
Good idea. I'll keep this in mind as another possibility and give it a shot on my next migration.
Closing this loop. I found the issue is that the machine was still bound to the domain when the time machine backup was initially taken. I tested my migration process on another device and found the device still bound to the network. I unbound the device, did a TMB and restored it after enrolling into JAMF. User was then able to change password and sync successfully with new one.
That is what the profiles command does as well. It will attempt to enroll the computer via DEP outside of setup. I would give this a shot, it might be a better solution than wiping and setting up the computers again.
Thanks for the insight Tribruin! Tested and confirmed removing the users from old MDM, unbind the device then do a sudo profiles renew -type=enrollment worked like a charm. This will cut our migration by at least half the time now since I can now do it remotely and no longer requiring taking a time machine backup and wiping the disk. If I ever see you at JNUC I owe you a beer! Thanks again.
