Remote Desktop Services (RDS) bestehen in der Praxis aus einer klaren technischen Kette, die sich aus mehreren Schichten zusammensetzt: Netzwerkpfad (Routing, Firewall/NAT, TCP/UDP), Namensauflösung (DNS), Aushandlung des RDP-Transports (inklusive Sicherheitslayer), TLS-Absicherung, Vorab-Authentifizierung mit Network Level Authentication (NLA) über CredSSP/SSPI (Kerberos oder NTLM), anschließend die Windows-Anmeldung (LSASS/Winlogon) und danach Autorisierung (Benutzerrechte, Gruppen, RDS-Richtlinien), Sitzungsannahme durch den RD Session Host (TermService) sowie das Laden der Benutzerumgebung (Profil, Gruppenrichtlinien, Shell/RemoteApp). In Farmen kommen zusätzlich Rollen wie RD Gateway (Zugriffstunnel über HTTPS), RD Connection Broker (Zielzuweisung/Reconnect/Last), RD Licensing (Lizenzierung) und optional NPS/RADIUS (Policy/MFA) hinzu.

Inhalt

Schnellstart: 10-Minuten-Triage für RDP/RDS-Verbindungsprobleme
Technische Kette vom RDP-Verbindungsaufbau bis zur Windows-Sitzung
Fehlermeldungen und Statuscodes: Zuordnung nach Phase, nicht nach Bauchgefühl
- Konkrete Log- und Eventquellen, die in der Praxis den Unterschied machen
- Praxis-Tipps, die häufig sofort helfen

Schnellstart: 10-Minuten-Triage für RDP/RDS-Verbindungsprobleme

Wenn eine Verbindung akut nicht funktioniert, ist die schnellste Methode eine harte Einengung: Zuerst Netz und Namensauflösung, dann TLS/NLA, dann Windows-Logon/Rechte, dann RDS-Rollen (Gateway/Broker/Licensing), zuletzt Profil/Benutzerumgebung.

Auf dem Client: Resolve-DnsName SERVERFQDN (oder nslookup) und IP plausibilisieren (kein altes A-Record, kein falscher CNAME, kein Split-DNS-Fehler).
Auf dem Client: Test-NetConnection SERVERFQDN -Port 3389 (direkt) oder Test-NetConnection RDGATEWAYFQDN -Port 443 (über Gateway). Ergebnis entscheidet, ob es ein Netzwerk-/Firewall-Thema ist.
Wenn TCP erreichbar, aber RDP scheitert: kurz NLA testen, indem man (nur zum Eingrenzen) eine Verbindung mit deaktivierter NLA auf einem Testziel zulässt – nicht als Dauerlösung. Scheitert es nur mit NLA, liegt die Ursache fast immer in CredSSP/SSPI (Kerberos/NTLM), Zeit oder Policies.
Auf dem Server (Session Host): Ereignisanzeige prüfen: Windows-Protokolle → Sicherheit (4624/4625) und Anwendungs- und Dienstprotokolle → Microsoft → Windows → TerminalServices-*. Ein 4625 mit Logon Type 10 bedeutet: Verbindung kam bis zur Windows-Anmeldung, scheitert aber an Credentials/Rechten/Policy.
Wenn RD Gateway genutzt wird: zuerst RDG-Logs prüfen (TerminalServices-Gateway) und NPS (falls aktiv). Wenn das Gateway abweist, erreicht die Anmeldung am Session Host häufig nie statt.
Wenn es nach der Anmeldung hängt (Willkommen/Black Screen): Fokus auf Profil/GPO/FSLogix/Dateidienst, nicht auf Kerberos oder Netzwerkports.

Technische Kette vom RDP-Verbindungsaufbau bis zur Windows-Sitzung

Zwischen dem ersten Verbindungsversuch und einer nutzbaren Sitzung liegen mehrere deterministische Phasen. Jede Phase hat typische Logs, typische Fehlerarten und typische Abhängigkeiten. Das Ziel ist, die Störung nicht über den Text in mstsc.exe zu interpretieren, sondern über die Phase, in der sie entsteht.

