Windows Server 2008: Sysvol-Replikation: Ein DC fehlt?

[DeathAndPain2 10]

Hallo allerseits,

 

wir haben eine Windows Server 2008-Domäne mit folgender Struktur:

• Haupthaus mit 2 DCs
  
• eine Zweigstelle mit einem weiteren vollwertigen DC namens "SERVICE" in einer anderen Site
  
• 5 Zweigstellen mit RODCs in jeweils einer anderen Site
  

Jetzt ist mir aufgefallen, daß nach Meinung der beiden Haupthaus-DCs die SYSVOL-Replikation in alle Server mit Ausnahme von SERVICE erfolgt?! Der DC in jeder Zweigstelle sieht sich selber auch in jener Replikation. Es gibt also im DFS-Manager der beiden Haupthausserver bei der SYSVOL-Replikation einen Eintrag weniger als auf dem Server SERVICE und den RODCs: Der Server SERVICE ist bei den Haupthausservern nicht in der Liste der SYSVOL-Replikationsziele. Wie kann man diesen Schiefstand beheben?

 

Leider sind im DFS Manager viele Optionen für die SYSVOL-Replikation nicht vorhanden. Man kann im Prinzip nur gucken und nichts verändern. Ich kann also den Server nicht einfach händisch der Replikation hinzufügen.

[Daim 12]

Servus,

 

Wie kann man diesen Schiefstand beheben?

 

du sprichst von DFS. Habt ihr es bei euch denn so konfiguriert, dass die SYSVOL-Replikation, durch das DFS-R durchgeführt wird?

 

Siehe auch:

Ask the Directory Services Team : Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style

 

Denn "out-of-the-Box" wird weiterhin das SYSVOL-Verzeichnis unter Windows Server 2008 noch durch den File Replication Service repliziert (in Abhängigkeit vom DFL und ob es sich um eine neue oder migrierte Domäne handelt). Demzufolge müssten (sofern durch das FRS repliziert wird) im Dateireplikationsprotokoll Fehler auftauchen, die es auszuwerten gilt. Führe auch das DCDIAG auf SERVICE durch.

 

 

 

Nachtrag:

Ob das SYSVOL-Verzeichnis durch das FRS oder DFS-R repliziert wird hängt auch davon ab, ob eine neue Domäne mit dem Domänenfunktionsmodus "Windows Server 2008" erstellt wird. Denn dann, wird über DFS-R repliziert. Wird aber von Windows 2000/2003 auf Windows 2008 migriert, so müsste auch das SYSVOL von FRS auf DFS-R migriert werden, falls gewünscht.

[DeathAndPain2 10]

du sprichst von DFS. Habt ihr es bei euch denn so konfiguriert, dass die SYSVOL-Replikation, durch das DFS-R durchgeführt wird?

Ja, definitiv. Das hier ist eine völlig neue reinrassige Windows Server 2008-Umgebung, auch vom functional level her. Eine Migration hat es nicht gegeben. Das alte FRS habe ich gar nicht erst installiert.

 

Die von Dir verlinkte Dokumentation (ebenso wie andere Online-Doku, die ich finden konnte) beschäftigt sich leider immer nur mit der Migration von FRS zu DFS-R. Ich konnte bislang nirgendwo eine SYSVOL-Troubleshooting-Dokumentation für DFS-R finden, die nichts mit Migration von FRS zu tun hat.

[Daim 12]

Ja, definitiv. Das hier ist eine völlig neue reinrassige Windows Server 2008-Umgebung, auch vom functional level her. Eine Migration hat es nicht gegeben. Das alte FRS habe ich gar nicht erst installiert.

 

Ahh... ok, jetzt ist es klar.

 

In der DFS-Verwaltung steht aber in den Eigenschaften der einzelnen DCs, der Mitgliedschaftsstatus auf "Aktiviert"?

Wie sieht denn im Ereignisprotokoll, das DFS-Replikations Log, dass du unter den "Anwendungs- und Dienstprotokollen" findest, aus? Tauchen hier Fehler auf?

Wenn du magst, kannst du noch einen Blick in das DFSR-Log, dass du unter "%windir%\debug\dfsr0000x.log" findest, reinwerfen.

