Not a Jamf Pro issue, but Jamf Pro does hightlight it. Four years ago when we got our first Silicon Macs, we occasionally found the odd machine which we couldn't log on with our admin account. Password wobble. We never found our the reason and just went into Startup Options, wiped the Volume Group and re-enrolled. We now have more Macs, almost all Silicons now, so we see the problem more.
In order to ensure that our first admin account has Secure Token, we create it through Jamf Policy. We've found that on Macs where we've flattened it with Erase All Content, or even Disk Utility in Startup Options (yes we definitely delete the Volume Group, not just Macintosh HD), we get the odd case where the Policy failed because "a folder with that name exists".
So Erase All Content, and even Disk Utility says it has erased the Data Partition, but somehow it hasn't. Not knowing as much about Macs as I do about PCs, I'm guessing that the partition table is held in NVRAM, and is resurfacing after a "wipe", so the old admin user folder still exists, preventing the user from being created again. The big problem is that macOS assigns the Secure Token to the account, but because we can't log onto it, we can't enable Bootstrap.
We have even seen cases where a second or third Erase still shows the same issue, and have actually found that Jamf's "Wipe Computer" button is the only thing that 100% erases the drive.
Doesn't happen on a new Mac, but only on one where a previous installation had taken place. Luckily we have found a clunky way round it - we use a Jamf policy to create a second admin account. That account can then be used to change the password of the first account (weirdly it accepts the old and new passwords as identical). This allows us then to log on with it and enable Bootstrap.
I realise this isn't a Jamf issue, but has anyone else seen behaviour like this?
Luckily we do have a
