How a Microsoft Teams Update reaches an End User

— This blog is part of a series of technical articles on Microsoft 365 products in general and Microsoft Teams specifically —

It may not be so exciting at first to know how the Microsoft Teams client stays up to date, but it can be very handy to understand the mechanics of updates and what’s going on behind the scenes when things don’t go as planned. As that is something we all know does happen at times.

In this blog we describe the steps and processes of Microsoft Teams updates and what you need to know about it.

Apart from the obivous reasons of getting new and improved features and obtaining bug fixes, having your Teams clients up to date is crucial too for being eligble for Microsoft support.

As a Microsoft customer we hopefully don’t have to tell you about the microsoft SLA and Modern Lifecycle Policy. But if you’re not familiar with it, we would recommend you to take a look, as it is important to know what requirements Microsoft has for supporting it’s own software.

There is a lot of information in this policy, but the crucial thing to know for the context of this blog, and what is often, overlooked is the following sentence:

“Customers must stay current as per the servicing and system requirements ….”

In other words:  if your Microsoft 365 applications (incl. Microsoft Teams; Outlook New; …) are not on one of the latest releases, you do not get support. What does that mean? Technically, they will not deny you support, but their first action will simply be to tell you  to update the Teams Client to the current release. They won’t look at anything else until you do, and that can be very frustrating when you are in a critical situation with your users.

Luckily, updating the Microsoft Teams client runs fully automatic in most cases, but to figure out why sometimes it doesn’t, it is important to understand how the update process runs.

Teams Updates run successfully in most cases. So, coming across a situation in which end-users are using an old version of Teams should be rare. That’s good, because it means that you comply with Microsofts lifecycle policy. However, automatic updates can fail as well, and do!

So, let’s look at how the update process run, as it will help you pinpoint potential risk areas and prevent issues in the long run.

The first thing to understand is, that the New Teams Client contains two elements: The Windows Application itself and the WebView2 component. Those two elements are crucial for Teams but each use a different update method. Mircosoft 365 apps, and therefore the Teams application, use the standard Microsoft update channel. WebView2, uses its own update procedure and schedule – separately from the update channel used by Microsoft 365 apps.

In this blog we will concentrate on the App update as that is where in general the problems occur.

Microsoft Teams (Windows App) is using the Microsoft 365 Apps update channel in combination with Delivery Optimization to help reduce bandwith consumption and network congestion. But Delivery optimization can be a tricky thing because you may have group policies in place that interfere with this service. Or you may use settings in which your end-user devices get their updates from other devices on the same local network (Peer2Peer). It’s therefore very important to plan and Set up Delivery Optimization correctly.

When does the update happen and how does the client know which version needs to be installed?

The windows App update check kicks in automatically each time the Teams Client is started, as Ms-teams.exe invokes ms-teamsupdate.exe.

It checks the Teams config service for the enduser by calling the following command:

Note!: the above url may look different depending on OS; Microsoft Ring and other variables.

The Client then gets a response back which contains the latest Teams version that is mandated for that user on that ring. This is then compared to the installed version. In the below example, version 24074.2321… for instance.

When the update process recognizes that the user is using an older version, it continues to pull the required msix app [FG1] [SF2] from the Content Delivery Network (CDN), and once done, it will silently install this version side-by-side to the existing Teams version.

As soon as this is done, the end-user gets a notification in Teams that an update is available. At this point in time, the C:\ProgramFiles\WindowsApps\ will contain the two installed MSTeams_* applications. The active one and the one which just got downloaded and silently installed.

By doing the side-by-side install, downtime for the user after he clicks on the “update button”, is kept to a minimum as the new version is already installed and just needs to be activated. After clicking the [Update] button, the new update is simply activated and the Teams Client restarts with the new version.

If, for whatever reason, the user decides to restart his device without clicking the „Update“ button, the update will be triggered as well, ensuring the update gets rolled out regardless.

The above is one way of how the update gets triggered. The other possibility is, that if the Teams Client is not being used (for instance when in idle/user is away mode), Microsoft triggers the update and restart of Teams automatically without having to bother the user with a notification.

Last but not least, there is a background tasks which checks every 2 hours (not only during startup of the client) if a new Version is available. So that users who notoriously never restart their system/Teams, still get updated. You can see this by opening the Teams logs:

And that is how Microsoft ensures your users are on the latest Teams version.

Hopefully this blog gives you new insights into what exactly is happening in the background when Microsoft Teams gets updated. We will dive into the things you should check when the process fails in a next blog!