Migration von SBS 2011 nach Server 2019, Entra Cloud Sync, ohne lokalen Exchange
Hallo,
ich würde euch um eure Kommentare zu meinem Vorhaben bitten.
Es geht um eine Migration eines SBS2011 nach Server 2019.
Der Exchange Server wurde bereits nach Microsoft 365 migriert und läuft nun schon länger stabil im hybrid Modus.
Auf dem alten SBS lief bis jetzt das AzureAD Connect Sync um das AD mit der Cloud zu synchronisieren. Diese wurde jedoch nun von Microsoft eingestellt und ich darf auf das neue Microsoft Entra Cloud Sync updaten. Dies funktioniert jedoch nicht mehr auf dem alten SBS11.
Der neue Server 2019 läuft bereits, ist in die Domäne eingebunden, ist zusätzlicher DC (global catalog, DFSR) und DNS-Server.
Nun die nächsten Schritte in folgender Reihenfolge:
Bin mir ein wenig unsicher was die Reihenfolge angeht, ob das so passt.
Bezüglich FSMO Rollen übertragen, welche Methode würdet ihr bevorzugen?
Vielen Dank
ich würde euch um eure Kommentare zu meinem Vorhaben bitten.
Es geht um eine Migration eines SBS2011 nach Server 2019.
Der Exchange Server wurde bereits nach Microsoft 365 migriert und läuft nun schon länger stabil im hybrid Modus.
Auf dem alten SBS lief bis jetzt das AzureAD Connect Sync um das AD mit der Cloud zu synchronisieren. Diese wurde jedoch nun von Microsoft eingestellt und ich darf auf das neue Microsoft Entra Cloud Sync updaten. Dies funktioniert jedoch nicht mehr auf dem alten SBS11.
Der neue Server 2019 läuft bereits, ist in die Domäne eingebunden, ist zusätzlicher DC (global catalog, DFSR) und DNS-Server.
Nun die nächsten Schritte in folgender Reihenfolge:
- FSMO Rollen übertragen an neuen DC (dcdiag passt soweit)
- Domänenfunktionsebene heraufstufen von 2008 R2 auf 2016
- Exchange Management Rolle auf neuem Server installieren, für die Verwaltung der Exchange Attribute im lokalen AD
- Microsoft Entra Cloud Sync auf neuem Server einrichten
- SBS2011 abschalten
Bin mir ein wenig unsicher was die Reihenfolge angeht, ob das so passt.
Bezüglich FSMO Rollen übertragen, welche Methode würdet ihr bevorzugen?
- Mit NDTSUTIL
- PowerShell: Move-ADDirectoryServerOperationMasterRole
- Manuell mit GUI siehe
Vielen Dank
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4316012217
Url: https://administrator.de/contentid/4316012217
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
8 Kommentare
Neuester Kommentar
Moin..
Gruß,
Avoton
Frank
Frank
Zitat von @Avoton:
Moin,
Warum sollte die Managementrolle nicht auf den DC dürfen?
Ist doch letztlich nur eine Cmdlet Sammlung...
weil auf den DC nix anderes gehört, was später stören kann!Moin,
Warum sollte die Managementrolle nicht auf den DC dürfen?
Ist doch letztlich nur eine Cmdlet Sammlung...
Gruß,
Avoton
Frank
weil auf den DC nix anderes gehört, was später stören kann!
Grundsätzlich hast du natürlich Recht, dass ein DC ein DC ist und nix anderes.Da es sich hier aber um Management Tools handelt, sehe ich persönlich da kein Problem. Was sollen denn Kunden machen, die nur einen Essentials Server haben?
muss ich dann dennoch irgend wie das AD mit der Exchange Schemaerweiterung "aktualisieren"
Das merkt das Exchange Setup, ob da was getan werden muss.Gruß,
Avoton
Und wieder der alte Spruch:
Ein DC ist ein DC und NUR ein DC.
Daran sollte sich niemand anmelden, auch nicht um irgendwas zu managen, am besten gleich als Core Version installieren, und in der VM den dynamischen Arbeitsspeicher aktivieren, dann braucht er so gut wie keinen RAM.
Gemanaged wird er dann über RSAT Tools von einem anderen Rechner aus.
Ein DC ist ein DC und NUR ein DC.
Daran sollte sich niemand anmelden, auch nicht um irgendwas zu managen, am besten gleich als Core Version installieren, und in der VM den dynamischen Arbeitsspeicher aktivieren, dann braucht er so gut wie keinen RAM.
Gemanaged wird er dann über RSAT Tools von einem anderen Rechner aus.