Fehlende Dateien bei Übertragung von Updates auf USB-Medium

Fehlende Dateien bei Übertragung von Updates auf USB-Medium

Postby engelhro » 19.07.2019, 10:37

Hallo zusammen,

Eine Frage zum Kopieren von Updates auf ein USB-Medium.

Ich hätte angenommen, dass dabei mehr oder weniger der Inhalt des lokalen "client"-Verzeichnisses dupliziert wird. Bei mir passiert das aber nicht vollständig, es ergeben sich (wenige) Abweichungen.

Ich lasse das Aktualisieren von WSUSOffline anhand des automatisch erstellten Sammelskripts erfolgen, das die Teile "DownloadUpdates.cmd" und "CopyToTarget.cmd" mit denselben bzw. vergleichbaren Optionen aufruft. Bei mir wären das "w100-x64 glb /includedotnet /includewddefs" und beim Kopieren dann (neben dem Zielverzeichnis natürlich) zusätzlich noch "/cleanup".

Danach gibt es im lokalen "client"-Ordner folgende Dateien, die nicht auf das USB-Medium übernommen (oder aber dort fälschlicherweise bereinigt?) werden:

  • Auf oberster Ebene die Datei "UpdateInstaller.au3" und im Ordner "bin" die Datei "IfAdmin.cpp". Diese beiden Ausnahmen verstehe ich, denn diese Dateien sind bei der Ausführung auf einem anderen Rechner nicht vonnöten (in der lokalen Fassung aber eigentlich auch nicht, da es sich um Quellcode handelt?).
  • Im Ordner "msse\x64-glb" fehlen die Dateien "MSEInstall-x64-deu.exe" und "MSEInstall-x64-enu.exe".
  • Im Ordner "dotnet" fehlt die Datei "dotnetfx35.exe".
  • Im Ordner "dotnet\x64-glb" fehlen (Stand heute) folgende Dateien:
    Code: Select all
    dotnetfx35langpack_x64de.exe
    ndp35sp1-kb2604111-x64_01fb9c1c60d9729d07977a7b142aab80ce9cc389.exe
    ndp35sp1-kb2736416-x64_d1d9b33957bba14e31988dfdaf4f5d3b13f37943.exe
    ndp35sp1-kb2840629-x64_8bceaa39f0da28e17ce593830f2b7abd94740228.exe
    ndp35sp1-kb2861697-x64_77cfad96c417bcce3f919e6a0e29d656f9d8adc1.exe
    ndp35sp1-kb4470633-x64_db23260a535f1a3447b1002b741621d64c24b6de.exe
    ndp35sp1-kb958484-x64_e69006433c1006c53da651914dc8162bbdd80d41.exe
    ndp45-kb4014566-x64_95b57712424a36cac3fc2f27fcc12e4555a80afd.exe
    ndp45-kb4014599-x64_f97a3de2f8ba2a800ffab4889f1619b5731a0ce2.exe
    ndp45-kb4040960-x64_49acc241ffd0fe529497060f2da2e1aa81d7f405.exe
    ndp45-kb4054172-x64_7821613e8a1810a7a4f247cebb151573a4c01ec2.exe
    ndp45-kb4095519-x64_e239b7eb13f24ef5c88bcc1c1a6de58b46751309.exe
    ndp45-kb4338602-x64_03744f9af275ed2f72031861dbe4f5ffe38d968a.exe
    ndp45-kb4344173-x64_ea505c9b01b36860cca15f62fdd1ed9b46871dc7.exe
    ndp45-kb4470493-x64_aa95b2e7b0b2140007de157386dd038c8e9ace98.exe
    ndp45-kb4483474-x64_a9192b5a94484cb358f4c8b7c9bdcbed614974ea.exe
    ndp45-kb4495593-x64_a4f49e7d49efda219915de6ae806e96a3724ce97.exe
    ndp45-kb4506966-x64_b199d0f7d29251be12ba01a99e2c99cea65ac24a.exe
    ndp45-kb4507001-x64_be0daee8df411dedfc9fdbc0b3eafd20af3afeb0.exe

Hinweis: das sind jeweils nur einzelne Dateien aus diesen Verzeichnissen, der Rest wird übernommen/abgeglichen. Es handelt sich also um kein Problem vom Typ "Verzeichnis wird überhaupt nicht berücksichtigt"…

Ich habe nicht überprüft, welche zusätzlichen Diskrepanzen sich ergeben würden, wenn man WSUSOffline weitere Produkte berücksichtigten ließe oder einige der Optionen über zu inkludierende Inhalte anders setzen würde.

Kann jemand diese Unterschiede erklären? Sind das Fehler, oder werden diese Updates absichtlich weggelassen (und wenn ja, warum)?