[DeathAndPain2 10]

In der DFS-Verwaltung steht aber in den Eigenschaften der einzelnen DCs, der Mitgliedschaftsstatus auf "Aktiviert"?

 

Sieh selbst:

 

Server BERLIN1:

 

 

Server SERVICE1:

 

 

Wie sieht denn im Ereignisprotokoll, das DFS-Replikations Log, dass du unter den "Anwendungs- und Dienstprotokollen" findest, aus? Tauchen hier Fehler auf?

Ich hatte die Berliner Server gestern nachmittag mal durchgebootet, in der Hoffnung, daß die dann ihre Replikationsgruppen neu aushandeln. Hat leider nichts gebracht. Auf dem Server BERLIN1 wurde überhaupt nichts geloggt, was mit der SYSVOL-Replikation mit dem Server SERVICE1 zu tun hätte.

 

Der Server SERVICE loggte das folgende:

 

 

(Alle älteren Einträge waren nicht relevant und bezogen sich hauptsächlich auf die andere Replikationsgruppe, die ich händisch eingerichtet habe und die auch funktioniert.)

 

Bei dem Error von 14:53:30 Uhr in obigem Bild handelt es sich um folgenden Eintrag:

 

 

Das war nicht weiter erstaunlich, denn das war genau der Zeitpunkt, als ich den Server BERLIN1 durchgebootet habe. Interessant ist aber der nachfolgende Informationseintrag von 14:58:31:

 

 

Der Server SERVICE1 ist also der Meinung, daß die SYSVOL-Replikation mit BERLIN1 einwandfrei läuft. Aber wie soll das möglich sein, wenn BERLIN1 den SERVICE1 als SYSVOL-Replikationspartner gar nicht kennt!?!? Da muß ich gestehen, daß ich dieser Replikation nicht wirklich über den Weg traue.

 

Wenn du magst, kannst du noch einen Blick in das DFSR-Log, dass du unter "%windir%\debug\dfsr0000x.log" findest, reinwerfen.

Auf dem Server SERVICE1 sind alle dort befindlichen Logs der letzten Tage aus der Zeit zwischen 20 und 21 Uhr. Um 20 Uhr wird immer das Verzeichnis der anderen Replikationsgruppe mit neuen Dateien versorgt. Deswegen gehe ich davon aus, daß alle Logeinträge sich nur auf die andere Replikationsgruppe und nicht auf SYSVOL beziehen. Selbst der Server-Reboot der BERLIN1 hat auf SERVICE1 zu keinerlei Logeintrag an dieser Stelle geführt.

 

In dem entsprechenden Log der BERLIN1 findet man schon Einträge aus der Zeit der Reboots, und wenn ich da reinschaue, dann kann ich auch erkennen, daß er da offenbar seine Replikation neu initialisiert hat. Aber natürlich ist dieses Log alles andere als übersichtlich, und ich sehe mich außerstande, daraus abzuleiten, warum der SERVICE1 in der SYSVOL-Replikationsgruppe der Maschinen BERLIN1 und BERLIN2 fehlt (aber in den SYSVOL-Replikationsgruppen der RODCs in den anderen Niederlassungen sehr wohl aufgeführt ist).

[olc 18]

Hi,

 

funktioniert die AD-Replikation zu den Standorten korrekt, in denen die DCs die Probleme aufweisen? Was sagt ein "repadmin /replsum" bzw. "repadmin /showreps", ausgeführt auf dem SERVICE1 und auf dem BERLIN1?

 

Sind auf dem Server Objekt von BERLIN1 alle DFS-R Subscriptions zu sehen, wenn Du Dich z.B. mittels ADSIEdit auf den SERVICE1 als auch den BERLIN1 verbindest? Sind die angezeigten Daten auf beiden Systemen konsistent (d.h. die Objekte auf dem BERLIN1, ausgelesen auf beiden Systemen)? --> siehe unten aufgeführten Artikel.

 

Was sagen die Health Reports für das SYSVOL?

 

