WSUS DoUpdate per Task unter W2K8R2

[Sheriff]

Hallo,
wir nutzen WSUS seit geraumer Zeit für die automatisierte Installation der Updates über einen Task (doupdate.cmd/ verify). Bisher gab es unter Windows 2003 Server keine Probleme. Aktuell stellen wir fest, daß mit der gleichen Methode auf Windows 2008R2 Maschinen im 'wsusofflineupdate.log' die Installation der Patche als erfolgreich gemeldet wird, jedoch diese innerhalb "Installierte Updates" (Windows Updateverlauf) nicht gelistet werden.

Bei nachfolgendem Aufruf des Tasks wird die Installation der gleichen Patches erneut ausgeführt.
Verwendet wird: WSUS Offline Update (v. 7.3.2)
Der Account ist ein DomainAccount mit Adminrechten. Der Task ist "Mit höchsten Berechtigungen ausführen" parametriert.
Es sind in den Logfiles / Eventlogs keine relevaten IFehlermeldungen ersichtlich. Wir sind uns nicht sicher, ob dieses Verhalten erst nach einem interaktiven Update auf SP1 aufgetreten ist.

Unsere Fragen:
a) warum werden die lt. Logfile installierten Patche nicht gelistet?
b) warum werden angeblich installierte Patche erneut installiert?
c) wie kann geprüft werden, ob ein Update erfolgreich durchgeführt wurde?

[aker]

Werden die installierten pAtches denn als fehlend angezeigt? (Windows Update)

Listet ./Client/Cmd/listinstalledupdates.vbs die Updates?

Viele Grüsse

[Sheriff]

Hallo,
(Automatische) Windows Updates sind per se auf den Maschinen deaktiviert (kein InternetZugang) - d.h. fehlende Updates werden auch nicht gelistet.
Wir haben folgendes festgestellt. Es gibt ein unterschiedliches Verhalten, wenn das Script 'DoUpdate' oder auch 'listinstalledupdates.vbs' aus verschiedenen Umgebungen (32/ 64 bit) aufgerufen wird. D.h. aus einer 64bit CommandShell werden z.B. nur die Windows Updates gelistet während bei einem Aufruf aus einer 32bit Shell zusätzlich auch MS-Office 2010 (32bit) Updates gelistet werden.

Zum Hintergrund: Wir starten via Windows-Task regelmäßig eine 32bit TCL Shell (zur Prüfung bestimmter Voraussetzungen), welche im Anschluss die DoUpdate Routine für das WSUS Offline aufruft.
Wenn der DoUpdate Aufruf durch die (geerbte) 32bit CMD Shell erfolgt, wird lt. Logausgabe die "Windows Update Agent version 0.0.0.0" erkannt und letztendlich kommt es zu o.g. Fehlerbild. Erfolgt der Task-Aufruf direkt mit DoUpdate.cmd' funktioniert alles tadellos, da 64bit Shell.

Als Ursache haben wir folgendes ausgemacht:
Im 'DetermineSystemProperties.vbs' wird das Environment aus "%SystemRoot%") & "\system32" ausgelesen. Beim Start aus einer 32bit Umgebung lenkt das Betriebs-System diesen Aufruf aber automatisch nach ..\syswow64\.. um und die Suche "scheitert" an einer"fehlenden" 'wuaueng.dll'. Damit scheint das komplette OfflineUpdate nicht richtig durchgeführt zu werden, obwohl eine korrekte Installation lt. WSUS Offline Logfile suggeriert wird.

Einzige Alternative ist jetzt ein (vorheriger) direkter Aufruf einer 64bit CMD Shell aus der TCL Shell über den unsichtbaren Aliasnamen SYSNATIVE.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
Dann klappt es auch mit dem Nachbarn...

Gibt es eine Möglichkeit, die "Erfahrungen" im WSUS Offline Mechanismus zu berücksichtigen?

[boco]

Ich denke, der ''SysNative''-Weg ist der beste. Die Alternative (ein Manifest, welches die Virtualisierung deaktiviert) ist wahrscheinlich schwierig...

Ist immer wieder eine Freude wenn man z. B. einen 32bit Dateimanager benutzt und die Dateien nicht dort landen, wo sie sollen. Die Gründe sind allerdings nachvollziehbar.

Jetzt ist der Boss gefragt...

[Sheriff]

Ja, klar ist das Verhalten (32/64bit) grundsätzlich nachvollziehbar, aber meiner Meinung nach trotzdem nicht so transparent, wie erwartet.

Offen sind für uns dennoch die Fragen (bitte nicht als Mecker verstehen):
a) Warum gibt es im WSUS-Offline Logfile keine Fehlermeldungen - sondern die Info: "Installiert....." - d.h. die fehlerhafte (?) Installation wird nicht erkannt
b) Wie kann sicher geprüft werden, ob ein Update erfolgreich durchgeführt wurde?
c) Gibt es eine Aussicht, dieses Problem über das WSUS Offline Update Handling zu lösen oder muss man der Workarround mit SYSNATIVE in Kauf genommen werden.

[boco]

Fragen, die nur der Entwickler beantworten kann. Deshalb schrieb ich:

Jetzt ist der Boss gefragt...

[WSUSUpdateAdmin]

Moin!

Tja, was soll ich da nu machen?

Die Installation läuft über "DoUpdate.cmd" (direkter Aufruf) inklusive Ermittlung von OS-Eigenschaften, fehlenden Updates etc. tadellos.

Damit das auch über "UpdateInstaller.au3" (32-Bit-Anwendung) funktioniert, steht dort vor dem Aufruf von "Update.cmd" bzw. "DoUpdate.cmd" der "Klimmzug":

Code: Select all

DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)


Ich bin geneigt, hier keine weiteren "Verrenkungen" à la "if exist %SystemRoot%\SysWOW64 ..." etc. einzubauen, zumal das nicht nur die .vbs-Skripte, sondern auch die .cmd-Skripte beträfe.

Ich bitte also darum, die bereits gefundene Lösung "SYSNATIVE" oder o.a. zu nutzen.

Gruß
Torsten Wittrock