this post was submitted on 10 Mar 2024
453 points (98.5% liked)
Mildly Infuriating
35493 readers
304 users here now
Home to all things "Mildly Infuriating" Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.
I want my day mildly ruined, not completely ruined. Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!
It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.
Rules:
1. Be Respectful
Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.
Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.
...
2. No Illegal Content
Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.
That means: -No promoting violence/threats against any individuals
-No CSA content or Revenge Porn
-No sharing private/personal information (Doxxing)
...
3. No Spam
Posting the same post, no matter the intent is against the rules.
-If you have posted content, please refrain from re-posting said content within this community.
-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.
-No posting Scams/Advertisements/Phishing Links/IP Grabbers
-No Bots, Bots will be banned from the community.
...
4. No Porn/Explicit
Content
-Do not post explicit content. Lemmy.World is not the instance for NSFW content.
-Do not post Gore or Shock Content.
...
5. No Enciting Harassment,
Brigading, Doxxing or Witch Hunts
-Do not Brigade other Communities
-No calls to action against other communities/users within Lemmy or outside of Lemmy.
-No Witch Hunts against users/communities.
-No content that harasses members within or outside of the community.
...
6. NSFW should be behind NSFW tags.
-Content that is NSFW should be behind NSFW tags.
-Content that might be distressing should be kept behind NSFW tags.
...
7. Content should match the theme of this community.
-Content should be Mildly infuriating.
-At this time we permit content that is infuriating until an infuriating community is made available.
...
8. Reposting of Reddit content is permitted, try to credit the OC.
-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.
...
...
Also check out:
Partnered Communities:
Reach out to LillianVS for inclusion on the sidebar.
All communities included on the sidebar are to be made in compliance with the instance rules.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.