Lösch mal den Inhalt vom Content Ordner und laß RESET laufen: (Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).

Hast Du bei der erneuten Deinstallation auch den Content Ordner und die Datenbank mit deinstallieren lassen?

Hast Du denn RESET laufen lassen? Vorher Content löschen/leeren. Stehen irgendwelche Fehlermeldungen im Ereignisprotokoll?

Läd der WSUS sich alle Updates in sämtlichen Sprchen runter oder kann man die Updates eingrenzen?

Hab Ihr vielleicht ein Beispiel um welche Updates es sich handelt?

Oh Mann, das gibts doch nicht. Vielen Dank für die Rückmeldung.

Hmm, da muß wohl noch etwas getan werden, bei der Version 4.0.

EDIT: Das Logging müßte hier noch angepasst werden. Damit man solche Dinge im Upstream WSUS nachlesen kann.

Hallo,
die gleichen Symptome mit meinem Upstreamserver(W2K3 mit SP2, Verteilung mit Gruppenrichtlinie), kein Hinweis, daß er was runterlädt. Ein Downstreamserver (nicht von mir aufgesetzt) hatte zwar "alle Sprachen vom Upstream laden" aktiviert. Hatte mich schon gefreut, die Lösung hier gefunden zu haben.
Nach Reboot beider Sever (welcher Dienst stoppt den Download eigentlich?), setzen der Synch auf manuell und Ausführen des Bereinungsassistenten (brachte 0MB) holt der Upstreamserver laut SoftwareDistributionlog munter weiter andere Sprachen runter.

Ein zweiter Upstreamserver lädt auch mehr runter als er sollte, obwohl die Downstreamserver von Anfang an die Sprachen explizit ausgewählt hatten.

Wäre für Lösungsansätze dankbar.
Michael

Aha, Danke für den Tip. Die 20 Jobs sind erstmal weg.
Aber kaum starte ich den BITS wieder, rattert er schon wieder los!

Das verrückte ist, das der andere Upstreamserver auch schon falsche Sprachen runtergeladen hat, als es noch gar keinen Downstreamserver gab. Da fiel es nur nicht auf, weil die Platte größer ist.
Ich werde wohl einen Call bei MS aufmachen müssen, ich such mir ja nen Wolf. Die Settings der Downstreamserver sind korrekt.

michaelcoface schrieb on 29.01.08 um 17:49:54:


Du willst mir jetzt sagen, der WSUS hat alle Sprche gedownloadet, auch solche, die Du nicht angehakt hast? Für alle Updates und Servicepacks? Nein, das glaub ich dir nicht.



michaelcoface schrieb on 29.01.08 um 17:49:54:


Ist schon was dabei herausgekommen?

Danke, parallel zur Anfrage hier habe ich mich schweren Herzens in die Tiefen des technet begeben (rtfm).

Das mit dem Löschen, da habe ich mich falsch ausgedrückt.
Wenn ich eine GUID lösche, ist dann sichergestellt, daß kein Neuversuch stattfindet? Ich hoffe halt immer moch, daß versehentlich jemand auf dem Downstream "Alle" angeglickt hatte und jetzt das noch irgendwo aktiv ist..

Ich kann verstehen, daß Du das nicht glaubst, daß er alle Sprachen runtergeladen hat, ich nämlich auch nicht. Aber ich sehe im Logfile, daß er Sprachen im November 2007 runtergeladen hat, wo noch kein Downstreamserver da war. Es sei denn, jemand anderes hat experimentiert ohne mein Wissen.

Danke für die Hilfe trotzdem. Ich versuche noch den Call zu sparen, wir haben nur noch einen. Will und muss mich ja auch in die Materie einarbeiten. Aber ich habe durch zig Projekte ein Zeitproblem und die Kisten brauchen Upates. Das klappte ja auch alles wunderbar, läuft von selbst und WSUS 3.0 ist eigentlich ne tolle Sache

das Löschen mit dem Assi klappt nicht, erlöscht nix runter.
Obwohl er nur englisch und deutsch hat.müsste er doch raffen, daß er hebräisch, türkisch, koreanisch und die andern nüscht mehr braucht?

Bin mal auf den einen Downstreamserver, er hatte auch munter babylonisches Sprachengewirr von meinem Upstream runtergeladen, weil jemand "alle" Sprachen angeklickt hatte.
Nachdem ich auf deutsch und englisch umgestellt hatte, habe ich eben den Assi laufen lassen. Der hat dann 3 GB freigeschaufelt.

Also ist das ein Zeichen für mich, daß der Upstream immer noch "glaubt", wir hätten koreanische Sprachversionen, da er diese Dateien ja nicht löscht....

Das sind die META-Daten in der Datenbank. Nochmal: Bei welchem Update/Patch? Kontrolliere doch auch mal andere Updates.

