Teams Client Update Manuell

Diese Seite beschreibt die Möglichkeiten, das Updates der Teams Client nicht automatisch erfolgen zu lassen, sondern manuell zu beeinflussen. Beachten Sie dazu auch die Seite Teams Client Update.

Der Inhalt dieser Seite entspricht nicht der Empfehlung von Microsoft und ist keine Anleitung sondern das Ergebnis einer Analyse und Überlegungen zur manuellen Kontrolle der Teams Client Updates.

Spoiler: Man kann Teams auf verschiedene Wege die automatischen Updates abgewöhnen, aber sie sind alle mit Einschränkungen verbunden. Eine Steuerung nach Build-Nummern kann aktuell Microsoft aber pro Tenant machen.

Warum?

"Weil man es kann" ist vielleicht die falsche Antwort aber weil man es muss oder möchte lasse ich schon gelten. Klassische wird das Update des Teams Client komplett von Microsoft gesteuert und das funktioniert in den üblichen 99,9% aller Fälle Problemlos. Die Details zum Update-Prozess habe ich auf Teams Client Update ausführlich beschrieben. Aber vielleicht haben Sie auch die Seite Sonderzeichen in Userprofile gelesen, bei der ein Teams Update in einem Sonderfall zu Problemen geführt hat. Gründe für ein manuelles Update wären.

  • Eigene Qualitätssicherung
    Microsoft testet umfangreich die neuen Clients und rollt diese auch stufenweise auf Clients aus, so das bei Problemen das Rollout gestoppt werden kann. Aber jeder Kunde ist anders und vielleicht wollten Sie selbst auch noch mal testen.
  • Bandbreite
    Eine Teams Vollinstallation oder Update kann schon einmal 100-150 Megabyte Download bedeuten. An größeren Standorten oder bei schwachen Bandbreiten könnten eine lokale Quelle von Vorteil sein.
  • Terminal Server/VDI
    Microsoft schreibt selbst, dass auf Terminal Server/VDI kein automatisches Update erfolgt.

Sie können also sicherlich den Microsoft Teams Client auch so konfigurieren, dass er kein Update vornimmt und sie sich selbst um die Updates kümmern.

Ob das ein sinnvolles Vorgehen ist, sei dahingestellt. ich denke an die Probleme, die Firmen heute schon mit Updates auf vielen Clients haben und bin eigentlich froh, dass ich mich nicht auch noch um Teams Updates kümmern muss.

Automatisch oder Manuell

Wenn Sie nichts machen, dann prüft Teams ca. alle 4 Stunden bei Microsoft, ob die eigene Version noch aktuell ist. Wenn Sie dies nicht, ist, wird im Hintergrund das Update heruntergeladen und nebendran in einem Ordner "stage" bereitgestellt. Wenn der Anwender längere Zeit nichts macht oder den Hinweis am Rand bestätigt, aktualisiert sich Teams und startet neu. Wenn ein Client keine automatischen Updates für Microsoft Teams mehr bekommt oder installieren, dann muss ich mehrere Dinge von Hand machen:

  • Neue Versionen erkennen
    Microsoft sagt, dass keine Teams-Version älter als 90 Tage sein darf, wenn keine automatischen Updates genutzt werden. Ich muss also regelmäßig die aktuelle Version prüfen und ggfls. herunterladen
  • Inventarisierung der Clients
    Dann muss ich für jeden Client wissen, welche Version von Teams er nutzt um ggfls. ein Update bereitzustellen oder Probleme beim Updateprozess zu erkennen
  • Update verteilen
    Der dritte Baustein ist die aktive Aktualisierung der Clients, damit diese innerhalb des "Support Statements" von Microsoft bleiben
  • Autoupdate am Client deaktivieren
    Wenn Sie sicher sind, dass Sie die ersten drei Punkte gelöst haben, dann können Sie sich beim Client das AutoUpdates unterbinden.

