SYSVOL Replikation

[Howard 10]

Guten Morgen zusammen,

 

ich habe seit ein paar Tagen das Problem, das auf einem DC in unserer Domäne das SYSVOL-Verzeichnis nicht mehr repliziert wird. Zur Ausgangslage:

 

10 DCs an 8 Standorten, alle DCs sind W2k3 mit sämtlichen Patches. Domänenfunktionsebene ist W2K3. Das SYSVOL-Verzeichnis ist auf allen DCs vorhanden und freigegeben, nur auf einem DC an einem Standort funktioniert die Replikation des SYSVOL-Verzeichnis nicht. Der betroffene DC ist der einzige DC an besagtem Standort, er ist auch DNS, DHCP, WINS und GC. Die Replikation des AD läuft ohne Probleme, auch ein anderer DFS-Stamm wird sauber repliziert.

 

 

DCDiag zeigt keine Fehler an, repadmin /showrepl zeigt auch an, das alles ok ist. Wenn ich mit mit Sonar die Replikation des SYSVOL-Verzeichnisse anzeigen lasse, wird mir (nur) beim betroffenem Server im DataCollectionState direkt ein "Failed" angezeigt, bei allen anderen DC ist der Status "Succeeded".

 

In der Registry ist mir aufgefallen, das bei allen DCs, wo die Replikation des SYSVOL funktioniert im HKLM\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\Replica Sets eine GUID mit diversen Einträgen zum SYSVOL auftaucht. Beim fehlerhaften DC ist dieser EIntrag nicht vorhanden (nur die Replica Sets der anderen DFS-Stämme) dafür taucht im Schlüssel "Sysvol Seeding" ein Eintrag "Domain System Volume (Sysvol Share)" auf. Dieser hat u.a. einen Schlüssel "Replica Set Parent" in welchem einer der anderen DCs mit FQDN eingetragen ist.

 

Bislang habe ich bei meinen Recherchen nur den folgenden Eintrag bei MS gefunden:

 

How to rebuild the SYSVOL tree and its content in a domain

 

Diese Vorgehensweise sollte aber wohl nur die letzte Option sein, ich hoffe, das es noch irgendwie eine etwas weniger umfangreiche Lösung gibt.

 

Bin für jeden Vorschlag dankbar!

 

Edit:

Im Ereignisprotokoll werden keine Fehlermeldungen die auf ein Problem mit der Repliaktion hinweisen angezeigt.

[Daim 12]

Servus,

 

Bislang habe ich bei meinen Recherchen nur den folgenden Eintrag bei MS gefunden:

 

How to rebuild the SYSVOL tree and its content in a domain

 

Diese Vorgehensweise sollte aber wohl nur die letzte Option sein, ich hoffe, das es noch irgendwie eine etwas weniger umfangreiche Lösung gibt.

 

ohhjaa... SYSVOL-Probleme können ekelig sein.

Aber genau dieser Artikel könnte und sollte dein Problem lösen.

Das Zauberwort lautet oftmals bei SYSVOL-Problemen eben BURFLAGS.

Der Artikel hört sich schlimmer an als er ist. Wenn du ihn mal durchgelesen hast und dich darauf beschränkst was durchzuführen ist,

ist es garnicht so wild.

 

 

P.S. 10 DCs in einer Domäne, auch wenn diese an acht Standorten stehen, halte ich im ersten Moment für "oversized".

[LukasB 10]

Off-Topic:

P.S. 10 DCs in einer Domäne, auch wenn diese an acht Standorten stehen, halte ich im ersten Moment für "oversized".

Das kommt vorallem auf die Standorte an. Wenn man da teilweise nur eine 128kbit Verbindung hat die nur Funktioniert wenn die Mondphase richtig steht und man täglich ein Huhn opfert, dann kann das durchaus sinnvoll sein.

Vorallem im asiatischen Raum ist das nicht immer so zuverlässig wie es sein sollte.

[Daim 12]

Off-Topic:

Das kommt vorallem auf die Standorte an. Wenn man da teilweise nur eine 128kbit Verbindung hat die nur Funktioniert wenn die Mondphase richtig steht und man täglich ein Huhn opfert, dann kann das durchaus sinnvoll sein.

 

Off-Topic:

Na klar, daher auch "...im ersten Moment...".

 

Aber neben der richtigen Mondphase muss nicht ein Huhn geopfert werden, sondern die Schweiz in der EM gegen die Türkei verlieren.

Erst dann kommt eine stabile Leitung zustande. ;)

[Howard 10]

Oversized würd ich nicht sagen, zumal zwischen den Standorten in der Tat relativ dünne Leitungen geschaltet sind. Diese funktionieren allerdings auch ohne die genannten rituellen Machenschaften...

 

