Die PH Luzern hat eine Lernsoftware zu Young World erarbeitet und stellt diese den Schulen von Luzern kostenlos zur Verfügung. Schulen von anderen Kantonen können das Lehrmittel über diesen Anbieter beziehen.

Wir haben für unsere Primarschule eine Lizenz gekauft und nun sollte ich eine Installation für die entsprechenden Computer erstellen. Auf einem beiliegenden Zettel wird vorgeschlagen, das Programm auf einem Server zu installieren und dann eine entsprechende Verknüpfung zu erstellen, die man dann ja auch irgendwie auf die Clients verteilen müsste. Da keine zentrale Datenbank oder ähnliches gepflegt wird, ist mir eine lokale Installation auf den Clients viel sympathischer, da dann bei der Anwendung keine grossen Datenpakete wie Audiofiles übers Netzwerk fliessen.

Das Programm schlägt C:\Program Files (x86)\English_YW2 als Zielverzeichnis vor. Bei einer späteren Verteilung könnte das Probleme mit vorhandenen 32bit Windows 7 Installationen geben, die wir auch immer noch im Einsatz haben.

Daher habe ich die Installation auf C:\Lernprogramme\English_YW2 verlegt.

Die Installation besteht aus einem reinen Kopiervorgang (und dem Erstellen der dem Installationspfad angepassten Verknüpfungen).

Da das Programm nichts anderes benötigt als die Dateien im Ordner, kann man nun diesen Ordner und die Verknüpfung (auf den richtigen Pfad) speichern und die virtuelle Maschine wieder auf den Grundzustand zurücksetzen.

Nun kann man ein Skript zur Installation erstellen, das die Dateien auf den lokalen Client kopiert.

@echo off
REM Ordner English_YW2 auf c:\Lernprogramme\ kopieren
robocopy %~dp0\English_YW2 c:\Lernprogramme\English_YW2 /s
REM Verknuepfung in Startmenue kopieren
robocopy „%~dp0\English Young World 2“ „C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Lernprogramme“
REM Return exit code to sccm
exit /B %EXIT_CODE%

Nun kann man mit SCCM den ganzen Ordner auf einen Verteilungspunkt verteilen und als Programm das install.cmd Skript ausführen.

Wie oben schon angetönt wäre eine andere Möglichkeit, dass man die Software auf einem Server installiert und dann nur die Verknüpfung auf die Clients verteilt. Das könnte man auch mit Robocopy erledigen oder über die Group Policy Preferences. Dies verursacht dann aber mehr Netzwerklast im Einsatz und vor allem installiere ich nicht gerne Clientsoftware auf Servern. Seit der Virtualisierung von Servern ist dies zwar auch etwas entschärft, man kann ja einfach noch einen zusätzlichen Applikationsserver erstellen, auf dem keine wichtigen anderen Dienste laufen.

Man merkt also leider auch dieser neueren Lernsoftware an, dass bei der Erstellung nicht an grössere Netzwerke und automatisierte Verteilung gedacht wurde. Wünschenswert wären Parameter für die automatisierte Installation im Stil von setup.exe /”ich möchte eine automatische Installation” /”ich möchte kein Desktopsymbol” /”Pfad für die Installation” /”Pfad zu einem allfälligen Logfile”.

Bisher habe ich die jeweils neueste Version von Java immer gemäss dieser Anleitung verteilt. Dabei hat man aus der EXE Datei die MSI Datei extrahiert (und dann mit Orca angepasst). Dieses Vorgehen wird aber schon länger nicht mehr von Oracle unterstützt, daher wollte ich bei der neuen Version den von Oracle empfohlenen Weg einschlagen.

Gemäss Oracle kann man die exe Dateil silent installieren. Alternativ bieten sie auch weiterhin ein MSI an, das aber nur kostenpflichtig erhältlich ist:

Vielleicht wär das ja zahlbar und sicher praktisch. Eine Suche war dann aber ziemlich ernüchternd… (CHF9,500.00 – CHF11,668.00)

Also versuchte ich die EXE Datei, die man von www.java.com herunterlädt, gemäss der Beschreibung von Oracle silent zu installieren.

Statt mit dem kostenlosen Download zu beginnen, wählt man alle Java-Downloads und dann die gewünschte Offline Installation aus. Da wir mit dem 32bit Internet-Explorer arbeiten, sollte auch die Java Installation für 32bit ausgewählt werden, unabhängig davon, ob ein 64bit Windows installiert wurde.

Um die Installation zu steuern, kann man ein ”Configuration File” mitgeben oder Optionen für die “Command-Line” Installation anfügen. Die Optionen sind die gleichen, die man auch für das “Configuration File” benutzen kann und finden sich hier.

Dies ergibt dann für meine Bedürfnisse folgende Installation:

jre-8u25-windows-i586.exe AUTO_UPDATE=Disable /s

Ein Problem dabei ist, dass die alte Version (in meinem Fall Java 7 Update 67) nicht deinstalliert wird.

Um diese Version zu deinstallieren, kann man den Befehl

msiexec /x {26A24AE4-039D-4CA4-87B4-2F03217067FF} /qn

verwenden. Bei der neuen Version von SCCM (ab 2012) kann man auch angeben, dass die alte Version gelöscht werden soll, wenn man die neue installiert.

Leider funktioniert diese Vorgehensweise nicht auf 64bit Computern für die 32bit Javaversion (obwohl das der von Oracle empfohlene Weg für eine silent Installation ist), wenn der Befehl über den System Account ausgeführt wird (wie meistens bei Softwareverteilung).

Die EXE Datei extrahiert zuerst ein MSI. Wenn man das als lokaler Administrator durchführt, wird das MSI in c:\users\<username>\appdata\locallow\sun\java\jre<versionsnummer> extrahiert und dann ausgeführt. Wenn der Systemaccount die EXE Datei ausführt, wird die 32bit Version in c:\windows\syswow64\config\systemprofile\appdata\locallow\sun\java\… entpackt, die 64bit Version in c:\windows\system32\… (ist zwar nicht ganz logisch mit 32 und 64, ist aber so…).

Der Windows Installer von einem 64bit Windows ist aber auch eine 64bit Anwendung und sucht die Datei nachher im 64bit Ordner c:\windows\system32\… wo er sie nicht finden kann, was dann mit einem Fehlercode 1619 quittiert wird, den man normalerweise gar nicht zu Gesicht bekommt, weil SCCM (oder andere Deploymentlösungen) die Installation silent mit dem System-Account durchführen…

Nochmals kurz zusammengefasst …

• Oracle empfiehlt eine silent Installation mit der EXE oder mit dem kostenpflichtigen MSI für etwa CHF 10’0000.-
• Wählt man die Installation mit der EXE Datei, kann man ein 32bit Java nur auf ein 64bit Windows installieren, wenn der Benutzer zwar lokale Adminrechte hat, aber nicht der System-Account ist.
• Und schon ist man in der Sackgasse… Danke für die Empfehlung, Oracle.

Es gibt Wege, wie man auch das hinbiegen könnte (wie dieser, der einen Ordner vorab erstellt und dann einen Junction Point benutzt, um dem System vorzugaukeln, dass der Ordner “system32” der gleiche ist wie “syswow64”. Aber ich gehe doch lieber den alten Weg über das extrahierte MSI, der von Oracle nicht mehr unterstützt wird…

Böse, wer dahinter Kalkül von Oracle vermuten würde, das teure MSI zu verkaufen