13.09.2019, aktualisiert um 10:46:19 Uhr

2140

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.ä.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 494561

Url: https://administrator.de/forum/domaincontroller-zum-testen-clonen-494561.html

Ausgedruckt am: 25.12.2024 um 02:12 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

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.

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?

moin...

Zitat von @NetzwerkDude:

Hi,

also der Server hat natürlich eine feste IP.

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?

ja....

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?

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

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

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?

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

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

)

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.

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."  

Zitat von @NetzwerkDude:
EventID 1311 (Error):

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

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..

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?
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.
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

Zitat von @NetzwerkDude:
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.

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

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

Frage Microsoft Windows Server

Mehr von NetzwerkDude

TLStorm 2 Sicherheitslücken auf SwitchenNetzwerkDude

MS: AD-Tier Modell ist nun Enterprise-Access-ModellNetzwerkDude

Zabbix Schwachstelle wird aktiv ausgenutztNetzwerkDude - 6 Kommentare

Fehlgeschlagene RDP Anmeldungen bei einem DC loggenNetzwerkDude - 30 Kommentare

Heiß diskutiert