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.
@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.
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
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.
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
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...
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. :/
@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
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.
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 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.
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.
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.
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...
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.
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.