New Microsoft Teams releases do not overwrite old

[bezzoh]

I'm having an issue with each new release PMP is pushing out of the machine-wide Teams application. Obviously this isn't coming as an 'update' but as an application.  Unfortunately what I've just realised is that its detection method is way off and if it targets a PC with an older release, it says it's installed without actually doing anything.  I've had this issue when deploying manually in the past and had to completely edit how the detection methods work and set up supersedence. The PMP release does none of this..

Surely I'm not the first to come against this and wondered what workarounds people were using to negate this?

[Adam Cook (Patch My PC)]

Hey Bezzoh,

We have this documented on our known issues page.

Patch My PC utilizes the Machine-Wide installer for Microsoft Teams. The Machine-Wide installer uses the same MSI Product Code for all versions. This causes multiple issues concerning updates to the product as well as detection of new versions. Microsoft does not recommend updating the Teams MSI once installed (Microsoft Docs)

[bezzoh]

Completely get that this is a shocker of an application to maintain. The MS recommendation is a million miles away from my own thoughts, in an estate of thousands of computers it's just really not manageable, especially in a shared environment with multiple users on computers in an average day (Schools.)  So.. what I've found is that the auto-update for individual user profile isn't always reliable so I have set my own powershell to compare the exe versus that in the program files(x86) folder and force an update that way.  As my program files dir isn't up to date however, thats where the problems lie. Can't update it... without having a perfectly lined up supersedence path in SCCM, so I'm just wondering if anyone else has come up with a more innovative idea than what I'm thinking now, which is just overwriting the program files Teams folder periodically via Group Policy files...

[Adam Cook (Patch My PC)]

Your post did spark a conversation internally about supporting MSI detection to look at DisplayName and DisplayVersion, and not just the product code.

Today, if a product in our catalogue is an .msi, we default to always looking for the product code.

Since the Teams installer product code doesn't change, this is largely the reason I believe we don't support it as an update.

However, hopefully if can we add support for MSIs to check DisplayVersion, then we might be able to better support this product as an update. I know a couple of installers in our catalogue behave like Microsoft Teams.

Unfortunately I can not provide an ETA or even if we will do this.

I agree with your sentiment, though, that Microsoft recommendations are sometimes a million miles away from reality. This I think is one of them. Beyond the installer using the same product code, I can't think of any reason why anybody _wouldn't_ or _shouldn't_ patch the system-wide install of it.

I think I've seen instances before where if the Teams client is so old, it won't start. I think if it's so old, it can't update either due to the same check. A real chicken and egg problem. I'm not sure if this is a problem in the latest versions, maybe they fixed it, but I've definitely seen it before. Maybe a year ago.

[Darren]

Hi Guys,

Here's some scripts for uninstalling MS teams:
https://lazyadmin.nl/powershell/microsoft-teams-uninstall-reinstall-and-cleanup-guide-scripts/

(I personally haven't tested them, but they look promising)

[bezzoh]

This is something we might need to do given the latest update that MS Teams is now going to be rolled out as part of the MS Office 365 bundle. That will no doubt install it somewhere completely different and result in 2x versions on the client.

[cdnk3v]

I really think there should be some way to maybe add a prestart script in the PMPC deployment for Teams to remove and older version... or just remove the current version regardless.

The challenge with having an old version of the System-Wide Installer installed on a machine is any new user that logs in, will get that initial version, then when it launches, it will get an update (at some point).

Security scan software will pick up the System-Wide Installer that is out of date, and need to have it updated.

So if the PatchMyPC deployment of Teams did do a remove first then an install, that I think may solve the issue.

I also thought that the deployment would remove and install (not upgrade) the latest version, as we still have version 1.5 on our workstations, so a technician may log into a desktop for the first time, and it will install version 1.5, then they log out and never to log back into that machine, security scan software will detect this as out of date, and need it remediated, which means we have to rip it out of peoples profiles.

the PatchMyPC Teams installer would not solve that issue, but keeping the System-Wide Installer up to date may help a bit in those use case scenarios... the ones Microsoft doesn't bother thinking of or testing.

So I vote for PMPC to look into this as part of the Teams installer.

[Adam Cook (Patch My PC)]

I really think there should be some way to maybe add a prestart script in the PMPC deployment for Teams to remove and older version... or just remove the current version regardless.

The challenge with having an old version of the System-Wide Installer installed on a machine is any new user that logs in, will get that initial version, then when it launches, it will get an update (at some point).

Security scan software will pick up the System-Wide Installer that is out of date, and need to have it updated.

So if the PatchMyPC deployment of Teams did do a remove first then an install, that I think may solve the issue.

I also thought that the deployment would remove and install (not upgrade) the latest version, as we still have version 1.5 on our workstations, so a technician may log into a desktop for the first time, and it will install version 1.5, then they log out and never to log back into that machine, security scan software will detect this as out of date, and need it remediated, which means we have to rip it out of peoples profiles.

the PatchMyPC Teams installer would not solve that issue, but keeping the System-Wide Installer up to date may help a bit in those use case scenarios... the ones Microsoft doesn't bother thinking of or testing.

The Teams installer functions like most machine-wide installers; it installs its bits in Program Files or ProgramData, and creates a Run key or a scheduled task (triggered via user logon.)

As you've described in your post, when someone logs in, the user then gets Teams installed in their AppData (launched from the scheduled task). If the user doesn't login again, ever, then that AppData installation will never get updated and will show up on your security scans.

Microsoft don't provide a user-based Teams installer to patch the AppData bits. Their software is driven by this machine-wide installation and Run key / scheduled task methodology.

So I vote for PMPC to look into this as part of the Teams installer.

As much as I would love to solve this problem with the user-based installations, we don't create third party software installers. Vendors of their own software do - in this case, Microsoft. We automate the 'packaging' of them into ConfigMgr/Intune/WSUS.

On the topic of this thread (of being unable to make updates for Teams, and only base install apps), we have made good progress on adding support to detection scripts for software which do not change MSI product code with each update.

[cdnk3v]

Hi Adam,

Appreciate the comment. This is totally on Microsoft, and their packaging technics, and the fact that I am sure the community has screamed at them for how they have done this, it comes down to how they view the process and customers.

I do not expect you guys to fix Microsoft's issues (although you guys are a group of very smart and talented people), it is just the way it is (for now).

I look forward to seeing how you guys implement something like that, as I would really love to have the System-Wide installer updated on a regular basis... the user based installs is a totally different beast, and we just need to find creative ways to implement these things.

[Adam Cook (Patch My PC)]

Thanks, cdnk3v.

We plan to support it by adjusting our detection scripts to ignore product code (when told to do so, for edge cases like this) and explicitly look at DisplayName and DisplayVersion (which is how EXE detection works.)