142008

14.10.2021, aktualisiert um 09:22:46 Uhr

4111

WSUS einrichten

Moin(sen) in die Runde!

Ich bin dabei, WSUS einzuführen, habe mich auch eingelesen, aber einige Fragen sind noch offen.

1. Sollte ich WSUS als eigenständigen Server einrichten, also eine neue VM erstellen oder bei einer anderen Maschine mit drauf knallen?
Im Fall einer neuer VM: Wären 4 vCPUs und 12-16GB RAM in Ordnung oder ist das zu viel des Guten?

2. Wo ich ebenfalls nicht ganz durchblicke, ist was die Konfiguration angeht, im speziellen die Produktliste und Klassifizierung.

3. Ist es besser, die Clients nach Freigabe der Updates, diese selber von MS ziehen zu lassen oder besser direkt vom Server selber?

4. Sollten die anderen VMs ebenfalls vom WSUS ihre Updates erhalten oder doch besser direkt von MS selber?

5. Wie sieht's bei den Hosts selber aus?

So, das wär's erstmal!

Und wie immer THX für die Antwort(en) im Voraus und immer dran denken: JEDER hat mal klein angefangen, gell @aqui!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1387392168

Url: https://administrator.de/contentid/1387392168

Ausgedruckt am: 23.11.2024 um 13:11 Uhr

58 Kommentare

Neuester Kommentar

Zitat von @142008:

Moin(sen) in die Runde!

Mahlzeit

Ich bin dabei, WSUS einzuführen, habe mich auch eingelesen, aber einige Fragen sind noch offen.

schön

1. Sollte ich WSUS als eigenständigen Server einrichten, also eine neue VM erstellen oder bei einer anderen Maschine mit drauf knallen?
Im Fall einer neuer VM: Wären 4 vCPUs und 12-16GB RAM in Ordnung oder ist das zu viel des Guten?

Meiner läuft mit 2 vCPUs und 16GB RAM. (auch nur weil wir genug RAM haben ;)) Auf der VM läuft zusätzlich noch unter Anti-Virus (Trend Micro) und paar andere Sachen. Keine Probleme. Ich würde nur raten die WSUS DB auf eine andere Partition zu legen.

2. Wo ich ebenfalls nicht ganz durchblicke, ist was die Konfiguration angeht, im speziellen die Produktliste und Klassifizierung.

Du wählst halt aus für welche Produkte der WSUS die Updates laden soll.

3. Ist es besser, die Clients nach Freigabe der Updates, diese selber von MS ziehen zu lassen oder besser direkt vom Server selber?

Natürlich vom Server, sonst würde der WSUS ja keinen Sinn machen. ;)

4. Sollten die anderen VMs ebenfalls vom WSUS ihre Updates erhalten oder doch besser direkt von MS selber?

Kann man machen, muss aber nicht

5. Wie sieht's bei den Hosts selber aus?

Hyper-V Hosts? Die lasse ich persönlich direkt von MS beziehen

So, das wär's erstmal!

Hier noch eine nette Lektüre dazu: How To Install 2019

Und wie immer THX für die Antwort(en) im Voraus und immer dran denken: JEDER hat mal klein angefangen, gell @aqui!

Gerne ;)

Grüße

Hi,
schau mal wsus.de.

E.

Moin,

1. Ich pack den meistens auf den Management-Server, wo verschiedene Verwaltungskonsolen laufen, wie Virenscanner, etc. aber auch schon mal mit auf einem Printserver und selten auch auf einem DC (ich höre schon den Mob)- je nach Umgebung eben. Der WSUS muss also nicht zwingend einzeln betrieben werden.

2. Was blickst du da denn nicht?

3. Macht natürlich Sinn, wenn der WSUS die Updates herunterlädt und anbietet - ist ja einer seiner Hauptaufgaben. Somit spart man dann auch Bandbreite, wenn die Clients nicht alle einzeln zu Microsoft Update tingeln.

4. Natürlich auch vom WSUS. So kannst du dann auch den Internetzugriff der Server auch weiter einschränken, da diese dafür nicht ins Internet müssen.

5. Wenn du einen WSUS hast, so nutze ihn doch

Gruß