Schau mal in folgenden Artikel, die Grundthematik greift auf alle DFS-R Replikationsgruppen, so auch das SYSVOL: Ask the Directory Services Team : Five Common Causes of “Waiting for the DFS Replication service to retrieve replication settings from Active Directoryâ€

 

Viele Grüße

olc

[DeathAndPain2 10]

Hi,

 

funktioniert die AD-Replikation zu den Standorten korrekt, in denen die DCs die Probleme aufweisen?

Eigentlich ja! Die Benutzer, die ich in letzter Zeit auf den anderen DCs (teilweise auch auf RODCs) angelegt habe, sind offenbar korrekt auf den SERVICE1 repliziert worden. Wann das genau geschehen ist, vermag ich natürlich nicht zu sagen, weil ich darauf nicht geachtet habe.

 

Ich würde gar nicht merken, daß etwas nicht stimmt, wenn nicht im DFS Manager so offensichtlich der Eintrag für den Server SERVICE1 fehlen würde, und das auch nur auf den Servern BERLIN1 und BERLIN2.

 

Was sagt ein "repadmin /replsum" bzw. "repadmin /showreps", ausgeführt auf dem SERVICE1 und auf dem BERLIN1?

 

BERLIN1

 

Replication Summary Start Time: 2008-07-24 13:49:20



Beginning data collection for replication summary, this may take awhile:

 ...........





Source DSA          largest delta    fails/total %%   error

BERLIN1               02h:03m:10s    0 /  35    0  

BERLIN2                   51m:56s    0 /   5    0  





Destination DSA     largest delta    fails/total %%   error

BERLIN1                   51m:56s    0 /   5    0  

BERLIN2                   53m:04s    0 /   5    0  

ab                    01h:52m:05s    0 /   5    0  

cd                    02h:00m:06s    0 /   5    0  

ef                    01h:56m:59s    0 /   5    0  

gh                    01h:49m:56s    0 /   5    0  

ij                    02h:03m:11s    0 /   5    0  

SERVICE1              02h:01m:38s    0 /   5    0

 

Der SERVICE1 ist mit aufgeführt. Allerdings darf man nicht vergessen, daß wir ja noch eine zweite Replikationsgruppe haben, in der er korrekt drinsteht. Es ist also nicht überraschend, daß BERLIN1 ihn zum Zwecke der Replikation kennt. Nur halt nicht für das SYSVOL.

 

Haupthaus-Berlin\BERLIN1

DSA Options: IS_GC 

Site Options: (none)

DSA object GUID: 6556e0bc-xxxx-xxxx-xxxx-xxxxxxxxxxxx

DSA invocationID: 6556e0bc-xxxx-xxxx-xxxx-xxxxxxxxxxxx



==== INBOUND NEIGHBORS ======================================



DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN2 via RPC

       DSA object GUID: 0b8axxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 13:37:04 was successful.



CN=Configuration,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN2 via RPC

       DSA object GUID: 0b8axxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 12:57:24 was successful.



CN=Schema,CN=Configuration,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN2 via RPC

       DSA object GUID: 0b8axxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 12:57:24 was successful.



DC=DomainDnsZones,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN2 via RPC

       DSA object GUID: 0b8axxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 12:57:24 was successful.



DC=ForestDnsZones,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN2 via RPC

       DSA object GUID: 0b8axxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 12:57:24 was successful.

 

showreps zeigt nur den Server BERLIN2. Das ist der einzige Server, der in derselben Site steht wie BERLIN1. Die übrigen Server sind nur RODCs, aber SERVICE1 ist ein vollwertiger DC, der halt in einem anderen Standort angesiedelt ist.

 

~~~ Fortsetzung im nächsten Posting (4000-Zeichen-Beschränkung) ~~~

[DeathAndPain2 10]

SERVICE

 

Replication Summary Start Time: 2008-07-24 13:49:46



Beginning data collection for replication summary, this may take awhile:

 ...........





Source DSA          largest delta    fails/total %%   error

BERLIN1               02h:03m:36s    0 /  30    0  

BERLIN2                   52m:22s    0 /   5    0  





Destination DSA     largest delta    fails/total %%   error

BERLIN1                   52m:22s    0 /   5    0  

