Anyone know if you can add a device again after a person clicks the leave remote management button at the setup assistant on a provional DEP enrollment?

We have this working fine but one of our techs clicked that button on one of the devices we were using to test by mistake and it dropped out of DEP as expected but now we can’t add it back. Curious if it’s the same as when it’s a vendor/regular DEP device and you drop it from DEP and it’s gone forever or if there is a “cool down” period before you can provionally add it in to DEP again through Configurator.

Thanks for the suggestion @jared_f .

With further testing, we found the issue was fixed when we included a Wi-Fi configuration profile to our network. Thanks to those above for the suggestions to do this.

For anyone out there with similar problems, note that it is essential for the devices themselves to connect to the network to complete the enrolment. They don't do this via the USB, they need an independent conneciton. So unless you have a cellular-based iPad with SIM and connection to the Internet, you must add a configuration profile in the step where it asks you to.

This resolved the

MCCloudConfigErrorDomain – 0x80EF (33007)

error for us. As such, this error may not pertain to whether the device is already enrolled - unless it means both. We tried to unenroll the device with the error returning that it was "NOT_ACCESSIBLE", i.e. it could have been enrolled in another DEP account, but this was not so as the issue was fixed by the above.

@chriscollins We were intentionally testing this same thing, (also asked our Apple SE) and were able to remove device from management (i.e. remove from DEP) and re-add to DEP again using the same workflow.

Note: when you click "Prepare" in Configurator to manually add to DEP a 2nd time, and you're presented with the various checkboxes, we were unable to re-add to DEP a 2nd time with the option to "Activate and complete enrollment" unchecked. Per https://help.apple.com/configurator/mac/2.5/#/cad99bc2a859), "enable “Activate and complete enrollment” if you have an existing device that already has a record in, and is managed by, your MDM."

The way I read that, you'd want to check this box only if the device in question was already enrolled in your MDM and you were simply adding it to DEP. But in our testing, it only worked to re-add a device to DEP for a 2nd time that the "leave remote management" button was tapped on if “Activate and complete enrollment” was checked too.

We were getting the same "Provisional Enrollment Failed" error, but only with AppleTV (4th Gen). iPads work fine. It's the craziest thing.

At first glance, the underlying issue is that apple have moved some of their DEP enrolment servers that are resolving to *.apple.com domains to 23.0.0.0/8 range which is akamaitechnologies

As I found our firewall has been struggling with IOS 11 with DEP
here is a list of domains an Ipad hit upon attempting to process DEP (non apple config 2 enrolment method)

init.ess.apple.com
init-p01st.push.apple.com
init-p01md.apple.com
init.ess.apple.com
sr.symcd.com
s2.symcd.com
gspe35-ssl.ls.apple.com
gspe21-ssl.ls.apple.com
gspe1-ssl.ls.apple.com
configuration.apple.com
sr.symcd.com
init.itunes.apple.com
bag.itunes.apple.com
cf.iadsdk.apple.com
init.itunes.apple.com

And because my firewall wont work on domain names and only IP's this could be an ongoing battle, as I cant just work with wildcards or just approve 17.0.0.0/8 which we have done in the past.

Frustratingly, I tried doing the Apple config 2 enrolment method off of my phone internet, but it still wouldn't proceed past the error: MCCloudConfigErrorDomain – 0x80EF (33007)
Presumably, this could be a time setting issue as enable location services on the device is no longer a prompt in IOS 11 it appears. Or it simply isn't available in some countries yet. (Australia being me)

Managed to get past MCCloudConfigErrorDomain – 0x80EF (33007) the ipad we were using, although new, had already been DEP enrolled by another onsite tech. Still working my head around how to use a wifi profile for the enrolment and then have the MDM remove the wifi profile later on. Also last attempt, while using user credentials, didnt assign the user to the device, is this a bug?

We got iPads in DEP, we have authentication required so our users are given the iPads in a restored state, they log in with LDAP creds which then populates user info in JSS. Now, if a user leaves and iPad needs to be assigned to another user, how do we get the iPad back that user auth page to adjust the user data in JSS? It would be great to be able to send a command to the iPad from JSS to do this.

We used wipe, but that just restored it and it skipped the user auth part, I’m guessing because that data is already on JSS? I tried with a different iPad by wiping and deleting it, but that just lost all management and required usb connection to prepare again.

Anyone found a more efficient way to assign an iPad to another user and require that user to sign into the iPad and have those credentials update JSS?

I run a script that gets the iPad assignments from our job management system (Disco discoict.com.au) and the export from our school management system (the UserCreator export) to assign the ipads to users in JAMF Pro and rename the devices to include their name.

If you are willing to get your "hands dirty" with python it could be changed to get its data from any text file.

