My surefire way is using dongles and ethernet. I ordered 50 of them just for these setups. Once you pick "other" for connecting to internet, it takes you to a DHCP screen and then everything kicks off as intended. So far no issues after switching to ethernet.

"EDIT"
Just FYI our DHCP screen when selecting other, shows nothing, but when I click through it, it works as it should"

Gabe Shackney
Princeton Public Schools

@gshackney which ethernet dongles are you using? I don't have the model numbers on hand but we are using the black Belkin USB-C ethernet adapters. Unfortunately we're finding that multiple reboots are needed to obtain a DHCP address on systems straight from the factory.
As others have stated, there are no issues when doing a wipe/reload - it's only when the system is out of the box for the first time.

@merps strange you should say that about the black Belkin’s
We’ve been using the Kanex USB-C to Ethernet adapters for several years without issue but recently had a supply issue getting hold of them so swapped to the black Belkin version and we now are getting strange issues with devices giving the JSS a 172.x.x.x address even though on the device they have the correct DHCP LAN address they should have and failing DEP installs

Iooking in ifconfig it reports back a really strange en number as well (like en28) even though other enternet dongles/dock ports configure themselves with low numbers like en0,en1 etc...
Definitely worth trying different manufacturers dongles to see if it changes anything

We are using the White belkin ethernet adapters sold by Apple. As long as I add them each as a removable MAC address ahead of time, we haven’t had a single issue with the new 2019 MacBook Airs that we just received. Gone through about 20 of them so far. Have another 140 to set up so I’ll let you know if we see anything.

Gabe Shackney
Princeton Public School

@gshackney - could you elaborate on what you mean when you say "As long as I add them each as a removable MAC address ahead of time". Thanks!

@nwsbear There is a section in your settings Under computer management that has a button called removable MAC addresses. This is to keep JAMF from looking at the mac address of that adapter and assigning it to a specific computer. If you don't enter the ethernet adapters as "Removable Mac Addresses" then Jamf Pro assumes you are just re-enrolling the same computer over and over and over again and may cause issues with imaging and DEP.

So you just have to take the mac address of that dongle and add it to removable to keep that from happening.

Also see my edit of my post above, when selecting "Other" during the initial dep setup, the DHCP screen doesn't show any info for our network but when I click continue everything does work properly.

Gabe Shackney
Princeton Public Schools

Having this same issue with 12 MBA's... Not using wifi, but ethernet... None of them are catching any profiles... Have no idea what to try next.

@kwoodard Are you using ethernet to thunderbolt adapters? Have you entered those ethernet to thunderbolt adapters into removable Mac Addresses as mentioned above? If not, then the JSS will just think you are reimaging the same machine over and over.
Gabe Shackney
Princeton Public Schools

@gshackney Yes, I only have one adapter, so it was easy enough to add.

Same here, also have it with Apple TV's, end up going through setup assistant, factory resetting then DEP kicks in?!

Uhhh NOT pleased to hear that defining Removable MAC Addresses is a thing again. We have literally THOUSANDS of thunderbolt/usb-c ethernet adapters globally, and having to enter them into Jamf to get ABM to work reliably is a non-starter. Hey Jamf! I thought we were using UDIDs as the primary identifier of a machine?

@dgreening AFAIK its the serial number as the unique identifier.

Good to know that this is still an issue, nearly three years after the first report. Just ran into this this afternoon with an Early 2015 MacBook Air, fresh out of the box. I'm wiping and reinstalling Mojave, just to see if that solves the issue.

I did discover a strange work around which leads me to think that this issue has something to do with networking. When you boot up the computer for the first time out of the box, you get to a language selection screen. Select a language...THEN hit the back button. It seems that the setup "package" that runs for the first time reloads. I let it sit for about 30 seconds and then go through the initial setup and the pre-stage catches. If you go through it too quickly and not wait, you sometimes will get to the screen that says that the computer will be managed and rather than it having your "org" listed, it will say "null". I let it sit here for a bit and the "null" changed to the name of my "org" and then things worked. I would imagine if your network is slower than mine, that wait time might need to be increased.

Let me know if this works for anyone else. My curiosity is peaked.

@kwoodard Ooooooh - I'm going to try that the next time I run into this issue. Nuking & repaving seem to have done the trick here. Thank you for sharing this; much appreciated.

I've been working more with this issue and I am convinced its a network deal between the new computer and Apple servers/DEP. I was talking with our Jamf tech contact and asked him about this and here is the process a new computer goes through.

1. Initial boot up


2. Network selection


3. Apple DEP servers contacted


4. DEP says "Yes! This is an institutional computer, please go to your MDM (Jamf in our case) for enrollment."


