@St0rMl0rD do you have any supervised or DEP devices?

I think those options are only available to those devices that are DEP &/or supervised.

To clarify:

• There is nothing in MDM to block iOS updates, including in iOS 9.


• Caching and Install iOS update MDM commands require support from the MDM solution. 9.8 does not have it, not sure if 9.81 will.


• Exists now by disabling App Store. iOS 9 and supporting MDM allows deployment and update of apps while App Store remains disabled.


• Nothing in MDM provides to ability to set a particular passcode. MDM can clear pass codes and require them. User must set it.

@jarednichols i wondered if the MDM spec had changed regards to some of this for iOS 9 as it seems lightspeed are advising that they can block OS updates.

If lightspeed's advising that, I'm not sure how they're accomplishing it aside from some voodoo snakeoil black magic. It'd likely have to occur at the network level. I'd be curious if you could share details.

@jarednichols in fact there is something to block/force iOS Updates, it was introduced on the WWDC 2015 - with iOS 9.
It should be part of the session "What's New in Managing Apple Devices" ( https://developer.apple.com/videos/wwdc/2015/?id=301 ) if I recall correctly.

@St0rMl0rD JAMF answered on that by promising to implement that in an old Feature Request ( https://jamfnation.jamfsoftware.com/featureRequest.html?id=386 )

Yeah I see, but we're more interested in blocking the iOS updates than forcing them. Oh well.

If lightspeed's advising that, I'm not sure how they're accomplishing it aside from some voodoo snakeoil black magic. It'd likely have to occur at the network level. I'd be curious if you could share details.

We're currently sort-of blocking it using a proxy-auto-config file on all of our iPads. It's a profile that contains "Global HTTP Proxy" settings that point at a file in our inhouse folder. That config file blacklists mesu.apple.com.

It's not perfect, but it's working for 99% of our iPads.

Is mesu.apple.com used for anything else? That tip sounds amazing.
EDIT: which port and credentials does one use for this?

They check mesu.apple.com on port 80.

@udopigorsch No, nothing for blocking. What was introduced at WWDC for iOS 9 is the ability to MDM command a device to cache and (separately, if desired) install iOS updates. These additions were important for customers in retail in particular who wanted to be able to push out iOS updates without having someone touch the glass.

There is currently still no iOS update blocking within MDM. (Have a look at the MDM Protocol Reference if you like.

There are things do-able at the network level (such as blocking mesu.apple.com) but keep in mind that these are completely unsupported and off the reservation. Do they work? In most cases, yes. However, I'd caution in blocking mesu for terribly long. For instance, if you were blocking it for iOS 9, finally tested it and open up mesu later this month, devices will see 9.1 which you hadn't tested. Blocking mesu is all or nothing. There's no granularity to picking which update you want to allow to devices. Also, if devices roam off your network (or have cellular capabilities) they will see mesu at some point. Should they see the catalog at some point, they'll be able to download updates from the CDN, even if they roam back to a network where mesu is blocked.

For instance, user takes iPad home, iPad is in sight of mesu. iPad begins download from the CDN. User goes back to work, is on work network where mesu is blocked. iPad completes download, user installs update. iPad is on an OS you didn't intend. Yes, you can resolve this by using Global Proxy or always-on-VPN, but do you have infrastructure to handle that?

iOS updates are critical for maintaining device security. Un-patched flaws are the #1 attack point.

And keeping iPads being useful is our #1. If it happens like last year, when after iWork for iOS update users with Mavericks couldn't read iWork files, created on iOS 8, things are gonna go ballistic.

@Emmert

We're currently sort-of blocking it using a proxy-auto-config file on all of our iPads. It's a profile that contains "Global HTTP Proxy" settings that point at a file in our inhouse folder. That config file blacklists mesu.apple.com.

It's not perfect, but it's working for 99% of our iPads.

Yup. Network level.

Hi everyone,

I tried using a profile with mesu.apple.com on port 80 as the global HTTP proxy, but the iPad still shows iOS update as available to download and install in the Settings. Am I missing something?

EDIT: just figured it out, specifying the proxy server will send ALL traffic of the iPad through that server..looks like we won't be doing this

Here are the contents of the pac.js file I have ours pointing to:

function FindProxyForURL(url, host) {

if (dnsDomainIs(host, "appchina.com")

  ||dnsDomainIs(host, "iemulators.com")

  ||dnsDomainIs(host, "mesu.apple.com")

  ||dnsDomainIs(host, "vshare.com")) {

return "PROXY 8.8.8.8:53";

}

else {

return "DIRECT";

}

}

It does do all traffic by default, but not if you use some "if" statements.

Oh, nice. Where do you put this pac.js file? So the traffic, that isn't going to one of those 4 servers, will not even go through the proxy?

Correct. I'm hosting the pac.js file in our inhouse folder, and the config points to it:

https://jss.yourdomain.org:8443/inhouse/pac.js

Thanks, we'll give this one a shot.

Hi @Emmert this is good info. I have two questions about the DIRECT.

1) Does the proxy server (your jss) end up forwarding the traffic or does the iPad handle it all?

2) Do you know if the pac.js settings are cached on the iPad at all, or does every single http request (browser, app, update check, etc.) have to go to the pac.js first?

I'm trying to implement a temporary iOS Software update block in case iOS 9.3 comes out during the middle of SBAC testing. Our JSS is hosted, but if I could put a pac.js on a Google Site page...

thanks!

chris

I have just completed my own testing, using OS X Server to host a pac.js that is identical to the above but for just mesu.apple.com.

It works to block iOS update checks. For the following explanation, please remember that I am not a network person.

Every time the iPad restarts it sends three to four connections to the web server, for processes configd, networkd, and securityd; sometimes there is also a locationd (I see this in /var/log/apache2/access_log). The settings are then cached locally, and as the file uses DIRECT there are no further connections as I navigate to different web pages and use various apps. I can install apps, get lists of updated apps, and store data in iCloud Drive. I get an immediate 'Unable to Check for Update' error when I check for an iOS upgrade. If I put the iPad to sleep and open it again the next morning, the information is still cached. When the iPad is restarted it connects to the web server and downloads pac.js again.

chris

Hi all,

I thought I had fully updated the thread with my last post, but I guess I did not.

I successfully deployed a configuration profile with a Global HTTP Proxy payload to my 7th graders using SBAC this past spring and they were unable to update iOS.

The pac.js file was uploaded to a Google Site but did not overload it due to the way it works (see previous post). It contained this code:

// created by chris denesha for GPS iOS Update blocking 03/2016

// copied from Emmert at https://jamfnation.jamfsoftware.com/discussion.html?id=17096

// I tried changing 8.8.8.8:53 (a DNS request) to 127.0.0.1 but it took longer for a timeout

function FindProxyForURL(url, host) {

if (dnsDomainIs(host, "mesu.apple.com")) {

return "PROXY 8.8.8.8:53";

}

else {

return "DIRECT";

}

}

Screenshot of config profile configuration:

chris

Chris, this is an interesting solution. If I point all my iPads to a global proxy to block an iOS update, does this also affect the iPads from getting the latest App updates?

@damienbarrett Nope, if you use just the URL above you just block the ability to check for iOS updates.

@cdenesha I would also like to block updates when they first come out and I followed your steps using a google site and everything seems to be working great. I was still a little confused on the caching part. Would every site that I go to on the iPad potentially have to go to the proxy first and then to the site? I don't know if we can have every iPad in our environment go to the proxy every time they browse to a website. Any clarification will be helpful. Great fix, though! I really do appreciate reading your insights on these discussions.

Hi @cnelson - no the iPad goes there on startup to get the settings and then it retains them until the next startup. It uses those settings for all web traffic not just web access which is why I couldn't use a profile for Content Filtering.

I'm currently blocking iOS 10 for all supervised devices in district until I complete my testing. I'm also in the middle of a deployment for K-6 so it is taking awhile.. :)

