Our Method For Restricting Visibility Of iOS 10 Update

steelopus
New Contributor III

Hi all,

We've decided that we do not want any of our iPads updating to iOS 10 this year, as we still have a large number of iPad2 and iPad Mini (original) devices that are not capable of updating. So, in an effort to ensure a consistent iOS environment in all of our classrooms we have decided to block access to iOS 10.

We are aware that once a device leaves our network then we have no control over their ability to update, but as the vast majority of our devices are shared in a cart-based environment in which they never leave the school, we feel this is a viable solution to cover the majority of our devices. Those that choose to update off-site will have to deal with the consequences of doing so (mostly: students complaining that what the teacher is showing via AirPlay doesn't look like what they are seeing at their desks).

Traditionally we would do this by simply filtering all traffic to mesu.apple.com with our Lightspeed webfilter, but in this case we don't want to do that because we still want iPads to be able to update to iOS 9.3.5 so they can apply that important security fix.

So our new method involves a DNS redirect to self-hosted XML files.


It is not complicated but we discovered a large number of XMLs that all needed to be self-hosted.

We initially tried it using only the XML that you've linked to in your post. After doing so we tailed the 404 log on the webserver and discovered a large number of other XML requests that were failing, so we manually downloaded each of those XML files and self-hosted them as well.

We are self-hosting 18 total XMLs.

One quirk is that each XML is stored in a folder whose name matches exactly the name of the XML, minus the .xml extension.
i.e., For two different files, "example1.xml" and "example2.xml", they need to be stored at these paths: "/assets/example1/example1.xml" and "/assets/example2/example2.xml"... and so on...

I don't know for certain what else we may be breaking by redirecting ALL of those XMLs, but so far things have been working well. As far as I'm aware, mesu.apple.com is only a software update server so I don't think any other Apple services would be running through that URL.


The setup should look something like this:

  1. Redirect mesu.apple.com using a Domain Alias (DNAME) to the hostname of a webserver of which you have full control.
  2. At the webroot directory of that webserver, create the folder structure as shown in the attached image.
  3. Download the xml files from those locations (you'd better do this TODAY, September 12, 2016, before Apple updates them for iOS10. The sooner the better!). If you have already redirected DNS then you'll need to download those XMLs from offsite and send them back to yourself. Alternately, download them before you enable the DNS redirect.
  4. Host each of those XMLs in the folder that matches their name, which you just created on the webserver.
  5. Note that one of those XMLs sits at "/assets/tv/".
  6. Test it out!

1f758f375bd341258ddda28a6bf787b0

Once we self-hosted all of those XMLs, we found that 9.3.4 and older devices on our network could see the update to 9.3.5 and perform the update. Devices that are at 9.3.5 do not see an update.

Now... we'll see what happens tomorrow when iOS 10 is released, but I'm confident that because we are redirecting their update server, no devices will see the update unless iOS 10 stops using mesu.apple.com entirely, which doesn't seem likely.

Good luck to everyone on release day!

13 REPLIES 13

steelopus
New Contributor III

Why this works:

The XML located here:

http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml

is what iOS devices use to determine if their iOS version is up to date. It lists all iOS device models and then has a matrix to link each model to the path of the correct update file to bring it's current version up to date.

Apple updates that XML every time they release an iOS update.

By self-hosting and using a DNS redirect, when an iOS device on our network checks for an update, it is redirected to our self-hosted XML file which tells them that 9.3.5 is the most recent update, and the device behaves accordingly.

jwojda
Valued Contributor II

so you said you had 18 self hosted xml's, where did you get the xml data for them?
or does your followup post supersede the 18 and contain it with just one?

steelopus
New Contributor III

Each of those XML files can be downloaded/saved from Apple's servers. Each path in the image I attached should be prefaced with: http://mesu.apple.com

For example:

http://mesu.apple.com/assets/com_apple_MobileAsset_Font2/com_apple_MobileAsset_Font2.xml

As mentioned in Step 3, you'll need to save/download those XMLs either before you setup the DNS redirect or from a computer that is not part of your domain.

steelopus
New Contributor III

It's still early, and I'm certain this will be resolved, but this is an example of why we like to control access to iOS updates on our network.
http://www.macrumors.com/2016/09/13/ios-10-update-bricking-iphones-and-ipads/

So far our DNS redirect has proven to be functional.

cpdecker
Contributor III

Great thinking @steelopus and thanks for the writeup.

I want to be clear on wants going on here. The XML files tell the iPad what iOS version is the latest, and they are still requesting iOS update 9.3.5 from Apple servers rather than 10.x because of that, is that correct? Are you still able to update to 9.3.5 now that 10 is out? Do you think Apple will stop hosting iOS 9.3.5 soon?

Thanks!

steelopus
New Contributor III

@cpdecker That is exactly the logic behind the process. I'm almost certain this will eventually break, but I am still successfully updating devices to 9.3.5 today. So, for now, it still works.

I don't think Apple ever stops hosting the actual files, because there are certain models that technically can't install iOS10. I guess I'll find out at some point in the next few weeks as I continue to push the Update iOS command from our JSS. I'll be sure to continue updating this post with my findings.

steelopus
New Contributor III

Also, if anyone missed the window and doesn't want to manually remove all the references to 10.0.1 from the current XML, just let me know and I'll zip up our collection and send them to you.

cpdecker
Contributor III

"I don't think Apple ever stops hosting the actual files, because there are certain models that technically can't install iOS10" -- I think you are right on the money again. I have observed something similar. When we had our App Store disabled, iPads couldn't check in to see what version of the App was the latest, and they were installing old versions of Apps that hadn't been available for months by using Self Service. That confused us for quite a while!

Again great write up, thank you for taking the time.

ROAllen
New Contributor II

@steelopus Do you still have those files? Thanks.

steelopus
New Contributor III

@ROAllen I do. Shoot me an email to slopez attt fairport dottt org.

steelopus
New Contributor III

Just an update to everyone that this is no longer a functional solution because Apple stopped signing iOS 9.3.5 on October 19th, 2016.

In theory it would still work for newer versions of iOS, if for instance you wanted to stop everyone at 10.1.1, then you could just grab the most current XMLs and setup the redirect now, but you'll constantly be at the whim of Apple as they can decide to stop signing old iOS versions at any time.

albyvar
New Contributor

Hi! I know this is an old post, but please can you tell me how you redirected mesu.apple.com to a local server? Please

steelopus
New Contributor III

@albyvar You or whomever is in charge of DNS at your organization would create a new zone and DNAME record to point mesu.apple.com to the name or IP of a server inside your own network that would then host the XML files that you grab from Apple.

This screenshot is what our setup looked like when we had this running on our WinServer2012R2 DNS box.

c3b8a54addc045a1b6fefc9ab052efc0

It's been a while so I can't really say if this is still a functional workaround.