Exchange 2010-Migration zu Office 365 mit ADFS

Question

Lassen Sie mich zunächst mit der Erläuterung unserer Umgebung beginnen.

Wir haben eine AD-Domäne - de***.co.uk

Unabhängig davon, in welcher Abteilung ein Benutzer ist, authentifiziert sich jeder Benutzer bei allen Systemen (inkl. Exchange) mit seinem Domänenkonto (user@de***.co.uk) oder (de***\user), selbst wenn seine E-Mail-Adresse[email geschützt](das kommt häufig vor, ich weiß)

Wir planen, schrittweise auf Office 365 E3 umzusteigen, eine Abteilung nach der anderen. Wir haben ca. 300 Mitarbeiter, 47 akzeptierte E-Mail-Domänen und >600 Postfächer (von denen einige möglicherweise nur lokal in pst archiviert werden). Wir in der IT haben 365 E3 mit einer Domäne getestet, die uns gehört: de***s****.co.uk, und Benutzer/Postfächer manuell eingerichtet.

Wir sind nun bereit, eine Abteilung auf Testversion 365 (20 Benutzer) umzustellen, möchten jedoch eine Verknüpfung mit unserem lokalen AD herstellen. Diese Teilmenge von Benutzern wird eine E-Mail-Adressdomäne mit der Domain @le***********.com haben.

Nach allem, was ich bisher erfahren habe, bin ich der Meinung, dass dies die Schritte sind, die ich ausführen muss (bitte korrigieren Sie mich, wenn ich falsch liege).

• Einrichten von ADFS
• Fügen Sie unserem 365-Konto die Domäne @le***********.com hinzu ********(nicht sicher, wie wir die Benutzer bekommen)********
• Ändern Sie die DNS-Einträge von le***********.com, damit sie auf Office 365 verweisen
• Kann ich die PST-Datei jedes Benutzers in sein 365-Konto importieren oder eine andere Methode verwenden?

Es ist der ADFS-Teil, der für Verwirrung sorgt. Bisher habe ich mehrere Tutorials gelesen, in denen die Dinge unterschiedlich angegangen werden (in einem heißt es, ADFS auf einem DC zu installieren, in einem anderen, drei neue Server einzurichten – einen ADFS-Proxy, einen ADFS-Server und einen DirSync-Server). Welches ist am besten?

Während der Einrichtung von ADFS wird gesagt, dass ein SSL-Zertifikat auf IIS installiert werden muss. Wäre dieses Zertifikat hostname.de***.co.uk oder hostname@le*********.com und jede andere akzeptierte E-Mail-Domäne, die ihr eigenes SSL benötigt?

Wären die anderen Benutzer, die sich auf der lokalen Börse befinden, von diesem Vorgang betroffen?

Grüße

Answer 1

Hier sind die besten Szenarios, um auf Grundlage der von Ihnen bereitgestellten Informationen weiter vorzugehen.

Benutzerauthentifizierung: Es gibt 3 Modelle, mit denen Sie hier arbeiten können:

1. Benutzer in Office 365 (Cloud-Konten): Die Benutzerverwaltung erfolgt vollständig in der Cloud. Sie können Benutzer erstellen, deaktivieren, Kennwörter zurücksetzen und alle Einstellungen über das Office 365-Portal vornehmen. Sie benötigen hierfür kein lokales AD. Diese Option funktioniert in Ihrer Umgebung offensichtlich nicht, da Sie bereits ein lokales AD mit Exchange haben und die Benutzerverwaltung lokal im AD steuern möchten.
2. Benutzer in AD, mit Einweg-Synchronisierung mit Office 365 (Semi-Federated Accounts): Mit diesem Modul können Sie Konten erstellen und die gesamte Benutzerverwaltung auf Ihren lokalen AD-Servern durchführen. Sie installieren ein Tool namens „DirSync“ oder die neuere Version „ADD Sync“, um eine Kopie der Benutzer von Ihrem lokalen AD in der Cloud zu erstellen. Die Tools bieten die Option, auch die Passwörter der Benutzerkonten vom lokalen AD mit der Cloud zu synchronisieren, wodurch Ihre Benutzer sich mit denselben Benutzeranmeldeinformationen bei lokalen Ressourcen in der Domäne und bei Office 365 anmelden können. Dadurch entsteht eine Semi-SSO-Erfahrung. Benutzer müssen beim Zugriff auf Ressourcen in Office 365 ihren Benutzernamen und ihr Passwort angeben und die Benutzerauthentifizierung/-überprüfung erfolgt auf der Cloud-Seite. Die Voraussetzungen für dieses Modul bestehen darin, die zuvor erwähnten Tools auf einem beliebigen Server in Ihrem lokalen Netzwerk zu installieren. ADFS oder ADFS-Proxy sind nicht erforderlich. Sie sollten diese Option wählen, da sie am einfachsten zu implementieren und zu unterstützen ist.
3. Benutzer in AD, mit bidirektionaler Synchronisierung mit Office 365 (vollständig föderierte Konten): Dies ist die fortschrittlichste Option der drei. Sie verwendet alle Einstellungen der vorherigen Option „Benutzer in AD mit Einwegsynchronisierung mit Office 365“ und bietet zusätzlich die Möglichkeit, die Benutzerauthentifizierung/-überprüfung auf Ihren lokalen AD-Servern mithilfe von ADFS und ADFS-Proxyserver zu erzwingen. Sie müssen entweder in Ihrem lokalen Netzwerk oder in einem Azure-Hybridnetzwerk über eine Bereitstellung von ADFS/ADFS-Proxy und AAD Sync verfügen. Mit dieser Option erhalten Sie ein vollständiges SSO-Erlebnis, da Benutzer in der Domäne auf Office 365 zugreifen können, ohne einen Benutzernamen und ein Kennwort angeben zu müssen. Ich würde diese Option nicht empfehlen, da die Installation, Konfiguration und Unterstützung eine IT-Horrorgeschichte ist.

