Neuer Teams 2.0-Client hängt bei Virtual Desktops/Windows 365

Wer den neuen Microsoft Teams 2.0-Client unter Azure Virtual Desktops/Windows 365 oder Citrix VDI verwendet, läuft unter Umständen in Probleme. Die Microsoft Teams App ist ggf. sporadisch nicht mehr funktionsfähig. Ein Blog-Leser hat mir die Tage die Information zukommen lassen, dass es von Microsoft einen Known Issues-Supportbeitrag gebe, der Probleme im neuen Teams 2.0-Client auflistet.

Es war eine kurze private Nachricht, die mich auf X von Patrick erreichte (danke für den Hinweis). Dieser wies mich darauf hin, dass es zum Thema "Problematik mit Teams 2.0 und VDI / Citrix", was ich im Blog angesprochen hätte, einen Known Issues-Beitrag von Microsoft gebe:

Den Blog-Beitrag kann ich ad-hoc nicht identifizieren – ist möglicherweise Windows Server 2019 mit Teams Classic nicht kompatibel mit FSLogix gewesen  – sicher bin ich nicht. Aber um was es hier geht, ist der Beitrag Features currently not available and known issues in VDI with the new Teams von Microsoft. Dort gibt Microsoft zu, dass der New Teams 2.0-Client einen Bug aufweist und nicht für Benutzer startet, die sich bei nicht-persistenten virtuellen Desktops anmelden, oder die App ist nicht im Startmenü sichtbar.

Das konkrete Fehlerbild: Nach dem Versiegeln des Golden Image und der Bereitstellung im großen Maßstab (mit Provisioning-Tools wie Citrix MCS/PVS oder VMware Instant-Clones) melden sich die Benutzer bei den virtuellen Maschinen an und klicken auf das neue Teams-Symbol, können die Anwendung aber nicht starten. Testet ein Administrator und will das Verhalten nachvollziehen, findet er nichts, denn Admins haben dieses Problem nicht.

Das Problem wird durch eine fehlgeschlagene Registrierung des MSIX-Pakets auf Benutzerebene mit verschiedenen Profilverwaltungsprogrammen (FSLogix, Citrix CPM, Ivanti UEM usw.) verursacht, obwohl die Bereitstellung des Pakets erfolgreich war (das Betriebssystem speicherte den Inhalt des Pakets auf der Festplatte im Verzeichnis %ProgramFiles%\WindowsApps). Dieses Problem kann durch Ausführen von Get-AppxPackage -name MsTeams für die betroffenen Benutzer bestätigt werden. Wenn Nutzer diesen Code ausführen, wird eine leere Ausgabe zurückgegeben. Wenn ich mir folgende Liste an bekannten Problemen so ansehe, frage ich mich spontan, was eigentlich beim neuen Teams 2.0-Client funktioniert?

• Screen sharing from chat for Azure Virtual Desktops/Windows 365 (This issue is now fixed on RD Client 1.2.5105 and Redirector Service 1.50.2402.29001).
• Screen sharing from chat for Citrix when using Workspace app 2311 only.
• The app switcher toggle isn't shown in new Teams if the virtual machine has the machine-wide classic Teams installed (MSI with ALLUSERS=1). Note: This issue is fixed on new Teams version 23320.3021.2567.4799 or higher.
• msteams_autostart.exe "The parameter is incorrect": In non-persistent environments that use FSLogix (any version) or Citrix Profile Manager profile containers, when new Teams attempts to autostart or a user tries to launch Teams from the Start menu, it throws the error: "The parameter is incorrect." The frequency and reproducibility of the error varies depending on the environment and especially the antivirus software being used (SentinelOne, Palo Alto, Trend Micro, Bitdefender, CrowdStrike, and so on.) and exclusions in place.
• New Teams fails to launch for users logging into non-persistent virtual desktops, or the app is not visible in the Start Menu.
  • Admins don't experience this issue – after installing new Teams on the golden image they can launch it successfully.
  • After sealing the golden image and deploying it at scale (with provisioning tools like Citrix MCS/PVS or VMware Instant-Clones), users log into the virtual machines and click on the new Teams icon, but aren't able to launch the app. The issue is caused by a failed registration of the MSIX package at the user level with different profile management software (FSLogix, Citrix CPM, Ivanti UEM, and so on), even though the staging of the package was successful (the OS stored the package's contents on the disk in the %ProgramFiles%\WindowsApps directory). This issue can be confirmed by running Get-AppxPackage -name MsTeams for the affected users. Running this code will return an empty output.
  • If Get-AppxPackage -name MsTeams -allusers is now run from an elevated powershell command window, the output shows that Teams is registered (see line PackageFullName) and the Status is OK.

Immerhin gibt Microsoft an, an diesen Problemen und fehlenden Funktionen zu arbeiten und die Beschränkungen "bald" aufzuheben. Die Hoffnung stirbt bekanntlich zuletzt.