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.
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.
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…
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.
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).
If updates are approved automatically, why have a system where approval is required?
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.
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.
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.
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.
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).
Someone needs to change something, this is exactly the purpose of opening an IT ticket.