Wie kann ich eine Cloud-Only Shared Mailbox in Office 365 in eine AAD Connect synchronisierte User Mailbox konvertieren, deren Anmeldung anschließend über ADFS erfolgt?
Verbinden Sie sich mit der Exchange Online PowerShell und prüfen Sie zuerst, ob das anzupassende Postfach vom Typ SharedMailbox ist. Dies erkennen Sie daran, dass das Attribut RecipientTypeDetails den Wert SharedMailbox hat.
Anschließend wird die Shared Mailbox in den Typ UserMailbox umgewandelt. Dies erfolgt mit Hilfe von
Set-Mailbox -Identity MAILBOXNAME -Type Regular
Die erneute Prüfung zeigt den neuen RecipientTypeDetails Typ UserMailbox.
Nun wird im lokalen Active Directory (AD) der entsprechende User mit dem gleichen User Pricipal Name wie der Cloud-Only User neu angelegt.
Nachdem der neue Benutzer im AD erstellt ist, muss diesem nun die Default SMTP Adresse eingetragen werden. Die Adresse wird bei den User Attributen unter proxyAddresses eingetragen. Um die Attribute sehen und bearbeiten zu können, müssen in der Active Directory Users and Computers Management Console die Advanced Features aktiviert werden.
Der Reiter Attribute Editor erscheint nur, wenn der entsprechende User in der OU aufgerufen wird, in dem er gespeichert ist. Wenn der User über die Such-Funktion aufgerufen wird, erscheint der Reiter leider nicht. Wo der User im AD liegt kann man im Reiter Object sehen.
Rufen Sie im Reiter Attribute Editor das Attribute proxyAddresses auf und tragen den entsprechenden SMTP Eintrag ein. Wichtig ist, dass SMTP in Großbuchstaben geschrieben wird. Nur dann ist es die Default oder primäre SMTP Adresse. In Kleinbuchstaben wäre es ein Alias bzw. eine zusätzliche Empfangsadresse und das passt nicht zum Eintrag in Office 365. AAD Connect matcht über die primäre SMTP Adresse.
Nach dem Speichern des Eintrages muss der AAD Connect Sync abgewartet werden und dem User in Office 365 noch eine passende Lizenz zugewiesen werden, damit die Mailbox auch aktiv wird.
Viel Spaß mit Office 365
Sichern Sie Ihre E-Mail Kommunikation mit PGP oder S/MIME und nutzen Sie sichere E-Mail Verschlüsselung am Gateway mit NoSpamProxy Encryption | E-Mail Security Made in Germany | Wir beraten Sie gerne: info@granikos.eu
The following PowerShell scripts have been published by our Exchange and Office 365 experts to the technical community at TechNet Gallery. Please use the GitHub repositories to report issues or to file feature requests.
Please send comments, wishes, and ideas to support@granikos.eu.
Enjoy!
Need assistance with your Exchange Server Organization? You plan to upgrade your Exchange Server Organization? You plan to migrate to Office 365? Contact us: info@granikos.eu
Update 2020-10-05: Fetch all remote SMTP servers from Exchange receive connector logs added Update 2020-05-25: TechNet Gallery links removed due to end of TechNet Gallery in mid-2020 Update 2020-02-07: Report for enabled client protocols, Exchange Environment Report - v2, Set thumbnailPhoto for AzureAD guest users added Update 2019-05-07: Export mailbox delegates and SMTP forwarding information added Update 2018-09-04: Add remote IP-address ranges to a receive connector added Update 2018-06-16: Manage Master Category List for Shared Mailboxes and Teams added Update 2018-04-29: Convert Word documents using PowerShell and Set Mailbox Item Private Flag added Update 2018-01-24: Create a new Room Mailbox with Security Groups added Update 2017-11-11: Export all user mailbox permissions added Update 2017-09-22: Remove Out-Of-Office rules from user mailbox added Update 2017-05-20: Parse email messages content for further processing and Update OWA vDir config across multiple servers added Update 2017-03-18: Fetch recently created public folders and Clear Private Flag on Mailbox Messages added Update 2017-02-22: Remove Orphaned HealthMailbox and SystemMailbox Accounts from MESO Container added Update 2017-02-17: Test Office 365 Domain Availability added Update 2017-02-13: Connect to Exchange Server 2013+ using remote PowerShell added Update 2017-02-07: Create Exchange internal/external Url based certificate requests, Create a scheduled task for Exchange Server 2013 added Update 2017-01-24: Gather Exchange Configuration Data added Update 2017-01-05: Export Messages from Transport Queue added Update 2016-11-29: Clean legacy public folder ACL added, Scripts categorized Update 2016-11-28: Add multiple legacy public folder replicas added Update 2016-08-18: Simple import of multiple PST files for a single user added Update 2016-07-28: Change IIS Log File settings Github Url added, Create a new Team Mailbox with Security Groups added Update 2016-06-04: GlobalFunctions added Update 2015-06-18: Copy-ReceiveConnector updated Update 2015-06-01: Exchange 2010 Public Folder Replication Report (UTF8 support) Update 2015-05-21: Copy anti-virus pattern to Exchange 2010/Exchange 2013 servers added Update 2014-12-10: Copy a receive connector from one Exchange Server to multiple Exchange Servers added
Exchange Server besteht aus zwei Kernkomponenten. Zum einen ist es die Bereitstellung von Postfächern, mit all den benötigten Client-Zugriffsprotokollen und Postfach-Funktionen. Die zweite Komponente ist der Nachrichtenfluss, also der Empfang, die Verarbeitung und der Versand von E-Mail-Nachrichten.
Was sich so einfach und trivial anhört, ist ein zentraler und komplexer Baustein in der Exchange Architektur. In diesem Artikel versuche ich ein wenig Licht ins Dunkel des Exchange Nachrichtenflusses zu bringen. Lassen Sie uns mit einem kurzen Rückblick auf die Exchange Server Architektur beginnen.
Wer sich den Nachrichtenfluss von Exchange Server anschaut, muss sich immer den Funktionsaufbau eines Exchange Servers und die empfohlene Implementierung im Rahmen der Preferred Architecture (PA) in Erinnerung rufen. In der PA wird Exchange Server immer in einer Konfiguration aus mehreren Exchange Servern, die als Datenbankverfügbarkeitsgruppe (DAG) zusammengefasst sind, betrieben. Hierdurch wird eine hochverfügbare Bereitstellung von Postfachfunktionen und Nachrichtentransport erreicht.
Jeder Exchange Server besteht aus einer Frontend- und Backend-Komponente. Eingehende Verbindungen von Drittsystemen erfolgen immer über die Exchange Frontend-Komponenten. Die Kommunikation mit den Backend-Komponenten erfolgt im Regelfall nur Exchange-intern.
Das folgende Diagramm zeigt den schematischen Aufbau der Verbindungen in einer DAG.
Die Konfigurationen für den Nachrichtenfluss unterteilen sich in organisationsweite und serverbezogene Einstellungen. Die organisationsweiten Einstellungen gelten, wie der Name es schon sagt, für die gesamte Exchange Organisation, ganz unabhängig davon wie viele Exchange Server oder DAGs Sie betreiben. Ob und wie ein Exchange Server diese Einstellungen verarbeiten kann, hängt von der Produktversion ab. Diese Einstellungen sind vollständig in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Sendekonnektoren.
Serverbezogene Einstellungen wirken sich nur für ein bestimmtes Serversystem aus. Diese Einstellungen werden hauptsächlich ebenfalls in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Empfangskonnektoren. Einige wenige Einstellungen werden jedoch auch in der lokalen Systemregistrierung gespeichert.
Für den sicheren und stabilen Betrieb von Exchange Server ist eine funktionierende Active Directory Replikation unerlässlich. Hierzu gehört auch eine korrekte Konfiguration der Active Directory Sites. Sie ist gerade in größeren Exchange Organisationen unerlässlich.
Ebenso wichtig ist die korrekte und einheitliche Konfiguration der TLS-Einstellungen auf allen Exchange Servern. Ohne solch eine Konfiguration ist nicht sichergestellt, dass verschlüsselte Verbindungen durch die Empfangs- und Sendekonnektoren aufgebaut werden können. Exchange Server vertraut hier auf die Konfiguration des lokalen Windows Server Betriebssystems und die Bereitstellung gültiger TLS-Zertifikate.
Kommen wir nun zum eigentlichen Thema, dem Exchange Nachrichtenfluss und beginnen mit dem Empfang von E-Mail-Nachrichten.
Exchange Server nehmen eingehende E-Mail-Nachrichten über unterschiedliche Wege entgegen. Der bekannteste Weg ist der Empfang über das Protokoll SMTP. Ein Exchange Server unterscheidet hierbei drei unterschiedliche Quelltypen. Im Frontend-Transport erfolgt die Annahme von Verbindungen anderer Server über den Standard TCP-Port 25. Zu den Servern, die sich über diesen Standard SMTP-Port verbinden, zählen:
Diese Verbindungen erfolgen über den Default Frontend Konnektor, der in seiner Standardkonfiguration nur Nachrichten, die an bekannte Empfänger eigener Domänen entgegennimmt. Die Zustellung von Applikationsnachrichten an externe Empfänger erfordert die Erstellung eines separaten Frontend-Empfangskonnektor.
Zusätzlich zu den Empfangskonnektoren stehen zwei weitere Wege über das lokale Dateisystem des Exchange Servers zur Verfügung, das Pickup- und Replay-Verzeichnis. Beide Verzeichnisse werden vom Backend-Transportdienst, den Sie aus früheren Exchange Versionen sicher noch als Hub-Transport kennen, permanent überwacht und sobald eine Datei dort abgelegt ist, wird sie aufgenommen und verarbeitet. Das Pickup-Verzeichnis dient der Ablage von neuen E-Mail-Nachrichten durch Applikationen. Das Replay-Verzeichnis können Sie nutzen, um Nachrichten, die Sie aus einer Warteschlange exportiert und entfernt haben, erneut in die Verarbeitung zu übergeben.
Zum Schutz vor unberechtigten Verbindungen verwendet Exchange Server unterschiedliche Formen der Authentifizierung. Ergänzend verfügen die Eingangswege über eine Header-Firewall, mit der unberechtigte Informationen aus einer E-Mail-Nachricht herausgefiltert werden.
Der Frontend-Transport verfügt über keine komplexe Business-Logik. Daher ist es wichtig, das Zusammenspiel zwischen Frontend-Transport und Transportdiensten im Backend zu verstehen und sich immer wieder in Erinnerung zu rufen, wenn es zu Problemen kommt. Der Empfangskonnektor im Frontend-Transport nimmt die Verbindung entgegen und führt die Authentifizierung durch. Anschließend wird eine Proxyverbindung zum Transportdienst per TCP-Port 2525 aufgebaut. Hierbei entscheidet nun die Konfiguration Ihrer Exchange Umgebung darüber, wie diese Proxyverbindung erfolgt. Bei einem Einzelserverbetrieb erfolgt die Verbindung zum Transportdienst des gleichen Servers. In einer DAG-Konfiguration wählt der Frontend-Transport den Transportdienst des DAG-Mitgliedservers aus, auf dem in diesem Moment die Datenbankkopie mit dem Postfach des Empfängers aktiv eingebunden ist.
Das folgende Diagramm zeigt das Zusammenspiel zwischen Frontend und Backend beim Empfang von Nachrichten per SMTP.
Beim Empfang einer Nachricht per SMTP versucht Exchange Server die Nachricht ausfallsicher entgegenzunehmen. Zu diesem Zweck erstellt Exchange Server eine Kopie der empfangenen Nachricht und speichert sie als Schattenkopie im Transportdienst eines anderen Exchange Servers. Erst nach dem erfolgreichen Speichern der Schattenkopie und der Speicherung in der lokalen Warteschlange des Backend-Transportdienstes, meldet der empfangende Exchange Server dem sendenden Server eine OK-Meldung.
Auf einem Exchange Server können mehrere Empfangskonnektoren für den gleichen Port konfiguriert werden. Wenn Sie weitere Konnektoren für den gleichen Port erstellen, müssen Sie festlegen, wie Exchange Server einen Konnektor auswählen soll. Am einfachsten ist hier die Konfiguration der IP-Adressen des absendenden Systems als Remote IP-Adresse am Konnektor.
Im Backend des Exchange Servers befinden sich zwei Transportdienste. Der wichtigste Dienst ist der Transportdienst, den manche von Ihnen sicher noch als Hub-Transport aus älteren Versionen von Exchange Server kennen. Diesen Dienst schauen wir uns im nächsten Abschnitt einmal genauer an. Der zweite Dienst ist der Postfachtransportdienst. Dieser Dienst hat die Aufgabe, eingehende Nachrichten in Postfächern lokal eingebundener Datenbanken zu speichern und Nachrichten, die versendet werden sollen, aus Postfächern lokaler Datenbanken zu lesen und zur weiteren Verarbeitung an den Transportdienst zu übermitteln. Diesen Dienst beschreibe ich in einem zukünftigen Artikel.
Der einfach erscheinende Empfang einer E-Mail-Nachricht ist, aus Gründen der Nachrichtensicherheit und zum Schutz vor dem Ausfall eines Systems, eine komplexe Aufgabe. Nach dem Empfang der Nachricht muss sie verarbeitet werden.
Die gesamte Verarbeitung von E-Mail-Nachrichten erfolgt im Transportdienst und ist Warteschlangen-basiert, mit der Betonung auf „Warte“. Eine empfangene E-Mail-Nachricht wird in der Submission-Warteschlange gespeichert und wartet dort darauf, zur sog. Kategorisierung aufgegriffen zu werden. In der Categorizer-Komponente erfolgt die Hauptarbeit des Transportdienstes. Zu den Aufgaben gehören:
Nach der Verarbeitung im Categorizer ist die Nachricht bereit zur weiteren Zustellung und wird hierzu in einer passenden Warteschlange gespeichert. Der Transportdienst legt für jedes Zustellungsziel eine separate Warteschlange an. Dies ist der Grund, warum Sie immer eine unterschiedliche Anzahl an Warteschlangen auf einem Exchange Server sehen. Die Warteschlangen gliedern sich in unterschiedliche Kategorien:
Zur Speicherung der Warteschlangen verwendet der Transportdienst auf jedem Exchange Server eine eigene Datenbank. In dieser Datenbank werden alle Nachrichten mit ihrem jeweiligen Verarbeitungs- und Zustellungsstatus gespeichert. Der Transportdienst kümmert sich eigenständig um den Funktionsstatus der Datenbank. Kommt es zu einem nicht behebbaren Fehler, wir eine komplett neue Datenbank erstellt und die korrupte Datenbank in einen neuen Ordner verschoben.
Das folgende Schaubild zeigt die Hauptkomponenten zur Verarbeitung von E-Mail-Nachrichten im Exchange Transportdienst.
Leider steht uns für die aktuelle Version Exchange Server kein detailliertes Diagramm des Transportdienstes offiziell zur Verfügung. Im Microsoft Download Center steht das Diagramm von Exchange Server 2010 zur Verfügung und bietet einen guten konzeptionellen Überblick über den Transportdienst. Achten Sie auf die Unterschiede zu modernen Exchange Server Versionen.
Anwender leben in der Illusion, dass die Zustellung von E-Mail-Nachrichten eine einfache Sache ist und haben meist kein Verständnis für eine verzögerte Zustellung von Nachrichten. In Zeiten von Gigabit-Leitungen und schier unerschöpflicher Computer-Ressourcen hat man sich daran gewöhnt, dass Nachrichten nahezu in Echtzeit übertragen werden.
Einen wesentlichen Beitrag zu einer schnellen und fehlerfreien Verarbeitung leistet das korrekte Routing einer E-Mail-Nachricht. Damit eine Nachricht von Exchange Server fehlerfrei verarbeitet und zugestellt werden kann, ist eine fehlerfreie Active Directory Gesamtstruktur unerlässlich. Die im Exchange Transportdienst aktiven Routing-Agenten arbeiten mit den Informationen, die im Active Directory gespeichert sind. Dies sind u.a.:
Beim Routing einer Nachricht spielt auch die Nachrichtengröße eine Rolle. Exchange zieht mehrere Konfigurationen zu maximalen Nachrichtengröße in Betracht, um so zu bewerten, ob die Nachricht auch wirklich zugestellt werden kann. Kann eine Nachricht nicht zugestellt werden, erhält der Absender einen sog. Non-Delivery Report (NDR). Der Transportdienst betrachtet für die Ermittlung der erlaubten Nachrichtengröße die Konfigurationen auf Organisationsebene, die aller Sende- und Empfangskonnektoren der internen Verbindungsstrecke und die Einstellungen des Zielpostfaches.
Sendekonnektoren arbeiten die Nachrichten in den Warteschlangen ab und versuchen das jeweilige Zielsystem mit den Konnektoreinstellungen zu erreichen. Eine korrekte DNS-Namensauflösung ist der Schlüssel zu einer fehlerfreifunktionierenden Exchange Infrastruktur. Die interne Namensauflösung ist selten eine Fehlerquelle. Anderes sieht es aus, wenn es um die DNS-Auflösung externer Domänen geht. Stellen Sie sicher, dass Ihre Exchange Server auch externe Domänen effizient und sicher auflösen können, um einen fehlerfreien Nachrichtenfluss mit externen Empfängern zu gewährleisten.
Kommt es beim Versuch einer Zustellung zu einem Fehler, wird der Fehler in der Warteschlange festgehalten. Im Regelfall erkennen Sie Zustellfehler am Anwachsen einer oder mehrerer Warteschlangen. Die Überwachung der Warteschlangengröße ist unerlässlich für einen stabilen Betrieb der Exchange Organisation.
Bedenken Sie, dass die Datenbank des Transportdienstes im Installationspfad eines Exchange Servers platziert ist. Wenn Ihre Exchange Server eine hohe Anzahl von Nachrichten verarbeiten muss, sollten Sie die Datenbank auf einem separaten und ausreichend dimensionierten Laufwerk platzieren.
Der Exchange Server Nachrichtenfluss ist, wenn man unter die Motorhaube schaut, ein komplexes Gebilde. Mit einem richtig konfigurierten Active Directory sind keine Probleme beim Betrieb von Exchange Server zu erwarten. Die Herausforderungen für den Exchange Nachrichtenfluss beginnen mit der Anpassung der Exchange Konfiguration.
Gerade im Hinblick auf die Konfiguration von zusätzlichen Empfangskonnektoren müssen Sie sich immer fragen, ob Sie einen neuen Konnektor wirklich benötigen. Das Troubleshooting des Exchange Nachrichtenflusses ist nicht schwierig, jedoch zeitaufwendig. Gerade in Exchange Umgebungen, die seit einigen Jahren betrieben werden und mehrere Exchange Versionen gesehen haben, besteht ein Risiko, dass veraltete Einträge in der Konfigurationspartition den Betrieb stören. Gleiches gilt für die Exchange Empfängerobjekte. Eine regelmäßige Pflege vermeidet Störungen im Nachrichtenfluss.
Der tägliche Betrieb Ihrer Exchange Organisation wird durch ein proaktives Monitoring, in dem nicht nur der Nachrichtenfluss überwacht wird, einfacher. Neben der Überwachung der Warteschlangen, empfehle ich auch die Überwachung der Transportdienste selbst. Exchange Server verfügt mit der Funktion der Managed Availability zwar über eine integrierte Monitoring Lösung mit automatischen Recovery-Aktionen, jedoch möchten Sie sicher nicht von automatisch neustartenden Diensten überrascht werden.
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.
Die Virtualisierung von Exchange ist nicht neu und war bereits seit Exchange 2003 mit VMware eine Option, obwohl es damals von Microsoft keine offizielle Unterstützung hierzu gab. Im Rahmen des Microsoft Server Virtualization Validation Program (SVVP) wurde die Virtualisierung von Exchange 2007 Service Pack 2 auf VMware ESX 3.5 Update 2 erstmal offiziell voll unterstützt.
Mit der Veröffentlichung von Exchange Server 2010 wurden alle Serverrollen (Unified Messaging ab Exchange 2010 SP1) auf allen SVVP validierten Hypervisor-Plattformen unterstützt. Die Unterstützung der Virtualisierung von Exchange Server 2010 wurde aber nur langsam adaptiert, da dies eine grundlegende Änderung im Design und der Architektur der Systeminfrastruktur mit sich brachte. Viele Systemadministratoren misstrauten der Virtualisierung und führten häufig die fehlende "Performance" als primären Grund an, sich gegen die Virtualisierung zu entscheiden. Interessant ist, dass "Performance" als genereller Begriff verwendet wurde (wird), um die Virtualisierung von Exchange Systemen abzuwenden. Die technologische Weiterentwicklung von Exchange und die stete Reduzierung der Anforderungen an Speichermedien in Bezug auf den erforderlichen Datendurchsatz, denn diese waren in der Vergangenheit der einzige Grund, sich gegen die Virtualisierung zu entscheiden, wird teilweise immer noch ignoriert.
Mit Exchange Server 2013 können alle Rollen problemlos virtualisiert werden und ermöglichen so eine optimale Ausnutzung der Hardware-Ressourcen in Ihrem Rechenzentrum.
Trotzdem ist es erforderlich, eine Exchange Umgebung korrekt und gewissenhaft zu planen und zu berechnen. Dies hat sich mit der Virtualiserungsoption für Exchange nicht geändert. Nur mit einer gewissenhaften Planung können komplexe Änderungen der Exchange-Landschaft zu einem späteren Zeitpunkt vermieden werden. Exchange Server 2013 besteht aus folgenden Serverrollen:
Die erfolgte Reduzierung von vier Serverrollen in Exchange 2007/2010, hin zu zwei Serverrollen, wenn wir die Edge-Rolle einmal als Sonderfall betrachten, erleichtert die Konzeption einer virtualisierten Exchange-Umgebung erheblich.
Wenn es um das Thema Virtualisierung von Enterprise-Applikation geht, einmal ganz ohne den Fokus Exchange, muss immer geklärt werden, wie die Hochverfügbarkeit (HA) der Applikation gewährleistet wird. Auf der einen Seite existieren HA-Funktionen in der jeweiligen Hypervisor-Plattform selber, auf der anderen Seite stehen die HA-Funktionen der Applikationen. Naiv gesehen könnte man annehmen, dass beides zusammen das Maximum an Hochverfügbarkeit bieten würde. Dies ist jedoch nicht der Fall.
Gerade für den Fall eines Support-Calls mit Microsoft ist es wichtig, dass Exchange in einer Konfiguration betrieben wird, die auch zu 100% unterstützt wird.
Für die Virtualisierung von Exchange Server 2013 gilt es Folgendes für einzelnen Systemkomponenten zu beachten
Exchange Server 2013 kann ebenso wie Vorgängerversionen als Multi-Role Server (Mailbox- und CAS-Rolle auf einem Server) oder als Single-Role Server (Mailbox-Rolle und CAS-Rolle auf separaten Systemen) installiert werden. So wie Exchange Rollen selber aufgeteilt werden können, können auch physische und virtuelle Systeme verteilt betrieben werden.
Natürlich können (sollten) auch die benötigten Load Balancer virtualisiert betrieben werden. Die möglichen Kombinationen mit den o.g. Exchange-Konfigurationen sind zahlreich und werden in diesem Artikel vernachlässigt.
Grundsätzlich gilt die Empfehlung, für das Sizing einer Exchange 2013 Umgebung (physisch oder virtuell), den Exchange 2013 Server Role Requirements Calculator zu verwenden. An diesem Tool führt kein Weg vorbei, wenn man eine verlässliche Aussage zu den Anforderungen für die Exchange Umgebung erhalten möchte. In den aktuellsten Versionen sind notwendige Berechnungskorrekturen für die Virtualisierung bereist enthalten. Microsoft geht von einem zusätzlichen Overhead durch den Hypervisor von 10% aus. VMware wiederum geht von ca. 2% bis 5% Overhead aus.
Wie bereits erwähnt, ist eine 1:1 Zuordnung von virtuellen CPU Cores zu physischen CPU Cores zu empfehlen, da dies die Umsetzung der kalkulierten Anforderungen in den laufenden Betrieb stark vereinfacht.
Microsoft hat empfiehlt beim Einsatz von Exchange Server (2010 und 2013) auf das Hyper-Threading der CPUs zu verzichten. Wichtig ist, dass Hyper-Threading CPUs nicht gleichzusetzen sind mit physischen CPUs. Als Hauptgrund wird angegeben, dass dies die CPU Planung unnötig verkompliziere. Als zweiter Grund wird die .NET Garbage Collection angeführt, die auf Basis der CPU Anzahl arbeitet und entsprechend Arbeitsspeicher allokiert. Durch Hyper-Threading wird allerdings unnötig viel Arbeitsspeicher für die Garbage Collection reserviert.
Im Rahmen einer Virtualisierung besteht das beschriebene Problem nicht im gleichen Ausmaß, wie in einer physischen Umgebung, da der VM eine feste Anzahl an Prozessoren zugeordnet ist. Dies bedeutet, dass Sie das für Ihre Umgebung passende Processor-Ratio finden müssen, wenn Sie nicht der 1:1 Zuordnung folgen möchte. Dies gelingt am besten, indem Sie mit einer 1:1 Zuordnung beginnen und mit einer System-Monitoring Lösung eine Baseline erstellen. Anschließend passen Sie die Prozessorzuordnung an und vergleichen die Auslastung- und Performancediagramme mit der Baseline.
Die nachfolgende Tabelle listet die Mindestanforderungen an Arbeitsspeicher für Exchange Server 2013
Dies sind die absoluten Mindestanforderungen. Ohne Verwendung des Role Requirements Calculators wird eine korrekte Planung für den performanten Betrieb von Exchange nicht gelingen.
Für einen Exchange Mailbox-Server mit 1000 Postfächern mit einem Anwenderprofil von 150 gesendeten und empfangenen Nachrichten pro Tag und einer Anforderung von 36MB Datenbankcache pro Postfach, benötigen Sie bereits mindestens 36GB Arbeitsspeicher. Ergänzend zum Role Requirements Calculator empfehle ich den Blog-Artikel "Ask the Perf Guy: Sizing Exchange 2013 Deployments" (http://bit.ly/PerfGuyExchange2013Deployments).
Ergänzend zu den Speicheranforderungen für Exchange Server 2013 müssen noch 4GB bis 8GB für das Betriebssystem addiert werden.
Für die Planung der Netzwerkverbindungen der virtuellen Systeme gelten die gleichen Anforderungen wie für physische Exchange Server. Exchange Server, die nicht Mitgliedsserver einer DAG sind, können mit einem einzelnen Netzwerkadapter konfiguriert werden. Mitgliedsserver einer DAG sollten immer mit zwei Netzwerkadaptern konfiguriert werden, um die Datenbankreplikation über ein separates Netz zu leiten und vom allgemeinen Zugriff auf die Postfachdatenbanken zu trennen. Der Einsatz von einzelnen Netzwerkadaptern ist zwar unterstützt, sollte sich aber auf Test- und Laborumgebungen beschränken.
Die physischen Netzwerkadapter im Host-System können durch Teaming ausfallsicher konfiguriert werden.
Das nachfolgende Beispiel zeigt, wie ein Exchange 2013 Mailbox Server, der Mitgliedserver einer DAG ist, und ein CAS Server nur durch VLANs getrennt an einem virtuellen Switch verbunden sind. Der virtuelle Switch ist durch NIC-Teaming im Hypervisor redundant mit der physischen Netzwerk Infrastruktur verbunden.
Mit der gleichen Exchange Server-Konstellation kann aber das DAG Netzwerk-Interface zur Datenreplikation über einen separaten virtuellen Switch, der über ein eigenes NIC-Interface im Hypervisor verfügt, mit einem dedizierten Replikationsnetzwerk verbunden werden.
Die zweite Konfiguration stellt sicher, dass die Datenreplikation in einem dedizierten physischen Netzwerk stattfindet. Jedoch erhöht dieser Lösungsansatz auch die Komplexität der Netzwerkinfrastruktur selber. Hinzu kommt, dass standardmäßig das MAPI Netzwerk als Backup für einen möglichen Ausfall des Replikationsnetzwerkes verwendet wird. Wenn Sie ausschließen möchten, dass das MAPI Netzwerk als Backup-Netzwerk verwendet werden kann, müssen Sie die Hochverfügbarkeit des Replikationsnetzwerkes sicherstellen.
In VMware Umgebungen empfiehlt es sich, immer den VMXNET3 Adapter für die virtuellen Maschinen zu verwenden, da der E1000 Adapter im Host-System nur CPU 0 für die Emulation verwendet. Die Nutzung des VMXNET3 Adapters bietet somit eine deutlich bessere Performance gegenüber dem E1000 Adapter.
Ganz unabhängig von der gewählten virtuellen Netzwerkkonfiguration muss immer sichergestellt werden, dass die Host-System sowohl in der Hardware-seitigen, als auch in virtuellen Netzwerkkonfiguration identisch konfiguriert sind. Die virtuellen Gast-Systeme können schließlich nur zwischen Hosts verschoben werden, die auch die notwendigen Ressourcen (virtuelle Switche, VM Port Groups, etc.) zur Verfügung stellen.
Die Bereitstellung des notwendigen Festplattenspeichers für virtualisierte Exchange Server 2013 Systeme bietet vielfältige Optionen. Die rein physischen Optionen, wie z.B. Bereitstellung von Raw LUNs, die in einem SAN Speicher konfiguriert sind, oder VMDK, VHD/VHDX Dateien im SAN oder im DAS, oder aber die direkte Einbindung der Datastore-Volumes per iSCSI im Gast-Betriebssystem selber, unterliegen den Möglichkeiten und Anforderungen Ihrer Unternehmensumgebung. Manchmal unterliegt die Auswahl des Speichermediums aber auch internen politischen Richtlinien, durch die bestimmt wird, dass ein "teurer" SAN Speicher verwendet werden muss, obwohl dies durch die Anforderungen von Exchange Server 2013 selber gar nicht mehr notwendig ist. Eines der Arguments für die Migration zu Exchange Server 2013 ist die Unterstützung von günstigen JBOD Enclosures, die sehr große Datenspeicher sehr günstig (im Vergleich zu klassischem SAN Speicher) bereitstellen können.
Hier muss eine sehr genaue Abwägung zwischen technischem Vorteil/Nutzen und dem zusätzlichen Aufwand und der zusätzlichen Komplexität in der Umgebung für Speichersubsysteme erfolgen. Es ist meist schwierig, die Einführung einer neuen Technologie nur mit den Anforderungen einer einzigen Applikation zu begründen. Es ist hilfreich zu prüfen, ob nicht auch andere Applikationen, die in naher Zukunft migriert werden sollen (z.B. von SharePoint 2010 auf SharePoint 2013), von dem neuen Speichermedium profitieren können. Eine stärkere strategische Ausrichtung hilft bei der Argumentation sehr.
Zusammenfassend kann man sagen, dass die Virtualisierung eine große Flexibilität im Sizing und im Betrieb einer Exchange Plattform mit sich bringt. Jedoch birgt eine Virtualisierung schnell auch Risiken. Dieses Risiken wirken sich nicht unbedingt auf den sicheren Betrieb von Exchange aus, sondern vielmehr auf die Reaktionszeit, also die Performance der Exchange Umgebung.
Grundsätzlich darf man aber nicht vergessen, dass gemessene Performance nicht gleichzusetzten ist, mit subjektiv gefühlter Performance. Insbesondere Endanwender sind sehr empfindlich und reagieren kritisch, wenn "Ihr" Outlook nicht in der gleichen Zeitspanne startet, wie "gestern". Ähnlich sieht es aus, wenn Nachrichten durch mangelhafte Ressourcenverfügbarkeit zu lange in einer Warteschlange verweilen, bevor sie zugestellt werden. Auch wenn Administratoren wissen, dass E-Mail (oder besser SMTP) ein Warteschlangen-basierende Kommunikation ist, ist dies Endanwendern meist nur sehr schwer zu vermitteln.
Viel Spaß bei der Virtualisierung von Exchange Server 2013.
Mit dem De-Mail Gesetz vom 28. April 2011 sollte ein neues Zeitalter der sicheren und verschlüsselten E-Mail Kommunikation zwischen Behörden, Unternehmen und Bürgern eingeläutet werden. Das Gesetz regelt die De-Mail-Dienste, die Akkreditierung von De-Mail-Anbietern, die Durchführung der Aufsicht und den Zugang zu De-Mail. De-Mail wurde mit der Intention ins Leben gerufen, die Verbreitung der Ende-zu-Ende Verschlüsselung zwischen E-Mail-Absendern und -Empfängern zu fördern.
Aktuell werden De-Mail-Dienstleistungen von vier Anbieter bereitgestellt:
Der Erwerb einer eigenen De-Mail-Domäne, wie z.B. varunagroup.de-mail.de, ist für Unternehmenskunden nur über einen der akkreditierten Anbieter möglich. Nach Erwerb der De-Mail-Domäne ist auch eine Gateway-basierende Anbindung für den Versand und Empfang von De-Mail-Nachrichten über diesen Anbieter möglich. Der Anbieter selber stellt hierbei die E-Mail-Verschlüsselung nach De-Mail-Standard sicher.
Die Informationen zum Erwerb einer De-Mail-Adresse bzw. De-Mail-Domäne ist bei den vier akkreditierten Anbietern unterschiedlich gut auffindbar.
Bei 1&1 ist das Produkt De-Mail relativ gut in der zweiten Menüebene zu finden. 1&1 versucht De-Mail Kunden mit einem finanziellen Einsparpotential gegenüber normaler Post zu locken. Hier ist allerdings bisher niemandem aufgefallen, dass mit leicht veralteten Zahlen auf den Jahren 2007, 2008 und 2010 gearbeitet wird. Ein De-Mail-Gateway, zur Integration in die IT-Infrastruktur wird für Unternehmenskunden augenschainlich nicht angeboten.
Mentana-Claimsoft räumt dem Produkt De-Mail mehr Aufmarksamkeit ein. De-Mail ist der erste Menüpunkt der Hauptnavigation. Die bereitgestellten Informationen lassen darauf schließen, dass Unternehmenskunden die Hauptzielgruppe sind. Es werden zwei unterschiedliche Optionen für eine De-Mail-Anbindung angeboten. Die erste Option besteht aus einer Gateway-Software-Lösung, die auf Java-Runtime 1.6 (32-bit) basiert und nur, laut Dokumentation, ältere Windows-Betriebssysteme, wie Windows 7/8 oder Windows Server 2008R2/2012, unterstützt. Als zweite Anbindungsvariante steht eine Web Service Integration zur Verfügung, für die allerdings eine Testintegration angefragt werden muss. Eine Bestellung kann über die Webseite nicht ausgelöst werden. Vielmehr darf man sich telefonisch an das Service Center De-Mail wenden.
Die T-Systems International GmbH versteckt De-Mail in der vierten Menüebene. Auf dem Weg in diese Ebene (Lösungen -> Security -> Lösungen -> De-Mail) trifft man auf aktuelle Buzz-Words zum Thema Cloud. Auch bei T-Systems wird zuerst mit dem preislichen Vorteil gegenüber der klassischen Briefpost geworben. Auf der Seite wird viel und bunt über De-Mail geschrieben und auf eine weitere Unterseiten verlinkt. Ein direkter Link zum Erwerb einer De-Mail-Domäne ist nicht auffindbar. Der Erwerb einer De-Mail-Domäne scheint nur in einem Beratungstermin möglich.
Die Telekom Deutschland GmbH bietet ebenfalls das Produkt De-Mail an. In der Menüstruktur der Hauptseite sucht man De-Mail allerdings vergebens. Das Produkt ist im Bereich des Menüpunktes Cloud & IT versteckt (Cloud & IT -> Sicherheit & Effizienz -> Für Daten & Mails) und befindet sich dort auf der Detailseite neben der Mobile Encryption App und BusinessMail X.400. Der einladende Link Jetzt Bestellen führt leider nicht zu einer Online-Bestellung, sondern zu einer Übersichtsseite für PDF-Formulare, um diese herunterzuladen und per Fax zurückzusenden. Die Telekom bietet unterschiedliche Leistungspakte für Geschäftskunden an. Man kann De-Mail ohne eigene Gateway-Lösung über das Web-Portal (einfache Variante) oder mit dem De-Mail-Gateway (Profi-Variante) nutzen. Der Erwerb einer De-Mail-Domäne ist bei der Telekom nur über die Nutzung von PDF-Formularen möglich.
In einem Kundenprojekt konnte ich Erfahrungen mit De-Mail und der Anbindung mit dem E-Mail-Security-Gateway NoSpamProxy sammeln. Der Vorteil dieser Lösung ist, dass kein separates De-Mail-Gateway, dass von den Anbietern in Eigenregie entwickelt wurde, implementiert und betrieben werden muss. Stattdessen wird ein ausgereiftes E-Mail-Gateway Produkt verwendet, dessen De-Mail-Integration per Web Services auf die Schnittstelle des ausgewählten De-Mail-Anbieters zu greift. So ist der De-Mail-Versand in den regulären E-Mail-Verkehr eingebettet und durchläuft alle E-Mail-Prozesse für zentrale Signaturen und rechtssichere Archivierung.
Als Bestandkunde der Telekom lag es natürlich nahe, die De-Mail-Domäne über die Telekom Deutschland GmbH zu beziehen.
So beginnt die Reise...
Aber alles beginnt mit der Registrierung einer De-Mail-Domäne, um im E-Mails im Format info@varunagroup.de-mail.de versenden zu können. Wie schon erwähnt, öffnet ein Klick auf die Schaltfläche Jetzt Bestellen, auf der Telekom De-Mail-Webseite, eine eindrucksvolle Liste von PDF-Formularen.
Vergebens suchte man eine PDF-Nutzungsanleitungsbeschreibung. Aber das Formular mit dem Titel Auftrag für ein Business De-Mail-Konto sah vielversprechend aus.
Randnotiz: Interessant ist, dass diese Formulare unter dem Punkt Ihre Vorteile im Überblick verortet sind.
Im PDF-Formular wird glücklicherweise der Zweck des Formulars beschrieben: Mit diesem Formular können Sie ein De-Mail Konto beauftragen
Das Ausfüllen fiel nicht sonderlich schwer . Das ausgefüllte und unterschriebene Formular fand, inklusive zusätzlich benötigter Dokumente, anschließend seinen Weg per Fax an die im Formular genannte Faxnummer.
Danach passierte erst einmal... nichts.
Am 19. April schrieb ich eine freundliche E-Mail an den Geschäftskunden-Service der Telekom, in der ich die Situation schilderte und um Mithilfe bei der Identifikation der Telekom-internen Ansprechpartner für das Thema De-Mail bat. Die Reaktion erfolgte prompt. Meine Original-E-Mail wurde, um einen kleinen Hinweis ergänzt, an das De-Mail-Team (De-Mail@telekom.de) weitergeleitet.
Auf diese E-Mail erfolgte eine telefonische Kontaktaufnahme durch das De-Mail-Team der Telekom. Die Grundinformation des Telefonats war leider ernüchternd. Es lag keine Beauftragung per Fax vor.
Am 24. April wurde der Antrag auf eine De-Mail-Domäne als PDF-Dateianhang, mit der Bitte um eine Auftragsbestätigung, an das De-Mail-Team der Telekom per E-Mail (S/MIME signiert) gesendet. Die erfolgreiche SMTP-Zustellung wurde im E-Mail-Gateway protokolliert.
Danach passierte erst einmal - nichts.
Am 24. Mai wurde der Antrag auf eine De-Mail-Domäne als PDF-Dateianhang, mit der Bitte um eine Auftragsbestätigung, zum dritten Mal an das De-Mail-Team der Telekom per E-Mail (S/MIME) gesendet. Die erfolgreiche SMTP-Zustellung wurde abermals im E-Mail-Gateway protokolliert.
Es ist immer noch nichts passsiert. Keine Reaktion per Telefon, per E-Mail oder per Post.
Ich kann mich des Eindrucks nicht erwehren, dass die Telekom keine Neukunden für den Dienst De-Mail gewinnen möchte. Der Dienst scheint eine Art lästiges Pflichtprogramm zu sein. Auch das wäre zu verstehen, wenn es eine angemessene Reaktion des De-Mail-Teams geben würde.
Die Untätigkeit auf der Anbeiterseite verleitet naturgemäß zu Aktionismus. Nachdem ich heute den Telekom Login erneutet habe, stolperte ich in der Vertragsübersicht über die Option, sich doch direkt für De-Mail Web zu registrieren bzw. einen Beratungstermin für das De-Mail Gateway zu vereinbahren.
Leider führt der Link Beratung vereinbaren auf die bereits bekannte Seite zur Digitalisierung meiner Post. Der auf dieser Seite befindliche Link Jetzt Bestellen leitet mich wieder zu den PDF-Formularen und ist somit eine Sackgasse.
Ist es Zufall, dass sich die aktuelle Ausgabe (Juli 2018) der brand eins mit dem Thema Service befasst?
Der Monatstitel des Magazins ist
Die Wüste lebt.
Gestern hat mich die Deutsche Telekom angerufen. Man hätte gehört, dass ich Probleme mit der Beauftragung einer De-Mail-Domäne hätte. (Frei zitiert)
Nach Angabe der Telekom Kundennummer hat man mir versprochen, dass sich ein Berater für De-Mail in der nächsten Woche telefonisch bei mir melden wird, da ich ja nicht die Standardlösung betreiben möchte, sondern eine De-Mail-Dirttanbieterlösung (in diesem Fall NoSpamProxy).
Ich bin gespannt...
Freitag der 13. muss nicht immer ein Tag für ein schlechtes Omen sein. Heute hat mich ein De-Mail-Berater von T-Systems angerufen. Er hat mir in einem sehr ausführlichen Telefonat die Herausforderungen der De-Mail-Bestellprozesse dargelegt (was sehr unterhaltsam war). Um nun eine schnelle Beauftragung in die Wege leiten zu können, läuft die Beauftragung nun nicht über die Telekom Deutschland, sondern über die T-Systems. Schon wenige Minuten nach dem Telefonat fanden die vorausgefüllten Auftragsformulare ihren Weg in den Posteingang meines E-Mail-Postfaches.
"De-Mail Auftragsbestätigung"
Ich hätte nicht gedacht, dass ich diesen E-Mail-Betreff noch einmal lesen darf. Nachdem ich heute die ausgefüllten und unterschriebenen Dokumente per E-Mail an den De-Mail-Berater bei der T-Systems gesendet hatte, dauerte es weniger als zwei Stunden, bis der Auftrag im T-Systems Buchungssystem erfasst war und ich die Bestätigung erhielt.
Nun bedarf es nur noch der Umsetzung des Auftrages.
Inzwischen sind alle notwendigen Unterlagen und Gerätschaften (Signaturkarten inkl. Lesegerät, Software) eingetroffen. Ich konnte mich erfolgreich am T-Systems De-Mail Webportal anmelden und die erste De-Mail erfolgreich versenden. Sehr positiv zu bewerten ist, dass die Multi-Faktor Authentifizierung sofort funktioniert hat.
Die Nutzung des De-Mail Web Portals ist natürlich kein Dauerzustand. Ziel ist die Integration in den normalen E-Mail-Workflow und die direkt Nutzung aus dem Outlook-Client heraus. Hierzu werde ich die vorhandene E-Mail-Gateway-Lösung NoSpamProxy an die T-Systems De-Mail Web Service Schnittstelle anbinden und das NoSpamProxy Outlook Add-In verwenden. Diese Konfiguration wird von einem separaten Blog-Artikel begeleitet.
Mein persönlicher Eindruck ist, dass die vier akkreditierten Anbieter das Produkt De-Mail vor potentiellen Kunden verstecken möchten. Vor dem Hintergrund, dass die Bundesregierung, als Wegweiser und Urheber eines digitalen Fahrplanes, immer noch auf das Thema De-Mail setzt und De-Mail sogar aus dem Ausland nutzbar machen möchte, ist dies eine Farce.
Man stellt sich als Geschäftskunde zwangsläufig die Frage, warum der Prozess für De-Mail so kompliziert sein muss und wer sich dieses Prozessmonster ausgedacht hat.
An meinem grundlegenden Fazit hat sich nichts geändert. Die Schwierigkeit bei der Beauftragung von De-Mail für Unternehmen liegt darin, einen kompetenten Ansprechpartner zu identifizieren. Wenn man diese Hürge genommen hat geht es recht zügig weiter. Im Rahmen einer De-Mail Beauftragung ist natürlich auch eine Verifizierung der Identität des Beauftragendfen erforderlich. Interessanterweise stehen die gängigen Methoden zur Überprüfung nicht zur Verfügung. In diesem Fall erweisen sich das BSI und das BKA als Bremser der De-Mail und nicht die akkreditierten Anbieter.
Die folgenden Ident-Methoden stehen nicht zur Verfügung:
Mögliche Ident-Methoden sind:
Es bleibt somit weiterhin kompliziert.
Trotz alledem - Viel Spaß mit De-Mail
Wenn Sie Fragen zum Thema De-Mail haben, freue ich mich über eine E-Mail: thomas.stensitzki@granikos.eu
Exchange Server ist eine der erfolgreichsten Serverlösungen von Microsoft, obwohl das Produkt immer wieder funktionale Lücken hinsichtlich Sicherheit, Archivierung, Datensicherung/Wiederherstellung, Überwachung und Berichterstellung hatte. Einige dieser funktionalen Lücken existieren selbst in der aktuellen Version Exchange Server 2019. Infolgedessen entwickelte sich rund um Exchange Server über die Jahre ein Ökosystem von Softwarelösungen, um diese Lücken zu schließen und den gewünschten Mehrwert zu bieten.
Selbst mit einem Wechsel zu Exchange Online besteht weiterhin Bedarf für eine bessere Überwachung und Berichterstellung. Microsoft bietet für Exchange Online nur einige rudimentäre Ansätze, die Administratoren nicht die Informationen bieten, die wirklich benötigt werden. Diese Informationslücken schließt ENow mit Mailscape 365 und liefert einen umfassenden Einblick in den Betrieb von Exchange Online und Microsoft 365.
ENow Software ist kein Neuling am Markt der Monitoring-Lösungen für Microsoft Serverprodukte. Ich kenne das Unternehmen und die Lösungen bereits seit mehr als zehn Jahren. Mich beeindruckt die Entstehungsgeschichte von ENow. Jay Gundotra, Gründer und Exchange-Geek, startete mit seinem Unternehmen nicht mit dem Anspruch ein Softwareanbieter zu sein. Die erste Lösung entstand durch den Bedarf, den er während seiner Arbeit als Service-Anbieter für Exchange sah. Es fehlte eine Monitoring-Lösung, die alle notwendigen Informationen in einem Dashboard zusammenfasst und so einen schnellen Überblick über den aktuellen Betriebsstatus ermöglicht.
Hieraus entwickelte sich das bekannte OneView-Dashboard des ENow Management Systems, mit dem eine ganze Plattform übersichtlich dargestellt und überwacht werden kann. Rot blinkende Signale und die Möglichkeit des Drill-Downs ermöglichen eine schnelle Identifikation von Problemen. Die Lösung wurde unter der Maßgabe entwickelt, so zu funktionieren, wie ein Administrator denken würde, um ein Problem zu identifizieren und zu beheben. Man muss nur der Spur der roten Ampelsignale folgen, um die Ursache zu finden. Dies Einfacheit ist der Grund, warum Network Operating Center (NOC) zahlreicher Unternehmen auf diese Lösung setzen. Die ENow-Lösung wurde und wird auf der Basis von Feedback aus der Exchange-Community stetig entwickelt. Unternehmen in über 130 Länder auf der ganzen Welt, wie z.B. VMware, Wendy’s und Facebook, vertrauen der Lösung.
Auf ENow und Mailscape bin ich im Jahr 2009, während eines Exchange Migrationsprojektes, gestoßen. Seinerzeit löste die Software das alltägliche Problem des Monitorings von lokalen Exchange Server Plattformen. Über die Jahre hat ENow den Umfang der Monitoring-Lösung weiterentwickelt, um immer komplexere Anforderungen und mögliche Probleme im Betrieb von Exchange Server zu überwachen, z.B. wurde die Lösung um das Monitoring von Active Directory Gesamtstrukturen ergänzt. Es darf nicht vergessen werden, dass Exchange Server eine sehr tolerante Serverlösung ist und in ganz unterschiedlichen Konstellationen betrieben werden kann. Dies birgt naturgemäß besondere Herausforderungen für das Monitoring.
Der Wert einer Plattformüberwachung mit der ENow Monitoring-Lösung wird deutlich, wenn wir uns drei beteiligte Job-Rollen, mit ganz unterschiedlichen Interessen, anschauen. So erkennen Sie vielleicht einen vertrauten Anwendungsfall aus Ihrer eigenen Betriebsumgebung wieder.
In einer lokalen IT-Infrastruktur haben IT- und Exchange-Administratoren meist eine gute Monitoring-Übersicht über Server und Dienste. Das Standard-Monitoring wird, aufgrund fehlender Integration, oft durch zusätzliche Tools ergänzt, um neben einem klassischen System-Monitoring auch ein Applikations-Monitoring zu ermöglichen.
Bei einem Wechsel zu Microsoft 365 und Exchange Online ist die Frustration auf Administrator-Seite groß. Es besteht keine Möglichkeit mehr, sich mal schnell per RDP auf einem Server anzumelden, um ein Problem zu identifizieren und zu beheben. Gleichzeitig ist der Druck unverändert hoch, bei einer Störung das Management und die Mitarbeiter informieren zu müssen. Das Microsoft 365 Admin Center stellt keine zeitnahen Informationen zum aktuellen Dienststatus bereit. Störungen, die früher schnell als Dienst- oder Hardwarestörungen identifiziert werden konnten, verstecken sich nun in einer großen (dunklen) Wolke. Office 365 Störungen können den ganzen Dienst betreffen oder nur Teilbereiche oder einzelne Dienste. In den letzten Jahren haben wir unterschiedliche Ausfälle erlebt, die das Resultat von Azure AD- oder Azure DNS-Problemen waren und die Identitätsverwaltung oder den Zugriff auf die gesamte Microsoft 365-Plattform beeinträchtigten. Andere Ausfälle betrafen nur einzelne Dienste, wie z.B. Microsoft Teams, oder einzelne Komponenten, wie die jüngsten MFA-Ausfälle.
Der obige Screenshot des ENow Dashboards zeigt, dass Microsoft Teams und SharePoint Online für Anwender in Salzburg gestört sind (3), jedoch nicht für Anwender in Wien. Die allgemeine Verfügbarkeit in Office 365 ist nicht gestört (1). Es scheint sich um ein lokales Netzwerkproblem zu handeln (2). Den Status der Dienstverfügbarkeit erkennen Sie auf einen Blick. Für ein international arbeitendes Unternehmen sind rollierende Störungen, bei denen Mitarbeiter einer Region nicht wie gewohnt arbeiten können, während andere Regionen keine Probleme haben, eine besondere Herausforderung. Denn dies stellt keinen direkter Ausfall von Office 365 dar.
In solch einem Fall fragt sich ein IT- oder Exchange-Administrator, „Haben WIR ein Problem, oder ist es ein Microsoft-Problem?“ Viele Überwachungslösungen betrachten nicht alle notwendigen Komponenten einer lokalen IT-Infrastruktur oder haben keine Kenntnis über die technischen Abhängigkeiten der eingesetzten Komponenten, wie z.B. beim Betrieb einer Hybrid-Konfiguration (AD FS, AAD Connect) und den erforderlichen Netzwerkverbindungen. Sie möchten sich nicht in der Situation wiederfinden, in der Sie denken, dass eine Störung durch ein Microsoft 365-Problem ausgelöst wurde, es sich aber in Wirklichkeit um eine Störung in Ihrer lokalen IT-Infrastruktur handelt.
Office 365 und Exchange Online verfügen über kein eigenständiges Monitoring je Mandanten. Bei einer offiziellen Störung gibt es für Administratoren keine Möglichkeit meistens keine schnelle und einfach Lösung, um den Grund der Störung zu ermitteln. Sie können keine Aussage darüber treffen, wer Schuld ist, welche Dienst gerade nicht verfügbar ist und für wen es Auswirkungen hat. Hier hilft ENow bei der Isolierung des Problems durch sog. Remote-Sonden und synthetische Transaktionen. Diese Funktionen imitieren Anwenderzugriffe auf Office 365-Dienste, wie z.B. Microsoft Teams. In einer cloudbasierten Welt benötigen Sie intelligentere Überwachungsfunktionen als eine „Dienst verfügbar/nicht verfügbar“-Lösung. Ebenso wichtig ist, sich nicht nur auf die Cloud-Endpunkte zu konzentrieren.
Die Verfügbarkeit der Office 365-Dienste ist zu einem großen Teil von der Funktionalität der lokalen Active Directory Gesamtstruktur und der Netzwerk-Infrastruktur abhängig. Da die ENow Lösung in Ihrer lokalen Infrastruktur betrieben wird, kann sie genau das leisten. Der Mehrwert liegt darin, dass Sie eine belastbare Aussage über den Grund der Störung abgeben können und sich nicht auf eine „Microsoft ist Schuld“-Begründung zurückziehen müssen, selbst wenn dies sehr bequem ist. Aber was ist, wenn der Fehler nicht bei Microsoft liegt, sondern bei Ihnen? Die Gründen hierfür sind vielfältig, wie z.B. abgelaufenen Zertifikate, ungewöhnlich hohe Netzwerklatenzen, AD FS Authentifizierungsfehler oder Azure AD Connect Synchronisationsprobleme, um nur einige zu nennen. Es ist kein eindimensionales Problem. Die von Ihnen gewählte Überwachungslösung für Office 365 muss mehrdimensional sein und auf die gleiche Weise testen, wie Anwender eine Verbindung zu den verschiedenen Office 365-Diensten herstellen.
Die oben dargestellte Störung signalisiert eine Störung von Microsoft Teams und SharePoint Online. Wenn Sie der Störungssignalisierung im Dashboard folgen, erhalten Sie die notwendige Sicherheit.
DIe Detailinformatiom zeigt, dass eine Störung beim Zugriff auf Microsoft Teams vorliegt.
Sie kennen die Schlagworte „digitaler Arbeitsplatz“, „digitale Transformation“ und all die anderen zu Genüge. Das gemeinsame Ziel ist die Einführung eines modernen Arbeitsplatzes und die umfassend integrierte Nutzung von Office 365. Ihr Unternehmen investiert mit den Abonnementkosten nicht nur in die Cloud-Plattform an sich, sondern auch in die Weiterentwicklung der Mitarbeiter. Daher ist es so wichtig, dass Sie wissen, wie die einzelnen Komponenten der Office 365-Plattform verwendet werden. Und hier spreche ich nicht nur von den Standardauswertungen, die Ihnen z.B. eine Microsoft Teams Nutzung vorgaukeln, nur weil Anwender einmal in dreißig Tagen Microsoft Teams gestartet haben.
Wenn Sie für die Einführung von Office 365 verantwortlich sind, sind Sie davon überzeugt, dass die Kommunikations- und Kollaborationssuite die Zusammenarbeit in Ihrem Unternehmen revolutionieren wird. Der Schlüssel hierzu ist jedoch, dass die Produkte der Office 365-Suite von allen Mitarbeitern angenommen und genutzt werden. Um eine breite Akzeptanz und Nutzung zu erreichen, muss Office 365 planvoll eingeführt und mit angemessenen Lernangeboten begleitet werden. Ein „probiert es einfach aus“-Ansatz wird scheitern. Sie benötigen ausführliche Berichte, wie die Office 365-Plattform von Anwendern genutzt wird. Dies dient auch der Erfolgskontrolle von Schulungen und Lernmaterialien.
Die Standardberichte der Office 365-Plattform geben Ihnen nur rudimentär Auskunft, meist stehen detaillierte Informationen nur per PowerShell zur Verfügung. Administratoren verfügen oftmals über das notwendige Knowhow, um diese Informationen abzurufen. Als Verantwortlicher für die Einführung von Office 365 benötigen Sie meist Hilfe, um die notwendigen Informationen zu erhalten und die Statusberichte für das Management zu erstellen.
Die ENow Mailscape 365 Suite verfügt über Hunderte von integrierten Berichten, die Sie für Ihre individuelle Bedürfnisse anpassen können. Ergänzt wird diese Lösung durch ein zentrales Repository für PowerShell-Skripte und einem Dashboard zur Verwaltung. Sie sehen z.B. nicht nur, ob Microsoft Teams selbst verwendet wurde, sondern auch wie viele Chat-Nachrichten gesendet wurden, wie viel Anrufzeit bereits aus dem Anrufguthaben genutzt wurde oder wie oft das Teilen von Bildschirminhalten eingesetzt wird. Mithilfe dieser Auswertungen stellen Sie schnell fest, ob es ein Problem mit den Schulungen und Schulungsinhalten gibt.
Bei einer einfach zu nutzenden Lösung wie OneDrive erkennen Sie, ob Personen überhaupt Dateien in ihrem persönlichen OneDrive-Speicher ablegen. Wenn dies nicht der Fall ist, ist dies ein Indikator, dass Anwender höchstwahrscheinlich eine Schatten-IT-Lösung wie Dropbox verwenden. Liegt das Problem nun darin, dass sich Anwender mit der neuen OneDrive-Lösung nicht wohlfühlen?
Mit dem Wissen über die Nutzung der Office 365-Suite können Sie proaktiv auf Ihre Schulungen einwirken und so sicherstellen, dass Ihre Mitarbeiter alle bereitgestellten Lösungen nutzen, für die das Unternehmen bezahlt.
Weitere Berichte geben Ihnen Auskunft darüber, welche Apps oder Geräte für den Zugriff auf die Office 365-Dienste verwendet werden. Erfolgt der Postfachzugriff mit Outlook für Desktop, Outlook on the Web oder die Outlook Mobile App? Welches Betriebssystem oder welches Endgerät kommt zum Einsatz? Ähnliche Auswertungen stehen für Microsoft Teams und andere Dienste zur Verfügung. Auf Basis dieser Informationen können Sie entscheiden, ob bestimmte Apps und Geräte in Schulungen stärker berücksichtigt werden müssen. Wenn Sie feststellen, dass mehr Personen iOS- oder Android-Apps für den Zugriff auf Office 365 Dienste verwenden, können Sie Ihren IT-Support für diese Nutzungsszenarien optimieren.
Die Lizenzierung von Office 365 ist ein bisschen wie ein schwarzes Loch und es ist nicht ungewöhnlich, dass ein Unternehmen mehr zahlt, als notwendig ist. Dies können im Einzelfall Tausende von Euros sein.
Genauso wie Nutzungsinformationen, werden Lizenzinformationen in Office 365 nicht sinnvoll dargestellt. Oberflächlich betrachtet, denken Sie möglicherweise, dass Ihre Lizenzierung richtig dimensioniert ist. Stellen Sie sich vor, dass von zugewiesenen 1.000 Microsoft 365 E5-Lizenzen nicht alle inkludierten E5-Funktionen durch die Anwender genutzt werden. Stattdessen wäre eine Microsoft 365 E3-Lizensierung für z.B. 300 Anwender vollkommen ausreichend. Bei einer Preisdifferenz EUR 22,00 je Anwender und Monat, könnten Sie EUR 79.920,00 pro Jahr einsparen, ohne dass sich dies auf die zur Verfügung stehenden Funktionen auswirkt.
Die richtige Lizensierung bietet ein großes Potential zur Kostenoptimierung und ist daher von großem Interesse für Software-Asset-Management Teams. Wenn Sie jedoch für die Einführung von Office 365 verantwortlich sind, möchten Sie die Lizensierung gar nicht erst reduzieren. Sie möchten viel lieber sicherstellen, dass die Anwender die lizensierten Funktionen ausgiebig nutzen.
Ein weiteres Problem sind überlappende Lizenzen. Kennen Sie alle Produkte und Dienste, die in einer E3- oder E5-Lizenz enthalten sind? Wahrscheinlich nicht. Es ist also möglich, dass Sie eine Lizenz für eine Add-On-Funktion kaufen und verwenden, die bereits in der E3- oder E5-Lizenz eines Anwenders enthalten ist? Sie erhalten bei der Zuweisung einer Add-On-Lizenz keinen Warnhinweis, dass diese Funktion dem Anwender bereits zur Verfügung steht. Möglicherweise gibt es bei Ihnen auch Anwender, die Visio Online oder Project Online benötigen, so dass Sie Lizenzen für diese Anwender erwerben. Aber vielleicht gibt es gleichzeitig andere Anwender, denen eine Visio Online- oder Project Online-Lizenz zugewiesen ist, diese aber gar nicht verwenden. Das Auffinden dieser Art von inaktiven Lizenzen ist mit den von Office 365 bereitstellten Tools nicht immer nativ möglich.
Die Berichte der ENow Management Suite bieten eine einfache und auf einen Blick verständliche Möglichkeit, Möglichkeiten zur Kostenoptimierungen zu messen und umzusetzen. Alle Probleme mit der richtigen Dimensionierung von Lizenzen, überlappenden Lizenzen oder der erneuten Bereitstellung nicht verwendeter Lizenzen können mit diesen Berichten gelöst werden. Sie erhalten einen exakten Einblick, wie Ihre Lizenzen in Ihrem Unternehmen verwendet werden. Diese Informationen helfen Ihnen bei Lizenzverhandlungen, ROI- oder TCO-Modelle zu formulieren und bieten reale Einblicke in Ihre digitalen Investitionen.
Der Einrichtungsprozess der ENow Management Suite und Mailscape 365 war sehr einfach. Der Installationsassistent führt Sie durch jeden einzelnen Schritt des Prozesses. Nach der Einrichtung der erforderlichen Dienstkonten für den Zugriff auf Ihren Office 365-Mandanten ist die Lösung betriebsbereit. Die Installationsroutine bietet sogar die Möglichkeit, eine Express-Installation durchzuführen, die weniger Rückfragen zur Installation notwendig macht. Die proaktive Office 365-Überwachung Ihres Mandanten wird innerhalb weniger Minuten aktiviert und die Berichte zur Lizenzverwaltung sind schon kurz nach Abschluss der Installation verfügbar.
Die ENow Management Suite macht mit Mailscape 365 genau das, was es soll. Es bietet eine Überwachung auf einen Blick, die Administratoren dabei hilft, ein Problem schnell zu erkennen und zum eigentlichen Kern des Problems zu gelangen. Hierzu müssen Administratoren nur dem Pfad der „roten Warnmeldungen“ folgen.
Ergänzt wird die Überwachung Ihres Office 365.Mandaten durch die Bereitstellung von aussagekräftigen Berichten, die Ihnen bei der Einführung und Nutzung von Office 365 helfen und sogar Geld sparen können. Sie erhalten eine Lösung, die Ihnen dabei hilft, Ihre tägliche Arbeit ohne unnötige Komplexität zu erledigen, ganz unabhängig davon, ob Sie ein IT-/Exchange- /Office 365-Administrator, für die Einführung moderner Arbeitsplätze verantwortlich oder ein Software-Asset-Manager sind.
Besuchen Sie die Produkt-Website für weitere Informationen: https://www.enowsoftware.com/products/office365-monitoring-and-reporting
Beginnen Sie mit einem 14-Tage Test: https://www.enowsoftware.com/get-started
Foto von Christina Morillo von Pexels
Um die Antwort direkt vorwegzunehmen, De-Mail ist keine Erfolgsgeschichte.
Mir stellt sich allerdings immer wieder die Frage, warum De-Mail keine Erfolgsgeschichte geworden ist. Die ursprüngliche Idee, verschlüsselte E-Mail-Nachrichten für jeden Bürger zu ermöglichen, um damit die Digitalisierung von Bürgerdiensten voranzutreiben war gut. Im Rückblick auf den Entstehungsprozess und das daraus resultierende De-Mail-Gesetz vom 28. April 2011 kann man nur festhalten, dass eine gute Idee den Kernproblemen im Umgang mit (IT-)Technologie in Deutschland geopfert wurde.
Als Kernprobleme sind insbesondere zu nennen:
Der Anspruch von De-Mail ist, dass jede verwendete E-Mail-Adresse eine verifizierte E-Mail-Adresse ist. Der Nutzer einer solchen E-Mail-Adresse ist somit eineindeutig identifizierbar. Dies gilt für Privatpersonen mit einer persönlichen E-Mail-Adresse ebenso wie für Firmen mit Unternehmens-Adressen für Dienste und Mitarbeiter. Dies steht im direkten Gegensatz zu herkömmlichen E-Mail-Adressen.
Die Ausarbeitung der De-Mail-Infrastruktur erfolgte in einem Elfenbeinturm und das Ergebnis war, im Hinblick auf die einfache Nutzung durch den Bürger, desaströs. Für Unternehmen wiederum war und ist die Anbindung an die De-Mail-Infrastruktur immer noch ein Drama. Die De-Mail-Anbindung von Behörden und deren Erreichbarkeit über eine De-Mail-Adresse ist ähnlich schlecht.
Für die Bundesverwaltung ist die Einführung und Nutzung von De-Mail verpflichtend über das E-Government-Gesetz geregelt. Die Einführung sollte zum 1. Quartal 2016 abgeschlossen sein1. Mit wem möchte die Bundesverwaltung über De-Mail kommunizieren? Die Realität sieht anders aus. Anstatt eine etablierte Lösung zu verwenden, erfolgt die bundesweite E-Mail-Kommunikation über das Netz des Bundes, in dem eine Verschlüsselung des Übertragungsweges (TLS SMTP) als ausreichend betrachtet wird. Eine einheitliche Nachrichtenverschlüsselung für die Kommunikation zwischen Behörden ist nicht verpflichtend geregelt.
In den Ländern und Kommunen sieht es nicht besser aus. De-Mail findet schlichtweg nicht statt.
Die immer angeführten Vorteile und möglichen Einsparpotentiale gegenüber der klassischen Briefpost wurden und werden ignoriert. Vergessen Sie nicht, dass das De-Mail-Gesetz die rechtliche Gleichstellung einer De-Mail-Zustellung mit der klassischen Briefpost regelt. Dies ist übrigens auch der Grund, warum die Post seinerzeit als De-Mail-Anbieter ausgestiegen ist.
Aber war da nicht noch eine andere besondere Lösung zum Austausch von besonders schützenswerten E-Mail-Nachrichten? Sie erinnern sich bestimmt an die andere deutsche Erfolgsgeschichte: Das besondere elektronische Anwaltspostfach (beA).
Ich habe mich von Anfang an gefragt, warum die Kommunikation zwischen Anwaltskanzleien und Gerichten nicht per De-Mail erfolgt. Sicher wird nun jemand darauf hinweisen, dass die technische Implementierung der De-Mail-Intrastruktur dem Anspruch zum Schutz der anwaltlichen Daten gerecht wird. Dies ist, aus meiner Sicht, ein fadenscheiniges Argument, da eine technische Anpassung möglich gewesen wäre. De-Mail wäre auf jeden Fall sicherer als die klassische Fallback-Lösung für termingerechte Zustellung an Gerichte, die Fax-Übertragung.
Gerade im Hinblick auf die Zustellung von anwaltlichen E-Mail-Nachrichten an Gerichte möchte ich eine Erfahrung mit Ihnen teilen. In mindestens einem Bundesland erfolgt die E-Mail-Kommunikation zwischen Kanzleien und Gerichten klassisch per SMTP über das Internet. Als Absicherung ist auch hier die Transportverschlüsselung ausreichend, solange eine E-Mail-Nachricht nach technischem Eingang unverändert in das Richter-Postfach zugestellt wird. Eine Nachrichtenverschlüsselung ist nicht erforderlich. Eine Nachrichtenverschlüsselung wird als zu kompliziert erachtet.
Bei der Einführung von De-Mail war besonders wichtig, dass keine De-Mail-Pflicht für die Kommunikation von Bürgern mit Behörden eingeführt wurde. Mit dem Verzicht auf eine De-Mail-Pflicht hätte man sich De-Mail auch sparen können. Eine freiwillige De-Mail-Registrierung haben nur wenige Bürger durchgeführt, nicht zuletzt auch wegen des aufwendigen Prozesses zur Prüfung der Identität. Die strengen Anforderungen zur Prüfung der Identität für De-Mail sind dem BSI anzulasten. Die Eröffnung eines neuen Bankkontos per Video-Ident ist erheblich einfacher.
Aber war da nicht noch etwas?
Was ist mit der inzwischen verpflichtend aktivierten Online-Ausweisfunktion des neuen Personalausweises (eID)?
In der Anfangsphase der Einführung des neuen Personalausweises war die Aktivierung der Online-Ausweisfunktion freiwillig. Völlig unerwartet hat sich gezeigt, dass die Mehrheit der Bürger an der Nutzung dieser Funktion kein Interesse hat. Inzwischen ist die Aktivierung dieser Funktion verpflichtend und soll dazu beitragen, dass wir mehr Bürgerdienste online nutzen. Leider hat die Bundesregierung dabei vergessen, dass die Aktivierung der Online-Ausweisfunktion nicht ausreicht. Jeder Bürger, der diese Funktion nutzen möchte, benötigt entweder ein passendes eID-Lesegerät für den PC/Mac oder aber eine spezielle App für das Mobiltelefon.
Wäre es mit der verpflichtenden Aktivierung der Online-Ausweisfunktion nicht ein genialer Schachzug gewesen, jedem Ausweisinhaber auch eine De-Mail-Adresse zu geben, falls noch keine vorhanden ist? Eine einfachere Prüfung der Identität kann ich mir nicht vorstellen.
So bleibt für den Bürger der fahle Beigeschmack, dass alle Bestrebungen hinsichtlich eGovernment unkoordiniert nebeneinander existieren und eine sinnvolle Integration gar nicht gewollt ist.
Welche einfachen Möglichkeiten gibt es nun, wenn Sie, als Bürger oder Unternehmen, E-Mail-Nachrichten verschlüsseln möchten und De-Mail keine Option ist?
Das kommt ganz darauf an, mit wem Sie kommunizieren möchten.
Die sicherste Methode ist die Verschlüsselung mit Hilfe eines Zertifikates, einem sog. S/MIME-Zertifikat. Solche Zertifikate sind meist kostenpflichtig und es bedarf einiger Kenntnis. um diese richtig ausstellen zu lassen und in der eigenen E-Mail-Software zu integrieren. Daher ist diese Methode auch bei Privatanwender selten in Nutzung. Für Unternehmen besteht die Möglichkeit, die E-Mail-Verschlüsselung mit Hilfe eines Gateways zu realisieren. Eine E-Mail-Verschlüsselung ist jedoch nur möglich, wenn sowohl Absender und Empfänger über ein gültiges Zertifikat verfügen. Der entscheidende Vorteil ist natürlich, dass die Möglichkeit für Absender und Empfänger weltweit zur Verfügung steht.
Office 365 bietet Ihnen die Möglichkeit, mit Hilfe der Office 365 Message Encryption (OME), E-Mail-Nachrichten zu verschlüsseln und diese an Empfänger zu senden, die nicht über ein S/MIME-Zertifikat verfügen. Um diese Funktion zu nutzen, benötigen Sie als Unternehmen natürlich ein Office 365/Microsoft 365 Abonnement. Für Privatpersonen ist diese Funktion auch Bestandteil von Office 365 Personal bzw. Office 365 Home. Die Benutzererfahrung als Empfänger einer OME-geschützten Nachricht ist allerdings gewöhnungsbedürftig.
Ist PGP eine Option? Nein.
PGP ist eine fälschungsanfällige Verschlüsselungslösung, die ihre Zeit hatte. Als IT-affiner Anwender ist eine PGP-Integration möglich. Für den Normalanwender ist sie, ebenso wie S/MIME, leider viel zu komplex. Im Gegensatz zur Nutzung von S/MIME erfordert PGP immer die INstallation von zusätzlichen Softwarekomponenten, die oft nur unzureichend in Standard-Mail-Clients integriert sind.
E-Mail-Nachrichten unverschlüsselt zu senden ist grob fahrlässig, insbesondere für Unternehmen (Stichwort: DSGVO). Die technischen Anforderungen an E-Mail-Verschlüsselung sind für Privatpersonen oftmals zu komplex. De-Mail könnte uns hier zwar helfen, ist aber wegen der fehlenden Unterstützung durch Behörden und Unternehmen in Deutschland keine Option. Leider.
Prüfen Sie bei Ihrem E-Mail-Anbieter, ob für Ihr persönliches E-Mail-Konto eine Möglichkeit zur E-Mail-Verschlüsselung zur Verfügung steht.
Als Unternehmen ist eine E-Mail-Verschlüssung alternativlos. Es gibt zahlreiche Lösungen am Markt, mit denen Sie eine Gateway-basierte Verschlüssung zum Schutz persönlicher Daten und Unternehmensinformations umsetzen können.
Wenn Ihr Unternehmen bisher keine De-Mail-Schnittstelle hat, denken Sie sich einmal darüber nach, solch eine Schnittstelle einzurichten.
Der größte Teil der De-Mail-Kommunikation ist übrigens Maschine-zu-Maschine-Kommunikation. Unternehmen tauschen auf diesem Weg, rechtlich abgesichert, automatisch zu verarbeitende Daten zwischen Softwaresystemen aus.
Verschlüsseln Sie Ihre E-Mail-Nachrichten. Wenn Sie bisher Ihre E-Mail-Nachrichten nicht verschlüsseln, fangen Sie noch heute damit an.