michaelcoface schrieb on 30.01.08 um 17:25:03:


Könntest Du bestimmt mal machen, schadet nicht und macht die Platte freier.

michaelcoface schrieb on 30.01.08 um 17:25:03:


Hast Du Expressinstallationsdateien ausgewählt? Wenn ja, dann brauchst Du dich nicht zu wundern.

michaelcoface schrieb on 30.01.08 um 17:25:03:


Nein, Garantie gibts von mir keine, ich seh die Konfiguration ja nicht. Wenn keine Expressinstallationsdateien aktiviert sind, kann/muß /RESET helfen. Wenn der Upstream aktuell, würde ich das /RESET mit vorherigem löschen auf dem Downstream laufen lassen. Der holt sich ja die Updates vom Mainstream.

Was mich noch irritiert:

bitsadmin /list oder /monitor zeigt mir ja aktive jobs,
aber bitsadmin /reset sagt immer 0 out of 0 jobs cancelled.

Ich kann doch nicht tausende GUIDs händisch rauslöschen?

Also, der Upstream hat in der Queue immer 10 jobs, die ich mit bitsadmin /list /allusers /verbose angezeigt bekomme und mit /cancel {GUID} einzeln löschen kann. Wenn ich das 10x gemacht habe, ist die Queue kurzzeitig leer, bis dank BITS die nächsten 10 kommen.

meine Hoffnung war, das bitsadmin /reset den ganzen Schlonz wegschmeisst, macht er aber nicht, da er 0 jobs findet.

Macht es denn dann Sinn, den  Content zu löschen und wsusutils /reset auszuführen, wenn der Bits in der Hinterhand die jobs hat.

Jetzt klarer?

Schritt für Schitt gehts voran:
Der Downstream ist fertig mit download von 5 GB Updates, hat auch nur English geholt wie geplant, keine Bits jobs mehr.

So, aber der Upstream hat noch jobs, die ich ja nicht gecancelt bekomme, nur mit immensem Aufwand!

Obwohl der Downstream ja zufrieden ist, weil er ja alle updates in English hat, bringt der Bereinigungsassi auf dem Upstream, eben grad gar nix!
Er löscht keine überflüssigen polnischen usw. Updates raus.... das heisst die Platte ist immer noch voll. Der Upstream muss lernen, die nicht benötigten Spraschen zu löschen bzw. nicht mehr nachzuladen, oder?

Wenn ich den Bits rennen lasse, der Assi nix macht, ich den Contentordner lösche und dann den wsusutil /reset ausführe was passiert dann?

Doch, deswegen frage ich ja!

"Checks that every update metadata row in the database has corresponding update files stored in the file system. If update files are missing or have been corrupted, downloads the update files again. "

Für mich heisst das: Ich lösche den Content, schaffe also Platz auf der Platte und der Bits schiesst die Files hinterher, die er abarbeitet.
dann löse ich wsusutil /reset aus. In der Db stehen doch noch die Metadaten drin für alle Sprachen, oder? Warum würde sonst der WSUS nachladen wollen, obwohl der Downstream bedient ist? Oder habe ich da einen Denkfehler?

Und warum bringt bitsadmin /reset nichts, obwohl er doch alle naslang jobs kreiert?

Aber, OK , ich werde mal den Job fertig laufen lassen, macht er halt die Leitung dicht.....

OK, Danke!
Dann sollte es aber für so Fälle die Möglichkeit geben, den Bits zu
leeren....
Obwohl er gerade runterlädt, sehe ich auf der Startseite nichts von download x of y:

Zwischenstatus:
Was endlich Wirkung auf dem WSUS für Windowsserverupdates gezeigt hat: BITS fertig laufen lassen, Bereinigungsassi, Löschen des Contentordners und wsusutil reset. Jetzt hat der downstream die Sprachen die er braucht und der upstream hat auch wieder nur die benötigten und nicht alle. Da der Upstream für die Server hier im Netz steht und der Downstream (Testdomain für AD-Migration) auch, gibts hier auch keine Leitungsprobleme.Soweit alles Klasse und Danke für die Tips

Aber der andere spinnende WSUS Upstream für die W2K und XP-Clients mit Office in 5 Sprachen macht noch Probleme bzw. dessen Downstreamserver. Was ich nicht wusste, alle Leitungen in die Zweigniederlassungen haben nur 300K! Ich ging von 2M bzw. 4M aus, aber das war eine Ausnahme, weil die neubeauftragt war und zufällig meine erste Installation. Jetzt kannst Du dir denken, wie lange es dauert....

Noch meckert keiner...
Aber 16GB über ne 300k Leitung jagen, dauert selbst bei voller Bandbreite arg laaaaaaaang