33
Domaincontroller zum Testen clonen
Morgen,
ich würde gerne ein paar Tests an der Domäne machen. Dazu die gestrige Sicherung eines DCs restored und in ein eigenes Netzwerk getan (quasi Maschine komplett unangetastet, nur anderen virtuellen Netzwerkstecker angeschlossen)
(Der DC ist der InfrastructureMaster / PDC Emulator / RID master etc. - also hat alle wichtigen Themen in sich vereint).
Nach dem Booten ist es aber so das der DC meint an einem nicht identifiziertem öffentlichen Netzwerk zu hängen, Get-ADDomain etc. funktioniert nicht. Das Netzwerk Ein/Ausstecken hat leider auch nichts gebracht.
Server ist ein 2012R2, Domain Mode ist 2008R2, insgesamt sinds 5 DCs und wenn die im Produktivbetrieb nacheinander gebootet werden etc, funktioniert auch alles
Muss ich noch einen magischen Button drücken damit der Server wieder meint er sei ein DC?
PS: VM Clonen führt zum selben ergebnis, es liegt also nicht an einem schlechten Backup o.ä.
ich würde gerne ein paar Tests an der Domäne machen. Dazu die gestrige Sicherung eines DCs restored und in ein eigenes Netzwerk getan (quasi Maschine komplett unangetastet, nur anderen virtuellen Netzwerkstecker angeschlossen)
(Der DC ist der InfrastructureMaster / PDC Emulator / RID master etc. - also hat alle wichtigen Themen in sich vereint).
Nach dem Booten ist es aber so das der DC meint an einem nicht identifiziertem öffentlichen Netzwerk zu hängen, Get-ADDomain etc. funktioniert nicht. Das Netzwerk Ein/Ausstecken hat leider auch nichts gebracht.
Server ist ein 2012R2, Domain Mode ist 2008R2, insgesamt sinds 5 DCs und wenn die im Produktivbetrieb nacheinander gebootet werden etc, funktioniert auch alles
Muss ich noch einen magischen Button drücken damit der Server wieder meint er sei ein DC?
PS: VM Clonen führt zum selben ergebnis, es liegt also nicht an einem schlechten Backup o.ä.
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: 494561
Url: https://administrator.de/contentid/494561
Ausgedruckt am: 24.11.2024 um 00:11 Uhr
33 Kommentare
Neuester Kommentar
Moin,
In was für einem "Netzwerk" hängt er denn?
Als VM findet der sich erstmal in einer "ganz anderen Umgebung".je nach Konfiguration muß man die Adaptereinstellungen noch anpassen, damit das Netzwerk "wieder stimmt".
Du solltest ein Isoliertes Testnetz aufbauen und den da reinhängen.
lks
Edit: Typo
In was für einem "Netzwerk" hängt er denn?
Als VM findet der sich erstmal in einer "ganz anderen Umgebung".je nach Konfiguration muß man die Adaptereinstellungen noch anpassen, damit das Netzwerk "wieder stimmt".
Du solltest ein Isoliertes Testnetz aufbauen und den da reinhängen.
lks
Edit: Typo
Ich schätze mal, dass Du einen anderen IP-Bereich in der andrren Umgebung hast, die passen natürlich nicht zu dem was im DNS hinterlegt ist. Also: per VLANs oder ähnlichem trennen und gleiche IP-Range nutzen
Oder noch schlimmer der TO lässt ihn im DHCP Modus laufen, was natürlich tödlich für einen Server ist. Die Fehlermeldung kommt dann aufgrund der fehlenden IP bzw. des Gateways weil die Auto Netzwerk Erkennung von Winblows dann nicht mehr funktioniert.
Eine statische IP wie es sich gehört und ein statisches Gateway sollten das fixen.
Eine statische IP wie es sich gehört und ein statisches Gateway sollten das fixen.
Hi,
also der Server hat natürlich eine feste IP.
Das Testnetzwerk ist komplett ein anderes Netzwerk auf Layer2 - daher hat der geclonte Server einfach die selbe IP behalten wie vorher.
Das Gateway ist auf diesem testnetzwerk nicht erreichbar - aber ist das schlimm? Die Kiste sollte ja auch offline arbeiten können?
also der Server hat natürlich eine feste IP.
Das Testnetzwerk ist komplett ein anderes Netzwerk auf Layer2 - daher hat der geclonte Server einfach die selbe IP behalten wie vorher.
Das Gateway ist auf diesem testnetzwerk nicht erreichbar - aber ist das schlimm? Die Kiste sollte ja auch offline arbeiten können?
moin...
bitte nicht irgendeine, sondern seine OP.....
Das Gateway ist auf diesem testnetzwerk nicht erreichbar - aber ist das schlimm? Die Kiste sollte ja auch offline arbeiten können?
ja....
schon mal den NLA Dienst neu gestartet... und auf verzögert gestellt?
Frank
bitte nicht irgendeine, sondern seine OP.....
Das Testnetzwerk ist komplett ein anderes Netzwerk auf Layer2 - daher hat der geclonte Server einfach die selbe IP behalten wie vorher.
ok...Das Gateway ist auf diesem testnetzwerk nicht erreichbar - aber ist das schlimm? Die Kiste sollte ja auch offline arbeiten können?
schon mal den NLA Dienst neu gestartet... und auf verzögert gestellt?
Frank
Das Gateway ist auf diesem testnetzwerk nicht erreichbar - aber ist das schlimm?
Nein, aber dafür solltest du dann irgendwas eintragen. Drucker, Client o.ä. was im Testnetz ist. Erst dann funktioniert die Windows Netzwerk Autoerkennung.
Zitat von @NetzwerkDude:
Das Testnetzwerk ist komplett ein anderes Netzwerk auf Layer2 - daher hat der geclonte Server einfach die selbe IP behalten wie vorher.
Ist er sein eigener DNS-Server? Falls nein, wurde dieser auch geklont und steht im Test-Netz bereit?Das Testnetzwerk ist komplett ein anderes Netzwerk auf Layer2 - daher hat der geclonte Server einfach die selbe IP behalten wie vorher.
Seine eigene IP blieb gleich und auch die Gateway IP blieb gleich - das Gateway ist aus dem Testnetzwerk nicht erreichbar. Der DC ist einfach allein in diesem Netzwerk mit einem Client PC - der Client ist im selben subnetz und kommunikation ist Netzwerktechnisch möglich (ping etc.))
NLA gerade paarmal neugestartet, keine änderung
NLA gerade paarmal neugestartet, keine änderung
Ja, er ist sein eigener DNS Server
Okay, ich trag da mal den Client ein....
Das brachte keine besserung
Das Gateway ist auf diesem testnetzwerk nicht erreichbar - aber ist das schlimm?
Nicht schlimm, aber ja, anhand der MAC Adresse des Gateways ermittelt Windows um welches Netzwerk es sich handelt, ob öffentlich, privat, domain. Den Modus/Firewall-Profil des aktuellen Netzes kannst du über secpol.msc > "Netzwerk-Manager -Richtlinien" festlegen.
moin...
ist er den jetzt im domänennetzwerk ? bekommst du eine netzwerk auswahl? mit dem öffentlichen Netzwerk geht kein AD...
stell mal den NLA auf verzögert... und starte neu
Frank
ist er den jetzt im domänennetzwerk ? bekommst du eine netzwerk auswahl? mit dem öffentlichen Netzwerk geht kein AD...
stell mal den NLA auf verzögert... und starte neu
Frank
Grad andere Arbeit reingekommen - ich melde mich wenn ich da weitermache, ggf. am Montag
Also NLA auf verzögert gestellt
Unabhängig davon: Das booten dauert unendlich ("Einen Moment Geduld bitte" mit den Punktkreiseln) - erst wenn man das Virtuelle Netzwerkkabel zieht bootet er in annehmbarer zeit.
Also irgendwas ist da faul - in welchen Logs kann ich stöbern um das Problem einzugrenzen?
Unabhängig davon: Das booten dauert unendlich ("Einen Moment Geduld bitte" mit den Punktkreiseln) - erst wenn man das Virtuelle Netzwerkkabel zieht bootet er in annehmbarer zeit.
Also irgendwas ist da faul - in welchen Logs kann ich stöbern um das Problem einzugrenzen?
Hast du meinen Kommentar zum Thema überlesen?
Ich hab ihn gelesen, aktuell bootet die kiste noch - irgendwas stimmt da nicht
Also jetzt sagt der Server das er im Domänennetzwerk ist - vermutlich durch das NLA auf verzögert stellen... oder weil IPv6 aus war, und nun eingeschaltet wurde
Aber get-addomain funktioniert nicht, auch keine verwaltungstools etc.
DNS dienst läuft, auch die Active-Directory-Domänendienste laufen
Aber get-addomain funktioniert nicht, auch keine verwaltungstools etc.
DNS dienst läuft, auch die Active-Directory-Domänendienste laufen
Okay, habe was:
EventLog im Active-Directory-Domänendienste: EventID 2092
(kann den fehler nicht raus-copy-und-pasten da es in der VMware remote console läuft... ich boot nochmal
)
EventLog im Active-Directory-Domänendienste: EventID 2092
(kann den fehler nicht raus-copy-und-pasten da es in der VMware remote console läuft... ich boot nochmal
)
Kann es sein, dass Du den DC hetzt?
Der DC ist jetzt allein. Er ist selbst der DNS-Server. Die DNS-Zone höchstwahrscheinlich AD-integriert. Seine DC-Kumpels findet er nicht.
Du solltest ihn also nach dem Booten ca. 30 min in Ruhe lassen.
Der DC ist jetzt allein. Er ist selbst der DNS-Server. Die DNS-Zone höchstwahrscheinlich AD-integriert. Seine DC-Kumpels findet er nicht.
Du solltest ihn also nach dem Booten ca. 30 min in Ruhe lassen.
Okay, das ist ein interessanter Tipp... ich hol mir ein Bier
EventID 1311 (Error):
"Die Konsistenzprüfung hat Probleme mit der folgenden Verzeichnispartition festgestellt.
Verzeichnispartition:
CN=Configuration,DC=name1,DC=name2
Es gibt für die Konsistenzprüfung nicht genügend Standortskonnektivitätsinformationen, um eine umfassende Gesamtstruktur-Replikationstopologie zu erstellen. Zudem besteht die Möglichkeit, dass mindestens ein Verzeichnisserver mit dieser Verzeichnispartition nicht in der Lage war, die Verzeichnispartitioninformationen zu replizieren. Dies liegt vermutlich an nicht zugreifbaren Verzeichnisservern.
Benutzeraktion
Führen Sie einen der folgenden Schritte aus:
- Veröffentlichen Sie genügend Informationen über Standortkonnektivität, sodass die Konsistenzprüfung eine Route ermitteln kann, durch die die Verzeichnispartition diesen Standort erreichen kann. Diese Option wird empfohlen.
- Fügen Sie von einem Verzeichnisdienst mit derselben Verzeichnispartition auf einem anderen Standort ein Verbindungsobjekt zu einem Verzeichnisdienst mit der Verzeichnispartition an diesem Standort hinzu.
Wenn keine dieser beiden Aufgaben den Problemzustand behebt, überprüfen Sie die bisher durch die Konsistenzprüfung protokollierten Ereignisse, die die nicht zugreifbaren Verzeichnisserver identifizieren."
Er wird noch mehr solch Zeug loggen. Ist doch logisch! Er ist jetzt isoliert.
Scheint mir mehr so ein henne-ei thema zu sein: Er startet den Dienst nicht weil er allein ist
Also ich konnte den nur zum laufen bekommen wenn ich einen zweiten DC in den Testnetz hingestellt habe - alleine weigert er sich (mit den o.g. Fehlern)
Daher eine bitte:
Könnt ihr auch versuchen einen DC aus einem größeren verbund nehmen und einsam und alleine in einem Netzwerk booten - ist das jetzt hier config hier die das verhindert, oder ist das ein grundsätzliches problem?
MFG
N-Dude
Daher eine bitte:
Könnt ihr auch versuchen einen DC aus einem größeren verbund nehmen und einsam und alleine in einem Netzwerk booten - ist das jetzt hier config hier die das verhindert, oder ist das ein grundsätzliches problem?
MFG
N-Dude
Geht hier problemlos, schon x mal durch exerziert. Ich schätze die virtuelle NIC wurde nicht richtig konfiguriert. Da sie in einem anderen Netz hängt hat sie sehr wahrscheinlich eine neue MAC erhalten und eine Default-Config geladen. Überprüfe NIC Settings sowie DNS-Server Einträge der NIC.
Also das war ein restore vom Backup, da wird die VM eigentlich so genommen wie sie war - ich kann gerne die MAC am Montag nochmal abgleichen, müsste aber die selbe sein
moin..
bist du sicher, das der DC alle rollen inne hat?... ein restore im test netz ist eigentlich kein problem.
was macht der orginal DC wenn er den zweiten DC nicht hat... das gleiche? wenn ja, stimmt was nicht!
Frank
Zitat von @NetzwerkDude:
Also das war ein restore vom Backup, da wird die VM eigentlich so genommen wie sie war - ich kann gerne die MAC am Montag nochmal abgleichen, müsste aber die selbe sein
wie wurde das backup erstellt?Also das war ein restore vom Backup, da wird die VM eigentlich so genommen wie sie war - ich kann gerne die MAC am Montag nochmal abgleichen, müsste aber die selbe sein
bist du sicher, das der DC alle rollen inne hat?... ein restore im test netz ist eigentlich kein problem.
was macht der orginal DC wenn er den zweiten DC nicht hat... das gleiche? wenn ja, stimmt was nicht!
Frank
Zitat von @NetzwerkDude:
Scheint mir mehr so ein henne-ei thema zu sein: Er startet den Dienst nicht weil er allein ist
Nichts neues, nicht besonderes. Nennt sich "Insel-Effekt" und ist im Web bekannt.Scheint mir mehr so ein henne-ei thema zu sein: Er startet den Dienst nicht weil er allein ist
Wenn er schneller verfügbar wird, wenn ein 2. DC verfügbar ist, dann liegt da ein handwerklicher Fehler vor. DNS, FSMO, GC nicht vergessen! NIC muss aktiv sein (verbunden) und eine statische IP-Adresse haben. DC sich selbst als DNS. DNS-Zone bei solchen Test vorzugweise vorher als Datei vorbereiten, also nicht AD-integriert. Oder wenn doch AD-integriert, dann eben nach dem Booten warten, bis der DC im Eventlog meldet, dass er betriebsbereit ist. Man kann für sowas auch die Freigaben SYSVOL und NETLOGON löschen. Wenn der DC diese automatisch wieder erstellt hat, dann ist das ein sicheres Indiz dafür, dass er dann betriebsbereit ist.
Oder, man bereitet noch in der Produktiv-Umgebung eine dritte VM als DNS-Server vor, als Member-Server. Diesem eine klassische Sekundär-Zone verpassen. Diese dritte VM dann auch in der Test-Umgebung bereitstellen und dem DC als ersten DNS-Server mitgeben.
Danke für die Ausführungen.
Schlussendlich ist aktuell so gelöst, in der Testumgebung sind jetzt zwei DC - dann tuts.
Irgendwie doof wenn alles explodiert in der Produktivumgebung und nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr
Schlussendlich ist aktuell so gelöst, in der Testumgebung sind jetzt zwei DC - dann tuts.
Irgendwie doof wenn alles explodiert in der Produktivumgebung und nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr
Zitat von @NetzwerkDude:
Irgendwie doof wenn alles explodiert in der Produktivumgebung und nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr
Irgendwie doof wenn alles explodiert in der Produktivumgebung und nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr
- Wenn "alles explodiert": Dafür plant und übt man ein Desaster Recovery
- "nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr" - Wenn man es "richtig" macht, dann geht das ohne Probleme. Aber auch dafür sollte man sich einen Plan zurechtlegen.
Zitat von @NetzwerkDude:
Danke für die Ausführungen.
Schlussendlich ist aktuell so gelöst, in der Testumgebung sind jetzt zwei DC - dann tuts.
Danke für die Ausführungen.
Schlussendlich ist aktuell so gelöst, in der Testumgebung sind jetzt zwei DC - dann tuts.
Dann solltest Du mal genauer schauen, was da die Abhängigkeiten sind. Ein DC muß auch alleine "hochkommen" ohne die Hilfe von einem Fluffer.
Oft sind es einfach die Netzwerkeinstellungen, weil bei einem Hyper-Visor-Host- oder Netzwerk-Wechsel Windows gerne mal alles "verstellt".
Irgendwie doof wenn alles explodiert in der Produktivumgebung und nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr
Dann solltest Du nochmal "Desaster-Recovery" üben, bis Du raus hast, woran es liegt. Nicht umsonst predige ich meinen Kunden, daß die sowas mal üben und durchspielen müssen (oder ich das bei ihnen mal mache).
lks
1
Also es ist noch weiteres ungemacht über mich gestürzt - daher muss ich dieses Thema leider erstmal sein lassen.
Danke an alle für die Ideen und Anregungen.
Disaster Recovery Übung kommt bei dem Laden dann auch auf die ToDo
Danke an alle für die Ideen und Anregungen.
Disaster Recovery Übung kommt bei dem Laden dann auch auf die ToDo
