DC 2012R2 repliziert sich nicht korrekt mit den anderen DCs - VPN als Ursache?

Hallo allerseits,

mir ist aufgefallen, dass einer unserer drei DCs sich nicht korrekt mit den anderen beiden repliziert. Festgestellt habe ich dies, als ich merkte, dass diejenigen Clients, die sich an diesem DC anmelden, keine Aktualisierungen für Gruppenrichtlinien ziehen.

Interessant finde ich, dass auch der betroffene DCs sämtliche Gruppenrichtlinien und Änderungen, die ich an den anderen DCs vornehme, in der Gruppenrichtlinienverwaltung anzeigt. Der Ordner Windows\SYSVOL\sysvol\<Domäne>\Policies ist jedoch erheblich kleiner und mit weniger Dateien bestückt, als bei den anderen beiden DCs.

Zu den Eckdaten:

--> 3 DCs, 1x 2008R2, 2x 2012R2

--> der betroffene DC steht nicht am Hauptstandort, sondern ist per VPN (Sophos RED 50) angebunden - möglicherweise liegt hier die Ursache verborgen? Es ist allerdings sämtlicher Traffic vom Außenstandort ins LAN des Hauptstandortes erlaubt, und andersherum ebenso. Sonst gibt es auch keinerlei Probleme; die Kollegen vom Außenstandort greifen auch auf Freigaben auf Servern am Hauptstandort zu etc. - auch synchronisiert sich ja die Anzeige in der Gruppenrichtlinienverwaltung

--> in den Ereignisanzeigen der DCs finde ich nichts dazu

--> DFS-Dienst ist auf allen DCs aktiviert (Starttyp automatisch)

Hat jemand eine spontane Eingebung zu dem Problem?

Und, als Notnagel, falls sich keine Lösung finden lässt: Ist es möglich, den Clients zu sagen, an welchem DC sie sich anmelden sollen? Es haben sich ein paar wenige Clients des Hauptstandortes am DC des Außenstandortes angemeldet. Macht wenig Sinn, wenn ein DC zwei Meter entfernt steht.

Beste Grüße und vielen Dank schon einmal!

Normal melden sich die Clients an dem DC an der zuerst antwortet. Das lässt sich wenn ich mich recht erinnere über die Standorte priorisieren. (VERWALTUNG - ACTIVE DIRECTORY STANDORTE UND DIENSTE)

Für die Analyse was beim Replizieren fehlschlägt hilft dir vielleicht dieses MS Tool

das mal durchgehen, auf beiden Servern MUSS derselbe Inhalt sein
http://jackstromberg.com/2014/07/sy...out-of-sync-on-server-2012-r2-dcs-using-dfsr/
Beachte bis zum abschluss des syncst (je nach größe/Bandbreite kann das ja dauern) ist der dc welcher synct kein dc!

über die Standorte könntest du steuern wo sich angemeldet wird

Danke für die schnelle Antwort!
Das Tool - sehr nützlich übrigens! - habe ich direkt getestet. "Leider" wurden sämtliche Vorgänge erfolgreich abgeschlossen. Laut dem Tool funktioniert die Replikation wunderbar.
Es sieht ja in der Gruppenrichtlinienverwaltung und dem AD auch durchaus so aus. Alle Objekte sind sichtbar und auch Änderungen werden recht flott übernommen. Es hakt also nicht grundsätzlich. Aber der Teufel steckt ja oftmals im Detail. Mich irritiert nachwievor der viel zu kleine Ordner SYSVOL\sysvol\<Domäne>\Policies. Das ist der Knackpunkt.

Wenn ich das irgendwie gefixed bekäme...

Namensauflösung und generell die gesamte Kommunikation funktioniert übrigens einwandfrei. Ein Ping braucht zwar 20-28ms, aber ist eben auch ein Außenstandort.

EDIT: Danke, 0711. Ich werde das mal versuchen. Muss ich die Schritte unter Link 1 per se in dieser Reihenfolge machen bzw. auf den dort genannten DCs? Oder führt der Autor Schritt XYZ nur deshalb auf dem primären DC aus, weil eben dieser bei ihm nicht synchronisiert wird? Bei mir ist es nämlich ein "eher unbedeutender" DC am Außenstandort. Ungern möchte ich mir nun das AD am Hauptstandort zerschießen.

Das dort beschriebene Vorgehen ist korrekt beschrieben, kannst auch mit dem MS Artikel abgleichen
https://support.microsoft.com/en-us/kb/2218556 (D4)

Er führt einige Schritt auf dem "PDC" aus weil er davon ausgeht dass hier die aktuellste variante seines sysvol Verzeichnisses liegt, das kann, muss aber nicht zutreffen - den pdc gibt es in der form ja nicht mehr wirklich.
Ein manueller Dateiabgleich kann hier Aufschluss geben wo das aktuellste sysvol Verzeichnis vorliegt...in der regel ist es aber tatsächlich die büchse mit der pdc rolle.

