Microsoft stopt met actieve ontwikkeling van Windows Server Update Services

Microsoft is gestopt met de actieve ontwikkeling van Windows Server Update Services. De systeembeheertool zal vooralsnog blijven functioneren, maar het bedrijf zal geen nieuwe functies meer aan de software toevoegen.

Microsoft schrijft in een blogpost dat gebruikers ook geen nieuwe functies meer zullen aandragen. De huidige functies en features van de systeembeheertool blijven echter wel werkzaam en dat zal volgens Microsoft ook zo blijven. Het Amerikaanse techbedrijf raadt klanten aan om naar andere tools over te stappen, zoals Windows Autopatch, Microsoft Intune en Azure Update Manager.

Microsoft Windows Server Update Services werd in 2005 voor het eerst uitgebracht. Het betreft een systeembeheertool waarmee IT-beheerders updates en patches voor Windows-apparaten binnen een organisatie kunnen uitrollen en beheren. De tool is onderdeel van Windows Server.

Door Jay Stout

Redacteur

22-09-2024 • 12:38

77

Lees meer

Reacties (77)

Sorteer op:

Weergave:

Begrijpelijk dat deze als stand-alone tool wordt uitgefaseerd qua nieuwe features. Het pakket werkt prima, maar was qua mogelijkheden toch best wel beperkt, als je het vergelijkt met genoemde alternatieven of SCCM/MECM etc.

En voor de duidelijkheid, omdat het artikel het niet meldt: SCCM/MECM, die onderwater ook deze WSUS tool gebruikt, is uitgezonderd van deze update-freeze, die blijven wel nieuwe features ontvangen:
WSUS deprecation does not impact existing capabilities or support for Microsoft Configuration Manager.
Zie het gelinkte bron-artikel van Microsoft: https://techcommunity.mic...-deprecation/ba-p/4250436
Bor Coördinator Frontpage Admins / FP Powermod @wildhagen22 september 2024 12:57
Het pakket werkt prima, maar was qua mogelijkheden toch best wel beperkt, als je het vergelijkt met genoemde alternatieven of SCCM/MECM etc.
De update management functie binnen SCCM/MECM is WSUS. Er is geen functioneel / tecnhisch verschil. Het enige wat SCCM toevoegt is management met andere tooling.
En voor de duidelijkheid, omdat het artikel het niet meldt: SCCM/MECM, die onderwater ook deze WSUS tool gebruikt, is uitgezonderd van deze update-freeze, die blijven wel nieuwe features ontvangen:

WSUS deprecation does not impact existing capabilities or support for Microsoft Configuration Manager.
De bron spreekt duidelijk van existing capabilities en support en niet over nieuwe features. Kortom, ook daar hoef je niet veel tot niets meer te verwachten. Het past allemaal in de lijn van het pushen naar Azure.

[Reactie gewijzigd door Bor op 22 september 2024 13:30]

[...]


De update management functie binnen SCCM/MECM is WSUS. Er is geen functioneel / tecnhisch verschil.
Dit is onjuist. SCCM/MECM gebruikt WSUS (en die is ook noodzakelijk), maar geeft meer controle over het deployment proces, plus meer rapportage mogelijkheden.
SCCM, or System Center Configuration Manager, is a paid patch management solution from Microsoft. SCCM relies on WSUS to check for and apply patches, but offers some more desirable features and gives users more control over how and when patches are deployed. While SCCM has a few advantages over WSUS and can seem like a more desirable option for larger organizations, there are still several challenges that companies may face when using SCCM for patch management.

SCCM includes a number of functions that can benefit users, including more control over patch deployment, the ability to generate reports and control over Windows machines on their network. SCCM also provides endpoint protection tools, and if configured correctly, SCCM can be an adequate patch management system for organizations predominantly running on Windows. As a Microsoft product itself, SCCM integrates quite well with Windows systems and Microsoft products.
Zie https://www.automox.com/b...nce-between-sccm-and-wsus

