Windows Server 2022 krijgt enkel nog 10 jaar Long Term Servicing-ondersteuning

Microsoft geeft Windows Server 2022 in de toekomst alleen ondersteuning via een Long Term Servicing-channel voor een periode van tien jaar. Semi-Annual-channel-ondersteuning verdwijnt, maar blijft onder Azure Stack HCI bestaan voor oudere versies.

Microsoft schrijft op een releasepagina over de veranderingen aan Windows Server 2022. Het serversoftwarepakket had altijd twee soorten ondersteuning, zowel een LTS-channel voor langdurige support als een Semi-Annual-channel of SAC waarbij regelmatig nieuwe features werden geïntroduceerd. Die laatste bood ondersteuning voor 18 maanden na een release. Die laatste versie verdwijnt. "Vanaf Windows Server 2022 is er nog maar een releasechannel beschikbaar, het Long Term Servicing-channel", schrijft Microsoft.

Dat betekent dat gebruikers vanaf de toekomstige versie van Server standaard vijf jaar ondersteuning krijgen, met vijf jaar 'extended' ondersteuning erbij. Zulke releases hebben volgens Microsoft alleen nog beveiligingsfeatures en bugfixes. Er komen iedere twee tot drie jaar nieuwe versies uit van de software.

Windows Server 20H2 is de laatste Server-versie die nog gebruik kan maken van SAC. Dat gaat wel wijzigen. De functie gaat dan integreren met Azure Stack HCI.

Update: aangepast dat de extended updates niet betaald zijn, maar gratis.

Reacties (49)

[The Zep Man]

Dus weer terug naar het oude model. Logisch. Servers moeten zo lang mogelijk werken met enkel noodzakelijke wijzigingen. Grote upgrades horen daar niet bij. Kritische en beveiligingsupdates uiteraard wel.

Ik ben benieuwd hoe Microsoft om zal gaan met Windows 11. Voor Windows 10 ondersteunt Microsoft op het moment zeven verschillende versies. Mogelijk willen zij dit langzaamaan afbouwen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 22:56]

[Jay-v]

Nee, dat willen we juist niet. Zoveel mogelijk alles regelmatig opnieuw uitrollen. Patchen? Doen we niet aan, we vervangen gewoon voor een nieuwer image en rollen de applicatie opnieuw uit.

Applicaties waarbij dat moeilijk of bijna onmogelijk is neem je af als mamaged service of SaaS product. Bijvoorbeeld active directory of exchange.

Voor mij is dit de hele reden dan containers e.d. populair zijn. Waarom wilt iemand zich nog bezig houden met het onderhouden van server OSen. Het is arbeidsintensief en een hoog risico (neem bijvoorbeeld de recentelijke print exploit). Spooler uitzetten in base image en deployments opnieuw triggeren en klaar.

[YoMarK]

Print spooler uitzetten is ook een kwestie van het aanpassen van een group policy setting.
Als het voor de use case goed werkt om containers te gebruiken, helemaal fijn. Waar ik doorgaans mee moet en wil werken zijn (veel verschillende )ingewikkelde applicaties met vaak gevoelige data. Even afnemen als managed service of SaaS gaat niet of mag niet of het is twijfelachtig of het mag(Verwerkingsovereenkomsten, AVG, enz). Voor die use cases heb je dus on-prem servers waarbij het OS vooral geen beperking moet vormen in de vorm van ondersteuning/security.

[Jay-v]

Containers zijn niet noodzakelijk, en zeker op Windows niet altijd even makkelijk. Je kan echter VMs ook makkelijk opnieuw uitrollen.

Group Policy kan, mits je server in AD hangt. De meeste machines hoeven echter niet in AD. Sterker nog, dat heb ik liever niet want ik wil ze helemaal niet managen maar telkens opnieuw uitrollen. Dit zorgt er tevens voor dat je de netwerk verbindingen verder kunt beperken en geen Admin accounts hebt rondzwerven.