Von Winblows Klicki Bunti hab ich eh' keine Ahnung. 🤣 Wobei das aber auch ausreicht um Punkt 3. als zum Thread widersprüchlichen Unsinn zu erkennen. Der freundliche Bär oben hat es ja schon treffend bemerkt. Zum klein anfangen kommt also noch das logische Denken !

Moin,

ich frage mich grade ob du den Sinn des WSUs überhaupt verstanden hast. Der Sinn ist ja, dass du (a) deine Internetleitung entlastest und (b) zentral kontrollieren kannst, wann und welche Updates du verteilst. Wenn du dieses Grundprinzip verstanden hast, dann erübrigen sich 3 deiner 5 Fragen

Gruß
Doskias

Servus,

die Kollegen haben es ja schon hinreichend beschrieben.

Wir haben den WSUS ebenfalls auf einem Server mitlaufen. Bei uns ist es der SRV-Health, der noch die AV-Serverdienste und ein... zwei... andere kleinere Management-Applikationen beherbergt.
Der Server selbst (Win 2016) darf mit 8GB auskommen, sowie 4 vCPUs

WSUS-Content etc. liegen auf einer separaten Partition.

Ansonsten wird nur das an Produkten von MS synchronisiert, was bei uns auch im Einsatz ist.
Und nicht vergessen, zyklisch den Aufräumjob laufen zu lassen.
Dazu findet sich hier im Board aber zahlreiches.

Gruß
em-pie

Um Bandbreite zu sparen, können die Clients alles vom WSUS beziehen, aber Bandbreite ist in der heutigen Zeit wohl das kleinste Problem. Die primäre Aufgabe des WSUS sehe ich darin, und das ist meine persönliche Meinung, dass man die Updates kontrollieren kann.

Wenn ich die VMs und die Hosts selber von MS die Updates ziehen lasse, müsste es ausreichend sein, bei der Produktliste Win10 auszuwählen. Bei der Klassifizierung ist es ja nicht ratsam, alles anzuklicken. Ich wollte nur wissen, was ihr da ausgewählt habt.

Auf wsus.de war ich als erstes.

Ich sag's immer wieder: Man muss ihn gern haben, unseren @aqui!

Zitat von @aqui:
Wobei das aber auch ausreicht um Punkt 3. als zum Thread widersprüchlichen Unsinn zu erkennen

Punkt 3 kann Sinn machen!
WSUS hat im Kern 2 Aufgaben:

Download-Cache
Verwaltung der freigegeben Updates

Man kann einen WSUS auch nur für Punkt 2 verwenden und die Updates immer direkt von Mutti laden lassen. Der Client wird sich dabei nur die für ihn freigegebenen Updates herunterladen.

E.

Sehe ich genau so wie @emeriks und deswegen meine Frage.

Wer hat da wohl etwas nicht ganz verstanden @aqui?

Zitat von @142008:
Um Bandbreite zu sparen, können die Clients alles vom WSUS beziehen, aber Bandbreite ist in der heutigen Zeit wohl das kleineste Problem. Die primäre Aufgabe des WSUS sehe ich darin, und das ist meine persönliche Meinung, dass man die Updates kontrollieren kann.

Bandbreite ist leider in ländlichen Gebieten immer noch ein Problem. Ich kenne Außenstellen vom Rathaus (Bauamt, Kläranlagen, etc.) die sind so weit weg, dass sie nur via Funk/Satellit angebunden sind. Da hast du dann teilweise (leider 2021 wirklich noch war) knapp 3 Mbit. Und dafür zahlst du dann schon 200 € weil sich kein anderer Anbieter findet. Und dann sitzen da 30 Leute im Bauamt, weil der Kauf des Standortes vor 20 Jahren so günstig war. Und das ist leider kein Einzelfall. Sofern du dich in den Bereich des Öffentlichen Dienstes begibst, wirst du sowas immer wieder finden. Ich wünschte du hättest recht und Bandbreite spiele keine Rolle mehr, aber etwa jeder vierte WSUS den ich installiert habe, ist ein zweiter WSUS an einem anderen Standort um die Leitung zu entlasten.

Zitat von @142008:

Um Bandbreite zu sparen, können die Clients alles vom WSUS beziehen, aber Bandbreite ist in der heutigen Zeit wohl das kleinste Problem.

Speicherplatz ist das wohl noch kleinere Problem ;) Ich wüsste nicht, warum der WSUS nicht die Updates anbieten sollte - außer eben Speichermangel.

