4
Windows Server Inplace Upgrade 2012R2 zu 2019
Guten Tag 
ich stehe vor einer Aufgabe, die vielleicht dem einen oder anderen bekannt ist. Vielleicht kann jemand Erfahrung teilen und mir vielleicht sagen ob einem Denkfehler unterlegen bin.
Anforderung ist : inplace upgrade von mehreren Windows Server 2012R2 auf Windows Server 2019. Die Server laufen alle in einer VMWare Umgebung.
einen der Server habe ich in eine Testumgebung gezogen und nun stürzt der Server IMMER bei 52% des Inplace Upgrades ab. Ich habe mir zwar die logfiles angeschaut, diese liefern allerdings keine Ergebnisse aus denen sich handfeste Lösungsvorschläge ergeben würden. Weiß jemand WAS genau bei Prozentangabe 52% Thema ist im Setup Prozess ?
Hab mich jetzt schon gefragt ob das Inplace Upgrade nicht in der Lage ist die system-reservierte Partition Upgrade bedingt "größer zu schieben", stellte dann aber fest das andere mit erfolgreichen Inplace-Upgrade installierten Servern immernoch über die bekannten 350MB system-reserviert verfügen. Jedoch waren hier vorher in der Partitionstabelle keine Recover Partition vorhanden und später schon. Kann es vielleicht daran liegen ? Übersehe ich etwas oder denke einfach in eine völlig falsche Richtung ?
Ja, "wegmigrieren" wäre eigentlich sauberer. Es geht momentan aber auch darum zu entscheiden welchen Server man per inlace upgrade abfrühstücken kann und welcher manuell neu gemacht werden muss.
ich stehe vor einer Aufgabe, die vielleicht dem einen oder anderen bekannt ist. Vielleicht kann jemand Erfahrung teilen und mir vielleicht sagen ob einem Denkfehler unterlegen bin.
Anforderung ist : inplace upgrade von mehreren Windows Server 2012R2 auf Windows Server 2019. Die Server laufen alle in einer VMWare Umgebung.
einen der Server habe ich in eine Testumgebung gezogen und nun stürzt der Server IMMER bei 52% des Inplace Upgrades ab. Ich habe mir zwar die logfiles angeschaut, diese liefern allerdings keine Ergebnisse aus denen sich handfeste Lösungsvorschläge ergeben würden. Weiß jemand WAS genau bei Prozentangabe 52% Thema ist im Setup Prozess ?
Hab mich jetzt schon gefragt ob das Inplace Upgrade nicht in der Lage ist die system-reservierte Partition Upgrade bedingt "größer zu schieben", stellte dann aber fest das andere mit erfolgreichen Inplace-Upgrade installierten Servern immernoch über die bekannten 350MB system-reserviert verfügen. Jedoch waren hier vorher in der Partitionstabelle keine Recover Partition vorhanden und später schon. Kann es vielleicht daran liegen ? Übersehe ich etwas oder denke einfach in eine völlig falsche Richtung ?
Ja, "wegmigrieren" wäre eigentlich sauberer. Es geht momentan aber auch darum zu entscheiden welchen Server man per inlace upgrade abfrühstücken kann und welcher manuell neu gemacht werden muss.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1247914176
Url: https://administrator.de/contentid/1247914176
Ausgedruckt am: 13.11.2024 um 11:11 Uhr
4 Kommentare
Neuester Kommentar
Moin
Um was für Server und welche Anzahl handelt es sich. Bei 4 oder 5 Server würde ich mir die Mühe nicht machen das Inplace-Upgrade vorher zu testen, sondern es gleich neu machen. Sind wir hier bei 500 Server, rechnet sich vielleicht der Aufwand der Testung aber es bliebe immernoch die Unsicherheit ob alles richtig funktioniert. Du hast ja jetzt schon festegesllt, dass es nicht saubr durchläuft. 52% ist offenbar noch korrigierbar, aber was machst du wenn er bei 89 % abbricht und kein Rollback mehr möglich ist. Das ganze kann dir auch nach deinen Tests passieren, weil vielleicht mittlerweile eine einzige Virensignatur dazwischen funkt. Da haste dann mit Restore und einer anschließenden sauberen Migration, genau das Gegenteil erreicht.
Wenn DB oder andere Programme im Spiel sind, musst du auch bedenken/beachten, dass einige SW-Anbieter keine Gewährleistung mehr geben, wenn ein Inplace-Upgrade durchgeführt wurde. Da steht dann drin, dass die SW auf 2016 installeirt wurde und eine Migration zu 2019 nur durch deren Personal vorgenommen werden darf, ansonsten entfällt die Gewähr und du musst extra zahlen für Problembehandlung. Das hatten wir selbst mal bei einer Firma wo wir SW vertrieben haben in den Vertragsbedgungen stehen. bei einem Inplace-Upgrade wird von 2016 auf 2019 migirert ohne, dass deren Mitarbeiter dort involviert sind. Da könnten im Fehlerfall einige kosten auf euch zukommen. Selbst wenn die SW an sich funktioniert, wenn es dann innerhalb der SW zu fehlern kommt, wird es nervig und heikel.
Gruß
Doskias
Zitat von @chevron-9:
ich stehe vor einer Aufgabe, die vielleicht dem einen oder anderen bekannt ist. Vielleicht kann jemand Erfahrung teilen und mir vielleicht sagen ob einem Denkfehler unterlegen bin.
Die Aufgabe ist denkbar einfach. Das Thema Inplace-Upgrade wurde kürzlich hier erst ausführlich erläutertich stehe vor einer Aufgabe, die vielleicht dem einen oder anderen bekannt ist. Vielleicht kann jemand Erfahrung teilen und mir vielleicht sagen ob einem Denkfehler unterlegen bin.
Anforderung ist : inplace upgrade von mehreren Windows Server 2012R2 auf Windows Server 2019. Die Server laufen alle in einer VMWare Umgebung.
einen der Server habe ich in eine Testumgebung gezogen und nun stürzt der Server IMMER bei 52% des Inplace Upgrades ab. Ich habe mir zwar die logfiles angeschaut, diese liefern allerdings keine Ergebnisse aus denen sich handfeste Lösungsvorschläge ergeben würden. Weiß jemand WAS genau bei Prozentangabe 52% Thema ist im Setup Prozess?
Ich denke was genau bei 52 % passiert wird entweder in den Logs stehen, oder aber MS will es nicht bekannt geben.einen der Server habe ich in eine Testumgebung gezogen und nun stürzt der Server IMMER bei 52% des Inplace Upgrades ab. Ich habe mir zwar die logfiles angeschaut, diese liefern allerdings keine Ergebnisse aus denen sich handfeste Lösungsvorschläge ergeben würden. Weiß jemand WAS genau bei Prozentangabe 52% Thema ist im Setup Prozess?
Hab mich jetzt schon gefragt ob das Inplace Upgrade nicht in der Lage ist die system-reservierte Partition Upgrade bedingt "größer zu schieben", stellte dann aber fest das andere mit erfolgreichen Inplace-Upgrade installierten Servern immernoch über die bekannten 350MB system-reserviert verfügen. Jedoch waren hier vorher in der Partitionstabelle keine Recover Partition vorhanden und später schon. Kann es vielleicht daran liegen ? Übersehe ich etwas oder denke einfach in eine völlig falsche Richtung ?
Dazu müsste man Wissen, was die Fehlermeldung in den Logs genau aussagt. Es wäre aber durchaus denkbar.Ja, "wegmigrieren" wäre eigentlich sauberer. Es geht momentan aber auch darum zu entscheiden welchen Server man per inlace upgrade abfrühstücken kann und welcher manuell neu gemacht werden muss.
Warum macht ihr die Server nicht neu? Der Aufwand ist doch relativ geringt, von dem einen oder anderem Programm mal abgesehen. Wenn es "richtig" programmiert und installiert wurde, dann mus da maximal eine Ip/Name angepasst werden und das geht per GPO/Skript recht gut. Anonsten sagst du ja selbst schon, dass wegmigrieren die saubere Methode ist. Was nützen dir 2 Stunden Zeitersparnis am Server, wenn du hinterher 4 für die Problembehebung benötigt?Um was für Server und welche Anzahl handelt es sich. Bei 4 oder 5 Server würde ich mir die Mühe nicht machen das Inplace-Upgrade vorher zu testen, sondern es gleich neu machen. Sind wir hier bei 500 Server, rechnet sich vielleicht der Aufwand der Testung aber es bliebe immernoch die Unsicherheit ob alles richtig funktioniert. Du hast ja jetzt schon festegesllt, dass es nicht saubr durchläuft. 52% ist offenbar noch korrigierbar, aber was machst du wenn er bei 89 % abbricht und kein Rollback mehr möglich ist. Das ganze kann dir auch nach deinen Tests passieren, weil vielleicht mittlerweile eine einzige Virensignatur dazwischen funkt. Da haste dann mit Restore und einer anschließenden sauberen Migration, genau das Gegenteil erreicht.
Wenn DB oder andere Programme im Spiel sind, musst du auch bedenken/beachten, dass einige SW-Anbieter keine Gewährleistung mehr geben, wenn ein Inplace-Upgrade durchgeführt wurde. Da steht dann drin, dass die SW auf 2016 installeirt wurde und eine Migration zu 2019 nur durch deren Personal vorgenommen werden darf, ansonsten entfällt die Gewähr und du musst extra zahlen für Problembehandlung. Das hatten wir selbst mal bei einer Firma wo wir SW vertrieben haben in den Vertragsbedgungen stehen. bei einem Inplace-Upgrade wird von 2016 auf 2019 migirert ohne, dass deren Mitarbeiter dort involviert sind. Da könnten im Fehlerfall einige kosten auf euch zukommen. Selbst wenn die SW an sich funktioniert, wenn es dann innerhalb der SW zu fehlern kommt, wird es nervig und heikel.
Gruß
Doskias
@Doskias:
Hallo.
Genau dies ist bei uns nicht selten, sondern die Regel. (Gefühlt) eintausend komplizierte Dinge konfiguriert, teilweise sogar direkt durch den Softwarehersteller (sonst wird u. U. - auch bezahlter - Support abgelehnt), nichts oder zuwenig vernünftig dokumentiert. Um bspw. unseren Applikationsserver ganz neu einzurichten, bräuchte ich (vor allem, wenn ich Softwarehersteller dazu bräuchte) sicherlich einen ganzen Monat, das geht dann nämlich nur allmählich Zug um Zug. Gerade dann versuch' ich doch lieber erstmal ein Inplace-Upgrade.
Wobei ich bislang mit Inplace-Upgrades, auch von Servern, die richtig viele und wichtige Dinge beherbergen, gute Erfahrungen habe. Ich hab' hier (virtuelle) Kisten, die schon 3 Inplace-Upgrades (z. B. 2K8R2-> 2K12 -> 2K16 -> 2K19) erfolgreich hinter sich gebracht haben.
Ich hab' übrigens noch kein Inplace-Upgrade gehabt, bei dem ich bei Bedarf kein Rollback hätte vornehmen können.
Viele Grüße
von
departure69
Hallo.
... von dem einen oder anderem Programm mal abgesehen ...
Genau dies ist bei uns nicht selten, sondern die Regel. (Gefühlt) eintausend komplizierte Dinge konfiguriert, teilweise sogar direkt durch den Softwarehersteller (sonst wird u. U. - auch bezahlter - Support abgelehnt), nichts oder zuwenig vernünftig dokumentiert. Um bspw. unseren Applikationsserver ganz neu einzurichten, bräuchte ich (vor allem, wenn ich Softwarehersteller dazu bräuchte) sicherlich einen ganzen Monat, das geht dann nämlich nur allmählich Zug um Zug. Gerade dann versuch' ich doch lieber erstmal ein Inplace-Upgrade.
Wobei ich bislang mit Inplace-Upgrades, auch von Servern, die richtig viele und wichtige Dinge beherbergen, gute Erfahrungen habe. Ich hab' hier (virtuelle) Kisten, die schon 3 Inplace-Upgrades (z. B. 2K8R2-> 2K12 -> 2K16 -> 2K19) erfolgreich hinter sich gebracht haben.
Ich hab' übrigens noch kein Inplace-Upgrade gehabt, bei dem ich bei Bedarf kein Rollback hätte vornehmen können.
Viele Grüße
von
departure69
Moin,
nicht nur bei euch
Ach übrigens: Die gleiche Diskussion haben wir grade hier:
Server migration auf 2019
MS selbst empfiehlt übrigens Inplace-Upgrades nicht. Und das hier etwas schieg geht sehen wir ja daran, dass er über die 52 Prozent nicht weiter raus kommt.
Gruß
Doskias
nicht nur bei euch
(Gefühlt) eintausend komplizierte Dinge konfiguriert, teilweise sogar direkt durch den Softwarehersteller (sonst wird u. U. - auch bezahlter - Support abgelehnt), nichts oder zuwenig vernünftig dokumentiert.
Dann musst du aber prüfen ob dein(e) SW-Herrsteller noch Support gewähren bei einem Inplace-Upgrade. Wie ich oben beschrieben habe, gibt es durchaus Verträge die dies ausschließen. Wenn du Support für 2012 hast, dann ist nach einem Inplace-Upgrade kein Support mehr gegeben.Um bspw. unseren Applikationsserver ganz neu einzurichten, bräuchte ich (vor allem, wenn ich Softwarehersteller dazu bräuchte) sicherlich einen ganzen Monat, das geht dann nämlich nur allmählich Zug um Zug.
Klar dauert es länger als ein Inplace-Upgrade. Das hab ich nie bestritten.Gerade dann versuch' ich doch lieber erstmal ein Inplace-Upgrade.
Der schnelle/einfache weg ist nicht zwingend der Beste:Wobei ich bislang mit Inplace-Upgrades, auch von Servern, die richtig viele und wichtige Dinge beherbergen, gute Erfahrungen habe. Ich hab' hier (virtuelle) Kisten, die schon 3 Inplace-Upgrades (z. B. 2K8R2-> 2K12 -> 2K16 -> 2K19) erfolgreich hinter sich gebracht haben.
Ich habe nie gesagt, dass es unmöglich ist. Ich fang jetzt nicht an wie viel Datenmüll da drauf liegt, etc. Und natürlich ist es auch immer eine Sache der Erfahrung und der Software. Ich sag einfach mal so: Reicht es aus den Virenscanner zu deaktivieren oder muss ich ihn ganz deinstallieren?Ich hab' übrigens noch kein Inplace-Upgrade gehabt, bei dem ich bei Bedarf kein Rollback hätte vornehmen können.
Ich hab es von 2012 auf 2016 zweimal in einer Testumgebung versucht. Eines davon war ein DC. Der ist gestorben und konnte kein Rollback mehr machen.Ach übrigens: Die gleiche Diskussion haben wir grade hier:
Server migration auf 2019
MS selbst empfiehlt übrigens Inplace-Upgrades nicht. Und das hier etwas schieg geht sehen wir ja daran, dass er über die 52 Prozent nicht weiter raus kommt.
Gruß
Doskias
Fun Fact, und nur nebenher... Ich hab mich über die Maschine von der ich Euch geschrieben habe micht so geärgert das ich einfach mal ALLES versucht habe.... wirklich alles...
Die Maschine die sich nicht upgraden lassen wollte war ein Druckserver.... Ich habe die Druckserver Rolle deinstalliert... dann das inplace-upgrade gemacht.... Lief problemlos durch ^^... und nu weiß ich auch nicht
Trotz deinstallierter Druckserver Rolle läuft übrigens alles völlig Problemlos... Welcome to the wicked world auf microsoft
Die Maschine die sich nicht upgraden lassen wollte war ein Druckserver.... Ich habe die Druckserver Rolle deinstalliert... dann das inplace-upgrade gemacht.... Lief problemlos durch ^^... und nu weiß ich auch nicht
Trotz deinstallierter Druckserver Rolle läuft übrigens alles völlig Problemlos... Welcome to the wicked world auf microsoft
