Office 365 Das kleine Projekt (50-250 User)

Office 365 ist gerade für mittlere uns kleine Firmen interessant, für die ich der Betrieb eines eigenen Exchange Servers mit allen Randbedingungen (Hardwareinvestition, USV, Backup, Monitoring, Lizenzen, SSL-Zertifikat, fest IP-Adresse, sichere Veröffentlichung im Internet (Firewall), Spamschutz, Verwaltung und Pflege etc.) nicht rechnet. Die Grenze von 100 ist nicht in Stein gemeißelt. Diese Beschreibung kann für 50 "anspruchsvolle" Mitarbeiter schon nicht mehr passen aber auch für 250 Mitarbeiter noch passend sein. Verstehen Sie die Annahmen und Entscheidungen und prüfen Sie diese auf Passgenauigkeit für ihr Projekt.

Ausgangsvoraussetzungen

Die meisten Firmen in der Größe haben heute mindestens einen Domain-Controller und ein lokale Active Directory zur Verwaltung der Benutzer und Gruppen. Oft ist der Server auch Druck/Dateiserver. Vielleicht war es sogar mal ein Small Business Server mit Exchange "drauf". Weitere Server sind denkbar. Der lokale Exchange Server bekommt seine Mails aus dem Internet per MX-Record und sendet selbst direkt. Die Firewall davor kann ein SMTP-Relay mit SpamFilter sein oder die SMTP-Verbindungen per NAT einfach durchreichen und Exchange hat einen Virenscanner und Spamfilter. Zugriff auf OWA und ActiveSync erfolgt mit einem Zertifikat über den Reverse Proxy der Firewall oder per NAT wieder direkt auf Exchange. Der Schutzleven ist verbesserungswürdig.

Die primären Clients für Exchange sind Outlook und Smartphones per ActiveSync. Drittprodukte wie z.B. Faxserver oder Scan2Mail-Geräte müssen bezüglich ihrer Office 365-Tauglichkeit überprüft werden.

Annahmen

Für eine Office 365 Umsetzung gibt es mehrere Komplexitätsstufen, die mit unterschiedlichen Einschränkungen verbunden sind. Für dieses Projekt nehme ich folgende Dinge an:

  • DirSync für Provisioning
    Der Kunde ist groß genug, um eine doppelte manuelle Pflege in der Cloud zu vermeiden. Er hat ja einen lokalen DC, der auch den DirSync mit betreiben kann, damit alle lokal verwaltete Benutzer und Gruppen in der Cloud auch nachgezogen werden.
  • Verzicht auf ADFS - Kennwort Sync
    Für die Anmeldung an Office 365 gibt es neben der Nutzung separater Kennworte in der Cloud und der Aufbau einer ADFS-Umgebung (zwei Server, DNS-Name, Zertifikat etc.) auch den Weg das lokale Kennwort als doppelter Hash-Wert in  die Cloud zu replizieren. Die Anwender haben dann zumindest ein "Same SignOn", wenn auch kein Single Sing on, d.h. Sie müssen das gleiche Kennwort wie lokal noch mal eingeben. Es kann ja im lokalen Kennwort-Tresor hinterlegt werden
  • Kein "echtes" Exchange Hybrid
    Mit dem DirSync ist es aktuell noch erforderlich die Exchange Properties On-Premises zu verwalten. Dazu brauchen wir zumindest einen installierten Exchange Server mit den Commandlets und optional der GUI.
  • Cutover Migration / StagedMigration
    Einen langen Koexistenz-Betrieb sehe ich für dieses Projekt gar nicht erst vor. Zu einem Stichtag werden alle Postfächer in der Cloud genutzt. Die Inhalte kann man vorher oder notfalls auch nachher übertragen. Auf jeden Fall gibt es einen Tag X, an dem der MX-Record in die Cloud verweist und die Anwender dort ihre neuen Mails bekommen. Für eine überschaubare Anzahl an Benutzern ist dies aber zu bewältigen, zumal Outlook in der richtigen Version und Autodiscover den Schwenk sehr einfach machen

Alle anderen Aspekte einer Office 365 Einführung, z.B. SharePoint (Migration oder Neustart) oder die Nutzung von Skype for Business sind dann nachgelagert

Vorarbeiten

Der Aufwand der Vorarbeiten hängt natürlich auch davon ab, wie gut der Dienstleister die Umgebung des Kunden von früheren Tätigkeiten kennt. Im Grunde sind es aber immer die gleichen Tätigkeiten. Ich versuche ein Abschätzung als Aufwand in Stunden zu geben, ohne dass dies natürlich als Zusicherung verstanden werden soll, dass die Zeit immer reicht oder gebraucht wird.

Tätigkeit Aufwand Erledigt

