I've had that happen a couple times. Usually, I got in and refresh the DEP token from ASM. This normally fixes the problem.

Every once in a while I encounter this issue if for some reason the ethernet adapter isn't communicating with the Mac properly at startup. I use the Anker USB-C to ethernet adapter, and I can see all the link lights working, but the Mac still doesn't communicate that it's in DEP.

A quick reboot or a PRAM reset has resolved the issue for me in the past. On one occasion I had to open a Terminal prompt in Setup Assistant and run this:

rm -f /var/db/Configuration Profiles/Settings/.cloudConfigNoActivationRecord

I do the same as @jcline

works for me too

So far I did zap the PRAM on one of the Macs in question and it worked. Some of these Macs have sat in the box a few months and the batteries may not be as fresh as they were right out of the factory. I'll try zapping the others to see what they do. thanks for the input, everyone.

Zapping the PRAM worked for one computer but not the other two. I figured I'd try refreshing my DEP token to see if that worked. Nope. The computers are still completely oblivious to DEP. There is no/var/db/Configuration Profiles/ directory on this Mac so there's nothing for me to delete yet. I took the Mac off our network and tried it on my home network (just because our network security can be a little too aggressive at times), but even on my home network it still does not recognize that it belongs in our DEP.
I thought DEP was supposed to be a magical service that made imaging completely a thing of the past. I could see that happening if it actually worked all the time. <extreme frustration>

A shot in the dark, but the file path sshort referenced needs the space escaped, or when you type it in Terminal you have to wrap it in quotation marks.

So you'd type

rm -f /var/db/Configuration Profiles/Settings/.cloudConfigNoActivationRecord

or

rm -f "/var/db/Configuration Profiles/Settings/.cloudConfigNoActivationRecord"

@adamcodega thanks for the suggestion, but I looked inside of /var/db/ and there was no subdirectory in there by any name even close to that. I rarely delete a file/folder in a path without verifying it exists in the first place. I looked. It wasn't there.

Not that it solves your problem, but have you booted all the way to the desktop on one of them and tried a

profiles renew -type enrollment

to see if once running they actually check into DEP and get recognized for management? I am seeing this morning and more frequently from DEP workstations, but I chalk it up to our stringent network access control tools. FWIW - sounds like it's time for a ticket with Apple.

correction When I checked the /var/db/ directory, I was looking on the Recovery partition. Stupid me didn't look at /Volumes/Macintosh HD/var/db/ That being said, I looked in the right location a minute ago and there IS a "ConfigurationProfiles" directory (no space). The only thing in there is a .migrated file that's zero bytes. Looked in /var/db/ConfigurationProfiles/Setup/ and there is a .profileSetupDone file. I deleted that to see if that would kick it, but it did not.

@easyedc That brings up a question I've had since jumping into DEP: If - for whatever reason - a mac is booted up all the way to creating a local account etc and not getting enrolled in our MDM, do I have the ability to manually reinstall the OS and try to get DEP to engage it during setup? Or is this very first time "out of the box" experience the one and only chance I have?

@AVmcclint If you get to the desktop and DEP hasn't recognized that it should be managed through a pre-stage, then you can run the above command and it will then go re-check DEP servers and call down any management. The only gotchya (and it's a biggie) is that the profile has to then be manually accepted through a pop-up notification. If the computer has made it into the hands of users, they could, theoretically, decline it.

I've been working on a re-enrollment process for Macs that get deleted out of our JAMF server (if they're inactive for 6+ months, we delete them thinking they've been removed from users hands). I've got some logic in place, but the users ability to decline the MDM is a problem. I submitted a ticket to Apple and was told that there's already a feature request

for a silent re-enrollment method

but as of yet, nothing's come of it. My argument to Apple is that if they're actively assigned to a DEP MDM, then re-enrollments should be able to be performed without any user acceptance.

... Follow-up - macOS 10.12 used to use

sudo /usr/libexec/mdmclient dep nag

but I believe it's all been supplanted by

/usr/bin/profiles

I ended up calling Enterprise support and they confirmed that the DEP assignments looked good on their end. I told them that 20 other Macs using the same network jack, cable, and ethernet dongle all worked fine, but these last 2 refuse to work. They suggested I reinstall the OS. I booted up in Recovery mode and went to Disk Utility and formatted the Macintosh HD volume, reinstalled, and TADA! it worked. it is now sitting on the workbench soaking in MDM goodness. The 2nd one was more stubborn. I was unable to format the volume - it kept hanging - so I ended up blowing out the drive and let it create a new APFS container and all that jazz. It's installing the OS now. I should know in 30 minutes if it worked. EDIT: It worked!

To sum up:
1) zap the PRAM, it could be an issue with getting on the network
2) reinstall the OS, the OS could be bad straight from the factory
3) completely reformat the APFS container, the drive format/partitioning could be bad from the factory

3 is likely what fixed it. You should get into the habit of partitioning to something other than APFS, then back to APFS in disk utility to completely wipe all containers before the OS is installed. I banged my head on the desk for this one as well.

I have had this problem as well; Resetting the PRAM worked on a few machines, but for the other I had to reinstall macOS. We still have one final one that never picked up DEP enrollment after a PRAM reset and a reinstall. I never tried to delete the APFS container so I will keep this in mind if I run into the problem again.

