Schön, dass Sie sich für dieses Buch entschieden haben!
Exchange ist seit Jahren die Standard-Software für E-Mail und Zusammenarbeit. Mit Exchange Online als Angebot in Office 365 hat sich der Marktanteil zwar zugunsten der Cloud-Lösung verringert, aber es gibt noch immer Anforderungen, die nur die lokal betriebene Variante der Software erfüllen kann, z.B. im Bereich der Compliance oder der Integration mit selbst entwickelten Applikationen.
Schon lange habe ich mit dem Gedanken gespielt, mein Wissen, das sich über die letzten 18 Jahre zum Thema angehäuft hat, in einem Buch zur Verfügung zu stellen. Seit einigen Jahren schreibe ich zwar bereits Blog-Artikel für den Microsoft-Learning-Partner, für den ich auch unterrichte (unter https://www.digicomp.ch/blog/tag/exchange), aber diese können immer nur jeweils einen Aspekt abdecken. In diesem Buch bietet sich die Möglichkeit, den ganzen Prozess von Design über Installation, Konfiguration bis Fehleranalyse aufzuzeigen und praxisnahe Tipps zu vermitteln.
Meine IT-Karriere begann vor 19 Jahren als System Engineer bei einer Privatbank in Zürich, wo ich vor allem für die Migration der NT4-Domäne zu Active Directory und der Exchange-5.5-Umgebung zu Exchange 2003 zuständig war. Zur selben Zeit konnte ich meine ersten Zertifizierungsprüfungen zum Microsoft Certified Systems Engineer bestehen. Da ich immer gerne Wissen vermittelt habe, war der Schritt zum zertifizierten Trainer nur logisch. Nach einer Anstellung bei einer weiteren Privatbank bin ich schlussendlich bei einem IT-Dienstleister gelandet, für den ich die letzten zehn Jahre viele Projekte durchführen konnte – die meisten davon Migrationen und Fehleranalysen von Exchange-Umgebungen. Mein Arbeitgeber ermöglichte es mir auch, die höchste Zertifizierung in diesem Bereich, den Microsoft Certified Master für Exchange zu erlangen. Trotz meiner Affinität zu Exchange habe ich auch viele andere Themen abgedeckt, darunter Active Directory, Loadbalancing, Federation Services, Office 365 und einige mehr. Die Breite meines Wissens hat mir in vielen Fällen die Fehlersuche massiv erleichtert. Ich hoffe, dass ich Ihnen einen Teil dieses Wissens in diesem Buch weitergeben kann.
Dieses Buch ist sowohl für System Engineers gedacht, die Exchange 2019 in ihrem Betrieb oder für Kunden umsetzen wollen, als auch für Systemadministratoren, die eine einmalige Migration durchführen müssen oder Tipps für die Fehlersuche benötigen. Vorwissen im Bereich Exchange ist nicht nötig, Grundkenntnisse in Serverbetriebssystemen, Netzwerk- und Speichertechnologien sowie Sicherheitskonzepten sind hingegen durchaus hilfreich für das Verständnis.
Das Buch ist so gegliedert, dass es dem Ablauf eines Exchange-Projekts entspricht. So können Sie ganz einfach und Schritt für Schritt in die praktische Anwendung der Software einsteigen.
In Kapitel 1 stelle ich Ihnen kurz die Geschichte von Exchange vor und gebe einen Überblick über die Neuerungen im Produkt.
Kapitel 2 zeigt Ihnen die Schritte auf, die nötig sind, um ein Design für Exchange zu entwerfen. Ich zeige Ihnen, welche Komponenten benötigt oder optional hinzugefügt werden können und welche Technologie-Entscheidungen gefällt werden müssen – zum Beispiel für Virtualisierung oder Speicher.
In den meisten Szenarien, in denen Sie einen Exchange-2019-Server installieren, wird schon ein Vorgänger-Produkt vorhanden sein. In Kapitel 3 beschreibe ich deshalb beispielhaft den Ablauf einer Migration von Exchange 2016.
Kapitel 4 befasst sich mit der Installation des Produkts – egal ob in einer neuen Umgebung oder im Rahmen einer Migration, wie im vorhergehenden Kapitel beschrieben.
Nach der erfolgreichen Installation von Exchange behandle ich im Kapitel 5 die Konfiguration der Komponenten wie Postfachdatenbanken, Database Availability Groups und virtuelle Verzeichnisse.
In Kapitel 6 erkläre ich den Verwendungszweck verschiedener Empfängerobjekte wie Postfächer, Verteiler oder Kontakte sowie die Verwaltung der Einstellungen dieser Objekte.
Kapitel 7 behandelt die Aspekte der Kernaufgabe von Exchange: den Versand und Empfang von Nachrichten. Zusätzlich zeige ich Ihnen die Möglichkeiten zur Reduktion von Spam, also ungewollter Nachrichten, auf.
Exchange muss wie jede andere Software auch gewartet werden. Die Schritte dazu zeige ich Ihnen in Kapitel 8. Neben dem Wartungsmodus ist auch der Austausch von Zertifikaten ein Thema.
In Kapitel 9 erläutere ich die Möglichkeiten, Exchange zu sichern und wiederherzustellen. Informationen, die Sie hoffentlich nie brauchen werden, aber immer zur Hand haben sollten.
Kapitel 10 enthält eine nach Komponenten strukturierte Sammlung von häufigen Fehlern und deren Lösung. Diese können Sie als Nachschlagewerk für konkrete Probleme verwenden, oder auch nur, um Ideen für die Fehleranalyse in anderen Themen zu finden.
Wenn man jahrelang mit einem Produkt arbeitet, vergisst man leicht, dass Abkürzungen und Begriffe nicht jedem Publikum geläufig sind – ich bemerke das jeweils während meiner Kurse. Aus diesem Grund befindet sich am Ende des Buches noch ein umfangreiches Glossar mit wichtigen Begriffen zum Nachschlagen.
Das Buch ist gespickt mit Kästen mit den Titeln Vorsicht, Wichtig, Hinweis, Tipp und Beispiel. Darin finden Sie Informationen aus der Praxis, die Ihnen hoffentlich die gleichen Steine, über die ich in meinen Projekten gestolpert bin, ersparen.
Im Laufe der Zeit bin ich im Internet auf zahlreiche Artikel gestoßen, die fehlerhafte oder veraltete Informationen beinhalten. Ich möchte Ihnen deshalb ein paar verlässliche Quellen angeben:
Der Exchange Team-Blog ist die beste Quelle, obschon sich in letzter Zeit eine große Zahl von Artikeln mit Exchange Online beschäftigen (https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/bg-p/Exchange).
msxfaq ist eine der umfangreichsten deutschsprachigen Websites zu den Themen Exchange, Office 365 und Skype for Business (https://www.msxfaq.de/).
Frankys Web ist ebenfalls eine deutsche Seite mit sehr guten und aktuellen Informationen (https://www.frankysweb.de).
Zu den besten englischsprachigen Büchern zu Exchange gehören die bei Microsoft Press erschienenen Titel Microsoft Exchange Server 2013 Inside Out : Connectivity, Clients and UM (Paul Robichaux) sowie Microsoft Exchange Server 2013 Inside Out : Mailbox and High Availability (Tony Redmond). Der Inhalt musste auf zwei Bücher verteilt werden – so umfangreich ist er. Zwar ist Exchange 2013 nicht mehr taufrisch, aber viele der Konzepte in der aktuellen Version haben sich nicht grundlegend verändert.
Da Sie sich ein Buch über Microsoft Exchange gekauft haben, werden Ihnen der Einsatzbereich und die Funktionen zumindest in den Grundzügen schon bekannt sein. Trotzdem möchte ich kurz einen Überblick geben. Exchange ist Microsofts E-Mail- und Collaboration-Produkt. Als solches bietet es natürlich den Empfang, die Speicherung und den Versand von Nachrichten an. Sie können in den Postfächern der Benutzer aber noch andere Daten als E-Mails speichern: zum Beispiel Kontakte, Kalender, Aufgaben und Notizen.
Abb. 1.1: Ordner mit verschiedenen Objekten in Outlook
Diese anderen Objekte kann Outlook prinzipiell zwar auch ohne Anbindung an Exchange verwalten – aber genau hier liegen die Vorteile des Produkts: Sie können Kontakte, Kalender und andere Informationen teilen und gemeinsam verwalten. Ein paar Beispiele:
Sie können Kollegen zu einem Termin einladen und vorher die Verfügbarkeit in deren Kalendern überprüfen.
Kontakte von externen Partnern können Sie in öffentlichen Ordnern oder freigegebenen Postfächern ablegen statt in den individuellen Postfächern. Dadurch stehen sie allen Mitarbeitern zur Verfügung.
Wenn Sie Exchange mit Skype for Business zusammen verwenden, sehen Sie den Anwesenheits-Status eines Mitarbeiters in Outlook. Diese Information kann unnötige E-Mails vermeiden.
Freigegebene Postfächer können mehreren Benutzern angezeigt werden. Empfangene E-Mails können dann im Team bearbeitet werden.
Exchange bietet den Zugriff auf das Postfach nicht nur über Microsofts eigenen Client Outlook, sondern auch über Webbrowser, POP3- oder IMAP4-fähige Applikationen und Mobiltelefone. Außerdem erlaubt Exchange Web Services (EWS) den Zugriff auf Postfachdaten durch Applikationen, wie zum Beispiel Systeme für die Besetzt-Anzeige von Sitzungszimmern. Exchange Web Services erlauben auch den Skype-for-Business- oder Teams-Clients, anhand der Kalendereinträge in dem Postfach des Benutzers deren Anwesenheits-Status anzupassen.
Abb. 1.2: Anzeige von Kalendereinträgen und Status über Exchange Web Services
Ich werde in den folgenden Kapiteln dieses Buches darauf eingehen, welche Funktionen Ihnen den Arbeitsalltag erleichtern.
Um ein Produkt mit seinen Eigenschaften, seinen Vor- und auch Nachteilen zu verstehen, ist es hilfreich, die Geschichte dahinter zu kennen. Deshalb werfe ich in diesem Abschnitt einen kurzen Blick in die Vergangenheit.
Die erste Version von Exchange wurde 1996 von Microsoft veröffentlicht. Zwar gab es ein Vorgängerprodukt namens Microsoft Mail, aber dieses war aufgrund der Limitationen noch kein konkurrenzfähiges Produkt für größere Kunden. Gleichzeitig mit der Veröffentlichung begann auch die Entwicklung der Version 4.1 respektive 4.5. Das Protokoll für den Versand von Nachrichten war damals noch X400 und das Directory für Konfiguration und Empfängerobjekte X500.
In den zwei folgenden Jahren nach dem ersten Wurf kamen Exchange 5.0 und 5.5 auf den Markt. Herausragende Funktionen waren der »Internet Mail Connector«, der die Kommunikation mit dem heute vorherrschenden Protokoll SMTP (Simple Mail Transfer Protocol) erlaubte und die Einführung des webbasierten Zugriffs, der damals noch Exchange Web Access hieß und heute als OWA (Outlook Web Access) bekannt ist. Die Version 5.5 brachte außerdem Support für Datenbankgrößen über 16 GB.
Die im Jahr 2000 veröffentlichte Version verwendete Active Directory als Speicherort für die Konfiguration, anstatt auf einen eigenen Verzeichnisdienst zu setzen. Der Preis dafür war natürlich auch die Abhängigkeit von Active Directory. Interessant war auch die Einführung einer Instant-Messaging-Funktion, die später aber in ein eigenes Produkt überging, den Live Communication Server – Vorgänger von Lync respektive Skype for Business.
In der Version 2003 integrierte Microsoft den Zugriff von mobilen Telefonen erstmals in Exchange. Vorher war ActiveSync clientseitig implementiert und erforderte eine Synchronisation zwischen den Endgeräten des Benutzers, also zum Beispiel Computer oder Notebook mit dem Mobiltelefon. Einen weiteren Meilenstein stellte der Cache-Modus für Outlook dar, der es mobil Arbeitenden möglich macht, ohne Netzwerkverbindungen auf die Postfachdaten zuzugreifen, und zusätzlich auch den Server entlastet. Dazu kam ein neues Protokoll für die Anbindung der Clients über das Internet ohne zusätzliche VPN-Verbindung: RPC/HTTP, später auch als Outlook Anywhere bekannt. Ebenfalls neu war die Möglichkeit, rudimentäre Anti-Spam-Filter einzusetzen.
Nachdem Exchange 2003 veröffentlicht worden war, wurden viele Ideen für den Nachfolger geboren und wieder verworfen. Eine davon war die Abkehr von der bewährten ESE-Datenbank-Engine zugunsten von SQL. Nach vielen Tests kam das Team aber zum Schluss, dass sich dieser Schritt nicht lohnte: ESE war schon zu sehr für die Anwendung in Exchange optimiert und brachte deshalb bessere Leistung. Das Gerücht, Microsoft wolle Exchange auf SQL portieren, hält sich aber seit damals hartnäckig.
Highlights in Exchange 2007 waren die neuen Optionen für höhere Verfügbarkeit: Local Continuous Replication (LCR), Standby Continuous Replication (SCR) und Cluster Continuous Replication (CCR). Dabei wurde im Gegensatz zu den Vorgängern, die nur herkömmlichen Microsoft Cluster unterstützten, der Storage als Single Point of Failure eliminiert. Mithilfe von Replikation der Transaktionsprotokoll wurden unabhängige Datenbankkopien geschaffen – damit war diese Funktion der Vorläufer der heute noch verwendeten Database Availability Group (DAG).
Exchange 2007 war auch die letzte Version, die noch auf 32-Bit-Betriebssystemen lauffähig war – wenn auch nur für Testing. Produktive Installationen wurden nur auf 64-Bit-Windows-Servern unterstützt.
Was im direkten Vorgänger als guter Ansatz für bessere Verfügbarkeit erkennbar war, wurde in Exchange 2010 stark verbessert. Die Database Availability Groups und die RPC-Clientzugriffsdienste, die den Zugriff auf das Postfach über eine abstrahierende Schicht ermöglichten und damit das Loadbalancing vereinfachten, machten Hochverfügbarkeit auch für kleinere Umgebungen praktikabel.
Da Exchange als sehr anspruchsvoll im Bereich Storage galt, unternahm Microsoft Anstrengungen, die Anforderungen an das Disk-Subsystem zu reduzieren. Änderungen in der Datenbankstruktur und dem Cache ermöglichten eine Einsparung von IOPS von ca. 70% gegenüber der Version 2007 und sogar 90% gegenüber Exchange 2003. Allerdings fiel der Single Instance Store (Deduplizierung der Datenbank auf Mail-Ebene) diesen Verbesserungen zum Opfer.
In Exchange 2010 wurde auch das missverstandene Feature In-Situ-Archivierung eingeführt. Ursprünglich gedacht zur Verkleinerung der lokalen OST-Datei auf dem Client, wollten viele Kunden damit teuren SAN-Speicherplatz einsparen.
In Exchange 2013 wurde mehrheitlich an der Architektur von Exchange 2010 festgehalten. Eine maßgebliche Änderung war die Reduktion der Rollen – die Hub-Transport- und die Unified Messaging-Rolle lassen sich nicht mehr dediziert installieren. Ebenfalls wurden die öffentlichen Ordner modernisiert und Data Loss Prevention eingeführt.
Der Clientzugriff wurde für alle Protokolle weiter vereinfacht, was auch Planung und Konfiguration des Loadbalancings simpler gestaltet.
Exchange erhielt einen Service, der nicht nur eine Selbstüberwachung erlaubte, sondern auch Recovery-Aktionen ausführen konnte – vom Restart einzelner Anwendungspools in IIS bis hin zum Reboot eines Servers.
Exchange 2013 ist auch die erste Exchange-Version mit integriertem Virenschutz. Dieser ist aber äußerst einfach gehalten und lässt wenige Konfigurationsoptionen zu. Erwähnenswert ist die Einführung von sogenannten kumulativen Updates oder kurz CU (von engl. cumulative updates). Dabei handelt es sich um vierteljährlich erscheinende Aktualisierungen, die immer eine komplette Installation darstellen und sowohl bekannte Probleme beheben als auch neue Funktionen beinhalten. Sie ersetzen das System von kleinen, häufigeren Rollup-Updates und großen Service Packs.
Oft als Service Pack für Exchange 2013 betitelt, handelt es sich bei Exchange 2016 jedoch um ein eigenständiges Produkt. Die Reduktion der Rollen wurde weiter vorangetrieben und lässt nur noch zwei Optionen zur Installation zu: den Postfachserver und den Edge-Transport-Server, der als Mailgateway dienen kann.
Weitere Verbesserungen betreffen das Benutzerinterface für den Webzugriff, der auch mit Outlook on the Web einen neuen Namen erhalten hat. Statt Outlook Anywhere ist nun MAPI over HTTP das standardmäßig von Outlook-Clients verwendete Protokoll für den Zugriff auf Postfachdaten.
Microsoft hat die neueste Exchange-Version im Oktober 2018 offiziell zur Verfügung gestellt. Sie bietet einige Neuerungen und Änderungen, die ich Ihnen in diesem Abschnitt kurz auflisten möchte.
Genauer ausgedrückt setzt Exchange 2019 Windows Server 2019 zwingend voraus. Die finale Version lässt sich anders als die Preview-Versionen nicht auf älteren Server-Betriebssystemen installieren. Einer der Gründe dafür ist die Abhängigkeit von verbesserten Sicherheitseigenschaften des Windows-Server-2019-Betriebssystems, zum Beispiel im Bereich TLS.
Gemäß Microsoft erlaubt Exchange 2019 als erste Version eine Migration auf ein neues Betriebssystem in-place, das heißt, es muss kein neuer Server installiert werden. Da momentan noch keine neuere Version des Server OS zur Verfügung steht, kann dieses Feature noch nicht eingesetzt werden.
Exchange 2019 unterstützt erstmals eine Installation auf Server Core. Es ist sogar die empfohlene Option, weswegen ich die praktische Vorgehensweise zusammen mit Vor- und Nachteilen in Abschnitt 4.2 aufzeigen werde.
Exchange 2019 kann jetzt mehr Prozessorkerne und Memory nutzen – bis zu 48 Cores und 256 GB RAM. Allerdings hat Microsoft auch die minimalen Anforderungen auf 128 GB RAM angehoben. Dies ist keine technische Anforderung – Exchange läuft auch mit weniger RAM problemlos. Der Hersteller entwickelt aber das Produkt nur noch für Großkunden, die (noch) nicht in die Cloud migrieren können. Diese Kunden sollten sich auch an das von Microsoft veröffentlichte Preferred-Architecture-Design-Dokument halten, um alle Vorteile nutzen zu können. Zu finden ist es unter dieser URL: https://docs.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/preferred-architecture-2019?view=exchserver-2019. Es empfiehlt physische Server mit JBOD-Disks in einer Database Availability Group mit vier Kopien jeder Datenbank. Neu erkennt Exchange 2019 jetzt auch Solid State Drives (SSD) und verwendet diese als Zwischenspeicher für oft benötigte Informationen wie den Index. Ebenfalls soll der Logon an dem Postfach bis zu 50% schneller erfolgen. Die Konfiguration dieses Features werde ich in Abschnitt 5.5.4 beleuchten.
Die Suche war in Exchange und Outlook schon immer eine Quelle für Probleme. Nachdem für Exchange 2013 und 2016 die Such-Engine von Sharepoint integriert wurde, wird in Exchange 2019 stattdessen Bing-Technologie eingesetzt. Es bleibt abzuwarten, welche Auswirkungen der Wechsel hat. Hier fehlen leider noch Erfahrungswerte. In Exchange Online rechnet Microsoft mit 50% schnellerer Suche, wenn auch die Funktion MetaCache Database in Verwendung ist. Als weiteres Benefit der neuen Technologie ist die Anzeige sogenannter Smart Captions zu erwähnen – hervorgehobene Suchbegriffe in den Resultaten.
Abb. 1.3: Smart Caption im Suchresultat
Statistiken über den Stand der Indexierung können neu mit dem Befehl
Get-MailboxStatistics -Identity administrator | Format-List *BigFunnel*
ausgelesen werden. In Abbildung 1.4 sehen Sie einen Beispiel-Output.
Abb. 1.4: Statistiken zur Indexierung eines Postfachs
Darin ist auch ersichtlich, welcher Anteil des Index auf SSD kopiert worden ist – sehen Sie dazu auch die Informationen über die MetaCache Database in Abschnitt 5.5.4.
Der Index ist bei Exchange 2019 nicht mehr in einer separaten Dateistruktur abgelegt, sondern in die Datenbank integriert. Deshalb wird Ihnen auch im Befehl Get-MailboxDatabaseCopyStatus die Gesundheit des Index nur noch mit NotApplicable angezeigt (Abbildung 1.5).
Abb. 1.5: Status des Index wird nicht mehr angezeigt.
Seit Exchange 2013 und der Einführung von webbasierten Verwaltungswerkzeugen wie Exchange Admin Center (EAC) stellt sich die Frage, wie der Zugriff darauf aus dem Internet unterbunden werden kann. Keine der von Microsoft unterstützten Methoden war bislang mehr als ein Workaround. In Exchange 2019 haben Sie die Möglichkeit, die Zugriffssteuerung mittels Clientzugriffsregeln basierend auf IP-Adressen, Authentisierungsmethoden oder Benutzerattributen umsetzen. Die Beispielkonfiguration dazu finden Sie in Abschnitt 5.12.
Der Kalender erlaubt es Ihnen nun, beim Versand von Einladungen anzugeben, dass der Empfänger den Termin nicht weiterleiten darf. Bislang war dazu die Integration von Active-Directory-Rechteverwaltungsdiensten (ADRMS) nötig.
Abb. 1.6: Weiterleitungsoption in Outlook on the Web (OWA)
Auf der Seite des Empfängers ist die Option, weiterzuleiten, nicht verfügbar, wenn Weiterleitung zulassen entfernt wurde:
Darüber hinaus wurden die Möglichkeiten für den Abwesenheitsassistenten erweitert. Nun können Sie den Kalender während der Abwesenheit automatisch blockieren und Einladungen während dieser Zeit absagen. Auch schon angenommene Termine können Sie so absagen.
Abb. 1.7: Neue Optionen im Abwesenheitsassistenten
Ebenfalls sehr interessant sind die beiden neuen Funktionen, Kalendereinladungen von Benutzern zu entfernen, die die Firma verlassen haben, und Zugriffsrechte für Stellvertretungen mittels der Exchange Management Shell zu verwalten.
Die Rolle für Unified Messaging wurde aus Exchange 2019 komplett entfernt. Kunden mit Skype for Business oder anderen Telefonielösungen, die Exchange für die Voicemail-Funktionalität verwendet haben, müssen eine andere Lösung suchen. Microsoft selbst empfiehlt Skype for Business 2019 und Cloud Voicemail oder einen Wechsel zu Office 365. Natürlich bleibt Ihnen auch die Möglichkeit, weiterhin Exchange 2016 zu betreiben.
Teams ist ein Cloud-Produkt, das in Zukunft Skype for Business ersetzen wird. Es bietet neben Instant Messaging, Telefonie und Konferenzen auch persistente Chat-Räume an und integriert sich neben Exchange Online auch in lokale Exchange-Installationen, wenn Sie die Benutzer-Informationen aus dem Active Directory zum Cloud-Dienst Azure AD synchronisieren.
Obschon sich in puncto Lizenzierung im Grunde nichts geändert hat, ist zu erwähnen, dass Exchange 2019 nur noch Volumenlizenz-Kunden zur Verfügung steht. Damit können weder Release-to-Manufacturing-(RTM-)Versionen noch kumulative Updates öffentlich heruntergeladen werden.
Bevor Sie den ersten Exchange-2019-Server installieren, sollten Sie sich Gedanken machen, wie Ihre neue Messaging-Infrastruktur schlussendlich aussehen soll. Dabei spielt es keine Rolle, ob Sie auf der grünen Wiese anfangen können oder von einer bestehenden Exchange-Version migrieren müssen. Im Folgenden erfahren Sie, welche Fragen Sie sich vor der Installation stellen sollten und welche Anforderungen Sie im Blick haben müssen.
Wie sieht der Ablauf eines Exchange-Projekts aus? Ich rate dazu, ganz am Anfang zu entscheiden, ob für die Umsetzung externe Hilfe herangezogen werden soll oder nicht. Es ist ein nicht zu unterschätzender Vorteil, wenn man schon einige ähnliche Projekte durchgeführt hat, selbst wenn letztlich keine zwei Umgebungen identisch sind.
Wenn von Beginn an ein Berater involviert ist, können zeitraubende Fehleranalysen gegebenenfalls vermieden werden. Als Nächstes sollten Sie von allen Nutzern der zu planenden Umgebung Anforderungen einholen. Das ist sicher leichter gesagt als getan, aber in den Anfängen des Projekts ist es noch nicht so schwer, Alternativen zu suchen und einzuplanen, als wenn schon eine fertige Installation vorhanden ist.
Nun kann eine Zielumgebung definiert und der Migrationspfad festgelegt werden.
Ein wichtiger Punkt ist die Auflistung aller bereits vorhandenen Produkte mit Schnittstellen zu Exchange. Die Erfahrung zeigt, dass meist etwas vergessen wird und dann ad hoc noch Updates oder Upgrades gemacht werden müssen. Im schlimmsten Fall kann sich das Projekt auch um Monate verzögern.
Beispiel
Bei einem Kunden mit anstehender Migration von Exchange 2003 zu 2010 und schließlich 2016 (Double-Hop-Migration) stellte sich heraus, dass die Telefonanlage nicht kompatibel mit den neuen Versionen war. Nach mehreren erfolglosen Versuchen konnte sie dann endlich auf einen Stand gebracht werden, der die Migration erlaubte. Die Verzögerung betrug aber fast ein Jahr.
Für das Sizing, also die Planung der Anzahl der Server und deren Ausstattung an Prozessoren, RAM und Disks, bietet Microsoft den Exchange Server Role Requirements Calculator an – ein auf Excel basierter Rechner, der aufgrund verschiedener Eingaben Eckwerte wie RAM und die Anzahl der Server oder Datenbanken berechnen kann. Der Rechner benötigt folgende Angaben entweder aus einer bestehenden Installation oder als Schätzung:
Durchschnittliche Anzahl ein- und ausgehender Nachrichten pro Tag und Postfach
Durchschnittliche Größe einer Nachricht
Anzahl der Postfächer – eventuell in maximal vier Teilmengen mit unterschiedlichen Anforderungen
Die restlichen Inputs sind dann Annahmen für die Planung, zum Beispiel:
Hochverfügbarkeit auf Standortebene
Postfach-Quota, die den Benutzern zur Verfügung stehen soll
Maximale Datenbankgröße
Einige der wichtigsten Eingaben für den Calculator beschreibe ich in Abschnitt 3.3.1.
Immer mehr Unternehmen entscheiden sich, keine Mail-Infrastruktur mehr in den eigenen Datacentern zu betreiben und stattdessen einen Cloud-basierten Dienst wie Microsofts Office 365 mit Exchange Online zu nutzen.
Die Vorteile der Auslagerung sind:
Keine eigenen Server und vor allem Speicherplatz für die Postfächer mehr nötig
Updates an der Infrastruktur werden durch Microsoft durchgeführt. Die Systeme sind dadurch auch immer aktuell und somit sicherer.
Weniger technisches Wissen für Betrieb und Fehlersuche nötig
Neue Funktionen sind zuerst in Exchange Online verfügbar – einige sogar ausschließlich dort.
Integration mit anderen Produkten wie Teams, Sharepoint oder Azure-Multi-Faktor-Authentisierung lassen sich einfacher aktivieren, da keine zusätzlichen Systeme aufgebaut werden müssen.
Microsoft entwickelt Exchange optimiert für den Cloud-Betrieb.
Neben den Vorteilen gibt es aber auch Schattenseiten, deren Sie sich bewusst sein sollten:
Falls Sie die Benutzerkonten des lokalen Active Directorys in die Cloud synchronisieren, benötigen Sie immer noch lokale Exchange Server für die Verwaltung. Eine bessere Lösung ist uns Microsoft schon seit Jahren schuldig.
Sie müssen sich stets informieren, welche Funktionen Microsoft hinzufügt oder entfernt, um Überraschungen zu vermeiden.
Die Integration von Fremdlösungen kann schwieriger oder sogar unmöglich sein.
Für große Kunden können die Kosten höher sein als erwartet.
Exchange-Online-Postfächer werden nicht gesichert. Stattdessen kann Exchange Native Data Protection und In-Place Hold verwendet werden, was aber die Kosten in die Höhe treibt.
Kunden mit rechtlichen Vorgaben für Journaling müssen beachten, dass Microsoft die Auslieferung von Journal-Reports in ein Cloud-Postfach nicht akzeptiert.
Tipp
Meine Empfehlung lautet: Falls Exchange nicht lokal so betrieben werden kann, wie Microsoft es vorsieht – also im Rahmen der Preferred Architecture –, sollten Sie eine Migration in die Cloud erwägen. Falls dann ein triftiger Grund gegen Office 365 spricht, können Sie Exchange lokal gemäß Microsofts unterstützten, statt empfohlenen Richtlinien betreiben.
Jede Exchange-Organisation basiert auf einer Active-Directory-Umgebung. Der Verzeichnisdienst übernimmt dabei folgende Aufgaben:
Speichern der Konfiguration von Exchange Servern und globalen Objekten
Darstellen des globalen Adressbuchs mit allen Empfängern und ihrer Konfiguration
Erlauben der Authentifizierung zwischen mehreren Exchange Servern oder auch der Benutzer beim Zugriff auf ihre Daten
Die Abhängigkeit von Active Directory bedeutet für das Design, dass eine Exchange-Organisation genau eine Active-Directory-Gesamtstruktur umfasst. Exchange-Organisationen können nicht mehrere Gesamtstrukturen umspannen und es können nicht mehrere Exchange-Organisationen in der gleichen Gesamtstruktur existieren. Eine Active Directory Gesamtstruktur stellt als Verzeichnisdienst sowohl die Grenze der Replikation von Objekten als auch eine Sicherheitsgrenze dar.
Sie sollten grundsätzlich nicht mehrere Exchange-Organisationen einplanen. Allerdings verlangen folgende Szenarien das Abweichen von diesem Grundsatz:
Sie betreiben eine dedizierte Testumgebung, die möglichst der produktiven Umgebung gleichen soll.
Sie wünschen eine vollständige Trennung der Administration von Exchange zwischen mehreren Firmenteilen (zum Beispiel nach einer Fusion oder rechtlichen Vorgaben).
Sie sind Hoster und müssen mehrere Kundenumgebungen isoliert betreiben.
Ein Teil der Firma wird herausgelöst und braucht nun eine eigene Infrastruktur.
Oftmals wird in kleinen Unternehmen oder in virtualisierten Umgebungen nur ein Exchange Server installiert und damit auf viele Funktionen des Produkts verzichtet. Hier ein paar Beispiele für Vorteile, die sich aus der Verwendung einer Database Availability Group und eines Loadbalancers mit mehreren Servern ergeben:
Installation von Windows- und Exchange-Updates ohne Ausfallzeit für die Benutzer. Exchange Server lassen sich innerhalb einer Database Availability Group in einen Wartungsmodus versetzen und werden dann weder für Postfach-Zugriffe noch Mailfluss berücksichtigt.
Automatische Reparatur von Fehlern in der Datenbank (Page Patching). Datenbanken werden von einem Hintergrundprozess permanent auf Inkonsistenz geprüft. Sollten während dieses Prozesses fehlende oder korrupte Datensätze gefunden werden, können diese aus einer anderen Datenbankkopie automatisch wiederhergestellt werden.
Weniger Abhängigkeit von Backups, z.B. bei Hardwareausfall oder Fehlern in Updates. Erstens muss bei Korruption keine Wiederherstellung gemacht werden, wie in vorhergehendem Punkt erwähnt, und zweitens können alle Services bei einem Ausfall eines Servers weiter angeboten werden, wodurch der Druck, schnellstmöglich eine Lösung zu finden, massiv kleiner ist.
Beispiel
Ein Kunde mit ca. 200 Postfächern auf einem einzigen Exchange-2007-Server ließ sich von uns überzeugen, im Rahmen der Migration auf 2013 eine Database Availability Group mit virtuellem Loadbalancer einzusetzen.
Nach erfolgreichem Abschluss des Projekts wollte der IT-Verantwortliche eine Schulung für das Vorgehen bei der Installation von Updates haben. Wir sperrten also an einem normalen Arbeitstag einen Server für die Benutzerzugriffe und installierten Windows-Server-2012-Updates. Es stellte sich beim Reboot heraus, dass einer der Hotfixes in der Konstellation des Kunden mit Hyper-V als Virtualisierungslösung die virtuelle Maschine so zerschoss, dass eine Rettung unmöglich war. Dank des zweiten Servers konnten wir die Umgebung ohne Druck wiederherstellen – die Benutzer merkten davon gar nichts.
Als Argument gegen Installationen mit mehreren Servern wird oft angeführt, dass Cluster kompliziert seien. Dies mag vor ein paar Jahren noch korrekt gewesen sein, als der Support für Clustering durch Microsoft noch auf ganz spezifische Kombinationen von Hardware und Treibern beschränkt war. Mit den aktuellen Betriebssystemen und dem Umstand, dass Exchange die Konfiguration des Failoverclustering-Features für den Administrator vornimmt, gilt die Aussage aber definitiv nicht mehr.
Tipp
Lohnt sich der Aufwand, mehrere Server zu betreiben, nicht, sollte ein Umzug in die Office-365-Cloud erwogen werden. Microsoft als Entwickler von Exchange kann das Produkt zweifellos am besten betreiben.
Wenn die Entscheidung gefallen ist, Exchange on-premises zu installieren, bieten sich immer noch mehrere Optionen an, die in Betracht gezogen werden müssen: Installation als virtuelle Maschine, auf physischen Servern oder als Kombination von beiden.
Es ist die Strategie vieler Unternehmen, möglichst alle Systeme virtualisiert zu betreiben. Daher ist es dann naheliegend, auch Exchange zu virtualisieren. Aber aufgepasst: Microsoft entwickelt das Produkt für die Anwendung in Office 365 weiter – und dort sind die Server physisch und nicht virtualisiert implementiert. Somit darf nicht damit gerechnet werden, dass Verbesserungen für virtuelle Umgebungen eingeführt werden – eher im Gegenteil. Hier ein Beispiel:
Bis und mit Version Exchange 2007 verwendeten die Datenbanken einen Mechanismus, der die Daten deduplizierte: der sogenannte Single Instance Storage (SIS). Er bewirkte, dass Nachrichten an mehrere Empfänger in derselben Datenbank nur einmal gespeichert und nur Referenzen darauf in die Postfächer abgelegt wurden. Im Gegensatz zur ähnlichen Funktion in gängigen Archivierungslösungen – auch Stubbing genannt – war dies komplett transparent für den Benutzer und benötigte keinerlei Anpassungen aufseiten der Clients.
Mit Exchange 2010 verschwand der Single Instance Storage von der Liste der Funktionen. Grund dafür war eine Änderung an der Tabellenstruktur in der Datenbank. Neu wurde die Speicherung der Daten eines Postfachs möglichst aufeinanderfolgend auf der Disk bevorzugt, denn damit ist es dem Server möglich, mit weniger Disk-IOs auszukommen. Auch nicht angeforderte Daten werden in den Datenbank-Cache geladen, für den Fall, dass der Benutzer diese ebenfalls benötigt. Außerdem sind die resultierenden IOs weniger zufällig verteilt, sondern mehr sequenziell, was ebenfalls die Leistung erhöht.
Für virtualisierte Exchange Server bietet diese Änderung wegen der Speicherung der Datenbanken auf SAN-Speicher keine Vorteile – im Gegenteil: Dieser Speicherplatz ist üblicherweise teuer, weswegen in solchen Umgebungen Deduplizierung bevorzugt würde.
Virtualisierung wird von Microsoft für Exchange zwar unterstützt, aber es muss einiges beachtet werden.
Der verwendete Hypervisor muss von Microsoft validiert worden und damit Teil des Windows Server Virtualization Validation Programs sein.
Virtuelle Maschinen (VM) mit Exchange-Server-Installationen in einer Database Availability Group (DAG) dürfen nicht auf demselben physischen Host zu liegen kommen. Das Gleiche gilt für den Server mit der Funktion des Zeugenservers (kurz FSW, von engl. File Share Witness). Der Zeugenserver stellt sicher, dass im Falle von Netzwerkausfällen, bei denen mehrere Server in der gleichen DAG nicht mehr kommunizieren können, die Datenbank nur auf einem Server bereitgestellt wird. Gibt es gemeinsame Abhängigkeiten für mehrere Exchange-Komponenten einer Database Availability Group, kann die Verfügbarkeit stark reduziert werden, wenn Hardware ausfällt.
Beispiel
Eine Exchange-Installation besteht aus zwei Servern in einer Database Availability Group und einem Zeugenserver, der auf dem Backup-Server konfiguriert ist. Eine Exchange-Server-VM und die Backup-Server-VM liegen auf demselben Hyper-V-Host, als dieser ausfällt. Da der Failovercluster-Service kein Quorum besitzt, muss die Datenbank auf dem verbleibenden Server gestoppt werden. Zwar werden die virtuellen Maschinen vermutlich auf einem anderen Host wieder gestartet werden und somit das Quorum wiederhergestellt, aber die Unterbrechung wäre vermeidbar gewesen.
Das Gleiche gilt auch für den Storage: Wenn die virtuellen Maschinen aller Exchange Server auf dem gleichen Storage liegen, kann ein Problem mit diesem den kompletten Ausfall des Maildienstes bewirken.
Beispiel
Ein Mitarbeiter eines namhaften Storage-Herstellers aktualisierte bei einem kleineren Kunden die Firmware der Controller. Dabei ging etwas schief und die gesamte Serverumgebung stand für zwei Tage still.
Ressourcen wie RAM, CPU oder Disk dürfen nicht überprovisioniert werden, das heißt, es darf nur verteilt werden, was auch wirklich vorhanden ist. Dies gilt nicht nur für die virtuellen Maschinen selbst, sondern für den ganzen Host, auf dem eine Exchange-VM liegt.
Beispiel
Auf einem Hyper-V-Host mit 2 CPUs und je 6 Kernen werden 5 VMs mit jeweils 4 virtuellen CPUs und 6 VMs mit jeweils 2 virtuellen CPUs betrieben. Das Verhältnis von physischen Kernen (ohne Hyperthreading gerechnet) zu virtuellen CPUs beträgt damit 1:2.66 – 12 Kerne zu 32 vCPUs. Unterstützt ist gemäß Microsoft maximal 1:2 und empfohlen 1:1. Auch VMWare geht in ihrem Whitepaper für produktive Umgebungen von einem 1:1-Verhältnis aus.
Wichtig
Es ist ein Teil der Strategie von Virtualisierungslösungen, Ressourcen gemeinsam zu nutzen. Wird wegen Exchange auf Überprovisionierung verzichtet, schränkt das die Plattform ein. Werden hingegen die Anforderungen nicht berücksichtigt, kann es zu Leistungseinbußen kommen, die schwer nachvollziehbar sind. Exchange eignet sich nur bedingt für den virtuellen Betrieb, selbst wenn es durch Microsoft unterstützt wird.
Virtuelle Maschinen können aus verschiedenen Gründen pausiert werden. Microsofts Hyper-V zum Beispiel verwendet die Funktion, wenn der Host heruntergefahren wird (nur sinnvoll für Testumgebungen), oder für geplante Migrationen von virtuellen Maschinen auf einen anderen Host mittels des Quick-Migration-Features. Dies ist für Exchange explizit nicht unterstützt.
Snapshots werden für Exchange nicht unterstützt. Eine Ausnahme ist ein Snapshot im Rahmen einer Sicherung, wenn Exchange über den VSS Writer darüber informiert wird.
Der Storage, den der Hypervisor verwendet, muss blockbasiert sein – also kein Network Attached Storage (NAS). Einzige Ausnahme ist Small-Message-Block-(SMB-)basierter Speicher im Rahmen von Hyper-V und Scale-out-Fileservern. Ein häufig anzutreffendes Szenario ist VMWare Hypervisor mit Network-File-System-(NFS-)basiertem Storage. Dies ist explizit nicht unterstützt.
Egal, ob die Hardware schlussendlich virtuell oder physisch vorliegt, müssen einige Anforderungen erfüllt sein.
Exchange benötigt 64-Bit-Prozessoren. Dabei kann es sich um Intel-64- oder AMD-64-Systeme handeln, jedoch nicht um Intels Itanium-IA64-Plattformen.
Das absolute Minimum an RAM beträgt für den Postfachserver 128 GB und für die Edge-Transport-Rolle 64 GB. Für Testsysteme reichen in der Regel 8 GB ohne Probleme.
Für die Disk, auf der Exchange installiert wird, sollten gemäß Microsofts Dokumentation mindestens 30 GB veranschlagt werden. Wird die Installation auf die Systemdisk durchgeführt, ist ein Wert von 100 bis 120 GB ratsam. Werden zusätzliche Sprachpakete für Unified Messaging installiert, sollten dafür jeweils 500 MB eingerechnet werden.
Die Größe der Datendisks lässt sich grob abschätzen, indem die Anzahl der Postfächer mit der gewünschten maximalen Größe pro Postfach multipliziert wird. Weitere Faktoren sind die Anzahl der Datenbankkopien, die Sicherheitsmarge für anwachsende Transaktionsprotokolle bei Ausfall der Backup-Lösung, die Verwendung der Funktionen Single Item Recovery (SIR, Wiederherstellung einzelner Elemente) oder In-Situ-Archiv. Der Exchange Server 2019 Sizing Calculator bietet genauere Formeln zur Berechnung der notwendigen Speichergröße. Sehen Sie dazu auch Abschnitt 3.3.1.
Exchange hatte bis Version 2007 sehr hohe Anforderungen an die Leistungsfähigkeit der Disks, auf denen Datenbank und Transaktionsprotokolle liegen. Wie schon erwähnt, wurden diese Anforderungen massiv reduziert – Microsoft spricht von über 90% gegenüber Exchange 2003. Grund dafür ist die Optimierung für JBOD – Just a bunch of disks, also lokale Festplatten ohne Leistungssteigerung oder Ausfallsicherheit durch einen RAID-Controller. Folgende Möglichkeiten stehen zur Verfügung:
Wenn Virtualisierung für Exchange eingesetzt wird, ist fast immer auch ein Storage Array Network oder SAN in Verwendung. Es ist aber auch möglich, in Zusammenhang mit physischen Servern die Daten auf einem SAN zu speichern. Hier in Stichworten ein paar Vorteile:
Zentrale Verwaltung und Monitoring
Hohe Performance möglich durch Verteilung der Daten auf viele Disks und/oder Tiering mit Solid State Disks (SSD)
Sicherung und Wiederherstellung mittels Storage Snapshots
Kann zentral erweitert werden
Natürlich gibt es auch Schattenseiten:
SANs sind tendenziell teuer.
Der zentrale Speicher kann ein Single Point of Failure sein.
Die Leistung wird von vielen Systemen geteilt, was trotzdem zu Engpässen führen kann.
In Bezug auf Exchange bedeuten diese Nachteile, dass oft auf zusätzliche Datenbankkopien verzichtet wird, weil der Speicherplatz teuer ist. Oder es werden Zusatzprodukte für die Archivierung der Postfächer eingeführt, um den Speicherbedarf zu verringern. Allerdings erhöhen diese Produkte die Komplexität und Fehleranfälligkeit der gesamten Umgebung.
Falls ein SAN für Exchange in Betracht gezogen wird, sollten folgende Punkte speziell berücksichtigt werden:
Der Speicher sollte zuvor auf die verfügbare Leistung getestet werden. Insbesondere die Latenz darf nicht zu hoch sein. Microsoft bietet dafür die Software Jetstress an. Deren Einsatz muss schon früh geplant werden, da sie nur eingesetzt werden kann, solange Exchange noch nicht auf den Servern installiert ist.
Idealerweise sollte jede Datenbankkopie auf einem unabhängigen SAN-Speicher liegen. Wenn das SAN blockbasiert Daten an einen anderen Standort spiegelt, sollte Exchange davon ausgenommen werden, da das Produkt ja eine eigene Replikationslösung beinhaltet und die Spiegelung somit nur unnötigen Platz belegt.
Hinweis
Wird ein SAN als Speicher für VMWare VSphere oder Citrix XenServer verwendet, wird die Anbindung mittels NFS nicht von Microsoft unterstützt. Da eine solche Konstellation problemlos funktionieren kann, wissen viele Administratoren nicht, dass sie eine nicht-supportete Umgebung betreiben. Erlaubt sind Fibre Channel und iSCSI. Zusätzlich kann für Hyper-V noch SMB 3.0 über einen sogenannten Scale-out File Server Setup verwendet werden.
Lokale Disks werden zusammen mit physischen Servern eingesetzt und können entweder in einem RAID-Verbund oder einzeln als JBOD konfiguriert werden. RAID (Redundant Array of Independant Disks) sollte verwendet werden, wenn weniger als drei Datenbankkopien vorgesehen sind. Microsoft empfiehlt JBOD aus Gründen der Redundanz erst ab drei Kopien. Folgende Vorteile ergeben sich aus der Verwendung von lokalen Disks:
Sie sind günstiger als SAN-Speicher.
Sie sind unabhängig voneinander, insbesondere in der JBOD-Konfiguration.
Sie bieten viel Platz.
Sie benötigen kein Spezialwissen für Konfiguration und Wartung.
Auch bei dieser Speichervariante gilt es, ein paar Punkte zu beachten:
Kommt kein JBOD zur Anwendung, sollte für Datenbanken und Transaktionsprotokolle RAID1 oder RAID10, nicht aber RAID5 verwendet werden. RAID5 hat keine gute Schreibleistung im Vergleich zu den anderen Optionen, da für jeden Schreibvorgang auch noch die Parity Information gelesen, neu berechnet und geschrieben werden muss.
Selbst mit JBOD sollte der Disk Controller Caching unterstützen und für 75% Write und 25% Read konfiguriert werden.
Unabhängig davon, ob Exchange schlussendlich virtualisiert läuft oder nicht, werden Disks für das Betriebssystem und die Exchange-Installation benötigt. Ich bin kein Befürworter von separaten Disks für diese beiden Zwecke, sondern verwende eine Disk oder LUN (Logical Unit Number) im Falle von SAN-Speicher für beides. Hier sind ein paar Gründe dafür:
Es gibt zu viele Abhängigkeiten zwischen Betriebssystem und Applikation.
Installation von kumulativen Updates kann dazu führen, dass einzelne Ordner trotz dedizierter Applikations-Disk wieder auf der Betriebssystem-Disk zu liegen kommen.
Wenn SAN im Einsatz ist, werden die Disks mit hoher Wahrscheinlichkeit auf den gleichen Arrays von physischen Disks liegen und darum kein Performance-Gewinn durch die Trennung möglich sein.
Im Falle von lokalen Disks müssen für die Trennung Disk-Einschübe im Server geopfert werden, die stattdessen für die Datenbanken verwendet werden könnten.
Es gibt eine Ausnahme: Falls der zu erwartende Mail-Verkehr sehr groß ist, muss die Transport-Datenbank auf eine dedizierte Disk ausgelagert werden. Allerdings bedeutet das nicht, dass die gesamte Installation auf dieser Disk zu liegen kommt.
Wichtig
Die Disk, auf der die Exchange-Installation liegt, muss ausreichend groß sein. Es lohnt sich nicht, hier zu sparen. In virtuellen Umgebungen stößt die gewünschte Größe von 100 bis 120 GB bei den Administratoren der Virtualisierungslösung wegen knappen Speicherplatzes oft auf Widerstand, aber ich habe genügend Fälle erlebt, in denen die Disk vollgelaufen ist und Exchange komplett stillstand oder zumindest die Rückstaufunktion oder Back Pressure aktiv wurde und den Mailfluss lahmgelegte. Die Rückstaufunktion misst bestimmte Werte wie zum Beispiel freie Kapazität auf der Disk, auf der die Transport-Datenbank liegt oder den Memory-Verbrauch und leitet Maßnahmen ein, wenn Schwellenwerte über- oder unterschritten werden.
Vorsicht
Alle Datendisks müssen die gleiche physische und logische Sektorgröße aufweisen. Es existieren drei Typen von Harddisks: 512-Byte ist die älteste Technologie und verwendet physisch und logisch 512 Bytes, 4K-Disks weisen sowohl logisch als auch physisch 4096-Byte-Sektoren auf und 512E-Disks emulieren 512-Byte-logische Sektoren auf 4096-Byte-physischen Sektoren. Innerhalb einer Database Availability Group dürfen keine Disktypen gemischt verwendet werden, da sonst keine Replikation von Datenbankkopien möglich ist. Dies betrifft nicht nur physische Disks, sondern auch virtuelle: Microsofts vhd-Format verwendet 512-Byte, und das VHDX-Format 4K.
Exchange-2019-Installationen sind nur auf Windows Server 2019 möglich. Semi-Annual Channel Builds wie Windows Server Version 1809 werden nicht supportet.
Es spielt für Exchange keine Rolle, ob die Standard- oder Datacenter-Edition installiert wird.
In diesem Buch haben wir uns dafür entschieden, Deutsch als Sprache für das Betriebssystem und Exchange zu verwenden. Daher entsprechen alle Angaben und Abbildungen der deutschen Software. Alternativ können Sie das Programm natürlich auf Englisch installieren. Gegebenenfalls erleichtert das in bestimmten Fällen die Recherche im Internet oder die Kommunikation im Falle eines Microsoft Support Cases.