BR                    01h:52m:50s    0 /   5    0  

CB                    02h:00m:51s    0 /   5    0  

FW                    01h:57m:43s    0 /   5    0  

LU                    01h:50m:41s    0 /   5    0  

NP                    02h:03m:57s    0 /   5    0  

SERVICE1              02h:02m:24s    0 /   5    0  





Experienced the following operational errors trying to retrieve replication information:

         58 - BERLIN2.rohwedder.net

 

Hier haben wir also zum ersten Mal eine Fehlermeldung. Aber die betrifft offenbar nur den Server BERLIN2 und nicht BERLIN1. Doch auf beiden Servern fehlt ja der SERVICE1 in der SYSVOL-Replikation.

 

Service-Berlin\SERVICE1

DSA Options: IS_GC 

Site Options: (none)

DSA object GUID: c2aaxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

DSA invocationID: 62a9xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx



==== INBOUND NEIGHBORS ======================================



DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN1 via RPC

       DSA object GUID: 6556xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 11:47:44 was successful.



CN=Configuration,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN1 via RPC

       DSA object GUID: 6556xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 11:47:44 was successful.



CN=Schema,CN=Configuration,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN1 via RPC

       DSA object GUID: 6556xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 11:47:44 was successful.



DC=DomainDnsZones,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN1 via RPC

       DSA object GUID: 6556xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 11:47:44 was successful.



DC=ForestDnsZones,DC=unseredom,DC=net

   Haupthaus-Berlin\BERLIN1 via RPC

       DSA object GUID: 6556xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

       Last attempt @ 2008-07-24 11:47:44 was successful.

 

Was sagen die Health Reports für das SYSVOL?

Auf der BERLIN1 alles perfekt, aber eben nur für die sieben Server, die er kennt. Auf der SERVICE1 sieht die Sache so aus:

 

(Hier sollte eigentlich ein Bild sein. Aber momentan scheint mein Webspace etwas zu streiken. Also füge ich das Bild auch dem Posting bei, in der Hoffnung, daß ein Mod es bald freischaltet.)

 

Also hat die SERVICE1 anscheinend irgendein Problem mit der BERLIN2. Aber der zentrale Server für die Replikation ist die BERLIN1:

 

C:\>WMIC /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig get LastChangeSource

LastChangeSource       
berlin1.unseredom.net  
berlin1.unseredom.net

 

Sind auf dem Server Objekt von BERLIN1 alle DFS-R Subscriptions zu sehen, wenn Du Dich z.B. mittels ADSIEdit auf den SERVICE1 als auch den BERLIN1 verbindest?

Nein, auf dem Server BERLIN1 spiegelt sich hier das Fehlen des SERVICE1 auch wider:

 

(Hier sollte eigentlich ein Bild sein. Aber momentan scheint mein Webspace etwas zu streiken. Also füge ich das Bild auch dem Posting bei, in der Hoffnung, daß ein Mod es bald freischaltet.)

[DeathAndPain2 10]

Der Artikel, den Du mir verlinkt hast, ist sehr interessant. Ich muß mich damit noch mal genauer beschäftigen. Aber vielleicht hast Du aufgrund Deiner oben beantworteten Fragen noch Tipps für mich?

[olc 18]

Hi Death,

 

in den Screenshots ist leider nicht zu sehen, ob in ADSIEdit (auf Service1 als auch Berlin1 und Berlin2 --> "Connect to" in ADSIEdit benutzen) auf den DC Objekten auch alle DFSR Subscriptions liegen. Bitte prüfe das noch einmal, siehe http://www.mcseboard.de/windows-forum-lan-wan-32/dfs-fehlermeldung-133262.html.

 

Warum ist dort bei den Servern der SERVICE1 nicht mit aufgeführt? Auf welchen DC warst Du mit ADSIEdit beim Screenshot verbunden? Weiß dieser DC unter Umständen gar nichts vom SERVICE1 (Stichwort Replikationsprobleme)?

Der DC SERVER1 ist (zumindest auf dem DC, mit dem Du verbunden warst mit ADSIEdit) nicht in der Replikationsgruppe SYSVOL, das ist Fakt. Wann ist das System promotet worden - nach den anderen DCs? Irgend ein Unterschied zu den anderen Systemen?

 