Die primäre Aufgabe des WSUS sehe ich darin, und das ist meine persönliche Meinung, dass man die Updates kontrollieren kann.

Richtig.

Wenn ich die VMs und die Hosts selber von MS die Updates ziehen lasse, müsste es ausreichend sein, bei der Produktliste Win10 auszuwählen.

Warum sollte man die Server denn nicht vom WSUS bedienen lassen? Das macht in meinen Augen keinen Sinn. So fehlt dir dann doch die Kontrolle über den Patchstand der Server. Und wenn du sie doch über den WSUS nur verwalten willst, musst du auch die entsprechenden Produkte anhaken

Bei der Klassifizierung ist es ja nicht ratsam, alles anzuklicken. Ich wollte nur wissen, was ihr das ausgewählt habt.

Für gewöhnlich nehme ich alles außer Treiber und Treibersätze.

@Doskias
Leuchtet ein und ist ein bekanntes Dilemma, aber in unserem Falle ist Bandbreite nicht das Problem.

@142008:

Hallo.

Ich weiß, Eigenlob stinkt, aber dies hier:

WSUS 2016, wo werde ich die angeforderten Updates sehen?

könnte zumindest mittelfristig sehr, sehr wichtig werden. Viel Lesestoff, doch ich finde, es lohnt sich.

Viele Grüße

von

departure69

Ich bin gerade (testweise) am Einrichten einer neuen VM für den WSUS. Dem Teil gebe ich anfangs 3 vCPUs mit 12 GB RAM und erstelle eine virtuelle Platte mit 60GB. Zudem will ich eine zweite für die Updates erstellen. Wie groß sollte diese sein?

Zitat von @142008:

Ich bin gerade (testweise) am Einrichten einer neuen VM für den WSUS. Dem Teil gebe ich anfangs 3 vCPUs mit 12 GB RAM und erstelle eine virtuelle Platte mit 60GB. Zudem will ich eine zweite für die Updates erstellen. Wie groß sollte diese sein?

Kommt darauf an wie viele Produkte du anklickst zum Download. Aber 200GB würde ich pauschal schon mal machen.

Also nun doch lokal speichern? Bisschen genauer kannst du deine Pläne ruhig erläutern ;)
Wie LauneBaer schrieb, hängt das ja nun letztendlich von den Produkten und Klassifizierungen ab.
200GB halte ich auch erstmal für einen guten Wert. Nach dem ersten Sync siehst du aber auch die genaue Größe des Downloads und kannst dann ggf. die Platte noch erweitern.

Wie bereits geschrieben, es ist aktuell alles nur testweise, um zu 'spielen'. Ich habe der zweiten Platte erstmal 120GB verpasst. Notfalls kann ich sie immer noch erweitern. Ausgewählt habe ich bei den Produkten aktuell auch nur 'Windows 10' und bin am Erstsynchronisieren:

Die GPO ist auch erstellt, die auch passen sollte:

Aber bis jetzt ist noch kein Client (von den zweien zum Testen) unter Computer bzw. Clients aufgeführt:

Na ein Client hat sich schon gemeldet. Stell den Filter einfach mal auf "Alle".
Dann empfehle ich beim alternativen Downloadpfad ebenfalls noch deinen WSUS einzutragen. Da gibt es sonst manchmal Probleme. Dann solltest du über eine automatische Genehmigungsregel nachdenken.
Und für Windows 10 solltest du für aktuelle Builds "Windows 10, version 1903 and later" anhaken. Nur mit Windows 10 bekommst du keine Updates mehr.

Zitat von @ArnoNymous:
Dann solltest du über eine automatische Genehmigungsregel nachdenken.

Vor allem hier solltest du gut darüber nachdenken. Wenn du die Updates automatisch genehmigst, dann gibst du ja wieder die Kontrolle über den Zeitpunkt der Installation ab. Wir haben einen Teil der Updates automatisch genehmigt (via PS-Skript). Ansonsten werde Updates erst nach frühestens zwei Tagen (händisch) freigegeben.

Zitat von @Doskias:

Zitat von @ArnoNymous:
Dann solltest du über eine automatische Genehmigungsregel nachdenken.

Vor allem hier solltest du gut darüber nachdenken. Wenn du die Updates automatisch genehmigst, dann gibst du ja wieder die Kontrolle über den Zeitpunkt der Installation ab.

