24
Windows 2016 - Anmeldeverzögerung
Hi,
wir haben unter Windows 2016 bei Zugriff via RDP oder ICA in ca. 50% der Anmeldungen eine Verzögerung von dann immer ziemlich genau 23 s.
Den einzigen halbwegs konkreten Hinweis, welchen wir bisher auf den Servern gefunden haben, ist im NETLOGON.log. Dort steht zu den betreffenden Zeitpunkten drin
Der letzte Eintrag vor dem ersten "CRITICAL" ist dann ca. 22-23 s früher.
Ja ich weiß, "local" als TLD. Da brauchen wir jetzt hier nicht drüber zu diskutieren. Das ist so historisch gewachsen.
Für den Anwender äußert sich das so, dass er beim Anmelden am Remotedesktop beim "Willkommen" für diese ca 22 s hängen bleibt. Danach geht es gewohnt weiter.
DCDIAG, NLTEST und Konsorten liefern keine Hinweise auf Fehler oder Probleme.
Wir haben getestet:
Das Verhalten ist immer gleich. Bei ca. der Hälfte der Anmeldeversuche geht es ohne diese Verzögerung (Anmeldung dauert ca. 9-11 s) und bei der anderen Hälfte der Versuche mit dieser Verzögerung (Anmeldung dauert ca. 30-35 s). Und diese Fälle sind dann auch schön ungleichmäßig verteilt.
Im Web haben wir bisher nichts hilfreiches gefunden. DNS und AD haben wir überprüft, wir finden keine Fehler.
Wenn die Verzögerung nicht auftritt, dann tauchen im NETLOGON.log aus den o.g. Zeilen die beiden CRITICAL nicht auf.
Hat jemand eine Idee oder kennt es sogar aus eigener Erfahrung?
E.
wir haben unter Windows 2016 bei Zugriff via RDP oder ICA in ca. 50% der Anmeldungen eine Verzögerung von dann immer ziemlich genau 23 s.
Den einzigen halbwegs konkreten Hinweis, welchen wir bisher auf den Servern gefunden haben, ist im NETLOGON.log. Dort steht zu den betreffenden Zeitpunkten drin
05/07 11:31:30 [MISC] [11256] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c0fffff1
05/07 11:31:52 [CRITICAL] [11256] NetpDcGetNameIp: xxx-DC03.xxx.local: No data returned from DnsQuery.
05/07 11:31:52 [MISC] [11256] NetpDcGetName: NetpDcGetNameIp for xxx-DC03.xxx.local returned 1355
05/07 11:31:52 [CRITICAL] [11256] NetpDcGetName: xxx-DC03.xxx.local: IP and Netbios are both done.
05/07 11:31:52 [MISC] [11256] DsGetDcName function returns 1355 (client PID=2632): Dom:xxx-DC03.xxx.local Acct:(null) Flags: LDAPONLY RET_DNS
05/07 11:31:52 [SITE] [11256] DsrGetSiteName: Returning site name 'ABCDEFG' from local cache. Ja ich weiß, "local" als TLD. Da brauchen wir jetzt hier nicht drüber zu diskutieren. Das ist so historisch gewachsen.
Für den Anwender äußert sich das so, dass er beim Anmelden am Remotedesktop beim "Willkommen" für diese ca 22 s hängen bleibt. Danach geht es gewohnt weiter.
DCDIAG, NLTEST und Konsorten liefern keine Hinweise auf Fehler oder Probleme.
Wir haben getestet:
- Benutzer mit und ohne vorhandenem lokalen Profil
- Benutzer mit und ohne Roaming Profile
- mit und ohne Umleitung von Clientgeräten (Drucker und Laufwerke)
- mit und ohne Citrix Profile Manager
- mit und ohne Citrix SSO (Bestandteil von Citrix Workspace)
Das Verhalten ist immer gleich. Bei ca. der Hälfte der Anmeldeversuche geht es ohne diese Verzögerung (Anmeldung dauert ca. 9-11 s) und bei der anderen Hälfte der Versuche mit dieser Verzögerung (Anmeldung dauert ca. 30-35 s). Und diese Fälle sind dann auch schön ungleichmäßig verteilt.
Im Web haben wir bisher nichts hilfreiches gefunden. DNS und AD haben wir überprüft, wir finden keine Fehler.
Wenn die Verzögerung nicht auftritt, dann tauchen im NETLOGON.log aus den o.g. Zeilen die beiden CRITICAL nicht auf.
Hat jemand eine Idee oder kennt es sogar aus eigener Erfahrung?
E.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 448222
Url: https://administrator.de/forum/windows-2016-anmeldeverzoegerung-448222.html
Ausgedruckt am: 07.04.2025 um 19:04 Uhr
24 Kommentare
Neuester Kommentar
Moin,
bezieht sich das Problem immer auf die Anmeldung am DC03?
Gruß
Spirit
bezieht sich das Problem immer auf die Anmeldung am DC03?
Gruß
Spirit
Moin,
prüfe mal in den Netzwerkeigenschaften die DNS-Server. Klingt so, als wäre da ein Nicht-DC-DNS mit drin.
Gruß
prüfe mal in den Netzwerkeigenschaften die DNS-Server. Klingt so, als wäre da ein Nicht-DC-DNS mit drin.
Gruß
Nein. Da werden auch andere DC erwähnt. Wir haben 12 Domänen in einem AD und alle DC sind auch GC. Die DC welche dort erwähnt werden, sind aber alle vom AD-Standort des betreffenden Terminalserver.
Hallo.
Ich seh' in gleiche Richtung wie @Spirit-of-Eli . Es gibt einen DC namens "DC03", und wenn die Userauth. an diesem landet, verzögern sich sowohl speziell DNS (der DC03 ist vermutlich auch DNS?) als allgemein auch die Auth. an der Domäne bis zu einem Zeitwert "Critical".
Nimm' den DC03 mal genauer unter die Lupe. Was passiert, wenn Du den mal testweise runterfährst? "DC03" impliziert, daß es noch zwei weitere DCs gibt, die den Job derweil übernehmen könnten.. Sieh' dann nach, ob die Probleme verschwinden (und an welchen DCs die schneller funktionierenden Anmeldungen zum authentifizieren landen). Wenn sich der DC03 als das Problem herausstellt, vergleiche ihn mit den anderen DCs.
Viele Grüße
EDIT:
Nach Deiner Antwort an @Spirit-of-Eli hat sich mein Posting natürlich erledigt, wenn's nicht alleine der DC03 ist, bei dem die Critical-Logs erscheinen.
EDIT2:
Hier hat sich jemand ziemlich ausführlich damit auseinandergesetzt:
https://blog.pohn.ch/der-falsche-anmeldeserver-und-netlogon-5719/
Scheint zumindest nicht TS-spezifisch zu sein, sondern generell langsame Namensauflösungen und Domänenauthentifizierungen zu betreffen. Offenbar ein Netzwerkproblem, und das ist leider ein weites Feld, wie Du besser weißt als ich.
Ich seh' in gleiche Richtung wie @Spirit-of-Eli . Es gibt einen DC namens "DC03", und wenn die Userauth. an diesem landet, verzögern sich sowohl speziell DNS (der DC03 ist vermutlich auch DNS?) als allgemein auch die Auth. an der Domäne bis zu einem Zeitwert "Critical".
Nimm' den DC03 mal genauer unter die Lupe. Was passiert, wenn Du den mal testweise runterfährst? "DC03" impliziert, daß es noch zwei weitere DCs gibt, die den Job derweil übernehmen könnten.. Sieh' dann nach, ob die Probleme verschwinden (und an welchen DCs die schneller funktionierenden Anmeldungen zum authentifizieren landen). Wenn sich der DC03 als das Problem herausstellt, vergleiche ihn mit den anderen DCs.
Viele Grüße
EDIT:
Nach Deiner Antwort an @Spirit-of-Eli hat sich mein Posting natürlich erledigt, wenn's nicht alleine der DC03 ist, bei dem die Critical-Logs erscheinen.
EDIT2:
Hier hat sich jemand ziemlich ausführlich damit auseinandergesetzt:
https://blog.pohn.ch/der-falsche-anmeldeserver-und-netlogon-5719/
Scheint zumindest nicht TS-spezifisch zu sein, sondern generell langsame Namensauflösungen und Domänenauthentifizierungen zu betreffen. Offenbar ein Netzwerkproblem, und das ist leider ein weites Feld, wie Du besser weißt als ich.
Moin,
kannst Du den RDP Zugriff testweise statt per Namen mit der IP starten?
Damit könntest Du zumindest die Namensauflösung definitiv ausschließen.
Gruss
kannst Du den RDP Zugriff testweise statt per Namen mit der IP starten?
Damit könntest Du zumindest die Namensauflösung definitiv ausschließen.
Gruss
Zitat von @sabines:
kannst Du den RDP Zugriff testweise statt per Namen mit der IP starten?
Damit könntest Du zumindest die Namensauflösung definitiv ausschließen.
Das ändert nichts. Wäre ja auch seltsam. Die Verbindung steht doch schon. Was "Willkommen" läuft (steht) doch in der Sitzung.kannst Du den RDP Zugriff testweise statt per Namen mit der IP starten?
Damit könntest Du zumindest die Namensauflösung definitiv ausschließen.
Zitat von @Kraemer:
prüfe mal in den Netzwerkeigenschaften die DNS-Server. Klingt so, als wäre da ein Nicht-DC-DNS mit drin.
Nein, leider nicht. Das wäre jetzt auch zu einfach gewesen ... prüfe mal in den Netzwerkeigenschaften die DNS-Server. Klingt so, als wäre da ein Nicht-DC-DNS mit drin.
No Data returned from DNS Query weist offensichtlich auf ein Problem mit der DNS Auflösung hin.
Ist es möglich, bei allen involvierten Kisten einen festen DNS einzutragen?
Bei der Site Auflösung bekommst du offensichtlich auch nicht rechtzeitig eine verwertbare Aussage zurück, sonst müsste er sie sich nicht aus dem local Cache holen.
Kann es sein das DCs demotet wurden und noch alte Einträge vorhanden sind, oder per netdom Names geadded oder geändert wurden?
Ist es möglich, bei allen involvierten Kisten einen festen DNS einzutragen?
Bei der Site Auflösung bekommst du offensichtlich auch nicht rechtzeitig eine verwertbare Aussage zurück, sonst müsste er sie sich nicht aus dem local Cache holen.
Kann es sein das DCs demotet wurden und noch alte Einträge vorhanden sind, oder per netdom Names geadded oder geändert wurden?
Reverse-DNS geprüft?
Ja, auch alles ok.
Zitat von @rzlbrnft:
No Data returned from DNS Query weist offensichtlich auf ein Problem mit der DNS Auflösung hin.
Jain. Wir haben am DNS-Server das Debug-Log aktiviert. Alle Anfragen von diesen TS werden prompt und fehlerfrei beantwortet.No Data returned from DNS Query weist offensichtlich auf ein Problem mit der DNS Auflösung hin.
Ich tippe hier eher auf einen Bug im Windows. Letzte Analysen haben ergeben, dass diese eine Zeile auch bei Anmeldungen ohne Verzögerung geloggt wird.
Ist es möglich, bei allen involvierten Kisten einen festen DNS einzutragen?
Was würde das ändern?Bei der Site Auflösung bekommst du offensichtlich auch nicht rechtzeitig eine verwertbare Aussage zurück, sonst müsste er sie sich nicht aus dem local Cache holen.
Cache ist hier gut und richtig. By design Microsoft.Kann es sein das DCs demotet wurden und noch alte Einträge vorhanden sind, oder per netdom Names geadded oder geändert wurden?
Nein. Lange her, dass da was gemacht wurde. Wie schon geschrieben, DCDIAG ohne Befund. Auch NLTEST und DNSLINT liefern nichts, was auf Fehler hindeuten würde.
Letzter Stand zum Feierabend war:
Wir haben auf den TS jetzt die Bindung für IPv6 an der NIC wieder aktiviert. Seit dem hatten wir keine Verzögerungen mehr beobachtet. Wir testen morgen früh weiter.
Wir haben auf den TS jetzt die Bindung für IPv6 an der NIC wieder aktiviert. Seit dem hatten wir keine Verzögerungen mehr beobachtet. Wir testen morgen früh weiter.
Hi
GPOs können es nicht sein ?
Mal mit GPresult geschaut wie lange die Abarbeitung dauert ?
In den GPOs etwas was von einem DFSN geholt wird und hier die „Grenzen“ nicht richtig gesetzt wurden sprich holt sich files von einem Server einer anderen AD Site ?
Wenn du schreibst, dass es um 19:30 wieder besser ist ggf. Doch etwas im Netzwerk was hier bremst? Datensicherung, viele Andmeldungen, DNS „Stürme“ oder ähnliches ? Das SAN auf wo deine TS Server liegen ausgelastet ? Generell die virtuelle Umgebung u.a Netzwerlkarte(n) ausgelastet?
Vielleicht auch was banales wie energieschema auf ausgeglichen anstatt auf Höchstleistung in virtueller Umgebung und am Server selbst ?
Mit freundlichen Grüßen Nemesis
GPOs können es nicht sein ?
Mal mit GPresult geschaut wie lange die Abarbeitung dauert ?
In den GPOs etwas was von einem DFSN geholt wird und hier die „Grenzen“ nicht richtig gesetzt wurden sprich holt sich files von einem Server einer anderen AD Site ?
Wenn du schreibst, dass es um 19:30 wieder besser ist ggf. Doch etwas im Netzwerk was hier bremst? Datensicherung, viele Andmeldungen, DNS „Stürme“ oder ähnliches ? Das SAN auf wo deine TS Server liegen ausgelastet ? Generell die virtuelle Umgebung u.a Netzwerlkarte(n) ausgelastet?
Vielleicht auch was banales wie energieschema auf ausgeglichen anstatt auf Höchstleistung in virtueller Umgebung und am Server selbst ?
Mit freundlichen Grüßen Nemesis
Zitat von @emeriks:
Letzter Stand zum Feierabend war:
Wir haben auf den TS jetzt die Bindung für IPv6 an der NIC wieder aktiviert. Seit dem hatten wir keine Verzögerungen mehr beobachtet. Wir testen morgen früh weiter.
Letzter Stand zum Feierabend war:
Wir haben auf den TS jetzt die Bindung für IPv6 an der NIC wieder aktiviert. Seit dem hatten wir keine Verzögerungen mehr beobachtet. Wir testen morgen früh weiter.
Moin,
warum wurde das deaktiviert? Meines Wissens nach, benötigt Windows Server ab 2008 IPv6 auch wenn Du es "offiziel" gar nicht einsetzt. Oder verstehe ich Dich falsch?
Gruss
Zitat von @sabines:
Moin,
warum wurde das deaktiviert? Meines Wissens nach, benötigt Windows Server ab 2008 IPv6 auch wenn Du es "offiziel" gar nicht einsetzt. Oder verstehe ich Dich falsch?
Gruss
Zitat von @emeriks:
Letzter Stand zum Feierabend war:
Wir haben auf den TS jetzt die Bindung für IPv6 an der NIC wieder aktiviert. Seit dem hatten wir keine Verzögerungen mehr beobachtet. Wir testen morgen früh weiter.
Letzter Stand zum Feierabend war:
Wir haben auf den TS jetzt die Bindung für IPv6 an der NIC wieder aktiviert. Seit dem hatten wir keine Verzögerungen mehr beobachtet. Wir testen morgen früh weiter.
Moin,
warum wurde das deaktiviert? Meines Wissens nach, benötigt Windows Server ab 2008 IPv6 auch wenn Du es "offiziel" gar nicht einsetzt. Oder verstehe ich Dich falsch?
Gruss
Das ist beim Exchange so. WTS Server können ohne laufen, es sei denn eine Anwendung erfordert das.
das wird es sein. Auch Windows 10 macht immer wieder die komischten Probleme, wenn man ohne IPv6 fährt.
Microsoft rät auch dringend davon ab, IPv6 "abzuschalten"
Gruß
Microsoft rät auch dringend davon ab, IPv6 "abzuschalten"
Gruß
Zitat von @sabines:
warum wurde das deaktiviert? Meines Wissens nach, benötigt Windows Server ab 2008 IPv6 auch wenn Du es "offiziel" gar nicht einsetzt. Oder verstehe ich Dich falsch?
Nee, Du verstehst richtig.warum wurde das deaktiviert? Meines Wissens nach, benötigt Windows Server ab 2008 IPv6 auch wenn Du es "offiziel" gar nicht einsetzt. Oder verstehe ich Dich falsch?
Warum das von den Citrix-Admins deaktiviert wurde, weiß ich nicht. Ich vermute mal "wird nicht offiziell gebraucht".
Moin Moin,
Im Großbereich Kopierwesen gibt es mit IPv6 auch immer wieder komische Sachen.
Mal funktionieren Sachen, auf Systemen die schon länger so laufen, plötzlich erst wenn man IPv6 umschaltet (von aus auf an oder umgekehrt).
Oder WIA läuft nur sauber wenn vorher via IPv6/WSD eine Verbindung hergestellt wird, oder oder oder.
Just a cent.
So long.
Im Großbereich Kopierwesen gibt es mit IPv6 auch immer wieder komische Sachen.
Mal funktionieren Sachen, auf Systemen die schon länger so laufen, plötzlich erst wenn man IPv6 umschaltet (von aus auf an oder umgekehrt).
Oder WIA läuft nur sauber wenn vorher via IPv6/WSD eine Verbindung hergestellt wird, oder oder oder.
Just a cent.
So long.
Nein, die GPO's ändern daran nichts.
Wir haben das u.a. mit dem Script Analyze Logon Duration gemessen und die Abarbeitung der GPO's dauert in allen Fällen etwa gleich lang.
Wir haben das u.a. mit dem Script Analyze Logon Duration gemessen und die Abarbeitung der GPO's dauert in allen Fällen etwa gleich lang.
Ich denke, wir haben es gefunden.
Die Server haben 2 NIC. Eine im "normalen" Netz und eine im Netz für Citrix PVS. Im PVS-Netz erfolgt die Verteilung der IP-Adressen über DHCP, damit der PXE-Boot funktioniert. Dort haben die Kollegen aber auch DNS-Server für dieses PVS-Netz mitgegeben, weil sie in den DHCP-Optionen im Pfad für das Bootfile den Servernamen angegeben haben. Dummerweise hat das zur Auswirkung, dass, weil auch unter Windows diese NIC auf DHCP steht, jetzt auch unter Windows auf dieser 2. NIC extra DNS-Server angegeben sind.
Auch wenn die Bindungsreihenfolge der NIC's unter Windows so ist, dass die aus dem "normalen" Netz an erster Stelle steht, kommt es zur beschriebenen Verzögerung, wenn an der 2. NIC diese DNS-Server eingetragen sind. Nachdem wir die DHCP-Optionen im PVS-Netz so geändert haben, dass das Bootfile mit IP-Adresse angegeben wird und keine DNS-Server verteilt werden, bleiben diese Verzögerungen aus.
Wir haben das durch mehrere Proben und Gegenproben gegengeprüft und sind uns ziehmlich sicher, dass das die Ursache war.
Die Server haben 2 NIC. Eine im "normalen" Netz und eine im Netz für Citrix PVS. Im PVS-Netz erfolgt die Verteilung der IP-Adressen über DHCP, damit der PXE-Boot funktioniert. Dort haben die Kollegen aber auch DNS-Server für dieses PVS-Netz mitgegeben, weil sie in den DHCP-Optionen im Pfad für das Bootfile den Servernamen angegeben haben. Dummerweise hat das zur Auswirkung, dass, weil auch unter Windows diese NIC auf DHCP steht, jetzt auch unter Windows auf dieser 2. NIC extra DNS-Server angegeben sind.
Auch wenn die Bindungsreihenfolge der NIC's unter Windows so ist, dass die aus dem "normalen" Netz an erster Stelle steht, kommt es zur beschriebenen Verzögerung, wenn an der 2. NIC diese DNS-Server eingetragen sind. Nachdem wir die DHCP-Optionen im PVS-Netz so geändert haben, dass das Bootfile mit IP-Adresse angegeben wird und keine DNS-Server verteilt werden, bleiben diese Verzögerungen aus.
Wir haben das durch mehrere Proben und Gegenproben gegengeprüft und sind uns ziehmlich sicher, dass das die Ursache war.
1
hehe - hatte ich also doch recht 
Ja, das klingt plausibel.
Theoretisch hätte es auch zum Erfolg geführt die DNS Bindung im system per script zu setzen.
Schöner ist natürlich einfach eine feste konfig.
Theoretisch hätte es auch zum Erfolg geführt die DNS Bindung im system per script zu setzen.
Schöner ist natürlich einfach eine feste konfig.
Nee, nicht ganz. Da waren ja keine "Nicht-DC-DNS" drin. Was ist das überhaupt?
Ich nehme an er meint DNSs, die nicht von Windows bereitgestellt werden und deswegen die für Active Directory nötigen einträge nicht haben.
