Office 365 Migration aus der Praxis (Stand 2015)
Outlook Versionen beachten!
In Konzepten und Anforderungen wird viel über die Outlook Versionen geschrieben. Leider kommt es immer wieder vor, dass die Minumumvorraussetzungen nicht eingehalten werden.
Leider treten diese Fehler erst während der Migration zu Office365 auf und werfen ein negatives Bild auf das Projekt. Bitte Prüfen, am Besten von jedem Client den genauen Versionsstand einfordern.
Eine einfache Frage verdeutlicht das Problem: Wie soll Outlook 2010 ein Cloud-Lösung unterstützen welches erst 2012 die Marktreife erlangt hat?
Migrationseinschränkungen beachten!
Serverbasierte Regeln werden bei einer Postfachmigration in eine neue Exchange-Organisation (Office365) nicht immer übernommen.
Postfächer welche unter Exchange Proxyadressen zugewiesen haben, deren Domäne unter Office365 nicht angelegt wurde, können erst nach einer Bereinigung migriert werden.
Indirekte Exchange-Berechtigungen, durch Gruppen auf Postfächer können nur übernommen werden, wenn die Gruppen vor der Migration der Postfächer unter Office365 bereitgestellt werden. Ich löse diese indirekten Berechtigungen auf, da die Automapping Funktion der Postfächer sonst nicht funktioniert.
Verteilergruppen können wenn diese mittels AADConnect unter Office365 bereitgestellt werden nicht bearbeitet werden. In einem meiner vorhergehenden Einträge habe ich eine Lösung mittels eines Powershell Skript beschrieben.
Organisationsübergreifende Zugriffe auf Postfächer funktionieren laut Microsoft nicht. Eine Einschränkung gibt es. Wenn eine Shared Mailbox nicht über das Automapping verbunden wurde, sondern manuell, kann nach der Migration des persönlichen Postfach weiterhin mit dem Teampostfach gearbeitet werden (kein Support!).
Wird ein manuell verbundenes Teampostfach zu Office365 migriert, aktualisiert Outlook die Verbindungsdaten nicht. Lösung: Alle zusätzlich verbunden Postfächer unter Outlook trennen und mittels Automapping wieder zu verbinden.
Netzwerkeinschränkungen beachten!
Für das beste Nutzungserlebnis mit Offic365 sollte kein Proxy verwendet werden. Die Umgehung des Proxy sollte auch nicht in einer zentralen Proxypac konfiguriert werden sondern lokal am Client durch eine GPO erfolgen.
In einem Projekt entstand die Herauforderung einer sehr schlechten Verbindungsqualität durch das massive Anfordern der Proxypac vom Webserver/Proxy. 6000 aktiven Verbindungen haben die Zeit bis der Proxy, die Pac-Datei ausgeliefert hat auf 25 Sekunden ansteigen lassen.
Porteinschränkung beachten!
Jede öffentliche IP hat eine begrenzte Anzahl an Ports. Wenn mit Office365 (EXO) gearbeitet wird, ist dieses Thema sehr wichtig da Outlook pro verbundenes Postfach zwei Verbindungen aufbaut. 65536 minus 1023 reservierte Ports, bleiben 64000 nutzbare Ports.
Pro Postfach baut Outlook zwei Verbindungen auf. Das bedeutet theoretisch 32000 Verbindungen, gleichzeitig muss die TTL berücksichtigt werden. Der Port ist nicht direkt frei wenn Outlook beendet wird. Eine generelle Aussage kann nicht getroffen werden. Microsoft empfiehlt nicht mehr als 6000. Die Wahrheit liegt irgendwo in der Mitte…
Konnektoren beachten!
Die Einrichtung eines Fax Connector um Faxe mittels Outlook zu versenden (Empfänger [fax:0123456]) ist nicht möglich.
Der zweite bekannte weg einer FAX Domäne wie zum Beispiel fax.local (Empfänger 0123456@fax.local) zu nutzen, ist weiterhin möglich.
Ein Relay an nicht im Internet publizierte interne Domänen wie zum Beispiel meinefirma.local ist wie unter Exchange möglich.
Hybrid
Bei der Aktivierung der Hybrid-Konfiguration zwischen Exchange und Office365 wird die Default-E-MailPolicy unter Exchange um die onmicrosoft.com E-Mailadresse ergänzt.
Anschließend erfolgt ein Update aller E-Mail Adressen. Das kann mitunter dazu führen, dass Anwender mit falschen E-Mail Adressen versenden.
Hintergrund sind meist Deploymenttools welche nicht mit der Exchange E-Mail-Policy abgestimmt sind.