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.
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
Das E-Mail-Sicherheitsgateway NoSpamProxy untertützt die Anbindung an die De-Mail-Infrastruktur. Mit Hilfe von De-Mail ist eine gesetzlich geregelte Zustellung von rechtlich relevanten E-Mail-Nachrichten möglich. MIt Hilfe von NoSpamProxy kann Ihr Unternehmen E-Mail-Nachrichten mit De-Mail-Empfängern austauschen, ganz unabhängig davon, ob Ihre E-Mail-Server in der internen IT-Infrastruktur betrieben werden oder als SaaS-Dienst wie z.B. Office 365. In meinem Beispiel befinden sich alle Postfächer in Exchange Online.
Die Anbindung von De-Mail und Office 365 über das E-Mail-Gateway wird im nachfolgenden Schaubild deutlich.
Die zur Anbindung an Office 365 erforderlichen Komponenten, wie z.B: Azure AD Connect, sind im Diagramm nicht dargestellt, um die Übersichtlichkeit zu gewährleisten.
Das E-Mail-Gatewaysystem wird in diesem Beispiel auf einer Hyper-V-Plattform betrieben. Da die De-Mail-Zertifikate auf einer Smardcard gespeichert sind und der Betrieb des Gateways unbeaufsichtigt erfolgen soll, muss die Smartcard über einen zertifizierten Kartenleser permanent eingebunden werden. Entsprechende Smartcard-Lesegeräte sind als USB-Geräte erhältlich. Beim Erwerb einer De-Mail-Signaturkarte erhalten Sie einen passenden Kartenleser.
Die Verbindung des physikalischen Smartcard-Lesegerätes zum virtualisierten Betriebssystem erfolgt mit Hilfe eines USB-Servers. Für diesen USB-Server wird auf dem virtualisierten Betriebssystem eine Treiber-Software installiert, die einen virtualisierten USB-Port bereitstellt. Über diesen vUSB-Port ist anschließend das Smartcard-Lesegerät mit dem Betriebssystem verbunden. Zusätzlich werden noch die passenden Treiber und die Verwaltungssoftware für das De-Mail-Zertifikat benötigt.
Das folgende Schaubild verdeutlicht die technische Anbindung des Smartcard-Lesegerätes mit einem virtualisierten Betriebssystem.
System-Komponenten
Software-Komponenten
Die Anbindung an De-Mail erfolgt immer auf einem NoSpamProxy-System mit installierter Gateway-Rolle. Ob es sich um ein reines Gateway-System handelt oder aber um ein System mit installierte Intranet- und Gateway-Rolle ist unerheblich. In der nachfolgenden Beschreibung gehe ich davon aus, dass die NoSpamProxy Gateway-Software bereits installiert ist und die Nutzung von De-Mail lizensiert ist.
Installieren Sie zuerst den USB-Server und richten Sie das Smartcard-Lesegerät im Windows Server Betriebssystem ein. Die in diesem Artikel beschriebenen Schritte und zu installierenden Komponenten gelten für Windows Server 2012R2 und Windows Server 2016 identisch. Für Windows Server 2019 liegen noch keine Erfahrungen vor.
An diesem Punkt haben Sie das Smartcard-Lesegerät über den USB-Server und den virtuellen USB-Treiber der USB-Umlenkung mit dem Windows Server Betriebssystem verbunden. Bei jedem Neustart des Betriebssystems wird das Lesegerät automatisch verbunden.
Für die folgenden Installationsschritte und die Einbindung des De-Mail-Zertifikates ist es erforderlich, dass Sie eine Konsolenverbindung zum virtualisierten Betriebssystem herstellen. Die Einbindung des Smartcard-Zertifikates innerhalb einer RDP-Sitzung auf dem Windows Server nicht möglich, da dies durch den Windows Smartcard-Treiber aktiv verhindert. Sie erkennen dies daran, dass es beim Start des TCOS-CardManagers zu folgender Fehlermeldung kommt.
In einer VMware Hypervisor-Plattform ist der Zugriff über eine Konsolensitzung kein Problem. Wenn Sie aber Hyper-V als Hypervisor-Plattform einsetzen, müssen Sie auf die folgenden Einstellung des Hyper-V-Hostsystems achten.
Die Funktion "Erweiterten Situngsmodus zulassen" muss ausgeschaltet sein. Wenn diese Funktion eingeschaltet ist, werden alle Sitzungen durch das Gast-Betriebssystem als RDP-Sitzungen wahrgenommen. Dies führt automatisch dazu, dass der beschriebene Zugriff auf die Smartcard-Blibliotheken unterbunden wird. Diese Funktion muss nur für den Zeitraum der Konfiguration der De-Mail-Zertifikate in Windows Server ausgeschaltet sein bzw. immer dann, wenn Sie mit dem TCOS CardManager arbeiten müssen.
Folgende Schritte sind notwendig, um die TCOS-Smartcard und die De-Mail-Zertifikate zu integrieren:
Der die TCOS-Softwarekomponenten sind so programmiert, dass die De-Mail-Zertifikate beim ersten Zugriff auf die Signaturkarte in den lokalen Zertifikatsspeicher des angemeldeten Benutzers kopiert werden. Dieser Zertifikatsspeicher ist für installierte Softwarelösungen gänzlich ungeeignet. Die Zertifkate müssen in den Zertifikatsspeicher des Computers verschoben werden. Hierbei hilft Ihnen das Tool CertificatePromoter.exe, das Sie vom Net at Work-Support erhalten können.
Nachdem nun die De-Mail-Zertifikate im richtigen Zertifikatsspeicher abgelegt sind, muss der Zugriff auf die Zertifikate und die privaten Schlüssel konfiguriert werden. Die hierzu erforderlichen Schritte habe ich im Artikel "Zugriff auf privaten SSL-Schlüssel konfigurieren" beschrieben. Führen Sie die dort beschriebenen Schritte für die drei verschobenen De-Mail-Zertifikate durch.
Damit sind alle Voraussetzungen für eine funktionierende Anbindung des E-Mail-Security Gateways NoSpamProxy an De-Mail abgeschlossen. Die Konfiguration erfolgt in der NoSpamProxy MMC-Verwaltungsoberfläche im Menüpunkt Connected systems. Sie können entweder einen Telekom De-Mail-Connector oder einen Mentana-Claimsoft De-Mail-Connector hinzufügen.
Wenn alle Einstellungen und Konfiguration korrekt durchgeführt wurden, wird in der NoSpamProxy MMC-Verwaltungsoberfläche nach kurzer Zeit die Anzahl der zur Verfügung stehenden De-Mail-Domänen angezeigt. Diese Information wurde durch NoSpamProxy vom De-Mail-Gateway abgefragt und ist daher ein Beleg für die funktionierende Verbindung.
Ab diesem Punkt können Sie mit den weiteren Benutzer-Konfigurationen für De-Mail, entsprechend der NoSpamProxy Anleitung fortfahren.
Sollte es doch zu Problemen bei der Verbindung zum De-Mail-Gateway kommen, prüfen Sie bitte die folgenden Punkte:
Damit erschöpfen sich auch schon die allgemeinen Möglichkeiten zum Troubleshooting der De-Mail-Anbindung. In den meisten Fällen liegt ein Problem beim Verbindungsaufbau vor. Dies ist entweder die HTTPS-Strecke selbst oder aber die Aushandlung der TLS-Verschlüsselung (Handshake). Die Analyse des TLS-Handshake erfordert die Installation eines Werkzeuges zur Netzwerkanalyse, wie z.B. Wireshark oder Microsoft Message Analyzer.
# Prüfung der TLS-CipherSuite # Wird kein Ergebnis zurückgegeben, muss die CipherSuite aktiviert werden (Get-TlsCipherSuite) | Where-Object {$_.Name -eq 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384'} # Alphabetische Auflistung der konfigurierten TLS-CipherSuites des OS Get-TlsCipherSuite | Sort-Object Name | FT Name # Aktivierung der CipherSuite Enable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 # Auflistung der aktivierten elliptischen Kurven # Wird die Kurve NistP521 nicht aufgeführt, muss sie aktiviert werden Get-TlsEccCurve # Aktivierung der ECC Kurve NistP521 Enable-TlsEccCurve NistP521 # Alle Änderungen an den TLS-Einstelliunge erfordern einen Neustart des Servers
Ich wünsche viel Spaß mit dem NoSpamProxy E-Mail-Sicherheitsgateway und De-Mail.
De-Mail ist Bestandteil der E-Government-2.0 Strategie Deutschlands und ist eine vom Bundesamt für Sicherheit in der Informationstechnik (BSI) zertifizierte Technik zur sicheren, vertraulichen und nachweisbaren E-Mail Kommunikation.
Eine komfortable Anbindung an die De-Mail Infrastruktur ist mit Hilfe der E-Mail Gateway Lösung NoSpamProxy Encryption möglich. Für eine Anbindung an die E-Mail Systeme eines Unternehmens muss eine De-Mail Gateway Kommunikation eingerichtet werden. Die Nutzung von De-Mail in dieserm Szenario erfordert den Einsatz einer Signaturkarte, was für die Anbindung an eine serverbasierte Softwarelösung ganz eigene Herausforderungen mit sich bringt.
Im nachfolgenden Artikel wird die Anbindung exemplarisch für die T-Systems De-Mail Schnittstelle unter Verwendung von NoSpamProxy Encryption beschrieben. Die von T-Systems zur Verfügung gestellte Gateway-Lösung wird hierzu nicht benötigt. Die NoSpamProxy Encryption Gateway Rolle ist in diesem Beispiel bereits auf dem Windows Server 2012R2 System installiert.
Lesegeräte für Signaturkarten sind mit einer USB Schnittstelle ausgestattet. Bei direkter Nutzung einer hardwarebasierten Serverlösung stellt dies kein Problem dar, da der Kartenleser direkt am Server angeschlossen werden kann.
In einer virtualisierten Serverinfrastruktur muss der USB Kartenleser mit Hilfe eines USB Servers dem Betriebssystem zur Verfügung gestellt werden. Hier gibt es unterschiedliche Produkte am Markt. T-System empfiehlt hier das SoHo Produkt myUTN-50a der Fa. SEH. Am Markt existieren auch industrietaugliche Alternativen.
Als Kartenlesen empfiehlt und verkauft T-Systems den SCR3310 (lt. Herstellt End of Life), der auch in diesem Beispiel verwendet wird.
Die Installation aller Smartcard Komponenten muss über die Konsole erfolgen. Eine Installation über eine RDP Verbindung (auch RDP Konsole) führt zu einer fehlerhaften Installation der Smartcard Komponenten.
Für den USB Server ist die Verwendung einer dedizierten und fest konfigurierten IP-Adresse einer Zuweisung per DHCP vorzuziehen. Nach der Einrichtung muss der USB Server mit Hilfe der zugehörigen Verwaltungssoftware erreichbar sein und die USB Ports müssen im Gastbetriebssystem eingebunden werden. Die korrekte Einbindung kann im Gerätemanager kontrolliert werden.
Wichtig ist, dass die Einbindung des USB-Servers als „Autostart“ konfiguriert ist, damit der USB-Server beim Start des Betriebssystems automatisch verbunden wird.
Die Installation der Treibersoftware für den Kartenleser SCR3311 ist einfach, da es sich um eine simple Windows-Installer Lösung handelt. Nach der Installation muss der Kartenleser im Gerätemanager sichtbar sein und als korrekt installiert angezeigt werden.
Für den Zugriff auf die Smartcard muss der Treiber für das TCOS (TeleSec Chipcard Operating System) installiert werden. Hier ist TCOS Cardmodul Treiber für die manuelle Installation zu verwenden. Nach dem Entpacken des gezippten Archivs erfolgt die Installation (Treiber Update) mit Hilfe des Gerätemanagers. Nach der Installation muss die Smartcard im Gerätemanager sichtbar sein und als korrekt installiert angezeigt werden.
Für die Registrierung der auf der Smartcard gespeicherten Zertifikate muss die TCOS CardManager Software installiert werden. Auch hier ist die Installation einfach, da es sich um eine simple Windows-Installer Lösung handelt.
Nachdem alle Komponenten korrekt installiert sind, können die Zertifikate auf dem Server registriert und mit Hilfe eines Tools im Zertifikatsspeicher des Servers zur Nutzung bereitgestellt werden.
Starten Sie den TeleSec CardManager und wählen Sie die den Knoten Personalisierung -> Zertifikate und registrieren Sie alle Zertifikate.
Nach der Registrierung müssen die registrierten Zertifikate in den lokalen Zertifikatspeicher promotet werden, damit die Software mit den Zertifikaten arbeiten kann.
Starten Sie die CertificatePromoter.exe und wählen Sie alle registrierten Zertifikate. Klicken Sie anschließend auf Ok und starten Sie anschließend den Server durch.
Wichtig ist, dass nach der Bereitstellung der Zertifikate mindestens das Zertifikat für Client Authentication, Smart Card Logon im Zertifikatsspeicher aufgeführt wird.
In der Anzeige der Zertifikatsdetails können die erweiterten Nutzungsarten angezeigt werden:
Nachdem nun die Zertifikate korrekt im lokalen Zertifikatsspeicher verfügbar sind, kann der NoSpamProxy De-Mail Konnektor in der NoSpamProxy Verwaltungskonsole konfiguriert werden.
Vergeben Sie einen Namen für den Konnektor und wählen Sie T-System als Ziel aus. Anschließend wählen Sie das zu verwendete Zertifikat aus.
Im Auswahldialog für das Zertifikat werden alle Zertifikate angezeigt, die auf den verbundenen NoSpamProxy Gateway Systemen im lokalen Zertifikatsspeicher zur Verfügung stehen. Werden in diesem Dialog die De-Mail Zertifikate nicht angezeigt, müssen die Konfigurationsschritte zur Einbindung der Zertifikate überprüft werden.
Überprüfen Sie anhand der Zertifikate-Detailanzeige das zu verwendende Zertifikat (s.o.) und wählen es anschließend aus.
Für jedes Gateway-System muss ein separater Konnektor erstellt werden.
Nach der Einrichtung des Konnektors und der erfolgreichen Verbindung zum T-System De-Mail Server werden in der NoSpamProxy Verwaltungskonsole die zur Verfügung stehenden De-Mail Domänen angezeigt. Damit wurde die De-Mail Anbindung mit NoSpamProxy Protection eingerichtet.
Nach der rein technischen Anbindung des Unternehmens an De-Mail, muss De-Mail in Ihre Fachverfahren nach Ihren Wünschen und Anforderungen integriert werden. Dies erfordert eine ganz individuelle Beratung und Umsetzung.
Viel Spaß mit De-Mail.
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
Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.
Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:
Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.
Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.
Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.
Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.
Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.
Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.
Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?
Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.
Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.
Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.
Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:
Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden.
Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.
Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.
Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.
Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:
Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.
Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.
Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:
In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:
Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:
Die weiteren Konfigurationen des Servers sind:
Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.
Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert.
In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.
Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.
Was ist nun die richtige Exchange Server Architektur?
Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.
Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.
Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.
Abkürzungen
Viel Spaß beim Betrieb von Exchange Server.
Die Einführung von Office 365 ist im Allgemeinen keine große technische Herausforderung. Die technischen Anforderungen sind klar definiert und können in den meisten Fällen direkt 1:1 umgesetzt werden. Bei manchen Unternehmen ist die Konfiguration der technischen Anbindung der lokalen IT-Infrastruktur an Office 365 durchaus komplex, aber kein wirkliches Hindernis.
Neben den rein technischen Themen bei der Implementierung von Office 365 können unternehmensinterne Abstimmungen und Entscheidungsfindungen ein großer Hemmschuh für Office 365-Projekte sein. Diese sind immer dann eine Herausforderung, wenn keine ausreichende Unterstützung aus der Führungsebene vorhanden ist oder, noch wesentlich schlimmer, keine klare Cloud-Strategie existiert. Ohne eine klar definierte Unterstützung der Geschäftsführung sollten Sie von einer produktiven Office 365-Einführung Abstand nehmen.
Welche Hindernisse gibt es jenseits der technischen Implementierung von Office 365 und unternehmensinternen Entscheidungsprozessen?
Aber selbst mit allen notwendigen technischen Voraussetzungen und einer klaren Entscheidung, Office 365 als integralen Bestandteil der IT-Plattform im Unternehmen zu nutzen, kann es zu Problemen bei der Einführung von Office 365 kommen. Wenn ein Unternehmen keine eigenen IT-Mitarbeiter hat, die über das notwendige Knowhow zur Einführung von Office 365 verfügen, werden gerne Projektpartner oder Personaldienstleister in Anspruch genommen. Dies führt zu besonderen Kunde-Dienstleister-Konstellationen.
Und hier beginnen die Herausforderungen, die zu einer schlechten Office 365-Implementierung führen können.
An den folgenden beiden Beispielen möchte ich Ihnen die Problemsituationen verdeutlichen, die auch für die Office 365-Einführung in Ihrem Unternehmen ein Risiko darstellen können.
Fachkräfte, die sich mit allgemeinen Cloud-Technologien und mit Office 365 im Besonderen auskennen, sind rar. Dies ist hauptsächlich darauf zurückzuführen, dass viele Unternehmen ihre IT-Mitarbeiter im Bereich Cloud-Technologien nicht weiterbilden.
Möchte ein Unternehmen Office 365 einführen und eine Migration zu Office 365 durchführen, wendet man sich entweder an ein IT-Systemhaus oder einen Projektdienstleister, mit dem man bereits andere Projekte durchgeführt hat. Alternativ beauftragt man einen Personaldienstleister, einen Office 365-Experten für einen definierten Projektzeitraum zu finden. Dies resultiert in einer direkten Beauftragung zwischen dem Kunden (Ihr Unternehmen, im Folgenden AG genannt) und Personal-/Projektdienstleister bzw. Systemhaus als Auftragnehmer (AN).
Auf dieser ersten Ebene (A) endet bereits Ihre direkte Einflussnahme als Kunde, da nur zwischen Ihrem Unternehmen und dem direkten Auftragnehmer ein Vertragsverhältnis besteht. Bei der Zusammenarbeit mit einem Personaldienstleister sollte es Ihnen als Kunden bewusst sein, dass ein weiteres Glied der Beauftragungskette hinzugefügt wird, bevor Ihnen ein Office 365-Experte zur Seite gestellt wird. Wenn Sie einen Projektdienstleister oder ein Systemhaus beauftragen, haben Sie die Erwartung, dass diese Ihnen mit eigenen Experten helfen können. Diese Erwartung kann oft nicht erfüllt werden, da die Auftragnehmer mehr Projekte annehmen als sie effektiv bedienen können. Die vorhandenen Experten werden schlichtweg überbucht.
Um das angenommene Kundenprojekt nicht zu gefährden, bedienen sich die Aufragnehmer der Ebene A der gleichen Methodik wie der Endkunde. Sie kontaktieren ihrerseits Personaldienstleister, um fehlendes Expertenwissen einzukaufen. Damit sind wir in der zweiten Beauftragungsebene (B) angekommen. Oftmals kontaktieren Projektdienstleister und Systemhäuser mehrere Personaldienstleister, um das fehlende Expertenwissen möglichst günstig einzukaufen. Hierbei kommt es zu einer weiteren Beauftragung und einer zusätzlichen Auftraggeber-/Auftragnehmer Konstellation.
Verfügt ein Personaldienstleister aus Ebene B nicht direkt einen Experten zur Projektunterstützung, erfolgt eine erneute Suche nach einem Experten aus dem Pool registrierter Beraterunternehmen und Freelancer.
Dies ist nun die dritte Beauftragungsebene (C). Die Suche nach einem Office 365-Experten der beiden ersten Beauftragungseben A + B führt manchmal zu der amüsanten Situation, dass das gleiche Kundenprojekt bei Dienstleistern der Ebene C durch unterschiedliche Personal- und Projektdienstleister angefragt wird. Die Beauftragung des ausführenden Dienstleisters oder Freelancers in dieser dritten Ebene führt natürlich zu einer weitere Auftraggeber-/Auftragnehmer-Situation.
Das folgende Diagramm verdeutlicht die Situation der Beauftragungskette zwischen einem Kunden und dem endgültig ausführenden Office 365-Experten.
Wie wirkt sich solch eine Beauftragungskette für ein einzelnes Office 365-Projekt auf den Erfolg des Kundenprojektes aus?
Das große Problem einer solchen Beauftragungskette ist, dass mehrere AG/AN-Beziehungen zwischen Parteien bestehen, die ganz unterschiedliche Geschäftsinteressen verfolgen, die von Ebene zu Ebene undeutlicher werden. Der Dienstleister der dritten Ebene hat keine direkte Beziehung zum Kunden und zum ausgehenden Kundenprojekt. Die Erbringung der Dienstleistung und die damit verbundene Verantwortung erfolgen immer nur von Ebene zu Ebene. Diese Beauftragungskette beeinträchtigt auch die Kommunikationswege für das Kundenprojekt, wodurch dem Kunden nicht das vollständige Expertenwissen zur Verfügung steht.
Ein weiteres Problem dieser Beauftragungskette ist, dass die Dienstleister und Freelancer der dritten Ebene preislich gegeneinander ausgespielt werden. Auf dem Weg nach oben wiederum schlägt jeder beteiligte Personal- oder Projektdienstleister 10-20% auf den Einkaufspreis der Dienstleistung auf. Der Preis, den der Kunde wahrnimmt, suggeriert ihm, dass er Expertenwissen erhält, was eine entsprechende Erwartungshaltung generiert. Die natürlichen Kommunikationsverluste der Beauftragungskette führen nahezu zwingend dazu, dass die Kundenerwartung nicht erfüllt werden kann.
Erschwert wird diese Situation dadurch, dass Dienstleister und Freelancer oftmals gezwungen sind, unter der direkten Flagge eines Projektdienstleisters aufzutreten. Hierbei erhalten sie ein eigenes Benutzerkonto mit E-Mail-Adresse und Telefonnummer des Projektdienstleisters und erscheinen dem Kunden gegenüber wie hausinterner fester Mitarbeiter. Um einer Scheinselbstständigkeit zu entgehen, arbeiten Freelancer zur gleichen Zeit in mehreren Projekten. Dies wiederum führt zu Zeitverzögerungen bei der Erbringung von Dienstleistungen und der Projektkommunikation und hinterlässt so bei Ihnen, als Kunden, automatisch einen schlechten Eindruck,
Die mehrstufige Kommunikation fördert Missverständnisse, gerade im Hinblick auf notwendige Kundenberatung für die erfolgreiche Einführung von Office 365. Durch die Eingrenzung auf festdefinierte Projektthemen ist keine ganzheitliche Beratung und Einführung von Office 365 Produkten und Diensten möglich. Selbst wenn der Dienstleister oder Freelancer, als beauftragter Experte, seine Expertise in das Kundenprojekt einbringen möchte, wird er in den meisten Fällen durch einen Auftraggeber in Ebene A oder B ausgebremst, da diese vermeintlich zusätzliche Expertise nicht Bestandteil der Beauftragung ist. Der Kunde erfährt nie, dass er keine umfängliche Dienstleistung erhalten hat.
Für den Kunden birgt solch eine Beauftragungskette ein hohes Risiko, nicht die optimale Beratung zur Implementierung von Office 365 zu erhalten.
Ähnlich sieht es im zweiten Beispiel aus, wenn Sie im Rahmen der Einführung einer neuen Software-Lösung zwangsweise auch Office 365 einführen müssen.
Dieses Beispiel ist eine Variation von Beispiel A und in der Wahrscheinlichkeit zum Scheitern einer zukunftsfähigen Office 365-Einführung noch riskanter.
Als Kunde möchten Sie gerne eine neue Software-Lösung, wie z.B. eine cloudbasierte ERP-Lösung, einführen, um eine ältere, lokal betriebene, Software-Lösung zu ersetzen. Die Nutzung dieser ERP-Lösung erfordert, dass die Postfächer Ihrer Mitarbeiter in Exchange Online bereitgestellt werden. Die ERP-Lösung ist nicht kompatibel mit Postfächern, die in einer lokalen Exchange Organisation gespeichert sind oder bei einem anderen Provider gehostet sind.
Der primäre Fokus des ERP-Vertriebsteams liegt auf dem Verkauf von Nutzungslizenzen. Die Voraussetzungen zur Nutzung der ERP-Software und die technische Realität in der Kundenumgebung werden bewusst ausgeklammert. Sie als Kunde werden in der Sicherheit gewogen, dass eine cloudbasierte Software leicht und einfach zu implementieren ist. Die noch fehlende Office 365-Implementierung in Ihrem Unternehmen wird als Integrationsbaustein zur Softwarenutzung mitverkauft.
Mit dem Erwerb der ERP-Lizenzen beauftragen Sie In diesem Beispiel auch die Migration von Office 365.
Nun ist es so, dass der Software-Dienstleister (Beauftragungsebene A) nicht über das erforderliche Knowhow verfügt, um einen neuen Office 365-Mandaten vollständig und sicher zu konfigurieren. Um dieses Defizit auszugleichen, vergibt er die Office 365-Anbindung an einen anderen Dienstleister (Ebene B). Dieser Dienstleister wiederum verfügt ebenfalls nicht über das notwenige Knowhow bzw. hat kein Personal verfügbar, um die Office 365-Anbindung selbst auszuführen.
Auch in diesem Fall tritt dieser Dienstleister an einen weiteren Dienstleister oder Freelancer (Ebene C) heran, um die eigentlich Office 365-Anbindung durchzuführen.
Das folgende Diagramm verdeutlicht die Situation der Beauftragungskette zwischen einem Kunden, dem Software-Dienstleister und dem endgültig ausführenden Office 365-Experten.
Der wichtigste Unterschied zu Beispiel A ist der Umstand, dass dem Kunden eine Software-Produkt verkauft wurde und die Office 365-Anbindung preislich bereits inkludiert ist. Somit besteht keinerlei Spielraum, um eine umfassende Office 365-Beratung und Umsetzung durchzuführen. Der ausführende Dienstleister in Ebene C ist gezwungen, nur das notwendige Mindestmaß an Arbeiten durchzuführen.
Als Resultat verfügt der Office 365-Mandant des Kunden zwar über die Funktionen zur Nutzung der verkauften ERP-Software, eine Konfiguration zur Absicherung des Office 365-Mandaten findet jedoch nicht statt. Als weitere negative Auswirkungen auf diese Art einer Office 365-Implementierung sind u.a. zu nennen:
In diesem Fall nutzt der Kunde anschließend zwar Office 365, jedoch in mit einer als unsicher einzustufenden Konfiguration.
Wenn Sie für Ihr Unternehmen die Einführung von Office 365 planen oder die Nutzung von Office 365 eine Voraussetzung für die Einführung einer SaaS-Lösung ist, achten Sie besonders darauf, wer welche Dienstleistung erbringen kann. Je mehr Beauftragungsstufen in solch einem Projekt vorhanden sind, desto komplizierter werden die Auftraggeber- und Auftragnehmer-Abhängigkeiten. Es entstehen automatisch Interessenskonflikte, die nicht mehr das Wohl des Kunden und den Erfolg des Projektes im Fokus haben.
Das Scheitern der Office 365-Einführung ist dann besonders groß, wenn Sie als Kunde keinerlei Wissen über Cloud-Technologien im Allgemeinen und Office 365 im Besonderen in Ihrer IT-Abteilung verankert haben. Ohne dieses Wissen sind Sie nicht in der Lage, die Empfehlungen und Arbeiten der beauftragen Dienstleister zu bewerten. Diese Situation wiegt noch einmal schwerer, wenn Sie die Betreuung Ihres Office 365-Mandanten als Managed Service an einen Dienstleister ausgelagert haben. Sorgen Sie für eine regelmäßige Weiterbildung und Zertifizierung Ihrer IT-Mitarbeiter in den Technologiefeldern, die Sie in Ihrem Unternehmen nutzen.
Achten Sie bei der Beauftragung eines IT-Dienstleisters unbedingt darauf, dass keine Beauftragungsketten entstehen. Nehmen Sie hierzu Ihre Dienstleistungspartner in die Pflicht und fordern Sie eine Mitteilung über solche Beauftragungsketten ein. So haben Sie die notwendige Klarheit über vertragliche Abhängigkeiten, die außerhalb Ihres Kontrollbereiches sind und eventuell ein Risiko für Ihr Office 365-Projekt darstellen.
Viel Spaß mit Office 365.