Granikos Technology Blog

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:

• Client Access
  Diese Rolle stellt alle Endpunkte für Client-Verbindungen zur Verfügung, arbeitet aber als reiner Proxy, da das Rendering für Clients in der Mailbox-Rolle stattfindet
   
• Mailbox
  Diese Rolle wird auch als Back-End Rolle bezeichnet, da sie alle Funktionen für den Exchange Betrieb beinhaltet: Postfachdatenbanken (MBX), Nachrichtenfluss (HUB), Unified Message (UM) und Client Rendering
  
  
• Edge
  Optionale Rolle für den Einsatz in der DMZ als E-Mail Gateway Server zum/vom Internet

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

• Live Migration
  Exchange 2013 Server können mit Live Migration (vMotion bei VMware) zwischen Hypervisor-Hosts verschoben werden. Live Migration kann auch mit Mitgliedsservern einer Database Availability Group (DAG) durchgeführt werden.
   
• Hypervisor HA
  Virtualisierte Exchange Server können mit HA Funktionen der Hypervisor-Plattform, z.B. vSphere HA bei VMware, kombiniert werden.
  Wichtig ist, dass bei den virtualisierten System der Disk State nicht gespeichert und wiederhergestellt wird. Hierbei wird ein System "suspended", auf einen anderen Hypervisor-Host verschoben und wieder "resumed". Dieser Vorgang stellt kein unterstütztes Szenario für Exchange Server 2013 dar. Im Rahmen von vSphere HA wird ein System im ausgeschalteten Zustand ("Power Off") recovered, was einem Kaltstart gleichkommt. Diese Vorgehensweise ist ein unterstütztes Szenario für virtualisierte Exchange Server.
   
• Snapshots
  Die Verwendung von Snapshots ist kein unterstütztes Szenario. Da ein Exchange Server in Abhängigkeit zu zahlreichen externen Systemen und Konfigurationen steht, führt ein zurückgerollter Snapshot zum Verlust von Konfigurationen und Instabilität der gesamten Exchange-Umgebung. Snapshots von virtualisierten Exchange Servern sind kein Mittel für Exchange-Backup und -Restore.
   
• CPU-Verhältnis (Virtuell/Physisch)
  Microsoft und VMware empfehlen ein CPU Core Verhältnis (Virtuell : Physisch) von 1:1. Dies erleichtert grundsätzlich die Planung der Exchange Umgebung. Ein Verhältnis von 2:1 ist möglich, sollte aber nicht überschritten werden. Ebenso ist dringend anzuraten, eine Monitoring-Lösung einzusetzen, um die CPU Auslastung stetig zu protokollieren. Ein Anpassung bzw. Verdichtung der Ressourcen empfiehlt sich erst, nachdem ein Baseline für den Betrieb erstellt wurde.
   
• Speichermedien
  Durch die stark gesunkenen Anforderungen an den Datendurchsatz für Postfachdatenbanken und Protokolldateien (Disk IO) können virtualisierte Exchange System mit einer Vielzahl unterschiedlicher Disksysteme betrieben werden. In der Vergangenheit wurde primär SAN Speicher entweder als DAS oder als virtualisiertes SAN (z.B. HP EVA) verwendet und als RAW Volume eingebunden. Mögliche Arten sind Fiber Channel, iSCSI VMFS, iSCSI PassThrough, iSCSI Initiator im OS, Flat File VHDX. Welche Variante zum Einsatz kommt hängt somit noch stärker von der jeweiligen lokalen Infrastruktur ab. Dynamisch erweiterte Disks sollten aus Performancegründen nicht zum Einsatz kommen. Microsoft unterstützt keine "Thin Disks" für Exchange Datenpartitionen (Postfachdatenbanken, Protokolldateien)
   
• Netzwerkspeicher
  NAS Speicher, also VMDK Dateien, die sich auf NFS Speicher befinden und die im Gastbetriebssystem direkt eingebunden werden, sind nicht von Microsoft unterstützt. Virtuelle VHDX Festplatten, die sich auf SMB 3.0 Speichermedien befinden werden von Hyper-V unterstützt.
   
• Arbeitsspeicher
  Hypervisor-Plattformen unterstützen Funktionen zur dynamischen RAM-Zuweisung oder zum Overcommitment von Ram-Ressourcen. Die sog. Dynamic Memory Funktionen in Hyper-V sind für den Betrieb eines virtualisierten Exchange-Servers nicht unterstützt. Auch die Funktionen zur Verwaltung des Arbeitsspeichers in VMware führen zu einem nicht-performanten Betriebszustand von Exchange. Der Arbeitsspeicher sollte im Rahmen einer festen Reservierung dem System zugewiesen werden.
  Auch hier gilt die Empfehlung, die RAM-Nutzung und -Auslastung mit einer Monitoring-Lösung zu überwachen. Das Verhalten mit und ohne Dynamic Memory lässt sich so auch gut einem A/B-Test unterziehen.

Planung für Exchange Server 2013

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.

• 100% Virtualisierung
  • CAS- und Mailbox-Rolle auf getrennten virtuellen Systemen installiert Ermöglicht die Skalierung von zusätzlichen CAS Systemen getrennt von Mailbox-Servern
  • CAS- und Mailbox-Rolle als Multi-Role System installiert Ermöglicht eine vereinfachte Skalierung mit System-Template und anschließender automatischer Verteilung von Postfächer über alle Mailbox-Server
    
    
• Gemischter Betrieb
  • CAS-Rolle virtualisiert, Mailbox-Rolle als physischer Server Ermöglich das einfach Skalieren von CAS Servern, die physischen Mailbox-Server arbeiten bevorzugt mit DAS Speicher für Postfachdatenbanken. Dieser Ansatz unterstützt den "klassischen" Administrator, der Exchange Server "lieber" physisch betreibt
    
    
• Physischer Betrieb
  • CAS- und Mailbox-Rolle als Multi-Role Server auf einem System Wie bereits beim gemischten Betrieb mit virtualisierter CAS-Rolle sollte auch hier der Exchange Server mit DAS betrieben werden. Durch die HA Funktionen von Exchange ist SAN Speicher entschieden zu teuer.

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.

Links

