Let admins manage updates
For corporate use please let stop automatic updates and user side updates.
Admins can deploy updates in a managable way
We are exploring the best way to ensure users receive the latest improvements to Teams while providing admins with more manageability.
Hi, What about this request ? We are global company with sites all over the world. Our sites mainly uses VSAT connexion with slow speed and we cannot let Teams manage the update, we need to be able to have a local cache to push the update localy or something like that.
I want to repeat the same theme just as the others have. I work in a company where We work in 53 countries and it’s not a mesh environment so you’re left with the lowest common denominator of a five meg link that kills an entire day because Teams decides to self update. It’s time Microsoft starts listening to its customers and understand that not everyone has North American Internet connectivity quality
Robert N commented
We need to be able to stop the updates because bad patches have caused problems and to ensure change happens in our non-busy seasons. It also helps with training and informing users of changes. .
We have 1000+ users in a VDI environment with Machinewide install and FSLogix and every day they pull nearly 100MB of WHAT ? This is ridiculous.
Mike Yam commented
It would be good to let IT Admin control a bit of updates. There is one scenario that make us frustrate:
We have a common computer in our meeting room. Our users will login with their own account and use it for Teams meeting. Sometimes if the user doesn't use the computer for a period of time. When the user signs in, he/she need to wait the Teams app to get updated, it can take a long time unless the user manually download it from MS website and install again.
any update on this one?
Shaun Wells commented
The ability to control updates is crucial in a financial institute, as we're governed by many controls and policies - Controlling what versions of software have been deployed into the Enterprise is critical to us.
Kanth Kolluru commented
Hi, Is there any progress on this? Auto update seems to have been compromised with a vulnerability identified where it can be tweaked to download package from any source instead of just Microsoft teams update packages. Being able to control the auto update behavior has become all the more crucial now.
Arti R commented
Hi any update on this would be very welcome.
Have the system save the up date till end of day and restart of computer.
The certificate used to sign the application changed last week and this impacted many users since we block executable files from running in the AppData folder structure except for trusted signed apps. Since we cannot control when the updates are executed, we can hardly update the trusted certificates list in advance making this security measure harder to manage.
Any update on this?
Jon Tydda commented
I do all my other MS updates via SCCM, why is Teams different? I want all my users to be on the same (approved and tested) version, not necessarily the latest version.
application white-listing + auto updating teams client is a killer.
Don't update auto make it as defualt ask before any update and if I want I can change it from settings
John Marques commented
does anyone have status on how to disable auto updates for MS Teams client?
echoing Ewald's comment
Ewald Bracko commented
Also I'd like to add:
Don't create an Teams application icon on the user desktop by default. This needs to be an administrative option.
Ewald Bracko commented
The best way to achieve this would be to install Teams into the %ProgramFiles% folder in general. Create an enterprise-specific install for that if necessary.
Use the user profile folders only to store user specific configuration settings and user specific temporary data like cache files.
Create and install a system service that handles the Teams Update. The Teams update mechanism should be limited to updating the central installation folder only and it should be avoided to do registry manipulations, especially not within the HKLM hive of the registry.
The Teams Updater service should first download the update package locally. Then it should check if any instance of Teams is running and delay the update process in that case for some minutes until doing a recheck. Updates should be deployed only if Teams is not being used on the system.
That way Teams will be well suited for any kind of business environment, even RDS and Citrix.