Lizenzfragen

Eine essentielle Aufgabe ist die Bestimmung des aktuellen Lizenzstatus und wie sich mit Office 365 die Lizenzierung verändert. Oft haben Firmen noch "sehr alte" Lizenzen in Benutzung, die für Office 365 gar nicht mehr geeignet sind (z.B. Outlook 2007) oder für die ein Update eh ansteht. Dann ist Office 365 vielleicht gerade der Weg einen Neukauf zu ersetzen. Es muss aber auch für das Budget klar sein, dass eine monatliche Zahlung erfolgt.

Für kleine Firmen muss es auch nicht immer "E1,E3,E5 sein. Es gibt durchaus "kleinere" günstigere Pläne, die dann aber z.B. kein "Unlimited Postfach" haben.

 

Active Directory

Für den späteren DirSync müssen natürlich alle Benutzer und Verteiler On-Premises entsprechend fit gemacht werden. Das betrifft unter anderem den UPN (User Principal Name). Der Office 365 Assistent kann hier schon einige Prüfungen vornehmen und auch IDFIX schafft ihnen schnell einen ersten Überblick.

Auch muss erfasst werden, welche SMTP-Domains der Kunde nutzt, da diese Domänen später in Office 365 auch aktiviert werden müssen.

 

Exchange On-Prem

Das lokale Exchange System muss bezüglich der Version und Erreichbarkeit aus dem Internet überprüft und ggfls. angepasst werden. Drittprodukte wie Fax-Server, Archivlösungen, Scan2Mail-Geräte etc. müssen auf ihre Eignung für Office 365 überprüft und ggfls. aktualisiert werden.
Prüfen Sie auch die Größe der Postfächer und der Elemente in den Postfächern, entfernen Sie Altlasten und Altbestände. Jetzt ist die Chance da jedes Postfach monatlich Geld kostet, solche Themen anzugehen.

 

Clients

Für den Einsatz von Office 365 sind Mindestvoraussetzungen bei den Clients zu erfüllen. Wenn Sie nicht eh z-B. Office 365 Professional Plus einsetzen werden, müssen bestehende Clients ggfls. aktualisiert werden.

 

Organisatorisches

Der Office 365 -Tenant bekommt einen neuen Namen. Auch wenn der Kunde quasi im Internet mal eben schnell mit einer Kreditkarte einen Tenant kaufen könnte, sollten Sie sich vorher über die Vertriebswege und Sonderprogramme informieren. Oft können Sie über einen Partner einen Tenant günstiger erhalten oder die 1-Monat-Testzeit deutlich verlängern. Wenn Sie dann 100 User a 10€ durch eine verlängerte Testphase nicht sofort bezahlen müssen, freut sich der Inhaber. Über den "Partner of Records" können Sie einen Teil ihrer Ausgaben an ihren Partner Weiterreichen, der dafür z.B. Unterstützung erbringen kann.

 

Dokumentation und Checkliste

Die Ergebnisse der IST-Aufnahme, Anforderungsanalyse und Zielplanung sollten Sie in einer Dokumentation festhalten und einen (wirklich kleinen) Projektplan der zeitlichen Abfolge von Tätigkeiten niederschreiben.

 

Evaluierungsphase

Wenn alle Vorarbeiten erledigt sind, geht es an die Einrichtung des Tenant

Tätigkeit Aufwand Erledigt

Office 365 Tenant einrichten

  • Passenden Tenant-Namen festlegen und Tenant einrichten.
  • Firmen-Domains eintragen und im DNS belegen, dass man "Besitzer" ist.

 

DirSync

In fast allen Office 365 Einführungen ist der "DirSync" einer der ersten Schritte nach der Einrichtung des Tenant. Er wird am Ende der Einführung permanent dafür sorgen, dass die lokal verwalteten Benutzter auch in der Cloud nachgeführt werden. Allerdings gibt es Migrationswege von Exchange nach Office 365, bei denen der DirSync gerade nicht aktiviert sein darf. Ein "erfahrener" Integrator, kann das Risiko abschätzen und spart sich diesen Schritt, vor allem wenn eine Firma "klein" ist.

Es kann aber durchaus interessant sein, den DirSync zu so einer frühen Phase einzurichten, um eben die Funktion zu prüfen und abhängige Prozesse (primäre Provisioning) mit zu verifizieren. Wer später per Cutover migriert, muss natürlich den DirSync vorher wieder abschalten und alle User wieder permanent löschen. Aber das System "verhält" sich dann schon fast wie "Produktion".

Den DirSync-Server müssen Sie aber nicht deinstallieren. Er wird nach der Migration der Postfächer sehr schnell wieder aktiviert, damit die Kennworte der Benutzer in der Cloud auch mit den lokalen Kennworten übereinstimmen.

 

 