• Server Virtualization Validation Program, http://www.windowsservercatalog.com/svvp.aspx
• Exchange 2013 Server Role Requirements Calculator v6.3, http://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780
• Ask the Perf Guy: Sizing Exchange 2013 Deployments, http://bit.ly/PerfGuyExchange2013Deployments
• ENow Monitoring und Management Suite, http://www.granikos.eu/de/Mailscape
• PRTG System Moniroting, http://www.paessler.com/prtg
• Microsoft Clustering on VMware vSphere: Guidelines for supported configurations, http://bit.ly/MSClusterOnvSphere
• Licensing Microsoft server products for use in virtual environments, http://bit.ly/ServerVirtualizationLicenseMobility
• Standard Performance Evaluation Corporation (SPEC), http://www.spec.org

Auf der Microsoft Ignite 2015 Konferenz in Chicago wurden erste Informationen über Exchange Server 2016 veröffentlicht.

Es wurde klar artikuliert, dass keine Abkehr von On-Premise Versionen geplant ist. Die Anforderungen der Microsoft Kunden werden auch in der Zukunft On-Premise Versionen von Exchange Server erforderlich machen. Wie neue Funktionen ihren Weg in die On-Premise Version von Exchange finden, hat sich aber bereits mit Exchange Server 2013 geändert. Neue Funktionen werden zuerst in Office 365 (Exchange Online) entwickelt, bereitgestellt und stabilisert. Nachfolgend wird entschieden, ob eine Funktion den Weg in die On-Premise Variante von Exchange Server findet. Microsoft beschreibt diesen Weg als "Delivering Innovation".

Das nachfolgende Schaubild verdeutlicht diesen Prozess:

Exchange Server Rollen

Jede Version von Exchange Server ging mit einer Änderung der Server Architektur einher. Mit Exchange Server 2016 lassen wir das mit mit Exchange Server 2007 eingeführte Konzept der Rollen fast komplett hinter uns. In Exchange Server 2016 exisitiert nur noch eine intere Rolle, der Mailbox Server. Hinzu kommt nur noch die Edge Rolle für den bereits bekannten Einsatz in der DMZ.

In der Mailbox Rolle sind nun alle Funktionen zusammengefasst, die in Exchange Server 2013 noch auf CAS und Mailbox aufgeteilt waren. Exchange Server 2016 nutzt eine tiefe Integration mit dem Office Web Apps Server, um in Outlook Web App 2016 eine direkte Bearbeitungsmöglichkeit für Office Dokumente anzubieten.

Die nachfolgenden beiden Schaubilder verdeutlichen die Architekturunterschiede zwischen Exchange Server 2013 und Exchange Server 2016.

Exchange Server 2013

Exchange Server 2016

Exchange Server Client Konnektivität

Mit Exchange Server 2016 ergeben sich keine grundlegenden Änderungen für die Kommunikation von Clients zum Exchange Server. Clients verbinden sich weiterhin über einen Load Balancer mit dem "Proxy" Endpunkt. Im Gegensatz zu Exchange Server 2013 kann der Proxy-Layer aber nicht mehr auf dedizierte Server installiert werden. Die Separierung von CAS und Mailbox-Rollen wurde bereits in der Preferred Architecture für Exchange Server 2013 nicht mehr empfohlen.

Exchange Server 2016 arbeitet mit einem Proxy-Layer. Dieser ist jedoch in einem Building Block auf dem Server integriert.

Auch für die Konnektivität für Unified Messaging ergeben sich keine Änderungen. Verbindungen zum Proxy-Layer werden zum direkten UM-Endpunkt umgeleitet.

Die beiden nachfolgenden Schaubilder verdeutlichen die Unterschiede in der Client Konnektivität zwischen Exchange Server 2013 und Exchange Server 2016.

Exchange Server 2013

Exchange Server 2016

Funktionen

Was bietet Exchange Server 2016 jenseits der Veränderungen in der Architektur? Die großen Themenblöcke, die Microsoft mit Exchange Server 2016 besetzen möchte sind: 

• Better Collaboration
• Smarter Inbox
• Mobile Productivity
• Modern Datacenter
• Security & Compliance

Better Collaboration

Unter dem Titel Better Collabiration soll durch die Integration von Exchange und SharePoint das Arbeiten mit Dateianhängen grundlegend verändert werden. Anstatt Office Dateien in unterschiedlichen Versionen per E-Mail zu versenden und so die Postfächer mit unnnötigen Daten zu füllen, sollen nur noch Links zu den entsprechenden Dateien versendet werden. Die Dateien werden hierzu in SharePoint bzw. OneNote for Business gespeichert. Die erforderlichen Berechtigungen zum Bearbeiten oder zur Ansicht werden für die E-Mail Empfänger automatisch vergeben. Dies ermöglicht den Anwendern, an einer Version des Dokumenten gemeinsam zu arbeiten. Diese Funktionen werden durch den Einsatz des Office Web Apps Servers ermöglicht.

Selbst mit externen Kommunikationspartnern ist solch eine Kollaboration möglich. Hier ergeben sich für Unternehmen aber auch neue Herausforderungen. Die Veröffentlichung der Funktionen und die Möglichkeit, dass externe Anwender Zugriff auf Dokumente erhalten können, erfordern eine detaillierte Planung der Infrastruktur und der notwendigen Konfigurationen.

Das nachfolgende Schaubild zeigt die erforderlichen Komponenten:

Smarter Inbox

Die Nutzung des Posteinganges unterscheidet sich grundlegend in zwei Varianten:

1. Ablegen in Ordnern
2. Stapeln im Posteingang

Es existieren zahlreiche Ratgeber zum effizienten Arbeiten mit E-Mail und dem Posteingang. Leider gibt es nicht die eine Antwort und E-mail wird aus unterschiedlichsten Gründen noch ein lange Zeit der primäre Weg der digitalen Kommunikation sein.

Exchange Server 2016 versucht mit einem intelligenteren Posteingang das Arbeiten mit Outlook zu verbessern. Hierzu gehört eine Verbesserung bei den Suchergebnissen und Beschleunigung der Suche selber. Hinzu kommt eine bessere Unterstützung für Add-Ins in Outlook.

Die neue REST API von Exchange Server 2016 erleichtert die Entwicklung von einheitlichen Add-Ins für Outlook Add-ins mit Anbindung an Exchange On-Premise oder Exchange Online.

Weitere Verbesserungen sind:

• Inline URL Vorschau
• Inline Video Player
• Intelligente Auswahl von Empfängern

Zu den OWA Verbesserungen gehören:

• Verbessertes HTML Rendering
• One-Click Archivierung
• Kontakt Verlinkung
• CSV Import von Kontakten
• Smarte Action Schaltflächen
• Verbesserte Ansicht von Dateianhängen

Mobile Productivity

