Mich hat eine Leseranfrage eines Administrators erreicht, der unter Windows Server 2025 RDS mit bösen Outlook-Problemen seiner Nutzerschaft kämpft. Outlook bleibt regelmäßig beim Start in bestimmten RDS-Konstellationen hängen (es ist ein Zeitproblem). Es stellt sich die Frage, ob es Einzelfall ist oder ob es mehr Beobachtungen diesbezüglich gibt. Und es gibt die Frage nach der Ursache bzw. Lösung.
Eine Lesermeldung zu "hängendem" Outlook
Blog-Leser Werner K. ist als Administrator im Firmenumfeld unterwegs und betreut auch eine RDS-Installation mit FSLogix unter Windows Server 2025 für einen Kunden. Die Anwender dieses Kunden arbeiten mit den Remote-Desktop-Diensten und verwenden dabei auch Microsoft Office.
Outlook 365 hängt beim Starten
Aber es gibt seit einiger Zeit ein böses Problem, weshalb Werner bei mir eingeschlagen ist. In seiner gestrigen Mail merkt er folgendes an: "Als begeisterter Leser deines Blogs, versuche ich es auch mal auf diesem Wege. Vorab, danke für deine tägliche Arbeit. Wir sind echt froh um deinen Blog. Vielleicht hilft das Schwarmwissen der Blog Community weiter."
Er steht beim Kunden vor dem Problem, dass Microsoft Outlook beim Start mit obigem "leeren" Fenster einfach hängen bleibt. Werner schrieb, dass die Mitarbeiter dieses Kunden nun regelmäßig melden, dass das Outlook beim Start hängen bleibt. Entweder mit einem weißen Fenster, wie in obigem Screenshot gezeigt. Oder Outlook hängt bereits beim Outlook Start-Screen.
Weitere Analyse weist auf Timing-Problem hin
Werner hat dann mit seinen IT-Kollegen eine Analyse des Problems versucht und ist auf einen kruden Sachverhalt gestoßen. Die Analyse hat ergeben, dass dieser Hänger "nur passiert", wenn die Benutzer des Kunden nicht warten, bis das Profil fertig geladen ist (ca. 20 Sek.), sondern gleich das Outlook starten.
Wenn ein Nutzer im hängenden weißen Outlook-Fenster hängen bleibt, dann Outlook per Task-Manager "abwürgt", also beendet, lässt sich Outlook erneut und dann erfolgreich starten. Gleichzeitig wird im Event-Log des RDS-Server folgende Meldung angezeigt:
Es wird also eine Reparatur der Statusspeicherorte beim Vorgang SettingsInitialize für den StartMenüExperienceHost von Windows durchgeführt, was aber an dieser Stelle für die IT nicht allzu erhellen ist.
Spezifikationen der Systemumgebung
Werner hat noch einige Spezifikationen zur Systemumgebung des Kunden geliefert, in der der Fehler auftritt.
- HyperV Cluster (Windows Server 2025)
- File-Server (Windows Server 2025)
- DCs, Application Server etc. (Windows Server 2025)
- Mehrere RDS-Server (Windows Server 2025)
- FSLogix Profile Disks (Ablage auf File-Server)
- Auf den RDS-Server aktuelle Version von Office 365
- Duo Single Sign On für Microsoft 365
Auf Nachfrage schrieb mir der Blog-Leser, dass Outlook Classic in der M365-Variante zum Einsatz komme und er hat folgende Builds angegeben.
- Office Version 2602 Build 19725.20190 (aktueller Build)
- FSLogix 26.01 CU1 Build 3.26.126.19110 (aktueller Build)
FSLogix ist mir in der Vergangenheit zwar häufiger als Problem aufgefallen. Aber in Facebook-Administratorengruppen höre ich, dass dieses Paket in letzter Zeit eigentlich zuverlässig läuft.
Was an Tests ergebnislos geblieben ist
Der Leser schrieb, dass sie erfolglos diverse Tests und Versuche in dieser Umgebung ausgeführt haben, um den Fehler zu beheben. Folgende Lösungsansätze haben nichts gebracht:
- Benutzerprofil neu erstellen
- Ausschluss von Outlook -ddins
- Ausschluss von AADBroker etc. aus Fslogix Profil via redirections.xml
Der Leser erwähnte auch noch ein "SSO Warmup-Script", welches von ChatGPT vorgeschlagen worden sei. Ein SSO-Warmup-Skript (Single Sign-On) ist ein automatisierter Mechanismus, der dazu dient, Authentifizierungsdienste, Caching-Ebenen und Sitzungsverwaltungssysteme nach einem Neustart oder in Zeiten mit geringem Datenverkehr vorzuladen, und zu initialisieren. Es gibt so etwas auf GitHub für SharePoint und soll sicherstellen, dass die ersten Benutzer keine hohen Latenzzeiten aufgrund von Kaltstartproblemen erleben.
In obigem Scenario hat ein SSO Warump-Script aber nichts am Fehlerbild behoben. Frage in die Runde der Administratoren, die in diesem Bereich tätig sind, ob das Problem und ggf. eine Lösung bekannt ist?
Ähnliche Artikel:
Office-Updates Juni 2025: Outlook-Abstürze, Dokumente nicht mehr zu öffnen
Microsoft Teams Meeting Add-in killt Microsoft Outlook Classic
Outlook Classic: Sync- und Connect-Probleme werden untersucht
Microsoft Outlook (2019, 2021, 365): Keine Verbindung zu Exchange Online Mailboxen
Outlook Classic: Wird das globale Adressbuch bei euch noch aktualisiert? (März 2026)
Outlook Classic: Bug blendet Mauszeiger aus (auch in MS 365 Apps)
MVP: 2013 – 2016
Mit Server 2025 kann ich nicht dienen. Ansonsten haben wir eine vergleichbare Konstellation.
Es gibt noch weitere Fragestellungen:
– Ist Outlook Cached Mode aktiv?
– Exchange OnPremise oder ExO?
– Wie groß sind die VHDs (als Vergleichsgröße)?
Wir nutzen OnPremise und können daher auf dem Terminalserver problemlos den Cached Mode abschalten. Das hält die Profile schlank. Ob das mit ExO auch machbar ist, weiß ich nicht.
Hi Stefan
Danke für deine Fragen.
– Outlook Cached Mode ist aktiv, es passiert aber auch wenn Cached Mode nicht aktiv ist
– Exchange Online
– Die VHDs sind zwischen 10-30GB gross, der Fehler tritt aber auch mit einem neuen Profil auf
Wie sehen denn die OST-Dateien im %appdata% aus? Hatte schon öfters mal erlebt, dass bei einem nicht identifiziertem Fehler neue OST-Dateien gegenüber den alten erstellt werden mit fortlaufender Nummer. Dort mal alle löschen, bzw. die älteste umbenennen und die restlichen Löschen.
Dürfte aber auf einem neuen Profil dann eigentlich nicht auftreten.
Testweise mal einen anderen Mail-Client versucht?
Kann aber auch sein, wenn nur ein User beim ersten Start angegeben hat, dass alle Apps über O365 eingerichtet werden sollen. Wenn Intune nicht verwendet wird, muss dort dann imm "Nur diese App" angeklickt werden. Beim RDS zieht sich das dann bei allen Usern durch.
Hallo Giesama
Danke für dein Feedback. Die OST-Dateien sind sauber.
Dein zweiter Hinweis ist sehr spannend. Da haben wir in der Tat vermutlich mal falsch gedrückt. Du meinst, wenn man das nur einmal falsch gewählt hat, dass es dann auf dem betreffenden RDS-Server für alle falsch ist? Kann man das im Intune oder sonst wo bereinigen?
Am besten den WorkPlaceJoin auf dem RDS deaktivieren, dann kommt auch gar keine Nachfrage bei der MS365-Authentifizierung mehr:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin BlockAADWorkplaceJoin = dword:00000001
Danke. Werde ich gerne probieren!
Zukünftige Anmeldungen werden so unterbunden, okay, danke für den Tip, aber rein Interesse halber, funktioniert das auch rückwirkend?
Heyho,
die Fehlermeldung hatten wir öfters mit einer bestehenden RDS-Umgebung zw. WS2016-WS2022 mit Office 365, wo Outlook im Hintergrund beim Öffnen von Dynamics NAV aufgerufen wird.
Die Fehlermeldung schaut für mich eher aus, dass das SSO durch eine fehlende Internetsicherheitseinstellung nicht sauber greift.
Sind die GPOs gesetzt?
Computerkonfiguration bzw. Benutzerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Internet Explorer\Internetsystemsteuerung\Sicherheitsseite:
– Liste der Site zu Zonenzuweisungen:Aktiviert => https://autologon.microsoftazuread-sso.com:1
Computerkonfiguration\Richtlinien\Administrative Vorlagen\Microsoft Office 2016 (Computer)\Lizenzierungseinstellungen:
– Aktivierung gemeinsam genutzter Computer verwenden:Aktiviert
– Den Speicherort für das Lizenzierungstoken angeben, das von der Aktivierung gemeinsam genutzter Computer verwendet wird:Aktiviert => Ordnerspeicherort:{hier Freigabepfad\Persistenter Ordner angeben}
Grüße
– Jules | xSOU1
Hallo Jules
Danke für die Inputs. Werde ich nochmals prüfen. Bin der Meinung diese GPOs sind gesetzt.