Blocking the iOS 9 Update

[aoconnell]

I would like to block the iOS 9 update in fear of the apps not being compatible. Is there any way to do this?

[kauppila]

Using my web filter I blocked these sites and it blocked the updates for our students.
appldnld.apple.com
mesu.apple.com

[kitzy]

Why not update a device yourself and test mission critical apps? Then you can make the decision based on facts instead of fear.

[McAwesome]

@kitzy For the obvious reason. Users may update before you are done testing if things are compatible.

[CasperSally]

Yup we block it internally until our team has used it a few days. We've ran into pretty bad exchange bugs in the past that don't necessarily present themselves immediately. It's been a few major iOS versions since those kinds of issues though.

[kitzy]

How do you prevent users from taking their device off network and updating? Or connecting their laptop to a VPN, downloading the update, and installing it via lightning cable? Or any other number of ways that users can bypass your blocks?

I think that a far better solution is to communicate to and educate your users. Tell them "we have not yet completed testing of iOS9, and we recommend that you do not update until we have verified all mission critical apps and features are working as expected. If you upgrade before then, you do so at your own risk."

When you block, your users interpret "IT are jerks and don't want us to have things."

When you communicate and educate, you users interpret "IT has our backs and is making sure things work for us."

[CasperSally]

Thanks, Kitzy, for the advice. We do communicate to our staff that we are testing it and please don't update until we OK it. We understand that they could at home, etc, but at least they got a heads up we're still testing.

We also block it at a network level so the update isn't advertised to our iPads in classrooms. There's no need for 1st graders to get nagged about it.

[mm2270]

I'd have to agree with @kitzy here. Its reasonable to give an update like this several days if not close to a week to shake out before making a determination on if its safe to upgrade. Every environment is going to be unique in that regard.

While we don't actively block iOS updates from being installed (when not on the corporate network) we do send out a global notification at least a few days prior (and often again immediately after its released) to encourage users to exercise some restraint to give IT a little time to qualify it. This message serves another purpose though. It let's them know IT is aware of the update coming and will be looking at it as soon as possible. That way they don't think we are just clueless about impending OS releases.
Now, if users decide to ignore that very reasonable advice, go ahead and update immediately and face issues, its really their own fault. That's why its referred to as "bleeding edge"

There is also getting enrolled into Apple's beta programs so you can get a jump on testing these releases and not start testing them the same time it shows up as an available update on everyone's iOS devices.

[kitzy]

This message serves another purpose though. It let's them know IT is aware of the update coming and will be looking at it as soon as possible. That way they don't think we are just clueless about impending OS releases.

This is so important, thank you @mm2270.

[kauppila]

Well, for us it is more of a not wanting to interrupt some of the wireless network during times when our users are taking tests. I cannot stop the students from downloading at home, and in fact, I WANT the students to update their iPads. We just needed a little breather until we could do the update on OUR terms...

[bentoms]

This is just one of the challenges of being an iOS admin.

We updated a few devices to GM & enrolled into our MDM when they released a compatible agent (Friday), we have also tested the apps we care about & reached out to the vendors of them to get their wording on compatibility.

Yesterday, on our internal blog we posted an article on the release.. Advising that we have tested "basic functionality" & gave some upgrading advise. Primarily around backing up 1st & making sure apps are compatible pre-upgrade.

We have just under 900 iOS devices we manage, majority are BYOD but the others are COPE.

This approach has served us well for the past 2 releases too.

[McAwesome]

There's also the obvious reason of "The developer of the apps we need didn't release the updated version until the general public had access to the OS" that makes things like the beta builds irrelevant. You can't test compatibility with app updates that haven't been released.

I mean, I can think of a bunch of perfectly valid reasons why an IT department would want to block an update for a few days that don't apply to my particular situation. It's asinine to act like there's no good reason to want to do that. It's a feature that should exist at least for DEP devices, but Apple hasn't (to the best of my knowledge) implemented in iOS just yet. Hopefully this will be a feature of a future version, but I have no idea how you could submit a request for an obvious management feature like that.

Also, just repeating the questions but in an intentionally sarcastic way in no way actually helps anyone. Weirdly directly answering them does significantly more good.

[kitzy]

There's also the obvious reason of "The developer of the apps we need didn't release the updated version until the general public had access to the OS" that makes things like the beta builds irrelevant. You can't test compatibility with app updates that haven't been released.

Exactly, which is why communication and education for end users is so important.