I just wanted to add a new experience I had with this. Yesterday we had 4 DEP Macs (with 10.13.6 on them) pulled out of their boxes and powered on... none of them recognized they were in DEP. So I did the steps outlined above and it worked for 3 of the Macs. The 4th one.... well it kinda sorta worked, but not really. After it was presented with the Remote Management screen with the giant gear acknowledging that the computer will be managed by us, we clicked Continue and it went to the login screen (where our standard practice is to let it sit for 30 minutes while it pulls down config profiles and installs all the post-enrollment profiles.) While it was sitting at the login screen, a message popped up telling us that the MDM profile needed to be approved in System preferences before it could be installed (or whatever it was). When I looked at the computer record in JSS, it said "MDM Capability: Yes" , "Enrolled via DEP: No" , "User Approved MDM: No"

It was very strange. Obviously the computer knows about DEP because it got the Remote Management screen during setup, and it DID enroll. I verified that the PreStage Enrollment was setup properly and this computer was in the scope. I decided to delete the computer record from JSS, wipe the hard drive, and reinstall the OS one more time. This time it worked fully and is properly recognized as DEP Enrolled..

I see where Apple and Jamf are going with this whole "zero touch" thing, but to me it seems that DEP is way too fragile to rely on it to work 100% of the time.

I see where Apple and Jamf are going with this whole "zero touch" thing, but to me it seems that DEP is way too fragile to rely on it to work 100% of the time.

Agreed. While you, as an IT admin were able to eventually resolve these issues, imagine if we were all using the Apple and/or IBM approach of just shipping these Macs to end users and expecting it should auto enroll, and in some cases it just doesn't work? That's a mess on our hands we'd need to track down and clean up later. It is indeed too fragile in my opinion.

That being said, in my own testing, I've had basically 100% success in taking a Mac enrolled into DEP and using the startosinstall command to wipe and reinstall the OS cleanly and have it be recognized and enrolled via DEP into our Jamf instance. So it does seem like a wipe and reinstall is a pretty sure fire way to get it to work.
But that of course falls apart in the above "drop ship to customer" scenario, since you will not have an opportunity to do that. And even if you did, who wants to go through that process for every single Mac? Might as well go back to traditional imaging if you have to go thru that rigmarole to get it to work reliably!

I have 600 new MacBook Airs to deploy and so far in my early testing I am seeing about every other one out of the box skip over DEP. I am not using an enrollment customization configuration.
I m using an ethernet adapter which sure seems like works just fine because without joining any wireless, the ones that don't work are able to boot right up to internet restore. I do not get the network picker on the successes or the failures, which to me would imply they are recognizing the ethernet connection
Once they skip over DEP, as mentioned by others I have to wipe them to get them back to where they will recognize my prestage. Once wiped and reinstalled, changing NOTHING ELSE, they work fine

Since half of them do work, it does not seem to be our network, the Token in jamf, DEP services, my prestage.....
Due to the number of failures my deployment strategy is pretty much out the window

When this has happened to me, it's almost always turned out to be the case that clock was skewed too far to allow communication with Apple's DEP infrastructure. Had to turn off SIP, boot to recovery and set the clock manually.

@Sandy
Did you try
completing applesetup, rm /var/db/.AppleSetupDone and doing it again?

or maybe
sudo rm /var/db/.AppleSetupDone
sudo rm -rf /var/db/ConfigurationProfiles/*
sudo rm /Library/Keychains/apsd.keychain

could also try
completing applesettupe
set network date & time
sudo profiles -N
sudo /usr/libexec/mdmclient dep nag
sudo profiles renew -type enrollment

could try checking the log while doing a NAG or during applesetup
CTL OPTION CMD T
log stream --info --debug --predicate 'subsystem contains "com.apple.ManagedClient.cloudconfigurationd"'
log stream --info --debug --predicate 'processImagePath contains "mdmclient" OR processImagePath contains "storedownloadd"
CTL OPTION CMD T

manully rebuilding KDC isn't supported anymore, but if your going to erase anyway. Might as well try rebuilding it, see if it has any effect before doing an Erase and Install.
rm -fr /var/db/krb5kdc
/usr/libexec/configureLocalKDC

Really just throwing out ideas.

Sorry if this has already been suggested, but this has fixed it for me 100% so far: Go back to the language choose page. summon Terminal as root with ctrl shift cmd + t. type in sudo profiles renew -type enrollment and click return. Then Proceed with through the setup assistant again.

@strayer I tried this (had to control+option+command+t) but Terminal opens as the mbsetupuser user and won't proceed because I don't have a password. Control+Shift+Command+T just beeps.

@tanderson Step 1 is Go back to the language selector screen. I just grabbed a new computer and it loaded for me as root on that screen. (sorry I got the key command wrong) I don't know when it switches over to mbsetupuser.

@strayer Gotcha, thanks! I'll try it again and see how it goes.

@Strayer If I am able to get back to the Language screen, that worked perfectly. Thank you so much!

If I am forced to complete setup and try to get it into DEP manually I ended up with an unmanaged device.
Tomorrow is another day though so will see what happens :)

@Sandy You can remove /var/db/.AppleSetupDone to re-run the setup assistant. http://www.theinstructional.com/guides/how-to-re-run-the-os-x-setup-assistant
or worst case wipe the computer.