Here's where I am do avoid having to nuke

If I can get back/reboot:
Return to Language screen
Terminal as root with ctrl opt cmd + t
sudo profiles renew -type enrollment
sudo rm /var/db/.AppleSetupDone

~~~~

If forced to proceed through setup:
complete setup and verify date & time
sudo profiles remove -forced -all
sudo profiles renew -type enrollment
(follow prompts to enroll from desktop)

we have been having huge issues with this lately - running profiles renew -type enrollment doesn't always pull down the activation record. Interestingly running profiles show -type enrollment on a machine exhibiting this issue gives the response

Error fetching Device Enrollment configuration: (34006) Error Domain=MCCloudConfigurationErrorDomain Code 34006 "The cloud configuration server is unavailable."

It also seems to come in waves - speaking to $fruitco to see if there is some rate limiting happening as it occurs during peak deployment loads. Also looking to see if it is something on our internal network

My jamf is on-prem.10.17.1
I am using ethernet adapters. Yesterday after posting my last response, I pulled 5 brand new from boxes. Connected to power and ethernet and started each one. let them all sit on the language screen for 10 minutes. The first one connected perfectly to DEP and got the prestage. The other four skipped. NONE of them asked to connect to wifi which implies to me they have a connection, and when I look, their ethernet connection has DNS and search auto-filled. I was eventually able to get them all to go without restoring, but some required multiple repeats of steps I posted most recently. Any that made it to the desktop (skipped DEP) had correct date and time.
Directions and workarounds get pretty complicated if it requires multiple retries and lots of "If this... do this" . My original plan had been to send out the cartons to each school, since we paid Apple to asset tag and our inventory has been preloaded. This somewhat shoots that plan. My other fear of course is that by not paying attention some might get out into the wild without DEP :(

our issues have all been with JamfCloud. I don't really think there is an issue with Jamf as the devices don't actually contact the MDM until after they click the "Continue" button on the remote management screen (it's all to Apple at this critical stage). We also realised that the devices were in fact getting a network connection (despite sometimes showing that the ethernet adaptor wasn't connected) as there was no "connect to Wi-Fi" prompt and they had successfully gotten the .cloudConfigActivationRecord from Apple, and have .cloudConfigRecordNotFound instead of .cloudConfigRecordFound - still troubleshooting but it's challenging now that all of the devices have gone out to the end user

@Sandy glad your making progress, at least a terminal command is faster then a erase and install.

Do you have to set date and time when you get to desktop? Or does it work even without setting date and time?

Does setting date & time in Apple Setup Assitence make a diffrence?
ntpdate -u time.apple.com

Also, have you tried checking to see if there is already a profile there?
profiles show

Hi!
profiles show reveals none installed
ntpdate -u time.apple.com. command not found
date reveals time is correct for PST (we are CST)

Can you set the date manually using date in the [mm][dd]HH]MM[yy] format?

date 0205112020

Would be today at 11:20am.

For those of you wondering how to sync your clocks in Mojave and Catalina, take a look at this article in short, use the sntp -sS time.apple.com command, but make sure you read the article first.

Couple quick question for everyone experiencing this, did you ever see anything like this when Macs were shipping with Mojave or earlier? And can you confirm through the Terminal that the Macs have full network connectivity (ie, they could load google.com or apple.com) I had this happen to half a batch of iMacs back in December, all running Catalina.

On those aforementioned iMacs, the ones that refused to pickup their DEP prestages also refused to talk to any network resource outside of our intranet. Before anyone starts asking me the obvious about firewalls and ports and all that nonsense, this batch of iMacs were all on the same network context. Same subnet. Same switch. If it was something with my network, A, none of them would work, and B, they wouldn't start working the moment Setup Assistant ended. Swapping cables didn't work. My JSS isn't behind a firewall. Basically everything MDM is over 443 these days anyways. The network infrastructure was not the problem. The networking stack ON the Mac seemed to be the problem. Reverse DNS failed for everything on the Internet at large. I couldn't ping or resolve anything outside our Class B blocks. All had valid IPs assigned via DHCP. None were MAC filtered. The moment, however, they completed Setup Assistant, network access to the outside world worked fine (nothing else having changed with the network config, either hardware or backend), profiles renew -type enrollment worked fine and picked up the DEP enrollment immediately and without error.

There is something specifically, and transiently, in the Setup Assistant environment that was causing them to fail to contact *.apple.com. At least that's what my observations lead me to believe. Whatever gets gummed up gets cleared when you wipe the machine or exit Setup Assistant.

As others have stated, this kind of inconsistency makes selling zero-touch a bit hard. Nuking and paving is not a realistic solution when you can't centrally deploy the installer and automate it like we could in the NetInstall days, and calling up remote employees asking them why their Macs haven't shown up in Jamf yet isn't great UX or security either.

