Windows Server 2022: abwarten?

[mwiederkehr 373]

Hallo zusammen

 

Demnächst darf ich einen neuen Hyper-V-Cluster bauen. Der Kunde beschafft Lizenzen für 2022 Datacenter und CALs sind für Hyper-V ja keine notwendig. Die Hardware ist unterstützt für 2022, die Backupsoftware (Veeam) ebenfalls. Von daher könnte ich Server 2022 installieren. Aber soll ich?

 

Einerseits sollte man davon ausgehen können, dass eine freigegebene Serverversion stabil genug läuft für den Produktiveinsatz. Andererseits sind die Vorteile bei Hyper-V im Vergleich zu Server 2019 nicht so gross, um viel zu riskieren. Andererseits scheint es von 2019 zu 2022 kein so grosser Schritt zu sein wie von 2008 auf 2012, sodass sich die Fehler in Grenzen halten dürften.

 

Wie macht ihr das? Setzt ihr neue Versionen sofort nach Veröffentlichung ein oder wartet ihr „das erste SP“ ab, wie einem früher geraten wurde?

bearbeitet 15. Oktober 2021 von mwiederkehr

[Gulp 256]

Ich habe mein Testlab jetzt komplett von 2019 auf 2022 migriert, läuft gut und stabil ....... cool war ein InPlace Upgrade eines DC, lief sauber durch, war aber auch kein "komplizierter jahrelang gewachsener" Forest.

 

Direkt notwendig ist es allerdings sicherlich noch nicht, 2019 erfüllt seinen Zweck auch noch und solange es für 2019 noch offiziellen Support gibt und keine Anwendung zwingend 2022 erfordert, könnten höchstens verbesserte Hyper-V Ressourcenauslastung, verbesserte Hyper-V Funktionen etc ein echter Grund sein. Da gilt dann aber wie so oft im Leben: "Versuch macht kluch!"

 

Grüsse

 

Gulp

bearbeitet 15. Oktober 2021 von Gulp
Typo(s)

[NilsK 2.939]

Moin,

 

naja, das mit dem Servicepack galt mal, als es noch kein laufendes Update-Management gab. Gibt es heute, daher würde ich an der Stelle eine Abwägung machen.

 

Mal grob gesagt: Das Jahr, das das OS im Namen führt, hat noch nicht angefangen. Das deutet nicht auf einen hohen Reifegrad hin. Ein VM-Host muss "rock solid" laufen. Alle Hersteller müssen ihn wirklich supporten, nicht nur auf dem E-Paper.

Auf der anderen Seite sagst du, dass die neuen Features gar nicht von Interesse sind. Da man in einem Host-Cluster heutzutage sehr einfach rollierend aktualisieren kann, würde ich dem Kunden empfehlen, erst mal 2019 zu nehmen und in ein paar Monaten noch mal einen Tag in ein Upgrade zu stecken.

 

Nur meine 0,02 Euro,

Nils

 

[mwiederkehr 373]

Vielen Dank für eure Antworten! Von Interesse könnten die verbesserten Container-Features sein, wobei das mehr Wunschdenken ohne konkretes Datum ist, denn ich habe bis jetzt noch keine als Container verfügbare KMU-Software gesehen. Und ich habe mich noch nicht eingelesen, ob man die Container dann direkt auf den Nodes oder mit Nested Virtualization auf Container-Host-VMs laufen lässt.

 

Wie dem auch sei, wenn ich den aktuellen Liefertermin für die Hardware anschaue, wird Windows Server 2022 wohl schon nicht mehr neu sein, wenn ich loslegen kann...

[Weingeist 159]

Habe es auf ein paar Maschinen schon ausgerollt. Am ersten Tag als es verfügbar war. Erst im LAB, ein paar exzessive Tests mit Storage-Spaces, RDP usw. Bisher kein Problem. Meine eigene Umgebung hab ich danach fast komplett umgestellt ( Mein "Produktiv-LAB" bevor ichs auf andere loslasse ). Läuft sogar mit Horizon-Desktops einwandfrei. Las im Netz lediglich, dass man mit Storage-Space übernahmen warten sollte. Da gibt es wohl tatsächlich noch einen Bug wenn eine alte Version portiert wird. Den gibt es nicht auf neu erstellten Volumes. Mein Testlab-Volume machte dagegen keinen Ärger. Da ich produktiv aber immer alles neu erstelle weil ich auf potentiellen Upgrade-Ärger keine Lust habe, wird mich dieser Bug wohl nicht einholen.

 

