none
Domainkonsolidierung von 4 Domänen mit je einem Exchange auf eine neue Domain mit Offic365 RRS feed

  • Întrebare

  • Hallo an Alle!

    Ich habe hier eine Infrastruktur mit 4 Domänen (firma1,2,3,4 .intern) bestehend aus je 2 Domain Controllern (2008r2 u 2012r2), 1 Terminalservern (2008r2 u 2012r2) und 1 Exchangeservern (2010 u 2013 ebenfalls auf entweder 2008r2 bzw 2012r2)

    Nun sollen alle 4 Domänen mit den bestehenden Usern in eine neue AD (ad.firma.org) gebracht werden. Parallel dazu ist die Einführung von Office 365 geplant.

    Pro Exchange sind ca 80 Mailboxen; Alle Server laufen auf je einem VMWare ESXi Host.

    Alle User auf den 4 Exchange Servern haben die gleiche offizelle Domain. Mails kommen über den Provider, werden dort auf einem Gateway Server auf SPam, AV usw gescannt und dann intern auf den jeweiligen Exchange weitergeleitet (eigene Subdomain-Email Adresse zb. userx@firma1.firma.org)

    Der UPN Name für die Office365 Migration ist bereits bei allen Usern hinzugefügt (firma.org).

    Mein Plan dazu wäre nun pro Domain:

    Update Exchange auf jeweils aktuellste Version

    Einrichten Ad-Connect für AD Sync zu Azue AD mit Passwortsync;

    Migration der Exchange Postfächer

    Aufheben der ADSync

    ->>>>User arbeiten weiterhin am alten Terminalserver (login via Netbios Namen)

    Dekomissionierung des lokalen Exchange,

    ADMT 3.2 installieren; AD-Sync in die neue Domain OHNE SID History

    Installierern, Konfigurieren und Datenübernahme auf den neuen Terminalserver unter Server 2019; Test RDP-Server

    Mit ADMT SID-History übernehmen, Test Outlook Verbindung zu Office 365;

    Mit der Übernahme der SIDs in die neue Domain und vorher mit ADConnect in Azure AD sollte die Verbindung funktionieren.

    Meine Frage wäre nun: Habe ich hier einen Denkfehler, was sagt ihr dazu ? Würdet ihr was anderes machen ?

    Danke im vorhinein für alle Anregungen und Tips!

    Herzliche Grüße

    Reinhold

    duminică, 10 mai 2020 17:07

Răspunsuri

Toate mesajele

  • Moin,

    ein paar Punkte, in keiner besonderen Reihenfolge:

    1. habt ihr in den Quell-Forests öffentliche Ordner und vor allem mail-aktivierte öffentliche Ordner? Das musst Du gesondert betrachten, denn diese Migration kann dauern.
    2. braucht ihr die SID History wirklich? Ich würde versuchen, das zu vermeiden - im Zweifel, Ressourcen zuerst migrieren oder zumindest vorberechtigen.
    3. Was wollt ihr mit den Benutzerprofilen anstellen?
    4. Im letzten Schritt müsst ihr übrigens nicht so sehr die SID History (s.o.) wie vor allem die Immutable ID in die Zieldomain übernehmen.

    Je nachdem wie cholerisch die User drauf sind, würde ich wahrscheinlich ein Third Party Tool erwägen, um die Koexistenz smoother zu gestalten. Für 300 User ist der Preis dafür überschaubar.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    luni, 11 mai 2020 05:48
  • Hallo Evgenij,

    danke für die Antwort.

    Zu deinen Fragen:

    ad 1) Nein, es gibt zu meiner Freude keinerlei öffentliche Ordner

    ad 2) Danke für den Hinweis mit der SID History: Ich war da auf Exchange eingeschossen. Aber das brauche ich ja in der Cloud nicht. Der TS wird ja komplett neu installiert, teilweise umstrukturiert. Hier werden alle Rechte neu vergeben.

    ad 3) Die Benutzerprofile werden neu erstellt, der alte TS ist ein 2008r2 mit Installationdatum 2010. Ich kenne leider keine wirklich gute Möglichkeit, die Profile von alten Dingen zu befreien und zu übernehmen. Bin da für jeden Tip dankbar.

    ad 4) Teileweise sind Benutzer mit dem Default UPN schon in der Cloud angelegt, aufgrund einer dem Coronavirus zu verdankenden vorgezogenen Implementation von Teams. Da in den alten und der neuen Domain die User den gleichen UPN verwenden war der Gedanke, via SMTP Match die User dann wieder zuzuordnen.

    Ich habe heute mal eine Testmigration von ein paar Usern in einer Testumgebung gemacht. Da hatte ich das Problem, das Outlook erst nach einem Neuanlegen des Mailprofils sich mit der Cloud verbunden hat. Mit der Mailfluß Cloud-Onpremise u OnPremise-Cloud hat aber funktioniert.

    Wo würdest Du die Vorteile eines Migrationstools sehen ?

    Ich glaube, da muß ich noch etwas für meinen Wissenstand machen.

    lg und besten Dank für deine Antwort,

    Reinhold

    luni, 11 mai 2020 18:36
  • Moin,

    der Grund für ein Migrationstool ist die Koexistenz. Ansonsten wird es mit dem Mailflow etwas komplexer und die Benutzer haben ggf. Probleme beim Zugriff über die Systemgrenzen. Zum Beispiel wenn ein Cloudbenutzer auf den Kalender eines Onpremise-Nutzers zugreifen möchte.

    Der weitere Vorteil ist, das die einiges an Arbeitabnehmen und es Einfacher machen.

    Die Alternative währe eine Big-Bang Migration, das bedeutet alles an einem Wochenende. Wichtig ist aber auch dabei den Mailfluss im Auge zubehalten, damit nix verloren geht. Ich hab die Stolperfallen für eine Office365 nach Office365 Migration mal beschrieben, manche treffen auch auf Ihr Szenario zu: https://www.infrastrukturhelden.de/microsoft-infrastruktur/office-365/vorbereiten-des-mail-fluss-fuer-die-office-365-migration/


    Viele Grüße / Kind regards
    Fabian Niesen
    ---
    Infrastrukturhelden.de (German) - Infrastructureheroes.org (English)
    LinkedIn - Xing - Twitter
    #Iwork4Dell - Opinions and Posts are my own
    My post are provided as they are. Usage is on your own risk.
    Please consider to mark this entry as helpful or solution if it helps or solved your issue.

    marți, 12 mai 2020 07:10
  • Hallo und schönen Abend,

    danke für die Antwort und vor allem für den interessanten Link. Der gesamte Blog ist hochinteressant.

    Ich habe mir heute mal das Migrationstools von CodeTwo angesehen.

    Herzliche Grüße aus Österreich

    Reinhold

    marți, 12 mai 2020 20:31