Domaincontroller zum Testen clonen

netzwerkdude
Goto Top
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.ä.

Content-Key: 494561

Url: https://administrator.de/contentid/494561

Ausgedruckt am: 10.08.2022 um 16:08 Uhr

Mitglied: Lochkartenstanzer
Lochkartenstanzer 13.09.2019, aktualisiert am 16.09.2019 um 08:28:11 Uhr
Goto Top
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
Mitglied: LKD1981
LKD1981 13.09.2019 um 10:57:17 Uhr
Goto Top
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
Mitglied: aqui
aqui 13.09.2019 um 11:00:03 Uhr
Goto Top
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.
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 11:03:18 Uhr
Goto Top
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?
Mitglied: Vision2015
Vision2015 13.09.2019 um 11:25:23 Uhr
Goto Top
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
Mitglied: aqui
aqui 13.09.2019 aktualisiert um 11:27:36 Uhr
Goto Top
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.
Mitglied: emeriks
emeriks 13.09.2019 um 11:35:51 Uhr
Goto Top
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?
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 11:36:33 Uhr
Goto Top
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
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 11:38:21 Uhr
Goto Top
Ja, er ist sein eigener DNS Server
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 11:39:04 Uhr
Goto Top
Okay, ich trag da mal den Client ein....
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 12:00:29 Uhr
Goto Top
Das brachte keine besserung
Mitglied: 140913
140913 13.09.2019 aktualisiert um 12:44:01 Uhr
Goto Top
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.
Mitglied: Vision2015
Vision2015 13.09.2019 um 12:43:37 Uhr
Goto Top
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
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 13:11:47 Uhr
Goto Top
Grad andere Arbeit reingekommen - ich melde mich wenn ich da weitermache, ggf. am Montag
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 aktualisiert um 15:40:19 Uhr
Goto Top
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?
Mitglied: 140913
140913 13.09.2019 aktualisiert um 15:42:23 Uhr
Goto Top
Hast du meinen Kommentar zum Thema überlesen?
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 15:43:39 Uhr
Goto Top
Ich hab ihn gelesen, aktuell bootet die kiste noch - irgendwas stimmt da nicht
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 15:49:33 Uhr
Goto Top
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
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 15:55:58 Uhr
Goto Top
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 face-smile )
Mitglied: emeriks
emeriks 13.09.2019 aktualisiert um 16:04:25 Uhr
Goto Top
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.
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 16:05:33 Uhr
Goto Top
Okay, das ist ein interessanter Tipp... ich hol mir ein Bier
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 16:10:04 Uhr
Goto Top
EventID 1311 (Error):
Mitglied: emeriks
emeriks 13.09.2019 um 16:14:13 Uhr
Goto Top
Zitat von @NetzwerkDude:
EventID 1311 (Error):
Er wird noch mehr solch Zeug loggen. Ist doch logisch! Er ist jetzt isoliert.
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 16:44:35 Uhr
Goto Top
Scheint mir mehr so ein henne-ei thema zu sein: Er startet den Dienst nicht weil er allein ist
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 aktualisiert um 17:26:19 Uhr
Goto Top
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
Mitglied: 140913
140913 13.09.2019 aktualisiert um 18:09:31 Uhr
Goto Top
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.
Mitglied: NetzwerkDude
NetzwerkDude 13.09.2019 um 19:19:01 Uhr
Goto Top
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
Mitglied: Vision2015
Vision2015 13.09.2019 um 19:52:05 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 15.09.2019 um 16:15:41 Uhr
Goto Top
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.
Mitglied: NetzwerkDude
NetzwerkDude 15.09.2019 um 16:35:35 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 16.09.2019 aktualisiert um 08:07:26 Uhr
Goto Top
Zitat von @NetzwerkDude:
Irgendwie doof wenn alles explodiert in der Produktivumgebung und nur ein DC übrigbleibt - dann hilft der ja auch nicht mehr
  1. Wenn "alles explodiert": Dafür plant und übt man ein Desaster Recovery
  2. "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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 16.09.2019 aktualisiert um 08:27:30 Uhr
Goto Top
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
Mitglied: NetzwerkDude
NetzwerkDude 16.09.2019 um 21:24:31 Uhr
Goto Top
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 face-smile