Einbindung eigener Systeme

  • FaxServer
    Wenn ihr FaxServer per SMTP eingehende Faxe zustellen kann, dann sollten Sie ihn auch mit der Cloud verbinden. Denken Sie z.B. an einen "Receive Connector" in der Cloud, um der IP-Adresse ihres Faxservers (oder der Firewall) einen Vertrauensvorschuss zu geben.
    Ausgehend muss man prüfen, wie Anwender per SMTP den Faxserver erreichen können. Vielleicht ist dies auch der Zeitpunkt für den Wechsel zu einem Fax-Hosting ?
  • Scan2Mail
    Wenn Die Kopierer/Scanner haben, die Mails an Exchange senden, dann müssen auch diese nu nbei Office 365 abliefern.
  • andere Systeme

Manchmal ist es sinnvoll, ein lokales SMTP-Relay aufzubauen oder die Funktion in der Application Firewall zu nutzen, um Mails von intern Anzunehmen und über ein System in der Cloud abzuliefern. Wenn dieses System dann auch noch TLS kann, ist die Übertragung sicherer und über das Queuung mekrt der Absender nichts von der Bandbreite zu Office 365.

 

Funktionstests

  • Admin und Test-Benutzer einrichten und Lizenzen zuweisen
  • Funktionstests mit Benutzer als "Username@tenantname.onmicrosoft.com
    Diese Benutzer sind "voll" Funktionsfähig. Sie können damit ihre verschiedenen Clients gegen Office 365 prüfen, Office 365 Funktionen evaluieren
  • Anleitungen erstellen
    Für die normalen Anwender sollten sie eine Informationsschrift erstellen: Sie sollten beschreiben, welche Dienste wie genutzt werden sollen und welche Dienste z.B.: noch nicht freigegeben sind.

 

Rückbau

Nachdem alle Tests erfolgt, die Doku erstellt und das Admin- und Betriebskonzept aktualisiert wurde, sollten Sie alles wieder zurückbauen, was die Migration stören könnte.

 

Cutover oder Staged

Die Umstellung der Exchange Postfächer ist abhängig von der Quell-Version.

Version Exchange 2003
Exchange 2007		 Exchange 2010
Exchange 2013
Migrationsweg

Staged Migration

Cutover Migration
Zugriff auf Quelldaten

RPC/HTTP

EWS
Reihenfolge
  • DirSync legt Benutzer an
  • Cloud kopiert Daten aus der Quelle
  • Benutzer wechseln mit MX Umstellung
  • Cutover legt User in Office 365 an
    DirSync darf nicht aktiv sein
  • Cloud repliziert Daten in das Ziel
  • MX-Record wechsel
  • DirSync matched User mit AD-Konten

Der erste sichtbare Unterschied ist natürlich, dass Exchange 2003 und 2007 von der Cloud per RPC/HTTP (Outlook AnyWhere) abgesaugt werden. Exchange 2003 unterstützt noch kein EWS und bei Exchange 2007 gibt es wohl noch einige Limitierungen. Erst Exchange 2010 und neuer werden per EWS ausgelesen.

Leider hat die EWS-basierte Migration die große Einschränkung, dass es keinen DirSync geben darf, da die Migration selbst die Benutzer anlegt. Das ist nützlich, wenn die Firma so klein ist, dass ein DirSync sowieso nicht in Betracht bekommt. Wer aber einen DirSync möchte, muss den quasi zügig nach der Umschaltung einrichten, damit z.B. per KennwortSync sich die Anwender auch am Postfach in der Cloud anmelden kann.

Cutover ist wohl wirklich für kleinere Umgebung, bei denen ein Hybrid Mode nicht sinnvoll ist. Die Exchange 2003/2007 Quellen können mit der Staged Migration auch Benutzergruppen umstellen und DirSync von Anfang an nutzen.

Wer Exchange 2010/2013 hat aber mit  vorher schon aktivem DirSync ohne Hybrid migrieren will, findet bei Drittherstellen entsprechende Hilfsprogramme zum Kopieren der Daten per EWS von On-Prem in die Cloud.

Cutover und Postmigration

Ich beschreibe hier exemplarisch die Cutover Migration, bei der die Mails vorab von Exchange Online per EWS von der On-Prem-Umgebung abgerufen und in der Cloud importiert werden.

Sie können diese Migration theoretisch auch während der "Evaluierungsphase" simulieren um Fehler und Probleme frühzeitig zu erkennen oder Messungen zur Performance machen.

Ich finde es schade, dass gerade die "Cutover"-Migration nur funktioniert wenn DirSync nicht etabliert ist. Es gibt hier Dritthersteller, die Daten zwischen Postfächern replizieren. Das ist durchaus eine interessante Option. Allerdings muss man dann den DirSync anpassen, da ansonsten die Cloud "erkennt", das es ein On-Prem-Postfach ist.

