none
DFS Eintrag im LOG-File EreignisID 5014 / Fehler 1726 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden
    Hallo liebes Forum!

    Ich betreibe eine Windows Domaine mit Standard SERVER2008, 64 Bit mit 3 Servern die alle im selben Netzwerk stehen und direkt auf dem selben Switch hängen. Seit vielen Wochen bekomme ich auf dem "primären" Server reglemäßig wie Ebbe und Flut die Meldung im Log:

    Der DFS-Replikationsdienst beendet die Kommunikation mit Partner SERVER02
    für Replikationsgruppe xyz aufgrund eines Fehlers. Der Dienst wird regelmäßig
    versuchen, die Verbindung wiederherzustellen.
     
    Weitere Informationen:
    Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
    Verbindungs-ID:
    Replikationsgruppen-ID:

    Im Log steht dann sofort danach, mit identischer Uhrzeit auf die Sekunde identisch quasi die Entwarnung:

    Der DFS-Replikationsdienst hat erfolgreich eine eingehende Verbindung
    mit Partner "SERVER02" für Replikationsgruppe "xyz" hergestellt.
     
    Weitere Informationen:
    Verwendete Verbindungsadresse: server02
    Verbindungs-ID: 
    Replikationsgruppen-ID:

    lch habe schon überall gesucht und in vielen Foren nur das identische Problem ohne Lösungsvorschläge gefunden. Einzig beim MS Support scheint es für Server 2003 ein identisches Problem zu geben mit einem Hotfix für Server2003
    http://support.microsoft.com/kb/943661/en-us/

    Aber nirgends etwas für Server2008!

    Hat jemand hier eine Lösung oder einen Vorschlag wie ich weiter vorgehen sollte?
    Mittwoch, 28. Oktober 2009 16:54
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden
    Hi,

    über welchen Zeitrahmen sprechen wir in Bezug auf die "regelmäßigen" Events? Stunden oder Tage?
    Laufen zu diesem Zeitpunkt unter Umständen Backups oder Schattenkopien?

    In den meisten Fällen bei dieser Art von Ereignissen lohnt sich ein Blick auf:
    - Anti-Viren Scanner und Firewalls (ggf. einmal testweise deinstallieren)
    - NIC-Teaming (testweise einmal entfernen)
    - ältere Netzwerkkartentreiber (ggf. aktualisieren)
    - TCP Offloading / TCP Chimney Probleme

    Check die Punkte doch einmal ab, vielleicht ist darunter schon eine Lösung.

    Viele Grüße
    Fabian
    http://blogs.technet.com/deds
    Mittwoch, 28. Oktober 2009 18:32
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Ewald,

    juup das ganze ist verwirrend und wiederum abhängig von der NIC und dessen Treiber, die auf jeden Fall aktuell gepacht sein sollte.

    Anbei Auszug aus einem Dokument (habe den Link nicht mehr) mit den weiterführenden Infos:

    More Information

    The following whitepaper lists the default settings, descriptions, and valid ranges of the configurable TCP/IP registry values in Windows 2008/Vista:

    http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc

    Note: There are some registry values from Windows Server 2003, such as “EnableRSS” and “EnableTCPChimney”, which are no longer used in Windows Server 2008. These settings are now only configurable in the using the netsh utility and on the properties of network adapters that support them. The following KB gives some examples of netsh commands:

    Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008

    http://support.microsoft.com/kb/951037

    Gruß Ralph Andreas Altermann
    Montag, 2. November 2009 18:21
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden
    Hi,

    über welchen Zeitrahmen sprechen wir in Bezug auf die "regelmäßigen" Events? Stunden oder Tage?
    Laufen zu diesem Zeitpunkt unter Umständen Backups oder Schattenkopien?

    In den meisten Fällen bei dieser Art von Ereignissen lohnt sich ein Blick auf:
    - Anti-Viren Scanner und Firewalls (ggf. einmal testweise deinstallieren)
    - NIC-Teaming (testweise einmal entfernen)
    - ältere Netzwerkkartentreiber (ggf. aktualisieren)
    - TCP Offloading / TCP Chimney Probleme

    Check die Punkte doch einmal ab, vielleicht ist darunter schon eine Lösung.

    Viele Grüße
    Fabian
    http://blogs.technet.com/deds
    Mittwoch, 28. Oktober 2009 18:32
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Fabian!

    Danke Dir für die Hinweise. Die Meldungen kommen über den Tag verteilt ca. 10 bis 20 Mal. Ursprünglich dachte ich auch immer, dass es mit dem Backup zu tun hat, denn wenn der startet habe ich fast prompt sofort immer den Effekt

    Anti-Viren Scanner ist keiner drauf, Firewall nur Windows Bordmittel
    Kein NIC Teaming verwendet
    Netzwerkkartentreiber neueste installiert.
    TCP Offloading / TCP Chimney Probleme da muss ich mal nachschauen. Da habe ich zusammen mit Microsoft Support einiges gespielt, da wir mit den neuen Servern mit Server2008 das Problem hatten, dass der schreibende Zugriffe von WXP Pro Workstations so extrem verlangsamt war, dass es nicht mal mehr Lieferzeiten waren. Mit VISTA Workstations ging es ohne Probleme. Dann mit viel Geld versucht durch MS beheben zu lassen. Aber die haben auch nur gebastelt....

    Durch einen Forumsbeitrag bin ich dann auf die Einstellungen für Offloading und Chimney gestoßen und konnte es damit lösen.

    Ich denke zwar momentan, dass ich beide Server gleich eingestellt habe und die geschilderten Probleme tauchen nur auf dem ersten Server aus. Hardware und Software 100% identisch. Prüfe ich Morgen aber noch Mal.

    Melde mich dann hier mit einer Rückmeldung.

    Ewald

    Donnerstag, 29. Oktober 2009 00:23
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Ewald,

    letzter Punkt von Fabian:

    zur Info: http://social.technet.microsoft.com/Forums/en/winserverfiles/thread/d27bd902-034e-4230-9516-0ede42308193
    Gruß Ralph Andreas Altermann
    Donnerstag, 29. Oktober 2009 08:33
    |
  • Question
    Anmelden
    0
    Anmelden
    Hallo Andreas! Hallo Fabian!

    Ich habe mal meine beiden Server kontrolliert. Wie halt so immer, dachte (hoffte) ich beide gleich konfiguriert zu haben. Tatsache durch die damaligen Probleme mit der Übertragungsschwierigkeiten, habe ich mit dem Befehl:

    netsh int tcp set global chimney=enabled auf Server 1 gesetzt und auf Server 2 disabled.

    Hatte ich damals aus diesem Link: http://support.microsoft.com/default.aspx/kb/951037/en-us

    Habe ich heute wie folgt überprüft.

    • auf Server1: (der mit den DFS Meldungen)
    C:\Users\Administrator>netsh int tcp show global
    Der aktive Status wird abgefragt...
    Globale TCP-Parameter
    ---------------------------------------------------
    Skalierungsstatus Empfangsseite          : enabled
    Chimney-Abladestatus                     : enabled
    Autom. Abstimmungsgrad Empfangsfenster   : normal
    Add-On "Überlastungssteuerungsanbieter"  : ctcp
    ECN-Funktion                             : disabled
    RFC 1323-Zeitstempel                     : disabled

    • auf Server2:
    C:\Users\Administrator>netsh int tcp show global
    Der aktive Status wird abgefragt...
    Globale TCP-Parameter
    ---------------------------------------------------
    Skalierungsstatus Empfangsseite          : enabled
    Chimney-Abladestatus                     : disabled
    Autom. Abstimmungsgrad Empfangsfenster   : normal
    Add-On "Überlastungssteuerungsanbieter"  : ctcp
    ECN-Funktion                             : disabled
    RFC 1323-Zeitstempel                     : disabled

    Bei dem Link von Dir Andreas, stehen einige Einträge für die Registry beschrieben. Ich hatte gehofft in der Registry dann quasi die passenden Einträge zu meinem damals mit NETSH vorgenommenen Einstellung zu finden.


    Value =EnableTCPChimney

    Type = DWORD

    Data = 0

     

    und eben dann auf dem einen Server mit Wert 1 und auf dem anderen Server mit Wert 0. Aber Nein, rein gar nichts weder im anegegeben Registry Pfad: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters " noch sonst wo in der Registry ist ein Schlüssel mit "EnableTCPChimney" zu finden oder überhaupt was zu TCPChimney.

     

    Bin deshalb unsicher und wollte nicht irgendwas machen. ;-)

     

    NETSH beeinflußt doch den TCPIP Stack. Ist das ganz was anderes mit den Einträgen aus Deinem Link in der Registry? Entschuldige, wenn ich vielleicht dämliche Fragen stelle ... ;-)

     

    Ich habe jetzt erst Mal mit NETSH beide Server "gleich" gemacht also: "Chimney-Abladestatus: disabled" und dachte, ich frage nach Eurer Einschätzung, ob ich die im Link vorgeschlagenen Registry Einträge noch zusätzlich machen soll?

     

    Danke für Eure Unterstützung.

     

    Ewald

    Montag, 2. November 2009 17:45
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Ewald,

    juup das ganze ist verwirrend und wiederum abhängig von der NIC und dessen Treiber, die auf jeden Fall aktuell gepacht sein sollte.

    Anbei Auszug aus einem Dokument (habe den Link nicht mehr) mit den weiterführenden Infos:

    More Information

    The following whitepaper lists the default settings, descriptions, and valid ranges of the configurable TCP/IP registry values in Windows 2008/Vista:

    http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc

    Note: There are some registry values from Windows Server 2003, such as “EnableRSS” and “EnableTCPChimney”, which are no longer used in Windows Server 2008. These settings are now only configurable in the using the netsh utility and on the properties of network adapters that support them. The following KB gives some examples of netsh commands:

    Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008

    http://support.microsoft.com/kb/951037

    Gruß Ralph Andreas Altermann
    Montag, 2. November 2009 18:21
    |
  • Question
    Anmelden
    0
    Anmelden
    Hallo aus München!

    Noch Mal Danke an Alle, besonders Andreas und Fabian. Mein Problem scheint erledigt zu sein!

    Seit dem ich gestern auf meinem Primären Server 1 mit

    netsh int tcp set global chimney=disabled

    TCP Chimney Offload disabled habe, kommt die Eingangs erwähnte Fehlermeldungsflut nicht mehr! Ich überwache es noch ein oder zwei Tage und sollte es dann wegbleiben, setze ich den Fall auf gelöst!

    Danke noch Mal.
    Dienstag, 3. November 2009 09:34
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Dotzauer,

    gern, danke Dir für die Rückmeldung.

    Viele Grüße
    Fabian
    http://blogs.technet.com/deds
    Dienstag, 3. November 2009 20:15
    |
  • Question
    Anmelden
    0
    Anmelden
    Hallo Fabian, hallo Andreas, hallo Forum!

    Schlecht Ding will auch Weile haben. Ich bin leider mit meinem Problem einer Lösung nicht näher gekommen. Die Eingangs beschriebenen Probleme Ereignis 5014,DFSR und Ereignis 5004,DFSR :
    ... Seit vielen Wochen bekomme ich auf dem "primären" Server reglemäßig wie Ebbe und Flut die Meldung im Log:

    Ereignis 5014,DFSR
    Der DFS-Replikationsdienst beendet die Kommunikation mit Partner SERVER02
    für Replikationsgruppe xyz aufgrund eines Fehlers. Der Dienst wird regelmäßig
    versuchen, die Verbindung wiederherzustellen.
     
    Weitere Informationen:
    Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
    Verbindungs-ID:
    Replikationsgruppen-ID:

    Im Log steht dann sofort danach, mit identischer Uhrzeit auf die Sekunde identisch quasi die Entwarnung:

    Ereignis 5004,DFSR
    Der DFS-Replikationsdienst hat erfolgreich eine eingehende Verbindung
    mit Partner "SERVER02" für Replikationsgruppe "xyz" hergestellt.
     
    Weitere Informationen:
    Verwendete Verbindungsadresse: server02
    Verbindungs-ID: 
    Replikationsgruppen-ID:       ......
    bestehen immer noch.

    Habe gerade gemerkt, dass ich im Eingangspost die Ereignis IDS 5014 und 5004 vergessen hatte, darum habe ich Sie in mein Zitat noch Mal extra ergänzt

    Ich habe jetzt gesichert auf beiden Servern den Chimney-Abladestatus auf disabled gestellt.

    Auf Grund der Hinweise von hier habe ich es in der Netzwerkkarte und mit netsh gemacht.

    Wenn ich den Status dazu abfrage heißt es immer disabled:
    C:\Users\Administrator>netsh int tcp show global
    Der aktive Status wird abgefragt...
    Globale TCP-Parameter
    ---------------------------------------------------
    Skalierungsstatus Empfangsseite          : enabled
    Chimney-Abladestatus                     : disabled
    Autom. Abstimmungsgrad Empfangsfenster   : normal
    Add-On "Überlastungssteuerungsanbieter"  : ctcp
    ECN-Funktion                             : disabled
    RFC 1323-Zeitstempel                     : disabled
    C:\Users\Administrator>

         Die Netzwerktreiber sind 100%ig identisch und waren zumindest im November auf dem neuesten Stand. Beide Server laufen auf 100%ig identischer Hardware, darum will ich nicht so recht glauben, dass falls verfügbar ein neuerer Netzwerkkarten Treiber irgend was bringen würde ... Aber ich werde noch Mal bei Intel nach fassen.

    Server haben alle neueste MS Patches und sind Software mäßig auch alle identisch.

    Im Netz gibt es viele Nachfragen dieser Art, entweder ohne Lösung oder Problem war irgendwann weg ....

    Hat irgend wer eine Idee?

    Ehrlich bin ziemlich ratlos.

    Ewald
    Montag, 14. Dezember 2009 08:38
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Ewald,

    einmal anders gefragt: Hast Du denn irgendwelche DFSR-Probleme, die aus den Meldungen resultieren? Läuft die DFSR Replikation nicht korrekt oder ähnliches?

    Wenn keine Probleme auftreten, sind die Meldungen im Kern ja nur "Schönheitsfehler" und kein tatsächliches Problem. Rein theoretisch könnte man natürlich versuchen, die Ursache für die RPC-Abbrüche herauszufinden oder mit den TCP-KeepAlive Werten "herumspielen" (nicht empfohlen), aber das macht ja nur dann Sinn, wenn es wirklich zu Problemen kommt.

    Viele Grüße
    Fabian
    http://blogs.technet.com/deds
    Montag, 14. Dezember 2009 14:51
    |