Fachartikel

Exchange 2019 Preferred Architecture (3)

Exchange ist ein äußerst komplexes Produkt, das verschiedenste Konfigurationsmöglichkeiten kennt. Dieser Workshop bringt Ihnen einige Empfehlungen zur Konfiguration von Exchange 2019 näher, damit Sie sich bei der Entwicklung Ihrer Umgebung besser an den Vorgaben von Microsoft orientieren können. Dabei gehen wir unter anderem auf Server, Storage, Lastenverteilung und DNS-Namen ein. Im dritten Teil erläutern wir die Bestimmung des DNS-Namens und wie Sie die DAG richtig konfigurieren.
Das Mantra "einfacher ist besser" ist bei Exchange 2019 stark spürbar.
So bestimmen Sie den DNS-Namen
Nachdem geklärt ist, dass interne und externe Namen identisch sind, stellt sich die Frage, welche Namen zur Anwendung kommen und damit in das Zertifikat müssen. Zunächst einige Hintergrundaspekte: Beim Namen wählen Sie ein ungebundenen Namensbereich für Ihre Rechenzentren, sofern Sie über verschiedenen Zugangspunkte aus dem Internet verfügen. Im Gegensatz zum gebundenen Namensbereich findet ein Name für alle Rechenzentren Verwendung. Die öffentlichen IP-Adressen der verschiedenen Zugriffspunkte werden über den gleichen Namen im öffentlichen DNS registriert und die Auflösung erfolgt, wie bereits beschrieben, extern über DNS Round Robin.

Auf diesem Weg erhalten anfragende Clients abwechselnd eine andere IP-Adresse zurück. Der Netzwerkverkehr wird infolge auf beide Rechenzentren verteilt und circa 50 Prozent der Anfragen werden zwischen den Datacentern weitergeleitet. Die Namensentscheidung ist auch von der Netzwerktopologie abhängig und es kann Sinn ergeben, einen gebundenen Namensbereich zu nutzen. Dies ist zum Beispiel der Fall, wenn ein Datencenter in Europa und eines in Nordamerika angesiedelt ist und Sie den Traffic zwischen den Locations begrenzen wollen.


Bild 2: Sofern es mehrere Rechenzentren gibt, verwenden Sie einen einheitlichen DNS-Namen.

Zum Einsatz kommt also nur ein Name für sämtliche Clientzugriffe auf allen Servern einer Umgebung: "mail.domain.de". Neben dem Zugriffspunkt für die Clients erstellen Sie als zweiten DNS-Eintrag ein Autodiscover-Eintrag: "autodiscover. domain.de". Optional richten Sie noch Namen für andere Dienste ein, etwa "imap.domain.de" oder "smtp.domain.de".

Die Namen der Webzugriffe ändern Sie im Exchange Administration Center unter dem Punkt "Server / Virtuelle Verzeichnisse". Als weitere Möglichkeit zur Einrichtung der URLs steht Ihnen die PowerShell mit den folgenden Befehlen und den Parametern "InternalUrl" und "ExternalUrl" zur Verfügung:
Set-ActiveSyncVirtualDirectory

Set-WebServicesVirtualDirectory

Set-OabVirtualDirectory

Set-OwaVirtualDirectory

Set-EcpVirtualDirectory

Set-PowerShellVirtualDirectory

Get-MapiVirtualDirectory
Einzig die Autodiscover-URL richten Sie direkt über den Server ein:
Set-ClientAccessServer -Identity LABEX19 -AutoDiscoverService 
 -InternalUri https://autodiscover.<domäne.de>/Autodiscover/Autodiscover.xml
DAG richtig konfiguriert
Seit Exchange 2010 gehören DAGs zum festen Bestandteil von Exchange und sind der einfachste Weg, um Mailbox-Server abzusichern. Dabei werden Datenbankkopien über die Windows-Cluster-Technologien auf bis zu 16 verschiedene Mailbox-Server verteilt, um eine passive Kopie kurzfristig zu aktivieren. Die Einrichtung erfolgt dabei komplett über Exchange, ohne dass Sie sich mit dem Failovercluster-Manager näher beschäftigen.