Phase	Was technisch passiert	Wo prüfen	Typischer Break-Indikator
1. Netzwerk und Namensauflösung	DNS-Auflösung, Routing, Firewall, Erreichbarkeit TCP/UDP	Client: `Resolve-DnsName`, `Test-NetConnection`, Firewall/NAT	Port nicht erreichbar, falsche IP, Timeout
2. RDP-Negotiation und Transport-Sicherheit	RDP-Protokoll verhandelt Security Layer (typisch TLS), optional UDP-Optimierung	Client-Eventlog TerminalServices-Client*, Server: Schannel/System	Zertifikat/TLS-Handshake scheitert, Verschlüsselung/Policy blockiert
3. NLA / CredSSP / SSPI	Vorab-Authentifizierung über CredSSP (SSPI: Kerberos oder NTLM)	Client: TerminalServices-ClientActiveXCore, Server: Security 4625 (vor/bei Logon), Kerberos/LSA-Events	Abbruch vor vollständiger Sitzung, CredSSP-/NLA-Fehlerdialog
4. Windows-Logon und Rechte	LSASS authentifiziert und erstellt Token; LSA prüft Logon Type 10-Rechte	Server: Security 4624/4625, Lokale Sicherheitsrichtlinie/GPO	`STATUS_LOGON_FAILURE`, `STATUS_LOGON_TYPE_NOT_GRANTED`
5. RDS-Rollenlogik (Farm)	Gateway CAP/RAP, Broker-Zielzuweisung, Licensing-Handshake	RDG: TerminalServices-Gateway, NPS; Broker/Licensing-Events	Policy-Ablehnung, Reconnect-Fehler, Lizenz-Disconnect
6. Benutzerumgebung	Profil laden (lokal/roaming/FSLogix), GPO, Shell/RemoteApp	ProfSvc, GroupPolicy, FSLogix-Logs, SMB/Storage	Willkommen hängt, temporäres Profil, sofortige Abmeldung

Phase 1: Netzwerk, DNS und Portpfad (direkt vs. über RD Gateway)

RDP funktioniert nur, wenn der Client den Zielendpunkt korrekt erreicht. Direktverbindungen nutzen typischerweise TCP 3389 (und je nach Konfiguration zusätzlich UDP 3389 für Performance). Bei Zugriff über RD Gateway läuft der erste Hop als HTTPS über TCP 443 zum Gateway; der zweite Hop ist RDP vom Gateway zum Session Host (intern meist TCP 3389, optional UDP). Viele „RDP-Fehler“ sind in Wahrheit DNS- oder Firewall-Themen.

Konkrete Prüfungen auf dem Client:

DNS-Auflösung prüfen: Resolve-DnsName SERVERFQDN. Bei Farm-/Alias-Namen zusätzlich CNAME/A-Record-Kette prüfen, damit nicht auf einen falschen Host verbunden wird.
Porttest direkt: Test-NetConnection SERVERFQDN -Port 3389. Wenn das fehlschlägt, ist alles Weitere (CredSSP, Kerberos, Rechte) zweitrangig, weil die Sitzung technisch nie beginnt.
Porttest RD Gateway: Test-NetConnection RDGATEWAYFQDN -Port 443. Wenn 443 nicht erreichbar ist, wird RDG niemals arbeiten – unabhängig von Benutzerrechten.
Wenn die IP stimmt, aber der Port nicht: Server-seitig prüfen, ob der Dienst lauscht: Get-NetTCPConnection -LocalPort 3389 -State Listen (Server) und ob Windows Defender Firewall bzw. Netzwerkfirewall den Pfad blockiert.

Typische Praxisfehler und direkte Gegenmaßnahmen:

DNS zeigt auf alte IP nach Migration: DNS-Record korrigieren, TTL beachten, Client-DNS-Cache leeren: ipconfig /flushdns.
Verbindung nur intern möglich: Split-DNS oder NAT-Regeln prüfen; bei Gatewayzugriff den öffentlichen Namen ausschließlich auf den Gateway-Endpunkt zeigen lassen.
Port offen, aber Disconnect sofort: dann ist es meistens TLS/NLA/Policy, nicht das Netzwerk selbst.

