I saw this for the first time today testing DEP on one machine while a different machine worked fine. Came back an hour later and the machine throwing this error went through DEP without issue..
Yes, my Jamf Pro Rep had me remove the Anchor Cert payload. Also, I reinstalled the macOS on the DEP enrolled MacBook Pro two times but got the same result.
* Tried using the company public Wi-Fi, my cell phone hot spot, my Wi-Fi at home, the free public Wi-Fi in a community center; the Wi-Fi in a public library - result: the same "Unable to configure your Mac..."
@SVC-SBDJamfAdmin do you have any network filtering/NAC in place? We use Forescout and for us if our key isn't there or the MAC address of my dongle isn't trusted through our DHCP filter, (or we placed on a dedicated build segment) our DEP doesn't reach both Apple and our internal
JSS JAMF Pro and the DEP fails. What I have seen is that I can usually take it to the GUI and it will DEP enroll there with a
sudo profiles renew -type enrollment
but that only applies to 10.13 machines.
@easyedc Hi, We have NAC in place and we are seeing the same issue. If I do "no network" at setup assistant and try the (sudo profiles renew -type enrollment" command I get an error that a certificate chain is not configured properly.
Once I install our company cert, I can install the profile.
Do I need to upload our company cert as an anchor certificate in the DEP PreStage?
Did anyone get this resolved? I've just started experiencing same problem, but it all used to work a month or two ago when I've tested last. The only change happened since was me upgrading our JSS to 10.3.1.
I am also having the same issue. I have tried multiple different networks to include wired and wifi. We also have a separate external network for our department that isn't part of the regular network and that is no bueno either. I got it to work one time out of 4 machines this week by reinstalling macOS but beyond that each one I have done the same thing to it has not worked.
We have also started to run into this issue frequently. During employee onboarding on the 22nd we had the issue occur across 3 separate offices at the same time. Today while doing a hardware upgrade for an employee we ran into the same issue. We initially thought it may have been network congestion during our onboarding, but today proved otherwise.
I was able to scope a prestage to my laptop and run the
sudo profiles renew -type enrollment and receive the error as well. I've reached out to jamf support, but if anyone has any interim solutions that would be awesome.
Have you tried on an external network? Quite possible you need to make sure the correct ports are open. We had this previously where DEP worked in one office and didn't in another.
This is what JAMF supplied:
Be sure to allow outbound connections to Apple’s 184.108.40.206/8 block over TCP port 5223 / 443 from all client networks and on ports 2195 and 2196 from Jamf Pro servers to make sure APNs will function correctly on your network.
Something is broke at Jamf and they don't seem to be too quick to acknowledge or fix it. I'm new to Jamf so I'm wondering if this is typical? I've attempted to get two brand new MacBook Pros into DEP from work and home resulting in the same configuration error window. So far the Jamf Support people I've talked with are only offering desperate guesses. If you haven't opened a ticket yet please do so!
Anyone had any luck diagnosing this yet? I'm starting to see same issue in our test lab.
Well, I say same, it's likely closely related...
sudo profiles renew -v -type enrollment gives an Error -34006. I cannot find any reference to this on the inter tubes..
And in fact -34011 error too...
As you can see below, we're definitely ok out to Apple on 5223/443
dep-test-machine:~ testuser$ ~/telnet 5-courier.push.apple.com 5223 Trying 220.127.116.11... Connected to pop-namer-ne-courier.push-apple.com.akadns.net. Escape character is '^]'. ^] telnet> quit Connection closed. dep-test-machine:~ testuser$ ~/telnet 5-courier.push.apple.com 443 Trying 18.104.22.168... Connected to pop-namer-ne-courier.push-apple.com.akadns.net. Escape character is '^]'. ehlo Connection closed by foreign host. dep-test-machine:~ testuser$ sudo profiles renew -verbose -type enrollment Password: profiles: verbose mode ON profiles: returned error: 34011
I am currently seeing this issue as well. We are starting to move to DEP for faculty now and not just labs. I need a solution before school starts again. Between our ordering process on campus and the DEP troubles, I am wondering if this is worth the transition. I would be interested to know the number of admins that use DEP for a majority of their devices.
This may be in relation to an open product issue with Jamf (PI-002379) which generates excess DeviceInfoAccountHash, DeviceInfoITunesActive, and ProfileList MDM commands. When these build up, MDM seems to slow down and DEP also seems affected. I would reach out to your TAM/Jamf support to see if you can confirm that you are experiencing this PI. They have a temporary fix for it until they address the issue in product.
I do not know what is causing this but I do know how I was able to fix it for the systems experiencing it in my organization. I took their serial numbers and searched in "Devices" (where iOS devices would go) and found that they were all in there with the name: [No Name] After I deleted these entries and reinstalled a fresh copy of MacOS on each system they connected via DEP without issue.
I ought to follow up on this for posterity...
Turns out that the 34011 error relates to the device being able to contact DEP servers (iprofile/albert), but not being able to reach the CRL servers (.symcb.com, .symcd.com) in order to validate that the certificate being presented to by the DEP servers has not been revoked.
We had exactly the same issue.
Turned out to be a policy scoped to a (static) group that did not existed anymore.
Jamf is going to fix this is in the new update.
We fixed it by re-creating the missing groups.
We were recently having issues with apps not installing in iOS and in particular the Native apps at activation Apple has updated this document:
Our fix was to whitelist: bag.itunes.apple.com
Since we did this I am also not seeing the random messages on my prestages saying they cannot connect