#DFSR, Fehler 4012 auf #SYSVOL DFS-Replikation in Windows Server 2012 / DC

Ab und an kommt das wohl vor. Üblicherweise hat es einen Crash gegeben oder der primäre DC wurde in einer virtuellen Umgebung „gespeichert“. Das kommt unangenehmer Weise (Link) bei nicht funktionierender Schattenkopiesicherung vor, bei einem Stromausfall, oder wenn der Wirt einfach mal so neu gestartet wird, ohne die Gäste zuvor herunterzufahren.

Subobtimal. Manche sind überfordert und die Anweisung im Protokoll ist nicht nur alles andere als hilfreich, sie ist sogar falsch (für diesen Fall). Hier will ich mal schreiben, wie man die Replikation von Sysvol wieder in Gang bekommt. Begründung ist, dass der Artikel bei Microsoft für diesen Fall alles andere als gut beschrieben ist und ich heute mal wieder eine Rückfrage dazu bekommen habe.

Klar, Ihr kennt das. Andere Replikationen habt Ihr schon mit meinem zuvor geschriebenen Artikel (LINK) wieder zum Laufen gebracht, das führte jedoch dazu, dass Ihr das ganze auch auf Sysvol übertragen habt und das ist – zugegeben – suboptimal, da für Sysvol ein paar Sicherheitsrestriktionen gelten, die Ihr mit diesem Artikel ausschließlich nicht umgehen könnt,

Bildschirmfoto 2016-03-22 um 10.11.53
auch wenn o.g. Screenshot den anderen bekannten Fehlern (mit Verlaub) quasi identisch ist. Aber: Sollte die Sysvol-Replikation in’s Stocken geraten sein, so müsst Ihr eine authoritative Replikation anwerfen, und das geht eben nicht so „mal eben“. Warum?

Ihr müsst eine „Authoritative DFS Replikation“ für das Sysvol anwerfen, denn Domänencontroller vertrauen nicht jedem, der da mal eben einfach so sagt, er sei einer. Wir bekommen das hin, in dem wir die  „msDFSR“ Konfiguration „mal eben“ zurücksetzen. Da ist ein klitzekleines Bisschen ADSIEDIT notwendig, auch wenn Ihr das nicht mögt. Tut aber nicht weh.

Also, führt zunächst wie in meinem Artikel hier (LINK) beschrieben aus, um die Überlaufszeit zu erhöhen. Anschließend öffnet Ihr in einer Kommandozeile (CMD) mit administrativen Rechten (die brauchen wir gleich auch noch) den ungeliebten ADSI Editor:

adsiedit.msc

Anschließend stellt Ihr eine Verbindung im bekannten Namenskontext „Standardmäßiger Namenskontext“ her, ich zeig‘ das mal hier (, da das Tutorial bei Microsoft da mal wieder nicht ausreichend ist):

Bildschirmfoto 2016-03-22 um 10.26.01

Und dann wählt Ihr hier aus:
Bildschirmfoto 2016-03-22 um 10.26.07
So, und jetzt müsst Ihr ein wenig klickern. Wer ist euer Primärer DC, also derjenige von dem alle synchronisieren? Zu dem müsst Ihr jetzt im ADSIEdit in //CN=Domänenname/OU=Domain Controllers/CN=ErsterDomänencontrollername/CN=DFSR-LocalSettings/CN=Domain System Volume/CN=SYSVOL Subscription schnuffeln:

Bildschirmfoto 2016-03-22 um 10.31.47

So. Nun müsst Ihr mal da bei „msDFSR Enabled“ das mit

Bildschirmfoto 2016-03-22 um 10.35.48

msDFSR-Enabled=FALSE

Abstellen und „mDFSR-Options“ auf 1 umstellen:
Bildschirmfoto 2016-03-22 um 10.36.20

msDFSR-options=1

So, Achtung:

Bei allen anderen Domänencontrollern (im Regelfall bei meinen Kunden nur ein weiterer) müsst Ihr lediglich die Einstellung für „mDFSR-Enabled“, wie oben gezeigt, auf False setzen.

msDFSR-Enabled=FALSE

Macht ADSIEDIT bitte nicht zu, Ihr braucht das gleich noch einmal!

Jetzt macht Ihr eine AD-Replikation in der Konsole (CMD, mit Administrativen Rechten), die Ihr schon geöffnet habt

repadmin.exe /syncall

Das muss jetzt überall funktioniert haben:
Bildschirmfoto 2016-03-22 um 11.09.07

Wenn das geklappt hat, so seht Ihr im Eventlog für DFSR folgenden Eintrag 4114 (bitte prüfen, sonst ist was schiefgelaufen):


Bildschirmfoto 2016-03-22 um 11.19.19

Schritt 1 wäre damit erledigt. Die Replikation ist beendet. Jetzt müssen wir die Replikation authoritativ wieder anwerfen.

Also zürück, Marsch Marsch in ADSIEDIT zu Eurem ersten Domänencontroller. Dort müsst Ihr jetzt wieder die Einstellung für msDFSR-Enabled auf True setzen:
Bildschirmfoto 2016-03-22 um 11.12.19

msDFSR-Enabled=TRUE

Jetzt macht Ihr wieder in der administrativen Konsole eine erzwungene Replikation mittels

repadmin.exe /syncall

und schaut, ob alles gut ist.

Dann ist’s jetzt zeit, die DFSR Replikation anzuwerfen. Das macht Ihr in der administrativen Konsole mit

DFSRDIAG POLLAD

Wenn das gut gegangen ist, so seht Ihr einen 4602 im DFSR Event, dass Euch wie folgt präsentiert wird:

Bildschirmfoto 2016-03-22 um 11.15.36

Wenn Ihr den Dienst für die DFS Replikation auf den anderen Domänencontrollern durchstartet, werdet Ihr ebenfalls (wie oben) eine 4114 gemeldet bekommen.

Jetzt geht Ihr auf allen anderen Domänencontrollern hin und setzt hier auch die Einstellung für msDFSR-Enabled auf True zurück, wie zuvor gezeigt.

msDFSR-Enabled=TRUE

Zum Schluss müsst Ihr Euch nur noch auf allen anderen Domänencontrollern anmelden und dort in einer administrativen Konsole den Befehl

DFSRDIAG POLLAD

Genehmigen. Wenn da alles gut ist, habt Ihr da folgenden Eintrag im DFSR-Protokoll:

Bildschirmfoto 2016-03-22 um 11.26.53

Und die Kuh ist vom Eis. Alles gut. Naja, nicht ganz. Ihr könntet Euch jetzt nochmal Gedanken über Euer Backupkonzept machen (Schattenkopie) oder überlegen, wer wann diesen DC als Gast auf dem Wirt gespeichert hat. Anschließend nehmt Ihr Euch einen Baseballschläger… ;-)

Bis bald.