Stop iOS updates- State Testing Requirement!!! HELP!

Have you checked this section in Mobile Apps?

@CapU I think you misunderstood the original post. I need to prevent iOS updates, not keep an app updated.. This is not applicable, unless I am totally missing your point, in which case- please explain how to implement....

We used to block via URL, but that stoppped working in the last few months (probably because we have apple's IPs whitelisted elsewhere). will be following along to see if you get any better suggestions. If you have an apple support contract, I highly suggest putting this in as a ticket to be able to disable iOS updates via MDM. There are cases (like this) where it makes sense.

The Apple iOS Management framework does not support this functionality. It only supports updating to the latest and greatest version of iOS on supervised devices iOS 9 or later. Outside of that the iOS updating is left to the individual device.

The work around some schools have used is to block the wide range of Apple IP addresses associated with updates. It goes without saying this will have repercussions on other systems as well.

Unfortunately, I've still got a lot of iPads that aren't up to 10.2 yet, so I can't block all updates. I think we're just going to need to rely on the testing companies to validate the iOS update quickly on their end.

This dance between Apple, the testing companies, and us is really tiresome.

@Emmert Ya, I wish this wasn't the case. Sadly, the update frequency from Apple is much much higher than the AIRAST app we are forced to rely on. Last year- all 480 student iPads updated the day before testing and were sitting on the "Welcome" screen. Even after we got to the home screen, the then updated iPads weren't compatible with the testing app and all students had to move to the computer lab.

Adding a firewall rule and block.
mesu.apple.com
appldnld.apple.com

@kuypers Already done, as stated in the OP. It no longer functions to stop the updates...

We added here this morning to one of are sites and it stopping.

These two servers are blocked in our top level filter. I have also deployed a policy to all iPads via JAMF to block them. I have verified that the policy was pushed out and installed.

The update is still available.

We do have a Mac Mini running Server on it with cache service enabled. This device is located behind the filter, however, could it have some backdoor/other method of downloading/serving updates?

Update: I shut the caching service off & cleared the cache. The iPads can still update...

Are you sure 10.2.1 is going to cause a problem? My understanding with most of these testing app vendors is that once they support iOS 10.X, they will also support 10.X.X. Regardless, there is no supported way to hold back updates. You can block mesu.apple.com, but you may find that it causes other issues.

@cbrewer They should be fine with such a minor update. The problem is that if there is a major update during the testing window- we currently have no way to stop it...

Also, our vendor in particular has issues with random minor patch numbers, i.e. 10.0 & 10.1
So once they say they support 10.2 specifically- we need to freeze the iPads there until the testing window closes...

We've come to accept that we just don't have control over it. It's a good reason to have some computers or iPad 2's as a backup for testing.

Last year iOS 9.3 wasn't supported when it first came out, but even though it wasn't supported it still worked for our testing.

@cbrewer This seems to be the general consensus around this topic, but to me- it isn't good enough. Last year we looked ridiculous in front of the entire junior class because they got 10 minutes into the test, then the app crashed. We then had to relocate all Juniors to computer labs / libraries, plus had to restart the test session, blah blah blah. Needless to say, it was awful & embarrassing.

I can't imagine this is acceptable in larger districts. Our neighboring district has 56 schools alone...

There's gotta be a way to avoid this in the future...

@cruess, have you had a conversation with the vendor? All parties need to understand that a minor OS update should not keep an application from working.

As of today (1/24/2017), Apple hasn't stopped signing 10.2 yet so you could downgrade those devices back to 10.2 if you needed to.

Another solution mentioned on several blogs is to install the "tvOS beta profile." It is claimed that this will stop the update notifications. I haven't tested this, so use at your own risk.

http://www.idownloadblog.com/2016/08/18/how-to-stop-iphone-asking-to-install-ios-updates/

@bradtchapman Yes, we have an open ticket/discussion going with the vendor. About an hour ago they replied and said it would be fine. Then 5 minutes ago they replied again and said that it requires further testing and that it is not approved.

The method you referred to appears interesting, however, it also looks like a nightmare to replicate on every ipad across the district...

I feel like between JAMF and web filtering there should be an easier avenue to accomplish the goal..

:

@cruess Have you thought about uploading that profile after signing it and testing it out on pushing and functionality to a small group of iPads? We push a custom built VPN profile here through the JSS.

Hey all,

Has anyone come up with a solution for this? We have a teacher using a Project Lead the Way app that is not compatible with iOS 11. She has asked me to make it so that the iPads do not update. Sorry if I missed the solution somewhere.

Blocking mesu.apple.com at the network level does block iOS updates so not sure where the issue was as stated above. If you dont want to update to iOS 11 I would suggest blocking mesu.apple.com on the firewall. Blocking mesu.apple.com will present other issues in iOS 11 but since you are looking to stop the update to iOS 11 then that is the route I would suggest.

Have you thought of blocking the whole Apple 17.0.0.0/8 network. Its very drastic but if you have to get through a testing period shortly then it might not be a huge inconvenience.

We have scoped a config profile to all devices - it's a Global HTTP Proxy payload, set to automatic, and it points them to a URL where a Proxy PAC file is located. We allow direct connection if PAC is unreachable, and our JSS is externally facing so they can't access the update offsite. The file states:

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";
}
}s

This has been extremely helpful for us; we only exclude devices we're testing, otherwise users get an error message when searching for the update. An engineer at JAMF helped us set this up and it's saved us so many headaches - we haven't had a single student update to iOS 11, which (thanks to the recent notification that it's not compatible with TestNav) we're very grateful for.