Yay — we’ve started work on this!
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.
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.
This means especially: No install into the user profile folder!
User profiles are meant to hold user-specific configuration settings and temporary user data (like application cache files) ONLY!
Teams should store all user specific configuration settings either within a subfolder under %AppData% or within the HKCU hive of the Windows registry.
It also means: The admins need to have full control over the update cycles.
It's fine to update the application install folder as long as there are no registry manipulations involved and the updates are limited to that folder only.
However, the update mechanism has to verify that no instance of Teams runs at that time, otherwise the update process has to be delayed.