Was Sie nach der Migration auf Office 365 sowie Exchange erledigen müssen

Alte Serverinfrastruktur entfernen oder als Stand-by nutzen

Ob nun eine Migration zu einer neuen Exchange-Version oder zu Office 365 ausgeführt wurde: Die alten Server müssen stillgelegt und notwendige Daten zu den neuen Servern oder in die Cloud verschoben werden. Dabei sollten sich Administratoren darüber im Klaren sein, welchen Weg sie beim Entfernen gehen wollen. Wollen Sie die bestehende Infrastruktur komplett stilllegen und außer Betrieb nehmen oder noch als Stand-by im Netzwerk nutzen? Eine weitere Möglichkeit ist, die lokalen Server als Mail-Relay für das Internet oder in die eigene Cloud zu behalten. Diese Entscheidung ist natürlich vor den weiteren Aufgaben zu treffen.

Sind neue Server oder Office 365 mit der Organisation verbunden, lassen sich Postfächer verschieben, damit die Anwender weiter arbeiten können.

Unabhängig davon, welche Aufgabe Sie der alten Infrastruktur zugedacht haben, verursachen alle Konfigurationen Mehrarbeit. Wissen Sie aber bereits frühzeitig, was mit den alten Servern passieren soll, erleichtert das die Migration deutlich. Außerdem wissen Sie dadurch, wann das Exchange-Migrations-Projekt abgeschlossen ist und Sie mit der nächsten großen Aufgabe beginnen können.

Alte Exchange-Server entfernen

Wenn Sie sich entscheiden, die Postfächer zu Office 365 umzuziehen, benötigen Sie die lokalen Exchange-Server in den meisten Fällen nicht mehr. Aus diesem Grund sollten Sie diese möglichst restlos aus dem Netzwerk nehmen oder zumindest auf ein Minimum reduzieren. Entfernen Sie immer die ältesten Exchange-Server zuerst. Betreiben Sie zum Beispiel noch ältere Exchange-Server im Netzwerk, also solche vor Exchange Server 2010/2013? Wenn diese keine Rolle mehr als Client-Zugriffs-, Postfach- oder Verwaltungsserver spielen, sollten Sie diese zuerst tilgen. Sollten die Postfächer in Ihrem Unternehmen keinerlei Dienste mehr auf den alten Servern benötigen, können Sie sich von ihnen getrost verabschieden.

Server, die eine Aufgabe bei der Migration oder für die Hybrid-Bereitstellung übernehmen, müssen Sie vorsichtig entfernen, zum Beispiel solche für E-Mail-Relay, Postfachverwaltung oder Client-Zugriff. Da diese Server noch im produktiven Einsatz sind, gilt es zuerst sicherzustellen, dass alle Aufgaben entweder von den neuen Servern übernommen oder die Dienste in die Cloud ausgelagert werden. Auch wenn Sie nicht sicher sind, ob ein Server noch eine Aufgabe in der Exchange-Organisation oder der Hybrid-Bereitstellung einnimmt, sollten Sie beim Entfernen vorsichtig sein.

Ein- und ausgehenden E-Mail-Fluss beachten

Ein wesentlicher Bestandteil bei der E-Mail-Migration ist der E-Mail-Fluss zwischen Server, Internet und der Cloud beim Einsatz von Office 365. Hier ist zu beachten, welche Server die E-Mails routen und ob neue Connectoren auf den neuen Servern notwendig sind. Bei einer Migration zu Office 365 sollten alle E-Mails möglichst immer über Office 365 laufen. Ein Grund dafür ist, dass die E-Mails automatisch nach Viren mit Exchange Online Protection gescannt werden. Für diesen Vorgang müssen Sie entweder die MX-Einträge Ihrer E-Mail-Domäne anpassen oder eigene DNS-Einstellungen ändern. Auch Einstellungen auf Servern im internen Netzwerk sind oft notwendig, zum Beispiel wenn Serverdienste E-Mails mit SMTP über Exchange-Server versenden.

Für fehlerfreien E-Mail-Fluss sind bei der Migrationen häufig neue Connectoren notwendig. Bei der Migration zu Office 365 sollten E-Mails immer über Office 365 laufen.