Hm, wenn niemandem was besseres einfällt, dann werden wir wohl den MS-Weg gehen müssen. Ich hoffte, das man den fehlenden Reg-Key einfach nachpflegen kann, den ntfrs-dienst neustartet und alles wieder supi läuft ;).

[blub 115]

Burflag 2 ist ja erstmal relativ harmlos. Da holt sich der DC einfach von einem anderen nochmal alle Daten rüber.

Erst bei 4 wird alles neu aufgebaut. Das ist kritischer.

 

cu

blub

[Howard 10]

Moin zusammen,

 

wie schön wäre es, wenn ich beim entsprechenden Registry-Key den Burflag einfach auf D2 setzen könnte, es ist ja nur 1 DC betroffen. Leider fehlt unter "Cumulative Replica Sets" der Eintrag für das SYSVOL. Nur die GUIDs für die anderen DFS-Stämme sind hier vorhanden...

 

Ich frage mich, ob ich durch das Setzen der Burflags überhaupt einen Erfolg erziele, wenn der Registry-Eintrag für das Sysvol garnicht vorhanden ist?

[olc 18]

Hi,

 

dann versuche es einmal mit dem D2 / D4. Damit sollte alles auf dem entsprechenden System neu aufgebaut werden.

 

Viele Grüße

olc

[Howard 10]

Die Frage ist, wo genau soll ich am betroffenen DC den Burflag setzen? In der Registry erscheint unter "Cumulativ Replica Sets" kein Schlüssel für das SYSVOL-Verzeichnis. Dort erscheinen lediglich die GUIDs für die anderen DFS-Stämme die per FRS verteilt werden...

[olc 18]

Ah, ok - verstehe. Entschuldige, das hatte ich irgendwie nicht "wahrgenommen".

 

Sind denn im AD die entsprechenden Subscriber Objekte überhaupt noch vorhanden (auf dem DC selbst als auch unterhalb von cn=domain system volume (sysvol share),cn=file replication service,cn=system,dc=a,dc=com)?

 

Siehe Recovering missing FRS objects and FRS attributes in Active Directory

 

Wenn nicht, ist das Problem ein wenig größer. Ggf. bist du mit einem DCPROMO des DCs schneller als mit dem manuellen neu anlegen der Objekte? Laufen noch weitere Dienste auf dem betroffenen DC?

 

Viele Grüße

olc

[Howard 10]

Moin,

 

also im AD ist das entsprechende Objekt auf dem betroffenem DC vorhanden. Unter System -> File Replication Service -> Domain System Volume (Sysvol share werden alle DC korrekt aufgelistet, auch der betroffene DC.

 

Neben File- und Printservices läuft noch DNS, DHCP und WINS. Die Dienste laufen, zumindest laut Ereignisprotokoll alle sauber.

[olc 18]

Hi Howard,

 

vielen Dank für Deine Rückmeldung.

 

Ich gehe einmal davon aus, daß Du den Server schon einmal neu gestartet hast oder (konkret geht es mir um den NETLOGON und FRS Dienst)?

 

Momentan fällt mir zu den fehlenden Registry Keys nicht viel ein - steht etwas in den Ereignisprotokollen des betroffenen DCs (insbesondere NTFRS Logs)? Es sollte diesbezüglich etwas geloggt werden, denn das FRS Set für den DC scheint ja in der AD vorhanden zu sein. Das sollte der DC bemerken und ggf. Fehler loggen.

 

Ggf. macht auch ein Durchlauf von FRSDIAG Sinn um an weitere Informationen zum Problem zu kommen, siehe Download details: File Replication Service Diagnostics Tool (FRSDiag.exe) .

 

Die Frage nach den zusätzlichen Diensten ging in die Richtung, daß Du unter Umständen am "schnellsten" wärest, wenn Du den DC neu promotest. Das sollte natürlich nur dann passieren, wenn Du keine Probleme mit den installierten Diensten siehst. Gerade mit den zusätzlichen FRS Sets für die Dateireplikation könnte das Probleme geben.

 

Ggf. könntest Du das D2 auf höherem Level durchführen, dann werden jedoch auch die anderen FRS Replica Sets mit den Daten des anderen Server versorgt. Ich weiß nicht, ob das gewünscht ist.

 

Ein Backup mit den korrekten Registry Settings steht nicht zur Verfügung, sonst hättest Du das schon erwähnt oder?

 

Viele Grüße

olc

[Howard 10]

Hi,

 

Server bzw. Dienstneustart war natürlich die erste Idee :). Im Ereignisprotokoll werden keine Fehlermeldungen angezeigt, die auch eine Replikationsproblem hinweise, zudem werden die anderen DFS-Stämme auch sauber repliziert.

 

