Tim312

Nein, vielen Dank. Das hilft uns sehr weiter.

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)

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

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?

Sofern die Erstsynchronisation dann einmal durch ist. Ich glaube es gibt keine Throttling Policy die den Cachemode direkt beeinflussen könnte, um Engpässen vorzubeugen?! RDS ist natürlich auch generell eine feine Sache. Da herrscht bei uns aber Sorge bezüglich der Planungssicherheit seitens Microsoft und Office in RDS Umgebungen. Da war doch einiges im Busch, dass man nicht weiß, wie die zukünftige Unterstützung dort von Microsoft aussieht.

Vielen Dank für euren Input, Mit einem zentralen Exchange haben wir etwas Sorge über die Belastung der Site 2 Site. (ca. 30 Postfächer vom 2. Standort und nur 50 mbit SDSL) Aber wir geben das intern bezüglich eines weiteren Dienstleisters zur Unterstützung auf jeden Fall weiter. Beste Grüße

Guten Morgen Norbert, Unabhängig der Frage über das Konstrukt als solches, scheinen wir aber doch trotzdem etwas zu übersehen?! Es wäre ja denkbar, dass an einem Standort aufgrund der Menge der Daten einfach zwei Exchange Server nebeneinander stehen. Wenn einer davon aus Wartungsgründen oder wegen einer Störung off ist, wie verhindert man, dass die Funktion des noch aktiven Exchange nicht beeinträchtigt wird? Dazu habe ich leider nichts gefunden.

Hallo Forum, wir haben hier seit längerem in einer klassischen Windows Domäne (firma.local) lokal einen Exchange 2019 laufen. Die Clients sind Outlook und ebenfalls vor Ort. Und es gibt auch keine Probleme in dem Sinne. Nun wird die Firma in naher Zukunft einen 2. Standort aufmachen. Beide Standorte sollen dann per Site to Site VPN miteinander verbunden werden und in der gemeinsamen Domäne firma.local verwaltet werden. Beide Standorte haben dann je einen Exchange und einen eigenen DC mit DNS vor Ort. E-Mails werden per Pop3 pro Standort abgerufen und dann an den jeweiligen Exchange weitergeleitet. Die neuen Server für den neuen Standort sind nun schon da und sollten vorab schon vorbereitet werden. Es wurde also der DC installiert und der Domäne hinzugefügt, sowie der 2. Exchange installiert und ebenfalls hinzugefügt und für den gemeinsamen Betrieb (Zertifikat, virt. Verzeichnisse, DBs...) konfiguriert. Das Zertifikat für die Exchange ist dabei auf autodiscover.fima.de und outlook.firma.de ausgestellt. Damit später der DNS immer nur den lokalen Exchange des Standortes zurück gibt, wenn ein Client nach "autodiscover" oder "outlook" fragt, ist auf dem jeweiligen DC im DNS je eine Pinpoint Zone (also nicht AD integriert) eingerichtet worden. Somit gibt Standort A DNS nur die IP des Standort A Exchange zurück und später Standort B DNS die IP des Standort B Exchange. Je nach DNS Einstellung im Client kommen auch die gewünschten IPs am Client zurück und wir stellen keine Probleme im täglichen Betrieb fest. Auf dem neuen Exchange ist aktuell auch noch kein Benutzerpostfach vorhanden. Nun waren die neuen Server, nachdem sie soweit vorbereitet waren, für ein paar Tage aus. Auch dabei haben wir keine Probleme im Netz festgestellt. Das änderte sich leider als wir auf dem ersten Exchange ein Freigabepostfach eingerichtet haben und den Vollzugriff einem Mitarbeiter zuweisen wollten. Das Senden als Recht lässt sich noch zuweisen. Aber bei der Zuweisung des Vollzugriffes, ob über GUI oder Shell, quittiert der Exchange mit der Meldung "Kommunikationsfehler bei Aufruf von Serverlocatordienst". Fährt man das Serverpärchen vom neuen Standort wieder hoch, ist die Zuweisung direkt möglich. Also sprechen die Exchange doch noch wo miteinander, obwohl das Postfach gar nicht auf dem neuen Exchange gehostet ist und DNS scheinbar immer den "richtigen" Exchange zurückgibt. Wir haben dazu jetzt leider so nichts finden können und wissen nicht in welcher Richtung wir schauen sollten. Was übersehen wir hier?