Mein Fazit: Da es sowieso die letzte Version in der W10 Reihe ist und 2022 eher ein Mini-Update zu 2019 ist und wenig gravierende Änderungen hinzukamen - ausser eben bei SP - würde ich den einfach verwenden. Für neue Umgebungen eh, die sind ja meist am besten getestet von MS. Die erste Update-Runde ist ja auch schon raus. Imho ist das mehr ein Service-Pack als wirklich ein neues OS.

 

Mit 2022 hast 3 Jahre länger Ruhe vor einer neuen, wirklich notwendigen Updaterunde. Ich weiss, ist nicht Dienstleister-Chef freundlich aber, ich persönlich sehe das eher praktisch, Zeit für anderes.  :D

ABER: 2022 hat noch keine Exchange-Freigabe soweit ich das mitbekommen habe. Also weder das Domain Functional-Level noch die Installation darauf.

 

Kleines Schmankerl bezüglich ReFs, darauf kann man jetzt auch eine NFS-Freigabe machen.

 

Das einzige was mich persönlich nervt ist der bzw. die absolut aufdringlichen Tasks welcher Firewall-Freigaben automatisch bei Anmeldung erstellt. Und zwar nicht nur das erste mal, sondern jedes mal. Für allerlei Apps. Betrifft aber nur die GUI-Version. Welcher Task/service effektiv für welche Regeln verantwortlich ist, bin ich noch nicht 100% durch. Bis jetzt ging immer etwas anderes nicht mehr, wenn ich das wirklich abdrehen konnte. Auch will sich die Maschine ständig online mit Azure verbinden/registrieren. Ohne entsprechende Konfig versteht sich. Scheint gekoppelt zu sein mit der Meldung im OnPremise AD, also eher mühsam zum abschalten (ich habs über die Firewall gelöst, wird einfach geblockt bzw. nicht explizit erlaubt). Ein Teil der "Ärgernisse" gabs schon in 2019. Aber ich bin da auch etwas eigen, mich nervt alles was sich irgendwie ungefragt/unkofigurierbar ins Netz verbinden möchte.

Es sind wieder ein paar Services/Tasks besser vor Manipulation geschützt. Braucht also teilweise den TI, da manche Einstellungen automatisch wiederkehren auch wenn sie einem nicht schmecken (Medical Services welcher den Kram überwacht).

 

In Core mit FOD läuf immer noch ziemlich alles an Tools ohne jedoch ein grosser Teil der App-Geschichte. Sprich man bekommt z.Bsp. selbst das aktuelle Firefofox ESR recht problemlos zum laufen. 0815 Apps wie 7zip, putty, winscp etc. sind eh kein Thema. Meine das ging sogar unter reinem Core mit Minimalaufwand, hab aber nur ganz kurz rumgespielt. MMC braucht für die Unterstützung aller Bereiche etwas mehr Liebe. Wie vorher schon. Lohnt nicht so der Aufwand.

 

In einer GUI-Installation möglichst alles abdrehen was in Core nicht vorhanden ist (um zbsp. die Verwaltungstools zu haben oder Applikationen die auf GUI-Bibliotheken angewiesen sind ohne jedoch den App-Kram). Ist dagegen nicht mehr gleichermassen einfach wie auch schon. Geht zwar, aber Windows merkt neu, dass die Shell nicht vollständig geladen ist und versucht x-mal pro Sekunde die Shell neu zu laden (So schnell wie die CPU ist).

[NorbertFe 2.045]

vor 1 Stunde schrieb Weingeist:

ABER: 2022 hat noch keine Exchange-Freigabe soweit ich das mitbekommen habe. Also weder das Domain Functional-Level noch die Installation darauf.

 

Bisher nicht. Das stimmt. Aber ich vermute, das ist nur eine Frage von Tagen maximal wenigen Wochen.

[NilsK 2.939]

Moin,

 

