magicpeter 11 Geschrieben 18. September 2019 Melden Teilen Geschrieben 18. September 2019 Moin, also jetzt seit nicht so streng mit mir. Ich habe ein wenig sc***s einen 2ten DC wieder einzuschalten. Ihr fragt euch bestimmt jetzt wieso? Also dann hole ich mal etwas aus. Ein VMware Netzwerk mit 3 VM sollte nach Hyper-V konvertiert werden. 1. Exchange 2016 Server mit Disk2VHD konvertiert alten VMWare Server ausgeschaltet und neuen Hyper-V Server gestartet, alles läuft 2. RDP Server mit Disk2VHD konvertiert alten VMWare Server ausgeschaltet und neuen Hyper-V Server gestartet, alles läuft 3. Einen neuen 2ten DC auf dem Hyper-V eingerichtet und mit dem ersten DC repliziert, alles läuft 4. Alle Server ausgeschaltet und den 1ten DC mit Disk2VHD konvertiert alten VMWare Server ausgeschaltet und neuen Hyper-V Server gestartet, alles läuft (Ihr fragt euch jetzt warum hat er denn den alten DC noch konvertiert. Da soviele Daten und Freigaben darauf eingerichtet waren und ich das nicht zeitlich geschafft hätte Der Kunde will ja morgen wieder arbeiten und zwar auf dem neuen Hyper-V. Was auch jetzt funktioniert.) 5. Den Exchange und den RDP Server auf dem Hyper-V wieder gestartet, alles läuft und auch noch viel schneller auf dem neuen Hyper-V Jetzt geht mir etwas der Stift, da ich bevor ich mit der DC Konvertierung gestartet bin so viel über den USN Rollback gelesen habe. Kann ich ohne Probleme den 2ten DC den ich ja vorher frisch erstellt habe als der 1. DC noch auf dem VMWare Host lief. Aber eigentlich sollte das doch kein Problem sein. Der 1. DC ist eine Offline Kopie der VM vom VMware Host. Der 2. DC sollte sich jetzt mit dem 1. DC wieder replizieren oder? Wie schon gesagt seit nicht so streng mit mir. Das mit dem USN Rollback habe ich noch nicht so ganz verstanden. Ich weiss, wenn ich den alten 1. DC auf dem VMware Host wieder einschalten würde hätte ich den USN Rollback zu 100%, aber das wollen wir ja gar nicht. Ich habe den 2. DC jetzt erst einmal ausgelassen. Wer weis ob man ihn wieder einschalten darf ohne das ein USN Rollback stattfindet. Aber eigentlich war der 2. DC ja nur aus und vor der Konvertierung des 1. DC hat der ja gar nichts mitbekommen, da ich ihn ja vorher ausgeschaltet habe. Zitieren Link zu diesem Kommentar
magicpeter 11 Geschrieben 19. September 2019 Autor Melden Teilen Geschrieben 19. September 2019 Hat denn keiner eine Idee? Jetzt bringt mir der virtuellisierte 1. DC auch noch eine Fehlermeldung. ID: 2092 Dieser Server ist Besitzer der FSMO Rolle, die jedoch nicht als gültig eingestuft wird. Für die Partien, die das FSMO enthält wurde dieser Server seit dem letzen Neustart nicht erfolgreich mit einem beliebigen Partner repliziert. Das Heist doch nichts anderes als das er Replizieren will und er den 2. DC haben will. Oder?? Zitieren Link zu diesem Kommentar
magicpeter 11 Geschrieben 19. September 2019 Autor Melden Teilen Geschrieben 19. September 2019 OK, ich habe den 2. DC wieder gestartet und alle Probleme sind verschwunden. Was ich jetzt noch nicht so ganz verstanden habe ist: Eigentlich sollte ein zusätzlicher Domaincontroller mehr Sicherheit und Zuverlässigkeit bringen oder? Es scheint jetzt aber so als wenn ein 2. DC mehr Probleme macht als nur ein Einzelner DC. Da, wenn der 2. DC ausfällt und auch der 1. DC Neugestartet werden muss, es dann zu Problemen kommt. OK, man sollte halt dann nicht bei einem Ausfall des 2. DC den anderen DC neu starten. OK, war jetzt in meiner Umgebung notwendig, aber in einer Produktiven Umgebung wahrscheinlich nicht so oft. Oder sehe ich as falsch? Zitieren Link zu diesem Kommentar
Gu4rdi4n 58 Geschrieben 19. September 2019 Melden Teilen Geschrieben 19. September 2019 Das ist nicht normal. Wenn ein DC wegfällt, dann nehmen die Clients den anderen. Wenn er dann wieder erreichbar ist, wird er ganz normal wieder von den clients benutzt, nachdem die "Sperrzeit" vorbei ist. Ich hatte noch keine Probleme mit meinen 2 DCs dahingehend. Zitieren Link zu diesem Kommentar
magicpeter 11 Geschrieben 19. September 2019 Autor Melden Teilen Geschrieben 19. September 2019 vor 16 Minuten schrieb Gu4rdi4n: Das ist nicht normal. Wenn ein DC wegfällt, dann nehmen die Clients den anderen. Wenn er dann wieder erreichbar ist, wird er ganz normal wieder von den clients benutzt, nachdem die "Sperrzeit" vorbei ist. Ich hatte noch keine Probleme mit meinen 2 DCs dahingehend. JA, danke dir.. OK war auch eine etwas ungewöhnliche Situation.... Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 19. September 2019 Melden Teilen Geschrieben 19. September 2019 vor 26 Minuten schrieb magicpeter: Es scheint jetzt aber so als wenn ein 2. DC mehr Probleme macht als nur ein Einzelner DC. Wenn alles richtig ist, macht der keine Probleme. Bei dir tritt das Problem doch erst auf mit dem Abschalten des 2.DC, oder? Dann liegt das Problem doch wohl im Zusammenhang mit dem 1.DC, oder? Es muss funktionieren mit nur dem 1.Dc, es muss funktionieren mit nur dem 2.DC, es muss funktionieren mit beiden DC. Man schaue in die Ereignisanzeigen! Man prüfe mit DCDIAG! Mein Hauptverdächtiger ist die Namensauflösung per DNS. vor 3 Minuten schrieb magicpeter: OK war auch eine etwas ungewöhnliche Situation.... Nein, esn war ein klares Versagen, sehr wahrscheinlich aufgrund fehlerhaufter konfiguration. Zitieren Link zu diesem Kommentar
Marco31 33 Geschrieben 19. September 2019 Melden Teilen Geschrieben 19. September 2019 Hattest du eventuell vergessen die FSMO-Rollen auf den neuen DC zu übertragen? Zitieren Link zu diesem Kommentar
Beste Lösung NilsK 2.930 Geschrieben 19. September 2019 Beste Lösung Melden Teilen Geschrieben 19. September 2019 Moin, es liegt doch überhaupt kein Problem vor. Und das Verhalten ist völlig normal und so, wie es sein soll. Der "1. DC" ist FSMO-Rolleninhaber. Und er weiß, dass es noch einen zweiten DC gibt. Natürlich versucht er beim Neustart, diesen zweiten DC zu erreichen - er weiß ja nicht, wie lange er offline war. Antwortet der andere DC nicht, dann gibt der "1. DC" eine Warnung aus - nota bene, die 2092 ist eine Warnung, kein Fehler. Diese Warnung besagt, dass kein Kontakt zu den Replikationspartnern besteht, sodass der DC nicht prüfen kann, ob ihm vielleicht Daten fehlen. Abhilfe ist im Normalfall einfach: Den Kontakt zu dem anderen DC herstellen - hier, indem man ihn startet. Es könnte ja aber auch sein, dass die Netzwerkverbindung fehlt, dann müsste man diese herstellen. Das kann der "1. DC" in dieser Situation nicht feststellen, daher die Warnung. Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.