En met MECM kan je, zei het beperkt, ook 3rd party applicaties patchen, iets wat WSUS veel minder uitgebreid support:
Hybrid infrastructure will still require elements of manual patching with SCCM, and third party application patching is just as limited. While SCCM does provide more support for third party apps than WSUS, that's not really saying much. In fact, problems with using SCCM to patch third party applications are a top source of frustration for IT managers.
(Zelfde link)

Ook biedt MECM de mogelijkheid om zelf extra rapportages te maken mbt patch managmeent, wat bij WSUS zelf niet kan (zonder zelf in de DB te gaan graven met custom queries dan).

[Reactie gewijzigd door wildhagen op 22 september 2024 13:03]

Bor Coördinator Frontpage Admins / FP Powermod @wildhagen22 september 2024 13:18
Mooie marketing speak. Die extra rapportages zijn bv ook met PowerBI te realiseren (en nog veel meer). De database is erg simpel. Rapportages kunnen ook met WSUS gemaakt worden zolang de standaard voldoet (maar als die niet voldoet voldoet de rapportage uit SCCM ook al snel niet).
Als je niet begrijpt wat het verschil is tussen lomp wsus via gpo naar je clients pushen of sccm/mecm op update gebied geeft dat niet, maar ga dan ook geen scheve discussies voeren.

De roll out for de major releases zoals 23h2 etc is echt wel even heel ander level binnen de sccm/mecm wereld. Ook de hoeveelheid controle die je hebt, en dan heb ik het dus niet alleen over deze update wel of niet.

Sccm/mecm zal nog wel een tijdje blijven bestaan want niet iedereen wil naar Intune, het is vooral het mkb waar wsus draait en dan machines imagen met kale deployment server en maybe via gpo een paar msi's droppen en dan heb je het wel gehad. Vaak zit de overige software in de image ingebakken etc.

Dat is echt een heel andere wereld die over de linie beter af zal zijn in de cloud oplossingen, al was het maar omdat je niet van die ene omhoog gepromoveerde finance medewerker die zich nu IT'er noemt kan vragen om de boel veilig te houden.

Nog een kleine toevoeging, wsus was vroeger handig toen je met je hele bedrijf op een 15mbit adsl zat en dan in de nacht de updates kon cachen. Gelukkig is het tegenwoordig 2024 en heb ik recent in sccm uitgezet dat updates gecached worden op de locaties, zonde van de schijfruimte. Clients trekken nu op basis van wat approved is in sccm gewoon direct vanaf Microsoft de updates binnen en de firewalls cachen dat tijdelijk indien nodig.

[Reactie gewijzigd door themadone op 22 september 2024 15:46]

Bor Coördinator Frontpage Admins / FP Powermod @themadone22 september 2024 20:01
Als je niet begrijpt wat het verschil is tussen lomp wsus via gpo naar je clients pushen of sccm/mecm op update gebied geeft dat niet, maar ga dan ook geen scheve discussies voeren.
Zo onvriendelijk hoeft niet hoor. Ik heb ervaring met beide oplossingen. Zoals gezegd is het update mechanisme in SCCM / MECM gewoon WSUS. Daar is de microsoft documentatie ook gewoon duidelijk. Ja SCCM biedt veel meer opties daar omheen maar de kern is echt hetzelfde. Datgene wat SCCM aan aanvullende zaken biedt kan je ook op andere manieren bereiken.

[Reactie gewijzigd door Bor op 22 september 2024 20:30]

Toch is een deployment/caching server wel handig in veel datacenters. Zorgt toch voor minder stress. Als het ff tegenzit met de download kan zo maar het maintenance window niet gehaald worden.
Daarnaast wil je gewoon niet altijd alle servers gewoon een verbinding laten hebben met het internet. Dat zorgt er ook voor dat als er iets raars op de servers komt te staan, dat ook dat rare programma niet zomaar naar buiten kan communiceren.
Datzelfde is van toepassing op sommige client netwerken. Die wil je soms ook gewoon niet allemaal zomaar het internet op laten gaan.