Vielen Dank!
engelhro
 
Posts: 5
Joined: 06.08.2018, 10:37

Re: Fehlende Dateien bei Übertragung von Updates auf USB-Med

Postby Dalai » 19.07.2019, 14:50

engelhro wrote:
  • Auf oberster Ebene die Datei "UpdateInstaller.au3" und im Ordner "bin" die Datei "IfAdmin.cpp". Diese beiden Ausnahmen verstehe ich, denn diese Dateien sind bei der Ausführung auf einem anderen Rechner nicht vonnöten (in der lokalen Fassung aber eigentlich auch nicht, da es sich um Quellcode handelt?).

Korrekt. Da WSUS Offline aber GPL ist, wird der Quellcode eben gleich mitgeliefert, auch wenn die Skripte zum Bauen der EXEn nicht dabei sind.

  • Im Ordner "msse\x64-glb" fehlen die Dateien "MSEInstall-x64-deu.exe" und "MSEInstall-x64-enu.exe".

Die dürften mit kopiert werden, wenn /includemsse angegeben wird. MSEInstall*.exe sind die Installer für den Defender, nicht dessen Virendefinitionsdateien. Für neuere Windows-Versionen wie 8.x und 10 werden die Dateien aber trotzdem weggelassen, weil nicht relevant (und deshalb auf der Exclude-Liste).

  • Im Ordner "dotnet" fehlt die Datei "dotnetfx35.exe".

Diese Datei wird nur noch für Server 2008 SP2 (NT 6.0) benötigt, ab Win7/Server 2008 R2 (NT 6.1) ist das .NET 3.5 bereits Bestandteil des OS und das Setup daher irrelevant (und steht deshalb auf der Exclude-Liste).

  • Im Ordner "dotnet\x64-glb" fehlen (Stand heute) folgende Dateien:

Siehe voriger Punkt. Bei den Dateien für .NET 4.5 bin ich mir nicht sicher, aber ich schätze, dass die weggelassen werden, weil WSUS Offline .NET 4.8 installiert und daher die Updates für 4.5 nicht von Bedeutung sind. Wer .NET 4.5.x von Hand installiert, dürfte auch in der Lage sein, die dafür relevanten Updates zu installieren bzw. zu kopieren.

Grüße
Dalai
Dalai
 
Posts: 922
Joined: 12.07.2016, 21:00

Re: Fehlende Dateien bei Übertragung von Updates auf USB-Med

Postby engelhro » 22.07.2019, 15:01

Dalai wrote:
engelhro wrote:[…]

Korrekt. Da WSUS Offline aber GPL ist, wird der Quellcode eben gleich mitgeliefert, auch wenn die Skripte zum Bauen der EXEn nicht dabei sind.

Okay, klar. Ich kann da sogar nachvollziehen, dass man die Dateien zwar lokal ablegt, aber nicht auf das USB-Medium übernimmt (weil am fremden Rechner nie benötigt).

Dalai wrote:
engelhro wrote:Im Ordner "msse\x64-glb" fehlen die Dateien "MSEInstall-x64-deu.exe" und "MSEInstall-x64-enu.exe".

Die dürften mit kopiert werden, wenn /includemsse angegeben wird. MSEInstall*.exe sind die Installer für den Defender, nicht dessen Virendefinitionsdateien. Für neuere Windows-Versionen wie 8.x und 10 werden die Dateien aber trotzdem weggelassen, weil nicht relevant (und deshalb auf der Exclude-Liste).

Soweit klar, nur: warum werden diese Dateien dann überhaupt heruntergeladen und liegen (unnötigerweise) im lokalen "client"-Ordner? Ich habe die Option "/includemsse" ja wie beschrieben weder beim Download noch beim Kopieren angegeben, da ich die Signaturen nie benötige.

Dalai wrote:
engelhro wrote:Im Ordner "dotnet" fehlt die Datei "dotnetfx35.exe".[/list]

Diese Datei wird nur noch für Server 2008 SP2 (NT 6.0) benötigt, ab Win7/Server 2008 R2 (NT 6.1) ist das .NET 3.5 bereits Bestandteil des OS und das Setup daher irrelevant (und steht deshalb auf der Exclude-Liste).
engelhro wrote:Im Ordner "dotnet\x64-glb" fehlen (Stand heute) folgende Dateien:[/list]

Siehe voriger Punkt. Bei den Dateien für .NET 4.5 bin ich mir nicht sicher, aber ich schätze, dass die weggelassen werden, weil WSUS Offline .NET 4.8 installiert und daher die Updates für 4.5 nicht von Bedeutung sind. Wer .NET 4.5.x von Hand installiert, dürfte auch in der Lage sein, die dafür relevanten Updates zu installieren bzw. zu kopieren.