1. Windows Clients sind Site-aware, d.h., wenn die Subnets richtig gepflegt sind, dann melden sie sich am 'lokalen' DC des Standortes an.
2. Der PDCe ist bei Gruppenrichtlinien natürlich wichtig, da sich das Snap-In standardmäßig mit dem PDCe verbindet.
3. Welche Dateien sind denn unterschiedlich?
4. Was sagt repadmin /showrepl? (Wahrscheinlich auch keine Fehler, wenn das Active Directory Replication Status Tool keine findet)
5. Fraglich ist, ob das Problem überhaupt mit den DCs zu tun hat. Du schreibst, daß die Außenstellen-DCs die Änderungen übernehmen und das Tool keine Fehler anzeigt. Du solltest das Problem evtl. bei den Clients suchen (-> netlogon.log).

Hallo,

danke so weit.

An den Clients liegt es mMn nicht, denn der DC, der an einem Außenstandort steht (es ist nur einer, der nicht im LAN des Hauptstandortes steht), einen auffällig kleinen Ordner "Policies" (Windows\SYSVOL\sysvol\<Domäne>\) hat. Bei den beiden DCs am Hauptstandort sind die Ordner identisch, was die Anzahl der enthaltenen Dateien sowie die Größe betrifft. Am Außenstandort ist nur ein Bruchteil der Dateien vorhanden. Sprich, hier wird nicht korrekt repliziert.

Einen Zusammenhang mit den Clients sehe ich hier auf Anhieb nicht. Lasse mir aber gerne auf die Sprünge helfen.

Ich werde das Prozedere, das 0711 mir ans Herz gelegt hat, heute Abend mal austesten. Im laufenden Betrieb spiele ich ungerne an den Kisten herum. ;-)


Ansonsten, kurz als Denkanstoß: es besteht eine VPN-Verbindung via Sophos RED 50 (am Außenstandort) und Sophos ASG 220 (am Hauptstandort). Sämtliche DCs am Hauptstandort sind durch den VPN-Tunnel pingbar, weshalb ich den DC am Außenstandort einfach über das bekannte Prozdere zum DC ernannt habe.
Im AD habe ich keinen zusätzlichen Standort angelegt oder sonst etwas modifiziert. Möglicherweise liegt ja auch hier der Fehler. Wenngleich mich dann wundert, wieso er einen Teil der Daten durchaus repliziert. Auch wenn ich nun eine neue GPO oder einen neuen Nutzer anlege, wird er mir am DC des Außenstandortes angezeigt. Möchte ein Client, der an eben diesem DC angemeldet ist, nun jedoch per gpupdate /force ein Update ziehen, bekommt er die Fehlermeldung, dass dies nicht möglich sei.



Viele Grüße

Pingen hilft die da nicht. Kommt drauf an was für DCs zu hast. Aber bei 2008R2 nutzt DFSR meine ich immer Port 5722. Schau mal nochmal nach obs wirklich der ist und prüfe ob der Port auf beiden DCs offen und erreichbar ist. Was sagt das DFSR Eventlog? Was sagt das DFSR Debug Log?

Hallo,

habe die Prozedur nun mal durchgespielt und bin leider erfolglos geblieben. Die beiden DCs am Hauptstandort (Standort bitte nicht im Sinne eines AD-Standortes verstehen, sondern im ursprünglichen Wortsinn) verhalten sich exakt wie in dem Tutorial beschrieben. Auf die Event-ID 4114 folgt an dem "nicht-primären" DC die ID 4604, die angibt, dass die Replikation abgeschlossen wurde und es keine Fehler gab.

Der problematische DC am Außenstandort zeigt nach dem 4114 jedoch eine ID 2010, dann 1210 und schlussendlich 2213. Nun passiert nichts mehr. Der Ordner SYSVOL\sysvol\<Domäne>\Policies befindet sich wenig überraschenderweise in dem selben Zustand wie zuvor. Nichts wurde repliziert.

Es gibt keine Einschränkungen, was das VPN/Netzwerk betrifft. Beide Standorte dürfen ohne Einschränkung miteinander kommunizieren.


Hat hier jemand noch eine Idee?

Was sagt das DFSR Debug Log?

Hallo,

habe das Event 2213 nun mit folgender Herangehensweise "behandelt" (steht eigentlich sogar in der Event-Beschreibung, der Artikel führt es nur etwas besser aus): http://www.mikesaysmeh.com/how-to-fix-event-id-2213-for-dfsr/

Nun kriege ich auch auf dem problematischen DC eine 4604. Alles super.

Vielen Dank für Eure Hilfe!

Wenn du meine Frage nicht beantwortest kann dir auch keiner helfen.

Hallo ntloader,

ich habe das Problem ja bereits gelöst und dies in meinem letzten Beitrag kundgetan. Hätte das nicht funktioniert, wäre der Debug-Log die nächste Konsequenz gewesen. So war es aber nicht mehr nötig.

Vielen Dank für Eure Mühe und Zeit.

Beste Grüße