Am 16.10.2021 um 17:58 schrieb mwiederkehr:

als Container verfügbare KMU-Software

klingt auch einigermaßen widersinnig. Der Witz bei Containern ist Modularisierung und bedarfsweise Skalierung auf Basis von Microservices. Nicht eben die Welt, in der sich selbst betriebene KMU-Software findet.

 

Gruß, Nils

 

[mwiederkehr 373]

vor 14 Stunden schrieb NilsK:

klingt auch einigermaßen widersinnig. Der Witz bei Containern ist Modularisierung und bedarfsweise Skalierung auf Basis von Microservices. Nicht eben die Welt, in der sich selbst betriebene KMU-Software findet.

Ja, grundsätzlich schon, aber ich sehe auch für einzelne Anwendungs-Instanzen Vorteile mit Containern. Ich habe die Hoffnung, dass sich so komplexe Installer, welche x Komponenten installieren oder updaten, vermeiden lassen. Aber da ist wohl etwas zu viel Wunschdenken dabei.

[NilsK 2.939]

Moin,

 

nun, wir sprechen von Serversoftware ... wer sowas nicht ohne komplexe Installation hinbekommt, wird als Developer wohl eher nicht auf Container umsteigen, fürchte ich ... 

 

Gruß, Nils

 

[Dukel 454]

Dafür hat man eine komplexe Installation einer Kubernetes Umgebung.

 

[cj_berlin 1.323]

Die Vision ist ja vor gefühlt 10-15 Jahren schon mal formuliert worden: Hersteller stellen ihre Software als virtuelle Appliances oder Container Images zur Verfügung, und der Kunde kann im Troubleshooting-Fall eine komplette Appliance dort einliefern... Vioelleicht kommen wir irgendwann auch dahin  

 

Eine komplette K8-Umgebung braucht man aber nicht, wenn nicht die automatisierte Skalierung das Ziel ist, sondern einfach das Verwenden vorgefertigter Container-Images. Noch ist Docker nicht tot, aber klar: in 2-3 Jahren muss man Kubernetes (oder Ähnliches) dann zwingend haben.

[Weingeist 159]

@cj_berlin Das mit Appliances/Container/Docker/Nano oder wie man immer das im Endeffekt nennen möchte sehe ich immer etwas kritisch . Ja die Begriffe sind vermischt, aber zielen alle drauf ab neue Standards durchzuboxen und alte Zöpfe abzuschneiden. Windows steht für Kompatibilität und das beisst sich mit abschneiden von alten Zöpfen. Wo es Schatten hat, hat es eben auch Sonne und anders rum. 

 

Keine Ahnung wie eine schöne neue IT-Welt funktionieren soll, wenn über 20 Jahre gewachsene Applikationen - auch wenn sie sogar mal Remanufactoring erleben - alle paar Jahre auf den Kopf gestellt werden sollen. Bugs ausmerzen wäre dann sicher nicht die Stärke von so einem Prinzip. Datenübernahme auch nicht. Innovationen würden entweder auf der Strecke bleiben oder die Entwicklung und Pflege wäre zu teuer. Sieht man ja an den Zigtausend technischen Geräten die überall rumschwirren. Sind im Grunde wie Appliances. Gepflegt wird da im Endeffekt gar nichts. Fire and Forget. Millionen wenn nicht Milliarden von kleinen technischen Geräten mit allerhand Sicherheitsproblemen. Von kleinen Gadget bis zur Kaffeemaschine oder dem Kühlschrank. Entweder man kauf neu oder es bleibt alt.

Klingt jetzt ketzerisch, aber das ist primär die Folge von Inkompatibilität und nicht gepflegtem Laufzeit-Untergrund. Es lohnt sich einfach nicht. Wenn auch in einem etwas anderen Kontext. Windows bietet eine Basis wo wenigstens der Unterbau selbst aktualisiert wird und somit viel zur Sicherheit von alten Zöpfen beiträgt.

bearbeitet 19. Oktober 2021 von Weingeist

[mwiederkehr 373]