Dus ja, bij een deel van de bedrijven kunnen de clients best zelf downloaden van Microsoft. Maar er zijn zeker ook veel situaties te bedenken waarop je dat niet wilt.
"t vanaf Microsoft de updates binnen en de firewalls cachen dat tijdelijk indien nodig.". Welke firewalls heb jij hangen dan?
En je merkt ook dat config mgr op zijn laatste benen aan het lopen is. Alles wordt op termijn cloud, en dus subscription based, wat ook de reden is dat ik bij ons in de firma niet eens de toestemming meer ga vragen om nog een project op te starten configmgr uit te rollen.
Probleem blijft toch dat niet alles wat in sccm zit al kan via de cloud. Als ik soms zie hoe gebrekkig Intune nog is, dat gaat nog wel even duren.

Maar vooral voor je servers is er nog niet echt een alternatief.
Is Intune dan “gebrekkig” naar jouw ervaring? Of zijn de producenten en ontwikkelaars te laat begonnen en lopen die achter?
Alleen kost SCCM dan wel weer extra geld. Microsoft zet nu een tool uit die in je Windows Server licentie zit en verwijst naar andere tooling waar je aanvullend voor moet betalen.
De tool wordt niet uitgezet, die blijft gewoon functioneren zoals het artikel al letterlijk meldt. Hij krijgt allen geen nieuwe functionaliteit meer.
De huidige functies en features van de systeembeheertool blijven echter wel werkzaam en dat zal volgens Microsoft ook zo blijven.
Waarbij ik me ook direct afvraag: wat is de laatste functionaliteit die ze toegevoegd hebben, en wanneer was dat?
Pfew, goede vraag. Ik kan het me niet eens herinneren, heb niet het idee dat er heel veel aan development gedaan is sinds versie 3.0, en die stamt alweer uit 2008 geloof ik (of 2009, mag ik even kwijt zijn).

Sindsdien zijn er uiteraard wel nieuwe versies met elke nieuwe Windows-versie uitgekomen, maar de nieuwe functionaliteit is daarin volgens mij beperkt gebleven tot (uiteraard) support voor die specifieke OS-versie inclusief bijbehorende rapportages etc.

Los van toevoegen van die nieuwe versies is er volgens mij qua nieuwe features uit 2008/2009 (dus versie 3.0 van WSUS) niet heel erg veel bijgekomen. Ook de interface is, op wat kleine details hier en daar na, nog altijd identiek aan 3.0.

Ik vraag me daarom in alle eerlijkheid af of deze feature-deprecation uit dit artikel wel heel erg merkbaar gaat zijn in de praktijk, anders dan dat het dus mogelijk niet meer in Windows Server 2025 (of hoe die ook gaat heten) zal worden meegeleverd (en mogelijk wordt hij daar alsnog geleverd, maar pas in de eerstvolgende versie van Server niet meer).

