DEP/PreStage Issue - Macs not picking up PreStage

smithjw
New Contributor III

Hey, not sure if this is a particular DEP issue or more so to do with macOS but I'm wondering if you've seen the following.

I'm starting to get a lot of new Macs shipping and while they are added to a particular PreStage, they do not immediately pick up that it's required. The issue goes like so:

  • New employee opens sealed laptop
  • Starts running through Setup Assistant and is prompted to connect to wifi
  • Mac connects and the next screen is the Migration Assistant screen NOT DEP page informing employee that the Mac is to be managed.

If the employee continues, they can successfully setup their Mac without the DEP PreStage being completed or being enrolled in JAMF.

In order for the User to be presented with the DEP Setup Assistant page they must do the following:

  • Start Mac and proceed through Setup Assistant
  • Connect to wifi and click Continue
  • On Migration Assistant page click Back button
  • Connect to wifi again (can be same or different network), then click continue
  • Now they see DEP SA page and are prompted for authentication.
  • Following this, they see all SA steps associated with the assigned PreStage and the Mac is successfully enrolled in JAMF.

I Have tested this on 6 brand new 2016 Macs plus several 2013-2015 macs that have been wiped back to factory with 10.12.2. All exhibit the same issues.

As you can imagine, this isn't great for UI as I need to communicate to make sure to click back then connect to wifi again, or be present for all enrolments.

Any ideas?

109 REPLIES 109

Sandy
Valued Contributor II

@sdagley, you've lost me there. MyTomcat servers are using a third party cert expiring 12/11/20 (network solutions)
My self signed CA Cert expiration is 3/23/23

Also getting this error if I try recon to enroll:
"error retrieving last session due to absence of an active session"
My hidden ssh account exists on the device, either created by Prestage or by enrolling from URL

I can get the computer into DEP, but without jamf (device record is created in jamf but no inventory is taken, no name, no other details). If I enroll in jamf using: https://myjss /enroll profiles download and install, and it changes enrollment in the device record to: "user Initiated no invitation" and removes the DEP profiles.

Either way I get no Binary and no Self Service

sdagley
Esteemed Contributor II

@Sandy It's not that your cert has expired, but it could be one of the Root CAs in the trust chain for it has. This can result in the Mac's attempt to download the jamf binary, and all that comes along with it, from your JSS failing.

lamador
New Contributor III

if anyone is still having issues the following helped me out still sucks that apple has not fixed this:

  • https://github.com/micromdm/micromdm/wiki/Troubleshooting-MDM
  • https://www.jamf.com/resources/videos/under-the-hood-device-enrollment/
  • https://cultureamp.wistia.com/medias/gaiq4f540s

aalquillera
New Contributor

@sdagley has Apple Support ended up helping you with this issue? Do they know the root cause of the issue or a solution besides wiping the drive?

sdagley
Esteemed Contributor II

@aalquillera The recommendation from Apple Support is to make sure a Mac is fully charged, and the battery has had time to cool down, before attempting to run Setup Assistant. The details why are pretty arcane, but the goal is to avoid triggering an error condition where the Mac won't connect to the Apple server that initiates the MDM enrollment process. You'd have to bug your Apple SE for the specific details.

dniven
New Contributor III

Hi Folks, this issue was hard to diagnose as we didn't see anything in the logs on either the JSS side or the client side pointing to the problem.

The issue is the root CA cert, which in our case was from InCommon.

What we did to fix it was 1) generate fresh SSL certs, then 2) create the Tomcat P12 cert, 3) move the certs into the correct location on our JSS, and 4) stop and restart Tomcat.

You can test to see if your server has this problem by using the following command:

openssl s_client -connect yourjss.example.com -port 8443

