illbert 10 Geschrieben 30. Oktober 2008 Melden Teilen Geschrieben 30. Oktober 2008 Moin allerseits, ich habe hier seit ca. einer Woche ein ziemliches Problem mit einigen XP Clients in unserer W2K Domäne. Mir ist bei einer Patrouille durch die Ereignisanzeigen aufgefallen, dass sich ziemlich Kisten plötzlich die Policies nicht mehr ziehen, weil angeblich kein DC zu finden sei. Startscripte wurden im Sysvol wurden nicht gefunden, W32tm hat auch herumgequakt usw. Letztenendes stellte sich heraus, dass auf den Kisten Netlogon ausgeführt wird, bevor überhaupt die Netzwerkverbindung steht (dazwischen ist ein Delay von ca 2 Sekunden). Ergo muss Netlogon ja auch in die Hose gehen (Netlogon 5719). Diese Phänomen tritt sowohl mit Intel als auch Broadcom Nun habe ich zwei Tage lang herumgegoogelt und folgende Lösungsansätze verfolgt: netdiag und dcdiag statische IP vergeben Das MediaSensing vom TCP/IP-Dienst über eine selbstgebastelte Policy abgeschaltet. GpNetworkStartTimeoutPolicyValue auf 60 Sekunden gesetzt, um die Ausführung von Netlogon zu verzögern Netlogon in Abhängigkeit vom DNS-Client auszuführen Verbindung Hat alless nix gebracht - immer das gleiche Spiel ERST scheitert Netlogon, DANN meldet der NIC "Huhu, ich hab Netz". Nun habe ich gerade mal auf einem Client den NIC auf statisch 100 MBit gesetzt. Problem scheint verschwunden. Dafür ein neues - der Client kann plötzlich seinen DNS-Eintrag nicht mehr aktualisieren. Langsam werde ich ..... uuuuuaaaaaaaaaagagagagagabblblblblblb :confused: Hat vielleicht noch jemand eine brauchbare Idee? ciao illbert Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 30. Oktober 2008 Melden Teilen Geschrieben 30. Oktober 2008 Beide Einstellungen aus der GPO FAQ-No. 36 setzen und 2 Neustarts machen: FAQ-GPO Alternativ auch mal das SMB-Signing in den beiden gen. Policies kontrollieren und wenn nötig, gem. Best Praxis einstellen: SMB Signing - Einstellungen für: Kommunikation digital signieren Zitieren Link zu diesem Kommentar
illbert 10 Geschrieben 3. November 2008 Autor Melden Teilen Geschrieben 3. November 2008 Moin Sunny61, vielen Dank für deine Antwort. Geholfen hat's leider nicht. Aber so langsam kommt Klarheit in die Sache. Das Problem scheinen die Gigabit-NICs zu sein. Das Aushandeln der Übetragungsgeschwindigkeit dauert offenbar zu lange (mag an unserer merkwürdigen 4-adrigen Netzwerkverkabelung liegen). Hinzu kommt , dass DHCP auch noch ein Weilchen dauert und scheinbar wird Netlogon die Warterei irgendwann zu doof, egal, ob die Policy sagt, dass es auf das Netz warten soll. Bevor ich mir jetzt wieder die Finger kaputtgoogle noch eine Frage: Gibt es eine Policy, mit der man den Übetragungsmodus für die NICs festlegen kann? Vielen Dank illbert Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 3. November 2008 Melden Teilen Geschrieben 3. November 2008 Müssen bei Gigabit nicht alle 8 Adern benutzt werden ? Es gibt keine Richtlinie, die einen Einfluss auf den Übertragungsmodus der Netzwerkkarten hat. Sowas lässt sich IMHO nur über die Registry einstellen, was allerdings wegen wahrscheinlich unterschiedlicher Karten und verschiedener Regschlüssel nicht einfach werden wird ... Zitieren Link zu diesem Kommentar
illbert 10 Geschrieben 3. November 2008 Autor Melden Teilen Geschrieben 3. November 2008 Ich denke mir auch, dass das ewig lange Autosensing daher rührt, dass die Schnittstellen auf Switch und NIC feststellen, dass sie eigentlich beide 1000MBit können, dann aber feststellen, dass sie die bandbreite nicht realisieren können um anschließend auf 100MBit zurückzufallen. Wenn ich den Übertragungsmodus nicht per Policy regeln kann, muss ich wohl in den saueren Apfel beißen und mir ziemlich viele Ports auf den Switches raussuchen und dort den Modus einstellen. Gruß illbert Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 3. November 2008 Melden Teilen Geschrieben 3. November 2008 Evtl. kann dir DEVCON helfen: Befehlszeilendienstprogramm "DevCon" als Alternative zum Geräte-Manager Alternativ gehts vielleicht per Script: Modify the IP Connection Metric for a Network Adapter Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 3. November 2008 Melden Teilen Geschrieben 3. November 2008 Ob das mit Devcon funktioniert, würde mich auch interessieren. Das Script aus dem zweite Link allerdings setzt nicht die Verbindungsgeschwindigkeit, sondern die Routenmetrik einer Verbindung ... Zitieren Link zu diesem Kommentar
tpk 10 Geschrieben 3. November 2008 Melden Teilen Geschrieben 3. November 2008 Müssen bei Gigabit nicht alle 8 Adern benutzt werden ? Jo bei Gigabit auf alle Fälle 4 Adernpaare, 100 Mbit läuft mit 2 Paaren, wobei ich hier schonmal gelesen habe das wenn 3 Adernpaare zur Verfügung stehen diese anscheinend auch für 100 Mbit genutzt werden da über das zusätzliche Paar dann eine erweiterte CSMA/CD Geschichte läuft und das ganze dann so ein wenig flüssiger gehen soll.. inwiefern es stimmt... :confused: Interessant wäre aber ob der TE wirklich nur 2 Adernpaare hat und warum er dann 1GBIT als Verbindung erhält (@TE Vollduplex?) bzw. Check ansonsten mal ob deine 4 Adern auch auf 1,2,3.6 liegen, müssten sie aber da sonst gar keine Verbindung zustande kommen dürfte.... lg Zitieren Link zu diesem Kommentar
illbert 10 Geschrieben 3. November 2008 Autor Melden Teilen Geschrieben 3. November 2008 Wie gesagt, es kommt auch nicht wirklich eine Gigabit-Connection zu stande, es wird nur erst versucht, eine auszuhandeln, dann kippen die Schnittstellen auf 100MBit zurück. Nur dauert das ganze eben eine Ewigkeit von mehreren Sekunden. Wir haben hier übrigens nur 4 Adren pro Dose, weil hier einst ein total beknacktes Dosensystem aus dem Hause Kerpen verbaut wurde. Zu der Zeit war von Gigabit noch nicht viel zu ahnen - damals schrie alles "Glaaaasfaaaaser!" Tja, werde ich wohl jetzt mal fleißig die Ports auf den Switches raussuchen und auf 100 Auto setzen - in der Hoffnung, dass es das bringt. Gruß illbert Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.