Durch den immer größeren Verbreitungsgrad von mobilen Endgeräten, erfolgt auch der Zugriff auf E-Mails immer mehr von diesen Geräten. Nach einer Studie von Experian erfolgten in Q3 2014 53% aller Zugriffe auf E-Mails von Telefonen oder Tablets.

Hier ist das Ziel, eine einheitliche Erfahrungswelt über alle Gerätetypen hinweg zu schaffen. Anstatt wie in der Vergangenheit unterschiedliche Exchange ActiveSync Clients auf mobilen Endgeräten zu haben, möchte Microsoft die einheitliche Outlook Erfahrung ermöglichen. Dies wird erreicht durch:

• Outlook für Windows 10
• Outlook für iOS und Android

Modern Datacenter

Exchange Server 2016 wurde für den Betrieb in modernen Datacentern entwickelt. Dieses Anspruch wird Exchange hauptsächlich durch die vereinfachte Softwarearchitektur und die vereinfachten Hardwareanforderungen erreicht. Die Preferred Architecture für Exchange Server 2016 setzt nicht auf komplexe Virtualisierung, sondern auf den Einsatz von einfachen Standardservern und JBOD als Speichermedium.

Exchange Server 2016 soll auf Standardhardware betrieben werden und so zusätzliche Single-Point of Failures vermeiden helfen.

Die Koexistenz mit Exchange Server 2013 ist einfacher zu implementieren als die Koexistenz in vorherigen Exchange Versionen. Grund hierfür ist einfach die starke Ähnlichkeit zwischen Exchange Server 2013 und 2016.

Die automatische Reparatur von Postfachdatenbanken erhöht die Verfügbarkeit und vermindert das Risiko von Datenverlusten. Dies wird erreicht durch "DB Divergence Detection", "Loose Trunctation" und den Einsatz des ReFS Dateisystems für Datenlaufwerke.

Für ein modernes Deployment von Exchange Server 2016 stehen der Betrieb einer DAG ohne adminstrativen Endpunkt und die Unterstützung von Azure File Share Witness zur Verfügung. Unternehmen, die noch ein klassisches Backup vewenden, werden von einer DAG ohne administrativen Endpunkt nicht profitieren können, da die Hersteller von Backup-Software sich mit dieser neuen Cluster-Variante (Funktion von Windows Server 2012 R2) schwer tun. Ebenso ist die Funktion eines Azure File Share Witness nicht für alle Unternehmen möglich.

Die Indizierung der passiven Postfachdatenbanken erforderte in der Vergangenheit immer eine Kommunikation mit der aktiven Kopie. Mit Exchange Server 2016 erfolgt die Indizierung nur direkt in der passiven Kopie, was zu einer Reduzierung des Datenverkehrs führt.

Security & Compliance

Exchange Server 2016 bringt neue Funktionen zur Data Loss Prevention, zur Auditierung und zu eDiscovery. Die Informationen und Funktionen von DLP Policies stehen nun nicht nur in Outllok zur Verfügung, sondern auch in anderen Office Client Produkten und in SharePoint. Hierdurch ergibt sich eine einheitliche Erfahrung für den Anwender. DLP Policies werden somit nicht erst beim Versenden von Nachrichten angewandt, sondern bereits beim versuchten Aufrufen von Dateien.

Das Auditierungsschema wurde in Anlehnung zu Office 365 vereinheitlicht. Dies erleichtert die Auswertung der Audit/Protokolldateien in einer Hybrid-Konfiguration. Ebenso wurden die Such- und Filterfunktionen verbessert.

Neue Öffentliche Ordner können nun auch auf In-Place Hold gesetzt werden.

Ausblick

Exchange Server 2016 bietet zahlreiche neue Funktionen und Verbesserungen bekannter Funktionen. Jedoch muss man auch die kommende Version von Exchange Server 2016 als Version 1.0 eines On-Premise Produktes sehen. Durch den mit Exchange Server 2013 eingeführten Deployment Zyklus von drei Monaten, müssen sich Unternehmen auf einen schnelleren Rolloutplan einstellen. Rein technisch wird alle drei Monate ein neues Produkt eingeführt. Interne Change Prozesse rund um Exchange müssen auf die neuen Anforderungen hin angepasst werden.

Exchange Server 2016 befindet sich sich gegenwärtig noch im geschlossen TAP Programm mit ausgewählten Kunden. Die öffentliche Beta-Phase für Exchange Server 2016 ist für den Sommer 2015 vorgesehen. Als geplanter Veröffentlichungstermin für Exchange Server 2016 ist Herbst/Winter 2015 vorgesehen.

Links

• Re-Thinking Attachments: Collaborating in Outlook with OneDrive, http://channel9.msdn.com/Events/Ignite/2015/BRK2196
• Building Tenant-Wide Apps with the New Exchange REST APIs, http://channel9.msdn.com/Events/Ignite/2015/BRK3145
• Outlook on Mobile Devices, http://channel9.msdn.com/Events/Ignite/2015/BRK2148
• Exchange Server Preferred Architecture, http://channel9.msdn.com/Events/Ignite/2015/BRK3197
• Deploying Exchange Server 2016, http://channel9.msdn.com/Events/Ignite/2015/BRK3129
• High Availability and Site Resilience: Learning from the Cloud and Field, http://channel9.msdn.com/Events/Ignite/2015/BRK3125
• Exchange Hybrid: Make Office 365 Work for You, http://channel9.msdn.com/Events/Ignite/2015/BRK3139
• Auditing for Office 365, http://channel9.msdn.com/Events/Ignite/2015/BRK3126
• eDiscovery Redefined: Real Time and In-Place, http://channel9.msdn.com/Events/Ignite/2015/BRK3121

Today's virtualization options provide a wide variety to even virtualize business-critical enterprise applications. Distributed enterprise applications can easily be virtualized but require proper planning. Otherwise, you will end up with virtualized SharePoint Server Farm that does not scale well and perform badly.

This article will provide information on how to virtualize your production environment properly and will not necessarily cover development environments, as those tend to run in over-committed scenarios anyway.

The following table provides a simple overview of the SharePoint farm terminology:

Never ever start a SharePoint production deployment with a single multi-role SharePoint Server.

The following figure illustrates the architecture of a SharePoint Server 2013 environment example.

Capacity and Performance: These two key aspects are the most important aspects when you plan your SharePoint virtualization infrastructure. You need to plan for enough disk capacity to host all of the content databases and data that is cached to disk by the web server and application server roles. Your overall capacity should be planned at least for a three year period. The requirements for CPU and memory sizing of the virtual hosts depends on your server requirements. A virtual host should always be equipped to the physical maximum. If you leave CPU sockets empty, there is no guarantee that you will get the CPU for that socket in the future. The memory banks should be filled in the proper ratio per CPU as well. Otherwise, you will not be able to fully benefit from the virtualization of your servers.