Aktuell gibt es von Microsoft keine offizielle Beschreibung, wie sie das Autoupdate auf normalen Clients unterbinden. Nur für Terminal Server/VDI gibt es eine entsprechende Information. Für die anderen Fälle beschreibe ich weiter unten meine Analysen.

Es kommt also schon etwas Arbeit auf sie zu, wenn Sie keine automatischen Updates mehr verteilen wollten. Arbeiten wir die drei Punkte mal ab:

Prüfpunkt Erledigt

Neue Versionen erkennen

Von der Seite Teams Client Update wissen wir, wie der Microsoft Teams Client sich aktualisiert. Die gleichen HTTP-Anfragen können wir auch per Powershell ausführen und die entsprechende Version erkennen und zur eigenen Verteilung herunterladen.

PS C:\> Invoke-RestMethod https://teams.microsoft.com/desktopclient/update/1.3.00.34874/windows/x64

Inventarisierung der Clients

Vor allem dürfte es eine Herausforderung sein die aktuell installierte Version zu ermitteln. WMI-Anfragen liefert hier normalerweise nichts aber die Abfrage der Produktversion der teams.exe funktioniert. Bei der "per User"-Installation geht dies z.B. mit

(get-item "$($env:localappdata)\microsoft\teams\current\teams.exe").versioninfo.ProductVersion

Sie sollten daher schon prüfen, ob sie per Inventarisierung diese Information mit ermitteln können. Dies gilt natürlich nicht nur für den Fall, wenn Sie automatischen Updates unterbinden.

Update verteilen

Die Verteilung der Binaries ist nur ein Schritt. Das Update selbst muss nun so gestartet werden, dass entweder Teams diese selbst einspielt oder Sie Teams beenden und einfach eine Neuinstallation starten. Die Schritte dazu sind ebenfalls auf Teams Client Update beschrieben

AutoUpdate abschalten

Wenn Sie alle anderen Voraussetzungen geschaffen haben, dann können Sie anhand meiner Versuche einen Weg ermitteln, das Teams AutoUpdate zu unterbinden.

Dieser Schritt ist noch nicht abschließend geklärt und sicher nicht im Sinne von Microsoft

Einen dokumentierten Weg dazu gibt es meines Wissens nicht. Aber ich lasse Sie an meinen Entdeckungen teilhaben.

Vielleiicht finden oder kennen Sie einen "sicheren" Weg.

Teams settings.json

Auf der Seite  Clouds von Microsoft habe ich beschrieben, dass es nicht nur eine Microsoft 365 Cloud gibt, sondern sehr viele. Das erkennen Sie an verschiedenen Stellen und auf Teams Client Update habe ich die verschiedenen URLs schon festgehalten: Hier nur ein Auszug:

{
   "settings": {
      "serviceEndpointInfoMap": {
         "https://teams.microsoft.com": {
            "update": {
               "pds": {
                  "hostname": "https://teams.microsoft.com",
                  "endpointPath": "/desktopclient/update",
                  "params": "/{{appVersion}}/{{os}}/{{architecture}}"
               },
               "feServer": {
                  "hostname": "https://teams.microsoft.com",
                  "endpointPath": "/desktopclient/update",
                  "params": "/{{appVersion}}/{{os}}/{{architecture}}"
               }
            }

Leider habe ich noch keinen Weg gefunden, wie ich über eine Konfiguration im Teams AdminCenter oder per PowerShell hier einen eigenen Hostnamen setzen kann.

Regkey: IsWVDEnvironment

Auf einem TerminalServer kann man Teams "per User" installieren und aktualisieren lassen oder auf dem System als "per Machine" installieren. Dann sind aber keine automatischen Updates für Teams möglich, da ein Benutzer ja nicht das Programmverzeichnis aktualisieren darf.

With per-machine installation, automatic updates are disabled. This means that to update the Teams app, you must uninstall the current version to update to a newer version. With per-user installation, automatic updates are enabled.
Quelle: Install or update the Teams desktop app on VDI (https://learn.microsoft.com/en-us/microsoftteams/teams-for-vdi#install-or-update-the-teams-desktop-app-on-vdi )

Allerdings schreibt Microsoft dazu auch weiter:

Keep the Teams desktop app in your VDI environment up to date. Teams desktop app versions with release dates that are more than 90 days older than the current version's release date aren't supported. Unsupported Teams desktop app versions show a blocking page to users and request that they update their app.
Quelle: Install or update the Teams desktop app on VDI (https://learn.microsoft.com/en-us/microsoftteams/teams-for-vdi#install-or-update-the-teams-desktop-app-on-vdi)

Als Betreiber einer VDI/WVD-Umgebung sind sie hier also gefordert, das Update dann selbst zu verteilen.

Bedenken Sie aber auch, dass die MSI-Installation in einigen Punkten gegenüber der normalen Installation eingeschränkt ist. So gibt es keinen Wähltone da Teams davon ausgeht, dass ein ThinClient mit VDI die Audio-Signale am Server vorbei routet. Wenn ich Teams auf einem "Virtual Desktop" installiere, dann muss ich dem Client über einen Registrierungsschlüssel die Umgebung mitteilen. Die kann per PowerShell erfolgen: Funktionierst dies aber auch auf einem normalen Desktop?

New-Item -Path "HKLM:\SOFTWARE\Microsoft\Teams" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Teams" -Name IsWVDEnvironment -PropertyType DWORD -Value 1 -Force

Genauso gut kann dies aber auch per REGEDIT oder eine Gruppenrichtlinie erfolgen.

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Teams]
"IsWVDEnvironment"=dword:00000001

Ich habe diese Einstellung auf einem Windows 10 Notebook ohne VDI gemacht und geschaut, ob dies schon die Updates verhindert.

In meinem Fall hat diese Einstellung beim regulären Client nichts bewirkt. Die Updates wurden dennoch installiert. -> Keine Option

Update URL sperren

Ein Clientupdate beginnt immer mit einem Versionscheck, bei dem der Client (Stand Dez 2022) folgende URL mit seiner eigenen aktuellen Version anspricht und eine JSON-Datei zurück bekommt.

PS C:\> Invoke-RestMethod https://teams.microsoft.com/desktopclient/update/1.3.00.34874/windows/x64

Leider nutzt Microsoft hier den gleichen Hostnamen, den auch Teams generell verwendet. Hätte Microsoft hier einen anderen DNS-Namen verwendet, hätte ein Administrator die Namensauflösung per DNS, HOSTS oder auf dem Proxy unterbunden.

Das ist so nur möglich, wenn der Client über einen HTTP-Proxy muss, der auch HTTP-Verbindungen aufbricht und die angefragten URLs analysieren und verändern kann. Theoretisch wären auch lokale Produkte denkbar, die z.B. sich im Browser/Chromium/Electron einklinken und die Update-Anfragen unterbinden.

Dieser Weg ist sicherlich denkbar aber Bedarf der entsprechenden Umgebung, die nicht jede Firma hat. Auch ein Homeoffice mit Split-VPN ist eine Heruasforderung.

Update-CDN blocken

Wenn Sie sich die Antworten auf die Update-Frage anschauen, dann kommen alle Updates von einem Content Delivery Network, welches einen eingehen Hostnamen hat.

https://statics.teams.cdn.office.net

Diesen Hostnamen können sie im Netzwerk per DNS oder Firewall einfach blocken oder notfalls auch per lokalem HOSTS-Eintrag auf einen nicht erreichbaren Server routen.

Damit kann der Computer selbst zwar noch ermitteln, dass es ein Update gibt aber kann es nicht mehr herunterladen, wenn Microsoft das Verfahren nicht ändert oder ein HTTP-Proxy die lokale Namensauflösung umgeht. Dann sollten sie auf dem Proxy diese URL ebenfalls blockieren. Ich habe den Namen per HOSTS-Datei auf 127.0.0.1 gelenkt und folgendes im Logfile (gekürzt) gefunden:

Auszug aus %APPDATA%\Microsoft\Teams\logs.txt

-- info -- Browser Window HTTP: Download URL:https://teams.microsoft.com/desktopclient/update/1.5.00.26358/windows/x64? 
-- info -- Downloading Browser Window HTTP:x64.json 
-- info -- Browser Window HTTP: Resolving. Download completed for:x64.json 
-- info -- UpdateResponse: {"isUpdateAvailable":true,"nugetPackagePath":"https://statics.teams.cdn.office.net/produ..... 
-- info -- setUpdateDetectedTimestampIfNotSet: set to Thu Dec 22 2022 23:25:07 GMT+0100 (Mitteleuropäische Normalzeit) (1671747907084) 
-- info -- Downloading updates 
-- event -- eventpdclevel: 3, newAppVersion: 1.5.00.34874, status: success, ...
-- info -- Blur mainWindow window 
-- info -- Is foreground set to false 
-- event -- eventpdclevel: 3, deltaStatus: UrlUnavailable, statusCode: undefined, deltaErr: , newAppVersion: 1.5.00.34874, status: failure,...
-- info -- Downloading file from - https:// 
-- info -- Browser Window HTTP: Get Data HTTP with url:https://statics.teams.cdn.office.net/production-windows-x64/1.5.00.34874/Teams-1.5.00.34874-full.nupkg 
-- info -- Browser Window HTTP: Push url in request queue:https://statics.teams.cdn.office.net/production-windows-x64/1.5.00.34874/Teams-1.5.00.34874-full.nupkg 
-- info -- Browser Window HTTP: Download URL:https://statics.teams.cdn.office.net/production-windows-x64/1.5.00.34874/Teams-1.5.00.34874-full.nupkg 
-- info -- Downloading Browser Window HTTP:Teams-1.5.00.34874-full.nupkg 
-- warning -- UpdateDaemon: silent update is currently blocked 
-- info -- Focusing window 1

Der Client versucht ein Download aber am Ende steht ein "-- warning -- UpdateDaemon: silent update is currently blocked". Auf dem Client selbst habe ich aber keine Fehlermeldung und keine Warnung.

Wenn Sie dann aber "Teams im Browser" öffnen und über die Debuggingtools die Netzwerkkommunikation anschauen, dann sehen sie auch Zugriff auf das CDN:

Wenn Sie dann "statics.teams.cdn.office.net" blockieren, dann können Sie auch im Browser nicht mehr mit Teams arbeiten.

Irgendwie schade, dass die Fehlermeldung hier nicht darauf hinweist, welche URLs nicht erreichbar sein. Weiterhin ist es nicht ausgeschlossen, dass nicht auch der Teams Desktop-Client z.B. weitere Apps dynamisch von diesem Hots nachlädt.

Insofern ist es keine praktikable Lösung, diesen Hostnamen zu blocken.

Verzeichnis "stage" blockieren

Wenn ich den Download schon nicht verhindern kann, dann kann ich vielleicht die Installation verzögern oder gleich ganz blockieren. Auf der Seite Teams Client Update habe ich die Schritte genauer beschrieben, wie Squirrel erst die neue Version im Verzeichnis "stage" bereitstellt und dann die Verzeichnisse umbenennt. Als Benutzer und ein Administrator kann z.B. dieses normalerweise nicht vorhandene Verzeichnis einfach anlegen und gegen Veränderungen mit NTFS-Berechtigungen schützen, indem ich einen DENY:Change addiere:

In der Folge kann selbst ich als Benutzer erst einmal nicht mehr auf den Ordner zugreifen.

Der nächste manuelle Update hat zwar noch das Delta-NUPKT nach "Packages" geladen und die Installation versucht. Die konnte aber nicht erfolgreich sein und Teams mit der vorhandenen Version erneut gestartet. Im Log war zu finden:

Auszug aus %localappdata%\Microsoft\Teams\SquirrelSetup.log

Program: Starting Squirrel Updater: --update C:\\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
Program: Starting update, downloading from C:\\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
Program: About to update to: C:\\AppData\Local\Microsoft\Teams
CheckForUpdateImpl: Reading RELEASES file from C:\\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
ApplyReleasesImpl: No delta packages found. Applying current release package.
ApplyReleasesImpl: Found partially applied release folder, killing it: C:\\AppData\Local\Microsoft\Teams\stage
StashableFolder: TryMove from C:\\AppData\Local\Microsoft\Teams\stage-s1\
       ->  failed with non I/O error, will not retry: System.UnauthorizedAccessException:
           Der Zugriff auf den Pfad "C:\\AppData\Local\Microsoft\Teams\stage-s1\" wurde verweigert.
IEnableLogger: Failed to install package to app dir: System.Exception:
           Failed to delete the stash "C:\\AppData\Local\Microsoft\Teams\stage".
Program: Failed to apply updates, falling back to full updates: System.Exception:
           Failed to delete the stash "C:\\AppData\Local\Microsoft\Teams\stage".
CheckForUpdateImpl: Using existing staging user ID: <guid>
CheckForUpdateImpl: Reading RELEASES file from C:\\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
RegistryService: RegKeyExists: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Teams\ does not exist
ApplyReleasesImpl: No delta packages found. Applying current release package.
ApplyReleasesImpl: Found partially applied release folder, killing it: C:\\AppData\Local\Microsoft\Teams\stage
StashableFolder: TryMove from C:\\AppData\Local\Microsoft\Teams\stage-s1\
       ->  failed with non I/O error, will not retry: System.UnauthorizedAccessException:
           Der Zugriff auf den Pfad "C:\\AppData\Local\Microsoft\Teams\stage-s1\" wurde verweigert.
IEnableLogger: Failed to install package to app dir: System.Exception:
           Failed to delete the stash "C:\\AppData\Local\Microsoft\Teams\stage".
Program: Really couldn't apply updates!: System.Exception:
           Failed to delete the stash "C:\\AppData\Local\Microsoft\Teams\stage".
Program: Starting Squirrel Updater: --quitAndInstall Teams.exe
Program: Want to launch 'C:\\AppData\Local\Microsoft\Teams\current\Teams.exe'
Program: About to launch: 'C:\\AppData\Local\Microsoft\Teams\current\Teams.exe':

Squirrel findet das vorhandene "stage"-Verzeichnis und versucht es zu löschen.

"Found partially applied release folder, killing it: C:\\AppData\Local\Microsoft\Teams\stage"

Um dann zu erkennen, dass der Rename mangels Berechtigungen nicht gelingt. Squittel versucht sogar zweimal das stage-Verzeichnis nach "stage-1" umzubenennen, was natürlich auch nicht gelingt und Squirrel aufgibt.

Es funktioniert wohl auch, indem einfach eine Datei "stage." angelegt wird. Damit kommt Squirrel auch nicht klar und ohne "stage"-Verzeichnis kann kein Update gelingen

Dieser Weg erscheint mir aktuell am besten wobei manchmal der Client oben ein verfügbares Update anzeigt, was dann aber fehlt schlägt. Das könnte Anwender stören.

Regkey: AcuireSource

Bei jedem Update habe ich im Protokoll gesehen, dass Teams den folgenden Registrierungsschlüssel abruft:

Auszug aus %localappdata%\Microsoft\Teams\SquirrelSetup.log

2022-12-22 12:50:28> RegistryService: TryGetRegKey: HKEY_CURRENT_USER\Software\Microsoft\Office\Teams\AcquireSource does not exist

Könnte das eine Option sein, eine alternative Update-Quelle anzugeben? Ich habe per REGEDIT einfach mal einen Wert gesetzt

Beim nächsten Lauf von Squirrel hat er auch den Wert gefunden.

Auszug aus %localappdata%\Microsoft\Teams\SquirrelSetup.log

2022-12-22 14:50:28> RegistryService: TryGetRegKey: HKEY_CURRENT_USER\Software\Microsoft\Office\Teams\AcquireSource exists. Data - https://update.msxfaq.de

Nur vom Verhalten hat sich gar nichts verändert. Teams hat nicht mal einen Versuch gemacht, diesen Namen per DNS aufzulösen.

Ich wäre schon neugierig, welche Funktion diese Einstellungen haben kann, aber auf eine Update-Steuerung konnte ich keine Wirkung ausmachen.

RELEASE spoofen

Eine bei Squirrel wichtige Datei hat den Namen "RELEASE.", in der die verschiedenen Versionen mit ihrer Größe hinterlegt sind. Laut Beschreibung sollte Squirrel die "RELEASE"-Datei aus dem zentralen Repository herunterladen.

Check for Updates - the RELEASES file at the distribution location is downloaded and compared to local RELEASES file to check for any updates.
Quelle: Squirrel Windows: Update Process https://github.com/Squirrel/Squirrel.Windows/blob/develop/docs/using/update-process.md

Sie wird auch im Log protokolliert:

Auszug aus %APPDATA%\Microsoft\Teams\logs.txt

2022-12-22 14:24:24> Program: Starting Squirrel Updater: --processStart 
Teams.exe --process-start-args --profile=AAD
2022-12-22 14:24:24> Unhandled exception: System.IO.FileNotFoundException: Die Datei "C:\\AppData\Local\Microsoft\Teams\packages\RELEASES" konnte nicht gefunden werden.
Dateiname: "C:\\AppData\Local\Microsoft\Teams\packages\RELEASES"


-- info -- Browser Window HTTP: Download URL:https://statics.teams.cdn.office.net/production-windows-x64/1.5.00.33362/RELEASES
-- info -- Downloading Browser Window HTTP:RELEASES.txt
-- info -- Browser Window HTTP: Resolving. Download completed for:RELEASES.txt

Theoretisch könnte man administrative eine RELEASES-Datei mit einer viel neueren Version auf jeden Client legen und diese gegen überschreiben schützen. Dann sollte der UpdateAgent kein Update machen. Das Update könnte man dann wieder gezielt über eine Anpassung der Daten und ein manuelles Update durchführen.

Diese Option habe ich aber noch nicht getestet, da sie mir aufwändiger und fehleranfälliger erscheint.

notManagedDeployed

In Logs.txt habe ich auch noch einen Wert gefunden, der ebenfalls einen Hinweis auf "Managed" gefunden. Bei mir steht da ein "type: notManagedDeployed". Ist das ein Hinweis, dass es noch weitere Deployment-Möglichkeiten gibt?

Auszug aus %APPDATA%\Microsoft\Teams\logs.txt

-- event -- eventpdclevel: 3, distSrc: default, source: exe,
                              type: notManagedDeployed,
                              launchPath: %LOCALAPPDATA%,
                              isUserInvoked: true,
                              isLoggedOut: false, bucketId: 6,
                              regularJitter: 3632479,
                              hotfixJitter: 1816245,
                              staggeredV2: true,
                              policy: false,
                              correlationId: 3ffd277b-a89e-4945-bc1b-acde73e50b34,
                              endpointSource: pds, route: https://statics.teams.cdn.office.net/production-windows-x64/1.5.00.33362/RELEASES,
                              scenarioCode: 2,
                              newAppVersion: 1.5.00.33362,
                              isDowngrade: false,
                              updateStatusReason: undefined,
                              distribution: FULL,
                              sizeInBytes: 137461385,
                              signedUpdates: ignore,
                              count: null,
                              status: success,
                              scenario: 771ef2b5-7c62-4b42-b4b2-682b3371bdbc,
                              scenarioName: desktop_update_download,
                              name: desktop_update_download,
                              step: stop, sequence: 1, delta: 7814, scenarioDelta: 7814, elapsed: 68607, stepDelta: 7814, Scenario.Mode: 1,
                              AppInfo.Language: de-de, complianceEnvironmentType: 0, isDataCategorizationEnabled: true, userpdclevel: 0,
                              processMemory: 20747028, freeMemory: 8060956672, clientType: desktop,
                              AppInfo.ClientType: desktop, batterylevel: 0.89, pluggedin: true,
                              Window.Focus: foreground, windowIsVisible: true, Window.Status: maximized,
                              UserInfo.TimeZone: +01:00, vdiMode: 0,
                              Scenario.Name: desktop_update_download,
                              Scenario.Step: stop, Scenario.Status: success

Allerdings habe ich bislang noch keine anderen Quellen zu diesem Feld gefunden.

Solange ich keine anderen Deployment-Optionen kenne, ist dies auch eine Sackgasse

Gruppenrichtlinien

In den Protokolldateien ist gut zu sehen, dass Teams/Windows durchaus den ein oder anderen Registrierungsschlüssel liest und damit auch eine Steuerung der Funktionen per Gruppenrichtlinien möglich sein könnte. Also laden wir und die aktuellen Richtlinien zu Office Apps herunter und schauen einmal hinein:

Administrative Template files (ADMX/ADML) for Microsoft 365 Apps for enterprise/Office LTSC 2021/Office 2019/Office 2016 and the Office Customization Tool for Office 2016
https://www.microsoft.com/en-us/download/details.aspx?id=49030

Das ca. 12MB große EXE-File extrahiert einfach die ADM/ADMX-Dateien in ein anzugebendes Verzeichnis. Eine Suche in der ebenfalls mit abgelegten Excel-Datei liefert aber nur genau eine Zeile:

HKLM\software\policies\microsoft\office\16.0\common\officeupdate!preventteamsinstall

This policy setting allows you to control whether Microsoft Teams is installed with a new installation of Office or when an existing installation of Office is updated.Note: This policy setting only applies to versions of Office, such as Microsoft 365 Apps for enterprise, where Teams is installed with a new installation or an update of Office.If you enable this policy setting, Teams won’t be installed with a new installation or an update of Office.If you disable or don’t configure this policy setting, Teams will be installed as part of a new installation or an update of Office, unless you have used some other method, such as the Office Deployment Tool, to exclude the installation of Teams.
Quelle: Office ADMX: office2016grouppolicyandoctsettings.xlsx.

Hier gibt es noch eine große Dokumentationslücke zwischen den ADM/ADMX-Beschreibungen und den Schlüsseln, die laut Teams Protokolldateien ggfls. ausgewertet werden.

Automatische Teams-Updates kann ich damit zumindest nicht dokumentiert steuern.

Zwischenstand

Aktuell habe ich noch keinen zuverlässigen oder dokumentierten Zustand gefunden, mit dem ich auch auf normalen Clients ein Updates sicher und ohne störende Meldungen unterbinden kann, so dass ich mich manuell um die Updates kümmern kann. Selbst der Ansatz durch das "stage"-Verzeichnis zeigt beim Anwender immer wieder die Updateinformation an.

Letztlich wäre Microsoft hier gefordert, ähnlich wie bei Office 365 Apps einen lokalen Distributionspunkt zu erlauben, über die eine Firma zumindest optional das Rollout selbst kontrollieren kann. Der Updater liest ja heute schon Registrierungsschlüssel. Es würde also nichts dagegen sprechen, wenn eine Firma per Gruppenrichtlinie oder Intune Policies eine alternative Download-URL oder zumindest Versionskontrolle bereitstellen könnte. Nebenbei könnte eine Firma so auch eine Ansicht aller installierten Clients mit Benutzername, Clientname, Versionsstand und letzte Aktivität erhalten. Ich halte mal die Augen und Ohren offen.

Die Analyse zu dem Thema ist aber noch nicht abgeschlossen. Ich würde mich freuen, wenn Sie ihre Lösung und Herausforderung mit mir teilen oder veröffentlichen..

Weitere Links