Server 2008 R2 In-Place Upgrade auf 2019

[TheChaosMaxi]

Wir haben in diversen Außenstellen noch Windows Server 2008 R2 am laufen. Diese sollen jetzt nach und nach auf Server 2019 geupgradet werden.

Nun stellt sich die Frage ob ich "einfach" ein In-Place Upgrade machen kann.

Folgende Dienste laufen:

• AD
• DHCP
• DNS
• Druckdienst
• Dateidienst(Div. Freigaben & Berechtigungseinstellungen)

Laut Microsoft sollte es kein Problem sein, man muss halt den zwischenschritt zu 2012 R2 machen.

Hat das so schon jemand durchgeführt? Neuinstallation wäre schöner, ist aber so erstmal nicht gewünscht.

 

[wern001]

Gehen tut das solange keine abgefahrene Software drauf ist.
Aber ein image vom Server das man schnell zurückspielen kann würde ich das nicht machen.

 

[l007v16]

Ich arbeite bei einem großen Dienstleister und wir haben ca. 500 solcher 2008er Server In-Place auf 2012 R2 und auch teilweise weiter auf 2016 geupgradet. Jedoch waren die meisten davon "nur" Applikationsserver und es liefen keine kritischen Dienste wie AD auf den Servern Ich kann aber sagen, dass mehrere Server durch das In-Place Upgrade kaputt gegangen sind und neu aufgesetzt werden mussten.

Ich empfehle ganz klar eine Migration auf einen frisch installierten 2019er Server. Bei den In-Place Upgrades wird zu viel alter Ballast mitgeschleppt, der den Server im Anschluss kaputt machen kann.

EDIT:

Was mir noch einfällt. Laufen die Server als VM oder auf physischer Hardware? Wenn ich das richtig im Kopf habe kann es da zu Inkompatibilitäten kommen wenn du auf "2008er" Hardware das 2019er Server OS laufen lässt. Stichwort Treiber etc.

 

[cloudman]

Die Frage ist ob das eine gute Idee ist. Siehe @l007v16
Kann gut gehen oder auch nicht 🙂

Wenn die Hardware auch über 10 Jahre alt ist wäre es eventuell an der Zeit sie zu ersetzen.
Der Zeitaufwand mit den notwendigen Update auf 2012 als Zwischenschritt sollte auch nicht vergessen werden.

Klingt sehr nach Chef will Geld /Zeit sparen ohne sich mit Fakten zu belasten 🙂

 

[t-6]

Frisch parallel neu aufsetzen. Da sind ja jetzt keine Dienste oder abgefuckten Programm bei, bei denen man auf Biegen und Brechen ein Upgrade machen will weil man keine Lust auf Neueinstellungen hat

AD: Zweiter DC
DNS: Dito; zweiter DC
DHCP: Kann mit auf den zweiten DC

Druckdienst: Separate VM
Dateidienst: Separate VM

Migration von Daten des Dateidienstes erfolgt über bspw. Robocopy (oder diesem Windows File-Migration Dienst) und zum Stichtag werden die alten Shares ausgeschaltet & die Netzlaufwerke per GPO auf den neuen Server umgebogen.
Bei der Gelegenheit kann man auch gleich mit DFS-N anfangen, dann muss man noch nicht mal Netzlaufwerke oder Verknüpfungen ändern sondern - künftig - nur den das DFS-N Ziel.

Und bei der Gelegenheit wäre neue Hardware ohnehin angezeigt. 2008R2 deutet ja doch schon auf älteres Stahl hin.

Neuinstallation wäre schöner, ist aber so erstmal nicht gewünscht.

Warum nicht?
Ihr habt hier alte Zöpfe die abgeschnitten werden müssen. Und wenn beim Upgrade etwas schiefgeht, wird es bei einer Blech- statt VM-Installation ungemein schwieriger wieder zurückzurollen.

 

[Innensechskant]

Migration von Daten des Dateidienstes

Kann man über das neue Windows Admin Center machen und da den Storage Migration Service nutzen. Dann hat man auch alle Berechtigungen und Freigaben nach wie vor...


Ein Inplace-Upgrade von einem AD-Server würde ich lassen.
Ich würde, wie @t-6 schrieb, einen zweiten AD aufsetzen, AD, DNS und DHCP rüber schieben (geht bei AD und DNS ja quasi von alleine) und DHCP per Export/Import, danach die FSMO-Rollen auf den neuen AD schieben.

Danach den Fileserver, mit dem neuen Windows Admin Center und dem Storage Migration Service auf einen neuen Übertragen, dort kann man dann, wenn man möchte, auch noch den Druckerserver installieren.

Wenn alles "drüben" ist und wie gewünscht funktioniert, den alten DC testweise herunterfahren, wenn dann alles noch klappt, den alten DC demoten.

 

[Ichthys]

Ich rate auch von einer Aktualisierung 2008 R2 -> 2019 ab. Die Wahrscheinlichkeit, dass dabei Zeit und Geld gespart wird, ist gering. Am Ende machst Du höchstwahrscheinlich eh beides.

So, wie oben beschrieben, neuen DC aufsetzen, da alles übertragen und alten abschalten.

 

[TheChaosMaxi]

Was mir noch einfällt. Laufen die Server als VM oder auf physischer Hardware? Wenn ich das richtig im Kopf habe kann es da zu Inkompatibilitäten kommen wenn du auf "2008er" Hardware das 2019er Server OS laufen lässt. Stichwort Treiber etc.

Ist alles schon Virtuell.

AD: Zweiter DC
DNS: Dito; zweiter DC
DHCP: Kann mit auf den zweiten DC

Druckdienst: Separate VM
Dateidienst: Separate VM

Migration von Daten des Dateidienstes erfolgt über bspw. Robocopy (oder diesem Windows File-Migration Dienst) ...

Warum nicht?
Ihr habt hier alte Zöpfe die abgeschnitten werden müssen. Und wenn beim Upgrade etwas schiefgeht, wird es bei einer Blech- statt VM-Installation ungemein schwieriger wieder zurückzurollen.

In den Ausstenstellen sind nicht wirklich viele Daten und Zugriffe, daher liegt alles auf einer VM und natürlich Lizenzkosten.

Okay, klingt alles so als ob ich mir ne menge Arbeit und Stress spare, wenn ich tatsächlich eine neue VM erstelle und alles frisch installiere.

Ich bin gerade noch in der Ideen/Planungs Phase. Daher möchte ich alle möglichleiten erstmal betrachten.

 

[t-6]

Angesichts dass Windows Server Standard 2 Virtualisierungsrechte gibt, wäre die Aufteilung auf 2 VMs optimal.

VM #1
dc
dns
dhcp

VM #2
File
Print


DFS-N könnte auch noch auf den DC gestülpt werden.

Im Idealfall habt Ihr natürlich zwei DCs im selben Standort auf unterschiedlicher Hardware (unabhängig davon ob das dann virtualisiert ist oder nicht).

 

[Blubmann1337]

Wie andere bereits sagen. Würde einen 2019er DC parallel danebenstellen, dann den alten herunterstufen und eine File-Druckserver draus machen. Da ist ein In-Place-Upgrade auch weniger risikoreich. Und ja ich hab es schon geschafft einen DC zu schrotten, durch ein Inplaceupgrade. War zum Glück in einer Testumgebung, aber Restore ist bei einem DC auch nicht mal so easy wie bei anderen Maschinen.