In der Office-365-Verwaltungskonsole müssen Sie die korrekten DNS-Einträge festlegen lassen, damit der E-Mail-Fluss funktioniert. Das gilt vor allem für den MX-Eintrag und Autodiscovery.

Wenn aktuell alle Ihre E-Mails über die interne Organisation geschickt werden, die Postfächer aber in Office 365 gespeichert sind, ist in diesem Bereich besondere Vorsicht angebracht. Hier sind Aufgaben in Office 365, aber auch in der alten Exchange-Organisation notwendig. Wichtig ist in diesem Zusammenhang das Umlegen der MX-Einträge ihrer Domänen zu Office 365. Dieser Vorgang kann mehrere Tage dauern.

Bei der Migration zu Office 365 müssen Sie auch Exchange Online Protection berücksichtigen und anpassen.

Wenn Sie mit einer Hybrid-Konfiguration arbeiten, müssen Sie auch bei der Konfiguration von Exchange Maßnahmen ergreifen, damit die E-Mails auf Viren gescannt und lokal überprüft werden. Unternehmen, die zu Office 365 wechseln und den eigenen E-Mail-Server entfernen, sollten beim Einsatz von Forefront Online Protection for Exchange (FOPE) beziehungsweise EOP zunächst die Domänen deaktivieren, die künftig von Office 365 gehostet werden. Diese Einstellungen sind im FOPE Administration Center zu finden. Löschen Sie nach einiger Zeit die deaktivierten Domänen in FOPE, da diese ohnehin nicht mehr durch diesen Dienst geschickt werden. Die genauen Unterschiede zwischen EOP und FOPE lesen Sie auf dieser Microsoft-Seite.

Autodiscovery konfigurieren

Damit sich die Outlook-Clients, aber auch die Smartphones der Anwender mit den Postfächern verbinden können, ist die Autodiscovery-Funktion ein wichtiger Bereich bei einer Migration. Durch Eingabe der E-Mail-Adresse weiß der Client über die DNS-Einstellungen der entsprechenden Domäne, wie die IP-Adressen der Server lauten und wie sich diese verbinden lassen. Daher müssen die Anwender nicht den Namen der E-Mail-Server kennen, vielmehr reicht es aus, dass sie sich an ihren Endgeräten mit ihrer E-Mail-Adresse und dem Kennwort anmelden, das Sie ihnen zugeteilt haben.

Wenn Sie zu Office 365 wechseln, verbinden sich die Outlook-Clients der lokalen Anwender immer noch mit den lokalen Exchange-Servern und suchen im Active Directory nach einem Dienstendpunkt für Autodiscovery. Bevor Sie also ehemals produktive Server abschalten, müssen Sie zunächst sicherstellen, dass für Ihre E-Mail-Domänen Autodiscovery-Funktionen in Office 365 gesetzt sind. Das geschieht normalerweise durch die Einbindung der Domäne in den Domänen-Assistenten von Office 365.

Damit Clients wie Outlook wissen, welche Exchange-Server sie nach einer Verbindung fragen sollen, ist in Active Directory hinterlegt, auf welchen Exchange-Servern mit der Client-Zugriffs-Serverrolle die Funktion Autodiscover zur Verfügung steht. Diesen Dienst bezeichnet Microsoft als Dienstverbindungspunkt. Sie lassen sich dessen Einstellungen im Snap-In Active Directory-Standorte und -Dienste anzeigen. Dazu müssen Sie im Menü Ansicht den Befehl Dienstknoten anzeigen wählen. Bei der Migration zu Office 365 werden diese Aufgaben künftig von DNS-Servern im Internet für Ihre E-Mail-Domäne übernommen, genauso wie der MX-Eintrag.

Starten Sie Outlook auf einem Computer, der nicht Mitglied der Domäne ist, dann kann der Client das Active Directory nicht durchsuchen. In diesem Fall verwendet Outlook den DNS-Eintrag der E-Mail-Adresse, die beim Start eingegeben werden muss. Outlook 2013 versucht sich dann über HTTPS mit einem Client-Zugriffs-Server oder mit Office 365 zu verbinden und verwendet dazu die folgenden URLs:

https://Autodiscover.<DNS-Name der E-Mail-Domäne>/autodiscover/autodiscover.xml