Phase 2: TLS, Zertifikate und RDP-Sicherheitslayer

Moderne Windows-Umgebungen nutzen für RDP typischerweise TLS. Zertifikats- und TLS-Probleme zeigen sich clientseitig oft als generische Verbindungsabbrüche oder als Zertifikatswarnung, serverseitig aber als Schannel-/TLS-Handshakefehler. Bei RD Gateway ist ein gültiges TLS-Zertifikat zwingend, weil der Client per HTTPS (443) verbindet. Bei direktem RDP ist ein Zertifikat ebenfalls relevant, wenn TLS erzwungen wird oder NLA genutzt wird (NLA baut auf einer gesicherten Verbindung auf).

Konkrete Prüfpunkte für „Zertifikat stimmt nicht / nicht vertrauenswürdig“:

Name muss passen: Der Name, mit dem verbunden wird, muss im Zertifikat als CN oder SAN enthalten sein (FQDN-Alias-Namen sind ein häufiger Stolperstein).
Zertifikat muss für Serverauthentifizierung geeignet sein (EKU „Server Authentication“) und gültig (nicht abgelaufen) sein.
Vertrauenskette muss auf dem Client vollständig vertrauenswürdig sein (Root/Intermediate). In Unternehmen ist das oft ein Thema bei internen CAs oder bei fehlenden Intermediate-Zertifikaten am Server.
Wenn Zertifikate scheinbar „plötzlich“ scheitern: Uhrzeit/Zeitzone und Revocation-Erreichbarkeit prüfen (CRL/OCSP kann in restriktiven Netzen scheitern und je nach Policy Handshakes beeinflussen).

Serverseitig ist für TLS-Probleme die Ereignisanzeige zentral: Windows-Protokolle → System (Quelle Schannel). Dort lassen sich Handshakeabbrüche, Protocol-Mismatch (z. B. harte TLS-Härtung) und Zertifikats-/Kettenfehler deutlich besser eingrenzen als über den mstsc-Dialog.

Phase 3: NLA, CredSSP, SSPI – Kerberos oder NTLM vor der Sitzung

NLA (Network Level Authentication) verlagert die Authentifizierung vor den vollständigen Aufbau der interaktiven Sitzung. Technisch nutzt Windows dafür CredSSP, das wiederum über SSPI (Security Support Provider Interface) Kerberos bevorzugt und nur bei Bedarf auf NTLM ausweicht. Das ist aus Sicherheits- und Ressourcenperspektive sinnvoll, aber es macht die Verbindung empfindlicher gegenüber Zeitdrift, DNS/SPN-Problemen und Sicherheitsrichtlinien.

Praxisregel: Wenn eine Verbindung ohne NLA funktioniert, mit NLA aber scheitert, liegt die Ursache fast immer in CredSSP/SSPI (Kerberos/NTLM), Zeit, SPN/DNS oder in Richtlinien (z. B. NTLM-Restriktion), nicht im RDP-Dienst selbst.

Kerberos: SPN und Name müssen zusammenpassen

Kerberos benötigt einen eindeutigen Service Principal Name (SPN) für den Dienst, zu dem verbunden wird. Für RDP ist das typischerweise TERMSRV/hostname bzw. TERMSRV/FQDN. Wenn über Alias-Namen (CNAME) verbunden wird, aber kein passender SPN existiert, scheitert Kerberos oder fällt auf NTLM zurück – und genau dieser Fallback kann in gehärteten Domänen blockiert sein.

Konkrete Prüf- und Diagnosekommandos:

Auf einem Domänen-Admin-System: setspn -Q TERMSRV/SERVERNAME und setspn -Q TERMSRV/SERVERFQDN.
Wenn Alias genutzt wird (z. B. rds.firma.tld): setspn -Q TERMSRV/rds.firma.tld prüfen. Fehlt er, muss die SPN-Planung sauber erfolgen (insbesondere: doppelte SPNs vermeiden).
Auf dem Client: klist zeigt, ob ein TGT vorhanden ist und welche Tickets gezogen wurden. Wenn ein Ticket für TERMSRV/... nie ausgestellt wird, ist der Kerberos-Pfad praktisch nicht zustande gekommen.