Nö.

Zitat von @ArnoNymous:

Zitat von @Doskias:

Zitat von @ArnoNymous:
Dann solltest du über eine automatische Genehmigungsregel nachdenken.

Vor allem hier solltest du gut darüber nachdenken. Wenn du die Updates automatisch genehmigst, dann gibst du ja wieder die Kontrolle über den Zeitpunkt der Installation ab.

Nö.

Ich merk schon. Nicht mein Tag heute. ich formulier heute irgendwie sehr unpräzise.

Du hast natürlich recht. Den Installationszeitpunkt kannst du weiterhin per GPO festlegen. Was ich aber meinte war, dass er die Updates dann immer zu den Zeitpunkt installiert. Wir haben es zum Beispiel so regelt, dass Updates immer sofort installiert werden sollen, wenn sie freigegeben sind.
- Edge/Defender Updates werden automatisch täglich freigegeben
- O365 Updates werden mit 2 Tagen Verzögerung automatisch freigegeben
- Alle anderen Updates müssen händisch freigegeben werden
Das Konstrukt lässt sich nicht aufrechterhalten, wenn du eine automatische Genehmigung aktivierst, oder täusche ich mich da?

@142008:

Die 200 GB für den WSUS-Content kommen mir zu wenig vor.

Wir sind hier eine kleine Hütte, 12 Server, 40 PCs/Notebooks für circa 35 Leute.

Klassifizierungen und Produkte sind in erster Linie wichtige Updates und Updates, keine Treiber. Windows 10, Windows 11, Server OSse 2012, 2012R2 und 2016, Office 2013-2019 und noch n' bißchen Kleinkram (vcredist und Konsorten). Wir haben außer für Definitionsupdates (MSE und Defender) keine automatische Genehmigungsregel (die nämlich alles seit Erscheinen des jew. Produktes auf Vorrat herunterladen würde und dadurch sofort die Platte/Partition füllen würde). Wir genehmigen erst am Patchday, was da so alles neu hereinkommt. Dadurch ist die Menge des WSUS-Content bis heute halbwegs schlank geblieben. Trotzdem sind auf den 320 GB, die ich dafür mal eingerichtet hatte, stets 180-200 GB belegt. Entsprechendes Aufräumen findet regelmäßig statt.

Ich weiß nicht, wie groß die Umgebung ist, die Du per WSUS versorgen möchtest, und wieviele versch. Produkte Du benötigst, aber 200 GB halte ich für zuwenig. Es ist zwar nicht schwierig, eine virtuelle Platte/Partition bei Bedarf zu vergrößern, aber es ist nervig, wenn man das öfter tun muß.

Viele Grüße

von

departure69

Zitat von @ArnoNymous:

Na ein Client hat sich schon gemeldet. Stell den Filter einfach mal auf "Alle".
Dann empfehle ich beim alternativen Downloadpfad ebenfalls noch deinen WSUS einzutragen. Da gibt es sonst manchmal Probleme. Dann solltest du über eine automatische Genehmigungsregel nachdenken.
Und für Windows 10 solltest du für aktuelle Builds "Windows 10, version 1903 and later" anhaken. Nur mit Windows 10 bekommst du keine Updates mehr.

Die beiden Test-Clients werden gelistet und beim alternativen Downloadpfad ist der WSUS-Server jetzt ebenfalls eingetragen.

Die Erstsynchronisation ist durch und es sind aktuell 771 Sicherheitsupdates und 84 wichtige Updates. Wie soll man denn wissen, was benötigt wird? 🤔

Das hatte ich bei den Klassifizierungen eingestellt (als Produkt nur Win10, Version 1903 and later):

Und wieso werden auch Updates aufgeführt, die für frühere Versionen als 1903 sind?

Sehe ich das richtig, dass ich nicht einstellen kann, dass WSUS nur x64-Updates zieht? Damit wäre das Ganze viel übersichtlicher.

Zitat von @departure69:

Ich weiß nicht, wie groß die Umgebung ist, die Du per WSUS versorgen möchtest, und wieviele versch. Produkte Du benötigst, aber 200 GB halte ich für zuwenig. Es ist zwar nicht schwierig, eine virtuelle Platte/Partition bei Bedarf zu vergrößern, aber es ist nervig, wenn man das öfter tun muß.