Run the above command from a Mac or Linux machine (don't know how to do this in Windoze).

In the Certificate chain section, if you see the words "AddTrust" then you have this problem and need to fix it.

For example, you'll see "AddTrust: in the last three lines here:

Certificate chain
 0 s:C = US, postalCode = 12345, ST = California, L = San Francisco, street = 124 Main Street, street = Boss Office, O = "University of SF", OU = CRM, CN = myjss.example.com
   i:C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
 1 s:C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
 3 s:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root

rhyde
New Contributor II

6f6dab6b0a564c69a516d542fcff2327

New fresh out of the box 2020 Macbook Pro 13in not receiving assigned pre-stage. Interesting error, also on ethernet. Yes it can be fixed with a wipe/reinstall just seems kinda lame for a new employee to have to do :/. I am wondering if there are any kind of tricks that can be done when using terminal.

ageevarughese
New Contributor II

I'm running into this issue as well with any 13" mac laptops that are prestaged in my environment. @dniven I've tried using the command you suggested, but receive the following error in terminal, "no port defined; usuage: s_client args". Any suggestions?

marktaylor
Contributor

We have also had this issue for ages and 100% of the time with all the new MacBook Airs lately, after extensive testing we have two choices to get it working again:

Wipe the Mac and re-install macOS Catalina then it will successfully enroll

or

If the remote management prompt doesn't pop up, boot into recovery mode
Open Terminal enter “touch /Volumes/Macintosh HD/var/db/.RunLanguageChooserToo” and then reboot. (This changes the setup user to root from mbsetuser)
Once the language preference comes up, press Command+Control+Option+T to open Terminal as root user.
Type “ls /var/db/ConfigurationProfiles/Settings” and see if it lists “.cloudConfigRecordFound” and “.cloudConfigHasActivationRecord” if it does then the computer has received the enrollment trigger. In Terminal type “date” to check that it has the correct date/ time recorded
Still in Terminal type “sudo profiles renew -type enrollment” to reset the enrolment status, then reboot

Works 100% so far...

kwoodard
Contributor III

So much for no-touch enrollments. I'm getting a new error now when trying to add serial numbers to our DEP with Apple. Every single serial number errors out now. I’m receiving “INVALID_INPUT” when I assign devices to an MDM server. All the computers and iOS devices we buy (with rare exception) we get directly from Apple. You would think they would already be in DEP. :/

dniven
New Contributor III

@ageevarughese I'd open a ticket with JAMF about this. But mention you suspect an issue with the root CA certificate in your JSS and need to verify that's not the case. The error you're seeing with the command I suggested is maybe because you're not using port 8443 on your JSS, but this is just a guess

merps
Contributor III

@kwoodard Buying directly from Apple is likely the cause here. IIRC only authorized resellers can register devices with your ABM/ASM instance.

brookstravis
New Contributor III

If you are purchasing under an institutional purchasing account with Apple that is not the case. You can associate that account with your ASM/ABM. In fact, it's better from this perspective because it doesn't rely on your reseller's POS system integration functioning properly.

kwoodard
Contributor III

@merps I have not had this issue until very recently. Nothing we buy through Apple now can be added to DEP without getting that error and I have to call.

jameson
Contributor II

Is it possible to find any logs on the machine while doing first time setup where pre-stage is not loaded ? - Or how to call terminal window?

Malcolm
Contributor II

It's been a while since I wrote this thread, a lot has changed in DEP, we don't see this problem any more, with newer versions of catalina, in the initial setup window of mac os you can call terminal.

This one was just shown to me during a migration training to jamf cloud...
control option command + T @jameson
fromt here you can run create a snapshot prior to progressing to the DEP expected prompt: by running: tmutil snapshot
the snapshot can be apparently recalled using disk utility in recovery, but flushing the pram or using filevault kills the snapshot.

As far as DEP enrolment goes these days, our vendor adds our serials and we automate their enrolment to a pre-stage, providing our vendor does their job properly, our success rate is now about 95%, the majority of hang ups experienced of late have been where DEP enrolment fails, pushing through to the user a standard setup. I believe this has been due to Apple's backend.

We don't allow local account creation, aside from our mdm management account, and everything else is configured when they login using their AD user.

I am now experimenting with having a custom VPN config file during the enrolment, period, that reoccurring script connects vpn, to ensure its always on VPN, to allow the bind process and allow the user to authenticate, and thus once another smart group confirms that has taken place, the VPN config file and policies will cease to run.

to my surprise this is working pretty well in our testing phase, a few caveats to work through, mostly with device naming, but I may also be at a point to push self setup to all our users in the up coming months.

reliability of our internet connection, and servers had also been factors in the past, but upgrades to firewall, UPS and moving our MDM to cloud, combined with the introduction of COVID, has given us more reassurance to begin doing zero touch.

kuyker
New Contributor II

I tell you, this would be funny if it weren't still an issue 4 years later. The last three Macbook Pros we purchased failed to pick up prestage.

kwoodard
Contributor III

I have found (lately) that if the Mac's out of the box have a charge level under 25%, DEP/Prestage will fail. If I plug them in to charge for an hour, then turn them on, they do a lot better. I still will get one that fails every now and again, but not wide swaths of them like before.

arepko
New Contributor III

I also had the same issues with this years MacBook Air lineup... Had to re-install most of them numerous times to get them to DEP/Prestage... After numerous calls with Apple, I spoke with an engineer who did in fact say if the battery charge is not sufficient, they will fail. I started plugging them in for an hour or so BEFORE opening the case. Seems to have done the trick for the most part.

kuyker
New Contributor II

@kwoodard As soon as I get them, I plug them in overnight before opening them up or turning them on. For whatever reason the "Zero Touch Deployment" just does not work reliably for us.

typeraj
New Contributor III

For anyone interested, @nstrauss did a fantastic writeup on the exact cause and his workaround for this issue: https://nwstrauss.com/posts/2020-08-11-mitigating-mac-enrollment-failures/

kwoodard
Contributor III

Seems like Apple should say thank you, cut him a check, and add this into the next OS update for all versions of the OS still supported...then make sure that its included on all new Mac's sold.

smithjw
New Contributor III

I never though this thread would still be active almost 5 years later...

sdagley
Esteemed Contributor II

@smithjw It probably shouldn't have been resurrected as all of the recent tread traffic, and what @nstrauss wrote about, was specific to an error Apple introduced in macOS Catalina. Whatever initially spawned this thread, it wasn't the same issue.

Scott_Conway
New Contributor III

November 2021, and we are having this issue on a stock of M1 Macbook Pro's that were purchased in July...

Has anyone considered also that there is some type of timeout on Apple's side that a device that has sit unopened too long fails to be identified on the first boot network connection? It could be purely coincidental, but our stock of macbooks were purchased and added to our ABM profile on July 21, 2021. Jamf enrollment has been working for us perfectly...until October 21, 2021. Our last successful "no issue" enrollment was October 20.

Since then, the few that we have opened fresh out of the box have had the failure, and we have had to wipe them to get the DEP enrollment started. I'm not saying the above reasons are also not true, but I can't help but think it also has to do with the devices not being online for exactly 3 months...

kmathern
New Contributor III

@Scott_Conway   I have had my deployment team charge the macs that have been sitting on the shelf for a long time before they enroll them and I don't seem to have that issue anymore.

I have seen this as well. If the Mac is under 25% charge, I have a very high rate of them not being picked up by the pre-stage. If they are higher than that, I have had one or two out of 50.

Malcolm
Contributor II

currently doing a batch of 80+ devices through DEP, all m1 with big sure so far, the experience has been much better regards to DEP. I believe the issue is specifically occurring at the ASM, check process, as i understand it, we aren't all sharing the one server, so the experience from country to country will ultimately be different. having a strong internet and wifi connection to the devices, I think is a key factor, limiting to no more than 12 to one WAP would be advised especially if a-lot of packages are being pulled down. But I believe the performance of ASM, and its activation check after the devices connects to wifi, has been modified of late, as some do take longer to process the check for ASM DEP activation status.

 

I suppose battery could impact this also, as power management could impact the functionality of the hardware connectivity etc. e.g. the haptic feedback of the trackpad is not available when battery is low.

Scott_Conway
New Contributor III

I would agree about the strong network connections or battery life, however in our situation, the DEP enrollments works after it initially fails, and then you wipe the machine (using the same network as before).

This leads me to believe there is some kind of issue on Apple's activation network.

 

I would agree also, and possibly a regional issue also.

I can say it's improved in Australia over the past year.