Also, just repeating the questions but in an intentionally sarcastic way in no way actually helps anyone. Weirdly directly answering them does significantly more good.

I apologize if my tone came off as sarcastic, that wasn't my intention.

[milesleacy]

iOS updates cannot be blocked unless you take the "mobile" out of your mobile devices and force them to only use your network.

iOS 9 includes at least one critical security update that I am aware of.

The iOS 9 beta has been available since 8 June 2015.

Lack of readiness for iOS 9 today is an organizational failure that should be remedied by better planning for the next release.

I judge no one. These are simply facts.

[St0rMl0rD]

@milesleacy It's not always as simple as that. You know, when Apple released iOS 8 and OS X Yosemite, they broke the file compatibility of iWork documents. For example:

• we have 350 Macs and 800 iPads
• all Macs were running OS X Mavericks
• files, created in iOS 7 iWork versions were readable on iWork on OS X Mavericks
• after update to iOS 8, iWork apps were updated
• after that, files, created in iOS 8 iWork would NOT be readable on OS X Mavericks

So there's a bigger picture to consider in environments where there's more than 1 platform.

[iaml]

I think the point I resonate with most that underlies @kitzy's responses is that it is no longer acceptable for IT units/staff to simply withhold new technology "because we say so" or "because we haven't been proactive in testing it yet." If you have zero one-to-one devices to manage, it is still possible for IT to get away with being complete control freaks. But that is not the direction our professional work is headed. The quicker we can get to being facilitators instead of gatekeepers, the better.

I understand @St0rMl0rD's frustrating situation, especially in Education environments in the Northern Hemisphere, where Apple couldn't have picked a worse time to release OSes. But even in the situation he described, beta testing of Yosemite was possible, and there was nothing stopping him from upgrading a select number of stations to Yosemite to act as file conversion stations until Yosemite could be qualified for all Macs.

There are ways to operate successfully, whether you are a blocker or a facilitator. The question is: which do you want to be?

[milesleacy]

I tried not to make this the obligatory "let's argue about update methodology" thread that follows every OS release, but it seems I'm failing.

Everyone will have their own approach that works for them and their organization.

My approach is "use products in a manner consistent with their labeling." As regards Apple products, that means not second-guessing Apple. In my experience, I create more problems than I solve or prevent when Apple says "our way is X" and then I do Y.

Sure problems come up. I have found that it is better to solve the problem than to impede progress out of fear of the problem.

For those who have differing strong feelings on the topic, I am not going to engage in a back and forth here on which methodology is right or wrong. I will be glad to examine and discuss solutions for any technical issues discovered in iOS 9 and OS X El Capitan when it releases shortly.

[barnesaw · Accepted solution]

"Lack of readiness for iOS 9 today is an organizational failure that should be remedied by better planning for the next release.

I judge no one. These are simply facts."

Except for the judging, you are correct in that you judge no one.

Apple's updates routinely break stable, otherwise unchanged infrastructure. To suggest that not constantly re-jiggering your entire infrastructure to suit Apple is an organizational failure.... Well, that's the entitled attitude of someone who doesn't have as diverse a support base as others, and in no way reflects on either's organizational failures.

That attitude, though, is one of pompous, self-righteousness and really makes one look like an unhelpful jerk.

I judge no one. These are simply facts.

[milesleacy]

@barnesaw I apologize if my refusal to engage in futile attempts to subvert Apple's procedures and technologies offends you. What you call pompous and self-righteous, I call dispassionate pragmatism. I've got no emotion invested here beyond the natural slightly hurt reaction to your verbal attack. Please stop that behavior. You may wish to refer to this page: Community Etiquette

I'll attempt to constructively address the technical item you alluded to...

To suggest that not constantly re-jiggering your entire infrastructure to suit Apple is an organizational failure....

A computer/device deployment is (ideally) a system in equilibrium. To expect to keep equilibrium after changing one item in the system but refusing to adjust other items is poor logic.

The fact is that iOS is what Apple says it is. Devices will get updated unless they are deployed in a Faraday cage. That is not something that you, I, or JAMF Software have the ability to change. I accept this and put my efforts toward designing the user experience within Apple's parameters.

[jillhughes]

We are wanting to block it during the day because it is killing our bandwidth. We need a way to do this efficiently, we would love for them to do this at home instead of schoo.

[jarednichols]

We are wanting to block it during the day because it is killing our bandwidth

Caching Server + (optionally) CacheWarmer.

