Anyone having any trouble getting Macs enrolled into JamfPro via DEP the past couple days?
I've seen 3 computers today that have this issue.
I've re-assigned all three to our MDM server in the DEP / Business Manager portal, and unassigned and assigned in the prestage enrollment settings on our JamfPro server.
The computer starts up and acts like it doesn't even see that a Remote management configuration is available.
We're having this issue now, we had a fully operational system, and then out of the blue machines were missing the enrollment page, either on network (ethernet) or off-network (any non-internal wifi) it made no difference, and the only fix so far has been to wipe and reinstall the OS 1 or more times. This makes zero sense since I am pulling some of these machines brand new out of the box. Has anyone figured out whats going on here?
We have the issue at our site so this looks like a larger issue.
I deleted both our DEP and our PreStage setup and then created everything from our internal wiki. This didn't help fix the problem but help us update our documentation.
I currently have an open case with Jamf who are looking at the server log files.
I was seeing this 2 days ago. I was not able to see a new device in jamf that was added to an MDM server in ASM. I called Apple after I was also not able to refresh my token on any of my MDM servers, which is the usual fix for jogging things into action. Getting same unable to connect message
Their response was that the next step would be to replace the public key, which made me a little more uneasy with 1300 iPads on the associated pre-stage. ( it should be ok... )
I opened a ticket with jamf and then things started working before jamf even had time to respond. Personally i think it was on Apple's end, but they did not admit and said no calls were coming in and their status showed green.
I am at JP 10.8, and have not had issues yesterday or today
I have a new test JSS hosted on a local VM. It's setup and assigned with DEP. I've got another VM with a serial number that's assigned to my test-JSS through DEP. When I launch it from a snapshot, it sees the correct DEP assignment, creates a record in my JSS, but then never gets the management account, so it just sits at the "enrolling now" screen, and JSS shows it as unmanaged.
JSS = v10.8
VM = macOS 10.14
It's not a network issue, I've been able to at least eliminate that much. Thoughts?
SOLUTION: Reinstall the OS
I just had the same issue on two new MacBook Pro's. One thing that I noted when I first fired up these Macs, they both had macOS 10.14.1, and when I ran Software Update, they responded that the Mac's OS were up-to-date. Kinda strange, when my other Macs were already on 10.14.4.
As Jordan Hare suggested, I reinstalled the OS. I booted into Internet Recovery Disk (to get the latest OS), wiped the drives, and it installed a fresh copy of 10.14.4. After they restarted, the Remote Management screen appeared and things are back to normal.
There shouldn't need to be a workaround though. It's a pretty basic step that should just work as is and it's been having off and on problems for almost a year now. It's pretty ridiculous that I have to wipe them if I get an order of 100+ devices that don't automatically enroll themselves. Very literally defeats the purpose of DEP for my org. It's suppose to be a (VERY IMPORTANT) cog in my minimal touch set up for my environment. It doesn't help that this isn't the only common problem that forces me to put hands on a device to get it working properly in my environment again. I'm honestly getting tired of these types of "workarounds", that is what DEP and MDM was suppose to put an end to.
I had this happen to us yesterday . I’d spent 2 weeks getting our new Dep sorted for our staff machines handed the project over to our helpdesk staff to assist clients with the DEP process and bam .... dep stopped working . after a few hours of frustration i renewed tokens etc restarted the server and everything was working again .
Same here, after refreshing the Token all the macbooks seem to work with DEP again. Unfortunate our iPads and iPhones still dont work. They will show the Remote Management screen and after clicking next, its stuck on "configuration could not be downloaded, cancelled".
Reassigning to ASM, reinstalling iOS and reassigning to preStage does not resolve it at the moment. It also says "completed" when looking into the prestage assingment.
Will try the same today with AC2.9 instead of prestage so we can at least set them up.
Does anybody have a suggest why it does happen and how to get rid of it?
I had issues with DEP which resulted in me bypassing DEP at setup, getting to the desktop, updating the OS (catalina) to the latest version and then using sudo profiles renew -type enrollment.
These were devices that were purchased prior to the Covid evac and so they were a little behind with updates.
Currently (TODAY) I am unable to add an OSX device to JAMF with either user initiated enrollment OR DEP due to the intermediate cert expiration issue.
I am hoping that my third party Tomcat Cert will be renewed today and that will fix the issue. the ONLY byproduct of that problem in my environment is enrolling OSX devices (so far everything else seems to be working as expected...)
Been having NEW MacBook Airs and NEW 16 inch MacBook pro's all enroll as "DEP" - "Serial number" wiping and re-enrolling does not resolve the issue. Its as if Apple isn't feeding Jamf the correct information. We have computers that are coming in as MacBook air's with the description "21.5 " iMac". No conflicting UDID's
We are seeing issues as well and now this afternoon none of my Macbook Airs are working with DEP. Some will show an error and if I click try again, they just spin on "retrieving activation record" and others just don't even bring up the management screen and go on to Data Privacy screen.
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