Virtualizing the Load Balancer

Mostly all of the major vendors of hardware load balancers offer virtualized load balancers as well. As long as the virtual load balancer is not running on an over-committed host, and sufficient performance is provided, there is no legitimate reason to not virtualize a load balancer. 

Especially when you maintain a large virtualization platform you are heavily interested to not add additional hardware complexity to your network infrastructure by adding hardware load balancers. Any additional layer of complexity adds an additional layer for support as well.

Some of the major vendors are (purely alphabetical):

• F5, http://f5.com
• jetNEXUS, http://www.jetnexus.com
• Kemp,  http://kemptechnologies.com
• Radware, http://www.radware.com
• Riverbed, http://www.riverbed.com

Virtualizing the Web Server role

Web servers are easy to scale because web servers generally provide much better performance by adding additional CPUs and memory resources. This is the reason why the webserver role within a SharePoint deployment is the easiest to scale out. Because it is so easy to just add additional resources it is not automatically the right approach. Performance-wise you will reach a point where adding an additional web server makes more sense. This decision if you extend the resources of an existing server or add a new virtual machine depends on the overall virtualization infrastructure and the available hardware resources.

Another important topic to think about is the migration of virtual machines between hosts and the high-availability functionality of your virtualization platform. A virtual machine can be moved between virtual hosts more quickly when the virtual machine is not over-sized. The larger the assigned resources are, the more time it takes to migrate a virtual machine. You need to keep this in mind not only for migrations due to maintenance reasons or virtual hosts fail-overs. The same is true when you utilize the automatic load balancing of virtual machines.

NUMA nodes are an additional important topic. Microsoft provides dedicated information to NUMA nodes SharePoint here. Even though the article is focusing on Hyper-V, the general NUMA node requirements are valid for other hyper-visor platforms as well. As per Microsoft performance can decrease by up to 8% when a virtual machine needs to access remote memory from another NUMA node.

The proper sizing of memory resources ensures that your web servers perform as expected. You need to ensure that the webserver does not require to swap memory and make heavy use of the page file. Any use of the page file results in unnecessary disk I/O. And depending on the disk subsystem the required I/O reduces the performance dramatically. Even though the operating system supports the hot-adding of virtual memory, not all application functions make use of added virtual memory. Some components recognized available memory during the start-up of the operating system and do not adjust themselves during run time (e.g. Distributed Cache).

Your SharePoint server running the webserver role should be configured with at least:

• 2 CPU
• 8 GB Memory
• Single Volume hosting the operating system and the SharePoint Server application files

Virtualizing the Application Server role

The CPU demand of SharePoint application servers depends heavily on the applications that are running on those servers. Some applications might be more CPU resource-intensive (e.g. Search), others might be more memory intensive. To find the proper sizing for your specific requirements you need to monitor the system resources not only on a general level (e.g. System CPU usage, system memory consumption) but on a more granular level (per service, per application pool, per worker process). 

Your SharePoint server running the application server role should be configured with at least:

• 2 CPU (4 CPU, if running multiple applications on a single server)
• 8 GB Memory (16 GB, if running multiple applications on a single server)
• Single Volume hosting the operating system and the SharePoint Server application files

Virtualizing the Database Server role

The virtualization of SQL Server is a separate topic that will be covered in more detail in a separate blog article. But it would be unfair to leave this section more or less empty.

First of all, it should be said that even SQL Server can be virtualized. If virtualizing SQL Server is an option for your IT infrastructure depends on the SQL Server and data warehouse design of your company. Some companies prefer to host SQL databases in central SQL Servers serving all data applications within the company. Other companies prefer to host SQL databases on different SQL servers and group those by SQL Server SLA and/or by the type of data stored in databases.

In this example, we assume that there are three SQL Server 2012 dedicated to SharePoint in use. The following table gives a brief overview of the recommended memory sizing for SQL Server virtual machines:

SQL Server 2012 provides a new functionality called AlwaysOn Availability Groups (AAG). The AAG provides a much better experience and performance when it comes to database fail-overs. But at the same time, you need to plan resource requirements in a different way than you were used to with classic Windows Clustering capabilities. An AAG does have a primary replica of a database and many secondary (passive) replicas of the same database.

AAGs can be operated in two different availability modes:

1. Asynchronous-commit
   The primary replica commits transactions without waiting for confirmation by the secondary replicas.
   This mode is similar to high-performance mode with database mirroring.
2. Synchronous-commit
   The primary replica waits for the acknowledgment of all secondary replicas.
   This mode is similar to high-safety mode with database mirroring.

 In our example we have two different AlwaysOn Availability Groups configured:

1. AAG1: Synchronous-commit
   This AAG supports the databases for Central Administration and the SharePoint configuration databases.
   These databases do not rely so much on database performance, but we want to make sure that the data is properly protected.
2. AAG2: Asynchronous-commit
   This AAG supports all SharePoint content databases.
   We want to achieve the best performance for the content databases. 

Summary

The SharePoint 2013 farm example ends up in the following virtual host demands:

To be able to have a single virtual host in maintenance, but still have redundancy we need to plan for at least three virtual hosts. But even in this case one of the two can fail. Therefore you need to protect yourself from a failure while having on a virtual host in maintenance. The disk subsystem is connected to each host by fiber channel or iSCSI on a dedicated 10GB network.

Links

• Performance And Capacity Technical Case Studies (SharePoint Server 2010)
• Use best-practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment
• Storage and SQL Server capacity planning and configuration (SharePoint Server 2013)

Im Gegensatz zu vorherigen Versionen von Exchange Server, wo Update Rollups relative kleine Installationspakete darstellten, kommt die Installation von Cumulativen Updates (CU) bei Exchange Server 2013 faktisch einer Neuinstallation gleich. Hierdurch ergibt sich ein ganz anderer Planungsaufwand für die Durchführung eines Upgrades, sowohl in zeitlicher wie auch in ressourcentechnischer Hinsicht. Erstellen Sie sich eine zeitliche Baseline, um die erforderliche Zeit für die CU Installationen in Ihre Wartungspläne zu integrieren.

