Forum Discussion
How to have the Teams client update itself on share devices
I agree that's what the documentation says, however it's not true. There is no 28 day grace period, if you think about it doesn't really make sense "the clients too old to work with the service, but will be fine for 28 days". If you install a device wide installer then first login to that device more than 3 months later you'll see the blocking page (now). This didn't used to be an issue, as they didn't actually enforce the blocking, however since April 1st they have been, which is why we are starting to see issues.
Microsoft support will direct people here, they are providing a script that will update a machine wide installer, and optionally, flag users profiles to reinstall the package. There's also some useful background on the mechanisms at play.
lalanc01 Even with the machine wide installer you just end up with an installation in the users profile that will expire if it's been 3 months. Could you clear up old profiles from the machine every month so the user profile and Teams client don't become old?
While that might happen it shouldn't be any problem updating the client "..be too old to even be able to update itself."
"If you deploy an older version of the MSI package, the client will auto-update (except in VDI environments) when possible for the user. If a very old version gets deployed, the MSI will trigger an app update before the user is able to use Teams."
https://docs.microsoft.com/en-us/microsoftteams/msi-deployment#pc-installation
"Users on Teams desktop clients that are more than three months old will see a blocking page that gives the options to update now, reach out to their IT admin, or continue to Teams on the web."
"Desktop client versions that are more than three months old upon first install and/or first run of Teams have a 28-day grace period before encountering the above-mentioned servicing information."
https://docs.microsoft.com/en-us/microsoftteams/teams-client-update#servicing-agreement
I agree that's what the documentation says, however it's not true. There is no 28 day grace period, if you think about it doesn't really make sense "the clients too old to work with the service, but will be fine for 28 days". If you install a device wide installer then first login to that device more than 3 months later you'll see the blocking page (now). This didn't used to be an issue, as they didn't actually enforce the blocking, however since April 1st they have been, which is why we are starting to see issues.
Microsoft support will direct people here, they are providing a script that will update a machine wide installer, and optionally, flag users profiles to reinstall the package. There's also some useful background on the mechanisms at play.
StevenC365 Any idea why the docs are saying stuff not true? I can understand when the wording is incorrect but take the grace period as an example. Is it the simple fact that things update and being released too fast and the tech writers just don't manage it? How on earth should non-MVP's not having direct contact with the engineers / product teams now things like that? I mean if you hadn't replied here I and others would go by the info in the docs (until noticing something is wrong). Just asking 🙂
ChristianBergstrom I get this from raising issues with Microsoft support, nothing to do with MVP contacts, also support were going to raise a request to have the article updated.
Maybe it was correct at one point, hard to say. Before April 1 the 3 month limit on clients wasn't enforced so we never saw this type of issue.
- Ah.. the Docs at it again 🙂 I'll take that info as I don't work with deployments. Thanks! Actually I've been providing feedback via GitHub to the Docs lately, but kind of feel it's getting overwhelming as I stumble across all sort of "unclear" documentation. But a couple articles has been updated though!