[English]Die Tage ist mir in einer Administratorengruppe auf Facebook ein Post untergekommen, wo ein Administrator sich über den Outlook-Fehler "Da hat etwas nicht geklappt [58tm1]" in Microsoft 365 auslässt. Der Fehler scheint öfters aufzutreten.
Anzeige
Administrator weist auf Outlook 365 Fehler [58tm1] hin
Der betroffene Administrator schrieb, dass er mit Microsoft 365 Business Premium Lizenzen unterwegs sei. Die MS 365-Anwendungen laufen auf zwei Terminalservern unter Windows Server 2022, wobei FSLogix zum Einsatz kommt.
![Microsoft 365 Error [58tm1]](https://i.postimg.cc/0QN96KjY/image.png "Microsoft 365 Error [58tm1]")
Das Problem ist, dass einige User den in obigem Screenshot gezeigten Fehler "Da hat etwas nicht geklappt [58tm1]" bekommen. Im Anschluss können sich diese Nutzer nicht mehr in Outlook 365 anmelden. Abhilfe ist in diesem Fall dann im Userprofil:
C:\%Userprofile%\AppData\Local\Packages
Anzeige
den Ordner Microsoft.AAD.BrokerPlugin_vnggnktrrj zu löschen. Dann funktioniert die Anmeldung in Outlook 365 wieder. Der Betroffene fragte, ob andere Administratoren das Problem auch haben und ob es eine Lösung gibt, die das Problem behebt?
Weitere Treffer im Internet
Wer im Internet nach dem Fehler [58tm1] sucht, trifft auf wiederkehrende Berichte von Betroffenen aus den vergangenen Monaten. Der oben gezeigte Screenshot stammt aus dem Microsoft Answers-Forenbeitrag Microsoft Office Error Tag 58tm1 vom 13. August 2024. Dort tritt der Fehler beim Zugriff auf Dateien in Microsoft Word auf.
Der Thread umfasst inzwischen bereits drei Seiten, weitere Betroffene bestätigen das Problem, eine Lösung gibt es (für mich erkennbar) nicht. Ein Betroffener schreibt, dass sie den Fehler für die betroffenen Nutzer temporär beheben, indem sich die Benutzer abmelden und erneut, z. B. in Word, in das 365-Konto einloggen.
Im Microsoft Answers-Forenthread listet Daniel Soenke hier einige Maßnahmen des Microsoft-Supports wie Ab- und erneutes Anmelden, Löschen des bereits oben erwähnten Ordners "Microsoft.AAD.BrokerPlugin" löschen, entfernen unnötiger Konten und weitere als Voodoo zu interpretierender Handlungen auf.
Ich bin auch auf den Microsoft Forenbeitrag Outlook 365 app error 1001 on RDS environment ( FSLogix) vom 7. Juli 2023 gestoßen, wo der Fehler ebenfalls beklagt wird. Der Forenthread umfasst inzwischen 27 Seiten. Die letzten Einträge sind von Januar 2025 – eine Lösung ist nicht in Sicht.
Grzegorz Krzyzanowski versucht sich auf Seite 27 in einem Post vom Dezember 2024 in einer Fehleranalyse. So richtig den Durchbruch kann man nicht erkennen – der Fehler tritt sporadisch auf und ist der Kombination von Microsoft 365 mit RDS-Farm unter Windows Server 2019.
Er hat ein Ticket bei Microsoft eröffnet, aber die Hoffnung, dass dabei etwas herum kommt, ist gering. Denn beim Fehler [58tm1] handelt es sich um eine generische Fehlermeldung, die auf unterschiedliche Ursachen zurückgehen kann. Auf reddit.com meldet ein betroffener Administrator so im August 2024, dass er das Problem für sich mit dem Upgrade auf die neueste Version von FSLogix und Ausführung einiger Operationen für sich gelöst habe. Ich bin aber skeptisch, dass das wirklich universell hilft.
Das Problem scheint bekannt
Ein andere Administrator gab auf Facebook an, dass der Fehler [58tm1] in Outlook, speziell bei einer Umgebung mit Microsoft 365 Business Premium, Terminalserver 2022 und FSLogix, ein bekanntes Problem sei, das oft mit der Authentifizierung und dem AAD Broker Plugin zusammenhänge.
Die oben beschriebene Lösung, Microsoft.AAD.BrokerPlugin_vnggnktrrj im Benutzerprofil im AAD Broker Plugin-Ordners zu löschen, setzt das Plugin zurück und behebt das Problem vorübergehend. Das sei keine dauerhafte Lösung, merkt der Nutzer an.
Durch eine Kombination aus FSLogix-Optimierung, Aktualisierung und Neuregistrierung des Plugins könne man versuchen, das Problem langfristig zu lösen. Der Nutzer beschreibt in seinem Post mögliche Ursachen für den generischen Fehler [58tm1] in Outlook:
- Korruption des AAD Broker Plugins: Probleme mit der Authentifizierungskomponente von Microsoft.
- FSLogix-Profilmanagement: Konflikte beim Laden der Profile oder bei Zugriffen auf die Daten des Plugins.
- Ungültige Token: Das AAD Broker Plugin speichert Token, die abgelaufen oder ungültig sind.
- Fehlerhafte Updates: Ein fehlerhaftes Update von Windows, Office oder FSLogix könnte das Problem verursachen.
- Gruppenrichtlinien oder Sicherheitsrichtlinien: Einschränkungen, die die ordnungsgemäße Funktion des Plugins beeinträchtigen.
In seinem Facebook-Post skizziert der Administrator einige Lösungsansätze, die man ausprobieren kann, in der Hoffnung, das Problem dauerhaft zu beheben:
- Outlook-Reset mit der Reparaturfunktion in Office: (Systemsteuerung – Programme -Microsoft 365 Apps – Ändern – Option Online-Reparatur wählen. Im Anschluss einen Neustart durchführen.
- Versuch einer "FSLogix-Optimierung", indem sichergestellt wird, dass die neueste FSLogix-Version installiert ist (die aktuelle Version von der Microsoft-Webseite herunterladen und installieren).
- Überprüfen der Einstellungen für den FSLogix-Profilordner, insbesondere die Konfiguration für Container Locking. Dies lässt sich über den Registrierungseditor im Zweig HKEY_LOCAL_MACHINE\Software\FSLogix\Profiles kontrollieren. Dort sollten die Einstellungen für ConcurrentUserSessions und EnableConcurrentSessions korrekt konfiguriert sein.
- Überprüfen der Gruppenrichtlinien, ob dort Einstellungen hinterlegt sind, die die Authentifizierung oder das AAD Broker Plugin beeinflussen. Das sollte im GPO-Zweig Computer Configuration > Administrative Templates > Windows Components > Authentication zu finden sein. Hier sind alle Richtlinien zu deaktivieren, die möglicherweise die Token-Erneuerung oder das Plugin blockieren.
- Neuregistrierung des AAD Broker Plugins mittels der folgenden PowerShell-Befehle auf dem Terminalserver. Dadurch wird das Plugin zurückgesetzt und erneut registriert.
Get-AppxPackage -Name Microsoft.AAD.BrokerPlugin | Remove-AppxPackage Add-AppxPackage -register "C:\Windows\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AppxManifest.xml" -DisableDevelopmentMode
Vorgeschlagen wurde auch (ist bereits oben erwähnt), den Token-Cache gezielt für alle betroffenen Benutzer leeren. Dazu sind alle Inhalte im Verzeichnis :
C:\Users\\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin*
zu löschen. Weiterhin gab es vom betreffenden Administrator noch allgemeine Hinweise, wie Windows Updates und Treiber für Windows Server 2022 auf dem aktuellen Stand halten. Klingt für mich alles wie hilfloses Herumprobieren ohne Aussicht auf Erfolg. Der Ratschlag des Gruppenmitglieds: "Falls das Problem weiterhin besteht, öffne ein Support-Ticket bei Microsoft, da dies möglicherweise ein bekanntes Problem ist. Verweise auf ähnliche Berichte im Zusammenhang mit [58tm1] und dem AAD Broker Plugin."
Ein weiteres Gruppenmitglied gibt an, bei sich das Problem durch aktivieren von Roam Identity beheben konnte. Anschließend sollten die Sessions Hosts "Hybrid Joined" sein und SSO sollte aktiviert sein. Das Mitglied hat diese Anleitung zum Durcharbeiten verlinkt.
Frage in die Runde der Administratoren in der Leserschaft: Ist das auch bei euch ein Problem? Gibt es eine bessere bzw. dauerhafte Lösung? Mir kommt das Ganze Microsoft 365 wie eine Dauerbaustelle vor, bei der nie alles funktioniert.
Anzeige
> Frage in die Runde der Administratoren in der Leserschaft: Ist das auch bei euch ein Problem?
Für (mehrere) vergleichbare Szenarien (Terminalservr-Umgebung)? Nein.
> Gibt es eine bessere bzw. dauerhafte Lösung?
Office LTSC ohne Abos offline auf dem ebenfalls offline betriebenen Terminalserver nutzen. Einzig der Firefox hat seine Proxydaten für den Internetzugriff, per GPO verteilt.
Dauerhafte Lösung kann es IMHO nur sein, perspektivisch von Microsoft ganz weg zu kommen. Bei Office leicht zu bewältigen, wenn die Prozesslandschaft stimmt und eine Wawi/ERP/BI/Reporting Lösung erst gar keine Notwendigket für irgendwelche Word/Excel Dokumente und Outlook Mails macht. Ist eine recht zuverlässige Heuristik: Überall dort, wo noch Excel zum Einsatz, versagt das ERP und BI/Reporting.
Das wenige, was übrig bleibt, kann auch mit einem Libreoffice bzw. dessen Onlineversion Collabora erledigt werden, gerade in Terminalserver-Umgebungen.
Vielleicht ist für manche diese Zusammenstellung hilfreich:
https://blog.jakobs.systems/blog/20250121-opensource-business-kmu/
Grundsätzlich gilt, je mehr Anwendungsprogramme plattformunabhängig oder webbasiert genutzt werden, desto geringer ist die Fallhöhe bei einem Systemwechsel.
Ja, ist mir auch inkl. "Lösung" bekannt. Leider tritt das Problem bei mir nach einigen Monaten erneut auf. Von 15 Personen ist aber aktuell nur 1 betroffen.
Ist das überhaupt für Termial Server freigegeben bzw. überhaupt vorgesehen?
Lese ich hier zumindest nicht:
https://learn.microsoft.com/de-de/fslogix/overview-what-is-fslogix
Musst du unten bei "Nächste Schritte" auf "FSLogix-Voraussetzungen" klicken, dort steht dann u.a.:
FSLogix arbeitet auf allen von Microsoft unterstützten Betriebssystemen, einschließlich, aber nicht beschränkt auf die folgenden:
– Windows 10 und Windows 11
– Windows Server 2012 R2, 2016, 2019, 2022, 2025
Habe ich natürlich, aber "Terminal Server" ist keine Betriebssystem-Variante sondern eine ganz spezielle und durchaus komplexe Betriebsart, die zwischen Installations- und Ausführungsmodus unterscheidet. D. h. ich würde nie auf die Idee kommen – außer auf eigenes Risiko – in einer solchen Umgebung Software zu betreiben, die nicht explizit für den Einsatz in Terminalserverumgebungen freigegeben ist (und damit getestet wird). Daher hatte ich danach gesucht und bin nicht fündig geworden.
Wir hatten sowas früher auch bei Kunden im Einsatz, aber heutzutage, wo ein durchaus leistungsfähiger PC kaum teurer als ein Thin Client ist (und mit AMD oder ARM-CPUs auch kaum mehr Strom verbraucht – Intel interessiert mich schon seit 10+ Jahren nicht mehr…), lohnt sich das finanziell kaum, höchstens aus Sicherheitsaspekten für eine sehr begrenzte Anzahl von wenig ressourcenhungrigen Anwendungen.
Kauf mal einen Server, der so viel Leistung (RAM, I/O) wie 10, 20, 30 handelsübliche Desktop-PCs hat, selbst mit einer relativ kleinen Office-CPU.
Im Cloud-Zeitalter sollten die meisten verteilten Anwendungen eh besser im Browser laufen und somit beliebig skalierbar, oder es steht Azure Virtual Desktop zur Verfügung, wo jeder Nutzer wirklich seinen eigenen PC bekommt und darauf nicht die Einschränkungen hat, die ein Terminal-Server-Betrieb mit sich bringt, wie wildes Gewurschtel in der Registry, um Anwendungen, die eigentlich gar nicht Multi-User-/Tasking-tauglich sind, doch so zu betreiben.
Zu seiner Zeit, also vor einigen Jahrzehnten, fand ist das cool, und es funktionierte auch tadellos. Aber heutzutage würde ich sowas nicht mit der Kneifzange anfassen, außer eben für sehr begrenzte Szenarien. Die mag es durchaus noch geben, nicht aber unbedingt eng mit der Cloud verzahnt. Denn das ist ein anderes Zeitalter…
Ist schon lange bekannt, sobald man ein Office Produkt nicht anmelden kann trotz Lizenz.
Kommt zb vor, wenn man ein System klont, oder 2fa für OneDrive nutzt.
Auch defekte Outlook Anmeldungen können dadurch öfters repariert werden.
Das größte Problem ist dabei, das Microsoft keine Fehlerprüfungen für ihre Software nutzt. Daher sind auch über 80% aller Fehlermeldungen erstmal ohne Aussagekraft, haben komische Zahlen usw.
Bei kam der Fehler bei allen neuen Usern. Ging am 21.01. los.
Mein Deutsch is nicht ganz gut, so I'll continue in English. I have had this issue as well, but I've worked around it by the following. I'm a bit out of time, so I copy/paste my post I made on Reddit on this before. We've never had anyone complaining anymore after this. So in my book it's working pretty well!
Original post: Not a real solution but I have a workaround in place that works for us. I never got RoamIdentity to work reliably, I have no clue why as even on a fresh vanilla Server 2022 I had the very same issues. What I now do is that we explicitely disable RoamIdentity. Then in a user logoff script I make a copy of the Microsoft.AAD.BrokerPlugin folder, in this case simply using robocopy (as I still love batch / cmd files for their speed for simple tasks compared to something like PowerShell):
robocopy "%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" "%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy_backup" /mir /sec /mt /ndl /nfl /r:0
So, there would be a Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy_backup folder in the FSLogix profile container now.
During the login process, I delete the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy folder if it already exists. If I remember correctly it's not even there when RoamIdentity is disabled, but I'm not sure anymore. Then a 'new' Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy folder is created as soon as the AADBroker 'app' initializes. However, nothing will be done with it before starting an app that needs it, like Office or Teams or what have you.
So, I made a login script that simply polls every second until the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy exists. At that point, the broker addin is initialized but not in use yet. Then I simply robocopy the backup folder over the original, and that's it. As soon as an app starts, the login script has long been processed, and everything works as expected. You can't copy the backup files over the original folder immidiately after login before the app is initialized, because for some reason that makes it fail too in our setup.
So we have in our login script, again simply in batch:
RD %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy /s/q
FOR /L %%G IN (1,1,10) DO (
IF NOT EXIST "%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" (
timeout /t:1
)
)
timeout /t:1
robocopy "%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy_backup" "%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" /mir /sec /mt /ndl /nfl /r:0
For some reason, RoamIdentity does not (always) do what it's supposed to do. So for now this works fine for us. Let me know if it helps.
Thanks for your hint, I guess, the reader of my German blog will be able to read your solution. I will also overtake your workaround into the English version of this blog post, after I've published it (the English blog post are sometimes delayed for a couple of days).
I want to add that we use this in environments that do NOT have SSO enabled. Most of them are multitennant environments, and SSO only works for one single instance of ADConnect. So as far as AADBroker goes, we use this on regular accounts without SSO, and credentials are saved fine in the FSLogix container using this. Remember to disable RoamingIdentity for this to work. Ofcourse it also works with SSO, as AAD.Broker is still broken using SSO, but you'll likely not notice because SSO fixes things up again.
Wir kennen das Problem von mehreren WTS-Installationen mit Citrix und ohne.
Es tritt immer in Verbindung von Roaming-Profilen auf. (Also mehrere Hosts) und nie bei kleinen Installationen mit nur einem Host.
Bei uns hat die Ausschluss-Liste von FXlogix (redirection.xml) das Problem zuverlässig abgestellt. Das wird auch bei Microsoft unter known issues empfohlen.
Sofern man nicht SSO nutzt, muss man sich aber regelmäßig neu anmelden muss.