Bevor ich darauf eingehe, was die Funktionen der Managed Availability von Exchange Server sind, müssen wir uns zuerst die Architektur von Exchange Server in Erinnerung rufen.
Exchange Server ist für eine hochverfügbare und ausfallsichere Bereitstellung von Postfachdiensten und Nachrichtentransport entwickelt worden. Die Basis hierfür sind die Datenbankverfügbarkeitsgruppen (DAG), Shadow Redundancy, SafetyNet und weitere Komponenten. Ebenso spielen ein korrektes Active Directory Site Design und eine Implementierung entsprechend der Exchange Server Preferred Architecture eine wichtige Rolle.
Sie können Exchange Server in einer Einzelserver-Installation betreiben, jedoch ist dies nicht das optimale Betriebsszenario für Exchange. Es ist, als würden Sie einen Sportwagen mit angezogener Handbremse fahren.
Exchange Server ist für den Betrieb einer DAG mit mehreren Servern entworfen worden. Für die Sicherstellung der Ausfallsicherheit und der Hochverfügbarkeit kommt nun die Funktion der Managed Availability ins Spiel.
Die Funktion Managed Availability ist Bestandteil der Exchange Server Funktionen zur Hochverfügbarkeit (HA) und ist ein Exchange-internes Überwachungssystem für Exchange Funktionalitäten, das automatisch Aktionen zur Sicherstellung einer positiven Anwendererfahrung auslöst.
Hierbei wird die Erreichbarkeit der einzelnen Verbindungsendpunkte für Anwender getestet. Diese Funktionstests werden kontinuierlich ausgeführt. Um diese Tests durchführen zu können, nutzt Exchange Server spezielle Postfächer, die sog. Health Mailboxen. Diese Postfächer und die dazugehörigen Benutzerkonten sind in vollständiger Kontrolle von Exchange Server. Jede Postfachdatenbank einer modernen Exchange Server Version verfügt über individuelle Health Mailboxen für die Managed Availability. Weitere Endpunkte, die nicht von Exchange bereitgestellt, aber von jedem Exchange Server benötigt werden, sind die Domain Controller und DNS-Server. Auch diese Endpunkte werden durch die Managed Availability getestet.
Ebenso wird die Antwortzeit der einzelnen Endpunkte durch die Managed Availability gemessen. Diese Antwortzeiten (Latenz) sind ein Indikator dafür, ob ein Verbindungsendpunkt die Performance bietet, um Anwendern eine gute Erfahrung zu bieten.
Zusätzlich zur Erreichbarkeit und der Latenz der Client-Endpunkte wird auch die Funktionalität getestet. Als Beispiel sei hier die korrekte Indizierung einer E-Mail-Nachricht, nach dem Empfang im Postfach einer Health Mailbox, genannt. Hierdurch stellt die Managed Availability fest, ob die Suche im Postfach fehlerfrei funktioniert.
Ist nun ein Endpunkt nicht erreichbar, sind die Antwortzeiten eines Endpunktes zu lang oder treten bei einem Funktionstest Fehler auf, löst die Managed Availability automatisch Aktionen aus, um eigenständig wieder einen optimalen Betriebszustand zu erreichen.
Die Kernkomponenten der Managed Availability sind der Exchange Health Manager Service und der Exchange Health Manager Worker Prozess. Der Health Manager Service hat die Aufgabe, den Health Manager Worker Prozess zu steuern und zu kontrollieren. So wird sichergestellt, dass ein Fehler bei der Ausführung des Worker Prozesses nicht zu einer grundsätzlichen Störung der Managed Availability führt.
Die Managed Availability verwendet Proben, um Informationen über einzelne Komponenten zu sammeln und Messungen durchzuführen. Ein Exchange Server verfügt über hunderte von Proben, die in einzeln definierten Intervallen ausgeführt werden. Den Status der Proben, und damit auch des Servers, können Sie im Rahmen der Health-Cmdlets abfragen.
Die gesammelten Informationen und Messungen werden von der Monitoring-Komponente ausgewertet. In dieser Komponente ist die Business-Logik implementiert, um Informationen und Messungen auszuwerten. Sollte das Monitoring ein Problem feststellen, entscheidet die Responder-Definition darüber, ob eine Administrator-Eskalation oder eine direkte Responder-Aktion ausgelöst wird.
Das folgende Schaubild verdeutlicht den Aufbau der Managed Availability Komponente mit Probe Engine, Monitor und Responder.
Unter einer Administrator-Eskalation dürfen Sie sich nun keine direkte Benachrichtigung der Exchange Administratoren vorstellen. Es wird ein entsprechender Eintrag in der Ereignisprotokollierung vorgenommen, den Sie mit einem System-Monitoring Tool überwachen müssen.
Wesentlich interessanter sind die automatischen Aktionen, die ein Responder ausführt. Kommt es z.B. bei der Prüfung von Outlook on the Web zu einem fehlerhaften Verhalten, durchlaufen die Responder-Aktionen mehrere Stufen, um wieder eine einwandfreie Exchange Funktion herzustellen. Als erste Reaktion wird der OWA-Applikationspool des betroffenen Exchange Servers neu gestartet. Hilft dieser Neustart des Applikationspools nicht, so führt die Managed Availability einen Neustart des W3SVC-Dienstes durch. Verbessert sich das Fehlerbild von Outlook on the Web nicht, führt die Managed Availability einen Neustart des Servers durch. Dieser Neustart des Servers wird allerdings nicht als regulärer Neustart durchgeführt, sondern per Bug-Check als harter Neustart.
Wenn Sie sich auf einem Exchange Server per Remote Desktop anmelden und einen Dialog erhalten, dass der letzte Shutdown unerwartet durchgeführt wurde, sollten Sie auf jeden Fall die Einträge der Managed Availability in den Crimson Channel Ereignisprotokollen prüfen.
Exchange Server unterstützt für einige der Proben die Möglichkeit einer Anpassung der Konfiguration. Diese Anpassung erfolgt als lokale oder globale Managed Availability Overrides. Lokale Overrides gelten für einen Server, während globale Overrides sich auf mehrere Server auswirken.
Der entscheidende Vorteil der Managed Availability ist, dass Exchange Server sich selbst überwacht und so selbständig für eine hochverfügbare Bereitstellung der Exchange Funktionalitäten sorgt. Dies kann die Managed Availability aber nur, wenn Sie eine Exchange DAG Umgebung betreiben und den Implementierungsempfehlungen der Exchange Produktgruppe folgen. Moderne Exchange Server Versionen wurden dazu entwickelt, eigenständig die Hochverfügbarkeit der Applikation sicherzustellen. Exchange Server kennt andere HA-Komponenten Ihrer IT-Infrastruktur nicht und verlässt sich auch nicht auf diese. Moderne Exchange Server Version ab Version 2013 können mit Standard-Hardware und Standard-Speichermedien betrieben werden. Die Managed Availability sorgt im Zusammenspiel mit den HA-Funktionen einer Datenbankverfügbarkeitsgruppe für eine hochverfügbare Bereitstellung von Exchange Funktionen.
Fehler treten nie während der regulären Arbeitszeiten von Exchange Administratoren auf. Probleme und Fehler haben naturgemäß die Eigenart, nachts und an Wochenenden einzutreten. Wenn Sie einen ruhigen Schlaf bevorzugen, ist die Managed Availability genau das Mittel der Wahl.
Viel Spaß mit Exchange Server.
Mailscape 365 - Überwachung von Hybrid Exchange und Office 365: Viele Unternehmen verwenden eine lokale Exchange Organisation und Exchange Online in einer Hybrid-Konfiguration, um die Anforderungen ihrer Mitarbeiter zu erfüllen. Der Betrieb einer hybriden Exchange Organisation seine ganz eigenen Herausforderungen für das Monitoring der Dienstverfügbarkeiten. Beginnen Sie noch heute einen unverbindlichen 14-Tage Test von Mailscape 365.
Das Blog Cumulative Update für Juni 2020 (CU0620) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Microsoft Teams und Azure des Monats Juni 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
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:
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?
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.
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:
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.
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.
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.
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!
Vom 4. - 8. November fand die diesjährige Microsoft Ignite Konferenz statt. Ein großes Thema war die Absicherung von Identitäten und Applikationen und die sichere Zusammenarbeit im Rahmen von Modern Workplace und Modern Life.
Die folgenden Liste bietet einen Überblick über die wichtigsten Sessions zum Thema Azure Active Directory. Der jeweilige Link führt Sie zu den detaillierten Session-Informationen, inklusive der Session-Aufzeichnung und PowerPoint-Präsentation, falls vorhanden. Hinter jedem Titel ist der Themenlevel für die Zielgruppe vermerkt.
Intermediate (200)
Foundational (100)
Advanced (300)
Expert (400)
TK = Technical Keynote WRK = Workshop Session THR = Theater Session (20 Minuten) BRK = Breakout Session (45 Minuten) SECO = Session (45 Minuten)
Viel Spaß mit Microsoft 365 und Azure Active Directory.
Sie benötigen Hilfe bei der Entscheidung für oder gegen einen Wechsel zu Office 365 oder Microsoft 365? Unser Microsoft Cloud Workshop hilft Ihnen, die für Ihr Unternehmen passenden Entscheidungen zu treffen. Melden Sie sich bei uns: info@granikos.eu
Am 14. Februar 2019 wurde das Exchange Server 2019 Cumulative Update 1 zum Download veröffentlicht. Mit dieser Veröffentlichung wurde nun auch die lange erwartete Anleitung zur Konfiguration der Meta Cache Datenbank (MCDB) auf Microsoft Docs bereitgestellt.
Die Funktion der MCDB ist eine optionale Funktion für den Betrieb von Datenbankverfügbarkeitsgruppen (DAG). Die Konfirguation der MCDB bietet eine Leistungssteigerung im Zugriff auf Exchange-Postfächer und die Exchange-Suche. Der Einsatz ist besonders dann anzuraten, wenn Sie große Festplatten für die Speicherung ebenso großer Postfachdatenbanken verwenden.
Die wichtigsten Voraussetzungen für die Nutzung der MCDB-Funktion in einer Exchange Server 2019 DAG sind:
Die Anforderung, dass die DAG für Auto-Reseed konfiguriert sein muss, macht die MCDB-Funktion nur für entsprechend konfigurierte Exchange Server Umgebungen attraktiv. Auto-Reseed wird meistens bei physikalisch betriebenen Exchange Servern verwendet, weniger mit virtualisierten Exchange Server-Systemen.
Planen Sie den Einsatz der MCDB sorgsam und folgenden Sie unbedingt den Microsoft Empfehlungen hinsichtlich der SSD-Typen, um unnötige Betriebsrisiken und Kosten zu vermeiden.
Empfehlenswert ist auch die Aufzeichnung der Breakout Session BRK3130 von der Ignite 2018. In dieser Session werden die Vorteile der MCDB-Funktion im Hinblick auf die neue Suche BigFunnel erläutert.
Wenn Sie die MCDB-Funktion für Ihre Exchange Server 2019 DAG aktivieren, möchte ich Sie einladen, mir Ihr Feedback mitzuteilen: thomas@mcsmemail.de
Viel Spaß mit Exchange Server 2019!
Das Blog Cumulative Update für September 2017 (CU0917) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Azure und Skype for Business (aka Lync) des Monats September 2017 zusammen.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform.
Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop.
Das Exchange Blog Cumulative Update (CU1014) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online) des Monats Oktober 2014 zusammen.
Gerne unterstützten wir Sie bei der Planung und Durchführung Ihrer Exchange Server Installation. Sie denken über eine Migration zu Office 365 nach? Wir beraten Sie umfassend über die Möglichkeiten der Office 365 Hosting Plattform. Nehmen Sie mit uns Kontakt auf: info@granikos.eu