Hast Du im SYSVOL einmal eine Datei abgelegt und geprüft, ob diese auf allen Servern ankommt (siehe Link von Daim, Stichwort "Kanarienvogel". ;)? Wird sicherlich nicht funktionieren, aber testen sollte man es für alle Fälle.

 

Interessant ist außerdem auch der im Health Report angegebene DCOM Fehler. Findest Du dazu irgendetwas im Eventlog des BERLIN1 / BERLIN2 bzw. im DFSR Debug Log des BERLIN1 / BERLIN2?

 

Gruß olc

 

P.S.: Schau noch einmal die von Dir geposteten Ausgaben oben an, da ist noch ein oder zwei Mal der Domänenname der Umgebung zu finden... :)

 

Gruß olc

[DeathAndPain2 10]

in den Screenshots ist leider nicht zu sehen, ob in ADSIEdit (auf Service1 als auch Berlin1 und Berlin2 --> "Connect to" in ADSIEdit benutzen) auf den DC Objekten auch alle DFSR Subscriptions liegen. Bitte prüfe das noch einmal, siehe http://www.mcseboard.de/windows-forum-lan-wan-32/dfs-fehlermeldung-133262.html.

Ich bin nicht sicher, was Du mit der Formulierung "auf den DC Objekten auch alle DFSR Subscriptions liegen" meinst. Sicher ist, daß auf BERLIN1 und BERLIN2 im Zweig

 

Default naming context -> DC=unseredom, DC=net -> CN=System -> CN=DFSR-GlobalSettings -> CN=Domain System Volume -> CN=Topology

 

der Server SERVICE1 fehlt, während alle anderen Server dort aufgeführt sind.

 

Mittlerweile taucht der SERVICE1 auch in der SYSVOL-Replikation auf den RODCs (also im DFS Manager) nicht mehr auf. Nur auf dem SERVICE1 selbst ist der Eintrag noch vorhanden.

 

Die andere Replikationsgruppe, über die wir unser Intranet verteilen, funktioniert aber. Der SERVICE1 bekommt damit einwandfrei die Änderungen, die auf der BERLIN1 vorgenommen wurden. Man kann also nicht behaupten, aus netzwerktechnischen Gründen würden die Server nicht richtig miteinander kommunizieren können. Nur die SYSVOL-Replikation ist betroffen. Und das ist leider auch gerade die, bei der der DFS Manager manuelle Änderungen verweigert.

 

Warum ist dort bei den Servern der SERVICE1 nicht mit aufgeführt?

Das ist die Frage, um die es in diesem Thread hier geht. :)

 

Auf welchen DC warst Du mit ADSIEdit beim Screenshot verbunden?

Auf der BERLIN1. Auf der BERLIN2 sieht es genauso aus, und wie gesagt, mittlerweile auch auf den abhängigen RODCs.

 

Weiß dieser DC unter Umständen gar nichts vom SERVICE1 (Stichwort Replikationsprobleme)?

Warum repliziert er dann das Intranet einwandfrei auf die SERVICE1?

 

Wann ist das System promotet worden - nach den anderen DCs?

Ja. Soweit ich mich erinnere, gab es zuerst den BERLIN1, mit dem die Domäne neu geschaffen wurde (keine Migration). Dann kam der BERLIN2 hinzu, danach die RODCs. Wenn ich mich recht entsinne, kam der SERVICE1 zum Schluß.

 

Irgend ein Unterschied zu den anderen Systemen?

Der SERVICE1 ist der einzige vollwertige DC (also nicht RODC), der nicht in derselben Site wie die DCs BERLIN1 und BERLIN2 steht.

 

