[English]Microsoft hat gerade das Ende der Weiterentwicklung seines Windows Server Update Services (WSUS) angekündigt. Damit geht eine Ära zu Ende, wenn auch das Ende des bei Administratoren seit Jahren im Einsatz befindlichen Verwaltungstools für Updates lange zu erkennen war.
Anzeige
Windows Server Update Services (WSUS)
Windows Server Update Services (WSUS) ist eine Softwarekomponente, die seit Microsoft Windows Server ab Version 2003 enthalten ist. Administratoren in Unternehmen verwenden den WSUS, um Updates zentral für Clients und Server zu verwalten. WSUS ist die Nachfolgeversion der Softwarekomponente Software Update Services.
Windows Server Update Services ist ein Client-Server-System, dass auf einer SQL-Datenbank (entweder über einen bereits vorhandenen MS-SQL-Server ab 2005 oder der mitgelieferten Windows Internal Database) des Servers aufbaut. Die Datenbank verwaltet die Versionsdaten der Aktualisierungen und die Berichte der Clients. Die Clients liefern einen Statusbericht an den WSUS zurück.
WSUS-Entwicklung eingestellt
Der Abschied vom WSUS kündigte sich ja schon länger an – Microsoft setzt auf Intunes und SCCM als alternative Lösungen. Im Juli 2024 hatte ich im Beitrag Microsoft beendet Treiber-Synchronisation im WSUS im April 2025 angekündigt, dass der WSUS nächstes Jahr eine Funktion verlieren werde.
Anzeige
Nun hat Microsoft im Techcommunity-Beitrag Windows Server Update Services (WSUS) deprecation das Ende der Produktentwicklung für WSUS angekündigt. Microsoft will "im Rahmen der Vision einer vereinfachten Windows-Verwaltung aus der Cloud den Windows Server Update Services (WSUS) abschaffen.
Konkret bedeutet dies, dass Microsoft keine neuen Funktionen mehr entwickeln und auch keine neuen Funktionsanforderungen für WSUS mehr akzeptieren wird. Das Ding ist damit faktisch tot – wenn auch seit Windows Server 2012 keine wirklichen Neuerungen mehr zum WSUS hinzukommen. Microsoft will jedoch die aktuelle Funktionalität des WSUS behalten und weiterhin Updates über den WSUS-Kanal veröffentlichen.
Die Abkündigung des WSUS hat aktuell keine Auswirkungen auf bestehende Funktionen oder Unterstützung für den Microsoft Configuration Manager. Auch die WSUS-Rolle in Windows Server 2025 wird weiterhin verfügbar sein. Microsoft empfiehlt Unternehmen aber den Übergang zu Cloud-Tools. Das schließt Windows Autopatch und Microsoft Intune für die Client-Update-Verwaltung und Azure Update Manager für die Server-Update-Verwaltung ein. Zusammengefasst gilt:
- WSUS deprecated
- keine neuen Funktionen/Fähigkeiten;
- bestehende Funktionalität bleibt erhalten
- Updates werden weiterhin über WSUS veröffentlicht
- WSUS-Rolle bleibt in Server 2025
- Umstellung auf Autopatch, Intune und Azure Update Manager empfohlen
Anzeige
…und langsam schloss sich die Schlinge um seinen Hals….
Die Alternativen sind für viele keine Alternativen, da kostenpflichtig, teilweise Cloudgebunden, für kleinere Umgebungen oversized oder in der Handhabung zu komplex. Gut für viele ist auch der WSUS schon zu oversized und zu komplex, aber für die ändert sich ja auch nichts.
Ohne gesteuerte zentrale Update Verteilung im eigenen Netzwerk wird bei vielen die Internetleitung an ihre Grenze kommen wenn alle PCs zeitgleich die Pakete von MS herunterladen statt sie aus dem eigenen Netzwek zu beziehen.
Schon mal jemand ausgewertet wie gut die Update-Übermittlungsoptimierung funktioniert? Also die Funktion die in einem Netzwerk die Updates auch zwischen den Clients verteilt und so nicht jeder Client jedes Downloadpaket von MS ziehen muss?
Wir machen das seit Windows 10 1607 und das funktioniert echt gut. Der wsus hat bei uns nur ganz am anfang ein bischen load und dann verteilt sich das im netz.
Klar requests sieht man trotzdem zum wsus, der client will ja wissen was man herunterladen muss.
Genau die Clienten einfach auf Übermittlungsoption = "nur im LAN" stellen damit die sich die Updates nicht mit extern sharen (default Einstellung)
Das ganze funktioniert gut mit Client OS ab Win 10
und Office Updates die "C2R" sind (egal ob per SCCM verwaltetet oder nicht)
"Klassische" Office Updates (da gibt es ja jetzt nur noch das 2016 das noch Updates bekomment) funktionieren damit scheinbar nicht. Die 2016 Updates zieht sich der Client immer komplett von der Quelle.
Microsoft will einen einheitlichen Qualitätsstandard einhalten. Da sind gut funktionierende Produkte fehl am Platz.
Es gibt gute und brauchbare Alternativen zu Microsoft, die sich über Jahre bewährt haben.
Heute gibt es fast keine zwingenden Gründe mehr, einen Wechsel nicht vorzunehmen.
Muß jeder selbst entscheiden (lassen). Bei mir spielt Microsoft keine nennenswerte Rolle mehr. Ist noch eine Spiele-Plattform (privat), sonst nichts. Jedwede Server-Tätigkeit wird schon von alternativen Produkten erledigt, egal auf welchem System (von klein bis groß, von ARM bis X86).
Immerhin belassen sie ja augenscheinlich die Funktionalität des WSUS. Daß die Treiber-Funktionalität entfleucht ist kein Fluch, eher ein Segen.
Der Großteil der dort vorhandenen Treiber war mies, ungetestet und in Kombination mit manuellen Treiberinstallationen inkompatibel.
WSUS und gut funktionierend?
Wenn man wenig Ahnung von Datenbanken und keine Erfahrung mit WSUS hat, kann man den WSUS so gut wie gar nicht betreiben.
Wenn man zu viele Produkte angeklickt hat, dauert die initiale Synchronisation einen halben bis ganzen Tag, müllt dann die Datenbank dermaßen zu, dass man laufend Skripte zur Optimierung braucht, weil die Datenbank nicht mehr vor dem Timeout antwortet.
Hat man einmal einen Fehler drin, kann man die Datenbank gleich wegwerfen und einmal neu syncen. Das kommt bei uns ca. 1x in 1-2 Jahren vor. Wenn man das System schlank hält, kann man es als stateless Proxy mit Verzögerungsfunktion betrachten, allerdings läuft man Gefahr, Updates auszulassen, weil man nicht alle schlecht und inkonsequent benannten Kategorien abonnieren möchte. Treiber sollte man ganz weglassen, weil das die Menge der Updates x-fach multiplizert.
Etliche Funktionen kann man mit Skripten nachrüsten, z. B. superseeded Updates oder die ganzen ARM64-Updates declinen – warum gibt es die nicht als eigene Kategorie?
Seit 2012 wenigestens Powershell-CMDlets gibt, mit denen man noch ein bisschen Skripten kann. Allerdings ist es schon ein bisschen armselig, was Microsoft da seit 12 Jahren "liegenlassen" hat. Der WSUS hat sich seit 2003 praktisch nicht verändert.
Ansible ist kostenlos, einfach zu bedienen und funktioniert einwandfrei.
Nutze schon einige Monate dieses Playbook https://spacepc.de/ansible-windows-update-playbook/
es gibt doch jetzt die tolle Übermittlungsoptimierung (englisch DeliveryOptimization) die regelt das ganze jetzt viel zuverlässiger… nicht?
🤡
Somit wird einen auch die letzte Möglichkeit genommen Updates zentral zu verwalten, jetzt sind wirklich alle dazu verdammt Microsofts Beta-Tester zu spielen.
Das kann ja nur richtig geil werden
es gibt seit ca 8(?) Jahren keine Änderungen mehr, seit 3.0 SP2 ist nicht passiert. nur weil er sich jetzt mit 4.0 meldet ist es ein 3.0 SP2.
traurig, aber es war abzusehen. aus MS Sicht ist es nur konsequent. Cloud und nichts anderes
Ist ja nett, G.Born erklärt den WSUS für tot und beerdigt ihn gleich.
Wenn der WSUS in Server 2025 drin ist, wird er auch für 5 Jahre mit Sicherheitsupdates versorgt und kriegt den Extended Support.
Das was der WSUS leistet, reicht für 99% aller Unternehmen völlig aus. Und das auch noch für sehr viele Jahre. Amen.
@Chris
Bei uns (~650 Clients + Server in 3 Standorten) wird immer noch auf den BITS in Sachen Übermittlungsoptimierung gesetzt, reicht uns und macht seine Arbeit. Mit der Übermittlungsoptimierung möchte MS einfach nur die Last von ihren eigenen Servern nehmen, wenn sich im Feld draußen die Clients die Updates holen, dann sollen sie das bei anderen machen, nicht bei den MS Servern.
Die Tatsache, daß für 24H2 "was anderes" kommt, heißt aber vermutlich, daß man perspektivisch zweigleisig fahren muß. Bei den M365-Applikationen ab 2019 ist es ja de facto schon so. Spätestens mit dem Supportende von Windows 10 werden vermutlich viele umschwenken (müssen).
Wieso W11 (auch 24H2) kommt aktuell normal über den WSUS
(Office 2016 C2R, ja gibt es, kommt ohne SCCM auch nicht über den WSUS)
ja, aber nicht als enablement package, sondern nur als Voll Update
das war wohl gemeint
enable packages gibt es ja nur wenn die Basis quasi gleich ist, das ist eh nicht der Standard.
Na ja, die Vergangenheit hat uns gelehrt, das MS seine Produkte durch Weiterentwicklungen und neue Funktionen sehr oft verschlimmbessert hat.
So kann die Einstellung der WSUS-Entwicklung auch positiv gesehen werden.
Entscheidend ist, dass
– die bestehenden Funktionen erhalten bleiben
– Updates weiterhin über WSUS veröffentlicht werden
– die WSUS-Rolle in zukünftigen Serverversionen erhalten bleibt (für Server 2025 ja der Fall)
Ist dieses nicht mehr gegeben, so bleibt bei uns als Alternative unsere UEM-Lösung
bzw. die integrierte Softwareverteilung. Da die Updates in der Regel auch nur einmal im Monat veröffentlicht werden und beim Betriebssystem kummulativ sind, ist der Mehraufwand eher gering.
Ein WSUS Server (dual homed) hat auch den kleinen Vorteil, das man die Clients komplett ohne direkten Kontakt zum Internet fahren konnte.
Wenn die sich ihre Updates jetzt direkt bei MS holen müssen reißt man ein erhebliches Loch in sein Firewall Konzept…
Alles wird gut
Das ginge auch über einen dual-homed (caching) Proxyserver, in IPFire ist er z.B. direkt inkludiert* (ist zwar eine Firewall-Distri, muss man aber nicht als fw nutzen)), inkl. URL-Filter**, damit auch nur Updates darüber laufen können.
Mir persönlich fehlte viel mehr die zentrale Blockade/Freigabe von Updates.
* ipfire. org/docs/configuration/network/proxy/update_accelerator
** ipfire. org/docs/configuration/network/proxy/url-filter
ja, mit einem WSUS Server hatte man beides in einem System: Isolation und Kontrolle.
Da jetzt noch einen Proxy zu bauen, warten etc.
ja, kann man machen…
je mehr Layer desto größer die Angriffsfläche.
Es sollte immer 1. Prio sein:
K.I.S.S.
und es die Kunst des Ingenieurs, das zu erreichen.
Kompliziert kann jeder.
in
Nun, wenn ich nur zwischen gar nicht und "kompliziert" (ist es nicht, ist Peanuts) wählen kann, dann ist mir die "kompliziert"e Lösung weit lieber, als Keine.
Aber das können Sie gerne anders halten.
Vielleicht ein oder dein Firewall-Konzept.
Welcher Teil von "ist zwar eine Firewall-Distri, muss man aber nicht als fw nutzen" will Ihnen nicht eingehen? Eine IPFire kann man problemlos als reinen Proxyserver betreiben, ohne Firewall, ohne traffic shaping und was sie sonst noch so bietet. Eine VM bietet sich dafür geradezu an.
Man kann natürlich einen caching squid o.Ä. auf Linux aufsetzen, dann hat man eben statt einfacher (nahezu selbsterklärender) GUI die Komplexität und Lernkurve, die @Pau1 aus verständlichen Gründen vermeiden will.
"SCCM als alternative Lösungen."
Verwendet der SCCM nicht den WSUS als Unterbau?
Genau das habe ich mich auch gefragt. Bzw ja, SCCM verwendet die WSUS Datenbank / Infrastruktur .
Ich kann mir nicht vorstellen, dass die das nochmal in dem Umfang anpassen und das vollständig in SCCM integrieren.
SCCM wird ja nicht stehenbleiben. WSUS war schon immer Schrott. Allein die Datenbank-Engine im WSUS ist doch ein Witz von 1997.
WSUS mit WID sollte man nicht verwenden, das ist schnarchlahm. Für kleine bis mittelgroße Umgebungen hat meistens MS-SQL-Express gereicht und war wesentlich performanter, selbst wenn beides auf einem Server lief.
Ich bin ja wirklich kein MS-Fan, aber was soll "WSUS war schon immer Schrott."?
Es macht seinen Job und spart viel Aufwand, erlaubt insb. die selektive und/oder zeitversetzte Anwendung von Updates.
Empfehlen Sie doch wenigstens ein besseres gratis Tool, dann wird das ein produktiver Beitrag.
@Matthias
Wenn man sich mit der Materie nicht auskennt und auch nicht beschäftigt, kommt man natürlich schnell zu Aussagen wie deiner. Das Gegenteil ist der Fall.
Und WID ist meist schneller als Express, da es eine vollwertige SQL Server Instanz ist, mit Einschränkungen im Handling. Keine Verbindung von außerhalb des Localhost. Ein paar Indexe erstellen, schon läuft die SUSDB in der WID auch viel schneller.
Microsoft sieht den Azure Update Manager als Ersatz für WSUS im Serverbereich.
Kostet auch "nur" schlanke 60 $ pro Server pro Jahr …
Da die Mircosoft Updates ja so gut und toll getestet sind ist es auch gar nicht notwendig ein Konzept zu fahren in dem man Test und Produktiv hat…
Ganz ernst gemeinte Frage, was nimmt man den jetzt als Ersatz? Cloud ist tabu, SCCM und ConfigMgr zu teuer. Clients ins Internet lassen, ebenfalls tabu. Wie löst man das?
Da die WSUS-Rolle auch in Server 2025 noch erhalten bleibt, darfst du drei mal raten…
Erst mal gar nicht, da der WSUS die nächsten Jahre noch funktionieren wird…
Moin,
managed engine ist für 25 Geräte frei nutzbar.
Nicht ganz einfach zu nutzen aber für kleine Unternehmen ggf. eine Option.
Opsi mit Abos wäre eine Lösung aber gehen auch schon gute Taler über den Tisch.
Beim WSUS gabs ja nur zwei Zustände, entweder das lief seit Jahren ohne Probleme oder spackt andauernd rum.
Je nach Größe der Firma, würde ich aber den Internetanschluß größer machen. Die Cloudlösung ist nett und funktioniert, aber halt teuer und man hat wieder monatliche Kosten.
"Das Ding ist damit faktisch tot" – dann bin ich auch faktisch tot, denn dass ich mal sterben werde, ist bereits heute bekannt.
Nicht überdramatisieren. Die Upcoming Releases von Windows Client/Server und Office LTSC sind ja noch drin, also ist der Betrieb noch auf 5 bis 10 Jahre gesichert.
Wir haben seit mehreren Jahren ACMP (von Aagon) im Einsatz als WSUS Alternative.. Läuft recht gut mit 3.000 Clients.
Ich finde die WSUS Mails zunehmend treffsicherer als gedacht:
"WSUS: Warnung zu neuen Updates von …"
Es warnt vor Updates von Windows und Microsoft Produkten.
Wie wahr…. wie wahr…