Hallo zusammen,
wir planen aktuell folgendes Projekt, zu dem ich 1-2-3 Fragen hätte:
Wir möchten an einem Zweigwerk in AT einen eigenen Exchange aufsetzen - die laufen aktuell über DE mit.
Wir haben in unserem AD zwei Standorte: DE und AT.
Am Standort DE haben wir eine Exchange DAG mit zwei Exchange 2016. Diese halten insgesamt 4 Datenbanken - pro Server zwei aktiv.
Die Mailserver in DE nehmen sowohl die TLDs .de als auch .at an. Das soll auch der neue Exchange in AT machen.
Der Standort AT ist per Site2Site VPN mit DE verbunden. Dazu setzen wir an beiden Standorten eine Sophos UTM ein.
Wir möchten dort in AT nun einen dritten Exchange installieren, der aber nicht Teil der DAG ist. Wir möchten dann die Postfächer der AT Mitarbeiter von der DAG raus in die Postfach DB des Servers in AT migrieren.
Abschließend wollen wir die MX Einträge über Kreuz legen - Fällt AT aus, gehen die Mails für AT nach DE. Fällt DE aus, gehen die Mails für DE nach AT.
Leitet der Exchange in AT trotzdem die Mails über die Warteschlangen an die deutschen Exchange weiter, sobald dieser wieder online sind, auch wenn er nicht Teil der DAG ist?
Leiten umgekehrt die DAG Member die Mails an den Exchange in AT weiter, sobald dieser wieder Online ist?
Dazu noch folgendes:
Erkennen die Clients anhand des Standortes den richtigen Exchange?
Wie müssten wir da das Autodiscover konfigurieren? Stellt sich das selber?
Spielen die Exchange untereinander CAS Proxy bzw. leiten zum richtigen Exchange um?
Hoffe ich hab mich nicht zu kompliziert ausgedrückt...
Grüße
Andreas
Ich lese mal mit.
Hallo Andreas,
grundsätzlich ist es kein Problem einen weiteren Exchange Server am Standort AT zu installieren, welcher nicht Mitglied der DAG ist. Für den AT Exchange Server muss es mindestens einen Domain Controller am Standort AT geben. Die Postfächer der AT Benutzer kannst du nach Konfiguration des Exchange Servers in die Datenbank des AT Exchange Servers verschieben. Bezüglich der MX-Einträge, hier macht es sogar Sinn die "MX Einträge über Kreuz" zu legen. Denkbar wäre beispielsweise folgende MX Konfig (als Beispiel):
- domain.DE -> MX -> Prio 10 -> exchange.domain.DE
- domain.DE -> MX -> Prio 20 -> exchange.domain.AT
- domain.AT -> MX -> Prio 10 -> exchange.domain.AT
- domain.AT -> MX -> Prio 20 -> exchange.domain.DE
Um das Mailrouting zwischen den Standorten kümmert sich Exchange. Fällt nun ein Standort aus, bleiben die Mails in der Warteschlange (Dauer konfiguriertbar) und werden später zugestellt.
Sofern der Zugriffpunkt für die Benutzer gleich bleiben soll, also alle Benutzer den gleichen DNS Namen für den Zugriff verwenden sollen, dann funktioniert dies im Prinzip schon Out-of-the-Box. Wichtig ist dann die Zuordnung der jeweiligen Subnetze zu den AD-Standorten.
Sollte ein Client am nicht "am richtigen Exchange Server" aufschlagen, ist dies nicht weiter schlimm, innerhalb der Exchange Organisation spielt es keine Rolle welcher Client welchen Exchange Server anspricht. Der CAS Proxy sucht dann eben den Exchange Server mit der aktiven Datenbank und stellt die Verbindung her. Dieses Verhalten lässt sich natürlich mittels DNS oder Loadbalancer etwas tunen, indem zunächst immer erst der Exchange Server aufgelöst oder angesprochen wird, welcher am Standort des Benutzers existiert.
Gruß,
Frank
Guten Morgen,
Danke für deine sehr ausführliche Antwort!
am Standort AT haben wir einen DC, die Subnetze sind auch sauber gepflegt in den Standorten.
Genau so wie du geschrieben hast, wollten wir die Einträge über Kreuz legen.
Die Frage des Zugrifsspunktes ist interessant. Wäre es sinnig diesen vielleicht nicht nur outlook.domain.de sondern outlookAT.domain.de zu nennen?
Auf der anderen Seite wäre es bestimmt auch nicht schlecht den selben DNS Namen zu verwenden, falls einer ausfallen sollte.
Eine Frage zur DNS Auflösung:
Wir setzen ganz normal den Microsoft DNS Server auf dem Domaincontroller ein. Da kenn ich mich nicht so gut aus - kann man dem beibringen, er soll als erstes die IP des Exchange am Standort vor Ort auflösen? Bewusst bin ich über so ein Feature noch nicht gestolpert beim Microsoft DNS.
Gruß
Andreas
EDIT: Im DNS ist das die Netzwerkmaskenanforderung. Haben wir aktiviert.
So macht unser DNS weiter Round Robin, präsentiert in AT aber immer die IP die am nächsten erreichbar ist!
Hallo Herby,
du könntest auch DNS-Richtlinien verwenden um die Auflösung zu steuern:
https://docs.microsoft.com/de-de/windows-server/networking/dns/deploy/primary-geo-location
Ich würde es über einen Zugriffspunkt / URL laufen lassen. Es könnte ja ein weiterer Standort hinzukommen, so müsste dann nicht wieder alles umkonfiguriert werden. Dies ist aber Geschmackssache. Ich denke hinsichtlich der Ausfallsicherheit, hat dies kaum Relevanz, wenn Standort AT ausfällt, hilft ja auch kein weiterer Zugriffspunkt, die Datenbank wäre ja nicht erreichbar. Am Standort DE ist ja bereits eine DAG.
Gruß,
Frank
Ich denke wir werden mit einem Zugriffspunkt laufen lassen. Outlook.domain.de - dann muss nicht alles geändert werden.
Aus DNS Sicht werden wir einfach nur die Netzwerkmaskenanforderung benutzen, das sollte ja schon genügen.
Ich werde hier immer mal Updates zum Fortschritt posten.
Wir befinden uns mitten in der Umsetzung und sind heute bei der Installation auf ein Problem gestoßen was ich mir nicht erklären kann.
Wir haben den Exchange normal durchinstalliert und dann die Internal und External URLs für owa und ecp angepasst. Identisch in AT wie bereits in DE vorhanden.
Also outlook.domain.de und mail.domain.de
Anschließend durchgestartet und versucht direkt auf dem AT Exchange das ECP zu öffnen über:
https://Servername.domain.at/ecp
Erwartungsgemäß kam auch die Anmeldeseite. Nach erfolgreicher Anmeldung werde ich allerdings umgeleitet auf mail.domain.de/ecp
Ich hab daraufhin festgestellt das ich vergessen hab den DNS Eintrag outlook für den AT Exchange hinzuzufügen. Sofort erledigt - allerdings keine Besserung.
Wenn ich jetzt noch hergehe und in DE in der Management Shell folgenden Befehl absetze, bleibt der hängen beim Versuch in AT an die Verzeichnisse zu kommen - umgekehrt von AT aus, bleibts bei den deutschen Exchange hängen.
get-ecpVirtualDirectory | fl
Der erste Exchange in DE wird ausgegeben, einige Sekunden später der zweite. Beim Versuch die Daten von AT abzuholen, bleibt der Befehl locker 10 Minuten hängen. Dann kommen die Daten allerdings. Das selbe von AT aus. Hier dauert es 10 Minuten bis die deutschen Daten erscheinen und die AT kommen nach Sekunden. Das kann doch nicht so lange dauern oder?
Irgendwo muss doch hier ein Problem sein, oder nicht?
EDIT: Ich habe den Server noch nicht lizensiert - den Exchange Product Key kriege ich erst morgen. Kann das eventuell daran liegen?
Nächstes Update:
Fehler gefunden warum die Abfrage der virtuellen Verzeichnisse so lange dauert, leider aber nicht behoben:
Dann aber die eigentliche Frage:
Wenn ich auf dem Server direkt das ECP öffnen will über: servername.doamin.de, warum werde ich nach der Anmeldung umgeleitet auf mail.domain.de statt servername.domain.de ? Hier am Standort DE funktioniert das wunderbar. Da bleibe ich auch nach der Anmeldung auf servername.domain.de
Das ist mir nicht verständlich das Verhalten...