While I don't have any suggestions on the "Activate Mac" issue, I have seen the behavior you describe during enrollments. There is a PI for this (PI111120), and the workaround is to un-check at least one of the PreStage "Setup Assistant" checkboxes. If you check them all there is a high likelihood you will run into account creation failures.

Interesting. I did recently make a few changes to which items are checked in that list. I'll uncheck one or two of the innocuous ones and see if that helps. Thanks so much for your suggestion!

PreStage huh? I just saw the behavior Dan described last night. I haven't changed anything with PreStage since last summer... c'est la vie.

That or creating a management account with the same username as the admin account being created as part of the PreStage config. That one is PI111014.

I feel like Ventura has become more difficult to manage than any previous versions of macOS.

Honestly, I would start with the network. Especially with that activation server error, if network traffic is interrupted during enrollment the process basically stops leaving the device in a semi-setup state. 

You can check JAMF Logs for what is going on when that device is enrolling. However, if it is network related you will see the logs just stop. If you can enable Root, you can get in to macOS and check the MDM logs to see what may be going on.

Thanks for the tip. I did at first blame the network, but this has been happening from multiple locations.

Two questions:

• Is your JAMF Pro on premises or Cloud hosted?
• Are the multiple locations in your corporate network (including random VPN's), or at peoples houses?

I can confirm that we have had this issue and I've resolved by the following:

• Ensuring that if you are creating an admin account before Setup Assistant in your pre-stage enrolment, that this account is different to what is specified in User Initiated Enrolment. Having them the same caused our machines to reboot straight after applying the MDM profile without going through the setup assistant.
• If you are using an LDAP or SSO customisation, and you are using this to pre-fill primary account information in your pre-stage, make sure your test account isn't listed as a Jamf user in Settings -> System -> User accounts and groups. Testing with an account that is listed here won't pass through pre-fill information, not sure why as it always used to work.
• Again with pre-stage enrolment, if you are using the Automatically advance through Setup Assistant option then you need to have a few options displaying otherwise it won't create the user properly (at least in my testing and what I've seen online). I have Location Services, Transfer Information, and Accessibility enabled in mine. I was getting an error that user account creation failed, but then it wouldn't allow me to use the same username as it said it already existed.

Our Jamf instance is cloud hosted.

I received reports of this happening in multiple locations (both on and off the internal network).

@luke_sthildas you shouldn't be using the "Create management account" option in Settings > Global > User-initiated enrollment. It's not longer needed and will be removed by Jamf in the future.

Jamf has randomized the password and made it part of the LAPS solution. I don't see them removing the account. It is not used for what it once was, but still has a purpose.

With Sonoma, having the management account and the local account within Pre-stage is the only way that I can do zero touch deployment and have a user create their own account. https://community.jamf.com/t5/jamf-pro/enrollment-with-macos-14-x-sonoma-skips-creating-local-user/m-p/302021#M265435