Auch hier: ich verstehe den Gedanken dahinter. Aber mir ist unklar, warum (trotz entsprechender anderweitg gesetzter gesetzter Optionen) überhaupt der Download dieser Dateien erfolgt und sie lokal vorhanden sind, aber dann keine Übernahme auf das USB-Medium erfolgt – ich hätte angenommen, dass das synchron gehandhabt wird.

Meine Frage müsste dann also wohl eher lauten: warum wird hier eine abweichende (in meinen Augen nicht konsistente) Logik verwendet bzw. für Download und Kopie unterschiedliche Filterlisten herangezogen? Da ich nur Windows 10 angegeben habe, ist z.B. das Dot.NET-Framework in Version 3.5 für mich niemals von Belang. Warum dann dennoch herunterladen und (zumindest lokal) bereitstellen? Analoges gilt dann auch für Dot.NET 4.5.
engelhro
 
Posts: 5
Joined: 06.08.2018, 10:37

Re: Fehlende Dateien bei Übertragung von Updates auf USB-Med

Postby Dalai » 22.07.2019, 16:14

engelhro wrote:Soweit klar, nur: warum werden diese Dateien dann überhaupt heruntergeladen und liegen (unnötigerweise) im lokalen "client"-Ordner?

Für welche Windows-Versionen hast du denn Updates laden lassen?

Ich habe die Option "/includemsse" ja wie beschrieben weder beim Download noch beim Kopieren angegeben, da ich die Signaturen nie benötige.

Zur Klarstellung: MSEInstall*.exe ist das Setup für Windows Defender für Win7. Die Dateien mpa*.exe sind die Virendefinitionen/Signaturen für den Defender, AFAIK für alle Windows-Versionen. Die Signaturen werden nur geladen, wenn /includewddefs angegeben ist. Das Defender-Setup wird nur geladen, wenn /includemsse angegeben wurde. Wenn das Setup bei dir rumliegt, solltest du mal im wsusoffline\log\download.log prüfen, ob es nicht doch irgendwann mal runtergeladen wurde.

Bei uns in der Firma lassen wir Updates für Win7, 8.1 und 10 laden, und dort liegen weder das Setup für MSE noch die Definitionen dafür rum. Benutzte Schalter: /excludesp /includedotnet /verify /seconly.

Auch hier: ich verstehe den Gedanken dahinter. Aber mir ist unklar, warum (trotz entsprechender anderweitg gesetzter gesetzter Optionen) überhaupt der Download dieser Dateien erfolgt

Weil sie statisch definiert sind, und sobald /includedotnet angegeben wird, werden eben die statisch definierten Updates/Installer für .NET geladen. Bei uns liegt auch dotnetfx35.exe (und auch die zugehörigen Sprachpakete) rum, obwohl es nicht gebraucht wird. Ja, ist überflüssig, aber sehe ich jetzt nicht wirklich als Problem.

Meine Frage müsste dann also wohl eher lauten: warum wird hier eine abweichende (in meinen Augen nicht konsistente) Logik verwendet bzw. für Download und Kopie unterschiedliche Filterlisten herangezogen? Da ich nur Windows 10 angegeben habe, ist z.B. das Dot.NET-Framework in Version 3.5 für mich niemals von Belang. Warum dann dennoch herunterladen und (zumindest lokal) bereitstellen? Analoges gilt dann auch für Dot.NET 4.5.

Meine Vermutung: Weil es sich vom Skript her einfacher handeln lässt als wenn man noch weiter verzweigt, X nur dann zu laden, wenn Bedingung A und B zutrifft, aber C nicht. Es gibt nur eine statische Downloadliste für DotNET für alle Windows-Versionen (StaticDownloadLinks-dotnet-*.txt), aber mehrere fürs Kopieren der Dateien zuständige Filterlisten (ExludeListUSB-w*.txt) - die lassen sich aber einfacher pflegen. Hinzu kommen wohl noch historische Gründe: .NET 3.5 ist erst seit NT 6.1 im System integriert, aber für NT 6.0 wird es eben noch gebraucht, was solange unterstützt wird wie NT 6.1 (Januar 2020).

Grüße
Dalai
Dalai
 
Posts: 922
Joined: 12.07.2016, 21:00

Re: Fehlende Dateien bei Übertragung von Updates auf USB-Med

Postby aker » 23.07.2019, 14:16

Die NDP-Updates werden beim Kopieren ausgeschlossen, da sie unter Windows 8 und neuer nicht anzuwenden sind. Die .NET-Updates für Windows 8 und neuer finden sich als msu/cab im jeweiligen Ordner.