Ik hoor vaker het "moet onprem" argument, maar dit blijkt vaak niet nodig. Check maar eens aan welk compliancy model een applicatie moet voldoen. Immers als banken en zorginstellingen het kunnen, wat maakt jou business dan zo uniek? Daarnaast ben ik van mening dat encryptie opzetten in de cloud veel makkelijker is (zowel at rest als in transit).

[kameraadpjotr]

On premise is voor een hoop - voornamelijk applicaties waar een consument nooit mee te maken krijgt - zo goed als verplicht; en zo staat het ook in hun TOS in any application or situation where failure of the Online Service could lead to the death or serious bodily injury of any person, or to severe physical or environmental damage, except in accordance with the High-Risk Use section below; or

Denk maar aan software die machines beheert, verkeerslichten, traffic control, traffic management enz. Voor de meeste businessoftware kan je inderdaad naar de cloud gaan, maar als het gaat om veiligheidskritieke systemen is on-premise de enige mogelijkheid.

[collinbel]

En hoeveel downtime heb je dan? Gaat dit werkelijk sneller dan updates uitrollen?

[Jay-v]

Geen downtime, je zet er een loadbalancer voor.

[the_stickie]

Je gaat daar allemaal nogal licht over.... niet elke service kan je zomaar gaan balancen of clusteren. Bovendien is een loadbalancer niet goedkoop (idem licenties voor clustering etc) en heeft die ook weer ondersteunend personeel en updates nodig.
Ook hebben (grote) organisaties vaak een geschiedenis van organische groei en veel overnames. Zo kom je tot heterogene omgevingen met honderden applicaties en tientallen locaties.
In grote organisaties komt er ook altijd een hoop budgettering en politiek bij. Vaak is er sprake van verschillende juridische entiteiten en beslissingsstructuren die niet louter top-down zijn. Fabriek A doet dit, fabriek B wil iets totaal anders... en binnen 2 maand is een overname effectief van een keten verkooppunten met 30 vestigingen
IT draait 90% om geschiedenis! Het is wat mij betreft juist een van de mooie dingen van system engineering in heel grote omgevingen. 't Is altijd puzzelen en compromissen maken, terwijl er altijd opportuniteiten zijn voor "continous improvement".

[YoMarK]

Ik denk dat het maar net over gaat wat voor een use cases je te maken hebt, en er zijn vele wegen naar Rome. Denk dat Jay-v vooral te maken heeft met goed clusterbare (web)applicaties, waarvoor goede containers beschikbaar zijn, met een leverancier erachter die dat ook ondersteund.
Waar ik veel mee te maken heb, veel procesautomatisering en besturingstechniek(SCADA), veel rekenkundige applicaties(servers) en allerhande software voor een relatief kleine markt, en daar steekt de vork net wat anders in de steel. Natuurlijk hebben we ook het normale kantoorspul, Office 365 en wat SaaS maar daar wordt het geld niet mee verdient.

[Jay-v]

Ik ga er makkelijk overheen omdat het een "solved problem" is voor het over grote deel van de applicaties. Loadbalancers, reverse proxies zijn enorm makkelijk en goedkoop af te nemen als service (in de cloud) en er zijn tal van "gratis" oplossingen zoals Traefik voor webapps. Je hebt echt geen dure hardware appliance nodig.

Loadbalancing betekend niet per definitie dat er een cluster achter hoeft te zitten. Het kan prima 1 machine zijn die wekelijks/maandelijks vervangen wordt of vervangen wordt zodra er een healthcheck failure is. Een loadbalancer zorgt dan alleen voor een 'static' entrypoint voor de eindgebruiker.

Tuurlijk zijn er uitzonderingen (bijvoorbeeld active directory) en "geschiedenis". Dat neemt niet weg dat dit de standaard is voor moderne applicaties.

[Yalopa]

Als je dat goed onder controle hebt, en je applicaties kunnen dat aan dan is dat zeker doenbaar.

We spreken hier wel over een bovengemiddeld maturiteits niveau.

