Die beiden MVP-Kollegen Hans Brender und Raphael Köllner sind Gastgeber des MVP Kaffeeklatsch, einer Podcast/Videocast-Reihe rund um aktuelle Themen aus der IT
Ich war Gast in der aktuellen Folge 32 und wir haben uns in gemütlicher Runde über Exchange, Microsoft 365 und Remote Work unterhalten.
Viel Spaß.
Seit dem 11. September 2017 besteht für Office 365 Kunden die Möglichkeit, Gastkonten für externe Benutzer zu Microsoft Teams hinzuzufügen.
Der Zugriff für Gäste muss ebenfalls lizensiert werden. Hierzu muss in der Microsoft Teams Verwaltung im Office 365 Admin Portal der Lizentyp Gast aktiviert.
Hinweis aus der Office 365 Benachrichtigung im Admin Portal:
When we make this change, the ‘Pick the license you want to configure’ setting in ‘Settings > Services and Add-ins > Microsoft Teams’, will now have an option for ‘Guest’ with a default value of “off” for the ‘Turn Microsoft Teams on or off for your entire organization’ setting.
Die Aktivierung wird gerne übersehen.
Viel Spaß mit Office 365!
Das E-Mail-Sicherheitsgateway NoSpamProxy untertützt die Anbindung an die De-Mail-Infrastruktur. Mit Hilfe von De-Mail ist eine gesetzlich geregelte Zustellung von rechtlich relevanten E-Mail-Nachrichten möglich. MIt Hilfe von NoSpamProxy kann Ihr Unternehmen E-Mail-Nachrichten mit De-Mail-Empfängern austauschen, ganz unabhängig davon, ob Ihre E-Mail-Server in der internen IT-Infrastruktur betrieben werden oder als SaaS-Dienst wie z.B. Office 365. In meinem Beispiel befinden sich alle Postfächer in Exchange Online.
Die Anbindung von De-Mail und Office 365 über das E-Mail-Gateway wird im nachfolgenden Schaubild deutlich.
Die zur Anbindung an Office 365 erforderlichen Komponenten, wie z.B: Azure AD Connect, sind im Diagramm nicht dargestellt, um die Übersichtlichkeit zu gewährleisten.
Das E-Mail-Gatewaysystem wird in diesem Beispiel auf einer Hyper-V-Plattform betrieben. Da die De-Mail-Zertifikate auf einer Smardcard gespeichert sind und der Betrieb des Gateways unbeaufsichtigt erfolgen soll, muss die Smartcard über einen zertifizierten Kartenleser permanent eingebunden werden. Entsprechende Smartcard-Lesegeräte sind als USB-Geräte erhältlich. Beim Erwerb einer De-Mail-Signaturkarte erhalten Sie einen passenden Kartenleser.
Die Verbindung des physikalischen Smartcard-Lesegerätes zum virtualisierten Betriebssystem erfolgt mit Hilfe eines USB-Servers. Für diesen USB-Server wird auf dem virtualisierten Betriebssystem eine Treiber-Software installiert, die einen virtualisierten USB-Port bereitstellt. Über diesen vUSB-Port ist anschließend das Smartcard-Lesegerät mit dem Betriebssystem verbunden. Zusätzlich werden noch die passenden Treiber und die Verwaltungssoftware für das De-Mail-Zertifikat benötigt.
Das folgende Schaubild verdeutlicht die technische Anbindung des Smartcard-Lesegerätes mit einem virtualisierten Betriebssystem.
System-Komponenten
Software-Komponenten
Die Anbindung an De-Mail erfolgt immer auf einem NoSpamProxy-System mit installierter Gateway-Rolle. Ob es sich um ein reines Gateway-System handelt oder aber um ein System mit installierte Intranet- und Gateway-Rolle ist unerheblich. In der nachfolgenden Beschreibung gehe ich davon aus, dass die NoSpamProxy Gateway-Software bereits installiert ist und die Nutzung von De-Mail lizensiert ist.
Installieren Sie zuerst den USB-Server und richten Sie das Smartcard-Lesegerät im Windows Server Betriebssystem ein. Die in diesem Artikel beschriebenen Schritte und zu installierenden Komponenten gelten für Windows Server 2012R2 und Windows Server 2016 identisch. Für Windows Server 2019 liegen noch keine Erfahrungen vor.
An diesem Punkt haben Sie das Smartcard-Lesegerät über den USB-Server und den virtuellen USB-Treiber der USB-Umlenkung mit dem Windows Server Betriebssystem verbunden. Bei jedem Neustart des Betriebssystems wird das Lesegerät automatisch verbunden.
Für die folgenden Installationsschritte und die Einbindung des De-Mail-Zertifikates ist es erforderlich, dass Sie eine Konsolenverbindung zum virtualisierten Betriebssystem herstellen. Die Einbindung des Smartcard-Zertifikates innerhalb einer RDP-Sitzung auf dem Windows Server nicht möglich, da dies durch den Windows Smartcard-Treiber aktiv verhindert. Sie erkennen dies daran, dass es beim Start des TCOS-CardManagers zu folgender Fehlermeldung kommt.
In einer VMware Hypervisor-Plattform ist der Zugriff über eine Konsolensitzung kein Problem. Wenn Sie aber Hyper-V als Hypervisor-Plattform einsetzen, müssen Sie auf die folgenden Einstellung des Hyper-V-Hostsystems achten.
Die Funktion "Erweiterten Situngsmodus zulassen" muss ausgeschaltet sein. Wenn diese Funktion eingeschaltet ist, werden alle Sitzungen durch das Gast-Betriebssystem als RDP-Sitzungen wahrgenommen. Dies führt automatisch dazu, dass der beschriebene Zugriff auf die Smartcard-Blibliotheken unterbunden wird. Diese Funktion muss nur für den Zeitraum der Konfiguration der De-Mail-Zertifikate in Windows Server ausgeschaltet sein bzw. immer dann, wenn Sie mit dem TCOS CardManager arbeiten müssen.
Folgende Schritte sind notwendig, um die TCOS-Smartcard und die De-Mail-Zertifikate zu integrieren:
Der die TCOS-Softwarekomponenten sind so programmiert, dass die De-Mail-Zertifikate beim ersten Zugriff auf die Signaturkarte in den lokalen Zertifikatsspeicher des angemeldeten Benutzers kopiert werden. Dieser Zertifikatsspeicher ist für installierte Softwarelösungen gänzlich ungeeignet. Die Zertifkate müssen in den Zertifikatsspeicher des Computers verschoben werden. Hierbei hilft Ihnen das Tool CertificatePromoter.exe, das Sie vom Net at Work-Support erhalten können.
Nachdem nun die De-Mail-Zertifikate im richtigen Zertifikatsspeicher abgelegt sind, muss der Zugriff auf die Zertifikate und die privaten Schlüssel konfiguriert werden. Die hierzu erforderlichen Schritte habe ich im Artikel "Zugriff auf privaten SSL-Schlüssel konfigurieren" beschrieben. Führen Sie die dort beschriebenen Schritte für die drei verschobenen De-Mail-Zertifikate durch.
Damit sind alle Voraussetzungen für eine funktionierende Anbindung des E-Mail-Security Gateways NoSpamProxy an De-Mail abgeschlossen. Die Konfiguration erfolgt in der NoSpamProxy MMC-Verwaltungsoberfläche im Menüpunkt Connected systems. Sie können entweder einen Telekom De-Mail-Connector oder einen Mentana-Claimsoft De-Mail-Connector hinzufügen.
Wenn alle Einstellungen und Konfiguration korrekt durchgeführt wurden, wird in der NoSpamProxy MMC-Verwaltungsoberfläche nach kurzer Zeit die Anzahl der zur Verfügung stehenden De-Mail-Domänen angezeigt. Diese Information wurde durch NoSpamProxy vom De-Mail-Gateway abgefragt und ist daher ein Beleg für die funktionierende Verbindung.
Ab diesem Punkt können Sie mit den weiteren Benutzer-Konfigurationen für De-Mail, entsprechend der NoSpamProxy Anleitung fortfahren.
Sollte es doch zu Problemen bei der Verbindung zum De-Mail-Gateway kommen, prüfen Sie bitte die folgenden Punkte:
Damit erschöpfen sich auch schon die allgemeinen Möglichkeiten zum Troubleshooting der De-Mail-Anbindung. In den meisten Fällen liegt ein Problem beim Verbindungsaufbau vor. Dies ist entweder die HTTPS-Strecke selbst oder aber die Aushandlung der TLS-Verschlüsselung (Handshake). Die Analyse des TLS-Handshake erfordert die Installation eines Werkzeuges zur Netzwerkanalyse, wie z.B. Wireshark oder Microsoft Message Analyzer.
# Prüfung der TLS-CipherSuite # Wird kein Ergebnis zurückgegeben, muss die CipherSuite aktiviert werden (Get-TlsCipherSuite) | Where-Object {$_.Name -eq 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384'} # Alphabetische Auflistung der konfigurierten TLS-CipherSuites des OS Get-TlsCipherSuite | Sort-Object Name | FT Name # Aktivierung der CipherSuite Enable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 # Auflistung der aktivierten elliptischen Kurven # Wird die Kurve NistP521 nicht aufgeführt, muss sie aktiviert werden Get-TlsEccCurve # Aktivierung der ECC Kurve NistP521 Enable-TlsEccCurve NistP521 # Alle Änderungen an den TLS-Einstelliunge erfordern einen Neustart des Servers
Ich wünsche viel Spaß mit dem NoSpamProxy E-Mail-Sicherheitsgateway und De-Mail.
Das Blog Cumulative Update für April 2020 (CU0420) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Microsoft Teams und Azure des Monats April 2020 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Der virtualisierte Betrieb von Exchange Server ist seit der Einführung von Hypervisor-Plattformen immer wieder Thema für Diskussionen. Oftmals werden diese Diskussionen sehr emotional geführt und die richtigen Argumente für und gegen solch einen Betrieb finden selten Gehör. Das ist meist dann der Fall, wenn das Motto 100% Virtualisierung ausgerufen wurde.
Unabhängig von der Exchange Server Produktversion gibt es für die Planung und den Betrieb virtualisierter Exchange Server einen wichtigen Grundsatz:
Die Anforderungen an Prozessor, Arbeitsspeicher und Datendurchsatz der Festplatten für virtualisierte Exchange Server sind identisch zu den Anforderungen eines Betriebs auf physischen Servern.
Von diesem Grundsatz wird in der Realität immer wieder abgewichen. Abweichung von diesem Grundsatz haben aber automatisch Auswirkungen auf den stabilen und sicheren Betrieb von Exchange Server und erhöhen zusätzlich das Betriebsrisiko.
Mit Exchange Server 2019 haben sich empfohlenen Betriebsparameter für einen stabilen Betrieb, im Vergleich zu den Vorversionen, stark verändert.
Die empfohlene Prozessor-Konfiguration sieht weiterhin eine 2-Sockel-Architektur, allerdings mit insgesamt bis zu 48 Prozessorkernen (Cores) vor. Für den Betrieb eines Exchange Servers mit Postfach-Rolle ist eine Arbeitsspeichergröße von 128GB und für einen Server mit Edge Transport-Rolle eine Arbeitsspeichergröße von 64GB empfohlen.
Ob für Ihre Exchange Server 2019 Umgebung diese empfohlenen Betriebsparameter sinnvoll oder ob andere Betriebsparameter notwendig sind, finden Sie mit Hilfe des Exchange Server 2019 Sizing Calculator heraus. Der Calculator basiert auf einer Excel-Datei, die für Exchange Server 2019 ab dem Kumulativen Update 2 Bestandteil der Exchange Server 2019 ISO-Datei ist. Für Exchange Server 2016 können Sie die Excel-Datei direkt aus dem Microsoft Download Center herunterladen.
Die Virtualisierung von Exchange Server 2019 ist, wenn Sie sich nur an den Empfehlungen der Online Dokumentation orientieren, eine Herausforderung. Sie werden zu recht einwenden, dass niemand diesen Empfehlungen folgt, um Exchange Server 2019 produktiv zu betreiben. Meine Gegenfrage ist aber automatisch: Warum folgen Sie diesen Empfehlungen nicht? Die Empfehlungen basieren auf den jahrelangen Erfahrungen der Exchange Produktgruppe mit dem Betrieb von Exchange Server 2019 in großen und hochverfügbaren Umgebungen.
An dieser Stelle sei auch noch einmal darauf hingewiesen, was das Produkt Exchange Server ist:
Exchange Server ist eine Softwarelösung zur hochverfügbaren und sicheren Bereitstellung einer Massaging-Plattform für Clients und weitere Applikationen.
Vor dem Hintergrund der Empfehlungen für die Prozessor- und Arbeitsspeicherkonfiguration ist eine Virtualisierung von Exchange Server 2019 nicht immer sinnvoll. Wenn Sie eine Datenbankverfügbarkeitsgruppe (DAG) mit der Mindestanforderung von vier Mitgliedsservern konfigurieren, benötigen Sie auch mindestens vier Hypervisor-Host-Systeme. Der gleichzeitige produktive Betrieb von zwei Exchange Servern auf einem Host-System stellt ein beträchtliches Betriebsrisiko dar und ist im Regelbetrieb zu vermeiden.
Für den empfohlenen Betrieb des Exchange Server Gast-Systems müssen Sie in der Hypervisor-Plattform mit fest reservierten Ressourcen für Prozessor und Arbeitsspeicher arbeiten. Sie können bei der CPU-Ressourcenzuweisung zwar ein Verhältnis von 1:2 (pCore : vCore) konfigurieren, jedoch ist dies nur dann sinnvoll, wenn Sie sowohl die CPU-Auslastung des Gast-Systems, als auch des Host-Systems lückelos überwachen. Sobald auf dem Host-System weitere virtuelle Systeme betrieben werden, die eine hohe CPU-Last erzeugen, geht dies automatisch zu Lasten des Exchange Server-Systems.
Bedenken Sie bei der Konfiguration der Ressourcen immer, dass eine auf einem Windows Server betriebene Applikation immer genau die Ressourcen sieht, die das Betriebssystem meldet. Ist ein Server-System mit 24 vCores und 128GB Arbeitsspeicher konfiguriert, so nimmt die Applikation diese Ressourcen auch in Anspruch. Stehen diese Ressourcen bei einer dynamischen Zuweisung durch das Host-System nicht unmittelbar zur Verfügung, kommt es zu spürbaren Leistungsproblemen und zu Appkilationsfehlern.
Neben den Hypervisor-Herausforderungen für CPU-Cores und Arbeitsspeicher ergeben sich ebenso Herausforderungen für die Anbindung der notwendigen Speichermedien. Idealerweise verfügt das Gast-System für Exchange Server 2019 über nur ein, per Laufwerksbuchstaben eingebundenes Volume für das Betriebssystem und die Exchange Server Programmdateien. Alle weiteren Volumes zur Speicherung der Postfachdatenbanken und Protokolldateien werden über Mountpoints eingebunden. Je nach Anzahl der benötigten Volumes und der verwendeten Technologie zur Bereitstellung von Volumes in der Hypervisor-Plattform, stoßen Sie hier an Grenzen. Erschwert wird diese Situation noch dadurch, dass der hochverfügbare Betrieb einer DAG die Nutzung der AutoReseed-Funktion von Exchange Server vorsieht. Die AutoReseed-Funktion erfordert die Einbindung weiterer Volumes durch die Hypervisor-Plattform in das Gast-System.
Die Bereitstellung von leistungsstarkem Datenspeicher ist der neuralgische Punkt einer virtualisierten Exchange Server-Plattform. Für die Bereitstellung des erforderlichen Datenspeichers bieten Ihnen zahlreiche Hersteller die phantasievollsten Lösungen an. In den meisten Fällen handelt es sich um Lösungen, die eine Ersparnis des benötigten Gesamtvolumens für Exchange Server Postfachdatenbanken und Protokolldateien versprechen. Oftmals wird dies durch eine Form der Deduplizierung für die Postfachdatenbanken und Protkolldateien erreicht.
In solchen einem Fall muss Ihnen bewusst sein, dass Sie das Feld eines unterstützen Betriebes von Exchange Server 2019 verlassen. Sie nehmen Exchange Server eine der wichtigsten Funktionen für den Fall eines Desaster, die Datenbankportierbarkeit.
Jede weitere Technologieebene im Betrieb Ihrer Exchange Server-Plattform erhöht die Komplexität und die Zahl der möglichen Fehlerquellen. Hinzu kommt, dass Sie solch einen extern angebunden Datenspeicher immer redundant betreiben müssen, um das allgemeine Betriebsrisiko der Plattform zu minimieren. Bedenken Sie in diesem Zusammenhang auch, dass das Exchange Server Produktteam klassische HDD-Datenträger für die Speicherung von Datendateien empfiehlt, da SSD-Laufwerke nicht die notwendige Zuverlässigkeit und Robustheit aufweisen.
Mit Exchange Server 2019 wurde die Funktion der MetaCache-Datenbank (MCDB) eingeführt. Die Aufgabe der MCDB ist die Beschleunigung des Datenzugriffs auf häufig genutzte Postfachinformationen. Für den optionalen Betrieb einer DAG mit aktivierter MCDB-Funktion sind einige Voraussetzungen zu erfüllen:
Beim Betrieb einer Exchange Server Plattform mit physikalischen Servern verwenden Sie idealerweise passende M.2 SSD-Laufwerke, die direkt innerhalb des Servers verbaut sind. Auf diese Weise stehen Ihnen mehr Standardsteckplätze für die HDD-Laufwerke der Daten-Volumes zur Verfügung.
Aber wie können Sie von den Vorteilen der MCDB bei einem virtualisierten Betrieb von Exchange Server profitieren?
Wie bereits erwähnt, basiert die Nutzung der MCDB-Funktion auf SSD-Datenträgern. Bei einem Betrieb in einer Hypervisor-Plattform sind immer zusätzlichen Technologieebenen zwischen dem Betriebssystem und dem eigentlichen Datenspeicher, die den Geschwindigkeitsvorteilen einer direkten SSD-Anbindung in einem physikalischen Server entgegenstehen.
In einer Hypervisor-Plattform ist der Betrieb einer MCDB-Konfiguration nicht sinnvoll. Die zusätzlichen Laufwerke, insofern Sie als SSD-Laufwerke bereitgestellt werden können, erhöhen nochtmals die Komplexität der Plattform und erzeugen mit ihren Disk-I/O zusätzliche CPU-Last auf dem Host-System. Damit steigt das Risiko einer Verlangsamung des Datenzugriffs, sobald auf dem gleichen Host-System andere Applikationen mit hohen Systemanforderungen betrieben werden.
Daher ist meine Empfehlung, die MCDB-Funktion von Exchange Server 2019 nur beim Betrieb mit physikalischen Servern zu nutzen.
Der zu Exchange Server 2019 gehörende Role Requirements Calculator unterstützt Sie auch bei der Planung einer MCDB-Implementierung.
Wenn Sie einen virtualisierten Betrieb von Exchange Server 2019 planen, beachten Sie bitte immer die Empfehlungen der Exchange Server Produktgruppe in der Online Dokumentation. Diese Empfehlungen gründen auf den Erfahrungen im täglichen Betrieb von Exchange Server und den Exchange Server Supportfällen, basierend auf sehr individuellen Exchange Server Betriebsarten in Kundenumgebungen.
Achten Sie bei der Virtualisierung von Exchange Server 2019 auf eine möglichst einfache und standardisierte Implementierung. Jede zusätzliche Technologieebene erhöht nicht nur die Komplexität des Betriebs, sondern ist immer auch eine zusätzliche Fehlerdomäne. Vertrauen Sie nicht auf die Versprechen für vermeintlich leistungssteigernde Speicherlösungen für Ihre Exchange Server Systeme, die gerne von Systemhäusern als Allheilmittel angeboten werden.
Der Einsatz der MetaCache-Datenbank ist nur auf physikalischen Servern sinnvoll. Nur dort bietet die MCDB den gewünschten Geschwindigkeitsvorteil als Cache-Speicher zwischen Applikation und den Postfachdatenbanken.
Und vergessen Sie nicht, die Hochverfügbarkeit der Exchange Server 2019 erfolgt, wie bei allen modernen Exchange Server Versionen, auf Applikationsebene.
Und wenn Sie den Betrieb einer Einzelserverinstallation von Exchange Server 2019 planen, so möchte ich Ihnen den Wechsel zu Microsoft 365 und Exchange Online ans Herz legen.
Viel Spaß mit Exchange Server 2019.
Die Virtualisierung von Exchange ist nicht neu und war bereits seit Exchange 2003 mit VMware eine Option, obwohl es damals von Microsoft keine offizielle Unterstützung hierzu gab. Im Rahmen des Microsoft Server Virtualization Validation Program (SVVP) wurde die Virtualisierung von Exchange 2007 Service Pack 2 auf VMware ESX 3.5 Update 2 erstmal offiziell voll unterstützt.
Mit der Veröffentlichung von Exchange Server 2010 wurden alle Serverrollen (Unified Messaging ab Exchange 2010 SP1) auf allen SVVP validierten Hypervisor-Plattformen unterstützt. Die Unterstützung der Virtualisierung von Exchange Server 2010 wurde aber nur langsam adaptiert, da dies eine grundlegende Änderung im Design und der Architektur der Systeminfrastruktur mit sich brachte. Viele Systemadministratoren misstrauten der Virtualisierung und führten häufig die fehlende "Performance" als primären Grund an, sich gegen die Virtualisierung zu entscheiden. Interessant ist, dass "Performance" als genereller Begriff verwendet wurde (wird), um die Virtualisierung von Exchange Systemen abzuwenden. Die technologische Weiterentwicklung von Exchange und die stete Reduzierung der Anforderungen an Speichermedien in Bezug auf den erforderlichen Datendurchsatz, denn diese waren in der Vergangenheit der einzige Grund, sich gegen die Virtualisierung zu entscheiden, wird teilweise immer noch ignoriert.
Mit Exchange Server 2013 können alle Rollen problemlos virtualisiert werden und ermöglichen so eine optimale Ausnutzung der Hardware-Ressourcen in Ihrem Rechenzentrum.
Trotzdem ist es erforderlich, eine Exchange Umgebung korrekt und gewissenhaft zu planen und zu berechnen. Dies hat sich mit der Virtualiserungsoption für Exchange nicht geändert. Nur mit einer gewissenhaften Planung können komplexe Änderungen der Exchange-Landschaft zu einem späteren Zeitpunkt vermieden werden. Exchange Server 2013 besteht aus folgenden Serverrollen:
Die erfolgte Reduzierung von vier Serverrollen in Exchange 2007/2010, hin zu zwei Serverrollen, wenn wir die Edge-Rolle einmal als Sonderfall betrachten, erleichtert die Konzeption einer virtualisierten Exchange-Umgebung erheblich.
Wenn es um das Thema Virtualisierung von Enterprise-Applikation geht, einmal ganz ohne den Fokus Exchange, muss immer geklärt werden, wie die Hochverfügbarkeit (HA) der Applikation gewährleistet wird. Auf der einen Seite existieren HA-Funktionen in der jeweiligen Hypervisor-Plattform selber, auf der anderen Seite stehen die HA-Funktionen der Applikationen. Naiv gesehen könnte man annehmen, dass beides zusammen das Maximum an Hochverfügbarkeit bieten würde. Dies ist jedoch nicht der Fall.
Gerade für den Fall eines Support-Calls mit Microsoft ist es wichtig, dass Exchange in einer Konfiguration betrieben wird, die auch zu 100% unterstützt wird.
Für die Virtualisierung von Exchange Server 2013 gilt es Folgendes für einzelnen Systemkomponenten zu beachten
Exchange Server 2013 kann ebenso wie Vorgängerversionen als Multi-Role Server (Mailbox- und CAS-Rolle auf einem Server) oder als Single-Role Server (Mailbox-Rolle und CAS-Rolle auf separaten Systemen) installiert werden. So wie Exchange Rollen selber aufgeteilt werden können, können auch physische und virtuelle Systeme verteilt betrieben werden.
Natürlich können (sollten) auch die benötigten Load Balancer virtualisiert betrieben werden. Die möglichen Kombinationen mit den o.g. Exchange-Konfigurationen sind zahlreich und werden in diesem Artikel vernachlässigt.
Grundsätzlich gilt die Empfehlung, für das Sizing einer Exchange 2013 Umgebung (physisch oder virtuell), den Exchange 2013 Server Role Requirements Calculator zu verwenden. An diesem Tool führt kein Weg vorbei, wenn man eine verlässliche Aussage zu den Anforderungen für die Exchange Umgebung erhalten möchte. In den aktuellsten Versionen sind notwendige Berechnungskorrekturen für die Virtualisierung bereist enthalten. Microsoft geht von einem zusätzlichen Overhead durch den Hypervisor von 10% aus. VMware wiederum geht von ca. 2% bis 5% Overhead aus.
Wie bereits erwähnt, ist eine 1:1 Zuordnung von virtuellen CPU Cores zu physischen CPU Cores zu empfehlen, da dies die Umsetzung der kalkulierten Anforderungen in den laufenden Betrieb stark vereinfacht.
Microsoft hat empfiehlt beim Einsatz von Exchange Server (2010 und 2013) auf das Hyper-Threading der CPUs zu verzichten. Wichtig ist, dass Hyper-Threading CPUs nicht gleichzusetzen sind mit physischen CPUs. Als Hauptgrund wird angegeben, dass dies die CPU Planung unnötig verkompliziere. Als zweiter Grund wird die .NET Garbage Collection angeführt, die auf Basis der CPU Anzahl arbeitet und entsprechend Arbeitsspeicher allokiert. Durch Hyper-Threading wird allerdings unnötig viel Arbeitsspeicher für die Garbage Collection reserviert.
Im Rahmen einer Virtualisierung besteht das beschriebene Problem nicht im gleichen Ausmaß, wie in einer physischen Umgebung, da der VM eine feste Anzahl an Prozessoren zugeordnet ist. Dies bedeutet, dass Sie das für Ihre Umgebung passende Processor-Ratio finden müssen, wenn Sie nicht der 1:1 Zuordnung folgen möchte. Dies gelingt am besten, indem Sie mit einer 1:1 Zuordnung beginnen und mit einer System-Monitoring Lösung eine Baseline erstellen. Anschließend passen Sie die Prozessorzuordnung an und vergleichen die Auslastung- und Performancediagramme mit der Baseline.
Die nachfolgende Tabelle listet die Mindestanforderungen an Arbeitsspeicher für Exchange Server 2013
Dies sind die absoluten Mindestanforderungen. Ohne Verwendung des Role Requirements Calculators wird eine korrekte Planung für den performanten Betrieb von Exchange nicht gelingen.
Für einen Exchange Mailbox-Server mit 1000 Postfächern mit einem Anwenderprofil von 150 gesendeten und empfangenen Nachrichten pro Tag und einer Anforderung von 36MB Datenbankcache pro Postfach, benötigen Sie bereits mindestens 36GB Arbeitsspeicher. Ergänzend zum Role Requirements Calculator empfehle ich den Blog-Artikel "Ask the Perf Guy: Sizing Exchange 2013 Deployments" (http://bit.ly/PerfGuyExchange2013Deployments).
Ergänzend zu den Speicheranforderungen für Exchange Server 2013 müssen noch 4GB bis 8GB für das Betriebssystem addiert werden.
Für die Planung der Netzwerkverbindungen der virtuellen Systeme gelten die gleichen Anforderungen wie für physische Exchange Server. Exchange Server, die nicht Mitgliedsserver einer DAG sind, können mit einem einzelnen Netzwerkadapter konfiguriert werden. Mitgliedsserver einer DAG sollten immer mit zwei Netzwerkadaptern konfiguriert werden, um die Datenbankreplikation über ein separates Netz zu leiten und vom allgemeinen Zugriff auf die Postfachdatenbanken zu trennen. Der Einsatz von einzelnen Netzwerkadaptern ist zwar unterstützt, sollte sich aber auf Test- und Laborumgebungen beschränken.
Die physischen Netzwerkadapter im Host-System können durch Teaming ausfallsicher konfiguriert werden.
Das nachfolgende Beispiel zeigt, wie ein Exchange 2013 Mailbox Server, der Mitgliedserver einer DAG ist, und ein CAS Server nur durch VLANs getrennt an einem virtuellen Switch verbunden sind. Der virtuelle Switch ist durch NIC-Teaming im Hypervisor redundant mit der physischen Netzwerk Infrastruktur verbunden.
Mit der gleichen Exchange Server-Konstellation kann aber das DAG Netzwerk-Interface zur Datenreplikation über einen separaten virtuellen Switch, der über ein eigenes NIC-Interface im Hypervisor verfügt, mit einem dedizierten Replikationsnetzwerk verbunden werden.
Die zweite Konfiguration stellt sicher, dass die Datenreplikation in einem dedizierten physischen Netzwerk stattfindet. Jedoch erhöht dieser Lösungsansatz auch die Komplexität der Netzwerkinfrastruktur selber. Hinzu kommt, dass standardmäßig das MAPI Netzwerk als Backup für einen möglichen Ausfall des Replikationsnetzwerkes verwendet wird. Wenn Sie ausschließen möchten, dass das MAPI Netzwerk als Backup-Netzwerk verwendet werden kann, müssen Sie die Hochverfügbarkeit des Replikationsnetzwerkes sicherstellen.
In VMware Umgebungen empfiehlt es sich, immer den VMXNET3 Adapter für die virtuellen Maschinen zu verwenden, da der E1000 Adapter im Host-System nur CPU 0 für die Emulation verwendet. Die Nutzung des VMXNET3 Adapters bietet somit eine deutlich bessere Performance gegenüber dem E1000 Adapter.
Ganz unabhängig von der gewählten virtuellen Netzwerkkonfiguration muss immer sichergestellt werden, dass die Host-System sowohl in der Hardware-seitigen, als auch in virtuellen Netzwerkkonfiguration identisch konfiguriert sind. Die virtuellen Gast-Systeme können schließlich nur zwischen Hosts verschoben werden, die auch die notwendigen Ressourcen (virtuelle Switche, VM Port Groups, etc.) zur Verfügung stellen.
Die Bereitstellung des notwendigen Festplattenspeichers für virtualisierte Exchange Server 2013 Systeme bietet vielfältige Optionen. Die rein physischen Optionen, wie z.B. Bereitstellung von Raw LUNs, die in einem SAN Speicher konfiguriert sind, oder VMDK, VHD/VHDX Dateien im SAN oder im DAS, oder aber die direkte Einbindung der Datastore-Volumes per iSCSI im Gast-Betriebssystem selber, unterliegen den Möglichkeiten und Anforderungen Ihrer Unternehmensumgebung. Manchmal unterliegt die Auswahl des Speichermediums aber auch internen politischen Richtlinien, durch die bestimmt wird, dass ein "teurer" SAN Speicher verwendet werden muss, obwohl dies durch die Anforderungen von Exchange Server 2013 selber gar nicht mehr notwendig ist. Eines der Arguments für die Migration zu Exchange Server 2013 ist die Unterstützung von günstigen JBOD Enclosures, die sehr große Datenspeicher sehr günstig (im Vergleich zu klassischem SAN Speicher) bereitstellen können.
Hier muss eine sehr genaue Abwägung zwischen technischem Vorteil/Nutzen und dem zusätzlichen Aufwand und der zusätzlichen Komplexität in der Umgebung für Speichersubsysteme erfolgen. Es ist meist schwierig, die Einführung einer neuen Technologie nur mit den Anforderungen einer einzigen Applikation zu begründen. Es ist hilfreich zu prüfen, ob nicht auch andere Applikationen, die in naher Zukunft migriert werden sollen (z.B. von SharePoint 2010 auf SharePoint 2013), von dem neuen Speichermedium profitieren können. Eine stärkere strategische Ausrichtung hilft bei der Argumentation sehr.
Zusammenfassend kann man sagen, dass die Virtualisierung eine große Flexibilität im Sizing und im Betrieb einer Exchange Plattform mit sich bringt. Jedoch birgt eine Virtualisierung schnell auch Risiken. Dieses Risiken wirken sich nicht unbedingt auf den sicheren Betrieb von Exchange aus, sondern vielmehr auf die Reaktionszeit, also die Performance der Exchange Umgebung.
Grundsätzlich darf man aber nicht vergessen, dass gemessene Performance nicht gleichzusetzten ist, mit subjektiv gefühlter Performance. Insbesondere Endanwender sind sehr empfindlich und reagieren kritisch, wenn "Ihr" Outlook nicht in der gleichen Zeitspanne startet, wie "gestern". Ähnlich sieht es aus, wenn Nachrichten durch mangelhafte Ressourcenverfügbarkeit zu lange in einer Warteschlange verweilen, bevor sie zugestellt werden. Auch wenn Administratoren wissen, dass E-Mail (oder besser SMTP) ein Warteschlangen-basierende Kommunikation ist, ist dies Endanwendern meist nur sehr schwer zu vermitteln.
Viel Spaß bei der Virtualisierung von Exchange Server 2013.
Heute wurde mein Gastbeitrag im ENow Exchange & Office 365 Solutions Engine Blog (ESE) zum Thema
Modern Attachments with OneDrive for Business
veröffentlicht.
Ich wünsche viel Spaß beim Lesen.
Hier geht es zum Artikel: http://blog.enowsoftware.com/solutions-engine/modern-attachments-with-onedrive-for-business