7
Kopien von DNS-Zone in mehreren Verzeichnispartitionen (EventID 4515)
Hi folks!
Im Ereignisprotokoll unserer beiden Domaincontroller erscheint nach dem Hochfahren folgende Meldung:
Beschreibung:
Daten:
Kennt jemand dieses Problem oder hat einen Lösungsansatz?
Nebenbemerkung: Der BDC hat letztens geschlagene 8 Stunden zum Hochfahren nach einem Reboot gebraucht. Daraufhin bin ich auf diesen Eintrag gestoßen, weil ich denke, dass er wegen dieser Zonenkopie so lange rum mehrt.
Im Ereignisprotokoll unserer beiden Domaincontroller erscheint nach dem Hochfahren folgende Meldung:
Ereignistyp: Warnung
Ereignisquelle: DNS
Ereigniskategorie: Keine
Ereigniskennung: 4515
Datum: 17.09.2010
Zeit: 06:26:16
Benutzer: Nicht zutreffend
Computer: BDC01
Ereignisquelle: DNS
Ereigniskategorie: Keine
Ereigniskennung: 4515
Datum: 17.09.2010
Zeit: 06:26:16
Benutzer: Nicht zutreffend
Computer: BDC01
Beschreibung:
Die Zone "werdom2.local" wurde bereits von der Verzeichnispartition "MicrosoftDNS" geladen, aber eine neue Kopie der Zone wurde in der Verzeichnispartition >> "DomainDnsZones.werdom2.local" gefunden. Der DNS-Server wird diese neue Kopie der Zone ignorieren. Beheben Sie diesen Konflikt so bald wie möglich.
Wenn ein Administrator diese Zone von einer Verzeichnispartition in eine andere verlegt hat, ist dies vielleicht ein vorübergehender unbedenklicher Zustand. In diesem Fall sind keine Maßnahmen erforderlich. Der Löschvorgang des Originals der Kopie in dieser Zone sollte bald zu diesem Server repliziert werden.
Wenn es zwei Ausgaben dieser Zone in zwei verschiedenen Verzeichnispartitionen gibt, dies aber kein Übergang ist, der durch eine Zonenverschiebung verursacht wurde, dann sollte eine dieser Kopien so bald wie möglich gelöscht werden, um diesen Konflikt zu beheben.
Der Replikationsbereich einer Anwendungsverzeichnispartition die DNS-Zonen enthalten und weitere Details über die Speicherung von DNS-Zonen in der Anwendungsverzeichnispartition finden Sie im Hilfe- und Supportcenter.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Wenn ein Administrator diese Zone von einer Verzeichnispartition in eine andere verlegt hat, ist dies vielleicht ein vorübergehender unbedenklicher Zustand. In diesem Fall sind keine Maßnahmen erforderlich. Der Löschvorgang des Originals der Kopie in dieser Zone sollte bald zu diesem Server repliziert werden.
Wenn es zwei Ausgaben dieser Zone in zwei verschiedenen Verzeichnispartitionen gibt, dies aber kein Übergang ist, der durch eine Zonenverschiebung verursacht wurde, dann sollte eine dieser Kopien so bald wie möglich gelöscht werden, um diesen Konflikt zu beheben.
Der Replikationsbereich einer Anwendungsverzeichnispartition die DNS-Zonen enthalten und weitere Details über die Speicherung von DNS-Zonen in der Anwendungsverzeichnispartition finden Sie im Hilfe- und Supportcenter.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Daten:
0000: 89 25 00 00 %..
Kennt jemand dieses Problem oder hat einen Lösungsansatz?
Nebenbemerkung: Der BDC hat letztens geschlagene 8 Stunden zum Hochfahren nach einem Reboot gebraucht. Daraufhin bin ich auf diesen Eintrag gestoßen, weil ich denke, dass er wegen dieser Zonenkopie so lange rum mehrt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 152395
Url: https://administrator.de/contentid/152395
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
Peter
Zitat von @kleinerbub:
Im Ereignisprotokoll unserer beiden Domaincontroller erscheint nach dem Hochfahren folgende Meldung:
Und wie immer: Welche OS Versionen?Im Ereignisprotokoll unserer beiden Domaincontroller erscheint nach dem Hochfahren folgende Meldung:
Nebenbemerkung: Der BDC
Aha, Ihr habt noch NT4 im Einsatz.Peter
Im Ereignisprotokoll unserer beiden Domaincontroller erscheint nach dem Hochfahren folgende Meldung:
Und wie immer: Welche OS Versionen?
jeweils Windows Server 2003 Standard SP2Nebenbemerkung: Der BDC
Aha, Ihr habt noch NT4 im Einsatz.
Moin
ein AD hat keinen BDC!!
sollte nach x Jahren so langsam bekannt sein...
Gruß
24
ein AD hat keinen BDC!!
sollte nach x Jahren so langsam bekannt sein...
Gruß
24
Ok, haste natürlich Recht. Da hab ich mich in der Überschrift vertan. Habs mal geändert.
Aber aus der Fehlermeldung geht ja hervor, dass die DNS-Zone gemeint ist.
Es gibt also einen primären Domaincontroller mit ActiveDirectory-integrierter DNS-Zone und einen "Backupdomaincontroller", der die Replica hält. Ich denke, diese Konfiguration sollte so Standard und daher verständlich sein.
Die o.g. Meldung erscheint unter DNS im Ereignisprotokoll beider Server.
Aber aus der Fehlermeldung geht ja hervor, dass die DNS-Zone gemeint ist.
Es gibt also einen primären Domaincontroller mit ActiveDirectory-integrierter DNS-Zone und einen "Backupdomaincontroller", der die Replica hält. Ich denke, diese Konfiguration sollte so Standard und daher verständlich sein.
Die o.g. Meldung erscheint unter DNS im Ereignisprotokoll beider Server.
Problem behoben!
An alle, die das selbe Problem haben nochmal Step by Step, wie ich das gelöst habe:
1. Als erstes hab ich die beiden Server, um die es ging virtualisiert, um in einer sicheren Versuchsumgebung ähnliche Voraussetzungen zu schaffen. Dort konnte ich nach belieben experimentieren und nach der Lösung suchen.
2. Dann hab ich auf dem virtualisierten DC mit ntbackup den Systemstate gesichert, per "csvde -f filename.csv" einen Textauszug des Active Directory gemacht, um im E-Fall nachvollziehen zu können in welchen Gruppen die User waren.
3. Als nächstes ein Test, ob die Wiederherstellung des AD im E-Fall funktionieren würde:
Also ran an die Buletten:
4. Nach Artikel KB867464 hab ich dann die faule Kopie gesucht, es gab ja 3 Möglichkeiten des Speicherortes
5. Ein Neustart des DNS-Dienstes und ein Blick ins Fehlerprotokoll zeigte, dass das Problem behoben war, zum Glück ohne Wiederherstellung des AD
6. Schritte 2,4 und 5 dann am Produktiv-System mit dem selben Ergebnis durchgeführt.
7. Wieder mal jede Menge gelernt.
Woher dieses Problem kam, weiß ich allerdings bis jetzt nicht. Dazu schweigt sich selbst Microsoft aus, da bei uns definitiv keiner versucht hat "die Zone von einer Verzeichnispartition in eine andere zu verschieben". Könnte mir nur vorstellen, dass es mit der AD-Funktionsebene zu tun hat. Wir arbeiten momentan noch mit Win2003 Server auf "Windows 2000 pur" Funktionsebene.
Ich hoffe, damit dem ein oder anderen eine kleine Hilfestellung geben zu können.
An alle, die das selbe Problem haben nochmal Step by Step, wie ich das gelöst habe:
1. Als erstes hab ich die beiden Server, um die es ging virtualisiert, um in einer sicheren Versuchsumgebung ähnliche Voraussetzungen zu schaffen. Dort konnte ich nach belieben experimentieren und nach der Lösung suchen.
2. Dann hab ich auf dem virtualisierten DC mit ntbackup den Systemstate gesichert, per "csvde -f filename.csv" einen Textauszug des Active Directory gemacht, um im E-Fall nachvollziehen zu können in welchen Gruppen die User waren.
3. Als nächstes ein Test, ob die Wiederherstellung des AD im E-Fall funktionieren würde:
- User im AD gelöscht
- DC im DSRM (Directory Service Restore Mode) gebootet (Stichwort F8)
- "autorisierende Wiederherstellung" durchgeführt (gut beschrieben im Technet
- DC normal gebootet --> User war mitsamt Gruppen wieder da
Also ran an die Buletten:
4. Nach Artikel KB867464 hab ich dann die faule Kopie gesucht, es gab ja 3 Möglichkeiten des Speicherortes
- mit adsiedit hab ich alle 3 DNS-Partitionen eingebunden und geschaut, welche Einträge sie jeweils haben
- dabei stellte sich heraus, dass auf dem DC die richtige Version der Zone lag und unter DomainDNSZones eine falsche Kopie, die nicht vollständig war
- nach Rechtsklick auf die Zone (in meinem Fall werdom2.local) und Klick auf Löschen, war das Übel beseitigt.
5. Ein Neustart des DNS-Dienstes und ein Blick ins Fehlerprotokoll zeigte, dass das Problem behoben war, zum Glück ohne Wiederherstellung des AD
6. Schritte 2,4 und 5 dann am Produktiv-System mit dem selben Ergebnis durchgeführt.
7. Wieder mal jede Menge gelernt.
Woher dieses Problem kam, weiß ich allerdings bis jetzt nicht. Dazu schweigt sich selbst Microsoft aus, da bei uns definitiv keiner versucht hat "die Zone von einer Verzeichnispartition in eine andere zu verschieben". Könnte mir nur vorstellen, dass es mit der AD-Funktionsebene zu tun hat. Wir arbeiten momentan noch mit Win2003 Server auf "Windows 2000 pur" Funktionsebene.
Ich hoffe, damit dem ein oder anderen eine kleine Hilfestellung geben zu können.
Hallo kleinerbub,
Danke für deine ausführliche Rückmeldung. Klasse. Sauber beschrieben.
(Und von einem PDC oder BDC sprichst du auch nicht mehr
)
Peter
Danke für deine ausführliche Rückmeldung. Klasse. Sauber beschrieben.
(Und von einem PDC oder BDC sprichst du auch nicht mehr
)Peter
Danke!
Ok, war wohl etwas unglücklich gewählt. Geb ich ja zu.
(Und von einem PDC oder BDC sprichst du auch nicht mehr )
)Ok, war wohl etwas unglücklich gewählt. Geb ich ja zu.
