forums.wsusoffline.net

Hallo,

langsam bin ich am Verzweilfen.
Mein letztes Update der Daten per Wsusoffline habe ich im September 2015 geladen.
Letztens wollte ich es schon laden, da mir aber alles zu lange dauerte brach ich ab und wollte es heute probieren.

Wsusoffline ist auf 10.5.

Er hängt bei mir immer an derselben Stelle... ich habe schon mindestens 3-4 mal abgebrochen, nachdem ich jeweils über 1 Stunde gewartet hatte und nichts geschah.
Habe auch schon im Ornder client/md die txt-Dateien verschoben (nicht gelöscht), brachte aber auch nichts.

Mein Wsusoffline-Ordner befindet sich auf einer externen USB-HDD und wid per net use eingebunden.

wget.exe ist in der Windows-Firewall freigegeben (verwende jetzt schon eine Weile Windows 10 Firewall Control und kein Comodo mehr).

PS: 128 Kib Begrenzung für jpg's. Also Bildausschnitt verkleinert.

Das hört sich nach einem paranoiden AV-Programm an.
Testweise bitte einmal den Ordner von wsusou & %temp% vom OnAccess-Scan ausschließen und erneut testen.

Falls das nicht hilft: %temp% leeren und beim Hänger eine Liste oder einen Screenshot der Dateien dort hier hochladen.

Viele Grüße

Habe den kompletten Laufwerksbuchstaben im AV zu den Ausnahmen längst (schon seit Monaten) hinzugefügt.
Müsste also damals, beim letzten Update, so funktioniert haben.
Warum das jetzt nicht möchte...
Ich verwende Emsisoft AntiMalware.

wget.exe ist in Windows10FirewallControl als WebBrowserZone freigegeben, kann es eher daran liegen?
W10FC ist aber auch schon länger installiert als das letzte Update her ist.

Mein Wsusoffline-Ordner befindet sich auf einer externen USB-HDD und wid per net use eingebunden.

Warum muss ein gewöhnliches USB-Laufwerk mit net use eingebunden werden? Das klingt eher nach einem NAS-Laufwerk (Network Attached Storage). Wie genau wird das Laufwerk eingebunden? Wie ist der genaue Pfad zum Programm UpdateGenerator.exe?

Es ist bekannt, dass das Update von Netzwerkfreigaben mit UNC-Pfaden (\\<Server>\<Freigabe>) aus etwas trickreich ist. Wenn man dem Laufwerk einen Laufwerksbuchstaben zuweist, geht es besser, aber es kann immer noch Probleme mit den Rechten geben.

siehe:

• wsusoffline\doc\faq-deu.txt
• viewtopic.php?f=5&t=4967

In solchen Fällen ist es am besten, den Ordner wsusoffline auf das Laufwerk C: zu kopieren, sodass der Pfad einfach C:\wsusoffline ist. Das schließt alle Fehlerquellen mit dem Pad aus.



Wenn das Skript beim Schritt Determining superseded updates angekommen ist, bedeutet das, dass zumindest die Datei wsusoffline\client\wsus\wsusscn2.cab erfolgreich heruntergeladen wurde. Die Datei für diesen Monat sollte ein Änderungsdatum vom 9. Februar 10:25 haben. Stimmt das soweit?

Die Dateien wsusoffline\static\StaticDownloadFiles-modified.txt und wsusoffline\static\StaticDownloadLink-recent.txt sollten ebenfalls neu sein und ein Änderungsdatum vom 15. Februar 12:56 haben. Die Datei StaticDownloadFiles-modified.txt sollte leer sein, was für diese Datei normal ist.



Die nächste mögliche Fehlerquelle wären Probleme mit dem Windows Scripting Host (WSH) und Cscript.exe. Wenn das irgendwie blockiert wird, geht es an dieser Stelle nicht weiter. Leider werden alle Fehlermeldungen von Cscript.exe mit der Batch-Option //B unterdrückt. Microsoft schreibt dazu:

/B
Specifies batch mode, which does not display alerts, scripting errors, or input prompts.

https://technet.microsoft.com/en-us/lib ... 20171.aspx

Diese Option kann ein paar überflüssige Meldungen unterdrücken ("Cscript verwendet MSXML 6.0"), aber sie ist bei der Fehlersuche nicht sehr hilfreich. Deshalb würde ich das Skript DownloadUpdates.exe in einem Editor öffnen und die Option //B aus allen Aufrufen von Cscript.exe (%CSCRIPT_PATH%) herauslöschen. Das ändert nichts an der Funktion, ermöglicht aber normale Fehlerausgaben.


Ein einfacher Test wäre es, das Programm client\UpdateInstaller.exe aufzurufen. Im Vergleich zum UpdateGenerator.exe führt dieses Programm ein paar zusätzliche Tests durch. Dabei wird auch die korrekte Funktion des Windows Scripting Host überprüft. Wenn das Programm einfach normal startet und sein Dialogfenster anzeigt, kann man es gleich wieder beenden, denn man möchte an dieser Stelle ja nichts installieren. Eventuell bekommt man aber vorher ein paar hilfreiche Warnungen angezeigt.

Die USB-HDD wird per net use eingebunden weil ich mit einer VM online bin und die Platte mehr Daten beinhaltet welche nicht in der VM verfügbar sein sollen.
Lokal, also mit dem Host, gehe ich nicht online.

Die wsusscn2.cab ist vom 09.02. das stimm also soweit.
Die wsusoffline\static\StaticDownloadFiles-modified.txt und wsusoffline\static\StaticDownloadLink-recent.txt sind auch vom 15.02. die Datei StaticDownloadFiles-modified.txt ist leer, jepp.

Die client\UpdateInstaller.exe lässt sich, mit per net use eingebunden, nicht öffnen und bringt eine Fehlermeldung (der Pfad ist nicht vorhanden).
Habe mal die Foren-Suche bemüht:
viewtopic.php?p=13188#p13188
Ist zwar nicht die Lösung zu dem Problem... funktioniert auch heute nicht.

Es muss doch als normaler User möglich sein die Updates per wusoffline zu laden.

hbuhrmester wrote:In solchen Fällen ist es am besten, den Ordner wsusoffline auf das Laufwerk C: zu kopieren, sodass der Pfad einfach C:\wsusoffline ist.

So viel Platz habe ich auf C:\ in der VM nicht!

Welche Dateien dürfen denn in der Firewall nicht geblockt werden?
Bei mir werden auch solche geblockt wie explorer.exe, die lasse ich nur zu, wenn ich sie wirklich brauche.

Eigentlich nur die wget.exe...
Was das Updaten angeht; das Netzlaufwerk einfach als Admin & als normaler User einbinden.
Das sollte helfen.

Wenn das Programm hängt, welche Dateien befinden sich in %temp% (bitte vor Start des Downloads einmal leeren)?

Viele Grüße

Letztlich scheint es ein Problem mit dem Setzen des aktuellen Arbeitsverzeichnis zu geben, aber nur mit cscript.exe. Die meisten Teile des Skripts funktionieren anscheinend, da wget immerhin die ersten drei Dateien herunterladen konnte. Die Frage ist nur, warum das mit cscript nicht funktioniert.

Ein einfacher Test wird in https://stackoverflow.com/questions/152 ... -not-found vorgeschlagen:

Anstelle von

Code: Select all

cscript.exe your.vbs

soll man

Code: Select all

cscript.exe "%~dp0your.vbs"

verwenden, um den Pfad zum Skript explizit zu setzen. In DownloadUpdates.cmd könnte man entsprechend die Aufrufe:

Code: Select all

%CSCRIPT_PATH% //Nologo //B //E:vbs XSLT.vbs
%CSCRIPT_PATH% //Nologo //B //E:vbs ExtractIdsAndFileNames.vbs
%CSCRIPT_PATH% //Nologo //B //E:vbs CreateDownloadTable.vbs