Dikke kans dat de soep allemaal niet zo heet gegeten wordt als hij nu wordt opgediend.
...Sindsdien zijn er uiteraard wel nieuwe versies met elke nieuwe Windows-versie uitgekomen, maar de nieuwe functionaliteit is daarin volgens mij beperkt gebleven tot (uiteraard) support voor die specifieke OS-versie inclusief bijbehorende rapportages etc.
Qua timing ligt het voor de hand dat Windows Server 2025 niet ondersteund zal worden. Daarmee ligt het einde van WSUS in de praktijk gelijk ligt aan de EOL van WIndows server 2022. Mainstream support daarvoor stop al in oktober 2026, dus voor de kleinere gebruikers die zich geen extended support kunnen veroorloven is WSUS over twee jaar feitelijk einde oefening.
Je krijgt gewoon security updates voor Server 2022 tot 2031, zonder meerkosten.
Dat durf ik niet zeggen, ik zie niet in waarom Server 2025 updates niet beschikbaar zouden komen in WSUS, het is uiteindelijk gewoon onderdeel van de update catalog. Wat er vermoedelijk zal gebeuren is dat MS ofwel bij Server 2025 danwel bij 2028 zal aankondigen dat WSUS geen feature meer zal zijn van het OS. Maar dat is niet wat ze hier gedaan hebben want als ik me niet vergis is WSUS gewoon aanwezig in de huidige test releases van Server 2025, die ondertussen al lang een feature freeze hoort te hebben.
Wat in de blog staat is dat WSUS zelf nog gewoon aanwezig is in Server 2025 als een role. Wat dan weer niet in het artikel staat is of WSUS ook nog de updates van Server 2025 of Windows 12 kan uitrollen.
De tool wordt niet uitgezet, die blijft gewoon functioneren zoals het artikel al letterlijk meldt.
Dit is wel de manier waarop Microsoft meestal software en services af laat sterven. Eerst een persbericht dat het "af" is (mature) en geen nieuwe features zal krijgen. Dan een paar jaar niets (in het begin misschien nog een bugfix) en dan stilletjes de stekker er uit trekken.
Ze blijven gewoon support geven (patching), het is ook nog gewoon onderdeel van Server 2025. Ze gaan geen active development meer doen, als ik het zo lees nog wel gewoon support.
WSUS is/was een feature van windows server, wat wil zeggen dat je het op élke server zonder extra licentiekost kon installeren en gebruiken als onderdeel van je on-premise domain als je geen zin had om over te stappen op een cloud en/of betalend alternatief, omdat het gewoon voldeed aan je vereisten. Welke "features" ze de laatste jaren zouden hebben toegevoegd kan ik je niet vertellen, tenzij ze "support voor versie X van Windows (server)" als feature zouden aanzien, wat het dus niet is, gewoon een nieuw nummertje qua OS-build.
Eigenlijk zie je dat on-the-prem langzaam aan totaal geen optie meer aan het worden is.
De ondersteuning van Microsoft voor on the prem oplossingen neemt geleidelijk maar gestaag af.

Ergens voor Microsoft perfect want je wordt geforceerd om van hun cloud oplossingen gebruik te maken als je deze functionaliteit wil.
Je kan ook iets van Ansible gebruiken. Dan zit je niet aan de oplossingen van Microsoft vast.
Kan ansible dan ook updates uitrollen op servers die geen internet hebben?
Ansible triggert het interne windows update mechanisme via Powershell over winrm. Waar de updates vandaan komen (Windows update of via wsus) zal hangen hoe je de windows machine geconfigureerd hebt.

Je kunt met Ansible ook prima software deployments doen. Een update pushen en deployen zal ook prima werken.

Maar losse updates wil je eigenlijk niet deployen via Ansible op reguliere basis want dan moet je elke maand alle updates afzonderlijk gaan zitten packagen.
Dat is wat ik dacht, geen alternatief voor WSUS dus (voor deze use case)
Ansible en Windows is ook een cocktail die ik liever vermijd of eerlijk te zijn.
Waarom? Het is allemaal gebaseerd op PowerShell, dingen die Microsoft zelf promoveert (als je native PowerShell of DSC wilt gebruiken bouw je snel een slechte versie van Ansible).

Het probleem is grotendeels dat veel niet kan in PowerShell native en dus moet je nog steeds WMI en de registry aanspreken, maar dat is Microsoft zelf die dingen niet kan doen.

[Reactie gewijzigd door Guru Evi op 22 september 2024 16:35]

Ansible zou je kunnen zien als tegenhanger van sccm/mecm. Niet als tegenhanger van wsus. Ansible en sccm/mecm doen de automatisering, aansturing en eventueel registratie en rapportage.

wsus zie ik meer als cache systeem voor de patches. De wsus server haalt de patches op bij microsoft en de systemen in het rekencentrum halen de patches van de wsus server.
Wsus is behalve caching ook management.
Je kunt systemen onderverdelen in groepen en vervolgens updates goedkeuren voor die groepen.

