Skip to main content

We are having an interesting problem getting our iPads enrolled... Environment is an internal JSS running on Windows Server 2012R2. iPads are on the same network as the JSS server, and there are no VLANS in place. When the iPads are connected to an internal WiFi network, they will get an error of "Invalid Profile" when trying to apply the initial Pre-stage enrollment. If you connect the iPad to an external wifi (eg, tether to a cell phone), the enrollment completes successfully.



To further complicate things, if you leave the iPad sit on the invalid profile screen for an undetermined amount of time, it will eventually allow you to proceed with a valid profile.



I'm wracking my brain trying to figure out what combination of firewall funkiness could possibly be causing these. If anything, I would expect enrollment to have more problems on an external connection than internal, since it would have to go through the NAT rule to get to the internal JSS IP. But in this case, the opposite is true.



Any help would be appreciated!

@nadams I thought for DEP your JSS would need to be externally accessible.

@bentoms



Our server is accessable internally and externally at the same address. Depending on where you're resolving it, you'll get either the external IP or the internal IP.



The way I understand DEP, after connecting to wifi, the iPads reach out to apple to activate. Apple says "hey, you're in DEP, so you need to look at the server "https://yourserver.yourdomain:8443" and get your configuration." The ipad then contacts the server at that URL to get the deployment profile. Depending on what network you're connected to, that could resolve either the internal IP or the external IP.



I think thats how its working anyway, Since we only have the issue on internal networks.

Hi Noah,
It's possible that your issue has to do with the devices attempting to contact Apple's time servers, and also the devices often start up in Cupertino time.
The waiting and then they work is a good clue, as they eventually time out, or location services kicks in and resets the time zone correctly.
We mostly fixed this by using DNS to re-direct time.apple.com and then time-ios.apple.com to our own network time server.
Apple says: Theoretically redirecting the DNS entry to a local server should improve the behavior as long as the device does not receive an older NTP time than the one it was using at the beginning of the setup assistant during enrollment, but there still exists the chance that the time might be set back.

Reply


Terms & ConditionsCookie settings