[the_stickie]

In heel grote omgevingen is dat vaal een doelstelling, maar ver van de realiteit. Er is serversoftware die nogal wat configuratie nodig heeft (ik denk bijv aan toegangscontrole en deursystemen of industriële sturingen) die anders is per site/implementatie. Ook worden er vaak applicaties geïnstalleerd en ondersteund door derden - die vaak hun eigen eisen of methode hebben.
Dan ligt de prio al snel op het vlot uitrollen van een base os + basisrollen.

Voor wat betreft de spooler uitschakelen, patching en basissoftware onderhouden, moet je niet opnieuw uitrollen, daar heb je configuratie mgmt tools voor. Sccm, bigfix, maar ook bijv ansible

[dasiro]

managed services en SaaS zijn the easy way out, maar dan zit je wel vast aan het release-tempo van een externe partij. als je dan servers hebt met slow connectivity van amper een paar Mbit dan mag je je nieuwe image dagenlang door de lijn proberen te duwen.

De wereld is groter dan enkel de breedbandlanden en dan spreek ik met ervaring over landen als cuba, nigeria, ... daar is het niet ff snel een image redeployen als dat je enige locatie in het land is. Zelfs in Europa is er nog plek zat met amper 10Mbit waar wel dingen lokaal moeten kunnen draaien zonder dat daar een deployment server of distribution point kan staan

[walteij]

Servers moeten inderdaad gewoon zo lang mogelijk en stabiel werken met enkel noodzakelijke wijzigingen, helemaal mee eens.
Maar met de huidige virtualisatiesprongen en de eenvoudige in-place-OS-upgrades is het op zich niet meer heel gecompliceerd om een server iedere 2-3 jaar te upgraden naar de laatste versie. Laten we wel wezen, de fysieke hardware is tegenwoordig geen reden meer om een Windows Server te vervangen, die draait immers op een Hyper-V/VMware/XenServer cluster of cloud dienst, dus die onderliggende laag kan vervangen worden zonder downtime.

[The Zep Man]

Maar met de huidige virtualisatiesprongen en de eenvoudige in-place-OS-upgrades is het op zich niet meer heel gecompliceerd om een server iedere 2-3 jaar te upgraden naar de laatste versie.

Dat het kan staat niet ter discussie. Of er voldoende vraag (use cases) naar is en of dat opweegt t.o.v. de investering (in menstijd) valt te betwijfelen.

[walteij]

Ik kan daarin 2 compleet verschillende scenario's verzinnen. Een MKB bedrijf met een VM of 8, waarbij een upgrade eenmalig een weekend werk is voor de ICT afdeling. Voor hen kan het een prima investering zijn, omdat het eens in de 2-3 jaar een weekend werk is.

Als je daar een enterprise organisatie tegenover zet met 2000+ Windows Servers, heb je een compleet team nodig om de in-place-OS-upgrades uit te voeren, waarbij dat team nooit klaar is, want zodra je alle servers hebt gehad, is de nieuwe versie er al en begin je van voren af aan. Daar zal toch goed nagedacht moeten worden over de investering in uren en mensen.

En dan heb je natuurlijk nog heel veel varianten daar tussen zitten.

[vali]

Het is maar net wat voor mensen je in dienst hebt en hoe het opgezet is. Ik vind een omgeving met 2000 servers niet echt heel spannend om eerlijk te zijn.

Als je automation goed beheerst rol je compleet nieuwe server uit en plaatst je de applicatie erop terug. Dan maakt het niet uit of je 5 servers in beheer hebt of 2000+.

[Reactie gewijzigd door vali op 23 juli 2024 22:56]

[Genicus]

Als je een aantal applicaties hebt, kan je dat misschien doen ja. Als je echter vanalles en nog wat hebt draaien, verspreid over die 2000 servers - laten we zeggen 1000 applicaties - dan is dat ineens veel moeilijker te scripten/automatiseren.

[vali]

