Kaum ein Unternehmen startet mit Office 365 auf der grünen Wiese, der Standardeinstieg erfolgt in der Regel über einen Parallelbetrieb per Hybrid-Architektur. Bei der Umsetzung sind wichtige Hürden zu meistern - wie Einbindung in das lokale Active Directory, Umstellung auf Click-to-Run-Technik der Office-Suite und Exchange-Migration. Wer bei der Planung und Umsetzung die Tücken kennt, erreicht ausfallfrei die ersten Etappen.
Das Leitmotiv bei Cloud-Diensten heißt "Anmelden und Loslegen", und auch Microsoft verspricht bei Office 365 einen Einstieg ohne übliche IT-Hürden. Doch in der Praxis ist dieses Idealszenario nur selten anzutreffen, beispielsweise bei neu gegründeten Unternehmen ohne IT-Altlasten. Sobald bereits IT-Infrastruktur vorhanden ist, sind für den Start in Office 365 eine Reihe von konzeptionellen Vorüberlegungen hinsichtlich der Architektur und der Projektplanung zu treffen, um einen Umstieg sauber und unterbrechungsfrei hinzubekommen.
Schrittweise in die Cloud mit Hybrid-Architektur
Grundsätzlich führt in den meisten Fällen der einzig sinnvolle Weg über eine "Hybrid-Architektur". Gemeint ist damit ein paralleler Betrieb von bereits vorhandenen Servern im Unternehmen mit den neuen Cloud-Services von Office 365. Ein solches Nebeneinander der beiden Welten hilft dabei, um Schritt für Schritt die bestehenden Anwendungen von den existierenden Servern in die Cloud-Rechenzentren umzuziehen. Durch den parallelen Betrieb verringern sich die Migrationsrisiken und der organisatorische Aufwand bleibt in überschaubaren Grenzen.
Doch wer auf Hybrid umsteigt, muss sich über eine einschneidende Änderung im Klaren sein: Da es sich hierbei um zwei voneinander unabhängigen Systeme handelt, ist auch ständig eine doppelte Benutzeranmeldung erforderlich. Mitarbeiter empfinden das als lästig, aber am härtesten trifft es den Support, der mit enorm steigenden Problemfällen bei Anmeldungen zu rechnen hat.
Risiken bei Single-Sign-On und ADFS vermeiden
Als Lösung bietet sich Single-Sign-On an, um in Hybridumgebungen eine simple Systemanmeldung mit einer einheitlichen Benutzerkennung und einem Passwort zu ermöglichen. Microsoft bietet dafür den Active Directory Federation Service (ADFS) als lokal installierten Verzeichnisdienst an. Dieser leitet Authentifizierungsanfragen über das lokale Active Directory an Cloud-Dienste weiter und nimmt dem Anwender Mehrfachanmeldungen ab.
Die Krux dabei ist allerdings, dass hier eine eigenverwaltete Komponente den Single-Point-of-failure bildet. Fällt ADFS aus, so ist keine Anmeldung an den Cloud-Servern mehr möglich, womit alle Vorteile einer externen, ausfallsicheren Systemumgebung wieder passee wären. Um solche Ausfälle einer Schlüsselkomponente zu verhindern, haben Unternehmen die Wahl zwischen zwei Optionen:
Entweder betreiben Sie den ADFS-Dienst intern mit entsprechendem Aufwand und ausreichender Redundanz,
oder aber sie beziehen Single-Sign-On als externen Managed Service, wie ihn inzwischen ein paar spezialisierte Microsoft-Partner anbieten.
Bei kleineren Unternehmen, die den Aufwand für Single-Sign-On nicht betreiben wollen, kommt noch ein weiterer, von Microsoft angebotener Lösungsweg in Frage. So lassen sich Passwörter zwischen dem lokalen Active Directory und Office 365 automatisch synchronisieren, geschützt durch einen Hash. Damit entfällt das ständige Eingeben von Kennwörtern, lediglich die Anmeldedialoge bekommen die Benutzer noch zu sehen.
Office 2013 Click-to-run: Tücken bei Lizenz und Softwareverteilung
Ein weiterer "Pferdefuß" beim Office 365-Umstieg lauert im neuen Click-to-run-Verfahren zur Softwareverteilung, das für die Installation von Office-2013-Anwendungen zum Einsatz kommt.
Foto: utilitas GmbH / Peter Haupt
Die Tragweite dieser Thematik ist insofern groß, da Microsoft derzeit sehr viele Unternehmen über den Lockvogel "günstigere Office-Client-Lizenzen" in das Abo-Modell ködert.
Der Preisvorteil ist gegenüber den klassischen Lizenzen wie Enterprise Agreement tatsächlich signifikant.
Was jedoch viele dabei nicht beachten: Mit der Lizenz ändert sich auch die Technik der Softwareverteilung, anstelle der altbekannten MSI-Installer-Methode kommt die neue, inkrementelle Verteilmethode Click-to-Run zum Einsatz. Dabei müssen folgende Gesichtspunkte beachtet werden:
Neuartiges Lizenzmodell zwingt zur Neuinstallation - Viele Microsoft-Kunden steigen auf das Office 365-Abomodell um, lassen aber die bereits installierten Office-Anwendungen unangetastet. Damit verstoßen sie gegen die Lizenzbedingungen von Microsoft, die eine Neuinstallation der Anwendungen per Click-to-Run verlangen.
Über-oder Unterlizenzierungen? - Nach dem alten Lizenzmodell müssen Unternehmen stets selbst dafür Sorge tragen, dass alle Arbeitsplätze korrekt lizenziert sind. Sind zu wenige Lizenzen vorhanden, drohen die berüchtigten Audits. Verfügt man über zu viele Lizenzen, wirft man unnötig Geld für Software raus.
Click-to-Run beendet dieses Dilemma, indem die Software-Verteilung und -verwaltung in ständiger Verbindung mit den Microsoft-Servern steht. So kennt Microsoft jede Lizenz und jeden Arbeitsplatz und rechnet entsprechend ab, Fehllizenzierungen können nicht mehr passieren.
Immer die neueste Office-Version - Click-to-Run-Anwendungen prüfen beim Start stets, ob Updates verfügbar sind und aktualisieren sich selbständig. Damit bleiben die Kunden auch bei einem Release-Wechsel immer auf dem neuesten Versionsstand.
Update-Risiken mit interner Verteilung umgehen - Was komfortabel klingt, birgt für Unternehmen allerdings auch einige Risiken. So kann es im Fall nicht getesteter Updates schon mal vorkommen, dass die eigenen Office-Add-Ons oder auf Office basierende Applikationen von einem Tag auf den anderen nicht mehr funktionieren.
Um das zu verhindern und Kunden eine kontrollierte Verteilung zu ermöglichen, lassen sich auch Click-to-Run-Anwendungen in die klassische Softwareverteilung integrieren. So kann ein Administrator beispielsweise mit Systemcenter Pakete erstellen und diese abgekoppelt von Microsoft nach einem internen Test- und Verteilplan ausrollen.
Exchange-Migration: Hybrid statt Big Bang
Ein separater Themenblock bei der Migration auf Office 365 ist noch die Umstellung des E-Mail-Systems auf Exchange-Server. Zwar wird E-Mail gerne als Commodity bezeichnet, und die E-Mail-Migration als triviale Aufwärmübung für den Cloud-Einstieg dargestellt. Doch von einem "Big-Bang"- Komplettumzug auf Exchange Online ist dringend abzuraten. Denn schließlich bilden E-Mail, Termine, Adressen und Aufgaben eine unternehmenskritische Funktion, ohne die heute viele Betriebe lahm gelegt wären.
Die Herausforderung beim Wechsel vom lokalen Exchange-Server in eine Hybridumgebung liegt dabei in der Komplexität, die im Verbund mit anderen Geschäftsanwendungen entsteht. Wenn beispielsweise das SAP-System Mails verschickt, oder ein Online-Shop Bestellbestätigungen aussendet, und solche Verknüpfungen auch noch schlecht dokumentiert sind, kann eine Migration im Chaos enden. Durch Hybrid-Konstellationen lassen sich solche Szenarien vermeiden.
Inkompatibilität durch abweichende Patch-Stände
Ein weiterer Stolperstein sind abweichende Release- und Patch-Stände, die sich im Zuge einer Migration durch die Aktualisierung einzelner Exchange-Server ergeben können. Je nach Kombination sind hier Störungen von Schnittstellen möglich, die sich ebenfalls auf Business-Anwendungen auswirken.
Schließlich spricht für die Beibehaltung einer teilweise lokalen Exchange-Infrastruktur in vielen Fällen auch noch die vorhandene Exchange-Konsole. Über sie wird das Gesamtsystem verwaltet, und auch nach einer Umstellung auf eine Hybrid-Umgebung ist es oft sinnvoll, diese Konstellation beizubehalten.