Regards
Graeme

I've been working through my bugs with this process... and finally came up with a solution, which I thought I would share here as it may come in helpful for some.

scenario
we use wifi authentication via profiles assigned through jamf pro, which will assign their wifi against their username and password, using a wildcard and a generic password for all students.

The reason for this method is, it individualises the connectivity on the wireless land controller, so we can locate devices easier, but it also passes authentication against our proxy as our proxy will assign proxy access based on wifi user auth.

The problem was generated through the manual enrolment DEP AC2.5 process as the profile we created in AC2.5 which has a specific user assigned to it to connect wifi, would also then get absorbed by the mdm profile, preventing it from being removed at a later date, and as a result not being the correct wifi user on the device.

In the past it appears the method around this was to set a self removing profile, but as it gets absorbed by AC2.5 this doesn't seem to remove on its own. This never seemed to work for me any way.

As we are using wpa2enterprise we cant wifi share our macOS connection via lightning bolt and pass the requirement for the internet access, which has been a bypass for some.

And the jamf prof generated profile wont work with wildcards in AC2.5

To resolve the issue, I duplicated our wifi profile within casper, and renamed it with manual DEP at the end
I then didn't scope the profile to anyone, and also excluded all managed devices also.

This allows the MDM to recognise that the profile shoudn't be on the device if it is found

Then I downloaded the profile, and collected the profile identifier code, and created a AC2.5 version for a generic user auth wifi profile, to be used during the enrolment process.

This allows our ipads to go through the manual enrolment process, and then recognise that the profile is incorrect and remove it, which then allows us to connect the wifi manually and receive the correct profile.

It's not the best solution, but it works.

I am also looking at sharing the internet access option, with a wired desktop over my laptop.

(Below for Jamf Cloud Hosted only)
In addition to the above information the below may help jamfcloud customers that are still having issues. It could be because we have a dedicated jamfcloud instance, not 100% sure. The main takeaway from the below is the URL name being different for the MDM URL setting.

From working with Jamf Support this morning:

First, we select the device in Apple Configurator and hit the Prepare button. We chose to perform a Manual Enrollment, Assign the Device to DEP, and allowed the device to pair with other computers.

When prompted for the URL for your MDM server, since you are a cloud customer, we had to use the following URL format (This is not our Jamf cloud web URL login, etc).

https://instancename-mdm.jamfcloud.com/mdm/

For example our normal Jamf Cloud server URL is https://instancename.jamfcloud.com:8443/ (we had them change it to 8443 on our dedicated hosted Jamf cloud server due to a cloud hosted content filter in order to bypass via a GRE Tunnel to Zscaler) Jamf Support said this was a little different for cloud hosted customers to use this instead for this process replacing instancename with your instancename "Including" the -mdm.

Example:
https://eastracademy-mdm.jamfcloud.com/mdm