Bei der Nutzung einer DAG laufen alle DAG-Mitglieder unter der gleichen Betriebssystemversion und weisen die gleiche Verzeichnisstruktur für die Datenbanken auf. Darüber hinaus verfügen alle Member-Server einer DAG über die gleiche Exchange-Version. Bis Exchange 2013 benötigte jede DAG ein Cluster Name Object (CNO). Dabei handelt es sich um ein AD-Objekt, das Exchange für die interne Cluster-Kommunikation nutzt. Der Name der DAG entspricht dem CNO.

Bei Exchange 2013 vor dem SP1 mussten Sie zunächst das CNO vorbereiten. Mit dem Update auf Exchange 2013 SP1 und in Verbindung mit Windows 2012 R2 führt Microsoft die AD-unabhängige Cluster-Konfiguration ein. Damit sind auch keine IP-Adressen aus den Subnetzen der DAG-Mitglieder mehr nötig. Ein Pre-Staging des CNOs ist somit nicht mehr erforderlich und die Einrichtung fällt deutlich leichter. Eine DAG neuen Typs richten Sie mit folgendem Befehl ein:
New-DatabaseAvailabilityGroup -Name DAG01 -DatabaseAvailabilityGroup 
-IpAddresses ([system.net.ipaddress])::none
Eine AD-unabhängige DAG können Sie ebenfalls über die EAC einrichten. Fügen Sie bei der Erstellung einfach die DAGIP-Adresse 255.255.255.255 in der Konfigurationsmaske hinzu.

Beim Hinzufügen eines Servers zur DAG wird auch weiterhin automatisch das Failovercluster-Feature installiert. Im Unterschied zu einer klassischen DAG werden Ihnen im Failovercluster-Manager zur DAG beziehungsweise zum Cluster keine Informationen mehr angezeigt. Wundern Sie sich nicht, wenn Sie zukünftig einen Blick in den Manager werfen und Ihnen augenscheinlich Informationen fehlen.

Im nächsten Schritt fügen Sie die Server der DAG hinzu und verteilen die Mailboxdatenbanken auf die Exchange-Server. Hier gibt es keine Änderungen zum bisherigen Vorgehen. Im folgenden Beispiel fügen wir den Server LABEX161 der DAG01 hinzu und richten auf dem Server LABEX162 eine Kopie der Datenbank DB01 ein:
Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer LABEX161

Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer LABEX162
-ActivationPreference 2
Dieses Vorgehen stellt ein weiterer Schritt zur Vereinfachung der Architektur dar und beschleunigt die Einrichtung einer DAG deutlich.

DAG-Netzwerk und Zeugenserver
DAG-Netzwerke werden bei der Einrichtung einer DAG automatisch angelegt und für den Replikations- oder MAPI-Verkehr verwendet. Jede DAG enthält maximal ein MAPI-Netzwerk und beliebige Replikationsnetzwerke. Bei Exchange 2010 war die Trennung zwischen Clientzugriffs- und das Replikationsnetz noch Best Practice, während Microsoft von der logischen Trennung zu Gunsten der Vereinfachung ab Exchange 2013 abrückt. Dies ist zum einen der höheren Netzwerkbandbreiten geschuldet – 10 GBit verbreitet sich immer mehr – sodass Performance-Engpässe der Vergangenheit angehören.