Kompatibilität ist wichtig, aber manchmal ist es gut, einen Schnitt machen zu können und Konzepte, die sich als nicht so gut herausgestellt haben, über den Haufen werfen zu können. Jeder Entwickler schreibt Software, die er zehn Jahre später anders schreiben würde. Bei Windows fällt mir da als erstes RPC ein, oder auch das Handling der Benutzersitzungen. Unter Unix war es noch nie ein Problem, eine Anwendung auf einen beliebigen entfernten Bildschirm zu bringen. Unter Windows brauchte man dafür Citrix. (Unix hat dafür andere Nachteile, das ist nicht der Punkt.) Oder beim IIS hat man gedacht, es sei eine gute Idee, .NET Code direkt in der Request-Pipeline zu verarbeiten. Dann hat man gemerkt, dass das die Installation von neuen Versionen erschwert bzw. Kompatiblitätsprobleme mit sich bringt. Mit .NET Core kann jede Anwendung ihre Runtime mitbringen. Windows ist vielerorts "schlechter" als es sein müsste, weil man kompatibel bleiben will.

 

Ich will es nicht so haben wie man bei vielen Web-APIs sieht: eine Ankündigung, dass in spätestens einem halben Jahr die bisherige API nicht mehr geht und man bitte umstellen soll. Einfach ein /v1, /v2 etc. zu machen geht aber auch nicht beliebig lange, da man alle Versionen warten muss.

 

Wer gerne noch bessere Kompatiblität als bei Microsoft hat, dem kann ich System i von IBM empfehlen.  Eine Kundin verkauft das an ihre (immer weniger werdenden...) Kunden und ich konnte kaum glauben, dass man eine dreissig Jahre alte Software, deren Hersteller seit zehn Jahren nicht mehr existiert, einfach ohne Nervenkitzel auf die aktuellste Hardware übertragen kann. In den dreissig Jahren hat sogar die CPU-Architektur gewechselt, war alles kein Problem.

[Weingeist 159]

Bin ich schon im Grundatz bei Dir. Aber Zeugs das Top funktioniert durch einen halbgaren und oft komplett lahmen Schmarrn zu ersetzen wie das heute leider oft der Fall ist, ist einfach obermühsam. Da wäre eine Verbesserung des alten Codes oft sicher der bessere Weg. Oder wenigstens zu Ende gedachte neue Ideen. Aber heute sind ja auch die Leute nicht mehr 10 Jahre und mehr in einer Firma, muss man ja immer etwas neues sehen.

 

Beispiel:

Aktueller Zeitstempel für UWP: https://docs.microsoft.com/de-de/windows/uwp/get-started/universal-application-platform-guide (Wie toll doch UWP ist)

Und hier die Abkündigung: https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/overall-migration-strategy

 

Wie lange es wohl geht das der Krempel nicht mehr tut, 16bit, 32bit oder auch VB6 Anwendungen immer noch? =)

 

Oder Powershell, teilweise unglaublich langsam in der Verarbeitung bis hin zur Zumutung. Windows Firewall für Apps, ist der totale Wahnsinn und nicht konfigurierbar. Die Druckergeschichte, dabei sind Features von den eigentlichen Druckern ungefähr seit 30 Jahren so gut wie keine hinzugekommen. Es könnte also ein einziger generischer Treiber mit Infos der Hersteller gefüttert werden dazu ein Wrapper-Treiber für alte Drucker oder als Übergang. Aber solange man bei MS nicht mal die verbreitesten Funktionen implementiert.

 

 

Wie dem auch sei, bei 2022 bin ich mal wieder Out-of-the Box happy das im Grundsatz das Zeug einfach funktioniert. Nichtmal seltsame Fehler die man nicht wirklich zuordnen kann liefen mir bis jetzt über den Weg. Das Starmenü - wenn man es zerstört - wird normal beim nächsten mal anmelden wieder neu aufgebaut (hoffentlich ist die Engine unter 11 nicht wieder komplett neu und das spiel fängt von vorne an). Deswegen Profile löschen dürfte also deutlich seltener werden. Auch Index bzw. der Zugriff darauf von Cortana scheint crahssicherer zu sein und die Suche funktioniert nach einmal neu anmelden wieder. Alles in allem wohl ein gutes Service Pack 4 oder so =)

bearbeitet 19. Oktober 2021 von Weingeist