Teams Desktop App Not Auto updating

[IT_Man_Dan]

Morning all,

 

We have Teams desktop client installed as part of O365 Apps that we install on Win 10 client machines when we image them.

It's been brought to my attention that our clients around the site are starting to show a message in teams saying something update update needed teams will stop working in 28 days.

 

Sadly I haven't seen this message myself as whenever I login as myself or a student user it hasn't come up for me. However my technician informs me that he's seen the message around site and various other staff members are reporting it.

 

It appears to be updating on my workstation as I don't get the message. However, one strange thing is when I click About > Version nothing happens and I can't see the version I'm on.

This leads me to think that something is blocked in my GPO's maybe?!

 

From my very brief research before looking on here I can see that an option would be pushing out the latest MSI although Microsoft do state you should uninstall old version first. Might try pushing the latest msi to a test client and see what happens.

 

Has anyone had any similar issues and if so have you managed to solve it?

 

Thanks

[mavhc]

Normally Teams installs itself per user, are you blocking per user installs, and/or blocking things in appdata?

[jtotheb]

From my very brief research before looking on here I can see that an option would be pushing out the latest MSI although Microsoft do state you should uninstall old version first. Might try pushing the latest msi to a test client and see what happens.

 

Yes, it will not install over the top/upgrade the existing Teams Machine-Wide Installer.

 

An odd quirk we found to it not auto-updating was rather than downloading the update exe, click your avatar top right in Teams -> check for updates and see if it finishes itself off.

[CHiLL]

It sounds like you deployed the MSI version of Teams - this version cannot and will not automatically update. I believe you can download and deploy a the new MSI every month or however often you decide to do it and that should work. However, I had issues with this, as it wasn't actually installing the updated MSI.

 

When a user runs the shortcut for the MSI version, it runs "C:\Program Files (x86)\Teams Installer\Teams.exe", which then installs a copy of that version of Teams into "%LocalAppData%\Microsoft\Teams". This causes a multitude of problems if you try and replace this MSI version with the normal EXE version.

 

I ended up removing the MSI version from all workstations and pushing the EXE version. Though, it also wasn't a straightforward process and I wanted to have as little disruption as possible. Also, despite the MSI is installed as 'User', the user cannot fully uninstall it. They can remove it from Apps & Features and also run msiexec /x to remove it - but it won't remove the folder from Program Files (x86), because the user doesn't have permissions.

 

So I created a GPO to delete that folder at system startup.

 

I then created a batch file that runs gpupdate /force to get that GPO and remove the folder and then executes a Powershell script.

The Powershell script checks if the MSI exists and removes it if it does. It then checks to see if the EXE version is installed in %LocalAppData% and also removes that.

Then it installs the latest EXE version from our network share.

 

This script was put on staff desktops and in the staff share, so they can run it at their convenience (otherwise forcing it may interfere with their lessons).

 

It was a complete ball ache, but it seems to be working.

Edited February 3, 2021 by CHiLL

[IT_Man_Dan]

Thanks @mavhc

I inherited these GPO's and they have caused a few issues previously which I'm trying to iron out. At some point I hope to create new GPO's but due to workload just haven't had chance.

 

Ok on looking through GPO settings briefly so far I can't see any gpo's set regarding windows installer prohibiting user installs and under software restrictions access to %userprofile%\appdata\Local\Microsoft\Teams\* is set to unrestricted.

 

My Technician has now been able to find a computer showing the message and when logged on as a user and you click download it downloads but then fails to run due to insufficient permissions. I assume this is because it's an exe file so that's the next thing I'm looking into.

[IT_Man_Dan]

I may be barking up completely the wrong tree now but have gone into software restrictions for staff and students and added an additional hash rule allowing unrestricted access to the MS Teams 64 installer exe.

[mavhc]

The teams.exe in Program Files is not the Teams.exe that's in AppData, the one in programfiles is an installer, that when run will install the real Teams into Appdata, aiui

[chazzy2501]

Phew, I made staff install from the website and never deployed in the end.

[jtotheb]

The teams.exe in Program Files is not the Teams.exe that's in AppData, the one in programfiles is an installer, that when run will install the real Teams into Appdata, aiui

 

Yup, my favourite Teamsism is that if you've installed the Teams Installer it just installs Teams rather than Teams actually being installed.

 

It's the Charlie Day red string meme come to life.

[DaveTheTech]

Yup, my favourite Teamsism is that if you've installed the Teams Installer it just installs Teams rather than Teams actually being installed.

It's the Charlie Day red string meme come to life.

I thought of the Xhibit meme:

 

Thankfully the only issue that we have had with installing the Teams client is that it looses a DLL file. This needs everything Teams to be uninstalled, which is a little annoying.

Why they started using AppData I will never know.

[Driftingashore]

When this happened to us, I ended up creating a supersedence rule in SCCM to uninstall the old msi installer, and then install the latest, though it I assume it should be pretty easy to script. Teams would update fine, but the msi creates a baseline version so if Teams were to be installed for a user, they'd get the version from the msi, which obviously ages. I'm just going to update the msi every now and again with more supersedence rules.