I've had more success with DEP enrollment when the Macs are pulled out of their boxes and setup as soon as possible after purchasing. The longer a Mac sits in the box on a shelf, the greater the chance of failure. I don't understand it myself, but the only repeatable solution for an affected Mac I found was to completely wipe the drive (not the volume) and reinstall the OS. I have verified the clocks on the Macs are in sync with available time servers, but it doesn't seem to matter.

We have that issue as well too. Usually just a machine here or there... Depending on your work flow and what you have scoped to install at enrollment. You may want to just continue through the Setup as if it were User Initiated Enrollment. Then run sudo profiles renew-type enrollment from terminal. If the device is DEP and has some how gotten to the desktop, this will pull down the profiles and enroll the devices as if it were DEP.

We have not had an OSX purchase in 4 years, except a few 5 packs. All my new macs have at least 75% battery charge out of the box We've had them stored about 1 month. I am doing 5 at a time, connecting to AC and ethernet. During setup assistant they skip over the Network page, they hang at connecting to activation server (prior to any jamf involvement).
Failure rate out of the boxes is anywhere from 1 to 3 in every 5, random order (Usually the first one works, but sometimes it fails). I am now getting them ALL to go without wiping or having to go to desktop, by going back to the Language screen (sometimes this requires a restart but not always) opening Terminal (command option control T) : sudo profiles renew -type enrollment. letting it sit for a couple minutes and that almost ALWAYS works. ALL my devices are on PST and pick up our zone with location services.

Same issue for us with catalina, first time running in to this as we usually only deploy batches of macbooks for our new students during summer.

First of, "profiles renew -type enrollment -verbose" returns error 34006 as mentioned before, seems to be related to this great article here "https://nstrauss.github.io/mitigating-mac-enrollment-failures/"

If you don't get the language chooser during setup (ie terminal launches as _mbtsetupuser~~) you can boot to recovery launch terminal and cd into the volume and on to /var/db/ and run "touch .RunLanguageChooserToo"
this way next boot you will get back to the initial language chooser which gives you Root access when terminal is launched.

on to the mitigation, seems to be almost random when the profiles renew will work, sometimes i just leave the computers off for a few minutes and try again, sometimes complete reimage.

This is a annoying issue apple should fix, I recall somewhere reading about this beeing acknowledged by apple enterprise support as an actual bug in Catalina and should be fixed in the next OS verison, in my mind this should be a Major bug and should be hotfixed, but apple does not seem to care about enterprise customers ..

@temilit I just ran into this with our MacBook Airs we received. Apparently, there is something wrong with Catalina 10.15.5? This affects the T2 Macs and once the computer has been updated to version 10.15.6, the problems seem to vanish. I have yet to understand what it is, but with Apple helping me yesterday, I was able to get this resolved.

This also means updating to 10.15.6. Whether you boot to an internet recovery drive and do or use some other mechanism, the bottom line is once you have them updated, you should be good.

@mconners I have already deployed my batch of about 100 devices but I did notice now when looking they were all at delivered with OS 10.15.3, I will have a go at trying the latests patched version as i get the chance.

Thanks for the information

If you keep doing the ctr-opt-cmd T and getting the mbsetupuser account, then root might not be enabled.  https://derflounder.wordpress.com/2019/10/11/enabling-root-on-a-mac-which-hasnt-gone-through-macos-catalinas-setup-assistant/

Any more reality around stale machine with the higher fail rate?

We just had this start happening to our batch of Macbook M1's that were purchased in June 2021. Same scenario, the DEP enrollment has been working great. Now we have opened a few right out of the box and the devices don't know they are supposed to be managed. I know how to fix already by wiping, but the real issue is that this happens at all! It makes the process completely unreliable if we want to ship directly to users and have them self enroll.

Is there a technical reason or bug that has been identified as to why this happens? I feel like we find something new that just doesn't work correctly with Jamf on a weekly basis, which is frustrating. Or maybe this is just an Apple problem? Rolling Macs out within a large company with very high expectations has been a serious challenge as an IT admin.

I haven't found a good reason why sometimes this happens, luckily if it's scoped properly in Apple School/Business manager, after going through the setup assistant you can go to terminal and just run the following command:

Though this isn't ideal when it's being shipped to a user in a sealed box, but if IT touches it first, this is a good workaround to note having to wipe the device.

I also haven't found a good solution other than the above command or wiping it.

I want to share a new possible detail we have discovered. Our bulk purchase of M1 Macbook Pro's happened on July 21, 2021. Up until October 21, 2021 every single one we opened, the DEP enrollment worked perfectly. The last successful one was on October 20, 2021. Now each one we open, the remote management step gets skipped during the startup.

This has us very suspicious that there is some kind of "timeout" after the devices get added to DEP to the time when they make their first network connection. I find it too coincidental that exactly 3 months after we got our devices, now all of a sudden each one fails.

I'd like to know if anyone else is seeing this behavior and can pinpoint the timeline like we can.