Standortvernetzung - dezentrale Konzeptidee bezüglich Servern und Diensten

[Mack 10]

Liebe Community,

 

vorweg, das Thema betrifft einige Forenbereiche. 
Wenn ich hier eher falsch positioniert bin, bitte ich die Forenadmin, das Thema in einen passenderen Bereich zu verschieben.

 

Im Rahmen eines Projekts soll das folgende Szenario umgesetzt werden, und ich möchte euch fragen, 
ob es realisierbar ist, bzw. ob besondere Aspekte beachtet werden müssen, die hier in der Auflistung fehlen.

 

Es ist nicht gewünscht, externe Cloud-Lösungen wie Exchange Online zu verwenden.

Das Projekt umfasst derzeit drei Standorte, möglicherweise in Zukunft bis zu sechs.

Alle Standorte sind über ein Side-to-Side-VPN (SDSL 50mbit aufwärts) miteinander verbunden.

Separate Internetverbindungen stehen jeweils für den allgemeinen Internetzugang zur Verfügung.

 

Es existiert eine gemeinsame Windows AD-Domäne (2022) und eine einzige SMTP-Domäne.
An jedem Standort gibt es lokale Fileserver, Domänencontroller mit DNS-Funktion und Exchange Server (2019).

 

Da die SMTP-Domäne auch über die drei Standorte hinaus genutzt wird, verweisen die MX-Einträge weiterhin auf den Provider. 
E-Mails werden über Pop3 (PopCon) an den jeweiligen Standorten abgeholt und an den lokalen Exchange-Server zugestellt.
Die Mitarbeiter arbeiten auch hauptsächlich an ihren jeweiligen Standorten. Daher sollte der Großteil des Datenverkehrs ebenfalls lokal stattfinden.

Externe Zugriffe (Smartphones, Notebooks) erfolgen ausschließlich über IPSec-Einwahl-VPNs zu den jeweiligen Standorten.

 

Die externe Autodiscover-Funktion befragt somit das externe DNS und leitet die Anfragen an den Provider weiter. 
Dort wird dann nur E-Mail angeboten, was momentan auch ausreichend ist.
Das interne DNS enthält mehrere HOST-A-Einträge für "autodiscover.contoso.local" mit den entsprechenden IP-Adressen der Exchange-Server (DNS-Round-Robin).

 

An jedem Standort wird voraussichtlich auch ein RDP-Server betrieben, um Mitarbeiter, die sich abwechselnd an Standort A und B befinden, zu unterstützen. 
Dadurch können sie sich mit dem Standort verbinden, an dem ihr Postfach gehostet ist, um den Datenverkehr über das Standort-VPN für Outlook zu minimieren. 
Wir erwarten primär standortübergreifenden Datenverkehr bei AD- und DNS-Replikationen sowie beim internen E-Mail-Verkehr von Exchange zu Exchange.

Und natürlich auch wenn jemand mal explizit auf ein Datenlaufwerk am anderen Standort zugreift.

 

In einer früheren Überlegung gingen wir noch von einem zentralen Standort aus, an dem alle Server zusammengeführt und ausschließlich über RDP (via VPN) angeboten wären.

Aufgrund unserer Bedenken hinsichtlich der Planungssicherheit in Bezug auf Microsofts Unterstützung von Office auf Terminalservern, sowie der nötigen Vermeidung von Azure-Lösungen aus verschiedenen Gründen,

versuchen wir nun, durch das dezentrale Konzept die Datenströme zu optimieren und trotz einer einfacheren Architektur eine gemeinsame Arbeitsumgebung zu erreichen.

 

In der oben genannten aktuellen Planung kommt RDP offensichtlich auch vor, jedoch sollte dessen Bedeutung geringer gehalten werden, um im Fall einer möglichen Abkündigung durch Microsoft weniger Auswirkungen zu haben.

Im schlimmsten Fall würden die Clients dann direkt auf die Server zugreifen.

 

Ich wäre dankbar für eine Einschätzung und konstruktives Feedback.

 

Beste Grüße

 

Dirk

[testperson 1.680]

Hi,

 

