Hallo, ich bin David, Principal Engineer bei Dell. Heute spreche ich über die Durchführung einer nicht autoritativen Synchronisierung von CIS-Daten mithilfe der verteilten Dateisystemreplikation oder DFSR-DF. Sr ist die neuere der beiden Methoden, die zum Replizieren von CIS-FLL-Daten in einer Domäne verwendet werden. Die ältere Version ist der Dateireplikationsservice oder FRS. Die meisten modernen Domains werden zu diesem Zeitpunkt DFS R verwenden, um CIS zu replizieren. Es ist robuster als FRS, kann aber trotzdem ausfallen und manchmal muss die Synchronisierung zwischen Domänencontrollern erzwungen werden. In diesem Video.
Ich zeige Ihnen, wie Sie eine nicht autoritative Synchronisierung durchführen, bei der unser Zieldomänencontroller die CIS-Daten von einem anderen Domänencontroller kopiert. In unserer Umgebung haben wir zwei DCs, um die wir uns hier kümmern werden. DC eins und DC drei, DC eins wird unser Quell-DC sein und DC drei wird unser Ziel sein. Wenn wir die Ereignisanzeige auf DC 3 öffnen und im DFS-Replikationsprotokoll nachsehen, werden in diesem Fall Fehler angezeigt. Die spezifischen Fehler sind nicht wichtig. Ich habe DFS R für diese Demonstration absichtlich kaputt gemacht. Hier können wir jedoch feststellen, dass die DFS-Replikation nicht ordnungsgemäß funktioniert und die CISL-Daten von einem anderen Domain Controller nicht wie erforderlich repliziert wurden.
Wenn wir uns die Ereignisanzeige auf DC 1 ansehen, sehen wir keine Fehler, sondern nur informative Ereignisse. Es gibt einige Fehler, die vor einiger Zeit aufgetreten sind, aber sie wurden behoben. Und DFS R auf DC 1 funktioniert ordnungsgemäß. Das einzige Problem hier ist DC 3. Wir können bestätigen, dass es ein Problem gibt, wenn wir in das Gruppenrichtlinienmanagement gehen und einen Blick auf die Anzahl der GPS werfen, die wir hier haben. Es gibt 10, darunter drei Test-GPS, die kürzlich für diese Demonstration erstellt wurden. Wenn wir uns den CIS-Herbstinhaltsordner ansehen, sehen wir hier 10 Ordner unter CIS-Fall-Domainrichtlinien. Jeder dieser Ordner enthält die Vorlagendateien für jedes GPS, das wir in der Gruppenrichtlinien-Verwaltungskonsole gesehen haben. Da wir also 10 GPS haben, haben wir 10 Ordner mit Vorlagendateien. Wenn wir zum gleichen Speicherort auf DC gehen, drei navigieren zu Windows, dann cis fall domain und policies, wir sehen hier nur sieben Ordner.
Die drei Test-GPS, die ich kürzlich erstellt habe, wurden nicht repliziert. Ihre Vorlagendateien sind also nicht auf DC 3 vorhanden, was wiederum auf ein Problem mit der DFS-Replikation der CIS-Falldaten hinweist. Um dies zu korrigieren, führen wir eine nicht autoritative Synchronisierung des CIS-Falls durch, um dies zu tun. Wir schalten Anzeigen, die ich bearbeite, und innerhalb von Anzeigen, die ich bearbeite, stellen wir eine Verbindung zum Standardnamenskontext her, belassen alle diese Werte auf ihren Standardeinstellungen und verbinden uns mit dem Standardnamenskontext. Hier unten erweitern wir den Standardnamenskontext und dann die Domänenspanne. Die Domänencontroller ou und DC 3 sind die einzigen, mit denen wir uns hier befassen werden. Wir erweitern also DC 3, erweitern die lokalen FSR-Einstellungen und erweitern das Domain System Volume. Hier sehen wir das CIS-Herbstabonnementobjekt.
Wir bearbeiten dieses Objekt, weil wir uns die Attribute ansehen möchten. Und das Attribut, um das es geht, heißt MS DF Sr aktiviert. Wir möchten das auf "false click" setzen. OK, zur Bestätigung und wieder OK. Und da wir diese Änderung tatsächlich auf DC 3 durchgeführt haben und DC 3 der einzige Domain Controller ist, um den wir uns kümmern. Im Moment müssen wir keine Replikation erzwingen. Dieses Attribut ist in Active Directory gespeichert, aber wir interessieren uns nur für den Wert auf DC 3. Dazu müssen wir DF Sr Diag Pole A ausführen, wodurch DFS R angewiesen wird, das Active Directory nach Konfigurationsänderungen abzufragen. Hier sehen wir, dass der Befehl erfolgreich war. Wir kehren also zur Ereignisanzeige zurück und aktualisieren sie. Dort werden einige informative Ereignisse 4114 und 2010 angezeigt, die darauf hinweisen, dass die DFS-Replikation deaktiviert wurde.
4114 bezieht sich speziell auf den CIS-Fallpfad und 2010 bezieht sich nur auf die DFS-Replikation insgesamt, da alle replizierten Ordner deaktiviert wurden. Nachdem wir das getan haben, kehren wir zum gleichen Attribut zurück, fügen die Bearbeitung hinzu und setzen sie wieder auf true click, OK? Zur Bestätigung und mit OK müssen wir noch einmal keine Replikation durchführen. Wir müssen DF Sr Diag Pole A erneut ausführen, da wir eine weitere Konfigurationsänderung vorgenommen haben. Auch hier ist der Befehl erfolgreich und wir kehren zur Ereignisanzeige zurück und aktualisieren sie erneut. Und jetzt sehen wir ein Warnereignis 4614: Der DFS-Replikationsservice hat CIS-Fall auf dem lokalen Pfad CIS-Fallpfad initialisiert und wartet auf die Durchführung der ersten Replikation. Bald schon sehen wir, dass es wieder neue Ereignisse gibt. Bei einer erneuten Aktualisierung wird Ereignis 4604 angezeigt, wonach wir suchen.
Der DFS-Replikationsdienst hat den CIS-Fall-Replikationsordner unter dem Pfad erfolgreich initialisiert. Das Mitglied hat die Erstsynchronisation von CIS Fall mit Partner DC One abgeschlossen. Dort wird angezeigt, dass nach dem CIS-Fallordner gesucht werden soll. Wir führen den Befehl "net share" aus. Damit wird bestätigt, dass CIS-Fall- und Net-Log-on-Freigaben vorhanden sind. Wenn wir zum Datei-Explorer zurückkehren, sehen wir jetzt 10 Ordner mit GP-Vorlagendateien, was auch bestätigt, dass die CIS-Daten aus dem DC repliziert wurden. Eins.
Wenn wir zu DC 1 zurückkehren, können wir diese Ordner vergleichen und bestätigen, dass sie identisch sind. Das war wieder einmal eine nicht autoritative Synchronisierung von cisl -Daten mit DFS R. Mein Name ist David und ich bin Principal Engineer bei Dell.
Vielen Dank für Ihre Aufmerksamkeit.
