iOS 9 payloads, options missing

I am also seeing the same behavior you are seeing taylor1. I get the message "Unable to check for update". But the iPad becomes basically unusable as you wrote.

Selecting the Allow Direct Connection if PAC is Unreachable option allows the iPad to keep functioning in case it can't reach the PAC. Anyone have any feedback?

MCAS testing coming up and I need to get this working. Thanks for any help.

Hi @jtaylor1 and @rknowles.

It has to be a hosted file with View permissions. I Shared the file and put the link in the configuration profile. As a test, if you paste that link into your computer's browser it should download the pac.js file.

I did NOT have 'Allow direct connection if PAC is unreachable' checked. Google just shut us down for 'Unusual traffic' and none of the iPads with the proxy were able to browse the internet, although they could use apps with their own connection. I immediately unscoped the profile but.. the iPads couldn't connect to the JSS. <sigh> So I'll be implementing that change!

I'm also testing now why iPads are acting differently in iOS 10 than iOS 9.. where they only contacted the pac.js file on restart and remembered the setting after that. I'll update this thread with my results if I learn anything.

chris

Yep, when I upload it as just a viewable pac.js file or even as an html url with the script in it, either way, navigating to it downloads the file (both the .html and the .js files) as expected. When trying either approach it then shuts down the iPad when I scope it to that iPad. No traffic to it at all, even though it has a connection and then I have to put it in recovery mode and wipe the device to get it usable again. If you check the "Allow direct connection if PAC is unreachable" box then it lets everything through, again, even the iOS updates. Thanks for the keeping us updated, @cdenesha, I'll keep fiddling with it a little as well, probably.

I ended up putting it on our server where we host the JSS, as others in this thread had mentioned trying.

We created "inhouse" folder in /Library/JSS/Tomcat/webapps/ROOT
Created "noiosupdate" folder in it, placed pac.js inside.
URL: https://<jss>.<schooldomain>:8443/inhouse/noiosupdate/pac.js

It works to block iOS updates, but allows all other app updates and internet traffic.
I do keep Allow Direct Connection if PAC is unreachable checked just in case it goes down. I don't want to end up with bricks for iPads again.

@jtaylor1 can you post the text of your pac.js?

I purely copy/pasted yours precisely. The one thing I hadn't tried is uploading JUST the pac.js and trying it with the Allow Direct Connection option checked- I tried it with the .html and it just let the updates happen, but I'll try just the pac.js later today and then post as to how that worked out.

I had two iPads that were both 9.3.x in my vault and I pushed out the config profile to both. One already had the update 10.2.1 downloaded, the other didn't. Both updated without a hitch from 9.3.x to 10.2.1 but now that they are both iOS 10 they can no longer check for an update! Additionally, they CAN do everything else. I can push commands to them, they can download apps and use apps all without issue so far.
So apparently doing it this way does not stop 9.x iPads from updating but does stop iOS 10 from updating. THANKS everyone!

Sadly, although this did work on my test devices here at the DO, once I tried to push them to the devices they'd be needed on, I ran into a new problem: Only one instance of a Global HTTP Proxy can be scoped to a device at a time, and since these devices are take-home devices, the web-filter proxy takes priority. Just a heads-up for anyone wanting to do this that also has another proxy already on a device!

Update:

Now with the 30-90 day iOS upgrade deferral option, there is another address you need to block (in addition to mesu.apple.com) if you are going to do it at the network level: gdmf.apple.com.

This is from page 185 of the latest MDM Protocol Reference.

chris