ich würde - egal wie das nachher ausgehen soll - auf alle Fälle keinen Pop Connector einsetzen. Warum nicht an zentraler Stelle ein (ggfs. redundantes) Mailgateway betreiben, welches die Mails verteilt und von den Exchange Servern dann ggfs. auch als SmartHost genutzt wird? Ebenfalls könnte man zentral einen Autodiscover Service betreiben, der dann in die entsprechenden Standorte routet.

 

In meinen Augen würdet Ihr ne ganze Menge Komplexität aus der Nummer bekommen, wenn Ihr die frühere Überegung wieder aufgreift und den "zentralen Standort" noch mal neu bewertet.

 

Was sind denn "externe Cloud Lösungen" und warum scheiden diese kategorisch aus?

 

Generell: Das ist alles ein wenig viel für ein Forum. Ihr solltet euch für das Projekt passende Beratung einkaufen und dort vom Know-How profitieren.

 

Gruß

Jan

[NorbertFe 2.045]

Ich stimme Jan da komplett zu. Sowohl was eure "schräge" Mailkonfiguration anbetrifft inklusive POPCon und Shared SMTP Space beim Provider als auch die konzeptionelle Ausrichtung deiner Frage. Da würde ich dazu tendieren externe Beratung einzukaufen. Für Detailfragen kann man sicher auch mal aus Forum zurückkommen, aber doch nicht bei so einer globalen Aktion. ;)

[teletubbieland 168]

Bin da bei Jan.

 

Habe so eine Installation mit 2 Standorten, bei dem Alles auf dem Hauptstandort läuft (Echange, RDS, Mailgateway...)

Der Zweite Standort ist via side-to-side VPN angebunden.

Die Leute haben sich daran gewöhnt und die Latenzen sind verschmerzbar.

 

Office 365 gibt es auch für RDS. Wenn MS das auch noch einstellt und dann Exchange nur noch Online geht und alle Clients virtuelle Maschinen in  Azure sind, gehe ich in Rente

 

[cj_berlin 1.323]

Moin,

 

1. Es heißt "siTe-to-siTe" VPN  

 

2, Eine RDP-Sitzung, in der Outlook läuft, verbraucht mehr Bandbreite und ist um Welten empfindlicher gegenüber Latenz als eine Outlook-Sitzung oder - erst recht - eine Exchange Backend-Proxy-Sitzung zwischen den gleichen Standorten. Daher ist Exchange meiner Meinung nach Deine geringste Sorge bei diesem Netzwerkkonzept. Wenn neben Exchange noch andere Sachen, wie Dateizugriffe auf standortspezifische Fileserver, zu berücksichtigen sind, kann RDP weiterhin Sinn ergeben.

 

3. Wenn Du der Kryptographie generell vertraust (und das musst Du ja, denn sonst dürfte VPN ja auch nicht zum Einsatz kommen  ) spricht Null dagegen, den Outlook-Zugriff auf Exchange - was ja alles HTTPS mit TLS 1.2 ist - übers Internet zu fahren. Du könntest die äußeren Firewalls ja so konfigurieren, dass sie nur Verbindungen von den jeweils anderen Standorten zulassen. Exchange-interner Traffic würde weiterhin über die Standortvernetzung laufen.

 

4. Zu der PopCon-Geschichte wurde schon fast allles gesagt. Es ist im übrigen auch so, dass, wenn Du SafetyNet nicht bewusst und absichtlich totgetreten hast, Deine Mails DENNOCH in einen anderen Standort zugestellt werden als wo der PopCon sie abholt. Dein Exchange-Design wäre bis inkl. Exchange 2007 mehr oder weniger vertretbar, mit 2010 wackelt es schon ganz deutlich und ab 2013 widerspricht es eigentlich allem, was Microsoft für Exchange vorgesehen hat.

 

5. Der Support von Office auf Terminalservern ist bis Oktober 2026 gesichert. Und wenn es dabei immer nur um einige wenige "Springer" geht, dann kann man dafür auch ein paar Windows 11-VMs hinstellen, da wird Office noch länger supportet.

bearbeitet 18. Juli 2023 von cj_berlin

[Squire 262]

Von wieviel Usern pro Standort reden wir?

 

Die PopCon Geschichte würde ich, wie die Kollegen schon sagten in die Tonne treten!

Ein Exchange oder wenn Redundanz gewünscht ist zwei in einer DAG reichen - wir haben hier die Postfächer mehrere europäische Standorte und die Niederlassung in Canada zentral auf unserer DAG am Hauptstandort. Mit Cache Modus vom Outlook normalerweise kein Problem. Die Standortverbindungen sind normale VPNs ...