MSEInstall ist "Microsoft Security Essentials", Microsoft's AV-Software. Da der Defender ab Windows 8 effektiv zu einer AV-Software umgebaut wurde, wird der Setup ab Windows 8 nicht mehr gebraucht.

Viele Grüße
Wer Rechtschreibfehler findet, darf sie behalten oder an den Meistbietenden versteigern. / Everybody finding a misspelling is allowed to sell it.
aker
aker
 
Posts: 3343
Joined: 02.03.2011, 15:32
Location: %SystemRoot%\System32\Boot\winload.efi

Re: Fehlende Dateien bei Übertragung von Updates auf USB-Med

Postby engelhro » 23.07.2019, 21:59

Hallo,

Dalai wrote:
engelhro wrote:Soweit klar, nur: warum werden diese Dateien dann überhaupt heruntergeladen und liegen (unnötigerweise) im lokalen "client"-Ordner?
Für welche Windows-Versionen hast du denn Updates laden lassen?

Wie im ersten Post angegeben nur für Windows 10 (w100-x64). Da, wie du schriebst, einige Dateien für Windows 10 nicht mehr relevant sind (separates Dot.NET 3.5, alter Defender), haben mich diese Downloads irritiert.

Dalai wrote:
Ich habe die Option "/includemsse" ja wie beschrieben weder beim Download noch beim Kopieren angegeben, da ich die Signaturen nie benötige.

[…] Das Defender-Setup wird nur geladen, wenn /includemsse angegeben wurde. Wenn das Setup bei dir rumliegt, solltest du mal im wsusoffline\log\download.log prüfen, ob es nicht doch irgendwann mal runtergeladen wurde.

Ich habe es heute noch mal mit einem jungfräulichen WSUSOffline ausprobiert: das ist keine alte Datei. Der Defender, Dot.NET 3.5 und die übrigen aufgelisteten Dateien werden dann ganz frisch geladen.

Anhand der weiteren Erklärungen verstehe ich auch, warum: es wird alles geladen und dann nur beim Kopieren gefiltert. Nicht unbedingt bandbreiten- und speicherplatzfreundlich, aber vermutlich nicht so einfach zu ändern…

Dalai wrote:Bei uns in der Firma lassen wir Updates für Win7, 8.1 und 10 laden, und dort liegen weder das Setup für MSE noch die Definitionen dafür rum. Benutzte Schalter: /excludesp /includedotnet /verify /seconly.

Das ist allerdings irritierend, bei mir landen sie auf der Platte. Ich habe zwar andere Optionen gesetzt (kein "/excludesp" und kein "seconly"), aber daran sollte es nicht liegen?

Dalai wrote:
Meine Frage müsste dann also wohl eher lauten: warum wird hier eine abweichende (in meinen Augen nicht konsistente) Logik verwendet bzw. für Download und Kopie unterschiedliche Filterlisten herangezogen? […]

Meine Vermutung: Weil es sich vom Skript her einfacher handeln lässt als wenn man noch weiter verzweigt, X nur dann zu laden, wenn Bedingung A und B zutrifft, aber C nicht. Es gibt nur eine statische Downloadliste für DotNET für alle Windows-Versionen (StaticDownloadLinks-dotnet-*.txt), aber mehrere fürs Kopieren der Dateien zuständige Filterlisten (ExludeListUSB-w*.txt) - die lassen sich aber einfacher pflegen.

Hm, eine zusätzliche Verzweigung/Fallunterscheidung hatte ich gar nicht im Sinn – ich hatte angenommen, die Filterlisten (Exclude…) würden auch beim Download eine Rolle spielen bzw. von den statisch definierten Links "subtrahiert".

aker wrote:Die NDP-Updates werden beim Kopieren ausgeschlossen, da sie unter Windows 8 und neuer nicht anzuwenden sind. Die .NET-Updates für Windows 8 und neuer finden sich als msu/cab im jeweiligen Ordner.

MSEInstall ist "Microsoft Security Essentials", Microsoft's AV-Software. Da der Defender ab Windows 8 effektiv zu einer AV-Software umgebaut wurde, wird der Setup ab Windows 8 nicht mehr gebraucht.

Okay, klar soweit.

Mir ging es inzwischen auch weniger um den Unterschied lokal ↔ USB-Medium, sondern vielmehr um den (nicht notwendigen) Download, der in meinem Fall "überflüssig" erscheint. Aber verstanden: das ist nicht die Logik/Funktionsweise von WSUSOffline. Passt, Frage beantwortet! ✓
engelhro
 
Posts: 5
Joined: 06.08.2018, 10:37


Return to Verschiedenes / Miscellaneous

Who is online

Users browsing this forum: Google [Bot] and 4 guests

cron