Wenn Sie auf einem Exchange 2013 Server ein CU installieren möchten, müssen die anderen Exchange Server wissen, dass ein Upgrade durchgeführt wird. Wenn Sie den entsprechenden Server nicht als "in Wartung" kennzeichnen, wird der Primary Activation Manager (PAM) der Database Availability Group (DAG) im Fehlerfall versuchen, auf dem im Upgrade befindlichen Server passiven Datenbank aktiv in Betrieb zu nehmen. Dies wird mit sehr großer Wahrscheinlich zu einem unfreiwilligen Test Ihres Desaster Recovery Plans führen.

Die folgenden Schritte beschreiben die Aktivierung und Deaktivierung der Wartung.

Vorbereitung

Vor dem Aktivieren der Wartung gilt es einige Vorbereitungen zu treffen, um unnötige Fehlersituationen des Exchange 2013 Setups zu vermeiden.

Prüfung Festplattenplatz

Auf dem Laufwerk der Exchange Server 2013 Installation, müssen ca. 10 GB freier Festplattenplatz zur Verfügung stehen. Sollte auf dem Laufwerk weniger Platz zur Verfügung stehen, müssen Sie diesen Platz zuerst sicherstellen.

Prüfung PowerShell Execution Policy

Wird auf dem Exchange Server die MachinePolicy per Gruppenrichtlinie (GPO) gesetzt, wird es beim Ausführen des Exchange Setups zu einem Fehler kommen.

Prüfung der aktuellen Konfiguration erfolgt mit Get-ExecutionPolicy -List.

Ist die MachinePolicy konfiguriert, so kann die Policy für die Installation mit folgendem PowerShell Befehl (Berechtigung vorausgesetzt) auf nicht konfiguriert gesetzt werden.

Get-ExecutionPolicy -List 
Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell -Name ExecutionPolicy -Value ""

Aktivieren der Wartung

Starten Sie die Exchange Management Shell als Adminstrator und prüfen Sie zuerst den aktuellen Status aller Serverkomponenten. Bei dieser Abfrage müssen alle Komponenten auf active stehen. Anschließend werden die Komponenten Hub Transport und UM Call Router auf Draining gesetzt. Dies Ausführung als Administrator ist erforderlich, da in den PowerShell Scripten StartDAGMaintenance und StopDAGMaintenance auch Cluster Befehle ausgeführt werden.

Get-ServerComponentState [SERVERNAME] 
Set-ServerComponentState [SERVERNAME] –Component HubTransport –State Draining –Requester Maintenance 
Set-ServerComponentState [SERVERNAME] –Component UMCallRouter –State Draining –Requester Maintenance

Verschieben Sie eventuell noch vorhandene Nachrichten im Transport Service auf einen anderen Transport Server.

Redirect-Message –Server [SOURCESERVER FQDN] –Target [TARGETSERVER FQDN]

Nach diesen Schritten wird der Server in DAG Maintenance gesetzt. Sollten Ihre DAG nur aus zwei Datenbankkopien bestehen, ergänzen Sie den Aufrud des PowerShel Scripts um den Switch Parameter -overrideMinimumTwoCopies.

cd $ExScripts 
.\StartDAGServerMaintenance.ps1 [SERVERNAME] 
Get-MailboxDatabaseCopyStatus -Server [SERVERNAME]

Setzen Sie nun alle Komponenten in serverweite Wartung.

Set-ServerComponentState [SERVERNAME] –Component ServerWideOffline –State Inactive –Requester Maintenance

Installation

Wenn alle Serverkomponeten auf Wartung gesetzt sind, kann die Installation des Cumulative Updates erfolgen. Schließen Sie die Exchange Management Shell und starten Sie ein neues PowerShell Fenster als Administrator. Wechseln Sie in das Verzeichnis des entpackten Exchange 2013 CU und starten Sie das Setup.

.\setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms

Nach Ablauf des ersten Teils der Installation werden Sie aufgefordert, den Server neu zu starten. Nach erfolgreichem Neustart und erfolgter Anmeldung, starten Sie ein neues PowerShell Fenster als Administrator, wechseln erneut in das Verzeichnis des entpackten Exchange 2013 CU und starten Sie das Setup.

.\setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms

Nach erfolgreichem Setup von Exchange ist kein erneuter Start des Servers erforderlich.

Prüfen Sie die Version der Exchange Server.

Get-ExchangeServer | ft Name, Admin*

Deaktivieren der Wartung

Nach erfolgter Installation des Exchange Server 2013 CU muss der Exchange Server aus der Wartung genommen werden, um wieder Verbindungen annehmen zu können.

Set-ServerComponentState [SERVERNAME] -Component ServerWideOffline -State Active -Requester Maintenance 
Get-ServerComponentState [SERVERNAME]

Wenn Sie die beiden Komponenten Hub Transport und UM Call Router in Draining gesetzt haben, werden diese beiden Komponenten separat wieder aktiviert.

Set-ServerComponentState [SERVERNAME] -Component UMCallRouter -State Active -Requester Maintenance 
Set-ServerComponentState [SERVERNAME] -Component HuBTransport -State Active -Requester Maintenance 
Get-ServerComponentState [SERVERNAME]

Anschließend wird die DAG Wartung beendet.

cd $ExScripts 
.\StopDAGServerMaintenance.ps1 [SERVERNAME] 
Get-MailboxDatabaseCopyStatus -Server [SERVERNAME]

Und nun heisst es warten auf das nächste CU für Exchange Server 2013.

Gerne unterstützen wir Sie bei der Planung und Umsetzung Ihrer Exchange Server 2013 Anforderungen und der Anbindung an Office 365.
Kontaktieren Sie uns: info@granikos.eu  
Erfahren Sie mehr über unsere Beratungsdienstleistungen unter http://www.Granikos.eu.

Am 24. Juli 2018 wurde die Preview Version von Exchange Server 2019 veröffentlicht. Exchange Server 2019 ist eine Weiterentwicklung von Exchange Server 2016 und somit bereits die dritte Version moderner Exchange Server. Wie schon die Vorversionen profitiert auch Exchange Server 2019 von den Entwicklungen in Office 365. Naturgemäß werden wir aber nicht alle Funktionen, die Exchange Online bietet, in der On-Premises Variante von Exchange Server zur Verfügung haben. Ebenso können wir, wie die Erfahrung der letzten beiden Versionen gezeigt hat, davon ausgehen, dass mit der Veröffentlichung der RTM Version noch nicht alle angekündigten Funktionen im Produkt aktiv sind. Vielmehr wird der Funktionsumfang mit den nachfolgenden Kumulativen Aktualisierungen stetig erweitert.