Als Produkt hatte ich nur 'Win10, Version 1903 and later' eingestellt und die Platte ist aktuell nur 120GB groß. Es sind auch nur um die 80-100 Clients, die versorgt werden müssten bzw. sollen.

Guten Morgen,

also ich würde dir noch empfehlen bei Klassifizierung auch "Updates" auszuwählen.
Und ja, der WSUS zieht sich ein Update immer in allen verfügbaren Versionen, also x64, x86 und ARM. (sofern es das gibt)

Klicke im WSUS links im Baum auf "Alle Updates" gehst und stell die Filter oben mal auf "Alle bis auf abgelehnte" und Status "Erforderlich" ein. Dann siehst du auch nur die Updates, die deine Clients brauchen.
Außerdem kannst du mit Rechtsklick auf Updates im Baum auch neue Updateansichten erstellen, z.B. nur Upgrades usw.

Grüße

@142008:

Wie soll man denn wissen, was benötigt wird? 🤔

Durch diese Filterung:

Und wieso werden auch Updates aufgeführt, die für frühere Versionen als 1903 sind?

Ich glaube, darauf hat man tatsächlich keinen Einfluß. Aber das ist ja auch nur ein Angebot. Der Synch. bezieht sich nur auf den Katalog und hat zunächst nichts mit dem späteren, tatsächlichen Download zu tun. Wenn Du keine automatische Genehmigungsregel hast (was ich empfehlen würde), und keiner Deiner W10-PCs was älteres als 1903 (das aber im Übrigen auch schon recht alt ist) braucht, werden die ja auch gar nicht von Deinen Clients angefordert bzw. im Abgleich nicht als erforderlich festgestellt und somit auch nicht heruntergeladen.

s sind auch nur um die 80-100 Clients

Wenig sind das nicht, wenn ich das mal mit uns hier vergleiche. Und Deine Server willst Du nicht per WSUS versorgen? Oder Microsoft Office?

Viele Grüße

von

departure69

Moin,

Ich halte 200GB für zu viel!

Wir, ca. 60 Server + 40Clients, mit einem MS Spektrum von Win 7 bis Win10 21H1 bzw. Server 2008 R2 bis 2016, div. MS SQL-Versionen etc, office 2013-2016. und wir haben einen Content von ca. 60GB.

Wichtig ist immer: regelmäßig den WSUS aufräumen lassen. Updates, die überall verteilt sind, muss man keine 2 Jahre vorhalten und mitschleppen.

Ferner lädt der WSUS nur das herunter, was freigegeben wurde. Beim Sync mit MS wird lediglich ermittelt, welche Updates freigegeben werden können!

Haltet den WSUS sauber und es bleibt überschaubar…

Ja die erst-Synchronisation bringt immer viel mit. Du siehst ja an deinem Bild hier, dass da Updates aus 2018-05 dabei Sind. WSUS kann dir bei jedem Update sagen ob deine Rechner es installiert haben oder nicht.

Sehe ich das richtig, dass ich nicht einstellen kann, dass WSUS nur x64-Updates zieht? Damit wäre das Ganze viel übersichtlicher.

Prinzipiell siehst du das richtig. Ich hab da mal was ähnliches als Anforderung gehabt. Hier mal ein Auszug aus meinem PS-Skript, angepasst für deine Anforderung:

$Updates=Get-WsusUpdate -Approval Unapproved | Select-Object -Property @{Name='Title';Expression={$_.Update.Title}}  
$update_id=get-wsusupdate -Approval Unapproved
$max=$updates.length
for ($i=0;$i -le $max;$i++)
{
if($updates[$i] -like "*for x86-based Systems*")  
    {
    $Update_id[$i]||Deny-WsusUpdate 
    }
}

Unser WSUS prüft nachts um 4 nach Updates, das Skript läuft morgens um 6 Uhr. In dem hier angepassten Fall würde das Skript also alle Updates ablehnen, die im Titel "for x86-basesd Systems" enthalten. Wir lehnen mit dem Skript zum Beispiel alles ab was Vorschau im Namen hat oder Edge-Beta, Edge-Dev, etc. Gleichzeitig werden aber zum Beispiel auch Edge-Stable-Versionen automatisch freigegeben.

Vergesst bitte nicht, dass das eine Testphase ist und ich deswegen nur Win10 als Produkt gewählt habe.