Als je een aantal applicaties hebt, kan je dat misschien doen ja. Als je echter vanalles en nog wat hebt draaien, verspreid over die 2000 servers - laten we zeggen 1000 applicaties - dan is dat ineens veel moeilijker te scripten/automatiseren.

Ook als je vanalles hebt draaien moet dit geen enkel probleem zijn. Het is echt maar net wat voor mensen je in dienst hebt maar als je tegenwoordig nog zo erin zit dan is het tijd om flink wat kennis op te doen en je team mee te krijgen naar het beheren van omgevingen met software as a code.

[Zackito]

En met die 1000 applicaties heb je ook nog eens 500 verschillende leveranciers voor de applicaties. Software pakket A praat met software pakket B, beide geleverd door een andere leverancier.

De applicatie kan je zelf niet migreren omdat je afhankelijk bent van meerdere third parties. Leverancier A zegt, wij ondersteunen geen server 2022 dat komt pas over een jaar.

Het is zeker makkelijk om servers uit te rollen door middel van een template, maar je moet mogelijk ook nog met third party leveranciers schakelen en inhuren (duur grapje) als je niet zelf de applicaties beheerd.

[vali]

En met die 1000 applicaties heb je ook nog eens 500 verschillende leveranciers voor de applicaties. Software pakket A praat met software pakket B, beide geleverd door een andere leverancier.

Klopt helemaal, maar ergens moet het begin zijn. Als je alleen maar beren op de weg ziet kom je nooit van een omgeving af dat niet te beheren valt.

[Zackito]

Zeker, ik relativeer alleen het deel waar jij aangeeft dat alles makkelijk te doen is.

Ik werk zelf bij een IT diensverleningsbedrijf en verbaas me altijd hoe moeilijk interne beheerders vaak denken, die zien inderdaad vaak beren op de weg. Geven ook vaak aan dat ze druk zijn, vraag me vaak af waarmee want als je er bent zijn ze vaak alleen maar aan het lullen met collegas.

[vali]

Ik zeg nergens dat het makkelijk is (verre van), geef alleen dat het niet spannend is om 2000 servers te beheren en als je het goed aanpakt het prima te realiseren valt.

Ik werk zelf bij een IT diensverleningsbedrijf en verbaas me altijd hoe moeilijk interne beheerders vaak denken, die zien inderdaad vaak beren op de weg. Geven ook vaak aan dat ze druk zijn, vraag me vaak af waarmee want als je er bent zijn ze vaak alleen maar aan het lullen met collegas.

Zeer herkenbaar. Die mensen moeten niet raar opkijken als ze straks zonder werk zitten. Jammer genoeg de harde realiteit wat nu gaande is in de IT-wereld.

[Reactie gewijzigd door vali op 23 juli 2024 22:56]

[IStealYourGun]

2 requirements die je niet snel zal zien in een industriële enterprise omgeving. Want personeel is duur, dus bij voorkeur zo weinig mogelijke en industriële software is zelden geoptimaliseerd om flexibel te upgraden. In een perfecte wereld draait die software gewoon in containers, in de realiteit heb je nog steeds providers die zelfs aanraden om hun software op fysieke hardware te draaien zonder hypervisor. Gelukkig kom dat laatste steeds minder voor.

[vali]

industriële enterprise omgeving

Dit zie je zeker wel in dat soort omgevingen hoor. Ooit moet de stap gemaakt worden om de omslag te maken en deze heb ik in het verleden al meerdere keren toegepast bij zeer grote klanten.

Het maakt hierbij niet uit of het in een container draait of niet. Niet elke applicatie is hiervoor perfect voor.

[Reactie gewijzigd door vali op 23 juli 2024 22:56]

[Yarisken]

Goh ik heb in de OT wereld pak applicaties beheerd en dat van "nieuwe server en applicatie erop" ... komt een heel heel pak meer bij kijken.
Testing alleen is al veel en lang werk.
Laatste grote migratie was 24 prod, 14 accept en 4 test servers en dit had toch een doorlooptijd van 1 jaar voor de upgrade rond was.

