iOS 10 - Can we delay the automatic rollout

[lbilston]

Stupid question time. I suspect the answer is you can't, but i know there are much smarter people than me out there

We run a fleet of ~800 iPads mostly in the hands of students with individual needs, some of which really don't handle change very well

Can anyone recommend any options on how to maybe delay automatic rollout of iOS 10 in the next 24 hours so we can stagger our rollout to those classes who are better suited to a change and then slowly introduce the idea to those who can't.

My initial idea was just to block the Update Services, but i'm pretty confident this would cause issues down the track with Apps updating etc.

If it helps, all iPads are supervised and managed

Thanks

[Look]

Pretty certain if automatic updates are turned off they would only update if someone manually told them to.
You can't really stop it being available but it won't just go ahead and install either.

[cpdecker]

The short answer is no, there's no client-side way to prevent the prompt to update from rolling to your iPads, and no client-side way of preventing users who want to update from updating. This is one reason why Apple is not an enterprise solution and iPads are better left under Christmas trees.

That being said, we use an Allott NetEnforcer traffic manager to block iOS updates on our network--they actually have a built in category called "Apple SoftwareUpdate" for doing this. Using this solution, users do not get an update prompt and cannot update if they try to.

I don't RECALL having an issue with App updates while blocking iOS updates. I am not sure if this is one of the few things Apple has set up intelligently or if the NetEnforcer is smart enough to make that distinction.

Keep in mind that if you decide to implement a solution like this, iPads that are taken outside of your network will still be able to update freely and will receive prompts.

We are holding out on mass-moving to 10 until we can determine that it doesn't completely break MDM capability like iOS 9.2 did for nearly 2 months, but we will have users moving to 10 against our wishes and will have to deal with whatever problems that creates.

[jbutler47]

Agreed, however, I do find that educating your users with what you wish to happen can make all the difference. In 1:1 and BYOD scenarios, communication is vital. Granted you have the drifters who will do what they want, and end up paying the price, then use them like some scarlet letter to deter future unwanted actions.

Remember, we are no longer in a set-it-and-forget tech world, roll with it, and have some fun doing it.

[jared_f]

@lbilston I actually decided to block iOS 10 for our users because it was bricking devices and I do not want the network speeds slowed down due to people updating. Assuming your devices are all supervised, I blocked the following sites via a configuration profile (we did this rather than network because devices don't stay on out network at all times) scoped to the users.

appldnld.apple.com
mesu.apple.com

For us, it did not affect updating apps.

Note: Users can bypass network level content filters via a VPN. I am not sure about config files though.

Hopes this helps! Jared :-)

[steelopus]

Here is the more complex method that we are using. This still allows for updating to 9.3.5, but not beyond.
https://jamfnation.jamfsoftware.com/discussion.html?id=21192

[cpdecker]

@jared_f , you used the Content Filter options of the configuration profile?

[jared_f]

@cpdecker Yes. We did it both at network level and a content filter configuration on supervised iOS devices. Worked perfectly.

[cpdecker]

Wow, I was under the impression that the content filter would only apply to Safari-based traffic and wouldn't affect traffic initiated by the OS itself. I will give this a shot and see what results I get. Thank you!

[cpdecker]

Are these the settings you used? (see screenshot)

[jared_f]

@cpdecker Yes. Did it work for you?

[RLR]

I tried the configuration payload restrictions a few weeks ago and it didn't work.

[nzmacgeek]

We use a Squid proxy to version control the iOS release on a group of iPads. We set up a lightweight Squid proxy that blocks the above URLs, then deploy a Global HTTP Proxy payload in a config profile to given iPads. Voila!

[cpdecker]

@jared_f , unfortunately no it didn't. It blocked access to the URLs via Safari as expected, but the update was still passable.

[jared_f]

@cpdecker I did it both the restrictions profile and network level, I was testing it on the network I blocked it on. Apple needs to find a better solution to allow us MDM admins to block updates.

[justin_shen]

@jared_f How are you restricting the updates from the network level? And can you confirm if what you are doing is actually blocking the update prompts and updates from being installed?

Thanks!

[miregan]

If you block mesu.apple.com at the network level, on iOS 11, it breaks core os apps after a device is wiped. The reason for this is that the core os apps need to check back in after a factory reset/wipe. We are using a global http proxy to take care of this allowing core os apps to function after a wipe as well as block updates. If you are not worried about the actual download of the iOS update, simply blocking 'gs.apple.com' will prevent the update from being able to verify with apple and therefore the update will be unable to install.

[CasperSally]

If you want this functionality built into MDM and have Apple enterprise support, your best bet is to put a ticket in with them requesting as a feature request. I did (at least once) and was recently told "we do have an active feature request in the works for this capability. "

Feel free to mention my ticket number to piggy back off if you want.
100325928604

We also have another ticket in requesting that VPP store be updated to alert users if they are buying 32bit apps that won't work in iOS11 (or remove the apps all together). It's bananas to me VPP purchasers have no idea they are buying apps that won't work on latest iOS and apple just shrugs. We're trying to get them to credit us for some purchases last week. That ticket number is 100331111842 if anyone else wants to piggy back on that one.

[thejenbot]

@CasperSally I just called in to piggyback on your cases and the guy at Apple was ecstatic that I did so. He said these are both high priority issues and specifically with 100331111842 there have been meetings to get this fixed.

[CasperSally]

thanks @thejenbot ! hopefully they do something soon.