Ik beheer een zwik servers die aan WSUS hangen en automatisch alles installeren wat goedgekeurd wordt. Het alternatief is handmatig de updates aanzwengelen op een tijdstip wat me uitkomt, maar zoals het nu werkt keur ik 's morgens de updates goed en draaien alle systemen volautomatisch de updates erdoor in de avond.
Dit heeft niet zozeer met on-premise (of het afschaffen ervan) als zodanig te maken. Je kan nog altijd WSUS/Patch Management on-premise doen met bijvoorbeeld SCCM/MECM, die je zowel on-premise als in de cloud kunt draaien.

Die gebruikt onderwater ook deze zelfde tool, maar deze blijft wel gewoon ontwikkeld en support worden.

Het gaat bij WSUS om een reeds 20 jaar oude tool die eigenlijk qua capabilities een beetje achterhaald is geraakt ten opzichte van andere tooling, ook al functioneert het naar behoren snap ik wel dat men er qua nieuwe functionaliteit de stekker uit trekt.
De basis van patchmanagement via sccm is WSUS, die draait op de achtergrond, SCCM legt er een beheerschil overheen/tegenaan.
Ja nou nee dus, sccm trekt de updates via wsus naar zich toe, gebruikt wsus zo ongeveer om de lijst van updates te downloaden.

De updates gaan vervolgens een sccm package in.

Als ze sccm direct aan de updates hangen, en dat is relatief simpel, dan is heel wsus niet meer nodig.

Teveel mensen hier denken dat omdat wsus wordt geïnstalleerd op je primaire update deployment point dat het alles op de achtergrond nog doet, dit is verre van correct.

Waarschijnlijk nooit met sccm gewerkt of het puur op 1 locatie laten draaien. Sccm is meer bedoeld voor bedrijven met heel veel clients en geeft buiten update deployment en caching nog een berg aan extra features die wellicht soms licht leunen op hun gratis broertjes maar zeker niet hetzelfde zijn.
Meer en meer wordt van Microsoft uit naar Intune geduwd. Zou me niet verbazen dat SCCM binnenkort ook niet meer zal werken, het is nu al enorm achteruit en verdere ontwikkeling staat al een paar jaar stil, Windows 11 kun je bijna volledig beheren zonder SCCM.

Ideaal zou natuurlijk SCCM en WSUS omzetten naar een on-prem MDM met een slimme cache voor een package server (Windows updates via NuGet) maar dat zie ik niet gebeuren, er is teveel afhankelijk van custom troep dat zelfs Microsoft niet meer verstaat in het Windows ecosysteem.

Het probleem met al dit cloud gedoe is natuurlijk beschermde netwerken, waar je een filter wilt tussen de buitenwereld moet je nu alsnog een gat slaan in de firewall en volledig toegang naar alles in Azure en O365 geven.

[Reactie gewijzigd door Guru Evi op 22 september 2024 16:26]

Gezien de meest recente ontwikkelingen op Azure windows licenses (lees: extreem duur) zie je steeds meer overschakeling op Linux server toepassingen. Voor zover men daar ook niet mee bezig was.

En dan heb je nog Windows desktop. Ja dat is nu nog extreem populair, wegens gebrek aan anders. Maar Linux desktop wint gestaagd aan populariteit. Niet in de minste plaats door features als recall, uitgebreide telemetry, verplichte windows online accounts, etc etc.

Windows sterf een langzame dood en gezien de werk- en denkwijze die ze aan te lijken willen houden verwacht ik niet dat ze dat kunnen keren. Maar ik zie ook nog wel een periode komen dat alles cloud op z'n retour gaat. Ik heb het al eerder gezien met uitbestede IT die weer in-house werd gehaald en nu weer naar de cloud gaat inclusief de uitbesteding. Totdat kritische processen ineens weer in-house moeten komen of naar Europa wegens privacy/security wetgevingen.
Het probleem in principe is de NT kernel en de oplossing is een NT runtime in containers zoals Docker stoppen. Ze kunnen het wel degelijk intern in Azure; VDI loopt echt niet in een dikke VM, maar verkopen aan de klant willen ze niet doen want dan is hun cloud dienst in gevaar.
LOL. 8 jaar geleden zei een architect al eens tegen mij dat SCCM dood is en Intune de toekomst is.
Nu 8 jaar verder is het tegenovergestelde nog steeds het geval.
SCCM wordt nog steeds doorontwikkeld, werkt veel beter, en Intune blijft maar achter de feiten aanhobbelen.
Van het begin af aan zeg ik al dat Cloud-only gedoomd is te mislukken, en dat is gewoon nog steeds zo.
Hybrid blijft in de praktijk de enige juiste keuze!
De wsus is ook meer voor kleine omgevingen te beheren en voor grotere zijn de cloud alternatieven of andere (offline) producten een betere keuze.