[vali]

Goh ik heb in de OT wereld pak applicaties beheerd en dat van "nieuwe server en applicatie erop" ... komt een heel heel pak meer bij kijken.

Er komt inderdaad hoop bij kijken en maar dat zit hem voornamelijk op de manier van werken. Veel handwerk toepassen en vooraf niet rekening houden wat je wilt gaan testen dan kost dat inderdaad veel tijd.

Over grotendeel van het testwerk kan je volledig automatiseren. Verre verleden flink wat RHEL6 bakken geupgrade naar rhel7. Deden er met gemak 12 per week en hiermee werden applicaties ook meegenomen. Mijn voorkeur gaat niet naar inplace upgrade, maar de klant wilde dit graag. Uiteraard kwam hier amper handwerk ten pas.

[Reactie gewijzigd door vali op 23 juli 2024 22:56]

[GeroldM]

Boot drive van mijn Bacula server (Linux backup server software) gecloned. Daarna de clone getest en werkte prima. Maar na de inplace upgrade was alle Bacuala software en data verdwenen. En het was de enige applicatie op die machine.

Was op Ubuntu Server LTS gebaseerde server. Denk dat sommige applicaties minder tot niet geschikt zijn voor de door jouw voorgestelde werkwijze.

De orginele drive maar weer terruggeplaatst en mijn backup teruggespoeld. Bacula server werkte weer als een zonnetje. Ben het dus met je eens dat inplace upgraden eigenlijk nooit de voorkeur zou moeten hebben.

[The Zep Man]

Ik kan daarin 2 compleet verschillende scenario's verzinnen. Een MKB bedrijf met een VM of 8, waarbij een upgrade eenmalig een weekend werk is voor de ICT afdeling. Voor hen kan het een prima investering zijn, omdat het eens in de 2-3 jaar een weekend werk is.

Dan nog steeds mis je de use case. Zoals genoemd wordt er niet getwijfeld aan of het kan. Bedrijven hebben echter geen boodschap aan 'omdat het kan'.

De meeste MKB's die iets van eigen servers draaien hebben meer behoefte aan stabiliteit, en niet zozeer aan nieuwe functionaliteit op servers.

[SHFT]

Ik zie daar eerlijk gezegd het nut niet van in, onze MKB klanten veranderen gemiddeld om de 3-5 jaar van server. Met die nieuwe hardware komt ook de nieuwste server versie.

Bijkomstig is er voor MKB bitterweinig veranderd op OS niveau de laatste jaren vind ik dus om een OS upgrade verkocht te krijgen halverwege hun afschrijving is lastig.

[Mastofun]

Enterprise is toch ongeveer hetzelfde, je hebt x aantal ICTers nodig per x aantal servers die ze kunnen onderhouden/nakijken/patchen. Wij krijgen servers toegewezen en moeten zorgen dat ze altijd up to date zijn. We bepalen algemeen wat het doel OS is en momenteel is dit 2016 en 2019 als alles compatible en getest is. Mijn servers draaien momenteel allemaal op 2019 buiten de ERP systemen die 2019 nog niet supporteren. Als techniekers geen tijd hebben voor hun servers te updaten dan moet er extra volk bijkomen. Dan hebben ze zeker ook geen tijd voor preventieve problemen te zoeken zoals logs nakijken etc

[Anoniem: 1322]

Een MKB bedrijf met een VM of 8, waarbij een upgrade eenmalig een weekend werk is voor de ICT afdeling. Voor hen kan het een prima investering zijn, omdat het eens in de 2-3 jaar een weekend werk is.
Een MKB bedrijf moet helemaal zelf geen servers meer draaien (tenzij het hun core business is). Als jij onder de 250 mensen in dienst hebt, dan kun je veel beter SaaS diensten afnemen. Dat is onder de streep veel goedkoper gezien organisaties simpelweg de kennis niet (kunnen) hebben om dit allemaal in-huis goed af te handelen. Ik geef Microsoft altijd als voorbeeld: als jij 1 of 2 Exchange servers hebt, dan ben je geen Exchange klant maar een Exchange online klant voor Microsoft. Het is financieel ook helemaal niet meer te verantwoorden om een Exchange server on-premise te hebben.

