Java Auto Updater Batch Script in Windows zeigt über Aufgabenplanung komisches Verhalten
Hallo Experts,
ich habe mal in Zusammenarbeit mit Administrator.de ein JavaAutoUpdater Batch Script in Windows erstellt, was bei manueller Ausführung auch perfekt funktioniert.
ABER SOBALD es über die Aufgabenplanung realisiert wird und mit höchsten Rechten als Domain Administrator ausgeführt wird, immer wieder in die 32Bit Installationsfunktion springt, wobei nix zu aktualisieren ist.
Der Ablauf ist recht simple. Das sCript prüft die Architecture des BS und springt in die richtige Funktion. Danach läd es sich mit dem Tool Wget die aktuelle Versionsnummer runter und speichert sie in einer Datei. Dann werden die Versionnummern untereinander verglichen und sobald eine Version 32/64Bit sich zur aktuellsten unterscheiden, soll die jeweilige geupdated werden.
Wie gesagt manuell kein Problem, autom. Aufgabenplanung installiert er immer die 32Bit Java Version egal ob gleich oder andere Revisionsnummer.
Das SCript darf gerne weiter verwendet werden von euch, es fehlt aber noch da Download Script, was ich weggelassen habe, weil es zur Fehleranalyse eigentlich keine Rolle spielt.
Wäre Toll wenn jemand mir erklären könnte wodurch das merkwürdige Verhalten kommt?!?
Danke schonmal für eure Mühe und schönes sonniges WE!!!
Das Script:
ich habe mal in Zusammenarbeit mit Administrator.de ein JavaAutoUpdater Batch Script in Windows erstellt, was bei manueller Ausführung auch perfekt funktioniert.
ABER SOBALD es über die Aufgabenplanung realisiert wird und mit höchsten Rechten als Domain Administrator ausgeführt wird, immer wieder in die 32Bit Installationsfunktion springt, wobei nix zu aktualisieren ist.
Der Ablauf ist recht simple. Das sCript prüft die Architecture des BS und springt in die richtige Funktion. Danach läd es sich mit dem Tool Wget die aktuelle Versionsnummer runter und speichert sie in einer Datei. Dann werden die Versionnummern untereinander verglichen und sobald eine Version 32/64Bit sich zur aktuellsten unterscheiden, soll die jeweilige geupdated werden.
Wie gesagt manuell kein Problem, autom. Aufgabenplanung installiert er immer die 32Bit Java Version egal ob gleich oder andere Revisionsnummer.
Das SCript darf gerne weiter verwendet werden von euch, es fehlt aber noch da Download Script, was ich weggelassen habe, weil es zur Fehleranalyse eigentlich keine Rolle spielt.
Wäre Toll wenn jemand mir erklären könnte wodurch das merkwürdige Verhalten kommt?!?
Danke schonmal für eure Mühe und schönes sonniges WE!!!
Das Script:
@echo off
rem #########Prozessor herausfinden und in Funktion springen#########
GOTO %PROCESSOR_ARCHITECTURE%
:x86
FOR /F "tokens=2* delims= " %%A IN ('REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /v Java7FamilyVersion') DO SET Version32=%%B
GOTO TEST32
:x64
FOR /F "tokens=2* delims= " %%A IN ('REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /v Java7FamilyVersion') DO SET Version64=%%B
FOR /F "tokens=2* delims= " %%C IN ('REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment" /v Java7FamilyVersion') DO SET Version32=%%D
GOTO TEST64
:AMD64
FOR /F "tokens=2* delims= " %%A IN ('REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /v Java7FamilyVersion') DO SET Version64=%%B
FOR /F "tokens=2* delims= " %%C IN ('REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment" /v Java7FamilyVersion') DO SET Version32=%%D
GOTO TEST64
rem #########Test der 32 Bit Version auf Aktualität#########
:TEST32
"c:\Program Files (x86)\GnuWin32\bin\wget.exe" -N http://java.com/applet/JreCurrentVersion2.txt
for /f %%i in (JreCurrentVersion2.txt) do ( set VERSION2=%%i
)
ECHO %Version32%
ECHO %VERSION2%
if %Version32% NEQ %VERSION2% (goto install32) else (goto end)
rem #########Test der 64 Bit Version auf Aktualität#########
:TEST64
"c:\Program Files (x86)\GnuWin32\bin\wget.exe" -N http://java.com/applet/JreCurrentVersion2.txt
for /f %%i in (JreCurrentVersion2.txt) do ( set VERSION2=%%i
)
ECHO %Version32%
ECHO %Version64%
ECHO %VERSION2%
if %Version32% NEQ %VERSION2% (goto install32) else (goto check64)
:check64
if %Version64% NEQ %VERSION2% (goto install64) else (goto end)
rem #########Installieren der 32 Bit Version#########
:install32
taskkill /F /im msiexec.exe
taskkill /F /im iexplore.exe
taskkill /F /im jusched.exe
powershell.exe C:\scripts\test.ps1
C:\Scripts\java32bit.exe /s IEXPLORER=1 REBOOT=Suppress AUTOUPDATECHECK=0 JAVAUPDATE=0 WEB_JAVA=1 /L C:\java_32_setup.log
taskkill /F /im msiexec.exe
C:\Scripts\mail_java_32.bat
if %Version64% NEQ %VERSION2% ( goto install64 ) else (goto end)
exit 0
rem #########Installieren der 64 Bit Version#########
:install64
taskkill /F /im msiexec.exe
taskkill /F /im iexplore.exe
taskkill /F /im jusched.exe
powershell.exe C:\scripts\test.ps1
C:\Scripts\java64bit.exe /s IEXPLORER=1 REBOOT=Suppress AUTOUPDATECHECK=0 JAVAUPDATE=0 WEB_JAVA=1 /L C:\java_64_setup.log
taskkill /F /im msiexec.exe
C:\Scripts\mail_java_64.bat
exit 0
:end
exit 0
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 240848
Url: https://administrator.de/contentid/240848
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
nach meiner Meinung liefert die Zeile
keinen oder einen falschen Wert für die Variable "PROCESSOR_ARCHITECTURE". (In beiden Fällen fährt das Skript mit der x86-Variante fort.)
Grund für einen falschen Wert könnte sein, dass das Skript im Taskplaner mit einer 32-bit-CMD aufgerufen wird.
Zitat: "Die Batch Systemvariable %processor_architecture% gibt die Architektur des aktuell ausführenden Programms wieder.
Wenn nun also auf einem 64bit System diese Variable in der CMD (ganz normal gestartet) abgefragt wird, so lautet der Wert “AMD64“. Starte ich jetzt aber auf einem 64bit System die 32bit CMD (C:WindowsSysWOW64cmd.exe) so wird “x86” zurückgegeben."
s.a. http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-proc ...
Lass doch das Skript im TP die Variable mal in eine Datei schreiben... Und am Rande: Ein "EXIT" oder "GOTO end" in Zeile 4 wäre n.m.M. gut.
Gruß,
Gersen
nach meiner Meinung liefert die Zeile
GOTO %PROCESSOR_ARCHITECTURE%
Grund für einen falschen Wert könnte sein, dass das Skript im Taskplaner mit einer 32-bit-CMD aufgerufen wird.
Zitat: "Die Batch Systemvariable %processor_architecture% gibt die Architektur des aktuell ausführenden Programms wieder.
Wenn nun also auf einem 64bit System diese Variable in der CMD (ganz normal gestartet) abgefragt wird, so lautet der Wert “AMD64“. Starte ich jetzt aber auf einem 64bit System die 32bit CMD (C:WindowsSysWOW64cmd.exe) so wird “x86” zurückgegeben."
s.a. http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-proc ...
Lass doch das Skript im TP die Variable mal in eine Datei schreiben... Und am Rande: Ein "EXIT" oder "GOTO end" in Zeile 4 wäre n.m.M. gut.
Gruß,
Gersen
Wenn ich das Programm in einer 32-bit-Windows-Umgebung installieren will, bietet es mir standardmäßig den Installationsordner "C:\Programme\..." an. Also wenn Du in den 32-Bit-Windows-Umgebungen den Pfad nicht angepasst hast (auf "C:\Program Files (x86)\..."), habe ich die Vermutung, dass in diesen Umgebungen das Skript die wget.exe gar nicht findet, nix herunterlädt - und dass dann natürlich die Vergleiche nicht stimmen... Kann das sein?
Gruß,
Gersen
Gruß,
Gersen