[English]Frage in die Runde der Administratoren, die noch mit Windows Server 2016 unterwegs sind. Mir liegt ein Bericht vor, dass nach dem Einspielen von Windows Updates auf einem Domain Controller (DC) Probleme auftauchen. Im Anschluss gibt es Konnektivitätsprobleme mit den Remote Desktop Services (RDS). Spannend wäre nun zu wissen, ob es Einzelfall ist oder ob es weitere Betroffene gibt. Hier die Beschreibung des Falls.
Eine Lesermeldung
Blog-Leser Patrick administriert in einem Unternehmen auch zwei Windows Server 2016. Dabei kämpft er seit Monaten mit Problemen, die sich aus Updates ergeben. Er hatte, laut seiner Aussage, vor rund 4 Monaten zuletzt die beiden Domain Controller (DCs) auf die neuesten Sicherheitsupdates aktualisiert. Nach jedem dieser Updates lief er aber im Ergebnis in RDS-Verbindungsprobleme.
- Alle rund 24 RDS-Server haben im Anschluss an eine Update-Installation eine eingeschränkte Netzwerkkonnektivität.
- Fehlerbild: Netzwerkicon mit Ausrufezeichen, Anmeldeversuch schlägt fehl mit „Es stehen keine Anmeldeserver zur Verfügung“.
- Nach Deinstallation des damaligen Updates funktionierte die Anmeldung wieder.
Inzwischen hatten wir Mai 2024 und die DCs sollten langsam mal die aktuellen kumulativen Sicherheitsupdate bekommen. Patrik meinte dazu: Nun dachte ich mir vergangenen Freitag, dass wohl inzwischen genug Zeit vergangen sein sollte und die Probleme möglicherweise behoben sind. Diese Annahme war aber gedacht. Nachdem Patrick am Freitag letzter Woche (muss der 31. Mai 2024 gewesen sein) gegen 23 Uhr beide DC aktualisiert und neu gebootet hatte, glaubte er, mit den Patches durch zu sein. Am Samstagmorgen gab es Anrufe mehrerer Filialen, die berichteten, dass sie sich nicht am DC anmelden können.
Diese Updates sind betroffen
Zur gescheiterten Update-Installation gibt Patrick an, dass er die nachfolgenden Updates auf den Windows Server 2016 Domain Controllern (DCs) installiert habe.
- KB5037016; Servicing Stack Update (SSU): Dieses Update kann nicht mehr deinstalliert werden
- KB5027219; Kumulatives Sicherheitsupdate Juni 2023, siehe Patchday: Windows 10-Updates (13. Juni 2023)
- KB5037763; Kumulatives Sicherheitsupdate Mai 2024, siehe Patchday: Windows 10/Server-Updates (14. Mai 2024)
Dass Servicing Stack Update kann ja nach der Installation nicht mehr deinstalliert werden. Aber die beiden kumulativen Sicherheitsupdates KB5027219 und KB5037763 sind deinstallierbar. Patrick hat das gemacht, was so mit einem Aufwand von einer Stunde verbunden war. Im Anschluss liefen die Server wieder und die RDS-Verbindungsprobleme waren weg.
Der Blog-Leser schreibt dazu: „Ich habe wirklich viele Stunden damit verbracht, das Problem zu ermitteln. Aber weder in Ihrem Blog noch im Netz habe ich Informationen zu dem Problem gefunden. Ob das wirklich nur in unserer Umgebung auftritt?“ Meine Interpretation des Sachverhalts ist die, dass es bereits seit der 2. Hälfte 2024 zu Problemen mit den RDS-Verbindungen im Zusammenhang mit Update-Installationen gekommen sein muss.
Leider hat der Leser keine weiteren Informationen, z.B. was in der Ereignisanzeige dazu einläuft, mitgeliefert. Von Microsoft gibt es diesen Support-Beitrag von Dezember 2023, der ein spezielles Szenario beschreibt. Und hier im Blog gibt es den Beitrag RDS Probleme nach Windows Update KB5015808 mit einer Beschreibung einer ähnlichen Problematik. Im Hinterkopf spuckt auch noch „kann es was in Bezug auf Kerberos-Hardening sein?“ herum, ich kann es aktuell aber nicht „fassen“. Und damit gebe ich die Problembeschreibung an die Leserschaft weiter. Hat jemand ähnliche Probleme schon mal beobachtet?
Ähnliche Artikel:
Patchday: Windows 10-Updates (13. Juni 2023)
Patchday: Windows 10/Server-Updates (14. Mai 2024)
Moin,
kann ich nicht bestätigen. 2016er sowohl Remotedesktop als auch Terminalserver konfig´s haben keine Probleme. DC ist ein 2019. Alles auf dem aktuellsten Patchstatus.
Wir konnten in o.g. Konfiguration keine Probleme feststellen.
Ich frage mich, warum man solch wichtige Updates nicht monatlich installiert. Möglicherweise sind die 2016er Terminalserver auch so lange nicht aktualisiert worden und das führt nun zu Kolissionen mit den nun aktualisierten DCs.
Auch wir haben noch 25 DC mit Windows 2016 im Einsatz… jedoch ohne diese genannte Problematik
Hi,
hier auch zwei DC’s (2016 STD 1607 B.14393.6981)
ohne RDS-Probleme mit KB5037763.
Es wäre schon sinnvoll zu wissen was der Eventlog sagt, warum das Netzwerk Icon ein Ausrufezeichen trägt.
Manchmal hilft auch der Befehl „net“ weiter….
Einfach mal gucken, was denn überhaupt kaputt
Ja, es ist mühsam sich durch einen Event log durchzuarbeiten.
Aber, ich sage es sehr nett, es ist schon sehr optimistisch zu hoffen das wer anders den Fehler auch schon hatte und lösen konnte und hier liest und Lust hat zu antworten…
Andererseits zeigt es die totale Hilflosigkeit ggu MS.
MS gibt eigne Logfiles nur gegen viel Geld raus.
Da muss doch jeder die Beine in die Hand nehmen, wenn er so erpresst werden soll?
Was hat das denn jetzt schon wieder mit Erpressung durch MS zu tun, wenn jemand seine Eventlogs nicht liest? Die sind ja da und reichen je nach eingestellter Größe und Anzahl der Events pro Zeiteinheit teils Monate zurück. Außerdem die Unterstellung, dass er noch nicht in die Eventlogs reingeschaut hat?
Wir haben 3 Windows 2016 DCs bei welchen die Updates KB5037016, KB5037763 installiert wurden ohne, dass es irgendwelche Probleme gab. Das Update KB5027219 ist entweder so alt, dass es nicht mehr ersichtlich ist in der History oder wir hatten dieses übersprungen.
Bei mir das gleiche Setup ohne Probleme. Vermute einen Dritthersteller oder eine Security Lösung die das Problem verursacht… oder eine eigenwillige DC Konfiguration.
Moin,
bin mir über den Zusammenhang noch nicht ganz sicher, aber wir hatten 1x 2016 Member Server (kein DC), dessen Webanwendung nach dem Update nicht mehr funktionierte.
Im Eventlog konnte ich sehen, dass keine TLS Verbindung zustande kam.
Nach Konfiguration von TLS 1.2 inkl. entspr. Cipher Suites und dazugehöriger Reihenfolge, funktionierte es wieder im Edge via Client PC.
Allerdings hatte ich dann auch Probleme per RDP auf den Server zu kommen.
Nach etwas Recherche und Konzentration bei der Anpassung der Wahl und Reihenfolge der Cipher Suites, ging dann beides wieder.
Kp, ob das hilft, aber vllt nen Versuch wert.
Liebe Grüße aus Hamburg
Ah Mist, das gleiche habe ich hier auch.
Habe schon die Zertifikate verbogen und das Teil erstmal ganz kaputt gemacht.
Danke für den Hinweis. Muss jetzt ein Rollback machen.
Moin,
Rollback war bei mir nicht nötig, nur halt spontan etwas näher mit TLS Config und Cipher Suites beschäftigen… :D
Brauchst du die Registry Infos?
Es gibt ja nicht nur Eventlogs.
Warum zeigt das Netzwerk einen harten Fehler an?
„das Netzwekicon hat ein Ausrufezeichen“ ist doch keine Aussage.
Da guckt man doch erstmal warum das Netzwerk unpässlich ist, oder?
Der Anmelde Fehler wird am kaputten Netzwerk liegen.
„weil das Update eingespielt wurde“ ist nicht die Antwort.
Beim Netzwerk Icon mit Ausrufezeichen kann es eventuell ein IPv6 Problem sein, Windows hat Prefer IPv6 und als DNS den loopback eingetragen. allerdings ist mir nicht klar aus dem Text wo die Meldung kommt auf dem TS oder DC nach dem Update. und haben die TS das Update und nur auf dem DC fehlt das noch. Währe dann aber trotzdem als erstes DNS prüfen :)
IPv4 gegenüber IPv6 zu bevorzugen ist ein Registrykey (DisabledComponents=0x20) oder ein Netshell-befehl (netsh int ipv6 set prefixpolicy ::ffff:0:0/96 50 0) und sollte sowieso in der Domainpolicy verankert sein.
Wenn IPv6 vorhanden ist sollte es zumindest soweit auskonfiguriert sein, daß die Konnektivität untereinander gegeben ist, also ein SLAAC sinnvolle Ergebnisse bringt. Ungünstig ist es, wenn nur auf einem Teil (z.B. den Arbeitsstationen) IPv6 aktiv ist und richtig böse wird es, wenn irgend ein Gerät (z.B. eine Fritz!Box) Adressen vergibt, die der Server nicht sieht.
„localhost“ als Default in der DNS-Liste habe ich bisher nur auf DCs gesehen, auf denen auch der DNS-Dienst installiert wurde, auf dem Terminalserver hat das nichts zu suchen.
ipv6 ausschalten, reboot, ipv4 kontrollieren, dcdiag: testdns. Alles grün?
Server 2016 eben, eine Wundertüte. Sollte aber mittlerweile bekannt sein. ;-)
Das klingt nach einem guten Plan.
Das Problem ist ja nicht „RDP geht nicht“ sondern „Netzwerk kaputt nach Update“.
Ich finde es besser, jemanden zu zeigen wie man fischt,als ihm jeden Tag nur eine neue Angel zu verkaufen, auch wenn das natürlich lukrativer und heute üblicher ist.
Wie gesagt, der Eventlogo kann einen erstmal erschlagen und es steht nur selten schon gleich die Lösung drin, aber wenn es TLS Probleme gibt, oder auch nur die Uhrzeit nicht synchronisiert werden kann, dann findet da man etwas.
Also bitte erstmal gucken wo das Ausrufezeichen herkommt.
Eine theoretische Möglichkeit wäre, daß ein umfassendes Update gefahren wurde, welches auch die (über WSUS etc. verteilten) Treiber aktualisiert.
Wenn ein Netzwerkkartentreiber aktualisiert wird, hatte ich es schon öfters, daß auch die Netzwerkeinstellungen, Protokollbindungen usw. zurückgesetzt wurden und z.B. statisch vergebene Adressen zu DHCP wurden.
Auch wir verwenden 2016 RDS-Server und haben keine Probleme, trotz wochenaktueller 2022-DCs.
Ggfls. liegt es aber am aktivierten Credential-Guard? Da gab es vor ein paar Monaten auch einen Beitrag auf borncity: https://www.borncity.com/blog/2023/08/22/windows-defender-credential-guard-ursache-fr-windows-11-22h2-rdp-probleme/
Grüße
DR
Tatsächlich hatte ich bei zwei VMs nach dem Update ein Problem mit RDP. Das ließ sich aber relativ schnell beheben.
Ein bisher anhaltendes Problem gibt es nur mit der Anwendung SFirm, was laut deren Support durch das Mai-Update verursacht wurde.
Immer erstmal ein nslookup machen.
Selbst in Domains habe ich schon gesehen, dass eine Fritzbox am anderen Ende des Netzwerks (als Backdoor/Failover gedacht) die DNS Einstellungen von Domain-Clients u. -Servern auf die Fritzbox IPv6 Adresse als DNS-Server gesetzt hat. Da gabs dann keine Kommunikation mit den DCs mehr.
Das hatte wenigstens den Trost, dass ich über IPv6 via Backdoor und Teamviewer noch auf das Netz zugreifen konnte und das Netz von „innen“ von IPv6 befreien konnte.
Dasselbe mit 2 Workgroups und heute mit einem HO-Arbeitsplatz. Das kann man noch hinnehmen, – nicht verstehen, weil sich an den Netzwerken seit 5 Jahren nichts geändert hat.
aber in einer Domain ???
Falls das nicht nur einfache RDP-Verbindungen sind, sondern mit dem ganzen RDS-Gedöns, würde ich mal das RDS-Gateway auf Verdacht setzen.
Das kann nur sein, wenn auf der Fritzbox DHCP aktiviert war. Es liegt dann außerdem ein Mist Netzwerk-Design vor, wenn die Switches mehrere/beliebige DHCP und DNS Quellen zulassen. Das ist begging4trouble:
Irgendwer wird irgendwan mal seine alte Fritzbox von Zuhause mitbringen, weil er nicht genug Ethernet Buchsen hat…
(ja darf er nicht, klar).
Und dann können 10% der Kollegen nicht arbeiten, die nach ihm den PC angeschaltet haben…und der unerfahrene Admin sucht sich den Wolf, weil das nicht bei schief geht und ein ipconfig /all zu viel ist.
Das ist doch der Grund warum man sich teure lvl3 switches gekauft hat, oder nur wegen der hübschen Netzwerk-Diagramme?
Mit ipconfig /all findest du das Problem nicht. Da sind alle in statischer IP-Adresskonfiguration
DHCP: Nein.
Alles ist dort korrekt.
nslookup zeigt den falschen DNS Server
Man braucht aber nicht nur Switches, die DHCP-Snooping und Trusted Ports können, sondern auch jemanden, der das passend konfiguriert. Gerade in „gewachsenen Umgebungen“, in denen sich der Spanning Tree theoretisch dutzende legitime Wege suchen könnten ist das nicht trivial.
Zumindest sollte man aber monitoren, was im Netz passiert, gerade gegen so was wie rouge DHCP. Für IPv4 empfehle ich mindestens Arpwatch, für IPv6 NDPmon.
ist aber menschliches Versagen und ausnahmsweise kein MS Problem
Ja, Fehler machen wir alle. Und wenn man vom Rathaus kommt..
Außer Microsoft, versteht sich.
Ich habe mal sehen können, wie ein Netzwerk aussieht, das von Profis gehärtet wurde aussieht.
Erste und Haupt- Regel:
K.I.S.S. Keep it stupid simple.
Das Ding war „innert“ sicher. Echt toll gemacht.
leider kamen dann wieder die normalen Admins dran, und zimmerten ein Rattenloch nach dem anderen, weil denen einfach nicht klar war, warum das so und genauso richtig gelöst war.
Ich hab das Problem nicht gemacht, sondern gelöst.
Und ich gehe schon davon aus, dass MS dafür verantwortlich ist. Wie kann in einer Domain mit statischen IPs ein Rouge Router die DNS.Einstellungen überschreiben?
Und MS Recommendation ist, IPv6 nicht zu deaktivieren. Das hat auch bis vor ca. 8 Monaten keine Probleme gemacht.
Der erste Befehl ist doch wohl immer:
ipconfig /all | more
da sieht man welche IP DNS etc. Verwendung findet
net share
net show
etc. sollte man kennen.
ist aber cmd.exe, also der „schwarze Bildschirm“ bei dem man in etwa wissen muss, was man machen möchte.
ich vermute, das hier irgendwie ein
Protokoll-Treiber nicht starten konnte. Das sähe man aber im Eventlog…
zweimaliger reboot könnte helfen, damit die Reihenfolge ggf. wieder stimmt.
Jedenfalls:
Solange das Netzwerk nicht problemlos geht, ist alles weitere Zeitverschwendung.
Mit ipconfig /all sieht man nicht, welcher DNS (v4 oder v6) aktuell genutzt wird, sondern nur, welche genutzt werden könnten. Den aktuellen sieht man mit nslookup.