und

https://<DNS-Name der E-Mail-Domäne>/autodiscover/autodiscover.xml

Damit Outlook eine Verbindung zu den Servern herstellen kann, muss sich der Servername auflösen lassen. Dies bedeutet, dass Sie DNS-Einträge in der DNS-Zone oder den öffentlichen DNS-Servern für Ihre Zone erstellen müssen, damit auf diese Webseiten zugegriffen werden kann. Das ist vor allem bei der Migration zu Office 365 wichtig.

Sobald Sie Microsoft Outlook gestartet haben, erscheint im Info-Bereich der Taskleiste das Outlook-Symbol. Wenn Sie mit der rechten Maustaste auf das Symbol klicken und dabei die Strg-Taste gedrückt halten, steht Ihnen die Option E-Mail-AutoKonfiguration testen zur Verfügung. Hierüber können Sie überprüfen, ob die Autodiscover-Funktion korrekt eingerichtet ist.

Arbeiten Sie mit Office 365, dann haben Sie in den Einstellungen Ihrer E-Mail-Domäne die DNS-Server von Microsoft eingetragen. Diese verwenden wiederum den Eintrag autodiscover.outlook.com, damit Ihre Clients automatisch angebunden werden. Wichtig ist, dass die DNS-Server von Office 365 für Ihre Domäne zuständig sind oder Sie die Einträge manuell vornehmen.

In den DNS-Einstellungen für Ihre E-Mail-Domänen sind die Office-365-DNS-Server hinterlegt. Diese übernehmen wiederum die automatisierten DNS-Einträge für Autodiscovery.

Um im lokalen Netzwerk den Dienstverbindungspunkt zu löschen, verwenden Sie die Exchange-Verwaltungs-Shell und den Befehl:

Set-ClientAccessServer <ServerName> -AutoDiscoverServiceInternalUri:$null

Bevor Sie also alte Server abschalten, stellen Sie sicher, dass der Autodiscover- und MX-Eintrag der Domäne funktioniert. Danach können Sie die alten Server deaktivieren. Ein Tipp: Lagern Sie bei diesen Vorgängen möglichst alle Einstellungen zu Office 365 aus. Dadurch ist die korrekte Konfiguration sichergestellt, und Sie sind künftig von Verwaltungsaufgaben freigestellt, da die Vorgänge nur einmal eingerichtet und dann von Office 365 automatisch überwacht werden.

OWA-URLs umstellen

Wenn Sie zu einer neuen Exchange-Version oder zu Outlook Web App migrieren, müssen Sie auch die Outlook-Web-App-URLs für die Anwender umstellen. Das gilt vor allem dann, wenn Sie mit Office 365 arbeiten. Es ist erforderlich, dass die Anwender die neuen URLs für den Zugriff auf Outlook Web App kennen. Nutzen Sie im Unternehmen eigene DNS-Einträge, dann müssen Sie diese einfach umleiten oder löschen und den Anwendern die neuen URLs mitteilen.

Greifen Anwender über das Internet auf OWA zu, dann verwenden diese künftig eine neue URL, die direkt zur Office-365-Anmeldeseite verweist. Office Web App in Office 365 entspricht der Oberfläche und den Möglichkeiten von OWA in Exchange Server 2013. Sollen Anwender auch intern auf OWA zugreifen können, müssen Sie auf Ihren DNS-Servern die Einstellungen so ändern, dass die neuen URLs von Office 365 verwendet werden. Die URL für den Zugriff auf OWA in Office 365 lautet: https://outlook.com/owa/<E-Mail-Domäne>. Wollen Sie Ihre alten OWA-URLs weiternutzen, erstellen Sie für die entsprechende Domäne einen neuen CNAME-Eintrag, der zum neuen Server weiterleitet. Unabhängig davon, ob Sie sich im Unternehmen über Office 365, Active Directory-Verbunddienste oder mit Azure Active Directory anmelden: Die Anwender werden für die Anmeldung an OWA immer an die richtige Adresse weitergeleitet.

Postfachverwaltung und DirDync

