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.)

[leeroy]

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.)

Wondering how this is going Adam? I appreciate and understand what you're saying about teams living in the users profile, but I need to update the old copy in program files, so that the 'source' installer is not a vulnerable version on my fleet.

Can I ask what you mean about the MSI code never changing? I thought from version to version, you want an app to maintain the same MSI code, so that it gracefullly replaces the old one when an install succeeds. I can't see what you mean by microsoft warning you not to update the machine wide MSI once it's installed - on this page? https://learn.microsoft.com/en-us/microsoftteams/msi-deployment#pc-installation

[bezzoh]

You really shouldn't have to worry about it any more. Just migrate to 'New Teams for Work or School' which is a WindowsApp and moves to C:\Program Files\WindowsApps\*  using a new directory for each version release - So that does mean you need to get your user shortcuts from 'shell:appsfolder'

[leeroy]

You really shouldn't have to worry about it any more. Just migrate to 'New Teams for Work or School' which is a WindowsApp and moves to C:\Program Files\WindowsApps\*  using a new directory for each version release - So that does mean you need to get your user shortcuts from 'shell:appsfolder'

I really, really dislike advice like this. Is there feature parity between new teams and classic teams? What if an organisation, lets just throw out a hypothetical, had users who were preventing your solution from working?

How about we just patch the version of teams that's used as a stub installer that lives in program files, while people handle their own migrations?

[bezzoh]

Frankly your like or dislike of what another might view as quite helpful advice is largely irrelevant. As the OP for this thread, I felt I was helpfully offering up how I myself have (very successfully) chosen to deal with this issue after being the person asking for the advice initially. (As a sidenote, I never told any other poster I didn't like their comments. I'd probably feel quite rude doing so.)

For info.. just because I can't help myself.. the new Teams app has the same look and feel of the old. On Windows 11 in particular its pretty seamless as it seems far better at simply maintaining itself, and I no longer have to keep replacing the exe and json in the old Teams installer directory which I was doing previously.  It seemingly removes all of the hassle and admin-overhead of having to maintain the application entirely and above all you know what its like once Microsoft decide they're going in a new way with an application/OS, etc... you've just got to suck it up really and not keep trying to flog a dead horse as they say in trying to keep an older version ticking over.

We all have problematic users, and I completely get that all organisations are different and have their own challenges, but I'm a firm believer in (obviously where possible due to technical considerations) not allowing the users to lead on progress. If something is going to make my (and my teams) jobs easier in the long run, it's happening.. and the users will be told why in a polite but firm manner.

[Darren]

Bezzoh,

Thank you for your comments.  Your recommendation to move on the the new teams was very helpful!