This causes problems for users logging on to a device for the first time where the copy in Program Files is old. We have seen reports from customers where Teams is blocked from launching by Microsoft if the copy in Program Files has not been patched in ~1 year. However, there is value in wanting to make sure the copy in Program Files is up-to-date in the scenario of shared computers. In my view, this provides little value and adds more confusion. If we ignored all of this and added Teams as an update anyway, you will more than likely see patch compliance reports telling you there's a mismatch for the version of Teams users' are running versus the one stored in Program Files. If a very old version gets deployed, the MSI will trigger an app update before the user is able to use Teams. If you deploy an older version of the MSI package, the client will auto-update (except in VDI environments) when possible for the user. To re-deploy the latest installer use the process of redeploying MSI described below. Microsoft's recommendation is clear on this, detail here in the second paragraph and pasted below: Do not use the MSI to deploy updates, because the client will auto update when it detects a new version is available from the service.
This is detailed herein the first paragraph. The user's copy in AppData is automatically updated by itself, independently of the copy in Program Files. This is because when a user first launches Teams, it copies the binaries from Program Files into the user's AppData. Once all copies are deleted in all user profiles, then we need to run the new MSI to update the system-wide component in Program Files. The process of updating Teams for all users on a system would involve a scripted action to recursively remove it from all user profiles on the system before running the MSI, as detailed here.
The reason for not supplying it as an update today is detailed below. This product exists in our catalogue today as an application, however not as an update.
0 kommentar(er)
