Posted on 12-19-2016 12:47 AM
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:
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:
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?
Posted on 06-01-2020 01:27 PM
@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
Posted on 06-01-2020 01:41 PM
@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.
Posted on 06-05-2020 05:06 PM
if anyone is still having issues the following helped me out still sucks that apple has not fixed this:
Posted on 06-08-2020 05:08 PM
@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?
Posted on 06-08-2020 06:23 PM
@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.
Posted on 06-08-2020 06:31 PM
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
Posted on 07-08-2020 12:51 PM
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.
Posted on 07-08-2020 02:55 PM
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?
Posted on 07-10-2020 02:54 AM
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...
Posted on 07-10-2020 09:13 AM
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. :/
Posted on 07-10-2020 12:24 PM
@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
Posted on 07-23-2020 11:40 AM
@kwoodard Buying directly from Apple is likely the cause here. IIRC only authorized resellers can register devices with your ABM/ASM instance.
Posted on 07-21-2021 10:40 AM
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.
Posted on 07-23-2020 11:42 AM
@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.
Posted on 09-29-2020 06:03 AM
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?
Posted on 10-18-2020 09:16 PM
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.
Posted on 03-02-2021 09:23 AM
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.
Posted on 03-02-2021 09:32 AM
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.
Posted on 03-02-2021 10:04 AM
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.
Posted on 03-02-2021 01:46 PM
@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.
Posted on 03-03-2021 07:26 PM
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/
Posted on 03-04-2021 10:17 AM
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.
Posted on 03-05-2021 04:48 PM
I never though this thread would still be active almost 5 years later...
Posted on 03-07-2021 10:46 AM
Posted on 11-22-2021 09:49 AM
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...
Posted on 11-22-2021 09:54 AM
@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.
Posted on 11-22-2021 11:00 AM
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.
Posted on 11-23-2021 02:48 PM
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.
Posted on 11-29-2021 07:43 AM
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.
Posted on 11-29-2021 01:34 PM
I would agree also, and possibly a regional issue also.
I can say it's improved in Australia over the past year.