How are you keeping Teams Machine-Wide Installer updated?

[David Phillips]

Now that Message Center # MC245996 is going into effect, users with new-to-them PCs with older install dates of Office are starting to see the update screen with the Teams Upgrade button.  Since Office updates don't appear to keep the Teams Machine-Wide Installer updated, I'm wondering what solution you've come up with to keep the installer up to date. 

The current method of relying on the user to update isn't very enterprise friendly for an organization that typically prohibits software downloads.  Is anyone aware of anything on the roadmap for the Office updater to keep the Teams Machine-Wide Installer updated with a more recent version of Teams?

[#2]

I'm wondering this very thing.
I just ran into an issue with Microsoft Teams not auto-installing for new logins after upgrading Windows 10 1809 to 20H2. I found a post about a registry key having to be re-written post upgrade. I'm curious if having a newer machine-wide installer would have combated this without having to perform registry modifications. Is there anything unique that would cause issues if one were to re-deploy the latest MSI of the machine-wide installer out to machines which were detected with having it already installed? I feel like creating a application for such in ConfigMgr to attempt.
It's funny, I can't find much on this topic...

[#3]

We have a Premier case open on this one. Will update the thread when we hear more.

[#4]

@David Phillips Any word on this?

I'm getting mixed results when running the latest Teams MSI to update it. Sometimes it's the x86 installer, other times it's the x64. Both of them live under the "C:\Program Files (x86)\Teams Installer" directory.

Thanks

[#5]

@David Phillips did you get any answers from support?

[#6]

@David Phillips Also getting this issue. Any updates from Microsoft? Highly frustrating.

Currently looks as though we'll have to uninstall the machine wide installer and then re-install, as well as deleting user profiles. Really don't want to do this for several users as it's very counter-productive.

[#7]

We got this suggestion from them so far, but I'm not sure it's a Microsoft certified solution:
https://github.com/microsoft/TeamsMsiOverride

[#8]

I have another update. Microsoft Premier support has stated this is "by design", and has asked us to fill out a Design Change Request. I've asked them to check if this change is on the roadmap, and if it is not, I'll be filling this out. If you're a Premier customer, and you want this fixed, I suggest contacting Premier and doing the same.

[#9]

Great updates, the TeamsMsiOverride looks potentially useful (for non-cloud native/non-fully-saas environments and those who have file shares).

Out of curiosity, did you receive an answer from them about if it's on the roadmap?

[#10]

It does look promising, but we prefer a Microsoft solution vs. a community solution.

I have not heard anything since I filed the DCR back on 4/30.

[#11]

Oddly enough, at work we have been dealing with this very problem.  we recently switched away from Chromebooks and Chromeboxes to full windows 10 endpoints.  We are building MDT/WDS to maintain tight control over the OS/software stack on the endpoints.  in working on deploying Teams we have been dealing with trying to create a start up script that automatically creates firewall rules for a couple of exes that need to run.  Some of them run from appdata which is challenging to create a dynamic rule to account for the user appdata locations.  This is part of the reason we are looking at the machine wide installer for teams.
We are a Citrix house so we end up on their support sites doing research.  we already use the machine wide msi installer with the switches for: ALLUSER=1 and ALLUSERS=1 embedded in non-persistent VDAs.  patching this way is pretty easy for us in this scenario.  In prep for the further deployment of our windows endpoints we found this snippet over on the Citrix docs site:

"If You have Windows 10 dedicated persistent VDI environments. You want the Teams application to auto-update and would prefer Teams to install per-user under Appdata/Local, use the .exe installer or the MSI without ALLUSER=1 (I found the Citrix Doc under the title: Optimization for Microsoft Teams). 

We built out our MDT application package with the command:  

"msiexec /i Teams_windows_x64.msi OPTIONS="noAutoStart=true" ALLUSERS=1"

My hope is that all goes well and the UX would be:

1. Best case: automatic patching just happens user doesn't do anything.  

2. The end user selects the 3 dots and then select "check for updates" from teams and the application updates on its own.

[#12]

Has there been any update from MS on what the hell we are supposed to do here?

It's bonkers that they are now including the machine wide installer with Office, but then not keeping it up to date.

Almost all of our users are now being prompted to update Teams as soon as they log in for the first time, and there is no advice on MS's documentation page on how to keep the Office bundled machine wide installer up to date.

Why can't they do an ACTUAL machine wide install, and bundle it into C2R, so it can keep itself up to date in the same way Office does?

[#13]

@David Phillips any updates from Microsoft support?

[#14]

@David Phillips 

The solution that i came up with is to use a logon script.

The script utilizes winget to check for teams. Installs if required and upgrades if available.

I have pulled out all the logging since it contained network information so i would suggest you create some logging to check the scripts behaviour. 

I run it with a GPO against a Computer OU with a User configuration and loop back applied.

it has installed and upgraded teams litterally thousands of times and since its introduction we haven't had a single user log a ticket due to teams been out of date.

Hope it helps

function Get-WinGet {

    [string[]]$Teams = @(winget list Teams --accept-source-agreements | where-object{$_ -match "Microsoft.teams"})[0]
    [int]$count = @($teams.split(" ") | where-object{$_ -match "[0-9]"}).count
    Return $count
}

[string]$testpath = ($env:USERPROFILE + "\AppData\Local\Microsoft\Teams\current\teams.exe")


if(!(test-path $testpath)){

    #install if teams doesn't exist at all  
    [int]$int = "0"
     while(!(test-path $testpath) `
            -and `
            $int -lt 8){

                winget install --id "microsoft.teams" --accept-source-agreements
                #wait 10 seconds to allow settings to upgdate to ensure the winget list command works
                start-sleep -seconds 20
            if(test-path $testpath){
            } 
         $int++
        }

}else{
    #check if upgrade required

    [int]$teams = get-winget
  

        #update teams if it is out of date.
        if($teams -gt 1){
            winget install --id Microsoft.Teams
    }
}