Job done.

[bcampbell]

While I agree we should try to work within the guidelines Apple has setup (and we really have no other choice), I think some people are missing the fact that Apple's procedures and guidelines don't stay the same. Nor should they or they risk stagnation.

I was told when I took CMA training to not bother changing the device name on an iPad because users can just change it back. At the time, that was a fact. With supervised devices under DEP, device names can now be specified by the MDM. If folks didn't discuss this need and, instead, just gave up by saying something like "Apple doesn't allow us to do this then it shouldn't be done", then this change would probably have never been made. Obviously, there was enough of a legitimate need.

In the past, one couldn't restrict the App Store and allow users to install software from Self Service. I'm sure some people originally said that shouldn't be restricted either since Apple didn't provide the restriction. Well JAMF tried to help with that before Apple made it part of the API and now Apple seems to actually have a way to do that reliably with iOS 9. Again, Apple's current status quo has change for the better. (We currently choose not to restrict the App Store, but who can argue with giving educated, thoughtful people the option to do something or not?)

The ability to delay iOS upgrades seems to fall into that same category. Apple doesn't allow it now, but there are organizations who seem to have a good reason to do that. Suggesting (overtly or not) that people who want that are not doing their job or are ignorant in some way is being a little presumptuous that one understands all possible use cases and programs where iOS is being used.

I for one am tired of sitting on the edge of my seat every fall for the past three years wondering if I'm going to have to waste hours dealing with iOS upgrade issues during one of my busiest times a year because students don't want to wait (even though I ask them too and explain why) and software developers don't always have the apps fixed to work properly for a brand new OS even though a beta has been out. (iOS 8 was a nightmare last year.) We put iPads in the hands of about 500 students and teachers to help improve teaching and learning. I want and am supposed to focus my time on helping students and teachers find useful ways to use the iPad to improve teaching and learning not focus on restoring functionality that worked last week but doesn't now due to a bug, which I know will eventually be fixed. Apple's has become successful on exactly that; creating technology that is suppose to just work without messing with it.

As representatives for our end users, we need to keep pushing Apple to evolve. Discussions like this that can highlight examples of why stronger management would be useful are good, and I hope get to those who have some voice with Apple.

[milesleacy]

Your points are well made, but I think we'll have to agree to disagree on a few of them.

In my view, Apple have recently changed for the worse in that they have begun to give customers what they ask for rather than what they need. In the past, Apple made the correct technical decisions (most of the time), and the ecosystem had no choice but to follow. It's the same mentality that scrapped the floppy drive, adopted USB, firewire, and either embraced or dropped several technologies over the years because it was the right move forward regardless of whether customers didn't yet want the new or still wanted the old.

Device names are irrelevant on a technical level; the only benefits to managing device names is satisfying the OCD of a manager or as an attempt to manage a behavioral problem such as a user putting foul language in a device name. All are attempts to manage social issues with technology, which is a mindset doomed to failure. Restricting the App Store, outside of point of sale or other appliance-style deployments causes more harm than good. Making undesired behavior impossible is a poor technique both from an educational and a management perspective and often creates unnecessarily broad and detrimental technical restrictions for the good actors involved. I am disappointed in Apple for focusing on and delivering the irrelevant and detrimental just because people ask for it.

If app publishers don't have zero-day support for a new Apple OS, that's a failure on the developer's part. Apple makes developer previews available for this very reason... so developers can be ready on release day. A developer that isn't ready on release day is a developer and product that needs to be replaced in the deployment.

If a deployment is relatively closed, as is the case with point of sale devices, then they're relatively locked down and OS updates can be more easily delayed. These devices are not very useful beyond the single purpose they were deployed for. That's fine, and in fact desirable, given the use case.

On the other hand, with a broad one to one use case, any and every choice to depart from Apple's intended user experience has real costs measurable in time and opportunity lost to the user. I posit that the person/organization that thinks they have a better understanding of UX design than the industry-leading teams at Apple is being presumptuous and not slightly arrogant.

I believe as IT people dealing with Apple products, we should...

• Select, deploy, and promote products that follow Apple's development and user experience guidelines rather than standing up entire devOps teams to re-engineer bad products.
• Fire products and developers that don't adhere to a zero-day OS support policy.
• Enforce restrictions as an absolute last resort, rather than a first reaction.
• Participate in developer previews/betas and be ready with knowledge and infrastructure (Caching Server) for zero-day OS support in the organization.