Zelfs als grote organisatie ben je slecht bezig als je nog (Windows) servers uitrolt, er is simpelweg geen businesscase voor te schrijven. Containers en clouddiensten zijn op zulke schaal beschikbaar dat het helemaal niet meer relevant is (buiten die hele bijzondere omgeving om, die veel mensen onterecht denken te zijn) om je daar nog mee bezig te houden.

[cool0]

Het is aan klanten ook lastig uit te leggen waar je vroeger kon zeggen u heeft Windows XP SP3 nodig of windows 7 SP1 minimaal moet je nu zeggen u heeft nodig Windows 10 .... build XXXXX En daar gaat het mis omdat klanten niet begrijpen wat een build is en deze te vaak wijzigen. Je kan niet meer zeggen u heeft windows 10 nodig want de klant denkt dan ja dat heb ik ja maar niet de goede windows 10 versie. Vooral in onze industrie(maritiem) is dit echt een drama.

[CAPSLOCK2000]

Dus weer terug naar het oude model. Logisch. Servers moeten zo lang mogelijk werken met enkel noodzakelijke wijzigingen. Grote upgrades horen daar niet bij. Kritische en beveiligingsupdates uiteraard wel.

Ik ben het daar niet helemaal mee eens. Uiteraard moeten dingen niet zomaar veranderen en tussendoor voorspelbaar blijven maar we moeten af van het idee dat je systemen jarenlang hetzelfde blijven en dat er dan een grote update komt waarin alle veranderingen tegelijk worden doorgevoerd.

Hoewel je een stabiele periode maakt is de kans dat je daarna ingrijpend moet veranderen er groot. Het zijn niet meer een paar kleine overzichtelijke veranderingen maar een hoop grote veranderingen die ook elkaar weer beinvloeden. In praktijk zie ik dat systemen jarenlang min of meer bevroren zijn en dan moet in een keer alles tegelijk worden gedaan. OS, database, applicatie, webserver, virusscanner, ssl-configuratie en weet ik veel wat er nog meer op zo'n server zit. Dat is niet te overzien en nauwelijks vooraf te testen. Als je dan ook interacties hebt met een hoop andere systemen wordt het nog moeilijker om op een punt grote veranderingen te doen. Dan krijg je de situatie dat je verschillende servers en applicaties tegelijk moet vervangen. Zo worden projecten steeds groter en trager. Ondertussen wordt het probleem alleen maar groter.
En als je dan eenmaal aan je megamigratie begint en er gaat iets fout dan is teruggaan vaak eigenlijk niet meer mogelijk omdat alles met alles is verweven.

Ik ben daarom steeds meer fan van continue verandering waarbij je niet hele systemen in één keer probeert te upgraden maar voortdurend kleine en overzichtelijk stapjes kan nemen. Als er iedere twee jaar een nieuwe Windows versie uitkomt dan zou je iedere twee jaar het OS moeten upgraden/herinstalleren. Natuurlijk lukt dat niet altijd maar daar zijn die 10 jaar support voort. Als je denkt dat je een server 10 jaar kan laten draaien en dan nog kan gaan upgraden dan ga je van een koude kermis terrugkomen zodra het een beetje complex wordt.

In mijn ervaring komen dat soort systemen in een legacy-hoekje terecht waar niemand meer naar omkijkt tot er iets dramatisch mis gaat en er eigenlijk niks meer aan te doen is.

[bartje]

Was er een semi annual update voor servers dan?

Dat betekent dat gebruikers vanaf de toekomstige versie van Server standaard vijf jaar ondersteuning krijgen, met vijf jaar optionele betaalde ondersteuning erbij

