Recently I’ve ran into an issue with Microsoft Teams where the user sees a blocking message that says “Teams needs an update”. The user needs to action it before they can use Microsoft Teams again. Typically the user can just click on Update Teams which will take them to a download page for Microsoft Teams, they also need to pick the correct version of Microsoft Teams because now there are two of them.
Let’s have some faith in the user and say they do download the correct version, now they need to run the downloaded file and then it will update Microsoft Teams for them and finally they can use Microsoft Teams again.
That whole process isn’t a good user experience and that’s way too many steps. It’s worse if the user is in a rush because let’s say the system with the outdated version of Microsoft Teams is a meeting room computer and they are trying to load Microsoft Teams for their meeting.
There has to be a way to prevent this and a way to reliably fix the Teams needs an update problem. Here’s what I found in this rabbit hole along with the solutions I found.
The How
When the Microsoft 365 Apps (aka Microsoft Office) is installed then Microsoft Teams will be installed (unless you use a custom deployment). The method that the Microsoft 365 Apps uses to install Microsoft Teams is the bulk install method with an MSI. This method is also known as the Teams Machine-Wide Installer.
Typically the Teams Machine-Wide Installer method works perfectly fine when the system has just one or two primary users. The Microsoft Teams needs an update problem starts to show up if you have a shared computer.
A perfect example would be a meeting room computer or if you reuse a system for a new user. The issue is that the Teams Machine-Wide Installer is locked in time from when you first installed it.
Even if you update the Microsoft 365 Apps or run Windows Updates the Teams Machine-Wide Installer won’t get updated.
The Why
The root of this problems seems to be a few things. One of them being how the Teams Machine-Wide Installer works. It works by putting a copy of Microsoft Teams in Program Files and copies it over to the user’s %LocalAppData% folder the first time they log in and then considers it installed for that user. Here’s the Microsoft documentation about the process if you want to read more.
The version of Microsoft Teams in Programs Files will be the version that is the same age as the Teams Machine-Wide Installer version. Microsoft has a list of the version numbers and when they were released for Microsoft Teams here.
If the version of Microsoft Teams is older than 90 days from the most recent release of Microsoft Teams the user is blocked from using Microsoft Teams until they update it. You can read more about this in the Microsoft documentation about Teams for VDI. I think the reason that the information is in the VDI documentation is because in some VDI setups you can disable the Microsoft Teams auto updates which would eventually cause a similar issue.
We now know that old versions of Microsoft Teams will be blocked when they get too old and that the old version of the Teams Machine-Wide Installer isn’t helping with the problem as it keeps deploying the old version to new users.
Why does this only seem to happen on shared computers? The answer is due to the way that Microsoft Teams updates itself.
Microsoft Teams checks for updates every few hours and will download and update your version of Microsoft Teams automatically while your system is idle and does everything silently. The problem with this process is that Microsoft Teams is an %LocalAppData% program meaning that it is a per user program and not a per system program.
This means my version of Microsoft Teams can be newer than the version that the Teams Machine-Wide Installer installs and that another user on the same system could have a slightly different version of Microsoft Teams than me.
Due to the fact that Microsoft Teams is a %LocalAppData% program and that Microsoft’s documentation shows that a user needs to be logged in for Microsoft Teams to auto update. You can read more about the update process in the Microsoft documentation here.
We can now see why we would run into the Teams needs an update problem with shared systems especially with meeting room computers. If the user isn’t logged in Microsoft Teams cannot update and falls out of date.
The issue starts occurring more frequently the more users you have and the more meeting rooms you have. You can chalk this up to a probability problem due to the likelihood of the same user booking a meeting that they login for in the same meeting room in a 90 day window and that their account is idle long enough for Microsoft Teams to preform an auto update. Throw in the fact that Microsoft pushes Windows Updates every month and typically requires a reboot. Boom you have the prefect spawning ground for an annoying problem.
The Fix
If you uninstall the Microsoft 365 Apps and uninstall the Teams Machine-Wide Installer. Then when you install the Microsoft 365 Apps again a new copy of the Teams Machine-Wide Installer gets installed.
That doesn’t fix the issue for the users that have already hit the old version block of Microsoft Teams. You could tell the users to manually do the update but no one wants to do that. You could also just delete the user profiles on that system, but then that results in slightly longer initial login times and this is a meeting room computer and the users don’t have time to wait.
The Teams Machine-Wide Installer checks for something in the %LocalAppData%\Microsoft\Teams folder to consider Microsoft Teams as installed. I’ve found that by deleting or renaming that folder you can force the Teams Machine-Wide Installer to treat the user as if it was the first time they’ve logged in since the Teams Machine-Wide Installer was installed and that will trigger the Microsoft Teams install.
You can also download the Team Machine-Wide Installer directly (here is the download link) and you could just remove the old version of the Teams Machine-Wide Installer and install the updated one. Now the Teams needs an update problem is fixed for new users.
To fix it for existing users you can just delete or rename the %LocalAppData%\Microsoft\Teams folder for each users.
My solution was to make a PowerShell script do exactly that.
The PowerShell script will do the following
- Downloads the Teams Machine-Wide Installer.
- Checks for an older version of the Teams Machine-Wide Installer and uninstall it
- Kills any running Microsoft Teams sessions.
- Nukes out the
%LocalAppData%\Microsoft\Teamsfolder for any users that are found inC:\Users - Installs the updated version of Teams Machine-Wide Installer
Due to how the Teams Machine-Wide Installer works in order for this to be fully successful all users should log off of that system and login again or you can just reboot the system.
By doing all of this we can consistently update the Teams Machine-Wide Installer and deliver the updated version to all users on that system.
You can manually force the Teams Machine-Wide Installer to install for a user by running the following command as the user C:\Program Files (x86)\Teams Installer\Teams.exe --checkInstall
If you are having issues with Microsoft Teams not installing check this log file %LocalAppData%\SquirrelTemp\SquirrelSetup.log
You can find the script on my GitHub here https://github.com/thedxt/win-updates#teams-msi-update