Bei uns gibt es keine Clients mehr, die nicht mit Win10 laufen und auch keine Office-Version, die unter 2016 läuft. Ebenso sind die Server aktuellerer Natur, nichts unter 2019.

Wenn ich mich mit WSUS angefreundet habe, werde ich mit Sicherheit andere Produkte darüber laufen lassen. Was die Server angeht, werde ich dann sehen.

Zitat von @142008:

Und wieso werden auch Updates aufgeführt, die für frühere Versionen als 1903 sind?

Liegt vermutlich daran, dass du die Erstsynchronisation mit "Windows 10" durchgeführt hast.
Allein durch Abhaken eines Produkts verschwinden die dann nicht mehr aus dem WSUS.

Unnötige Updates kannst du einfach mit Rechtsklick > Ablehnen selbst entfernen.
Die Bereinigung vom WSUS arbeitet da wirklich sauber.
Auch ist zu empfehlen, ersetzte Updates selbst abzulehnen. Dazu in der Updateübersicht den Reiter "Ersatz" einblenden lassen und dann alles, was Stufe 2 (ersetzt und wurde ersetzt) und Stufe 3 (wurde ersetzt) hat, kann einfach abgelehnt werden. So hält man die DB schön klein. Alternativ gibt es auch ein Skripte, die das erledigen.

Eine Anmerkung zum "erforderlich".

Darauf sollte man sich nur bedingt verlassen.
z.B.

Ein Update, welches man explizit verweigert hat, sei es bewusst oder aus Versehen, taucht dann nie mehr als "erforderlich" auf. Und weil man das "verweigert" nicht direkt wieder entfernen kann, muss man solche ein Update erst genehmigen und diese Genehmigung gleich wieder löschen, damit das Update dann wieder potentiell für "erforderlich" verfügbar wird.
Wenn man ein Update nur auf wenigen Clients benötigt, diese Clients aber oft unterwegs sind und das länger als das konfigurierte Intervall (ComputerDeletionTimeThreshold), dann melden sich diese Clients zu lange nicht mehr beim WSUS und werden deshalb u.U. aus der DB gelöscht. Dann verschwindet dieses Update auch aus dem "erforderlich".

O.g. gilt dann natürlich auch für ersetzende Updates, welche später reinkommen.

Außerdem gibt es keinen Filter nach "nicht erforderlich", sodass man darüber auch keine Revision ausführen kann.

Zitat von @LauneBaer:

also ich würde dir noch empfehlen bei Klassifizierung auch "Updates" auszuwählen.

Klicke im WSUS links im Baum auf "Alle Updates" gehst und stell die Filter oben mal auf "Alle bis auf abgelehnte" und Status "Erforderlich" ein. Dann siehst du auch nur die Updates, die deine Clients brauchen.

Der Haken bei der Klassifizierung ist jetzt gesetzt. Nachdem ich den Filter entsprechend gesetzt habe, werden weiterhin keine Clients (sind nur zwei Testclients) aufgeführt.

Bedeutet das nun, dass diese Clients up2date sind und aktuell somit keine Updates benötigen?

Zitat von @142008:

Der Haken bei der Klassifizierung ist jetzt gesetzt. Nachdem ich den Filter entsprechend gesetzt habe, werden weiterhin keine Clients (sind nur zwei Testclients) aufgeführt.

Bedeutet das nun, dass diese Clients up2date sind und aktuell somit keine Updates benötigen?

In der o.g. Ansicht zeigt er dir auch nur Updates und keine Clients an. Wenn du die Clients sehen willst musst du im Baum weiter unten auf Computer wechseln. Dort sollten deine 2 Clients auftauchen. Wenn du dort einen anklickst siehst du unten ob er Updates braucht. (aber vermutlich nicht, wenn er bisher von MS bezieht und erst seit kurzem mit dem WSUS redet)

Grüße

Na man würde hier aber die Updates sehen, die von min. einem Client angefordert werden.
Da bei dir nichts zu sehen ist, sind deine Testclients wohl aktuell, ja.

Die zwei Testclients sind sichtbar:

Zitat von @ArnoNymous:

Da bei dir nichts zu sehen ist, sind deine Testclients wohl aktuell, ja.

Hmm, ok! Dann muss ich mir mal einen Testclient suchen, der nicht up2date ist. 😐