Tätigkeit Aufwand Erledigt

Veröffentlichen von Exchange EWS

Bei der klassischen Cutover Migration holt sich Exchange Online die Information über die Benutzer und deren Inhalte per EWS. Der lokale Server muss also per EWS zumindest von Office 365 per HTTPS erreichbar sein. Denken Sie ein ein passendes SSL-Zertifikat.

 

Anlegen eines Dienstkontos mit Impersonate

Die Cloud braucht ein Konto, welches die Mails aller zu migrierenden Benutzer lesen kann. Dieses muss On-Prem angelegt werden.

 

DirSync zurückbauen

Wenn Sie in der Evaluierungsphase einen DirSync eingerichtet haben, muss der Dienst beendet und die Einstellung im Tenant zurückgestellt werden.

 

Einrichten der Migrations-Job

Über Exchange Online wird nun die Migration der Daten von der On-Prem-Umgebung angestoßen. Exchange Online synchronisiert die Mails der Postfächer in die Cloud. Der Prozess legt aber auch zugleich die Benutzer in Office 365 an. Der DirSync darf hier also noch nicht aktiv sein.

 

Kennwort setzen

Die Cutover-Migration legt Konten in der Cloud mit Kennworten an. Sie können diese Kennworte den Benutzern schon mitteilen. Sie können dann sogar schon mit Office 365 arbeiten, wenn Sie eine Lizenz haben. Das kann sogar nützlich sein, da beim späteren DirSync der Benutzer sein Kennwort On-Prem ändern muss, damit das Konto in der Cloud auch das gleiche Kennwort hat.

So kann er nach dem späteren Umschalten sofort weiter machen und muss nicht erst sein Kennwort On-Prem ändern.

 

Schwenken des Mailrouting

  • Umstellen MX-Record
    Diese Vorarbeit sorgt dafür, das Absender ihre Mails nun an Office 365 senden. Es kann einige Stunden oder Tage dauern, bis wirklich alle Absender diese neue Information erhalten haben
  • Sperren des alten Mailzugang
    Daher muss der Eingang zum alten System natürlich geblockt werden. Nach diesen beiden Schritten sollte zumindest aus dem Internet niemand mehr die alte Umgebung erreichen
  • Aussperren der Benutzer
    Aber auch die interne Zustellung muss unterbrochen werden, damit die Anwender untereinander sich keine Mails mehr senden oder Termine verändern können, die dann nicht mehr in das Ziel repliziert würden

 

Abschluss der Replikation

Nachdem das lokale System "frozen" ist, kann die Cloud ein letztes Mal die Daten replizieren und die Migration abschließen.

 

Abschalten des alten Servers

Um sicherzugehen, dass niemand mehr den alten Server anspricht, sollten Sie nach Abschluss der Migration zumindest die Exchange Dienste beenden.

 

Autodisover

Vergessen Sie nicht die "autodiscover.<maildomain > in die Cloud umzustellen. Dies gilt sowohl für die DNZ-Zonen im Internet für externe Anwender wie auch für die interne Namensauflösung.

 

Nun haben Sie den Zwischenstand, dass alle Postfächer in der Cloud sind und auch die Client dort hin gesendet werden.

DirSync mit Kennwort reaktivieren

Nachdem alle Postfächer in der Cloud aktiviert wurden wird der DirSync aktiviert. Der Prozess nutzt das Feld "Mail" der On-Prem-Umgebung und findet damit die Cloud-Konten. Wenn alles gut geht, dann "matchen" die Konten und mit aktivierten Kennwort-Sync haben die Konten in der Cloud nach wenigen Minuten dann auch das gleiche Kennwort wie On-Premises.

Tätigkeit Aufwand Erledigt

DirSync aktivieren

Wenn Sie in der Evaluierungsphase den DirSync noch installiert (aber nicht aktiv) haben, dann können Sie den Dienst einfach wieder starten und einen "FullSync" machen.

 

Kennwort Lokal ändern

Leider muss der Anwender sein Kennwort lokal einmal ändern, damit die Kennwortsynchronisation das neue Kennwort in die Cloud übertragen kann.

 

Nachsorge

Autodiscover und Co machen sicher einen guten Job. Dennoch kann es den ein oder anderen Client geben, der etwas Nachhilfe braucht.

 

Skype for Business, SharePoint und mehr

Die Plattform ist da, jeder Benutzer hat ein Konto in der Cloud und kennt seine Zugangsdaten. Was liegt da näher als die anderen in den Lizenzen enthaltenen Funktionen zu nutzen.

Weitere Links