Wenn Exchange DAG, dann bitte mit Loadbalancer (gibt es kostenpflichtig von Kemp, Citrix, ... oder OpenSource HAProxy z.B.). Den Exchange würde ich nicht direkt ins Internet stellen - veröffentlicht über eine WAF ... Je nach Firewall (Sophos z.B.) nimmt diese als Mailproxy die Mails an und leitet dann nach innen an den Exchange. Wenn die Firewall keinen Mailproxy bietet, könnte man ein anderes Produkt hier einsetzen (Proxmox Mailgateway, MailCleaner, ...)

 

zu den anderen Dienste lässt sich im Moment nix sagen, weil wir nicht wissen wieviele Benutzer in den Standorten sind, und welche Dienste sonst noch verwendet werden (applications, DBs, ...)

[NorbertFe 2.045]

vor 6 Minuten schrieb Squire:

Je nach Firewall (Sophos z.B.) nimmt diese als Mailproxy die Mails an und leitet dann nach innen an den Exchange

Der Mailteil ist technisch gesehen "unkritischer", denn da kommt sowieso Exchange mit seinen "Rudimenten" an Spamfilterfunktionen nicht mit halbwegs vernünftigen Produkten mit. Diese eierlegenden Wollmilchsäue von Firewallherstellern haben aber auch ihre Nachteile, wenn da zuviele Funktionen (Firewall, Spamfilter, WLAN Controller usw.) dran/drauf hängen. Mal davon abgesehen, dass die erwähnte Sophos mit ihrem Spamfilter eher im Mittelfeld spielt (aus meiner Sicht), und würde da eher zu entsprechenden Alternativen die eben _nur_ Mailfilterung bieten, aber das dann vermutlich in Summe besser.

 

Aber warten wir mal, was der TO noch zu sagen hat. :)

[Mack 10]

Sorry, wenn das Thema zu groß und unspezifisch für ein Forum ist. 

 

Ich habe wohl, im Nachhinein betrachtet, auch eine nicht unerhebliche Info weggelassen, die Eure Antworten ggf. durchaus beeinflusst haben könnte.

 

Das Konstrukt ist nämlich am Ende das Ergebnis einer Migration aus aktuell drei Standorten mit zwei eigenen lokalen Domänen und einer lokalen Arbeitsgruppe.

Da die alte IT aber so hannebüchen aufgesetzt wurde, ist eine klassische Migration zumindest einer der alten Domänen nicht erwogen worden. 

Die neue Architektur sollte also bei Null beginnen und dann die Inhalte nach und nach aus den alten Strukturen übernehmen.
Da es unter Anderem diverse Individuallösungen gibt, besteht die Migration aus sehr viel Handarbeit und wird daher wohl über längere Zeit gehen.

Deswegen sehe ich auch nicht wie man zumindest anfänglich mit MX Umstellung arbeiten kann, ohne den Mailfluß der anderen Stellen (inkl. lokaler Outlookse) zu verhindern. 
Perspektivisch gebe ich euch aber Recht, ist eine wie auch immer dann gestaltete direkte Mailzustellung prinzipiell besser.

 

Es gibt bestimmt auch viele gute Gründe alles zentral zu organisieren. Gleichzeitig wird dann allerdings auch der Anspruch an Ausfallsicherheit immer höher.
Der zu betreibende Aufwand dabei steigt schnell bezüglich Kosten, Aufwand und auch notwendigem Know How, was ggf. zu weiteren Kosten wieder eingekauft werden muss.

Daher präferiert man prinzipiell den dezentralen Ansatz, da dann einzelne Standorte trotz Ausfalles eines anderen in großen Teilen weiter arbeitsfähig sind.

 

Und schließlich spielt, zumindest für uns, auch eine Rolle, wo kommt man her (IT technisch) und wo will man hin, was braucht man und wieviel kann man investieren und leisten.
Längst nicht jedes Szenario ist dabei das best Mögliche, sondern im Zweifel werden Kompromisse gemacht werden (müssen).

 

Ich möchte hier dann aber auch eure Zeit nicht überstrapazieren mit einem für das Forum zu hoch aufgehängtem Thema.