Aber was genau bedeuten die Prozentangaben?

Das die doch nicht aktuell sind :P
Wenn du einen Client auswählst, kannst du unten, neben dem Kreisdiagramm, auf "Erforderliche Updates klicken und bekommst eine Übersicht mit den Updates, die hier noch fehlen.

Das geht nicht, da ausgegraut und 0 Updates erforderlich:

Klicke ich auf das Feld darunter, erscheint folgende Fehlermeldung:

Und wenn ich den Report Viewer installieren will, erscheint folgendes:

Auf dem Server ist kein SQL-Server installiert, nur das WID von der WSUS-Installation.

Installieren: https://www.microsoft.com/en-us/download/details.aspx?id=56041

Gibt noch viele Updates ohne Status, daher die Prozentanzeige. Such mal beim Client nach Updates und mach mal bei einem Client ein wuauclt /reportnow in die Kommandozeile.

Ja, der Report Viewer ist zum Betrachten der Reports notwendig und die WSUS-Rolleninstallation bringt diesen leider nicht mit

.

Du brauchst aber auch keinen SQL-Server, die einfache WID-Instanz genügt vollauf. Wobei diese rein technisch auch ein SQL-Server ist (man kann z. B. mit dem SQL-Managementstudio darauf zugreifen). Was Du hier nachinstallieren mußt, ist nicht ein SQL-Server, sondern bloß die "Microsoft System CLR Types für SQL Server 2012" (über Google müßten die zu finden sein). Danach kannst Du dann nochmal das Report-Viewer-Setup anwerfen.

Viele Grüße

@ArnoNymous:
Den Link hatte ich schon, nur welches soll ich davon installieren?

Beide Clients sind up2date und der Befehl zeigt/bewirkt nichts.

@departure69:;
Ich schaue mal, ob ich fündig werde.

Zitat von @142008:

@ArnoNymous:
Den Link hatte ich schon, nur welches soll ich davon installieren?

SQLSysClrTypes.msi

THX, die Installation hat geklappt und auch ein Bericht konnte generiert werden:

Was ich aber nicht so ganz verstehe, ist, wieso ich auf dem Client direkt keine Updates angezeigt bekomme, aber über den WSUS schon.

Ich habe vor, den WSUS-Server über Veeam zu backuppen, aber das Backup soll eine Größe von 180GB haben. Noch wurde aber nichts geladen.

Wie macht ihr das? Backupt ihr den WSUS-Server ebenfalls? Falls ja, komplett oder lasst ihr die Festplatte mit den Downloads außen vor?

Der Client zeigt Dir nur an, was für ihn explizit genehmigt wurde. Der Bericht sagt Dir aber: "Nicht genehmigt".
Der Bericht ermittelt die fehlenden Updates nicht nach den Genehmigungen, sondern nach der Verfügbarkeit.

Zitat von @142008:

Was ich aber nicht so ganz verstehe, ist, wieso ich auf dem Client direkt keine Updates angezeigt bekomme, aber über den WSUS schon.

Wie emeriks schrieb.

Ich habe vor, den WSUS-Server über Veeam zu backuppen, aber das Backup soll eine Größe von 180GB haben. Noch wurde aber nichts geladen.

Wie macht ihr das? Backupt ihr den WSUS-Server ebenfalls? Falls ja, komplett oder lasst ihr die Festplatte mit den Downloads außen vor?

Ich sichere den WSUS selbst nicht. Der Dienst ist schnell wieder eingerichtet und Updates zu sichern finde ich auch unsinnig. Kostet nur Speicher und Zeit.

Zitat von @ArnoNymous:
Ich sichere den WSUS selbst nicht. Der Dienst ist schnell wieder eingerichtet und Updates zu sichern finde ich auch unsinnig. Kostet nur Speicher und Zeit.

Doch, die DB solltest Du schon sichern. Da reicht ein B2D über VSS und frisst kein Heu, spart aber viel Zeit bei der Wiederherstellung.

Ich habe das Problem, dass sich zwei weitere Test-Clients nicht beim WSUS-Server anmelden bzw. nicht angezeigt werden. Laut 'rsop.msc' sollten die Clients erfolgreich an WSUS angebunden sein und die Einstellungen in den Gruppenrichtlinien greifen.