Los daarvan zal er zeker nog support zijn tot 2035, vermoedelijk langer.
Natuurlijk kunnen we stellen dat de tools al lang bestonden maar dat is niet relevant. Het gaat om de intentie. Die is niet duidelijk het de gebruikers van on-prem diensten makkelijker maken vertrouwde tools te blijven gebruiken. De intentie is eerder het makkelijker maken om de cloud diensten te kunnen beheren. Dat is niet zomaar alleen bedoeld om ook on-prem nog behoorlijk te ondersteunen. Zeker niet als ze al meerdere tools die breed gebruikt werden stoppen. Dat gaat ook om als Microsoft proberen meer te investeren en verdienen aan cloud diensten en kosten besparen op on-prem klanten. Nieuw is zo niet zomaar even goed of beter voor on-prem gebruik.
Ergens voor Microsoft perfect want je wordt geforceerd om van hun cloud oplossingen gebruik te maken als je deze functionaliteit wil.
Iedereen wordt hiertoe geforceerd. Het zijn alleen sysadmins die zometeen niet meer de vrijheid(?)/mogelijkheid hebben om op eigen houtje te bepalen of een update wel geschikt is voor de pc's in het netwerk.

Ik vind het wel een goeie zet, want is 1 systeembeheerdertje nou echt in staat een update te beoordelen die Microsoft al met een legertje testers helemaal doodgetest heeft? Niet lullig bedoeld verder, gewoon realistisch.
die Microsoft al met een legertje testers helemaal doodgetest heeft? Niet lullig bedoeld verder, gewoon realistisch.
Toch is het al regelmatig voorgekomen dat patches servers (ernstig) overhoop haalde. Je hebt gelijk, een enkele systeembeheerder kan niet alles testen, maar dat hoeft ook niet. Simpelweg met oa. WSUS patches gefaseerd uitrollen (minder kirtische system eerst) om te kijken of er toch iets omvalt voor je de rest doet is vaak genoeg.
Dat kan prima zonder wsus.
Met GPOs kan je idd instellen op welke dag updates automatisch geïnstalleerd moeten worden. Als je dan snel genoeg bent als updates op woensdag problemen geven kan je het nog uitzetten op de systemen die gepland staan voor het weekend.

Ik heb liever iets als WSUS, waar ik zelf bepaal welke update op welk systeem wordt toegepast en waarbij de systemen automatisch volgen.
[...]


Iedereen wordt hiertoe geforceerd. Het zijn alleen sysadmins die zometeen niet meer de vrijheid(?)/mogelijkheid hebben om op eigen houtje te bepalen of een update wel geschikt is voor de pc's in het netwerk.