Typische Fehlerbilder, die in diese Kategorie fallen:

Kerberos meldet sinngemäß „Principal unknown“: meist falscher Zielname oder fehlender/doppelter SPN. In der Praxis ist der Auslöser häufig ein DNS-Alias ohne SPN oder ein Umzug des Dienstkontos/Computerobjekts.
Kerberos scheitert nur sporadisch: oft DNS-Splitbrain (abwechselnde Auflösung auf unterschiedliche Hosts), DC-Erreichbarkeitsprobleme oder Zeitabweichungen.

Zeitdrift: ein einzelnes Problem, das Kerberos und Zertifikate gleichzeitig bricht

Kerberos toleriert nur eine geringe Zeitabweichung zwischen Client, Server und Domain Controller. Zusätzlich kann eine falsche Uhrzeit Zertifikatsprüfungen scheitern lassen (gültig/ungültig). Das ist einer der häufigsten „Kettenauslöser“, weil er mehrere Symptome gleichzeitig produziert.

Konkrete Prüfungen:

Client/Server: w32tm /query /status (Quelle, Offset, Sync-Status).
Client gegen DC: w32tm /stripchart /computer:DC-FQDN /dataonly /samples:5 (sichtbarer Drift in Sekunden).

NTLM-Fallback: funktioniert nur, wenn er erlaubt ist

Wenn Kerberos nicht zustande kommt, weicht SSPI häufig auf NTLM aus. In vielen Umgebungen ist NTLM jedoch eingeschränkt oder teilweise verboten. Dann entsteht ein typischer Effekt: „Früher ging es noch“, bis eine Härtungsrichtlinie NTLM weiter reduziert hat. Die Folge sind generische NLA/CredSSP-Fehler, obwohl Netzwerk, RDP-Dienst und Credentials korrekt sind.

Konkreter Tipp zur Eingrenzung: Wenn Verbindungen nur mit FQDN funktionieren, nicht aber mit Kurzname oder Alias, ist das sehr häufig ein Kerberos/SPN-Thema. Wenn Verbindungen nur noch aus bestimmten Netzen/Clients scheitern, ist es häufig Policy (NTLM, TLS-Härtung, CredSSP) oder Zertifikat/Trust.

CredSSP-„Oracle Remediation“: typischer Patchstand-Mismatch

Der bekannte CredSSP-Fehlerdialog („Authentifizierungsfehler… Funktion wird nicht unterstützt“) ist in der Praxis meist eine Kombination aus Patchstand und Policy. Der Client stuft den Server als nicht ausreichend abgesichert ein und blockiert die Credential-Delegation. Die nachhaltige Lösung ist nicht „NLA ausschalten“, sondern Patchstand und Richtlinien konsistent machen.

Nachhaltig: Server und Clients auf einen aktuellen Patchstand bringen.
Policy nur als kontrollierte Übergangslösung: Gruppenrichtlinie „Encryption Oracle Remediation“ (unter Anmeldeinformationen delegieren) sauber dokumentieren und zeitnah zurückhärten.

Phase 4: Windows-Anmeldung und Autorisierung (Logon Type 10)

Wenn Transport, TLS und NLA erfolgreich sind, folgt die eigentliche Windows-Anmeldung. Hier unterscheiden sich zwei Dinge, die in der Praxis oft vermischt werden: Authentifizierung (ist der Benutzer echt?) und Autorisierung (darf er sich auf diesem Weg anmelden?). RDP-Interaktiv entspricht in der Regel Logon Type 10 (RemoteInteractive). Genau hier entscheidet das Benutzerrecht „Anmelden über Remotedesktopdienste zulassen“ sowie eventuelle Deny-Regeln.

Konkrete Diagnose am Session Host:

Ereignisanzeige: Windows-Protokolle → Sicherheit nach 4625 (Fehllogons) und 4624 (Erfolgslogons) filtern. Logon Type 10 bestätigt, dass der Versuch bis zur Windows-Anmeldung gelangt ist.
Wenn 4625 vorhanden ist: die Felder Status und SubStatus sind die fachlich belastbare Quelle (nicht der mstsc-Text).
Benutzerrechte prüfen (lokal oder via GPO): secpol.msc → Lokale Richtlinien → Zuweisen von Benutzerrechten → „Anmelden über Remotedesktopdienste zulassen“ und „… verweigern“.
Effektive Richtlinie nachvollziehen: gpresult /h C:\Temp\gp.html (Server) und die relevante GPO identifizieren.

Typischer Status	Was es bedeutet	Konkrete Maßnahme
`0xC000006D` / `STATUS_LOGON_FAILURE`	Authentifizierung fehlgeschlagen (allgemein)	SubStatus aus 4625 auswerten; gespeicherte Credentials im Client prüfen; UPN/SAM-Format konsistent nutzen
`0xC000006A` / `STATUS_WRONG_PASSWORD`	Passwort falsch	Gespeicherte Anmeldeinformationen (Credential Manager) bereinigen; Account-Lockout-Kette prüfen
`0xC0000234` / `STATUS_ACCOUNT_LOCKED_OUT`	Konto gesperrt	Lockout-Quelle finden (alte Dienste, Tasks, gespeicherte RDP-Creds); Entsperren und Ursache abstellen
`0xC0000071` / `STATUS_PASSWORD_EXPIRED`	Passwort abgelaufen	Passwortwechsel über geeigneten Pfad (z. B. lokal/VDI/Portal); NLA kann Passwortwechsel-UI verhindern
`0xC000015B` / `STATUS_LOGON_TYPE_NOT_GRANTED`	Benutzer darf sich per RDP nicht anmelden	Benutzerrecht `SeRemoteInteractiveLogonRight` korrekt setzen; Deny-Regel prüfen
`0xC000018D` / `STATUS_TRUST_FAILURE`	Secure Channel/Vertrauen des Computers gestört	Domänenvertrauen/Maschinenkonto prüfen (Netlogon/Secure Channel); besonders nach Snapshots/Migrationen

Phase 5: RD Gateway, NPS, Connection Broker, Licensing – klare Abgrenzung statt Vermischung

In Farmen ist entscheidend, ob der Fehler vor dem Session Host entsteht (Gateway/NPS), bei der Zuweisung (Broker) oder nach Annahme (Licensing). Jede Rolle hat eigene Logs. Eine Gateway-Ablehnung ist keine falsche Windows-Anmeldung am Zielserver, und ein Licensing-Disconnect ist kein Kerberos-Problem.

RD Gateway: CAP/RAP-Entscheidungen und Erreichbarkeit der Zielressource

RD Gateway baut zuerst den HTTPS-Tunnel Client↔Gateway auf und entscheidet dann über Policies: Connection Authorization Policy (CAP) und Resource Authorization Policy (RAP). Erst wenn CAP/RAP passt, versucht das Gateway die Verbindung Gateway↔Zielhost. Daraus folgt eine sehr praktische Diagnose-Reihenfolge: Wenn der Client eine Gateway-Richtlinie nennt, ist das Thema im Gateway/NPS; wenn der Client sagt, der Gateway könne den Remotecomputer nicht erreichen, ist es der zweite Hop (Firewall/DNS/Port/Hostdienst).

Konkrete Logs:

Gateway: Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows → TerminalServices-Gateway.
NPS (wenn genutzt): NPS-Ereignisse/Logs (RADIUS Access-Accept/Reject) und Policy-Match-Reihenfolge prüfen.

Connection Broker: Zuweisung, Reconnect und „keine Hosts verfügbar“

Der Broker entscheidet, auf welchen Session Host verbunden wird und ob eine bestehende Sitzung wiederverbunden wird. Fehler in dieser Schicht wirken für Clients häufig wie „Server nicht erreichbar“ oder „Verbindung getrennt“, obwohl Netzwerkpfade zu einzelnen Hosts funktionieren. Hier ist die technische Kernfrage: Hat der Broker einen gesunden Host in der Sammlung und kann er den Benutzer konsistent zuordnen?

