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 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.
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.
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.