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

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


Anzeige

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:

Teams 2.0 Known Issues

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.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Teams abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

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

  1. Jürgen Streu sagt:

    Wir untersuchen das Thema gerade. Reproduzieren lässt sich das Verhalten mit UPM Full Container oder bei Aktivierung der Accelerate Mirror Folder. Annahme unsererseits ist, dass die spezielle Berechtigung auf WindowsApps für .\Users, versehen mit einer Condition nicht erfüllt ist, wenn Pfade (Packages?) im Container "liegen". Ein Ticket bei Citrix besteht (82579903). Heute habe ich ein weiteres Ticket von einem Kunden mit selben Verhalten bei einer weiteren Anwendung CrossDeviceService im WindowsApps. Ein Ändern der WindowsApps Berechtigung ist wohl eine schlechte Idee. Mal sehen, wie Citrix hier weiter vorgeht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.