Ik vind het wel een goeie zet, want is 1 systeembeheerdertje nou echt in staat een update te beoordelen die Microsoft al met een legertje testers helemaal doodgetest heeft? Niet lullig bedoeld verder, gewoon realistisch.
Dat leger van Microsoft kent mijn omgeving niet. Alle patches moeten eerst door onze eigen teststraat en dan worden alle bedrijf kritische applicaties getest. Daar zitten applicaties tussen die speciaal voor ons gemaakt zijn. Ik ben al applicaties tegen gekomen die niet meer werkten na een patch van Microsoft. Daar moeten we dan wat mee. We hebben dus al patches tijdelijk niet uitgerold op bepaalde machines, omdat het geen optie was om de applicatie niet te laten werken. Dat we de applicatie vervolgens hebben aangepast, zodat de patch alsnog kon worden uitgerold is een andere. En voor de mensen die nu roepen, dat dat niet veilig is. Nee, dat klopt. Maar ik krijg het ook niet uitgelegd als het bedrijf stil ligt of bijvoorbeeld de salarissen niet uitbetaald kunnen worden. Soms is het kiezen tussen twee kwaden.
Nee dat is niet realistisch. Dat legertje van Microsoft heeft namelijk *NIET* mijn maatwerksoftware in mijn datacenter draaien en heeft dit dus *NIET* getest. Dat doe ik dus toch graag echt eerst even zelf. Natuurlijk ga ik niet de integratietest van de patch in het OS zelf overdoen, maar wel de hele regressietest van *MIJN* applicatie op de nieuw gepatchte ondergrond van MIcrosoft. Dat kan MS nooit zelf, het zou fijn zijn als dat gewoon mogelijk blijft.
Okay, fair enough, maar dat kan toch ook zonder WSUS?
Systeembeheerders moeten zelf testen. Microsoft doet echt niet veel integratietests en er zijn altijd applicaties en hardware die niet goed werken, zelfs van bekende merken. Tegen dat de laatste versie van Windows Update gecertificeerd is zijn we meestal een half jaar verder. Het model dat Linux gebruikt is hier beter in, compatibele drivers zitten in de kernel en voor de rest is er DKMS en behalve met grote versie updates is de interface stabiel.
1 systeembeheerdertje heb ook de tijd daar niet voor
Ja net als bijv Office pakket, word ook nog maar 5 jaar ondersteund. Echt met alles merk je het dat je naar die @$#Q!@#(@!( cloud moet.
Volledig me eens, doet me denken een de nieuwe Office 2024 waarbij Microsoft toch eigenlijk een soort van dringend adviseert om tòch maandelijks te betalen. :?
De vervanger is Azure Update Manager die tot 4,50 per server per maand kost.
Bor Coördinator Frontpage Admins / FP Powermod @svenk9122 september 2024 13:29
Microsoft is al tijden bezig om zo veel mogelijk naar Azure te pushen met een abonnementverplichting. Dat levert nu eenmaal veel meer op; min of meer gegarandeerde periodieke inkomsten zijn vaak interessanter dan eenmalige betaling. Die 4.50 per server per maand kan in sommige omgevingen behoorlijk aantikken, zeker gezien dit veelal los is van de andere abonnementsdiensten die je bijna wel moet nemen.
En abonnementen zijn moeilijker in te schatten dan 1 malig aankoop.
Beetje abo telefoon idee.
Schijnt dat als je Defender P2 neemt, de update licentie er bij in zit. Zelf nog niet onderzocht maar die business case is voor veel bedrijven niet te negeren.