Ihr habt ja schon Denkanstöße gegeben und erwähnt, was euch stört, dass es technisch aber prinzipiell wohl im großen Ganzen so funktionieren kann.
In Zukunft geht es sicherlich in Richtung MX Umstellung, RDP in Maßen, ob nun als Terminal Server, oder virtuellem Windows 11. (Danke für den Tipp)

 

Vielen Dank für euer Feedback.

[NorbertFe 2.045]

vor 16 Minuten schrieb Mack:

Es gibt bestimmt auch viele gute Gründe alles zentral zu organisieren. Gleichzeitig wird dann allerdings auch der Anspruch an Ausfallsicherheit immer höher.

Du sitzt dem Irrglauben auf, dass man in einer Exchange Org irgendwie Standortbezogene Server einfacher betreuen könnte, als eine zentrale DAG. Das ist definitiv nicht so und bei ALLEN Kunden die ich kenne/habe, bei denen ein dezentraler Ansatz gefahren wurde führte das früher oder später zu genau dieser Erkenntnis.

vor 17 Minuten schrieb Mack:

Das Konstrukt ist nämlich am Ende das Ergebnis einer Migration aus aktuell drei Standorten mit zwei eigenen lokalen Domänen und einer lokalen Arbeitsgruppe.

Ja, das wär nicht so unwichtig gewesen, ändert aber nur was am Ausgangszustand und nicht am Ziel (bzgl. unserer Aussagen).

vor 18 Minuten schrieb Mack:

Und schließlich spielt, zumindest für uns, auch eine Rolle, wo kommt man her (IT technisch) und wo will man hin, was braucht man und wieviel kann man investieren und leisten.
Längst nicht jedes Szenario ist dabei das best Mögliche, sondern im Zweifel werden Kompromisse gemacht werden (müssen).

Das ist so lalala gesprochen, das trifft immer und überall zu. Was soll uns das jetzt sagen? :)

[testperson 1.680]

vor 19 Stunden schrieb testperson:

Was sind denn "externe Cloud Lösungen" und warum scheiden diese kategorisch aus?

Hier wäre - wenn man über zentrale IT spricht - weiterhin die Frage, wieso kategorisch "externe Cloud Lösungen" ausgeschlossen werden. Was verstehst du hier genau unter "externe Cloud Lösungen"? In der Terra Cloud von Wortmann und sicherlich auch bei anderen Anbietern kannst du dir bspw. verwaltete Cluster bereitstellen lassen und hättest - je nach Anforderungen - bereits eine recht verfügbare (Grund-) Infrastruktur.

 

vor einer Stunde schrieb Mack:

Es gibt bestimmt auch viele gute Gründe alles zentral zu organisieren. Gleichzeitig wird dann allerdings auch der Anspruch an Ausfallsicherheit immer höher.
Der zu betreibende Aufwand dabei steigt schnell bezüglich Kosten, Aufwand und auch notwendigem Know How, was ggf. zu weiteren Kosten wieder eingekauft werden muss.

Daher präferiert man prinzipiell den dezentralen Ansatz, da dann einzelne Standorte trotz Ausfalles eines anderen in großen Teilen weiter arbeitsfähig sind.

Das kannst du allerdings auch genau andersrum "kalkulieren".  

 

Unterm Strich sieht das für mich allerdings weiterhin danach aus, als wäret Ihr weit weg von solchen "Detailplanungen".

 

vor 15 Stunden schrieb cj_berlin:

Der Support von Office auf Terminalservern ist bis Oktober 2026 gesichert.

Hier würde ich fast schon sagen, dass der Support von Office auf (Terminal) Servern auch im Mainstream Support von vNext, also vermutlich bis 2029, gegeben ist. (https://www.mcseboard.de/topic/220710-m365-apps-support-auf-windows-server-2022)

 

[teletubbieland 168]

vor 34 Minuten schrieb testperson:

 

Hier würde ich fast schon sagen, dass der Support von Office auf (Terminal) Servern auch im Mainstream Support von vNext, also vermutlich bis 2029, gegeben ist. (https://www.mcseboard.de/topic/220710-m365-apps-support-auf-windows-server-2022)

 

you saved my day

[NorbertFe 2.045]

bearbeitet 19. Juli 2023 von NorbertFe