As an IT guy, start a ticket.
Those update messages are likely from an automated system, and the updates are probably controlled by a completely independent system that nobody looks at regularly.
By submitting exactly what you did here as a ticket to the IT team, you’re pushing them to check in on those systems and approve updates that haven’t been approved.
Yes, it’s dumb. The updates should be automatically approved. Obviously they’re not, or something has prevented them from approving it.
Personally, as IT, if I get a ticket about this, I’d want to dig into why the update wasn’t approved and make sure future updates get approved without delay; solving both the immediate issue and all related issues in the future. However, if I’m not aware of the issue, I can’t really fix it. From their view, they likely only see a dashboard of all devices and yours (along with others) are probably flagged as needing an update. This is extremely common and probably entirely ignored under normal circumstances. Almost every one of the systems I administrate at work have updates that are pending. Either the system hasn’t been restarted (mainly desktops and servers and such) or, if it’s reliant on a user taking action, I assume the user doesn’t care enough about the update to bother running it… The idea that the update hasn’t been approved or that there’s a problem getting or applying the update, doesn’t even enter my brain as a possibility until someone complains. Simply put, I don’t have time to investigate every pending update that has not yet been applied. You’d almost need a dedicated person just to keep an eye on updates in order to keep on top of them, and nobody pays an IT person solely to look after updates.
So I’m busy fixing Debbie’s printer, and Joe’s scanner, and Frank’s email that’s slowing the date in that strange format again because he somehow changed his regional settings to the UK again…
Do your IT team a favour and send them this. I promise you that they’ll be grateful, even if they don’t seem like it. Bluntly, this is a perfect amount of information.
I get requests that range from “please call me when you have a chance” to “this specific function in this specific program is doing a thing that’s different from what I see on a coworker’s screen and I like how their screen shows it better because it reminds me of my grandchild’s grade 3 school play where they played a tree.” Ok Linda, thanks, I really didn’t need to know about little Timmy’s school play… Users either give us nothing, or way too much irrelevant data. So this image shows exactly what is required for a diagnosis. Either the messages will be stopped or the update will be approved.
If updates are approved automatically, why have a system where approval is required?
Because an iOS change might break existing corporate software? Just a guess.
That’s my point. Updates pose some kind of risk to something and so require approval before they’re allowed on a corporate owned phone. But the update approvals are just automated, so…
If updates are not automatically approved, then why does the notification system alert users of updates that can’t possibly install?
For me the problem is either A or B.
On the “A” side, the update should be approved and able to be installed.
On the “B” side, if updates need to be manually approved, users should not get notified about it until after approval has been granted.
Clearly, neither is what’s happening to OP. So someone needs to change something.
Someone needs to change something, this is exactly the purpose of opening an IT ticket.
Agreed.
On the face of it, option B would seem to be clearly better, but I’m just trying to understand how an approval system can work if it automatically just approves things, that sounds more like slight delay system than an approval system. Maybe I’m misinterpreting, the way I was reading it sounded something like “the process of approving updates would be cumbersome and time consuming for humans to do, that’s why the process of calling things approved is automated” but perhaps what you were saying is the “the process of evaluating whether approval should be granted is automated and done by software that can figure out if the update will or won’t cause problems and then either does or doesn’t approve depending on the evaluation” which sounds great, but I just didn’t think that was actually a thing that could be done by software. Is that actually how it works? There’s software that can determine if OS updates to phones does or doesn’t cause unexpected problems with an entity’s existing systems? I just thought for sure you’d need a human to do that given how hard it is to define a ‘problem’ and how specific the needs of an enterprise would be.
If my initial understanding was correct, that the software just does the job of ticking ‘approved’ for you, so you don’t have to tick it yourself, then I am completely at a loss in understanding how that is any better than simply having no approval process and just allowing updates without oversight since it’s functionally the same, except a little bit slower (albeit only a little slower because it’s automated).
Given that the op is taking about an apple device, Apple has made their own mobile device management system (MDM) for their devices. Within that MDM you may, or may not be able to set that updates are automatically approved. I’m not certain as I have limited experience with their MDM. I have used it in the past, but only a very small amount, and never in-depth enough to deal with how that MDM handles updates, or what options are available.
I know from my experience with other remote monitoring and management systems that you can often, especially with Windows, specify some clarifications of updates to automatically approve, or do so manually. It is up to the administrator. You can set the approvals to be automatic for all updates too… Or, when doing manual updates, you can approve updates for a group of computers, or one computer, or all computers. I imagine much of this is also available from Apple’s MDM.
The approval only gives the end user the ability to install the update. Due to the disruptive nature of updates, it is generally up to the end user to finish the process at their convenience. Updates usually involve a system restart, so the thinking is to allow the user to pick when specifically to install it, to minimize disruption to their work.
Some organizations with the IT resources to do so, will approve a batch of updates to a group of test devices (usually the IT staff, if there’s no pool of devices that are dedicated to testing), where all applications are run through testing after the update. These unit tests, if you will, are usually designed to give an idea if the update has caused any issues with the software that the users need to use. Not all organisations have the resources to do this, and usually rely on third party testing (usually reports from companies that do this sort of testing, or complaints from the public), and will simply approve the update after a duration of time after it has been available for more than a week or month without complaint.
Every organization is different in this respect.
At the same time, the monitors that inform the notification system may not be aware of the approval status of the update and simply see that an update is released, and that the user does not have it installed. This may be an issue with reporting (eg. The update is installed and it’s working with outdated information), or it could be any number of other factors.
It’s likely that the MDM and update monitoring are done by completely unrelated systems, unaware of what the other is doing, or what has been set.
In the A scenario, going into the MDM and setting automatic approval would fix the problem. By the time the monitoring solution is reporting and notifying the users about an update, it is available to them.
The B scenario, on the other hand, may not even be possible, as it relies on a link from the monitoring system into the MDM to know if an update is approved. If such a system has the ability to set which version all users should be updated to, then when the update is approved, then the version of software that should be expected on the device can be set to a minimum level and notify the users if they are below that level.
The unit tests are usually done by hand, so the outcome can be evaluated immediately. Rather than rely on an automated system for testing, which may not recognise that a failure has occurred if it is an unknown or unexpected error.
Yes, B is preferred, but not always possible. Often with MDM, you cannot exempt a single system from MDM control for updates, depending on the platform, so usually approval is a required step, hence A being an alternative approach.
On the “B” side, if updates need to be manually approved, users should not get notified about it until after approval has been granted.
I work in corporate IT so I can entirely understand what’s happened to you.
The team that’s supposed to manage user communication doesn’t themselves actually know what’s going on so they just push out a notification whenever there’s an update and no one’s actually bothered to check whether or not that update is actually downloadable. Resolving this issue would require someone to actually care and no one really does so it’s never fixed.
Yep. I try to be the change. When I see something that’s entirely preventable, I try to invest the time, mostly for my own sanity, to correct the issue, and reduce the frequency of the issue.
I’ll put in small scripts on servers to quietly restart problematic services at 4 AM daily so that we don’t have to go and do it manually, I’ll develop login scripts and such that set a user’s environment variables to what they prefer, stuff like that… I’ll even run full systems reports from a remote PowerShell script running as an admin that emails me if anything isn’t as expected, so I can investigate long before the user even knows there’s a problem.
I’ve pushed for network monitoring by SNMP with sensible alerting, and often, I’ll sign in for the day and the first thing I’ll check is if any servers are down. Strangely, it’s happened.
I want to know about the problem before it’s a problem. I want to be able to fix that problem before anyone knows the problem exists.
It’s usually because updates will be automatically approved after a certain amount of time but not immediately. Usually because they’ll be some business critical corporate app and we have to make sure that the iOS update isn’t going to break it.
Apple do love breaking apps. Normally the app developers would get for warning of updates and be able to update their apps to accommodate but a lot of corporate apps won’t be run through the app store they’re just loaded in via some management tool (businesses get side loaded apps by all means). The corporate apps tend not to get any warning.
And all of the above is assuming that the app is developed in house which often it isn’t so you’ll need to hire a developer team to update the app, which again adds more time.
I’m not in IT, I’m an SE, but I do wonder if their system automatically approves minor updates but requires manual intervention to approve major updates?
Or maybe it provides the functionality for them to turn off the automatic approval if they’ve done testing while the update is in beta and discovered issues that need to be addressed?
Or maybe it’s just a crufty relic of a previous IT regime when they actually did have to manually update everything, but disabling that specific checkbox would cause downstream issues they hadn’t considered. Or it’s an edict of the management that they have approvals enabled, but they don’t care whether it’s automated or not.
In my experience all enterprise technology policy is basically just three Windows scheduled tasks in a trench coat, so I also wouldn’t be surprised if it’s all of the above.
Yep, they may not know what’s going on, there may be a bug in their system, either the update nag or the block on the new update may be incorrect.
I’ve had IT bug me about this at my company for the past several updates. For some reason their software never picks up that I’ve updated my machine, maybe because I literally do it only hours after the update has come out. Every single time I’m like “I’ve been on that version since the day it released. They then do something on their side and are like “oh it’s showing up as up to date now, thank you”… smh
Tell them to set up Watchtower on the dinky lil NAS they’re apparently running!
As an IT guy, half of the “missing update” garbage we see is because our reporting tools haven’t updated the status of the device since before the update was applied…
I blame developers.
Software nagging as a whole is mildly annoying for me. If, for whatever reason, I don’t want to follow whatever action it’s “suggesting” me to do, stop me bugging about it!
Also fuck off with the “MaYbE LaTeR :-)”. It’s simply “no”.
To be fair, most of the time those updates are trying to patch security vulnerabilities haha
Like iOS and Android both had a few critical CVEs a few months ago that were a really big deal since the vulnerabilities required no user input.
Anyway, those updates are pretty important more often than not and not just meant to annoy you :)
More important than what devs “try”, those patches do often address vulnerabilities…
…however, sometimes, shit breaks. It’s perfectly possible that a specific user does not want that patch, for multiple reasons:
- the patch is botched, the dev fucked up, and the user knows it
- the patch doesn’t even work on the user’s machine on first place
- the patch works fine, but it tanks the performance in an unavoidable way
- the patch introduces some bugs due to interaction with something else
- addressing the security vulnerability kills a feature that is more critical for that user than the security issue
- et cetera.
Devs have no way to know it. And they shouldn’t code software as if they did.
Furthermore, regardless of what they “mean”, this sort of nagging sends a message to the user, that they shouldn’t be allowed to choose the software of their own machines.
It gets worse! This sort of nagging is not present only for security patches. It’s every bloody where. Including things that clearly do not benefit the user, with data harvesting being just the tip of the iceberg.
I mostly agree with all of your points, but I think you’re failing to see the forest for the trees. The vast majority of users are ignorant as fuck about their tech. They couldn’t give a shit about anything other than their own convenience. If the devs allowed everyone to opt out if it meant no longer getting annoying messages, a huge majority of them would do exactly that, caring little for what that actually means in the long-term for their own security and others’ (yes, a vulnerable device is a danger to others, it isn’t always only impacting just that user).
So they opt for this collective, utilitarian approach, despite it meaning less user control. If you don’t like it, get an android device and root it. Again, I don’t disagree with your points, I just thought it worth pointing out the larger picture.
[Note for readers: my top comment was rather off-topic, as I focused on development. OP has two additional layers of complexity - IT bureaucracy and corporate environment.]
I don’t think that I’m failing to see the forest for the trees. I think that the key difference is that I’m not willing to give the stupid a pass to cause harm; and because of that I don’t think that devs should go out of their way to protect those [in your words] “ignorant as fuck” users, even if they’re the majority.
Once the devs provided the security patch, informed the user about it, and informed the user about the consequences of not applying that security patch (in clear and layman-friendly words), their job is done. Going past that to ask the user over and over about it, with no way to turn it off, is 1) patronising, 2) assumptive, and 3) belittling.
Exaggerating it a bit, it’s a lot like someone knocking at your door and asking:
- [Person] “If you have knives, I’ll get rid of them for you. You’re assumed to be too disgustingly stupid to not cause itself harm with them.”
- [You] “Sod off! I’m not getting rid of my knives. Also if I hurt myself it’s my problem, not yours.”
- [Person] “Ah, so you said «maybe later»! Ok! I shall visit you tomorrow and repeat the request. Remember, I care about you~”
If the devs allowed everyone to opt out if it meant no longer getting annoying messages, a huge majority of them would do exactly that
Advanced settings, sane defaults, and automatic updates exist for this reason. If the user is so ignorant that they’re unable to realise why they should at least consider to apply the sec patch, they’re also too ignorant to turn automatic updates off.
yes, a vulnerable device is a danger to others, it isn’t always only impacting just that user
Again, not the devs’ fault. The user shouldn’t be treated as something unable to be held responsible for the harm that it causes. And when they cause someone harm, they should be blamed.
That backtracks to the OP, with the IT nagging the user to update the software but not allowing them to do so. In those situations, the IT shouldn’t be acting like those shitty devs, who think “if you annoy the user enough it’ll obey you”; they should be asking the user/employee why they’re not updating their software, even if it causes a risk for the company.
I’ll use this analogy: Do you hate seatbelt reminders in cars? It’s the same concept. You’re putting a lot of trust in people that just isn’t going to work out well in the long run, as was seen with countless people continuing to ignore seatbelt safety for generations until it was forcefed into the culture. I view cybersecurity reminders the same way, where lots of people ignore it until it’s forcefed into the collective to be taken seriously.
Those who hate it because they already take it seriously, will just figure out how to quiet the alarms/notices and/or move on. Again, I get that you’re essentially saying, “but it’s the principle of the matter!” I just don’t think it’s that big of a deal, as I’d rather be comforted knowing that my friends and family who send me videos/pictures/random crap are doing so from a device that isn’t as likely to be completely compromised.
I’ll use this analogy: Do you hate seatbelt reminders in cars? It’s the same concept.
AFAIK the government that I pay taxes to doesn’t demand seat belt reminders. Instead it fines people for not using the belt. (I’m not sure though; I don’t own a car.)
That said, working with your example: the risk associated with not applying a security patch, on typical conditions, is way smaller than the one of not using a belt; one is at worst ransomware and personal data leakage, another is literally losing one’s own life (or worse, getting brain damage). So it’s apples and oranges.
Even then I think that my view is consistent between both situations:
- The devs / car makers should offer the reminder
- They should instruct users why that feature is there, and why it’s a bad idea to turn it off.
- Even then you should be able to deactivate that feature, if for some reason you want to do so.
- Trying to prevent the user / car owner from deactivating the nagging boils down to the devs / car makers stepping over their boundaries, assuming that the user is something lacking human-like rationality, and assuming that there are no reasonable motivations to do so.
- If the software user / car owner causes himself harm by deactivating it, that’s their problem. And if they cause damage for someone else, they need to be held accountable for it, no matter their “intention” (whatever this means).
You’re putting a lot of trust in people that just isn’t going to work out well in the long run
You’re assuming that I trust people to not fuck it up; I don’t.
Instead what I think that, if and when they fuck it up, they should own their actions, instead of effectively being a dead weight for everyone else. “Oh noes, I got a vyrus lol!!!1” - that’s their problem, not mine.
Those who hate it because they already take it seriously, will just figure out how to quiet the alarms/notices and/or move on.
A lot of times, there’s no way.
Or more specifically, if it’s a controlled IT environment and you rely on centrally vetted and controlled software updates (which makes sense in a lot of contexts), then, well, control them centrally.
As in, either they update on their own, or every weekend the devices stay with IT anyways and get updated.
I think this is an intentional design choice by Apple, to encourage users to complain to their IT departments and bully them into updating their device fleets. Apple likes it when more devices are on the latest version of their software.
Is that a flip iPhone or something? What’s up with the aspect ratio?
I think they just took two screen shots and put them together but with the one about iOS 17.3.1 being overlayed slightly on the other.
i placed the two screenshots side by side using the freeform app 😀
Two screenshots, should be an iPhone SE 2020 or 2022.
MDM is a scourge upon the earth
As opposed to completely unmanaged devices with software and hardware that I have zero idea what exploits are available for it?
If it’s because you’ve had some dumbass BYOD policy then that’s a you problem. I always tell my users to not put company policies on their private devices. On company devices, and especially government, I want my capacity to control my domain better.
To clarify: I’m not opposed to the concept of MDM, but the available solutions for implementing it are garbage. The MDM agent is one of the first things a nation state attacker goes after because it’s ubiquitous and usually worse code than the OS itself.
Exactly.
Also be aware that if you add an Outllook account to iOS, IT may be able to wipe your entire phone.
While you’re not wrong, and the only thing worse is possibly printers; just like printers, it’s a necessary evil.
It’s bluntly the only way to manage a fleet of devices. It sucks, but it’s required.
Better than nothing
