Apple DEP with PreStage Enrollment

@CairoJXP, I just scanned or JSS server and found the DEP folder in a backup from when we upgraded the JSS to 9.31. I have copied over the DEP folder and restarted Tomcat. Now to test to see if this resolved the issue.

We are running the JSS on LInux, so the backup was located in:
/usr/local/jss/backups/tomcat/2014-04-29_08-04-25/tomcat/webapps/ROOT/WEB-INF/frontend/enrollment/dep

We found the exact same thing and we restored the AppleCA and AppleIntermediate pem files to the DEP folder, but nothing's happening with that so far.

@musat knock on wood, but we've got the OTA deployment working again since we did the restore of the pem files and moved them accordingly. Hope it stays this way!

We thought we were back to having issues, but then I noticed that the few that were having problems were not at 7.1. Once updating them those were back to working.

So we are having the same issue but I figured it out. We have a guest network that is treated as an outside connection so it goes through our DMZ'ed casper server. This is causing a problem it looks like. When I connect the device to an internal network it works fine. So I'm not sure what is causing the issue.

Gabe Shackney
Princeton Public Schools

I'm catching up on the threads now that I have time to properly test DEP.

I skipped testing 9.32 after a day when 9.4 dropped. Is this thread still valid for 9.4?

I don't have a tomcat/webapps/ROOT/WEB-INF/frontend/enrollment/dep folder.. in enrollment there is 'enroll' and 'osxenroll'.

In tomcat/webapps/ROOT/WEB-INF/trustanchors/dep I have an AppleiPhoneCA.pem and an AppleRootCA.pem, but the timestamp is from my 9.4 upgrade not from creating the DEP server.

I do have recent .pem files named with my DEP server name and the day I created it in /private/etc/certificate. They are: myjss.domain.name.guid.cert.pem myjss.domain.name.guid.chain.pem myjss.domain.name.guid.concat.pem myjss.domain.name.guid.key.pem

I *was* able to enroll three iPads running 7.1.2 last night via DEP.. but do have an InvalidPermissionsException error every minute in the JAMFSoftwareServer.log. Perhaps from my first failed attempt at DEP enrollment (trying again was successful)?

I'm not trying to spam the thread, just trying to identify potential issues while still in my test environment.

thanks,

chris

Reviving this as I'm seeing this issue crop up on iOS 8.3, iOS 8.4 and Casper 9.73.
What happens on new devices enrolled via DEP is that we get the invalid profile error, but cycling back to the beginning of the setup assistant and then trying again results in success.

In all cases we're using self signed certs for the JSS. Interested to hear if others are experiencing the same issue, and particularly if it's only within the last week or so.

We also are seeing this. Either going back to the beginning of the Setup Assistant (3 - 15 times) or just letting the device sit on wifi for a few minutes and then they go.
iOS 8.4, JSS 9.7.3
Error occurs across multiple DEP instances, on different SSIDs, in different buildings
Using authenticated and non-authenticated DEP enrollment
Using JSS Built-in CA for certificate.
Checked times are synced: domain controllers and JSS and ext webapp
We are not authenticating with the students but assigning devices in jss after activation
whitelisted Apple's gateway of addresses going in and outbound on firewall, no ports are blocked
Any other ideas from anyone who has fixed this?

We haven't seen this issue @Sandy so I won't be able to help other than to say we have the same setup and have not seen the issue. Most iPads are on 8.3, but there are some 8.4's in there. We are authenticating users also.

We blocked the time.apple.com IP addresses (all IPs returned from pinging time.apple.com) on our firewall, and completely fixed this:

New devices enrolling via DEP: we get the invalid profile error, but cycling back to the beginning of the setup assistant and then trying again results in success.

We will now set an internal DNS redirect as others have mentioned to more permanently fix this

weird.

@psliequ @Sandy We were seeing the same Invalid Profile message during the iOS Setup Assistant. Similar JSS setup using a self signed cert. DEP enrollment on iOS devices was only working 50% of the time and this was infuriating! I spent countless hours renewing certs and testing authenticated/non-authenticated LDAP DEP enrollment Prestage Enrollments -- nothing seemed to decrease the probability of DEP enrollment failing / seeing the Invalid Profile error.

