[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.
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
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.
Ergänzung: Beachtet meinen Beitrag FSLogix 25.09 fixt Outlook 365-Fehler [58tm1] und Windows Server 2019 OneDrive-Rename-Bug – das Problem scheint mit FSLogix 25.8 gefixt zu sein
MVP: 2013 – 2016
> 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…
Du scheinst nicht zu verstehen, wofür FSLogix ist, bzw. was es ersetzt (User Profile Disks). NATÜRLICH will man das für RDS Session Hosts haben…
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.
Hallo Sven,
kannst du bitte mitteilen was genau ihr in der redirection.xml eingetragen habt bzw. welcher known issue Artikel von Microsoft?
Danke
Hallo Dominic,
hier meine Excludes, welche ich von MS und dem Forum Beitrag zusammengetragen habe:
AppData\Roaming\Microsoft\Protect
AppData\Roaming\Microsoft\Credentials
AppData\Local\Microsoft\Credentials
AppData\Local\Microsoft\Office\16.0\OfficeFileCache
AppData\Local\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\TempState
AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\TempState
AppData\Local\Packages\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\TempState
AppData\Local\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\TempState
AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
AppData\Local\Microsoft\TokenBroker
https://learn.microsoft.com/de-de/fslogix/troubleshooting-known-issues
https://answers.microsoft.com/en-us/outlook_com/forum/all/outlook-365-app-error-1001-on-rds-environment/e6ae8598-81a0-4859-846a-d9509b246bf4?page=26
Hier ist ein Beispiel der redirection.xml:
"AppData\Roaming\Microsoft\Protect"
https://answers.microsoft.com/en-us/outlook_com/forum/all/outlook-365-app-error-1001-on-rds-environment/e6ae8598-81a0-4859-846a-d9509b246bf4?page=26
https://learn.microsoft.com/de-de/fslogix/troubleshooting-known-issues
Hi zusammen,
um welche Facebook Gruppe handelte es sich?
Wir haben das Problem auch bei vielen unterschiedlichen Benutzers mit Business Premium und FSLogix.
Könnte IT-Profis / Netzwerk-Spezialisten / Administratoren gewesen sein – genau weiß ich es nicht mehr – ich verlinke grundsätzlich keine Facebook-Posts hier im Blog.
Hier wird die Lösung wohl endlich adressiert:
https://techcommunity.microsoft.com/blog/fslogix-blog/fslogix-v3-release-25-02-is-now-generally-available/4377003
Hat für uns keine Änderung gebracht. Leider
Hallo,
danke für das Zusammentragen der Infos. Wir haben leider lange Probleme mit Office Anmeldungen in
diversen Citrix Umgebungen. Ua Windows Server 2019, Windows 10, Windows Server 2022.
Profile werden entweder über Citrix UPM oder FSLogix gemanaged.
Dennoch sieht man den Fehler mal häufiger, mal seltener.
Workarounds wie das selektive Bereinigen von Profilen helfen betroffenen Usern für einige Wochen oder Monate.
Doch wirklich dauerhaft gelöst haben wir das Problem nicht oder nur temporär gute Phasen gehabt.
Der Februar Patchday wurde erstmal in Teilen rückgerollt, da zu viele Anmeldungen fehlschlugen.
Wirklich erschreckend welche Software Qualität Microsoft abliefert.
MS Calls waren bisher nicht wirklich zufriedenstellend.
Just for info, there's a new FSLogix release, 25.02 (3.25.202.4223)
https://learn.microsoft.com/en-us/fslogix/overview-release-notes#fslogix-2502-3252024223
It might fix things, I haven't tried it yet.
I tested with the new 25.02 version, and so far as my testing went today, with the previous version (and no additional login/logoff scripts to work around the issue) I can reproduce the issue at every single login. With 25.02 though it actually seems to work fine. Weird thing is it works with either RoamingIdentity enabled or disabled, it doesn't seem to matter.
Your mileage may vary, but so far it looks good on our test environment.
Hey Folks,
So we have the same Problem on a 3 Server RDS-Farm with ConnectionBroker.
Even after the 25.2 FSLogix install, it keeps happening. With RoamIdentity on OR off, doesnt matter.
Its horrible, how Microsoft does not respond to this Problems, since it seems like a major issue.
So anybody got any Luck, besides the deleting script or excluding of folders?
Hi zusammen,
wir sind auf diesen Reddit-Thread gestoßen, in dem der User notmyfault_404 ein Problem mit einer RDS-Farm (Windows Server 2022) und FSLogix beschreibt. Der Nutzer seluce_ gibt den Tipp, die FSLogix-Roaming-Identität zu deaktivieren und die Session-Hosts im Hybridmodus zu konfigurieren.
Hat jemand Erfahrung mit diesem Szenario? Würde dieser Ansatz helfen, oder gibt es noch weitere Best Practices, um den Fehler zu beheben?
Hier ist der Link zum Thread: https://www.reddit.com/r/Office365/comments/1fkfie9/rds_farm_2022_fslogix_h4_office_error_58tm1/?tl=de
Danke vorab für eure Tipps!
Viele Grüße
Hey Everyone,
Currently also working on a case with Microsoft to get this solved, currently they shared these instructions as "fix".
We are yet to see if this will fix the issue permanent.
1. Reset the Office to activation state (Method: Use scripts to automate the cleanup process): https://learn.microsoft.com/en-us/office/troubleshoot/activation/reset-office-365-proplus-activation-state#method2
2. Clear WAM State:
• Stop the tokenbroker service from an admin powershell:
o Set-Service TokenBroker -StartupType Disabled
o Stop-Service TokenBroker -Force -PassThru
• Stop any running AAD WAM instances:
o taskkill /F /IM Microsoft.AAD.BrokerPlugin.exe
• Delete the account files in the following folder:
o %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts
• Take backup copy of the following file and then delete it:
o %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\settings.dat
• Rename (or delete) this registry key:
o Computer\HKEY_CURRENT_USER\Software\Microsoft\IdentityCRL\TokenBroker\DefaultAccount
—>
o Computer\HKEY_CURRENT_USER\Software\Microsoft\IdentityCRL\TokenBroker\DefaultAccount_backup
• Restart the tokenbroker service (from admin cmd)
o Set-Service TokenBroker -StartupType Manual
o Start-Service TokenBroker -PassThru
Currently running the vbs script as user (user cannot elevate offcourse).
The other steps are run via PS script, ofcourse an admin is involved.
Anyone else already tried these steps?
Hi Wout,
your solution did not work for me, cause we have the problem on a remote desktop server. So we arent able to start/stop services on a system with 15 users.
thanks
borsch
Hi Borsch,
We also face this issue on RDS servers (2022 farm / 11 hosts).
We made a script which does run some commands with elevated permissions (saved credentials, I know its not the safest but we are running desperate..) however we see that some users already ran the script multiple times on different hosts. (so still waiting for the scenario in which a user runs the script again on a host on which they have ran it before).
According to Microsoft the commands need to be executed as admin (vbs script and PS1 script as well).
To me it feels that the engineer in question does not entirely understand what RDS is.
MS support told me to run this for every user on every systems, in my situation that would mean that 150 users X 11 servers = 1650 runs of the script, I kindly told them that was not gonna work.
To be continued.
Gibt es hier mittlerweile eine funktionierende Lösung?
Würde mich auch interessieren. Wir haben das Problem bei Kunden mit RDSH, ohne Fslogix. Jeden Tag sind 3-4 Benutzer betroffen. In Word ab- und anmelden hilft meistens, manchmal sind noch M365-Anmeldebereinigungen und RDSH ab- anmelden nötig.
Benutzer sind aber nicht nur 1x betroffen, sondern melden sich inzwischen teilweise auch schon das zweite Mal.
Könnte das ein Timing Problem sein?
FSlogix brauch länger als der AAD Broker seine Verzeichnisse erwartet?
Der Trick mit dem Logon/Logoff Script würde genau das abfangen.
Das würde auch ein inkonsistentes Verhalten über verschiedene Session Hosts und User erklären.
Das Thema zieht sich wie ein Kaugummi. Selbst nach dem neusten FSLogix Update, gibt es ettliche User, die immer wieder das Problem haben.
Nervt.
Moin, wir haben das gleiche Pr0blem.
3 Terminalserver (Server 2022), FSLogix 2.9.8612.60056), AzureAD Hybrid Sync,
Bei uns half "meistens" auch in Word ein Ab- und Anmelden. Eine dauerhafte Lösung wäre echt mega. Hat jemand Kontakt mit Microsoft zu dem Thema?
Nutzt einer in FSLogix die ODFC Container? Gibt es damit die gleichen Probleme? Wir setzen die aktuell noch nicht ein.
FSLogix 3 schon jemand im Einsatz und Erfahrungen?
Gruss Oliver
Moin Oliver,
wir haben FSLogix 3.25 mit ODFC Containern im Einsatz.
Bei uns ist das Problem, dass die User sich mit Benutzername und Kennwort anmelden müssen, obwohl wir Single Sign On konfiguriert haben.
Sind sie einmal angemeldet, funktioniert es häufig problemlos bis wir eine neue Version der Citrix PVS VM frei geben.
Dann geht scheinbar das PRT Token von Microsoft verschütt und die nächste Anmeldung wird fällig.
Heute hatte ich dann mal wieder aus heiterem Himmel einen Haufen Leute mit dem bekannten 58tm1 Fehler.
Der Workaround mit dem Löschen des Ordner hilft glücklicherweise.
Habe auch bereits ein Ticket bei Microsoft dazu eröffnet, mal schauen was die Auguren aus Redmond heraus finden…
Hi Dominik,
ok. kam da von Microsoft schonmal was?
LG Oliver
Hallo Oliver,
mach mal als erstes ein Update auf das neueste FSlogix Release.
Evtl. hilft es bei dir.
VG Sven
Hi Sven,
hab mich noch nicht getraut auf FSLogix 3 zu gehen. Hab viel gelesen dass es damit noch einige Kinderkrankheiten gibt.
Wenn dann muss ich das mit VM Klonen testen. Dazu kam ich aber noch nicht.
LG
Wir haben dasselbe Problem, aber ohne FSlogix und nur bei einem Benutzer in einer Hybridjoin Structur.
Profil Bereinigungen wie auch das Userprofil der Citrix neu zu machen hat keine Lösung gebracht.
Teilweise tritt das Problem auch mehrmals täglich auf und das im täglichen Intervall.
Ich plage mich mit diesem und anderen Fehlermeldungen im Bezug auf Office 365 Enterprise unter Windows 11 Enterprise und Citrix DaaS schon seit Monaten herum.
Auch bei uns kommt FSlogix zum Einsatz, aktuellster Release.
Erschwerend scheint bei Citrix noch hinzu zu kommen, dass hier seit Anfang des Jahres nur noch die Zertifikatsbasierte Authentifizierung für Single Sign On unterstützt wird.
Was auch immer das Problem ist, es nervt…hart! Man wünscht sich die seligen Zeiten zurück, wo man eine Seriennummer nach der Installation eingab und Ruhe wars…
oh ja :D
FCKGW-RHQQ2…. :-)
Also ich habe das Problem nun auf einer RDS Farm mit zwei 2025er RDP Servern. Allerdings habe ich hier Onprem Office 2024 LTSC und Exchange Online Plan 1. Der Name des Ordners ist auch leicht anders "Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
Installation ist "frisch" aus Mai 2025. aktuellste FSLogix. 3 PCs sind betroffen, immer im wechsel.
Gibts mittlerweile eine Lösung?
Soweit ich weiß aktuell nur die bekannten Workarrounds.
Word Abmelden, word beenden, word starten, word anmelden
oder
löschen des Ordners: Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
LG
Hallo zusammen, ich habe das Problem auch und es nervt einfach nur noch!
4x RDS 2019, FSLogix aktuell, Office 2024 LTSC und EXOp1, täglich mindestens 1-2 Benutzer mit dem Fehler in Outlook.
Angefangen hat es nach dem Wechsel von Office 2016 auf Office 2024
AAD.Broker Ordner leeren schafft dann zwar für ein paar tage Abhilfe bis es dann wieder knallt… es muss doch eine Lösung geben?
Since my german is not that good i'll comment in english.
We never got this fully worked out the way I wanted with Microsoft.
Eventually we got the issue "fixed" by using fslogix redirections.xml:
AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
AppData\Local\Microsoft\IdentityCache
AppData\Local\Microsoft\TokenBroker
AppData\Local\Microsoft\OneAuth
AppData\Local\SquirrelTemp
However when you apply this users will have to login with there office 365 credentials on each RDS server within a farm.
After the first signin on a specific server they will not be reprompted for credentials.
As already mentioned its not the fix we wanted but at least it does make sure the 58tm1 is gone.
Within fslogix make sure roam identity is not enabled.
Are the redirections path excluded or included?
excluded from the profile, they remain in the local_ folder on the server when the user is logged off.
Wir haben hier ähnliche Erfahrungen gemacht,
—————————
Umgebung:
Diverse RDS Host Server 2025 Datacenter
Server 2025 Datacenter Server als FSLogix Profilserver
FSLogix Version 25.04 -> Test auf 25.06 steht noch aus
FSLogix GPO-> Roam Identity = aktiviert und im DopDown = Enabled
Hybrid Joined Hosts
————————–
Update:
FSLogix Version 25.06 wurde eingespielt
FSLogix GPO-> Roam Identity = aktiviert und im DopDown = Disabled
FSLogix GPO-> Roam Identity = aktiviert und im DopDown = Disabled
FSLogix GPO->Redirection XML Source Folder aktiviert -> Datei auf jedem RDS Host abgelegt. Eintrag -> C:\Skripte\FSLogix
Inhalt der redirections.xml
AppData\Roaming\Microsoft\Protect
AppData\Roaming\Microsoft\Credentials
AppData\Local\Microsoft\Credentials
AppData\Local\Microsoft\Office\16.0\OfficeFileCache
AppData\Local\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\TempState
AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\TempState
AppData\Local\Packages\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\TempState
AppData\Local\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\TempState
AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
AppData\Local\Microsoft\TokenBroker
Testlauf mit Testbenutzern sieht (bis jetzt) gut aus
-> Weiteres Update folgt nach Zeit.
Mit genannten Einstellungen haben wir generell ein besseres Verhalten erzielen können jedoch stellen wir noch folgende Probleme fest:
-> Tägliche Neuanmeldung beim Start der ersten O365 Anwendung
-> Probleme wenn Outlook über den Autostart gestartet wird ( dies führt dazu, dass das Outlook als nicht Lizensiert angesehen wird) -> Ein einfacher Neustart der Anwendung hilft als Workaround
-> Sporadische ,,Session Key ist Empty" Meldungen, welche vom User geschlossen werden können und die Nutzung im Office Paket nicht beeinträchtigt
Hat hier jemand ähnliche Erfahrungen gemacht oder Lösungansätze?
Er erwähnen wäre noch das in der FSLogix GPO eingestellt wurde das User Temp Verzeichnisse automatisch bereinigt werden bei abmeldung
Update:
Bis auf eine Neuanmeldung nach Sitzung Aufbau scheinen die anderen Probleme gelöst zu sein.
Konnte hier schon jemand neue Erfahrungen machen auch dies zu beseitigen?
Just an update, as far as my testing went so far, it seems FSLogix 25.06 finally fixes the roamidentity issues. I've only got it in test yet, nowhere in production. But so far it looks good.
I spoke too soon; this morning FSLogix 25.06 also showed us the dreaded errors again. So it's still not fixed. I also had a test environment running with 25.06 with 'my' AAD.Broker backup scripts and that still works fine.
Mir ist das Problem Heute zum ersten Mal begegnet.
Umgebung Citrix, aktuellste LTS Version auf W2019 Servern, mit Citrix eigenem Containerprofil-Gedöhns. (FSLogix flog bei uns vor ca. 3 Jahren wegen nicht lösbarer Dauerprobleme raus! davor lief es fast 5 Jahre ohne den Hauch eines Problems Ursache: mit MS Updates getötet)
Userlizenzen sind seit einem Quartal Business Premium Retail, davor ProPlus Retail.
Seit der Umstellung von Exchange von On-Prem in die Cloud häuft sich der Bullshit-Fehler-Anteil extrem. Ich bin nur Techniker, kein Entscheider, sonst wäre Microsoft außer als OS komplett aus der Firma getilgt worden. Kein Bock mehr auf M365, vor allem nicht auf Teams und die Powertoys ähh Tools… Es ist ein Graus. Die Welt wäre deutlich schöner ohne irgendwelches Zeug aus Azure/Entra und all dem Blödfug. In einer on-Prem Umgebung gibts mit dem ganzen Windows und Office Kram nahezu keine Probleme. Der Weg in die Cloud scheint mir der Weg des Totengräbers für eine Firma zu sein.
The following method has successfully resolved the issue for us, and we highly recommend you try it in your own environment. The core of the solution lies in a simple but crucial change to your FSLogix redirections.xml file. By excluding specific folders, you prevent authentication data from being corrupted when a user logs off and on again.
Resolution Steps
To implement this fix, you'll need to edit your FSLogix redirections.xml file. If you haven't set one up yet, you'll need to create the file and then link it to your FSLogix configuration using either a Group Policy Object (GPO) or a registry key.
Add the following exclusion entries: Open the redirections.xml file and insert these three entries inside the section:
XML
AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
AppData\Local\Microsoft\TokenBroker
Thanks Marry for sharing your solution.
Other people (Fabian from above) already suggested this, but mentioned that users have to sign in to O365 apps with every new login at RDS server.
Did you observed this also?
I can confirm this – we tried the suggestion and had to revert it immediately.
In a RDS farm with multiple servers this is not a solution because as mentioned the users need's to authenticate every time they connect to office.
But the update to the new FSLogix 25.09 seems to solve the issue.
Mit der neuen FSlogix Version tritt der Fehler in meiner Farm nicht mehr auf. Ohne Änderungen am System. Brokerplugin usw.
Version 25.09
Hallo,
do have 'roam identity' enabled?
thanks
Do you have 'roam identity' enabled? For SSO office365 apps in a multi server RDS farm?
yes, we have EntraID-Sync and FSLogix "Roam Identity" GPO enabled
Ich habe gestern Abend version 25.09 auf eine Umgebung installiert (2 x RDS-Hosts, 2025). Wir hatten zunächst Probleme mit der Aktivierung von Office. Heute haben jedoch bereits zwei Benutzer, die nach einer Stunde einwandfrei gearbeitet zu haben, die Verbindung zu Exchange Online verloren. Nach einem Neustart von Outlook erscheint der Fehler 58tm1.
Mit einem Skript löschen wir dann einige Dateien, die Benutzer melden sich ab und wieder an, und es funktioniert wieder. Das ist jedoch keine dauerhafte Lösung.
Wir haben "Roam Identity" enabled.
Zum Thema "Roam Identity" empfiehlt Microsoft dieses nicht zu aktivieren:
https://learn.microsoft.com/en-us/fslogix/reference-configuration-settings?tabs=profiles#roamidentity
Ich hatte das auch anders in Erinnerung und aktiviert während der ursprünglichen Einrichtung von FSLogix bzw. des Servers.
Aktuell fahre ich mir der neuesten FSLogix Version 25.09 und nun deaktivierter "Roam Identity" problemlos.
Es wird auf dem RDS aber auch nur die MS Office Suite + OneDrive verwendet, Teams hingegen nicht.