DEP not working all of a sudden

[ooshnoo]

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.

[seanjsgallagher]

I experinced a slow response at the remote management screen. Once it had completed the device was not MDM capable. I am rebuilding it now.

[ooshnoo]

Turns out I had to wipe the laptops and reinstall High Sierra in order for it to work. That, itself makes no sense as I just imaged them yesterday w/a fresh copy of 10.13.6

[JJL]

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?

[climberbry]

Ditto here.

[Stevie]

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.

[afarquhar]

We are also having the issue. Cannot connect to mdmenrollment.apple.com

[Sandy]

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

[afarquhar]

Also had issues. Seems I can enroll a macBook, but not iPads. Yesterday was getting the cannot connect to mdmenrollment.apple.com message.

[ethan_dang]

+1 We migrated from on-premise 10.5 to Jamf Pro Cloud 10.8. Tested for two days and DEP was working as expected. All of a sudden DEP stopped working after 2 days. Been working with support for 2 days on this so far.

[sparky627]

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?

[Jordan_Hare]

I have had this issue for a few weeks. Sometimes it works and when it doesn't I have to wipe and reinstall the OS then it works.

[rsterner]

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.

[rfajen]

Same issue here. JAMF cloud hosted. My MacBooks show as scoped in the correct prestage enrollment profile, I've logged into ASM and reassigned them in DEP and I still have about a 50% success rate when I'm trying to enroll via DEP. This has been going on for over a week.

[mroe]

I just started seeing this today as well with our newest order of a dozen iMacs. Can't believe this is still a problem a year later.

[rsterner]

Boot into Recovery, Erase the startup drive and Re-install macOS. Restart, and DEP is recognized.

I'm having 100% success with this workaround.

[mroe]

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.

[tguyers360]

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 .

[morti]

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?

[morti]

Ok adressing our mobile devices, their PreStage had a corrupt anchor cert. After removing everything worked fine as before. Now we still have an eye on our macOS devices as they seem working after the token refresh for now.

[Abou_Juwayriah]

Same here, we found that the Mac App store apps tried to update directly the apps after creating the local account.
we have scoped this out and it worked for a while and then it started again...pain in the ass!

[lamador]

if anyone is still having issues the below articles helped me. Sucks that we have to do this though:

• 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

[Andrewpants1]

I've had this issue happen to me the solution I found was to reinstall the OS and it seemed to fix the issue let me know your results.

[Sandy]

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...)

[dniven]

Wiping via Recovery Mode and reinstalling 10.15.5 did not fix the problem for us. We have a ticket with JAMF but haven't heard anything back yet. Glad it's not just us.

[henrik_schack]

We have this issue as well, but for some strange reason it's only affecting Swedish Macbook Air's

[cvill]

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

[jtrant]

@cvill I see this too, but it always resolves after first inventory. The "DEP - XX" entry is because they have not yet inventoried.
I also see the new 2020 MacBook Air show as a 21.5" iMac but this is a visibility issue only, I have not seen any issues because of it.

[barnharts]

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.

[dniven]

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