FRSDiag hab ich auch schon probiert, hat mir leider keine neuen Erkenntnisse gebracht.

 

Datensicherung, das wäre noch eine Option...mal gucken ob ich da morgen noch was reißen kann. Ansonsten denke ich, wäre es das einfachst den DC runterzustufen, 1 Tag zu warten und dann einen erneuten dcpromo durchzuführen...

 

Vielen Dank aber für deine Unterstützung!

[Howard 10]

Moin,

 

ich hab leider doch keine Sicherung der Registry von einem Zeitpunkt, an welchem der DC noch sauber funktionierte. Dafür hab ich mir aber die Logs des FRSDiag-Tools noch mal genauer angeschaut und bin auf folgende Meldungen gestossen (Auszug):

 

<FrsDsFindComputer: 2496: 8796: S2: 15:30:22> :DS: Computer FQDN is cn=dc01,ou=domain controllers,dc=firma,dc=intern

<FrsDsFindComputer: 2496: 8802: S2: 15:30:22> :DS: Computer's dns name is dc01.firma.INTERN

<FrsDsFindComputer: 2496: 8816: S2: 15:30:22> :DS: Settings reference is cn=ntds settings,cn=dc01,cn=servers,cn=StandortA,cn=sites,cn=configuration,dc=firma,dc=intern

<FrsDsGetSubscribers: 2496: 8249: S0: 15:30:22> :DS: No NTFRSSubscriber object found under cn=ntfrs subscriptions,cn=dc01,ou=domain controllers,dc=firma,dc=intern!

<FrsDsGetSubscribers: 2496: 8249: S0: 15:30:22> :DS: No NTFRSSubscriber object found under cn=dfs volumes,cn=ntfrs subscriptions,cn=dc01,ou=domain controllers,dc=firma,dc=intern!

<FrsDsGetSubscribers: 2496: 8249: S0: 15:30:22> :DS: No NTFRSSubscriber object found under cn=90f6aa90-09ca-4e4b-a7ad-faf2f25932bc,cn=dfs volumes,cn=ntfrs subscriptions,cn=dc01,ou=domain controllers,dc=firma,dc=intern!

<FrsHashCalcString: 704: 4842: S0: 15:30:43> Name = S-1-5-21-1438342117-1551623555-3899493943-6113

<SERVER_FrsRpcSendCommPkt: 704: 449: S0: 15:30:43> ++ ERROR - Invalid Partner: AuthClient:firma\dc02$, AuthSid:S-1-5-21-1438342117-1551623555-3899493943-6113

<FrsHashCalcString: 704: 4842: S0: 15:30:43> Name = S-1-5-21-1438342117-1551623555-3899493943-6113

<SERVER_FrsRpcSendCommPkt: 704: 449: S0: 15:30:43> ++ ERROR - Invalid Partner: AuthClient:firma\dc02$, AuthSid:S-1-5-21-1438342117-1551623555-3899493943-6113

 

Es wird vermutlich auch nicht ausreichen, mit dfsgui den SYSVOL-Stamm noch mal neu anzulegen, oder?

[olc 18]

Hi Howard,

 

das war der Grund, warum ich oben nach den Subscriber Objekten im AD SYSTEM-Zweig und nach den Objekten auf dem DC Objekt selbst gefragt habe. ;)

 

Es ist also doch so, daß die Subscriber Objekte zumindest auf dem DC Objekt nicht vorhanden sind. Daher ist es auch kein Wunder, daß die Regsitry Einträge nicht vorhanden sind - der DC weiß schlichtweg nichts von seiner Mitgliedschaft in der SYSVOL Replikationsgruppe.

 

Schau dazu noch einmal in den oben geposteten Link hinein: Recovering missing FRS objects and FRS attributes in Active Directory

Im Bereich "Recovering deleted FRS subscriber objects" findest Du ein Vorgehen, die Objekte wiederherzustellen, wenn Du kein Backup hast. Danach den NTFRS Dienst (oder besser gleich den DC) neu starten und Du solltest die Registry Einträge wieder sehen - wenn das Vorgehen korrekt durchgeführt wurde.

 

Danach solltest Du trotzdem in jedem Fall ein D2 / D4 durchführen, nicht nur das D2.

 

Aber wie oben schon angemerkt - wenn Du mit den anderen FRS Sets oder weiteren Diensten keine Probleme siehst, kannst Du auch den DC neu promoten. Wie es Dir lieber ist. ;)

 

Achso, und nein, es reicht nicht den SYSVOL Stamm in der DFS MMC neu anzulegen. ;)

 

Viele Grüße

olc