Praktischer Tipp: Wenn direkte Verbindungen zu einem Session Host funktionieren, Verbindungen über die Sammlung/Broker aber nicht, ist das ein starkes Indiz für Broker-/Sammlungszustand (oder DNS/Cert-Mismatch zum Broker-Namen), nicht für Kerberos oder Passwort.

RD Licensing: typische „sofortiger Disconnect“-Symptome

Lizenzierungsprobleme zeigen sich häufig als sehr kurzer Erfolg (Sitzung beginnt) und dann ein schneller Disconnect oder eine Meldung über fehlende Lizenzen bzw. Lizenzierungsmodus. Das ist in der Praxis oft zeitverzögert, weil Kulanzfristen (Grace Period) eine Zeit lang „Kaschierung“ erzeugen.

Konkrete Prüfpunkte:

Auf dem Session Host: ist der Lizenzierungsmodus korrekt konfiguriert (Per User/Per Device) und zeigt auf den richtigen Lizenzserver (häufig per GPO gesetzt)?
Auf dem Lizenzserver: Dienststatus, Aktivierung, Erreichbarkeit (DNS/Firewall) und Logs.
Wenn nur einzelne Hosts betroffen sind: GPO-Anwendung und lokale RDSH-Konfiguration vergleichen.

Phase 6: Profil, Gruppenrichtlinien, FSLogix – wenn es „nach dem Logon“ scheitert

Wenn Authentifizierung und Autorisierung erfolgreich sind, aber der Benutzer bei „Willkommen“ hängt, einen schwarzen Bildschirm sieht oder in einem temporären Profil landet, liegt die Ursache in der Regel in der Benutzerumgebung: Profil laden (lokal/roaming/FSLogix), Zugriff auf Profilpfade, gesperrte Registry-Hives (NTUSER.DAT), langsame/instabile SMB-Backends, Logon-Skripte oder GPO-Client-Verarbeitung. Diese Klasse von Fehlern wird häufig fälschlich als „RDP-Probleme“ behandelt, obwohl die RDP-Verbindung selbst technisch bereits steht.

Konkrete, sehr praktische Prüfschritte:

Security 4624 vorhanden? Dann ist die Anmeldung grundsätzlich gelungen. Ab hier Fokus: ProfSvc/GroupPolicy/Application.
ProfSvc-Events prüfen (User Profile Service). Bei temporären Profilen die Ursache ist fast immer Zugriff/Locking auf Profilpfad oder defekte Profilstruktur.
Wenn FSLogix genutzt wird: FSLogix-Logs auf dem Session Host prüfen (Mount/Attach/SMB-Zugriff). Häufigste Ursachen sind Rechte auf Share, Offline/Latency, Locks oder fehlende Erreichbarkeit des Storage.
GPO-Verarbeitung messen: gpresult /r bzw. gpresult /h und Ereignisse des GroupPolicy-Clients prüfen. Ein einziges blockierendes Logon-Skript kann eine komplette Farm „wie eingefroren“ wirken lassen.

Fehlermeldungen und Statuscodes: Zuordnung nach Phase, nicht nach Bauchgefühl

Viele RDP-Dialogtexte sind Sammelmeldungen. Aussagekräftig werden sie erst, wenn sie mit der Phase und den passenden Logs korreliert werden. Die folgenden Zuordnungen sind so formuliert, dass sie direkt zu einem nächsten Prüfschritt führen.