Hier finden Sie zahlreiche Informationen zum Nachlesen und Weiterverwenden:https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

E-Mail-Migration: Da Sie Exchange 2010 im Netzwerk haben, sind hier die unterstützten Möglichkeiten zum Migrieren Ihrer E-Mails:

1. Cutover-E-Mail-Migration: Über das Office 365-Portal erstellen Sie einen Migrations-Batchjob. Der Job sucht mithilfe der Exchange-AutoErmittlung nach den Benutzerpostfächern, greift auf die Benutzerpostfächer auf dem lokalen Exchange-Server zu und beginnt mit dem Kopieren des Postfachinhalts in die Cloud. Dies alles kann geschehen, während der Benutzer das Postfach auf dem lokalen Server noch verwendet. Sobald alle E-Mails erfolgreich in die Cloud kopiert wurden, stoppen Sie den Migrations-Batch und ändern die DNS-Einträge, sodass neue E-Mails/AutoErmittlung auf den Cloud-Mailserver und nicht auf den im lokalen Netzwerk verweisen. Benutzer müssen neu konfiguriert werden, um auf den neuen Server zugreifen zu können, und Sie können die Benutzerpostfächer vom lokalen Server entfernen, da dieser nicht mehr verwendet wird. Ich persönlich bevorzuge diese Option.
2. Massenexport/-import von PST-Dateien im Auftrag von Benutzern: Sie verwenden ein Tool zum Exportieren der Benutzerpostfächer in PST-Dateien. Sie können diese Dateien auf einer Festplatte speichern und zum Importieren an Microsoft senden, oder Sie speichern die PST-Dateien in einem lokalen Ordner und importieren sie dann mithilfe eines Migrationsassistenten von Office 365 selbst in Office 365. Ich würde diese Option nicht in Betracht ziehen, es sei denn, Ihre Postfächer sind relativ klein.
3. Bitten Sie Ihre Benutzer, den PST-Import/-Export durchzuführen: In einer perfekten Welt könnten Sie Ihre Benutzer bitten, ihre Postfächer in eine PST-Datei zu exportieren, die Dateien lokal auf ihren Rechnern zu speichern, Outlook so zu konfigurieren, dass es mit dem neuen Postfach in der Cloud funktioniert, und die PST-Datei von ihren Rechnern in das neue Postfach zu importieren. Ich würde diese Option um jeden Preis vermeiden, weil... nun ja... Endbenutzer.

Weitere Informationen zur E-Mail Migration finden Sie hier:https://support.office.com/en-us/article/Möglichkeiten-mehrere-E-Mail-Konten-zu-Office-365-0a4913fe-60fb-498f-9155-a86516418842

Wenn Sie Option 2 für die Authentifizierung und Option 1 für die E-Mails auswählen, benötigen Sie weder ADFS noch ein Zertifikat, um die Migration abzuschließen. Endbenutzer sind nur in den letzten Phasen der Cutover-Migration betroffen.

Hoffe das hilft.

BEARBEITEN:

Ihre Migrationsschritte sollten einfach sein. Befolgen Sie diese Tipps:

1. Fügen Sie alle akzeptierten Domänen zum Office 365-Portal hinzu und überprüfen Sie sie.
2. Verwenden Sie das Microsoft IDFix-Tool, um sicherzustellen, dass die Formatierung und Daten Ihrer lokalen Konten mit Office 365 kompatibel sind.
3. Erstellen Sie die ADFS-Integration (ich würde trotzdem DirSync verwenden, nur weil Sie es überall installieren können und keine Hardware dafür benötigen. Es würde trotzdem genauso laufen wie ADFS ohne die automatische SSO-Anmeldung, aber in Ihrem Fall scheint ADFS eine Voraussetzung zu sein)
4. Erstellen Sie eine Verbundvertrauensstellung zwischen Ihrem lokalen Mailserver und Office 365.
5. (Optional) Leiten Sie eingehende E-Mails zunächst in die Cloud um, um einen besseren Viren- und Spamschutz zu gewährleisten.
6. Weisen Sie Ihren Benutzern, die Sie zu Office 365 verschieben möchten, Lizenzen zu.
7. Beginnen Sie nach Bedarf mit dem Verschieben der Benutzer für die einzelnen Abteilungen.
8. Nachdem alle Benutzerkonten in die Cloud verschoben wurden, entfernen Sie die Verbundvertrauensstellung zwischen Office 365 und Ihrem lokalen Mailserver. Behalten Sie ADFS oder DirSync, obwohl diese immer vorhanden sein müssen.
9. Entfernen Sie den lokalen Mailserver nach Bedarf. Sie haben die Möglichkeit, ihn zu virtualisieren und ausgeschaltet zu lassen.