onkeldave
Goto Top

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:
@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

Content-Key: 240848

Url: https://administrator.de/contentid/240848

Printed on: April 23, 2024 at 07:04 o'clock

Member: onkeldave
onkeldave Jun 13, 2014 at 13:14:56 (UTC)
Goto Top
Wir nutzen hier im Hause Windows 2008 R2 Standard SP1
Member: Gersen
Gersen Jun 13, 2014 updated at 14:13:20 (UTC)
Goto Top
Hallo,

nach meiner Meinung liefert die Zeile
GOTO %PROCESSOR_ARCHITECTURE%
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
Member: onkeldave
onkeldave Jun 16, 2014 at 07:53:23 (UTC)
Goto Top
Moin Gersen,

danke für deine neuen Ideen, hab die Prozessor Variable mal über die Aufgabenplanung in eine Datei reinschreiben lassen und er gibt mir wirklich AMD64 aus, also scheint das schon mal zu klappen.

Aber selbst wenn er es falsch machen würde mit der Architektur, würde das auch nicht nicht erklären warum er bei drei gleichen Versionsnummern, die Install Funktion nicht einfach überspringt, so wie er es eigentlich tun sollte!

das Echo liefert doch folgendes zurück:

1.7.0_60
1.7.0_60
1.7.0_60

das heißt 32 und 64 sind identisch mit der neuen Java Version.

und die Schleife danach sagt doch eindeutig, springe nur in die Install Funktion wenn es NICHT gleich ist.

*confused*
Member: Gersen
Gersen Jun 16, 2014 at 13:25:10 (UTC)
Goto Top
Hallo,

noch eine Sache, die mir im Skript auffällt:

Auch in der 32-bit-Architektur arbeitet das Skript einen Befehl ab:
"c:\Program Files (x86)\GnuWin32\bin\wget.exe" ...  
, dessen Pfad es in einem 32-bit-Windows eigentlich (standardmäßig) nicht gibt. Oder?

Gruß,
Gersen
Member: onkeldave
onkeldave Jun 18, 2014 at 07:41:10 (UTC)
Goto Top
Guten Morgen,

das Program ist kein Windows Standard - richtig!
Wget ist ein freies Kommandozeilenprogramm des GNU-Projekts zum Herunterladen von Dateien aus dem Internet
Member: onkeldave
onkeldave Jun 18, 2014 at 07:51:05 (UTC)
Goto Top
ich denke aber das es keine Rolle spielt. Es wird ja über die Aufgabenplanung über den Domain Administrator ausgeführt mit höchsten Rechten oder möchtest du auf was anderes hinaus ?
Member: Gersen
Gersen Jun 18, 2014 at 08:03:47 (UTC)
Goto Top
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
Member: onkeldave
onkeldave Jun 18, 2014 at 09:26:27 (UTC)
Goto Top
Danke Gersen,

das ist es!

@echo off
"c:\Program Files (x86)\GnuWin32\bin\wget.exe" -N http://java.com/applet/JreCurrentVersion2.txt   
exit 0

Bei Handausführung - läd er die Datei, bei Aufgabenplanung nicht.
Das bedeutet die Aufgabenplanung bekommt kein Zugriff aufs x86 Verzeichnis ?
Member: onkeldave
onkeldave Jun 18, 2014 at 09:32:19 (UTC)
Goto Top
wir gehen von einer x64 -> amd64 umgebung aus
Member: onkeldave
onkeldave Jun 18, 2014 at 10:04:04 (UTC)
Goto Top
Ja Perfekt danke für diene Mühe!

Installiert in x64 Programm Verzeichniss und es läuft nun!

Danke vielmals CLOSED