Was der Nutzer sieht	Wahrscheinlichste Phase	Was als Nächstes konkret geprüft wird
Timeout / „Remotecomputer reagiert nicht“	Netz/DNS/Port	`Resolve-DnsName`, `Test-NetConnection`, Firewallregeln, Server lauscht auf 3389/443
Zertifikatswarnung / Name passt nicht	TLS/Zertifikat	Verbindungsname vs. CN/SAN, Kette/Intermediate, Ablaufdatum, Schannel-Events
„Authentifizierungsfehler“ / CredSSP	NLA/CredSSP	Zeit (`w32tm`), SPN (`setspn -Q TERMSRV/...`), NTLM-Policy, Patchstand
„Der Benutzername oder das Kennwort ist falsch“	Windows-Logon	Server: 4625 SubStatus, gespeicherte Credentials, UPN/SAM-Format, Lockout
„Der Benutzer verfügt nicht über den angeforderten Anmeldetyp“	Autorisierung	`SeRemoteInteractiveLogonRight` / Deny-Regeln per GPO prüfen
„Gateway-Richtlinie hat abgelehnt“	RD Gateway/NPS	TerminalServices-Gateway-Events, CAP/RAP, NPS Policy-Match
Sofortiger Disconnect nach Logon / Lizenzmeldung	Licensing	Lizenzmodus, Lizenzserver, GPO, Erreichbarkeit, Licensing-Events
„Willkommen“ hängt / schwarzer Bildschirm / temporäres Profil	Benutzerumgebung	ProfSvc, GPO-Client, FSLogix, SMB/Storage, Logon-Skripte

Konkrete Log- und Eventquellen, die in der Praxis den Unterschied machen

Für eine schnelle Ursachenbestimmung ist es hilfreich, sich pro Rolle die zwei bis drei wichtigsten Protokollpfade zu merken. Damit lässt sich in Minuten entscheiden, ob die Störung „vor dem Server“, „am Server“ oder „nach dem Logon“ liegt.

Client: Anwendungs- und Dienstprotokolle → Microsoft → Windows → TerminalServices-ClientActiveXCore (Clientseitige RDP/NLA-Hinweise).
Session Host: Windows-Protokolle → Sicherheit (4624/4625, Logon Type 10), plus TerminalServices-* Kanäle für Sitzungsannahme.
TLS/Handshake: Server Windows-Protokolle → System (Schannel).
RD Gateway: Microsoft → Windows → TerminalServices-Gateway.
NPS/RADIUS: NPS-Ereignisse (Access-Accept/Reject) und Policy-Match (wenn RDG über NPS authentifiziert/autorisiert).
Profil/Logon-Probleme: ProfSvc (User Profile Service), GroupPolicy-Events, optional FSLogix-Logs.

Praxis-Tipps, die häufig sofort helfen

Immer mit dem Namen verbinden, der fachlich korrekt ist: Wenn Zertifikat und SPN auf FQDN ausgelegt sind, konsequent FQDN nutzen. Alias-Namen sind möglich, müssen aber in Zertifikat (SAN) und SPN-Design sauber mitgezogen werden.
Bei plötzlichen, flächigen Ausfällen nach Änderungen: zuerst Zeit (w32tm), DNS (Records), TLS-Härtung (Schannel) und NTLM-Policy prüfen. Diese vier Kategorien erklären einen Großteil „plötzlicher“ RDS-Probleme ohne dass am RDS selbst etwas verändert wurde.
Wenn nur einzelne Nutzer betroffen sind: Security 4625 (SubStatus) und Lockout-Situation prüfen, gespeicherte Credentials (Windows-Anmeldeinformationsverwaltung) bereinigen, parallele Services/Tasks mit denselben Konten kontrollieren.
Wenn nur einzelne Hosts betroffen sind: Konfiguration vergleichen (GPO, Zertifikate, Licensing-Settings, lokale Benutzerrechte). In Farmen ist „Drift“ zwischen Hosts eine sehr häufige Ursache.
Wenn es „nach Login“ hängt: Profilpfade/Storage zuerst. Ein einziges langsames SMB-Backend oder ein blockierendes Logon-Skript wirkt für Anwender wie ein RDP-Ausfall, obwohl Netzwerk und Auth korrekt sind.

Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden

Kostenfreie Ersteinschätzung Ihres Anliegens?

❱ Nehmen Sie gerne Kontakt auf ❰

Werbung

UGREEN Revodok 105 USB C Hub PD100W, 4K HDMI, 3*USB A Datenports USB C Adapter Multiportadapter kompatibel mit iPhone 17/16, Galaxy S24, Surface, MacBook Pro/Air, iPad Pro/Air, Steam Deck usw.^ℹ︎

UVP**: € 16,99

€ 14,99

Auf Lager

Preise inkl. MwSt., zzgl. Versandkosten