Dat je over 2 jaar een forse verhoging krijgt van je maandelijkse kosten is natuurlijk bij voorbaat al te voorspellen ;)
Toch is dit model veel fijner voor de klant, omdat je dan opex kunt kopen en veel beter kunt schalen. Dit maakt de administratieve rompslomp veel minder.
Ja dat was een leuke "verassing" met ruim 1000 servers die elke maand gepatched moeten worden. Tools als DattoRMM, N-able of zelfs Ansible zijn velen malen goedkoper.
Is WSUS sowieso niet draak met zoveel servers?
Bor Coördinator Frontpage Admins / FP Powermod @Tweakert202022 september 2024 13:44
Nee hoor, waarom zou dat zo zijn? Je kan werken met groepen, regels instellen, updates voor losse groepen goedkeuren, automatisch laten patchen of alleen patches aanbieden etc. Wat SCCM / MECM gebruikt voor het uitrollen van patches, ook in grote omgevingen is ook gewoon WSUS.
WSUS zelf niet, maar de rapportering die eruit komt is nu niet direct modern of flexibel te noemen.
Valt mee. Je moet er wel tegenaan scripten, wij schonen bijvoorbeeld maandelijks de cache van alle servers op voordat de updates binnenkomen. Als je dat overlaat aan WSUS zelf (of niks doet) loopt het binnen enkele maanden spaak.
Dit is dan ook de enig reden van Microsoft, nog meer maandelijkse abonnementjes binnenharken :(

Als je de licentie uitgaven van 10 jaar gelden bekijkt en vergelijkt met die van vandaag sla je gewoon steil achterover.

[Reactie gewijzigd door klakkie.57th op 22 september 2024 14:43]

Is dat niet met alles zo? Boodschappen, woningmarkt etc?
Exact om deze reden is het gebruik van wsus nog populair. Eerst was Azure update manager gratis, nu per server betalen.

Tja vanuit een business case is het hier een nobrainer ook al heeft AUM wel extra functies.
Van wat ik heb begrepen was WSUS o.a. bedoeld om eenmalig updates van het internet te downloaden en via een interne server te verspreiden. Hierdoor werd je internet minder belast.
Als je nu naar een cloud oplossing wordt gedwongen, dan raak je die voordelen toch kwijt?

En waarom heeft MS zelf al 4+ verschillende tools om hetzelfde te doen? :?
Ik zou het wel fijn vinden om een intern distributiepunt te houden. Genoeg servers die helemaal nooit naar het internet mogen, daar ook helemaal niets te zoeken hebben, niet eens een default route krijgen en dat houd ik heel erg graag zo.
Deze functie zit tegenwoordig ingebakken in Windows Update en die heet Delivery Optimization.
Deze kan het van andere Windows machines trekken. Dus wat dat betreft is een dedicated wsus server ook niet meer nodig.

Link; Choose network sharing options for Delivery Optimization - Microsoft Support
Een beetje server zit niet in hetzelfde vlan als andere servers. Je zult gewoon een fw regel moeten maken om een update server te benaderen. Je wilt echt niet tussen alle vlans poorten open zetten om een paar updates te ontvangen.
Goed punt. Ik bekeek het enkel vanuit de werkplek-perspectief.
Ik had het dus ook over Windows 10/11, waar het artikel ook naar verwijst, niet over Server.
Ik ben bij Windows NT 4.0 gestopt.
Dan heeft u veel gemist, maar dat maakt niks uit. Zo had ik rond 2000 eens een versie van BEOs die niet verder kwam dan die je cd er in moest steken waarmee die was opgestart.
Ik heb ook vast veel gemist, maar dat maakt mij ook niks uit.
Volgens mij is het gewoon goed nieuws als de wsus server geen nieuwe functies krijgt. Zolang ze zelf maar de patches van microsoft kan ophalen en in het rekencentrum verder kan verspreiden. Meer hoeft ze niet te doen. Minder ook niet.

Veel extra functies zitten in extra servers zoals sccm/mecm, mdt en dergelijke. Die pretenderen wel de patchs te versturen maar gebruiken daar nog steeds een wsus server (of wsus service/deamon) voor.

Grotere rekencentra zullen niet snel de servers zelf rechtstreeks de patches bij microsoft laten ophalen. Veel servers kunnen/mogen niet rechtstreeks of via een netwerk-proxy naar internet. En als het om de delivery-optimization gaat om de patches intern te verspreiden: Veel servers mogen ook niet zomaar met elkaar contact hebben.
Ik heb maar een maand het beheer overgenomen omdat iemand op vakantie was. En het was allemaal niet echt goed geregeld.
Maar als ik me niet vergis hadden ze z’n vijf jaar geleden daar toch aparte groepen aan gemaakt waarmee je dan een soort piloot kon doen.
PSWindowsUpdate scriptje en klaar, aie to!
WSUS was toch altijd al een log apparaat.
Als je een Powershell scriptje gaat gebruiken die windows update aftrapt als vervanger van WSUS, dan heb je duidelijk geen besef waar je WSUS voor gebruikt en hoort te gebruiken.

Dat powershell scriptje kun je dan net zo goed vervangen door een GPO die de instellingen gewoon hard vast zet.

Op dit item kan niet meer gereageerd worden.