Hast Du im SYSVOL einmal eine Datei abgelegt und geprüft, ob diese auf allen Servern ankommt (siehe Link von Daim, Stichwort "Kanarienvogel". ? Wird sicherlich nicht funktionieren, aber testen sollte man es für alle Fälle.

Versuch ich jetzt mal. Dauert aber drei Stunden, bevor ich eine verläßliche Aussage machen kann.

 

Was ist eigentlich mit der Fehlermeldung bei der Replication Summary und dem Health Report bezüglich der Replikation zwischen BERLIN2 und SERVICE1 (siehe mein voriges Posting)? Wie ist die einzuschätzen, und was kann man da machen? BERLIN2 und BERLIN1 stehen schließlich als vollwertige DCs in derselben Site, und wenn die BERLIN2 ein Problem mit SERVICE1 hat, dann hat sie vielleicht die BERLIN1 dazu gebracht, den SERVICE1 aus der SYSVOL-Replikation zu nehmen?

[olc 18]

Hallo,

 

ich gehe jetzt mal nicht auf alle Punkte ein, weil eine Ursachenanalyse an dieser Stelle (und vor allem: mit den vorhandenen Daten) wahrscheinlich eher schwierig ist.

 

Du hast meines Erachtens im Moment drei Möglichkeiten, das Problem zu lösen:

1. Den DC SERVICE1 neu promoten ("schnell und schmutzig Variante").
   
2. Du könntest die DFSR Objekte aus einem Backup autorativ wiederherstellen (würde ich auch nicht unbedingt empfehlen, da in der Zwischenzeit schon Änderungen an der Struktur durchgeführt wurden, die damit verloren wären)
   
3. Das SYSVOL manuell neu auf dem System hosten. Da ich das jedoch bisher noch nicht gemacht habe, habe ich keine Ahnung, ob das funktioniert. :D
   Ich vermute einmal, Du kannst mittels dfsradmin den Server (ausgeführt auf SERVICE1) aus der Replikationsgruppe entfernen und danach wieder hinzufügen. Da SYSVOL nicht irgend eine Replikationsgruppe ist, wird man dabei jedoch sicherlich einiges zu beachten haben. Ich teste das bei Gelegenheit einmal und melde mich bei Erfolg. Solltest Du es vorher hinbekommen haben, wäre iene Meldung klasse.
   

 

Viele Grüße

olc

[DeathAndPain2 10]

Ich denke, ich habe die Ursache gefunden.

 

Auf dem Server BERLIN2 war die Routingtabelle fehlerhaft gepflegt. Dadurch konnte dieser Server mit keiner anderen Site (d.h. mit keinem anderen DC oder RODC außer BERLIN1) kommunizieren. Dadurch wurden dann auch Events geloggt wie der, daß es in der Service-Site keinen Global Catalog Server gäbe und das daher von der Haupthaus-Site mitgemacht werden würde.

 

Ich habe die Routingtabelle korrigiert, aber dadurch ist natürlich der AD-Schiefstand noch nicht weg. Zur Lösung habe ich mich für Deine "schnell und schmutzig -Variante" entschieden. Allerdings gab es beim demoten des Servers SERVICE1 ein Problem:

 

 

Wie mache ich das genau? Das muß ich doch sicherlich auf dem Server BERLIN1 einstellen. An welcher Stelle wird das gemacht? Oder kann ich das einfach ignorieren, da ich den SERVICE1 ja sowieso wieder promoten will?

[olc 18]

Hi Death,

 

über die Replikation hatten wir doch aber gesprochen oder? ;)

Funktioniert hierbei etwas nicht richtig, wird das auch in den Eventlogs der DCs geloggt - das hätte auffallen können / müssen, zumal wir darüber gesprochen haben... ;)

 

Da Du den DC erneut promoten wirst, ist die Meldung zumindest grundsätzlich kein Stolperstein. Zwei Dinge sind dabei jedoch trotzdem relevant:

 

1. Wenn Du einen RPC Fehler bekommst, kann entweder mit dem DNS oder aber mit der Netzwerkverbindung immer noch etwas nicht stimmen. Das solltest Du prüfen, bevor Du weiter machst.
   
2. Da die RODCs scheinbar (Deinen Aussagen zur Folge) auch erst recht spät von den Änderungen "erfahren", sind hier unter Umständen auch Replikationsprobleme vorhanden. Bevor Du den DC neu promotest, solltest Du auch hier noch einmal prüfen, ob es hier Änderungsbedarf gibt.
   

 

Viele Grüße

olc