Selbst ein gpupdate /force und anschließendes wuauclt.exe /reportnow /detectnow mit einer Wartezeit von 10 Minuten haben nichts bewirkt.

Am Freitag konnte ich erst nach einigen hin und her einen Notebook dazu bringen, sich mit dem WSUS zu connecten. Das kann es aber doch nicht sein! 🤔

Wenn ich mich nicht blind drauf verlassen kann, dass sich die Clients am WSUS anmelden, kann ich das Ganze auch gleich sein lassen und die Clients können sich die Updates selber, wie bisher, automatisch ziehen. 🙄

Hi,

das kann durchaus etwas dauern bis sich die Clients beim WSUS melden.

Probier mal folgendes in der Kommandozeile: (auf einem der Clients die sich nicht melden)

c:\windows\system32\UsoClient.exe startscan

Soweit ich mich erinnern kann, funktionieren die ganzen wuauclt.exe Kommandos ab Windows 10 nicht mehr. (kann mich aber auch vertun)

Ich hatte früher immer folgendes benutzt, weiß aber nicht 100%ig ob das noch funktioniert:

net stop wuauserv
rd /s /q %windir%\softwaredistribution
net start wuauserv
wuauclt /resetauthorization /detectnow
wuauclt /detectnow
wuauclt /reportnow

Grüße

Ja, angeblich soll ab Win10 nur noch der folgende wuauclt-Befehl funktionieren: wuauclt /resetauthorization /detectnow, was aber auch nichts gebracht hat. Den 'neuen' Befehl usoclient.exe habe ich bereits auch durch. Ebenfalls ohne Erfolg und gewartet habe ich über 2h. Selbst die Clients habe ich im DC aus der OU geschmissen und neu eingefügt. An einem Client könnte ich es verstehen, aber mittlerweile sind es drei Test-Clients, die sich alle beim WSUS-Server nicht melden wollen.

Moin,

wie LauneBaer schon schrieb:

net stop wuauserv
rd /s /q %windir%\softwaredistribution
net start wuauserv
wuauclt /reportnow

Das funktioniert auch noch bei Win10 (detectnow dagegen nicht mehr) und behebt 90% aller Probleme.

Ich habe jetzt folgendes von hier ( https://www.security-insider.de/wsus-tipps-zur-fehlersuche-und-fehlerbeh ... ) ausprobiert und falls das auch nicht helfen sollte, werde ich das obige austesten.

Weder das Eine noch das Andere hat eine Änderung bewirkt. Ich habe jetzt als letztes den WSUS-Server neu gestartet, in der Hoffnung, dass es irgendwie an diesem hängt.

Hämmere mal einem der betroffenen PCs in einer administrativen CMD "wuauclt /reportnow
" ein. Ganz viele Male. Irgendwann tut sich was. Garantiert. Ich hatte das auch schon, war aber am Ende nie ein Problem, wie gesagt, irgendwann erscheinen sie.

Viele Grüße

von

departure69

Den Befehl habe ich jetzt bestimmt ca. 20x an den zwei nicht gemeldeten Clients eingehämmert, aber geändert hat es nichts.

Ich stehe kurz davor, den WSUS-Server wieder komplett zu löschen......🤨

Ich stehe kurz davor, den WSUS-Server wieder komplett zu löschen......🤨

Wenn der Schlüssel am Auto nicht funktioniert, das Auto dann wieder zu verkaufen hilft ungemein

Was steht in der C:\Windows\SoftwareDistribution\ReportingEvents.log
Was gibt das Eventlog her?

Was steht unter
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\WindowsUpdate

WUServer
WUStatusServer

Taucht bei beiden RegEinträgen dein WSUS-Server auf?

ReportingEvents.log ist zwar von heutigem Datum, aber leer. Folgendes steht in der Ereignisanzeige und die Reg-Einträge sind ebenfalls vorhanden:

Witzbold! Was steht steht denn im Eventlog? Dein Screenshot zeigt ja nur, dass es einen Eintrag gibt.

Da der Eintrag fehlerfrei war, habe ich dies nicht gepostet, aber hier ist der dazugehörige Inhalt:

Also mit der zur Verfügungstellung der relevanten Angaben hast du es auch nicht.

ich bin raus, hinterlasse dir jedoch noch diese Hilfe:
https://www.google.de/search?q=wsus+client+log