ändern in:

Code: Select all

%CSCRIPT_PATH% //Nologo //E:vbs "%~dp0XSLT.vbs"
%CSCRIPT_PATH% //Nologo //E:vbs "%~dp0ExtractIdsAndFileNames.vbs"
%CSCRIPT_PATH% //Nologo //E:vbs "%~dp0CreateDownloadTable.vbs"

Vielleicht funktioniert auch:

Code: Select all

%CSCRIPT_PATH% //Nologo //E:vbs .\XSLT.vbs
%CSCRIPT_PATH% //Nologo //E:vbs .\ExtractIdsAndFileNames.vbs
%CSCRIPT_PATH% //Nologo //E:vbs .\CreateDownloadTable.vbs

Vielleicht spielt auch der UpdateGenerator.exe da mit rein. Was passiert denn, wenn man ein Terminal (Eingabeaufforderung) öffnet, in das Verzeichnis wsusoffline\cmd wechselt und von dort aus das Skript DownloadUpdates.cmd direkt aufruft? Im einfachsten Fall wäre das:

Code: Select all

DownloadUpdates.cmd w100 glb
DownloadUpdates.cmd w100-x64 glb

Viele Grüße

Der "Pfad nicht gefunden" bei 'net use' tritt auf, wenn man nicht beachtet, daß 'net use' zweimal für dieselbe Ressource benutzt werden muß:
1. In einer Kommandozeile ohne erhöhte Rechte, um einen Startpunkt für das Programm zu haben.
2. In einer Kommandozeile mit erhöhten Rechten, denn ansonsten findet das gestartete Programm nach der UAC-Bestätigung keine Netzwerkfreigabe mehr vor.

Eine Netzwerkverknüpfung gilt nur für die Rechteebene, auf der man sie eingerichtet hat. Deshalb braucht die erhöhte Rechteebene eine eigene Verknüpfung.

aker wrote:Eigentlich nur die wget.exe...

Ja, die habe ich ja schon "Ewigkeiten" freigegeben.
Im September hat das Upadtes laden ja geklappt.

aker wrote:Was das Updaten angeht; das Netzlaufwerk einfach als Admin & als normaler User einbinden.
Das sollte helfen.

Oha, mal was ganz neues.

boco wrote:Der "Pfad nicht gefunden" bei 'net use' tritt auf, wenn man nicht beachtet, daß 'net use' zweimal für dieselbe Ressource benutzt werden muß:
1. In einer Kommandozeile ohne erhöhte Rechte, um einen Startpunkt für das Programm zu haben.
2. In einer Kommandozeile mit erhöhten Rechten, denn ansonsten findet das gestartete Programm nach der UAC-Bestätigung keine Netzwerkfreigabe mehr vor.

Eine Netzwerkverknüpfung gilt nur für die Rechteebene, auf der man sie eingerichtet hat. Deshalb braucht die erhöhte Rechteebene eine eigene Verknüpfung.

Habe ich gerade gemacht, mal sehen ob's was bringt.

Komisch nur, dass ich das vorher nie so machen musste.

aker wrote:Wenn das Programm hängt, welche Dateien befinden sich in %temp% (bitte vor Start des Downloads einmal leeren)?

Sollte es hängen, werde ich schauen.

@hbuhrmester
Das ist mir dann doch etwas zu umständlich.

Edit:
Also, da es immer noch nicht weiter geht... habe mit Ccleaner mal den Temp-Ordner bereinigt, läuft trotzdem nicht.
Habe sogar in der Admin-CMD, in welche ich das Laufwerk per net use eingebunden habe, den Updategenerator gestartet, aber auch das bringt nichts, weil er an besagter Stelle nicht weitermacht.

Nach dem Leeren von %temp% & beim Hängen von wsusou: welche Dateien befinden sich in %temp%? (Screenshot (bevorzugt) oder Liste)

Viele Grüße