5 jaar in de basis lijkt kort. Dat berent dat zonder extra te betalen je iedere 5jaar er iets mee moet doen.
Op dit moment krijgt win 2012 nog security updates zonder te betalen.

[burnedhardware]

Dat is verschrikkelijk kort.

In de industrie en in laboratoria zit je met leveranciers die 3-4 jaar nodig hebben om hun produkt geschikt te maken voor een nieuwe windows versie (of beter gezegd: het duurt zolang voordat ze durven te zeggen dat ze die versie ondersteunen; installeren op een nieuwere versie kan wel, maar veel plezier als er een bug in blijkt te zitten). Vervolgens ga je dat implementeren en testen, en tegen de tijd dat je live gaat, is de windows uit support

[SED]

Commercieel een terecht punt. Maar security wijze gezien een mooi moment om na 5 jaar te bekijken of je niet toe bent aan een nieuwe versie. Als dat te vroeg is heb je weer 5 jaar om te schakelen.

[Anoniem: 1322]

Was er een semi annual update voor servers dan?
Ja, net als Windows 10 werd deze gebruikt binnen Azure. Je moet die dingen zien als 'stateless' servers die iedere keer refreshed werden met de laatste build.

Volgens mij werden ze ook ingezet als Nano servers (hosts voor containers) maar daar ben ik niet zeker over.

[beerse]

Dus na windows Server in 2016 die net als W10 een roling-update zou krijgen was er voor Windows Server al snel ook een lts versie: windows server 2016. In 2018 is een versie aangewezen als Windows Server 2019. Dus is het mijn verwachting dat na Server 2022 ook Server 2025 en volgend gaat komen. Allemaal long term support, hoe lang dat long ook gaat zijn.

De windows server, dus zonder nummer gat nu blijkbaar online. Geen probleem, die is voor vele bedrijven toch niet praktisch.

[Loller1]

Windows Server 2016 is ouder dan de eerst SAC-versies, dat begon pas met versie 1709 een dik jaar nadat Server 2016 uit kwam en had nooit de bedoeling om de "grote" versies te vervangen.

[beerse]

Dat er een windows-server-sac versie is gekomen is pas nadat eerst Windows Server (zonder nummer) was geïntroduceert en vervolgens toch maar Windows Server 2016 genoemd is omdat de grote klanten graag stabiliteit wilden hebben, ook in de geboden services en dergelijke. Windows Server 2016 is daarom ook pas echt in 2016 aangekondigd en in het nieuws gekomen en niet zoals windows 2019 een jaar ervoor.

[Marve79]

Dus de semi annual core only versies verdwijnen als ik het goed begrijp (die waarsch niemand gebruikt).

[gerwim]

Ook een leuke: aangezien Microsoft is gestopt met SAC, is er voor Windows 21H1 geen base container image. Dit betekend dat je geen Windows containers op Windows 10 21H1 kan draaien met process isolation.

Thread op GitHub: https://github.com/microsoft/Windows-Containers/issues/117

[Reactie gewijzigd door gerwim op 23 juli 2024 22:56]

[fRiEtJeSaTe]

Prima. Maar Microsoft’s agenda is wel duidelijk. Als je nieuwe features wilt, moet je naar de cloud.

[Loller1]

Dus... Vroeger, pre-Server 2016 was het ook Microsoft's plan dat als je nieuwe features wilt dat je naar de cloud moest? Met Server 2000 wou Microsoft ook dat je naar de cloud ging?

[fRiEtJeSaTe]

Doe niet zo simpel. Er gebeurt hier precies hetzelfde als met Office, Exchange, etc. Microsoft wil gewoon abonnementsvormen aansmeren en de rest uitfaseren. Logisch want daarmee hebben ze een steady cashflow, vendor lock-in, en kunnen ze een hogere prijs vragen.

[Psycho_Mantis]

Volgens mij was Server Core een eis voor de feature update. Echter heb ik maar weinig bedrijven gezien die Server Core wilde draaien.

[Kaassaus3]

Als of we vast zitten in n loop met die chip tekort 😔