Lohnt sich ein Wechsel?

Aber was hat uns Exchange Server 2019 anzubieten und warum sollte man auf die neue Version wechseln? Werfen wir einen Blick auf die Unterschiede zwischen Exchange Server 2019 und den Vorversionen.

Exchange Server und Windows Server Core

Die wichtigste Neuerung in Exchange Server 2019 ergibt sich für den Betrieb des Produktes. Endlich ist es möglich, Exchange Server auf Windows Server Core zu betreiben. Durch den Verzicht auf eine Betriebssystemvariante mit grafischer Benutzeroberfläche (GUI) wird die potentielle Angriffsoberfläche stark reduziert. Ich empfehle den Einsatz von Exchange Server auf Windows Server 2019 Core, um die maximale Sicherheit für den Betrieb von Exchange Server zu erreichen. Diese Möglichkeit steht uns allerdings erst zur Verfügung, sobald Windows Server 2019 veröffentlicht wurde. Die aktuelle Preview Version von Exchange Server 2019 erlaubt daher die Installation auf Windows Server 2016 und Windows Server 2016 Core. Ob dies auch noch für die RTM Version von Exchange Server 2019 gelten wird, bleibt abzuwarten. Auf jeden Fall sollte Ihnen der Einsatz von Windows Server Core Varianten keine Angst machen, da Sie mit dem Windows Admin Center eine sehr gute Web-Verwaltungsoberfläche zur Verfügung haben.

Prozessor und Arbeitsspeicher

Nach der Sicherheit im Betrieb ist die Leistungsfähigkeit von Exchange Server immer wieder ein Thema. Mit jeder Produktversion hat das Exchange Team weitere Leistungssteigerungen ermöglicht. Ob Sie von diesen Verbesserungen immer profitiert haben, hängt immer davon ab, wie Sie Exchange Server implementiert haben.

Auch für Betrieb von Exchange Server 2019 gelten die Empfehlungen für die Preferred Architecture. Wie Sie sicher wissen, empfiehlt das Produkt Team den Betrieb von Exchange Server auf echter Hardware. Der Hauptgrund für diese Empfehlung ist, dass die Hochverfügbarkeit auf Applikationsebene (Stichwort DAG) realisiert ist und ein Hypervisor nur die Komplexität erhöht, ohne einen echten Nutzen zu bieten. Die nächste Version von Exchange Server unterstützt Serversystem mit bis zu 48 Prozessor-Cores und 256GB Arbeitsspeicher. Bei einem virtualisierten Betrieb von Exchange Server, unabhängig von der CPU- und Arbeitsspeicherkonfiguration, müssen Sie sowohl die Prozessor-Cores als auch den Arbeitsspeicher als fest reservierte Ressourcen konfigurieren. An dieser Anforderung ändert sich mit Exchange Server 2019 nichts.

SSD Cache-Speicher

In den letzten Jahren sind Postfächer immer größer geworden und damit auch der benötigte Festplattenspeicher. Um nun eine weitere Leistungssteigerung erreichen zu können, bietet Exchange Server 2019 einen SSD basierten Cache-Speicher an. Wie bei den HDDs kommen bei den SSDs kostengünstige Komponenten zum Einsatz, um ein gutes Kosten-/Nutzen-Verhältnis zu gewährleisten. Dieser Cache-Speicher steht in der Preview Version von Exchange Server 2019 leider noch nicht zur Verfügung.

Die Suche

Die bisher in Exchange Server verwendete Suchfunktion basierte auf der FAST-Engine und hat so manchem Exchange Administrator schlaflose Nächte bereitet. Im Blog-Artikel des Exchange-Teams wird nun die Integration einer Suchmaschine mit Bing-Technologie angekündigt. Zum einen ist es gut, die FAST-Suche loszuwerden und sich nicht mehr um korrupte Suchindizes kümmern zu müssen, zum anderen werden einige Leser sicher bei dem Begriff “Bing-Technologie” zusammenzucken. Die im Web verfügbare Bing-Suchmaschine hat, je nach Land, eine sehr unterschiedliche Wahrnehmung hinsichtlich der Qualität der Suchergebnisse. Im Zusammenhang mit Exchange Server liegt der Schwerpunkt aber weniger auf dem Wort “Bing” sondern auf dem Begriff “Bing-Technologie”. Der entscheidende Vorteil der neuen Suche ist, dass die Speicherung der Metadaten und Indizes nicht mehr in einer separaten Ordnerstruktur je Server gespeichert wird, sondern in der jeweiligen Postfachdatenbank. Damit erfolgt die Synchronisierung dieser Informationen mit Hilfe des normalen Log-Shipping-Mechanismus. Dieser technologische Kniff ermöglicht eine im Falle eines Switch- oder Fail-Overs eine noch schnellere Aktivierung einer passiven Datenbankkopie. Durch die Speicherung in der Datenbank sind die Suchinformationen somit auch automatisch Bestandteil einer Datensicherung.

Für Anwender

Als neue Funktionen für Anwender wird es hauptsächlich Änderungen im Bereich der Kalenderfunktionen und der Freigabe von Kalenderinformationen für Dritte geben. Eine wichtige Funktion, die ihren Weg aus Exchange Online zu Exchange 2019 findet, ist "DoNotForward". Mit dieser Funktion kann eine Weiterleitung einer Nachricht, und damit z.B. auch von Termineinladungen, an weitere Empfänger unterbunden werden. Zusätzlich wird die nachträgliche Konfiguration von bestehenden (Serien-)Terminen in Kalendern durch Exchange Administratoren ermöglicht. Dies ist ja gerade bei Austritten von Anwendern immer wieder ein anstrengendes Thema.

Outlook on the Web wird immer mehr zur zentralen Schnittstelle für den Zugriff auf E-Mails und funktioniert mit allen gängigen Browserversionen tadellos. Bedenken Sie bitte, dass die korrekte Nutzung aller Postfachfunktionen von Exchange Server 2019 nur gewährleistet werden kann, wenn eine aktuelle Outlook for Deskop (Windows/Mac) Version eingesetzt wird.

Was fehlt?

Keine Exchange Version ohne einen Wegfall von Funktionen. Nein, die Öffentlichen Ordner sind immer noch vorhanden.

Die Unfied Messaging Funktion, die ja bereits in den Vorversionen nicht mehr als separate Funktionsrolle zur Verfügung stand, zur Bereitstellung von VoiceMail-Funktionen, ist in Exchange Server 2019 nicht mehr vorhanden. Microsoft lässt Ihnen die Wahl, sich für eine Anbindung von Cloud VoiceMail bei gleichzeitiger Nutzung von Skype for Business Server 2019 zu entscheiden, oder eine Drittanbieter Lösung einzubinden.