I know this is an old(ish) thread, but we have testing coming up and for the secure browser, they are saying that iOS 10.3 is scheduled but they might not be compatible with 10.3 in time for testing. This has Academic Services worried, so I decided to try what @cdenesha suggested here, and it seems to be preventing ALL traffic on the device I scoped it to.
Well actually, the first thing I tried was to create the pac.js file copied directly from your example and uploaded that to a google site, pointing to that pac.js within the global proxy, it didn't do anything at all. My bad, I realized, there's nothing telling it to run the script. So I created an html page that just called the script and then uploaded that html to the google site (you can't directly edit html on a google site page with the new and improved google sites?!), and then aimed my global proxy at that url.
Screenshot of what what I did:

This was when everything stopped working. Once that profile was pushed to the device, it definitely stopped it from updating, but it also stops everything else! I can't send commands to the device, I can't remove the profile, the device can't use the internet at all. It tells me that it is not connected to the internet even though it plainly is connected. In the end, the only thing I can do is put the device into recovery mode and use iTunes to wipe and restore the device. For some reason, "Erase all content and settings" is missing as an option on these iPads now, as well. Not sure what's going on with that, either...

Any thoughts? Ideas? I am not really a javascript person so I fully recognize that I simply failed to understand the instructions, but I'm hoping I can get this to work and make Academic Services happy.