I decided to try setting our JSS server time zone to San Jose, CA (We're located in NJ) and haven't seen the invalid profile error since.

@lionelgruenberg @psliequ @john_wetter

I am mystified as to why this whole time server DEP issue was so elusive to figure out. I searched here and everywhere and found no reference to time.apple.com being an issue...
What was the reason, John, that you did the DNS redirect initially? was it to fix this issue?

We had similar problems last fall with iPad 2's and Apple told us to factory restore our used devices (800 of them) which DID allow us to activate them, but now I'm wondering if it was necessary.... was this the real fix needed?

I finally went down this path after being persistent with my TAM, because I do not really think this is a Casper Suite issue....but since they are the best source for anything Apple, I figured someone else must have been suffering as we were.... and yes.

I am still wondering what the unexpected side affects would be from either resetting my time zone on my jss servers OR blocking those IPs

Seems to me that logs will all be timestamped in PST, any OS X policies that have do not run schedules or imaging prestages with start/end dates will have to be written in PST. It would also be interesting to see if setting the time zone of the JSS to UTC would also solve the problem. Will also be interesting to see if the problem persists in iOS 9. I agree with @Sandy that this seems to be an issue with the OS and not Casper.
@Sandy, if you have any devices you can test with (I don't currently) get a copy of iOS Console and watch the output as you're attempting an enrollment. This may not work with iOS 8.4 because the device won't trust your computer until you get to the home screen to OK the connection. But, if it does work and you see anything interesting post back the results.

So, I have been having a similar issue as described above. I spoke with Korey and Al at JAMF who walked me through the below troubleshooting steps. Thank you Korey and Al!

Issue: "The configuration for your iPad could not be downloaded from "School Name. Invalid Profile.

I tried the following:
1. Unchecked Location Services under PreStage Enrollment.
- This would allow the iPad to set my timezone to CST.
-- Mobile Devices -> PreStage Enrollment -> "Your Enrollment Name" -> Steps to Skip -> Uncheck or leave blank Location Services
2. Checked my certs
- Everything appeared in order
-- Redownloaded and applied Server Token
---- Settings -> Global Management -> Device Enrollment Program -> "Your DEP Name" -> Server Token
3. Enrolled a device manually without issue
4. Deleted and Recreated my PreStage Enrollment (This resolved my issue)

My Resolution: Deleting and Recreating the PreStage Enrollment Profile.
-- It appeared that the anchor profile had become corrupt and could not install

I hope this helps!

We will not edit: skip location services, as it is required for find my iPad and is the one chance we get to make sure students turn this on. Blocking Apple's time servers has completely 100% fixed this for us without making other changes. Not sure if my net admin has set up a DNS re-direct yet or not, probably not. And probably not coincidentally, our Apple Configurator syncing has been WAY more successful since we did this.

@Sandy , Just out of an abundance of caution, to confirm, you actually have it unchecked, right? The dialog is "skip these" so unchecking it would show the location services. Before iBeacons, this was the main reason we showed the dialog was for the time zone setting. For the DNS, we don't have a redirect, but the time zone certainly got us back a few years ago. Now, iBeacons also need location services so that really is one that is hard to skip.

For Middle School Student rollout, we skip everything (by checking boxes for all ) except Location Services and Apple ID and Siri.
I found in testing that even if we did not Enable Location services, we still had the connection issues, but once we blocked the time server IPs on the firewall, the issue IMMEDIATELY went away

@lee.smith which time zone are you in?

We did the DNS redirect of time.apple.com to our own internal time server, when we discovered that when we blocked the associated IPs we could no longer activate an Apple TV.
Now in our iPad 1 to 1 rollouts we are back to the same issue: cannot walk through the activation in timely manner, as we get an error when downloading the MDM enrollment.

To work around this, we take the iPads out and take each one to Enable Location Services, then let them sit for several minutes at that point.
If they sit there for 3-5 minutes, they will proceed with no errors, so we then hand those out to the students.

Most of them start up on Cupertino time, then once we enable Location Services, often after A COUPLE MINUTES the time changes, but not always. On those that do not change while sitting, they change to our time as soon as we click to the next screen.

Hot off the presses:

I was provided the following response for a solution.
There’s a new NTP server. time-ios.apple.com. Block this now.