Eine Alternative ist der Weiterbetrieb von Exchange Server 2016, bis diese Version das Support-Ende erreicht hat. Eine Vergleichstabelle über die Möglichkeiten zur VoiceMail-Nutzung finden Sie hier.

Weitere Informationen und Empfehlungen zum Umgang mit dem Wegfall der Unified Messaging-Funktionen wird es auf der Ignite 2018 Konferenz geben.

Koexistenz

Welche Möglichkeiten ergeben sich mit Exchange Server 2019 für die Co-Existenz der Exchange Versionen während der Transitionsphase?

Auch Exchange Server 2019 folgt dem seit Jahren bekannten N-2 Prinzip. Eine Koexistenz der aktuellen Exchange Server Version (N) ist nur mit den beiden letzten Exchange Versionen (-2) möglich. Das bedeutet, dass Sie Exchange Server 2019 nicht in einer direkten Koexistenz mit Exchange Server 2010 installieren können. Wenn Sie noch Exchange Server 2010 betreiben und auf Exchange Server 2019 wechseln möchten, müssen Sie eine Zwischenmigration über Exchange Server 2016 durchführen. Für Exchange Server 2013 ist ja seit Juni 2018 der Mainstream-Support beendet.

Weitere Informationen und Empfehlungen zur Co-Existenz wird es auch hier auf der Ignite 2018 Konferenz geben.

Zusammenfassung

Auch mit Exchange Server 2019 wird die produktinterne Hauptversionsnummer nicht hochgezählt. Die Programmversion wird als 15.2 gezählt. Böse Stimmen werden nun lamentieren, dass es sich, der alten Microsoft Notation folgend, um Service Pack 2 für Exchange Server 2013 handeln muss. Das ist natürlich nicht der Fall. Exchange Server 2019 ist ein eigenständiges Produkt.

Die Neuerungen in der Architektur und die Unterstützung von Windows Server Core versprechen einen leistungsstarken und sicheren Betrieb von Exchange Server 2019, der von den Erfahrungen im Clouddienst von Office 365 profitiert. Insbesondere die neue Suche ist ein Ergebnis aus dem betrieb einer sehr großen Exchange Umgebung.

Die Vorteile für Endanwender sind aus meiner Sicht eher Komfortverbesserungen. Ob diese alleinig einen Wechsel zu Exchange Server 2019 rechtfertigen lassen, müssen Sie entscheiden.

Ende September findet die Microsoft Ignite 2018 Konferenz in Orlando statt. Es wird eine spannende Woche mit interessanten Vorträgen zu den Neuerungen und Änderungen im Vergleich zu Exchange Server 2016 werden. Wir dürfen gespannt sein. Ich werde dort sein.

Sie haben Fragen zu Ihrer bestehenden Exchange Server Umgebung? Sie möchten auf eine neue Version von Exchange Server wechseln? Kontaktieren Sie uns. info@granikos.eu.

Mit Exchange Server 2016 wurde das Cmdlet Get-MailboxServerRedundancy eingeführt. Mit Hilfe dieses Cmdlets können Sie den Betriebsstatus der Postfach-Server einer Datenbankverfügbarkeitsgruppe (DAG) abfragen, bevor Sie einen Exchange Server in Wartung nehmen.

Leider exisitiert zu diesem Cmdlet keinerlei Hilfeinformation, weder in Microsoft Docs, noch direkt in der PowerShell per Get-Help.

Das Cmdlet verfügt eine tabellarische Standardausgabe der wichtigsten Informationen.

In der Standardausgabe werden angezeigt:

• Identity
  Name des Mitgliedsservers der DAG
   
• IsServerFoundInAD
  Hier sehen Sie, ob das zum Exchange-Server zugehöriger AD-Objekt in Active Directory exisitert
   
• IsInMaintenance
  Diese Spalte zeigt an, ob für einen Server aktuell der Wartungsmodus aktiviert ist
   
• RepairUrgency
  In dieser Spalte wird der Reparaturstatus der Postfachdatenbanken und Suchindizes angezeigt
   
• SafeForMaintenance
  In dieser Spalte zeigt das Cmdlet an, ob für einen Server In sicher der Wartungsmodus aktiviert werden kann
   
• HealthInfoLastUpdateTime
  Dies ist der Zeitstempel der letzten Aktualisierung der Health-Daten für den Server
   

Beispiel - Vor einer Wartung

Das folgende Beispiel zeigt die Informationen einer DAG mit sechs Mitgliedsservern, bevor für Server LOCEXS06 der Wartungsmodus aktiviert wird.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 09:10:11
LOCEXS02        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS03        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS06        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS05        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS04        True          False       Prohibited    False              17.02.2020 09:10:11

Als Exchange Administrator interessieren uns besonders die Spalten RepairUrgency und SafeForMaintenance.

Für keinen der sechs Server ist in diesem Screenshot der Wartungsmodus aktiv. Für die Server S01 und S04 wird angezeigt, dass beide Server nicht sicher in Wartung genommen werden können und die RepairUrgency den Status Prohibited hat.

Was ist der Grund hierfür?

Serverinformationen

Für jeden einzelnen Mitgliedsserver der DAG können Sie Einzelinformationen abfragen. Bei Abfrage der Informationen zu einem Server erhalten wir in der Standardausgabe keine ausführlicheren Informationen zum Status. 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 09:11:11

Da der Server LOCEXS01 gegenwärtig nicht sicher in Wartung genommen werden kann, interessiert uns natürlich, welcher Status genau dafür entscheidend ist.

Diese Information erhalten Sie über die Abfrage der Detailinformationen des gewünschten Servers.

Detailinformationen

Die Detailinformationen erhalten Sie einfach durch die Ausgabeformatierung mit Format-List oder kurz FL.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 | FL

RunspaceId                                  : 70d82f8d-e6ca-4bfc-863f-11300a9784ff
Identity                                    : LOCEXS01
IsServerFoundInAD                           : True
IsInMaintenance                             : False
RepairUrgency                               : Prohibited
SafeForMaintenance                          : False
ServerContactedFqdn                         : LOCEXS04.VARUNAGROUP.DE
HealthInfoCreateTime                        : 15.06.2018 15:16:19
HealthInfoLastUpdateTime                    : 17.02.2020 09:11:11
ServerFoundInAD                             : CurrentState: Active; LastActiveTransition: 15.06.2018 15:22:16;
                                              LastInactiveTransition:
InMaintenance                               : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02;
                                              LastInactiveTransition: 17.01.2020 10:42:02
AutoActivationPolicyBlocked                 : CurrentState: Inactive; LastActiveTransition: 09.01.2020 10:14:50;
                                              LastInactiveTransition: 09.01.2020 11:00:51
ActivationDisabledAndMoveNow                : CurrentState: Inactive; LastActiveTransition: ; LastInactiveTransition:
                                              15.06.2018 15:22:16
HighAvailabilityComponentStateOffline       : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02;
                                              LastInactiveTransition: 17.01.2020 10:42:02
CriticalForMaintainingAvailability          : CurrentState: Inactive; LastActiveTransition: 31.01.2020 16:52:49;
                                              LastInactiveTransition: 31.01.2020 16:56:49
CriticalForMaintainingRedundancy            : CurrentState: Active; LastActiveTransition: 29.01.2020 11:43:06;
                                              LastInactiveTransition: 29.01.2020 11:42:06
PotentiallyCriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 01.02.2020 05:49:37;
                                              LastInactiveTransition:
CriticalForRestoringAvailability            : CurrentState: Inactive; LastActiveTransition: 06.05.2019 09:16:36;
                                              LastInactiveTransition: 06.05.2019 09:20:36
CriticalForRestoringRedundancy              : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06;
                                              LastInactiveTransition: 29.01.2020 11:43:06
HighForRestoringAvailability                : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06;
                                              LastInactiveTransition: 29.01.2020 11:43:06
HighForRestoringRedundancy                  : CurrentState: Inactive; LastActiveTransition: 10.02.2020 09:05:02;
                                              LastInactiveTransition: 10.02.2020 09:06:02
IsSafeForMaintenance                        : CurrentState: Inactive; LastActiveTransition: 03.11.2019 09:42:35;
                                              LastInactiveTransition: 12.11.2019 06:29:58
IsValid                                     : True
ObjectState                                 : Unchanged

Interessant sind die Information in den Zeilen 24-27. Der CurrentState-Wert für die Status-Parameter CriticalForMaintainingRedundancy und PotentiallyCriticalForMaintainingRedundancy ist für beide Active. Das bedeutet, dass der Primary Activation Manager (PAM), zuständig für die Aktivierung von Datenbanken innerhalb der DAG, die Verfügbarkeit dieses Servers als kritisch einstuft, um die Verfügbarkeit der auf diesem Server konfigurieren Datenbankenkopien zu gewährleisten.

Für jeden Status-Parameter werden drei Informationen angezeigt:

• CurrentState
  Dieser Wert gibt den aktuellen Status an
   
• LastActiveTransition
  Dieser Zeitstempel gibt an, wenn der Wert zum letzen Mal auf Active gewechselt ist
   
• LastInactiveTransition
  Dieser Zeitstempel gibt an, wenn der Wert zum letzen Mal auf Inactive gewechselt ist

Warum werden im Regelbetrieb zwei Server als nicht sicher für die Wartung angezeigt?

Der Grund hierfür ist recht simpel. Die auf den sechs Servern eingebunden Postfachdatenbanken werden aus Kapazitätsgründen mit einer unterschiedlichen Anzahl an Datenbankkopien betrieben. Die Datenbanken für Standardpostfächer werden mit jeweils vier Kopien betrieben, die gleichmäßig über alle sechs Server verteilt sind. Die Datenbanken für Archivpostfächer wiederum werden mit je drei Kopien je Postfachdatenbank betrieben. Mit diesen beiden Szenarien ist es jederzeit möglich, einen Exchange Server sicher in Wartung zu nehmen, ohne die Redundanz der Postfachdatenbanken zu gefährden.

Auf den Servern LOCEXS01 und LOCEXS04 sind jedoch auch Postfachdatenbanken eingebunden, die nur mit je zwei Kopien betrieben werden. Einen dieser beiden Server in Wartung zu nehmen würde bedeuten, dass während der Wartung keine Redundanz von Datenbanken mehr vorhanden ist. Dies ist der Grund, warum uns der PAM über das Cmdlet mitteilt, dass wir diese beiden Server nicht sicher in Wartung nehmen können.

Beispiel - Während einer Wartung

Das folgende Beispiel zeigt den Betriebszustand der Mitgliedsserver der DAG, während der Server LOCEXS06 in Wartung ist. Auf dem Server wurden zu diesem Zeitpunkt die monatlichen Windows Updates installiert.

Der Exchange Server wurde mit Hilfe des PowerShell-Skriptes StartDagServerMaintenance.ps1 in Wartung genommen.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS02        True          False       Normal        True               17.02.2020 11:04:12
LOCEXS03        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS06        True          True        High          True               17.02.2020 11:04:12
LOCEXS05        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS04        True          False       Prohibited    False              17.02.2020 11:04:12

Wenn sich ein Server innerhalb der DAG in Wartung befindet, wirkt sich dies natürlich auch auf die verbleibenden Server aus. Weitere zwei Server (LOCEXS03 und LOCEXS05) können nicht sicher zusätzlich in Wartung genommen werden, da ansonsten die redundante Verfügbarkeit der Postfachdatenbanken nicht mehr gewährleistet ist.

Beispiel - Nach einer Wartung

Der durchgeführter Installation der Windows Updates oder eines Kumulativen Updates, wird die Wartung des Servers mit StopDagServerMaintenance.ps1 wieder beendet. 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 11:23:12
LOCEXS02        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS03        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS06        True          False       High          True               17.02.2020 11:23:12
LOCEXS05        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS04        True          False       Prohibited    False              17.02.2020 11:23:12

Der Server ist zwar nicht mehr im Wartungsmodus, jedoch ist der Status der RepairUrgency weiterhin auf High, da die Exchange Replication Engine damit beschäftigt ist, die während der Wartung aufgelaufenen Protokolldateien einzuspielen und die Suchindizes zu aktualisieren.

Tipp

• Wenn Sie für einen Exchange Server, der nicht sicher in Wartung genommen werden kann, den Wartungsmodus mit StartDagServerMaintenance.ps1 -serverName [SERVER] aktivieren möchten, wird es zu einer Fehlermeldung kommen.

  In diesem Fall müssen Sie den Wartungsmodus mit folgendem Aufrauf aktivieren

.\StartDagServerMaintenance.ps1 -serverName SERVERNAME -overrideMinimumTwoCopies:$true

Viel Spaß mit Exchange Server!