Sie haben die Möglichkeit, Benutzerkonten zwischen Actrive Directory und Office 365 sowie mit Active Directory-Verbunddiensten oder Azure Active Directory zu synchronisieren. Nach einer Umstellung zu Office 365 müssen Sie diese Synchronisierung überprüfen und anpassen. Über die Synchronisierungsfunktion können Sie auch nach der Migration neue Benutzerkonten zwischen den Verzeichnissen synchronisieren; das gilt gleichermaßen für Änderungen der Kennwörter und anderer Daten der Anwender.

Bei der Verwaltung der Benutzer ist darüber hinaus zu beachten, wo deren Konten gespeichert sind und wie diese synchronisiert werden. Hier unterscheiden sich lokale Exchange-Server deutlich vom Betrieb der Cloud-Dienste in Office 365 und Azure Active Directory.

Mit Windows Azure Active Directory synchronisieren Sie Daten zwischen lokalen Exchange-Organisationen mit Active Directory und Office 365.

Benötigen die User neben dem Zugriff auf Office 365 noch bestimmte Attribute im lokalen Active Directory, zum Beispiel weil Sie bestimmte Serverdienste wie SharePoint oder Lync (noch) nicht ausgelagert haben? Dann müssen Sie einen Workflow entwickeln, der vorgibt, wie diese Daten in Zukunft gepflegt werden sollen. Da gilt natürlich auch dann, wenn Benutzer mehrere E-Mail-Adressen verwenden, zum Beispiel beim parallelen Betrieb von Office 365 und lokalen Exchange-Servern.

Lokale Exchange-Server und Office 365 lassen sich nur begrenzt in einer einzelnen Weboberfläche verwalten. Für beide Varianten gibt es Möglichkeiten für die PowerShell. Dazu müssen Sie jedoch die CMDlets für Office 365 erst installieren, einrichten und mit dem Office-365-Abonnement verbinden. Danach können Sie in der Exchange-Verwaltungs-Shell die CMDlets für Office 365 nutzen und viele Einstellungen auf diesem Weg vornehmen, ohne ständig die Verwaltungswerkzeuge wechseln zu müssen.

Mail-Relay für Geräte und Anwendungsserver

Bei der Umstellung zu Office 365 und einer neuen Version von Exchange sollten Sie auch Ihre Netzwerkgeräte und Anwendungsserver berücksichtigen. Gibt es hier irgendwelche Verbindungen zu Exchange, zum Beispiel E-Mail-Benachrichtigungen, sind diese auf Office 365 oder Exchange umzustellen.

Vor allem CRM- und Finanzsysteme, die Berichte versenden, überwachen und Warnungen abschicken, sind hier zur berücksichtigen. Das gilt auch für Netzwerk-Switches, Storage-Systeme, Drucker, Service-Desk-Lösungen und Geräte wie Scanner oder Kopierer, die ebenfalls E-Mails senden oder empfangen können. Alle diese Geräte müssen Sie anpassen und auf Office 365 umstellen. Die Geräte müssen dazu für den sicheren E-Mail-Fluss SSL oder TLS beherrschen. Verwenden Sie intern noch den Port 25, müssen Sie diesen umstellen, wenn die E-Mails direkt in das Internet geschickt werden, sonst entsteht hier eine Sicherheitslücke.

Die entsprechenden Einstellungen können Sie direkt im Verwaltungs-Center von Office 365 vornehmen und auch testen. Hier ist festzulegen, von welchen externen E-Mail-Adressen Office 365 E-Mails annehmen und weitersenden kann. Normalerweise werden alle E-Mails, die an Office 365 weitergeschickt werden, erst durch Exchange Online Protection (EOP) nach Viren gescannt. Daher lassen Sie die internen Geräte am besten an das Sicherheits-Mail-Relay anbinden. Dieses hat normalerweise die Adresse im Format: domain-com.mail.protection.outlook.com.

Sie haben aber auch die Möglichkeit, alle internen E-Mails zu einem gemeinsamen internen Relay weiterzuleiten, zum Beispiel einem Windows-Server mit aktiviertem SMTP-Server im IIS. Dieser Server gibt die E-Mails dann gebündelt an Office 365 weiter. Natürlich können Sie in diesem Fall auch weiter einen lokalen Exchange-Server betreiben, der diese Aufgabe zukünftig übernimmt.