5. Jamf kicks in and we get the screen where it tells the user that the computer is going to be managed. Hazzah!

So, the breakdown is happening between 2 and 3. If Apples DEP validation computers are getting hit hard, there will be a delay in the new computer being introduced to our JSS. So what the Jamf tech told me today is to select your network and wait, or if you are on ethernet, I would imagine waiting on the select keyboard screen for a while, would allow enough time to pass so the DEP server can make the bridge between the new computer and Jamf.

Going to try that in a bit... Will report back.

Three Things,

1. I just saw this PI "PI-007502 In environments with multiple Jamf Pro web app instances using a single Tomcat instance, devices fail to enroll with Jamf Pro using a PreStage enrollment if there is an Enrollment Customization configuration added to the PreStage."




2. Just to clarify my previous post:
   My surefire way is using dongles and ethernet. I ordered 50 of them just for these setups. Once you pick "other" (on the bottom left of the screen and then select ethernet) for connecting to internet, it takes you to a DHCP screen and then everything kicks off as intended. So far no issues after switching to ethernet.
   "EDIT"
   Just FYI our DHCP screen when selecting other, shows nothing, but when I click through it, it works as it should




3. I ran through all my steps and one that I don't bypass is the location settings. I always have to click through the turn on location services (during setup) and then let it find my time zone. I used to see issues with this on mobile devices when the time zone was incorrectly set and how it communicated with Apples servers.

Gabe Shackney
Princeton Public Schools

So nearly another 6 months later and we have a whole new batch of machines to deploy and first one out of the box strikes this problem! Tried most relevant solutions short of wipe and re-install OS, none of which have worked.
Tried a 2nd computer and everything worked as expected. "There is something rotten in the state of Denmark!"
So now am wiping and reinstalling the OS on the first computer.
This is obviously a serious bug with Apple, does anybody know if a ticket has been raised?

EDIT: Can confirm @BlakeRichardson comment that the HD needs to be wiped and the OS installed, not just installed overtop of current system, for this to work.

I have encountered this issue this morning and have been working through most of your solutions thus far, but to no avail. Have finally found out the root cause of the issue for us anyway. The issue ended up being that on the Catalina Setup Assistant it was unable to fully accept the certificate that our organisation has for our Wi-Fi (Even attempting to connect to another network that didn't include the after would fail as it was still trying to resolve the certificate).

In the end we created a hidden SSID that had no certificate attached to it for the devices to connect to, using this method resulted in 100% success rate of the MacBooks getting to the "remote management" screen. As for the devices that we already attempted accepting the certificate for, unfortunately we had to re-wipe those again.

This still an issue. It is 2020.

I'm not convinced this is Jamf specific. I have a case open with AppleCare Enterprise Support for some new in box Macs not hitting the Remote Management screen, and I know my case is linked to others. So far wipe and re-install macOS seems to be the solution for users in the field that have run into this, but I have a test Mac in my hands that failed enrollment today and I'm hoping to do some excavating to see if there's any clue as to where things failed. Since I don't see a partial computer record (i.e. DEP-<SerialNumber>) created from a failed device certificate push like I do when our SSL filters bork the initial APNS connection (you really need to whitelist *.push.apple.com if you're doing SSL inspection as *courier.push.apple.com doesn't cut it with Catalina) I'm pretty sure the Mac never hit my Jamf Pro server. Doing a sudo profiles renew -type enrollment on the Mac does recognize that our Jamf Pro system can manage it, and it leaves a breadcrumb in the PreStage enrollment status for the computer by changing it from Assigned to Completed

To follow up on my last post, the logs show my test Mac failed to connect to Apple's servers for Device Enrollment configuration. This failure pattern is a known one, and it's not Jamf specific. Wiping the Mac and re-installing macOS Catalina resulted in a successful enrollment.

this has been an issue for us as well. Its not a jamf issue. its with apple. all of our iOS devices 100% of the time get the remote management page. macOS. its a hit and miss. Does anyone have a radar link of the stuff you guys submitted with apple? I have having to tell users to go into the terminal and run profiles -renew type or other commands at the language setup assistant.

this has been an issue for us as well. Its not a jamf issue. its with apple. all of our iOS devices 100% of the time get the remote management page. macOS. its a hit and miss. Does anyone have a radar link of the stuff you guys submitted with apple? I have having to tell users to go into the terminal and run profiles -renew type or other commands at the language setup assistant.

this has been an issue for us as well. Its not a jamf issue. its with apple. all of our iOS devices 100% of the time get the remote management page. macOS. its a hit and miss. Does anyone have a radar link of the stuff you guys submitted with apple? I have having to tell users to go into the terminal and run profiles -renew type or other commands at the language setup assistant.