Migration Fileserver Windows Server 2008 R2 auf 2019 mit RDS-Profilen
Hallo zusammen,
ich habe aktuell ein Projekt in der Arbeit den bisherigen Fileserver (leider noch Windows Server 2008 R2) auf Windows Server 2019 zu migrieren.
Folgenden Fall haben wir in unserer Umgebung:
Auf dem Fileserver befinden sich die RDS-Profile für unsere Terminalserver Farm. Leider können wir aufgrund einer alten Software nicht auf VHD Profile umsteigen. Zusätzlich befindet sich noch das "Home"-Laufwerk aller Mitarbeiter mit eigenen Daten auf dem Fileserver.
Ich habe mir bereits einige Gedanken gemacht wie ich am besten die Migration durchführen kann, aber wie würdet ihr hier vorgehen? Mein Problem ist tatsächlich wie ich am besten die RDS-Profile umziehe und ob ich dann tatsächlich im AD bei jedem User den RDS-Profil und -Home Pfad abändern muss oder evtl. mit einem Alias arbeiten kann.
Vielen Dank schonmal für eure Hilfe.
Viele Grüße
ich habe aktuell ein Projekt in der Arbeit den bisherigen Fileserver (leider noch Windows Server 2008 R2) auf Windows Server 2019 zu migrieren.
Folgenden Fall haben wir in unserer Umgebung:
Auf dem Fileserver befinden sich die RDS-Profile für unsere Terminalserver Farm. Leider können wir aufgrund einer alten Software nicht auf VHD Profile umsteigen. Zusätzlich befindet sich noch das "Home"-Laufwerk aller Mitarbeiter mit eigenen Daten auf dem Fileserver.
Ich habe mir bereits einige Gedanken gemacht wie ich am besten die Migration durchführen kann, aber wie würdet ihr hier vorgehen? Mein Problem ist tatsächlich wie ich am besten die RDS-Profile umziehe und ob ich dann tatsächlich im AD bei jedem User den RDS-Profil und -Home Pfad abändern muss oder evtl. mit einem Alias arbeiten kann.
Vielen Dank schonmal für eure Hilfe.
Viele Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4103135303
Url: https://administrator.de/contentid/4103135303
Ausgedruckt am: 25.11.2024 um 03:11 Uhr
16 Kommentare
Neuester Kommentar
@SithAns:
Hallo.
Ich hätte keine Bedenken, ein Inplace-Upgrade durchzuführen. Weil Startpunkt aber W2K8R2 ist, würde ich einen Zwischenschritt mit 2012R2 machen, dann W2K19. Vor jedem Schritt natürlich ein Sonderbackup anfertigen.
Soll das System auch auf andere Hardware umziehen? Windows-Server-Sicherung (Bordmittel) anfertigen (auf eine riesige USB-Platte, zum Beispiel). Windows-Server-Backup ist bare-metal-recovery-fähig, kann danach also auch auf anderer Hardware wieder eingespielt werden. Neue Maschine von W2K19-USB-Setup-Stick booten, "Reparaturoptionen" auswählen, als Medium die zuvor angefertigte Backup-USB-Platte angeben, falls nötig noch Treiber für die neue Hardware zufüttern.
Bei der Methode ist es vollkommen wurst, was auf dem Fileserver drauf ist.
Außer bei Domain-Controllern und Exchange mache ich keine Migrationen mehr. Und nein, Inplace-Upgrades sind nicht "unsauber", das funktioniert mittlerweile (eigentlich schon seit Vista/2008) allergrößtenteils einwandfrei. Vielleicht schadet es aber vorher nicht, das zu aktualisierende System etwas "aufzuräumen".
Achja, wegen der zu erwartenden Downtime ist das natürlich ein Wochenend-Job .
Viele Grüße
von
departure69
Hallo.
Ich hätte keine Bedenken, ein Inplace-Upgrade durchzuführen. Weil Startpunkt aber W2K8R2 ist, würde ich einen Zwischenschritt mit 2012R2 machen, dann W2K19. Vor jedem Schritt natürlich ein Sonderbackup anfertigen.
Soll das System auch auf andere Hardware umziehen? Windows-Server-Sicherung (Bordmittel) anfertigen (auf eine riesige USB-Platte, zum Beispiel). Windows-Server-Backup ist bare-metal-recovery-fähig, kann danach also auch auf anderer Hardware wieder eingespielt werden. Neue Maschine von W2K19-USB-Setup-Stick booten, "Reparaturoptionen" auswählen, als Medium die zuvor angefertigte Backup-USB-Platte angeben, falls nötig noch Treiber für die neue Hardware zufüttern.
Bei der Methode ist es vollkommen wurst, was auf dem Fileserver drauf ist.
Außer bei Domain-Controllern und Exchange mache ich keine Migrationen mehr. Und nein, Inplace-Upgrades sind nicht "unsauber", das funktioniert mittlerweile (eigentlich schon seit Vista/2008) allergrößtenteils einwandfrei. Vielleicht schadet es aber vorher nicht, das zu aktualisierende System etwas "aufzuräumen".
Achja, wegen der zu erwartenden Downtime ist das natürlich ein Wochenend-Job .
Viele Grüße
von
departure69
Moin,
Eigentlich simpel:
limitierender Faktor ist nur der Kopierprozess, ansonsten alles binnen 5-10 Minuten erledigt
Ich gehe davon aus, dass der alte Server ausschließlich als FileServer dient. Laufen dort noch andere Dienste kann man mitunter identisch vorgehen…
Gruß
em-pie
Eigentlich simpel:
- Neuen Server aufsetzen
- per Robocopy (mit den passenden Parametern) alles rüber schaufeln
- vom Quellserver die Freigaben anschauen
- Freigaben am Neuen Server 1:1 anlegen
- alten Server umbenennen + herunterfahren
- Neuem Server den Namen des alten Servers geben.
limitierender Faktor ist nur der Kopierprozess, ansonsten alles binnen 5-10 Minuten erledigt
Ich gehe davon aus, dass der alte Server ausschließlich als FileServer dient. Laufen dort noch andere Dienste kann man mitunter identisch vorgehen…
Gruß
em-pie
Hi
Oder mach es gleich für die Zukunft richtig und nutze anstatt eines neuen oder alten Hostnames einfach DFS-Namespace.
Egal ob du jetzt TS Roaming Profiles oder FSLogix einsetzt.
Bei DFS-Namespace ist es dann auch egal welcher Hostname dahinter steht.
Einfach Files mittels Robocopy umziehen und im DFS-Namespace das Target umhängen.
Musst halt einmal jetzt die Profilepfade am Benutzer anpassen oder GPO je nach dem was gesetzt ist und bist nicht mehr vom Hostnamen abhängig.
Mit freundlichen Grüßen
Nemesis
Oder mach es gleich für die Zukunft richtig und nutze anstatt eines neuen oder alten Hostnames einfach DFS-Namespace.
Egal ob du jetzt TS Roaming Profiles oder FSLogix einsetzt.
Bei DFS-Namespace ist es dann auch egal welcher Hostname dahinter steht.
Einfach Files mittels Robocopy umziehen und im DFS-Namespace das Target umhängen.
Musst halt einmal jetzt die Profilepfade am Benutzer anpassen oder GPO je nach dem was gesetzt ist und bist nicht mehr vom Hostnamen abhängig.
Mit freundlichen Grüßen
Nemesis
Moin SithAns:
und wenn du nun noch bestätigst, dass die Daten selbst nicht auf C: sondern auf einer anderen Platte/VHDX/VHD liegen, dann ist die Sache total easy. Sprich, mit etwas Vorbereitung in weniger als einer Stunde erledigt. 😁
Gruss Alex
@MysticFoxDE der Server ist bereits virtualisiert
und wenn du nun noch bestätigst, dass die Daten selbst nicht auf C: sondern auf einer anderen Platte/VHDX/VHD liegen, dann ist die Sache total easy. Sprich, mit etwas Vorbereitung in weniger als einer Stunde erledigt. 😁
Gruss Alex
@MysticFoxDE Ja das sind alles eigene virtuelle Festplatten. Diesen Gedanken hatte ich auch bereits die virtuellen Platten einfach vom alten Fileserver abhängen und an dem neuen wieder einbinden.
Aber da habe ich mir die Frage gestellt, ob das wirklich so einfach geht wie ich es mir vorstelle und ob es zu Problemen kommen könnte, da diese Platten damals auf NTFS mit Server 2008 R2 erstellt wurden und ich diese dann an einen Server 2019 anhängen würde.
Oder geht das tatsächlich einfach bedenkenlos?
Aber da habe ich mir die Frage gestellt, ob das wirklich so einfach geht wie ich es mir vorstelle und ob es zu Problemen kommen könnte, da diese Platten damals auf NTFS mit Server 2008 R2 erstellt wurden und ich diese dann an einen Server 2019 anhängen würde.
Oder geht das tatsächlich einfach bedenkenlos?
Easy going
- Wie hier beschrieben vom alten Server die Freigaben exportieren (Registry): https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking ...
- VHD(X) umhängen
- VHD(X) am neuen Server einhängen (und den selben Buchstaben vergeben, wie am alten Server)
- RegKey importieren
Fertig
Hinweis: Beim importieren des Keys werden ggf. bestehende Freigaben überschrieben.
NTFS ist auch heute noch ein Standard in der Windows-Welt, auch wenn ReFS gerade im kommen ist (in Teilen jedenfalls)
Moin SithAns,
eventuell muss du am 2019er noch SMBv1 reaktivieren, damit alte Rechner auch auf dessen Freigaben kommen,
ansonsten kann ich mich em-pie nur anschliessen. Sprich, absolut easy going.
Gruss Alex
@MysticFoxDE Ja das sind alles eigene virtuelle Festplatten. Diesen Gedanken hatte ich auch bereits die virtuellen Platten einfach vom alten Fileserver abhängen und an dem neuen wieder einbinden.
Aber da habe ich mir die Frage gestellt, ob das wirklich so einfach geht wie ich es mir vorstelle und ob es zu Problemen kommen könnte, da diese Platten damals auf NTFS mit Server 2008 R2 erstellt wurden und ich diese dann an einen Server 2019 anhängen würde.
Oder geht das tatsächlich einfach bedenkenlos?
Aber da habe ich mir die Frage gestellt, ob das wirklich so einfach geht wie ich es mir vorstelle und ob es zu Problemen kommen könnte, da diese Platten damals auf NTFS mit Server 2008 R2 erstellt wurden und ich diese dann an einen Server 2019 anhängen würde.
Oder geht das tatsächlich einfach bedenkenlos?
eventuell muss du am 2019er noch SMBv1 reaktivieren, damit alte Rechner auch auf dessen Freigaben kommen,
ansonsten kann ich mich em-pie nur anschliessen. Sprich, absolut easy going.
Gruss Alex
"magische" Grenze...
durchschnittlich kann bedeuten: 1,0TB, 1,6TB und 2,2TB oder aber auch 1,5TB, 1,6TB und 1,7TB
Bei MBR ist bei 2TB Ende...
https://www.diskpart.com/gpt-mbr/mbr-vs-gpt-1004.html
https://www.freecodecamp.org/news/mbr-vs-gpt-whats-the-difference-betwee ...
durchschnittlich kann bedeuten: 1,0TB, 1,6TB und 2,2TB oder aber auch 1,5TB, 1,6TB und 1,7TB
Bei MBR ist bei 2TB Ende...
https://www.diskpart.com/gpt-mbr/mbr-vs-gpt-1004.html
https://www.freecodecamp.org/news/mbr-vs-gpt-whats-the-difference-betwee ...
Moin SithAns,
😬, na ja, bis 2TB ist da nicht wirklich noch viel Luft dazwischen.
Also ja, ich würde die Daten bei der Gelegenheit auch gleich auf GPT konvertieren.
Geht mit dem folgenden Tool übrigens ohne Daten verschieben zu müssen.
Bitte sicherheitshalber aber auf jeden Fall vorher die VHD(X) sichern!
https://www.easeus.de/partitionieren-tipps/mbr-zu-gpt-konvertieren.html
Gruss Alex
es handelt sich um insgesamt drei Festplatten mit durchschnittlich ca. 1,6TB.
😬, na ja, bis 2TB ist da nicht wirklich noch viel Luft dazwischen.
Also ja, ich würde die Daten bei der Gelegenheit auch gleich auf GPT konvertieren.
Geht mit dem folgenden Tool übrigens ohne Daten verschieben zu müssen.
Bitte sicherheitshalber aber auf jeden Fall vorher die VHD(X) sichern!
https://www.easeus.de/partitionieren-tipps/mbr-zu-gpt-konvertieren.html
Gruss Alex