question

@Franois-0770,

Updating Teams client with machine-wide installer is not supported now.

Once you have installed Teams on your computer, there are two ways to update the desktop client. One is to update itself automatically, another is to manually download updates by clicking Check for updates on the Profile drop-down menu on the top right of the top.

The MSI file is mainly used to broad deployment of Teams client.

For more information, please refer to this article.

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

We are in a similar situation. We pushed out the Microsoft Teams Machine-wide installer to 1,500 PC's in our organization. The deployment was disappointing to begin with, in that all the installer does is create a Teams Installer directory under program files and then copies the installer (approx 100mb) to every single logged in user, which chews up the hard disk for multi user devices).
We've only just noticed now, that despite us pushing out version 1.3.003564 in the initial rollout, the end users were only receiving the updated Teams to their local profiles, so the initial installer is never updated due to being in a locked down environment.
We are now starting to get users who log into PC's for the first time and get prompted about not being a updated version and click here to update, which takes them to a download link for Teams. This will not install for all users as it requires elevated credentials which end users do not have.

Today I started working on a script to push out the new version only to find out that when we run:
"\\server\share\msteams\Teams_windows_x64.msi" ALLUSERS=1 /norestart OPTIONS="noAutoStart=true" (which was the initial script with /qn added for quiet mode) we get the error:
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use add/remove programs on the control panel.

That would be fantastic, except for the fact that Teams does not uninstall when doing this, nor does it uninstall when using the uninstall string from the registry with the /x option:
MsiExec.exe /I{731F6BAA-A986-45A4-8936-7C3AAAAA760B}.

I've also tried extracting the Teams.exe and setup.json files from the MSI and just dumping them in C:\Program Files\Teams Installer and my existing version does not update via this as it's searching online.

In writing this, I've just discovered that running the Teams.exe from the above directory has just kicked me out of Teams and performed the update on my profile installation. I guess I'll try and also push the update.exe file to all users and see if that works.

@BrianGe-5506 I have the exact same issue as you, we have a wide range of versions when we first deployed the Machine installer, and are running into the issues where a new user signs in and the app wants a update.

I also tried the same thing as you - installing the latest version of the machine wide installer, and of course it failed with the message you got

The other day a new user signed in got the update message, so we let it download from the web, it installed, Teams launched but did not connect to their work account.

I'm going to try the idea of uninstalling the machine installer (with existing user Teams already installed), then re-install the latest version and see if it breaks anything.

Not sure how else to do this, I have to keep these installers up to date or I'm going to get a lot more of these issues with new users.

Anyone else??? - how do you handle this?

The trouble is, Teams is updated very often, so trying to keep the Machine Wide Installer up to date on all devices is a big challenge with a big administrative overhead.

Since running the updated Teams.exe on that test PC, a new login to that PC has resulted in an updated Teams. I'll be back to work on Tuesday, so will be doing more testing before writing up a script to redeploy.

Something like:
If exist c:\program files (x86)\Teams Installer\Teams.exe and version = 1.3.003564 then
copy Teams.exe and setup.json files from \\server (64 bit version)
If exist c:\program files\Teams Installer\Teams.exe and version = 1.3.003564 then
copy Teams.exe and setup.json files from \\server (32bit version)

It's still unclear if running Teams.exe manually once updates the application for all users of the PC, so that will need some testing. If it does, we can just add an extra line into the script after the files are copied to simply launch Teams.exe, if it doesn't we will have to also add to the User login script to update the files on their profile.

Here's a PS1 I've just whipped up, still needs some more testing on site, but so far it seems to be what I want. I've modified the script that we initially used to push Teams, so it'll also do the install on a new client along with an update if required:

$TeamsExist_64 = "C:\Program Files (x86)\Teams Installer\Teams.exe"
$TeamsExist_32 = "C:\Program Files\Teams Installer\Teams.exe"
$64Exists = Test-Path $TeamsExist_64
$32Exists = Test-Path $TeamsExist_32
If ($64Exists -eq $True) {
$64_Ver = (Get-Item "C:\program files (x86)\Teams Installer\Teams.exe").VersionInfo.FileVersion
If ($64_Ver -eq "1.3.00.3564")
{xcopy "\\server\share\msteams\Teams_x64.exe" "C:\Program Files (x86)\Teams Installer\Teams.exe" /Y}
}
If ($32Exists -eq $True) {
$32_Ver = (Get-Item "C:\program files\Teams Installer\Teams.exe").VersionInfo.FileVersion
If ($32_Ver -eq "1.3.00.3564")
{xcopy "\\server\share\msteams\Teams_x32.exe" "C:\Program Files\Teams Installer\Teams.exe" /Y}
}

If ($64Exists -eq $False -and $32Exists -eq $False) {
if ((gwmi win32_operatingsystem | select osarchitecture).osarchitecture -eq "64-bit")
{
#64-Bit install
Start-Process msiexec.exe -Wait -ArgumentList '/I \\server\share\msteams\Teams_windows_x64.msi ALLUSERS=1 /qn /norestart OPTIONS="noAutoStart=true"'
}
else
{
#32 bit Install
Start-Process msiexec.exe -Wait -ArgumentList '/I \\server\share\msteams\Teams_windows.msi ALLUSERS=1 /qn /norestart'
regedit /s "\\server\share\msteams\IMProviders.reg"
}
}

Here's what I ended up doing:

This is a batch file I run on the computers with a lower version (but is also based on the Uninstall string of the installer)

@echo off
set THISDIR=%~dp0
rem Forces the machine wide installer to re-cache itself using the new msi version. Caches to: (C:\Windows\Installer)
msiexec.exe /fv "Teams_windows_x64.msi" /qn
rem Forces the machine wide installer to re-install itself based on the new cached msi
msiexec.exe /f "Teams_windows_x64.msi" /qn

So in my case I created a collection in SCCM based on Teams installed with a version lower than 1.4.0.4167 and it needs to have the uninstall string of MsiExec.exe /I{731F6BAA-A986-45A4-8936-7C3AAAAA760B}

It does not affect users who have Teams already installed
It updates the Teams installer for any new user that logs in C:\Program Files (x86)\Teams Installer
It updates the existing version of Teams Machine Wide installer in Programs and Features

@BenjaminJohn-2954
I grab the latest Machine Wide installer v1.4.0.4167, then create a package and using a batch file to execute.

@echo off
set THISDIR=%~dp0
REM this command forces the machine wide installer to re-cache itself using the new msi from the sccm package. All installs of msi's reside here: (C:\Windows\Installer)
REM this command does not install anything,just updates the msi version in installer cache
REM the msiexec switches
REM /f (force) & v (Runs from source and re-caches the local package)

msiexec.exe /fv "Teams_windows_x64.msi" /qn

REM Forces the machine wide installer to re-install from the updated cache
msiexec.exe /f "Teams_windows_x64.msi" /qn

The machine wide installer has been updated to 1.4.0.4167 (use to be at 1.3.0.12058) & C:\Program Files (x86)\Teams Installer\Teams.exe is updated
This does nothing to any user that already is using Teams
The other thing I did is grab a report showing me all of the Machine Wide Installers and showing their unique GUID
...part1

The solution for me at least was to update my O365 deployment repository.
Only my new deployments on 20H2 were having unwanted teams update appear
and all manner of messing with the teams machine wide installer just went down a
deep rabbit hole. The only other tweak I had to make was to add a reg hack to
stop the AAD nag to the user.

Given teams is now included within O365 and the teams machine wide installer appears to be unsupported
on later Win10 builds, I think this is probably your best way out.