Zum anderen nutzt Exchange meist die gleiche Netzwerkinfrastruktur, sodass eine Trennung aus Sicherheitsgründen wenig Sinn ergibt. Ein Fehler des Servers oder im Netzwerkbereich führt immer zur Aktivierung einer Kopie eines anderen DAG-Mitglieds und eine Vereinfachung der Konfiguration ist zu empfehlen. Eine manuelle Konfiguration ist nicht notwendig. Ein Eingriff ist nur bei iSCSI-Netzwerken nötig. Deaktivieren Sie diese, sofern diese vorhanden sind:
Set-DatabaseAvailabilityGroupNetwork -Identity DAG10\DAGNetwork02 
-ReplicationEnabled:$false -IgnoreNetwork:$true
Zeugenserver kommen weiterhin nur dann zur Anwendung, wenn eine gerade Anzahl von Mitgliedern in der DAG vorliegt. Ist eine DAG über zwei Standorte verteilt und kommt ein Witness-Server zum Einsatz, sollte der Server nach Möglichkeit in einem dritten Standort liegen. Sofern keine dritte Lokation vorhanden ist, bietet sich auch die Nutzung von Microsoft Azure an. Voraussetzung ist, dass ein Netzwerkfehler zwischen den primären Standorten keinen Einfluss auf den dritten Standort hat. Dadurch kann immer ein automatischer Failover erfolgen, egal welches Rechenzentrum betroffen ist.

Fazit
Bei der Konfiguration von Microsoft Exchange 2019 hat sich nur wenig verändert.
Vor allem durch das Tiering mit SSD-Festplatten für MCDB müssen Sie bei der Festplattenkonfiguration einmal genauer hinschauen. Dem Weg zurück auf physische Server mit einfachen Festplatten bleibt Microsoft treu. Das Mantra "einfacher ist besser" ist stark spürbar und erleichtert die Arbeit der Administratoren deutlich.

Im ersten Teil des Workshops erklären wir, warum Microsoft mit Exchange 2019 den Pfad der Virtualisierung verlassen hat und wie der Storage-Unterbau aussehen sollte. In der zweiten Folge gehen wir darauf ein, was sich bei den Serverrollen, der Ausfallsicherheit und der Lastenverteilung geändert hat. Im dritten Teil erläutern wir die Bestimmung des DNS-Namens und wie Sie die DAG richtig konfigurieren.
20.12.2021/ln/dr/Christian Schulenburg

Nachrichten

In eigener Sache: Trauer um Marc Grote [26.01.2022]

Kürzlich musste die Redaktion leider vom unerwarteten Tod Marc Grotes erfahren, einem langjährigen Stammautor des IT-Administrator. Wir sind sehr bestürzt und traurig über diese Nachricht und verlieren mit Marc Grote einen freien Mitarbeiter, der uns bereits seit den frühen Anfängen des Magazins im Jahr 2006 zuverlässig begleitet hat. [mehr]

Telefonzentrale aus der Cloud [19.01.2022]

Die Deutsche Telekom und ihr Partner Aircall bieten Geschäftskunden eine Telefonzentrale aus der Cloud. Neben der Flexibilität einer cloudbasierten Lösung verspricht Aircall eine einfache Integration mit nahezu allen anderen Geschäftsanwendungen. So sollen Unternehmen ein einem umfassendes Kommunikationssystem erhalten, bei dem keine wichtigen Informationen wegen System- oder Medienbrüchen verloren gehen. [mehr]

Tipps & Tools

Freier sprechen – ob in Konferenzen oder im Home Office [22.01.2022]

Konferenzlautsprecher eignen sich nicht nur für große Räume, in denen viele Teilnehmer wichtige geschäftliche Treffen abhalten. Schon in einem Home Office kann ein solches Gerät wertvolle Dienste erweisen und seine Anwender darin unterstützen, entledigt von Kabeln und Kopfhörern mit freien Händen entspannter Gespräche mit der Außenwelt zu führen – und darüber hinaus wie das Modell "eMeet Luna Lite" schick und preiswert sein. [mehr]

Download der Woche: Wickr Me [22.12.2021]

Messenger sind als schnelle und einfache Kommunikationstools auch für Unternehmen hochinteressant. Allerdings scheitern gehypte Vertreter in der Regel an den im Firmenumfeld hohen, elementaren Sicherheits- und Vertraulichkeitsbedenken. Die will ein ehemals reiner Smartphone-Messenger überwinden: "Wickr Me" gilt als besonders sicher und ist in einer für Windows-Systeme bestimmten Desktop-Version kostenlos erhältlich. [mehr]

Buchbesprechung

Datenschutz im Unternehmen

von Michael Wächter

Anzeigen