Computer finden Domänencontroller beim Start nicht (Event ID 5719)

[Daniel -MSFT- 129]

Aller Wahrscheinlichkeit nach ist der Netzwerklink nicht ganz oben, wenn Netlogon auf den Server zugreifen will. Das kann an DHCP-Relayagenten liegen oder auch an der Switchfirmware. Bezeichnend ist ja, dass es in dem einen Fall der kaskadietrnden Switches funktioniert.

 

Ich würde mit dem Parameter ExpectedDialUpDelay in der Registry den Zeitraum für Netlogon verlängern, bis es passt: http://blogs.technet.com/b/instan/archive/2008/09/18/netlogon-5719-and-the-disappearing-domain.aspx

 

Der Hotfix, auf den Norbert verweist, kann auch helfen, da es ja nur bei Windows 7 auftritt und nicht bei Windows 8: http://support.microsoft.com/kb/938449/ und http://support.microsoft.com/kb/2459530

[daabm 1.348]

Tja, schönes T-Shirt, aber hat mir leider nicht weitergeholfen. :(

 

Jaros, das war mir schon klar, und das ist auch nicht böse gemeint - aber Deine Tests mit unterschiedlichen Switches zeigen (mir zumindest) deutlich, dass es eigentlich kein Problem der Clients ist, sondern der Infrastruktur. Und dass es mit W8 geht und mit W7 nicht - ok. möglicherweise hat MS da irgendwas eingebaut, um bestimmte Fehlersituationen besser zu überstehen...

[lefg 276]

Wie schaut es denn eigentlich mit der Verkabelung aus? Ist es gesichtert, dass die einwandfrei ist?

 

Auch mal geschaut und verglichen die Einstellungen unter Netzwerk, Eigenschaften, Konfiguration, Erweiter?

bearbeitet 28. September 2014 von lefg

[Jaros 10]

Hallo,

 

@Daniel: Patch von Norbert habe ich vorhin ausprobiert. Immer noch Event 5719.

 

@daabm: Ist schon klar, dass das nicht böse gemeint ist und wir vermuten es auch in der Infrastruktur, nachdem die ganzen Patches und Einstellungen in Windows nicht funktionierten. Wir haben inzwischen auch mal den Support von Dell bemüht, aber die meinten, dass von der Fehlerbeschreibung kein Problem in der Hardware zu finden sei. Meh... ja wo denn nun?

Wir hatten jetzt am Wochenende leider keine Zeit, die Switches auf ne neue Softwareversion zu patchen. Mal sehen, ob wir das noch zeitnah schaffen.

Ich melde mich dann wieder, wenn ich neue Infos habe.

[Daniel -MSFT- 129]

Hast Du auch den Timeout höher gesetzt?

 

Ich würde mit dem Parameter ExpectedDialUpDelay in der Registry den Zeitraum für Netlogon verlängern, bis es passt: http://blogs.technet.com/b/instan/archive/2008/09/18/netlogon-5719-and-the-disappearing-domain.aspx

 

Have fun!
Daniel

[Jaros 10]

Hallo,

 

ich gebe mal ein kleines Update:

Die Switches wurden alle am Wochenende auf die aktuelle Firmware-Version gepatcht.

Leider hat das nicht zur Lösung beigetragen. Ich habe immer noch Event 5719.

Da es bei uns jetzt wieder etwas ruhiger geworden ist, hoffe ich, dass ich diese Woche zum größeren Testen komme.

Letzte Woche ist mir nämlich noch aufgefallen, dass das Problem doch bei unserer Rechnerinstallation anschlägt (siehe Post weiter oben, als ich dachte, es wäre ein Irrtum).

Ein Rechner hängt bei mir an dem 100MB-Switch und wird über unsere Softwareverteilung installiert. Wenn die Betriebssysteminstallation beendet ist, wird ein Autologon durchgeführt, der dann mit der Softwareinstallation fortsetzt. Dieser Autologon bleibt hängen und ich stelle dann fest, dass der Rechner nicht in der Domäne hinzugefügt wurde. Ich muss ihn dann manuell in die Domäne hinzufügen und die Installation läuft normal weiter.

 

Wegen dem ExpectedDialUpDelay habe ich mal ne Frage: Wie ist denn das Verhalten, wenn der Eintrag gesetzt ist? Ich habe den Timeout auf 60 Sekunden gestellt. Ich erwarte dadurch, dass es mindestens 60 Sekunden dauert, bis mir die Anmeldemaske angezeigt wird. Aber dem ist nicht so. Die Anmeldemaske ist meist so nach 20 - 30 Sekunden da (PC mit SSD). Wenn man sich dann anmeldet, sind natürlich keine Netzlaufwerke da.

 

Gruß Jaro

[4077 30]

Bei uns hat damals bei dem gleichen Problem das geholfen.

Der im KB-Artikel angebene Standardwert 60 hat auch auf Anhieb funktioniert.

[Jaros 10]

Hallo,

 

es gibt Neuigkeiten in diesem Fall.

 

Nachdem wir jetzt endlich mal Zeit hatten, das Problem intensiv zu untersuchen, haben wir eine Lösung gefunden.

Wie wir herausgefunden haben, machen unsere Switche (Dell Power Connect 5548) Probleme mit Intel-Netzwerkkarten.

Weder ein Firmwareupdate der Switche noch der Netzwerkkarten noch ein Treiberupdate der Netzwerkkarten hat geholfen.

Letztendlich war der Registryeintrag

 

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0007\WaitAutoNegComplete=1

 

die Lösung.

Bei aktuellen Inteltreibern kann man dies auch im Treiber selbst einstellen unter:

Erweitert - Auf Verbindung warten - Ein (statt default "automatisch")

 

Ob das jetzt Ursachen- oder Sympthombekämpfung war, kann ich leider nicht sagen. Intel-Netzwerkkarten haben wir seit mindestens fünf Jahren, die Switche ebenfalls seit über 1,5 Jahren im Einsatz. Da hätte das Problem eigentlich schon früher auftreten müssen.

 

Gruß Jaro

bearbeitet 24. Oktober 2014 von Jaros

[lefg 276]

 

Weder ein Firmwareupdate der Switche noch der Netzwerkkarten noch ein Treiberupdate der Netzwerkkarten hat geholfen.

 

Moin.

 

hat es denn aber mal ein Treiberupdate gegeben?

 

Ich hatte es mal, nach einem Update trat das Problem auf, nach dem Zurückstellen auf die vorherige Treiberversion war das Problem behoben.

 

Der neuste Treiber war Verursacher des Problems. Allerdings war es nicht Intel sondern Realtek.

bearbeitet 25. Oktober 2014 von lefg

[Jaros 10]

Moin,

 

ich hatte mehrere Treiber der Netzwerkkarten ausprobiert. Brandneue als auch ältere. Der Fehler trat trotzdem auf.

Den Fehler hatte ich teilweise auch auf Rechnern, deren Installationsstand schon zwei Jahre alt waren. Treiberaktualisierungen gibt es bei uns nur bei Bedarf.

[Nobbyaushb 1.464]

Hi Jaros,

 

auch moin!

 

Ich habe ein ähnliches Problem, allerdings passt die Anmeldepause bei uns.

 

Nur behauptet in unregelmäßigen Abständen und auch bei verschiedenen LAN-Karten (Intel, Realtec usw..) das der Computer mit einem öffentlichen Netzwerk verbunden ist, logischer Weise sind das andere Firewall-Regeln als in dem Domänen-Netzwerk - und schon geht das Meiste nicht mehr.

Adapter disablen, ein paar Sekunden warten und wieder enablen regelt das Problem normalerweise.

 

Das tritt nicht nur bei physischen Maschinen, sondern auch bei VM unter Hyper-V 2012R2 auf.

 

Bevor einer fragt - ja, alle Systeme sind voll durchgepatcht (WSUS - hallo Sunny..)

 

Es gibt kein erkennbares Muster und keinen Eintrag im Event-Log!

[Reingucker 3]

@Nobbyaushb

 

Ha! Das hatte ich auch heute :D

 

Ich hab dann unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList]\"FirstNetwork"=dword:00000000 einfach ne 2 draus gemacht. Hab dann auch überlegt ob ich dem System das schreibrecht auf diesen Schlüssel entziehen soll, also nur lesen. Dann dachte ich mir aber: Das kann es nicht sein.

 

Es muss irgendwas unter "Networklist" mit den "unmanaged" und den da fest zugeordneten Profilen zu tun haben. Vielleicht mal die ganzen chaches und festen zuordnungen in den Unterschlüsseln unter "Networklist" löschen? Bin da aber noch nicht weiter weil es schon nach 16:00 war und ich die Schule verlassen musste.

Edit:

 

Aha! Hab etwas gefunden was dir vielleicht weiter hilft

 

http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx

 

könnte also etwas mit den "unknown" zu tun haben.

bearbeitet 8. Dezember 2014 von Reingucker