(For example in this case the normal login URL would be https://eastracademy.jamfcloud.com:8443/)

They had us remove the 8443 from the end even though our server is setup this way.

It will give an error when you click next but continue. You know it worked if it asks for your certificate which would be *.jamfcloud.com

Select a WiFi profile you have created previously and tested.

Create the login to your DEP/ASM in the next steps.

If you prepare and run this your iPad should reboot during activation and show up in the Apple Configurator MDM in your ASM. Then just just assign that serial # to your Jamf and roll on.

I didn't go into extreme detail since all has been explained above. Mainly the instancename-mdm.jamfcloud.com was the ticket for our issue.

Jamf support mentioned they have been running into random glitches with this and some customers may have an issue that another does not with bringing a non DEP iOS device into the fold.

We had one iPad with the MCCloudConfigErrorDomain – 0x80EF (33007) error. The iPad that was accidentally disowned that was in our DEP previously. If it has ever been in anyones DEP previously the Configurator 2.5/iOS 11 method to get it back into a DEP/ASM will not work according to AppleCare. So in theory if you had some iPads/iPods donated from another school system or business that had them in DEP even though they disown them it will not allow them back into DEP at this time (10/31/2017). However they did take the serial # and I took a picture of the back of the iPad and uploaded to the Applecare ticket but he didn't hold out much hope it could be added back into any DEP account.

We have a locally hosted Jamf Pro installation and the issue I'm seeing with trying to enroll the devices via Configurator is that the devices will get up to the Remote Management screen and eventually just return "The request timed out". Anyone else seen this?

@MikeT
I came across that one also, with one enrolled within our own dep, even removing it wont work, as I believe it has to be disowned by the original purchaser before it will work. Which in a school environment may occur, as I initially never disowned devices rather than unmanaged them through the DEP portal, in the event the student came back, or a seperate issue of ownership arrived, I could renrol it, locking it back into our infrastructure.

This from the look of it will never have a solution, or at least for several years. e.g. if they built an interface in the start up saying who the device belongs to, so the matter can be requested through the original purchaser.

Hello All
So it was an interesting experience using AC2.5 and a iPhone 8. I read the above post and followed @ncarvalheiro87.
I followed the documentation until i got to the Server and MDM Url. I then found the other post by @MikeT as we using JamfCould and changed my URL to suit. I received errors, made some modifications (removed the -mdm from URL) and got through to the next screen. I entered our Schools Apple ID to connect to our ASM and continued with the process.
After that I really don't know what happen, errors on the phone, errors on AC2.5 after completing 14 of 16 steps. I decided to re do it all and had the same experience. After a 2nd failure I checked DEP the iPhone was there. After wondering WTF. I disconnected the phone, wiped it and now I can use DEP to manage it.

I kinda wish the process was 'cleaner' if that makes sense. I think after i enter the School Apple ID and the phone went through the first few steps thats when it registered with DEP. After that, It does not matter for us as do not use AC here.
Anyway, I don't know if I was much help, but thought I would add my 2 cents.

Cheers
P.

*UPDATE: Completely failed. The SN did not appear in Jamf even after Refreshing the DEP menu. Went back to ASM try to re add the SN and received a Not Accessible Error. Back to AC2.5 and a phone call to AppleCare.

Hello All

I had another attempt at self enrolling via AC2.5 and DEP. This time I had more success.
Here is the rough process:

Insert SIM card
Connect iPhone to AC2.5
Click 'Prepare'
Fill out all details - Server, URL etc.
AC shows ‘Preparing “iPhone”
Phone is showing 'Select WiFi and Syncing information'
At this point I checked ASM and it showed a Device added to ASM.
Downloaded the CSV
Assigned device to institution
Checked Jamf Prestage.
Refreshed
It worked this time - Device SN was in Prestage.
Ran a DEP Test and it worked fine.
Deployed to User.

Yesterday I did the same steps and the SN disappeared from ASM.

Why do we need to assign an MDM in Apple Configurator? That is assigned in ASM?

I have tested with 3 iPads. Two of them successfully assigned to ASM/DEP and then into JAMF. The other always times out. I am using a dummy MDM assignment in Configurator, as it really gets assigned from ASM.

An MDM must be selected because although the device is being added to ASM/DEP, the device can be opted out of ASM/DEP within 30 days of configuration. Essentially it needs to be configured with an MDM that it knows it will have a path to.

I'm getting the same issue on an iPad.
None of these suggestions in the comments work, nor JamfNow, nor Apple documentation.

On that note, whenever I don't receive this error, I get 'The Configuration file cannot be downloaded from 'server'. invalid profile.'

This is ridiculous tbh

I had the same issue and I contacted apple care.
After sending all my logs to apple engineers, they seem to have fixed it.
The consultant that i spoke to said the it was something wrong from there and and they have fixed it now.
I have successfully added 3 iPhones to my Apple DEP via Apple configurator 2.7.1.

Provisional Enrollment failed error Network communication error. [MCCloudConfigErrorDomain – 0x80EF (33007)]

I recently ran into this issue with Apple Configurator and iOS 11 and 12 devices when I adding devices to DEP.

I went through the trouble of configuring a wireless profile but it wouldn't seem to hold.. Eventually I found out that if I just go through the first prompt and sign in to wireless on the device and then run the DEP setup on Apple Configurator with a fake MDM server, the device would get added to DEP and I could then assign it to our MDM.

After DEP is completed, you could then go through the DEP enrollment and the device would connect to our MDM.

Hello
We are still getting this error as well with iOS 12.4 Anyone have a fix?

Provisional Enrollment failed error Network communication error. [MCCloudConfigErrorDomain – 0x80EF (33007)]

When we got that error message, the device was available in DEP and we moved it into Jamf. After that we just wiped through Apple Configurator and went through the Setup Assistant to make sure it was picking up the MDM and installing the applications.

I'm getting this same error and the device is not in ABM (DEP)

What a waste of time this forum is

We come across this problem when our wireless profile cannot contact the network. In order for the iOS devices to reach the enrollment page with Apple, they need to have a network connection. To do this over the lightning cable, open System Preferences > Sharing from the macOS device running Apple Configurator. Check the box for each "iPad USB" in the "To Computers Using" section before enabling Internet Sharing (There will be one box for every iPad plugged in, so if you have more than one, check each box).

I had the same issue and it was as simple as my wifi not responding quickly or consistently enough. I created a separate AP that sits right near my sync station and is only used for AP2 initial DEP enrollment. Works a treat!