Teams is a client, rather than a standalone application. That client needs to keep in sync with the central shared service that it's talking to, so Microsoft currently have it update every 2 weeks (sometimes less). This allows the pace of continuous development and feature release of the product. I'm sure you'll probably acknowledge that when 'enterprise' scale testing and deployment processes get involved they slow things down, e.g. choosing Semi-Annual office app updates. This old model used to be how Skype for Business worked, and it became hugely slow for new capabilities like VBSS to get to widespread deployment, years rather than weeks. It's just not viable for a modern product in a competitive market.


I think it's fair comment that storing applications under %userdata% isn't good practice, and other frequent self-updating apps like OneDrive, Chrome etc. manage to do it in Program Files by installing an agent as an admin to overcome locked down user accounts. There was originally a plan that Teams would eventually become a UWP app deployed and update through the Windows Store, but when the strategy around Edge changed to Chromium that took a backseat. I work for a company with 500K Teams users, it's not ideal, but really it doesn't cause much issue to get it to just look after itself.