Tim312 0 Geschrieben 10. April Melden Teilen Geschrieben 10. April Wir haben einen zentralen Standort mit DCs und zentralem Exchange, der seit Monaten produktiv ist. Ein 2. Standort sollte später per Site to Site VPN dazu kommen mit eigenem lokalen DC, File, Print Server etc. Diese Server des 2. Standortes sind in einem S2D Hyper V Cluster zusammengefasst. Da dafür auch eine Abnahme des Herstellers notwendig war, wurde im vorauseilenden Gehorsam dieser Cluster inkl. DC etc. schon am 1. Standort vor Ort betriebsfähig gemacht und in die Domäne gebracht. Danach wurde das Cluster an den neuen Standort geliefert und verbaut. Leider hat sich darauffolgend die Baustelle durch externe Verzögerungen massiv in die Länge gezogen. Die DCs und der Cluster vom 2. Standort sind nun also seit Monaten aus und ohne Connect zur Domäne. Ich fürchte wir dürfen die gar nicht mehr Online nehmen, Stichwort Tombstone? Muss dann auch das Cluster neu gemacht werden, welches ja ebenfalls AD gebunden ist? Zitieren Link zu diesem Kommentar
Nobbyaushb 1.372 Geschrieben 10. April Melden Teilen Geschrieben 10. April Den Cluster musst du m.E. nicht neu machen, cached credentials (habe 120Tage im Gedächtnis…) Anders bei den DC, die dürften nach 90 Tagen über die TS Zeit sein Aber alles ohne nachschauen, das weiß bestimmt jemand besser als ich… Zitieren Link zu diesem Kommentar
NilsK 2.795 Geschrieben 10. April Melden Teilen Geschrieben 10. April Moin, gut, dass du fragst. Den DC auf dem "entfernten" Cluster erst mal nicht in Betrieb nehmen. Den Cluster selbst würde ich erst dann einschalten, wenn am 2. Standort Netzwerkkontakt zum Zentralstandort besteht und das Routing auch funktioniert. Dann sollten die Anmeldevorgänge funktionieren. Wie lang die Tombstone Lifetime in eurer Domäne ist, musst du nachsehen, das können 60 oder 180 Tage sein (oder ein ganz anderer Wert, aber das wäre unwahrscheinlich). Nachsehen kannst du mit diesem PS-Kommando: (get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=<domain>,DC=<tld>" -properties "tombstonelifetime").tombstonelifetime Den Domänennamen musst du natürlich anpassen. Falls der betreffende DC schon länger aus ist als die Tombstone Lifetime in Tagen, schaltest du ihn nicht an, sondern löschst die VM sowie das Computerobjekt in Active Directory. Dann richtest du einen neuen DC ein. Das ist in dem Fall am einfachsten. Gruß, Nils Zitieren Link zu diesem Kommentar
Nobbyaushb 1.372 Geschrieben 10. April Melden Teilen Geschrieben 10. April Danke Nils, hab das unterwegs auf dem Phone getippt... Zitieren Link zu diesem Kommentar
cj_berlin 1.165 Geschrieben 10. April Melden Teilen Geschrieben 10. April VM und Computer-Objekt reicht nicht, Du musst einen Metadata Cleanup durchführen. Zitieren Link zu diesem Kommentar
NilsK 2.795 Geschrieben 11. April Melden Teilen Geschrieben 11. April Moin, Der geschieht zu großen Teilen automatisch. Aber ja, die Reste muss man noch selbst entsorgen. Also +1. Gruß, Nils 1 Zitieren Link zu diesem Kommentar
Tim312 0 Geschrieben 11. April Autor Melden Teilen Geschrieben 11. April vor 17 Stunden schrieb NilsK: Den DC auf dem "entfernten" Cluster erst mal nicht in Betrieb nehmen. Den Cluster selbst würde ich erst dann einschalten, wenn am 2. Standort Netzwerkkontakt zum Zentralstandort besteht und das Routing auch funktioniert. Dann sollten die Anmeldevorgänge funktionieren. Wie lang die Tombstone Lifetime in eurer Domäne ist, musst du nachsehen, das können 60 oder 180 Tage sein (oder ein ganz anderer Wert, aber das wäre unwahrscheinlich). Nachsehen kannst du mit diesem PS-Kommando: (get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=<domain>,DC=<tld>" -properties "tombstonelifetime").tombstonelifetime Danke schön Nils. Die Tombstone Laufzeit beträgt laut deiner Abfrage bei uns 180 Tage. Wenn ich das richtig verstehe, liegt aber generell das Hauptaugenmerk nur auf den DCs? Die anderen VMs (File, Print ...) und auch Cluster Nodes selber hätten kein Problem mit Überschreiten der TombStone? Es geht also nur darum, dass alle Server die AD Rollen haben, nicht in Inkonsistenzen bezüglich des AD laufen? Wenn ich mir von Sysinternals den AD Explorer nehme und mir in der laufenden AD (1. Standort) die Computerobjekte der DCs vom 2. Standort anschaue, sehe ich dort die last Logon Time. Das kann ich deuten wie bei einem Userobjekt, wann der letzte Anmeldezeitpunkt an der AD war? Der Cluster besteht aus 2 Nodes mit einem 3. Server der als Share Witness läuft und ebenfalls DC ist. Dieser DC war im Dezember noch an laut last logon Time. Eine VM im Cluster, die auch DC ist, allerdings im Oktober. Kann ich den Ablauf dann folgend verstehen?: 2. Standort per Site to Site VPN zum 1. Standort verbinden Routing testen, DNS testen Den Share Witness Server der innerhalb der TombStone geblieben ist, einschalten, synchen lassen, schauen, dass die AD synchronisiert ist, dann die Cluster Nodes starten, die VM mit dem DC der zu alt ist, aber aus lassen dessen VM in AD löschen, MetaCleanUp durchführen ggf. neue VM hochziehen und zum 2. DC an dem Standort promoten Zitieren Link zu diesem Kommentar
NilsK 2.795 Geschrieben 11. April Melden Teilen Geschrieben 11. April Moin, Einen DC zum Witness zu machen, ist ein schwerwiegender Designfehler. Das führt, ohne es weiter analysiert zu haben, dazu, dass du den Cluster so, wie er eingerichtet ist, nicht mehr in Betrieb nehmen kannst. Ohne nähere Analyse müssen wir davon ausgehen, dass alle DCs an den entfernten Standort veraltet sind und nicht mehr online gehen dürfen. Das gilt dann auch für den Witness. Für den Cluster musst du also wenigstens den Witness neu einrichten, dann nicht auf einem DC. Die Tombstone Lifetime betrifft nur DCs, keine anderen Mitglieder der Domäne. Gruß, Nils 1 Zitieren Link zu diesem Kommentar
Tim312 0 Geschrieben 11. April Autor Melden Teilen Geschrieben 11. April Hallo Nils, sorry, ich bin verwirrt. Der DC / Dateifreigabezeuge ist aus Blech für den Cluster und nicht selbst eine VM im Cluster. Dieser DC, welcher ja den Cluster selbst nicht braucht, war im Dezember noch an, also innerhalb der 180 Tage und sollte dann doch noch aktuell genug sein, dass er sich mit der AD replizieren kann. Ein Zeuge als VM des gleichen Clusters für den er Quorum ist, haben wir ja nicht vorliegen. Das verstehe ich auch, dass das designtechnisch dämlich wäre. Wir haben uns da im Übrigen auch auf den Dienstleister für den Cluster verlassen, dass er sagt, ein Dateifreigabezeuge, ist erst einmal nur eine Freigabe und kann grundsätzlich überall laufen. (Ausnahme innerhalb des Clusters selbst wie gesagt) Zitieren Link zu diesem Kommentar
Beste Lösung NilsK 2.795 Geschrieben 11. April Beste Lösung Melden Teilen Geschrieben 11. April Moin, Ein DC ist ein DC und kein Witness. Er hält also auch kein Share. Punkt. Die Abhängigkeit mag gering und leicht aufzulösen sein, aber sie ist ja vorhanden. Schöne Grüße an den Dienstleister, aber auch so ein Share läuft auf einem DC nicht mal eben mit. Welcher eurer DCs jetzt wie lange aus ist, ist der Teil, den ich hier eben nicht einschätzen oder prüfen kann. Vielleicht muss man die Maschinen auch nicht neu machen, wenn weniger Zeit verstrichen ist. Das musst ihr dann selbst prüfen und entscheiden. Ist von der prinzipiellen Seite noch was unklar? Gruß, Nils 1 1 Zitieren Link zu diesem Kommentar
Tim312 0 Geschrieben 11. April Autor Melden Teilen Geschrieben 11. April vor einer Stunde schrieb NilsK: Ist von der prinzipiellen Seite noch was unklar? Nein, vielen Dank. Das hilft uns sehr weiter. Zitieren Link zu diesem Kommentar
NilsK 2.795 Geschrieben 11. April Melden Teilen Geschrieben 11. April Moin, Prima, danke für die Rückmeldung. Dann viel Erfolg. 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.