I have a number of VS installations split between Professional and just Team Explorer depending on workstation role. I've successfully kept them updated through the Visual Studio Installer for a little while and recently reconfigured our environment to allow users to update the application themselves following guidance here:
https://video2.skills-academy.com/en-us/visualstudio/install/configure-policies-for-enterprise-deployments?view=vs-2022
I was able to determine that setting this reg key via GPO was successful. This GPO set a single key, "AllowStandardUserControl" to 1, allowing regular users to kick off updates when they close out of VS.
Interestingly, it appears to have caused an issue on all but one specific machine. My very first test machine - an agile seat usually unoccupied - was able to have a regular user log in and successfully update the Team Explorer instance on it. However, every single other workstation in my environment was no longer able to update, indicating a failure of either "Sorry, something went wrong" or "Sorry something went wrong unable to download the channel manifest from https://aka.ms/vs/18/release/channel". What's more, this also prevented my administrator account from updating as well.
At first we thought this might have been connectivity related there is no evidence to support that - indeed the next day the one working machine was able to get a new 7.9.1 patch while the others remained failing. Further, someone online suggested that the VS Installer was outdated, but updating it manually on a failed machine got us nowhere.
When I rolled back the GPO and deleted the key, I was able to update as an Administrator again (and naturally users were blocked from doing so). In this case it appears that setting "AllowStandardUserControl" is not having the desired effect. Does anyone have experience setting this up, and has anyone encountered issues such as these either way?