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.