Problem: Häufige Updates Adobe Acrobat Reader
Am 19. 6. 2016 wurde die aktuellste Version [15.016.20041] von Acobe Acrobat (Reader) DC als optionales Update released. Sollte man die automatischen Updates nicht deaktiviert haben, werden User durch entsprechende Meldungen auf Updates hingewiesen, was uns AdministratorInnen wiederum Arbeit beschert.
Seit Anfang 2016 wurden bis zum heutigen Tag (Stand: 22. 6. 2016) 6 Updates angeboten, was für SystemadministratorInnen einen – für mich zumindest – inakzeptablen Mehraufwand bedeutet, den es zu vermeiden gilt.
Die Deaktivierung der automatischen Updates bzw. Unterdrückung der Meldung bringt hier nur bedingten Erfolg, da die zu den Updates führenden Sicherheitsrisiken bzw. Bugs dadurch nicht behoben werden.
Mir erscheint als einzig tragbare und wartungsfreieste Lösung ein zentralisierter Ansatz sinnvoll, dh, eine Serverlösung, auf die Benutzer zugreifen.
Aus Sicht des Datenschutzes müssen dabei Lösungen, die als Service im Web angeboten werden, vermieden werden, da unternehmensinterne Daten keinesfalls aus der Hand gegeben werden dürfen!
Wünschenswert wäre es also, eine Lösung zu finden, die folgende 3 Kriterien erfüllt:
Lösung: PDF erstellen mit webPDF
Ich wurde nun fündig anhand der Lösung von WebPDF. Hier wurden konsequent die oben gelisteten Forderungen umgesetzt.
Das Konzept im groben Überblick:
Es wird auf einem beliebigen (auch virtualisierten) Rechner innerhalb der Infrastruktur WebPDF installiert (Betriebssystem ab Windows XP Pro bzw. Server 2003 bis Server 2012 R2 bzw. Linux) – und das wars auch schon!
Die BenutzerInnen greifen mittels Weboberfläche auf den Service zu, wodurch eine Clientinstallation entfällt! Darüber hinaus kann dieser Dienst natürlich auch – zb via VPN oder SSL – an verschiedenen Unternehmensstandorten genutzt werden. Zeitraubende Updates auf den Clients gehören damit der Vergangenheit an!
Da ein Bild mehr als 1000 Worte sagt:
WebPDF arbeitet mit allen gängigen Dateiformaten, von Office-Dateien über Bilddateien bis hin zu Websites oder Mails, und erstellt daraus ein PDF. Mit an Board ist eine weiters eine PDF-OCR Funktion sowie die Möglichkeit, PDF-Dateien zu signieren.
Darüber hinaus gibt es für Entwickler entsprechende Schnittstellen, sodass aus selbst erstellten Anwendungen auch direkt auf den zentralen Service zugegriffen werden kann. Eine Integration in SAP, Exchange etc ist ebenfalls einfachst zu realisieren.
Interessant für zertifizierte Unternehmen ist auch, dass der ISO-Standard 19005-2:2012 (PDF/A-3) eingehalten wird!
Wie nicht anders zu erwarten war, funktioniert mit ADMINOMAT natürlich auch das Rollout für die Version JAVA 8 Update 91.
Eine detaillierte Beschreibung der Vorgangsweise gibts hier
Ein Bild sagt oft mehr als 1000 Worte:
VORHER:
NACHHER (und dazwischen liegen 2 Minuten 😆 ):
Kurzanleitung:
/V /C "\\SERVER\share\jre-8u91-windows-i586.exe" /s
oder für 64bit Systeme:
/V /C "\\SERVER\share\jre-8u91-windows-x64.exe" /s
Tipp: im ADMINOMAT kann unter Ansicht->Detailfelder kann ausgewählt werden, dass angezeigt wird, ob die Clients als 32bit oder 64bit System laufen. Eine Sortierung danach ist ebenfalls möglich…
UPDATE:
ACHTUNG – ACHTUNG – ACHTUNG!
Wir haben nun die Vorgangsweise des Rollouts von JAVA grundlegend geändert!!!
Die neue, von uns empfohlene Methode wird hier beschrieben!
Diese neue Methode funktioniert getestet für die Versionen
JAVA 8 Update 66
JAVA 8 Update 71
JAVA 8 Update 91
—————————————
Für Interessierte folgend der ursprüngliche Artikel:
Die übliche Vorgangsweise, um Java per Gruppenrichtlinien auszurollen war bisher, den offline-Installer bei JAVA downzuloaden, den installer zu starten – und nach dem ersten Stopp der Installation („Willkomen bei Java“ bla bla) das .msi – Paket im Ordner
C:\Users\administrator\AppData\LocalLow\Sun\Java\jre1.8.0_25
zu suchen – und dann per GPO auszurollen
Warum Sun nicht einfach gleich das .msi zum Download anbietet wird ein ewiges Rätsel bleiben…
Leider ist das derzeit von SUN angebotene .msi NICHT geeignet, per GPO ausgerollt zu werden, da es erhöhte Rechte (=Administratoren) benötigt.
Ich habe nun eine Anleitung (siehe hier) gefunden, die ich gerne – nachdem ich sie getestet habe – noch einmal kurz zusammenfassen möchte – und die dortigen Fehler ausgebessert habe.
Herzlichster Dank an den Urheber.
Step – by – Step – Anleitung: zentralisierte Installation von JAVA 8 25
[Edit: UNTEN bei den Kommentaren findet sich eine Lösung für Java 8 Update 40
Ich hatte aber noch keine Zeit, diesen Vorschlag auch zu testen…]
table “Component”
Component = emptycfgComponent
ComponentId =
Directory = JavaDir
Attributes = 0 (Decimal)
Condition =
KeyPath Field =
table “FeatureComponent”
Feature_ = jrecore
Component_ = emptycfgComponent
table “File”
File Field = java.settings.cfg
Component_ = emptycfgComponent
FileName = java~1.cfg|java.settings.cfg
FileSize Field = 0
Version =
Language =
Attributes = 8192 (Decimal)
Sequence Field = 1
table “Media”
DiskId Field = 2
LastSequence Field = 1
DiskPrompt Field =
Cabinet Field =
VolumeLabel Field =
Source Field =
table “InstallExecuteSequence” ändern:
“SetSilentInstall” –> UILevel=2 –> UILevel<=3
table “Properties” (ändern bzw. fehlende Fehlder hinzufügen)
AUTO_UPDATE=0
AUTOUPDATECHECK=0
JU=0
JAVAUPDATE=0
EULA=0
SPONSORS=0
WEB_JAVA_SECURITY_LEVEL=H
WEB_ANALYTICS=0
7. verändertes .MSI speichern und auf ein Share eines Servers kopieren
8. in diesem Share – ausgehend vom Speicherort eurer .msi folgenden Pfad anlegen:
CommonAppData\Oracle\Java
9. in diesen neu erstellten Unterordner „Java“ eine leere Datei erstellen namens
java.settings.cfg
10. Gruppenrichtlinie erstellen (COMPUTERKONFIGURATION)
Letzter Tipp noch:
man kann auf einem Test-PC das .msi-Paket auch manuell starten, um zu testen, ob es Problemlos durchäuft.
Dazu sollte mit einem User, der NICHT Mitglied der Administratoren ist, folgendes in eine Command-Shell eingegeben werden (alles in 1 Zeile!):
[Tipp: davor auf C: den Ordner InstallLOG manuell erstellen, dort ist dann eine Logdatei zu finden]
msiexec /qn /a \\SERVERNAME\SHARENAME\JAVA\jre1.8.0_25.msi /Lime C:\InstallLOG\Protokolldatei.txt
nach ein paar Minuten des wartens und einem NEUSTART sollte JAVA 8 25 dann am Testrechner installiert sein.
(Anmerkung:
dieses .msi lässt sich auch installieren, wenn am Client ältere Versionen vorhanden sind – und bleiben!)
Die angesprochene Logdatei sollte so aussehen:
=== Logging started: 13.11.2014 17:22:53 ===
Action start 17:22:53: ADMIN.
Action start 17:22:53: CostInitialize.
Action ended 17:22:53: CostInitialize. Return value 1.
Action start 17:22:53: FileCost.
Action ended 17:22:53: FileCost. Return value 1.
Action start 17:22:53: CostFinalize.
Action ended 17:22:53: CostFinalize. Return value 1.
Action start 17:22:53: InstallValidate.
Action ended 17:22:53: InstallValidate. Return value 1.
Action start 17:22:53: InstallInitialize.
Action ended 17:22:53: InstallInitialize. Return value 1.
Action start 17:22:53: InstallAdminPackage.
Action ended 17:22:54: InstallAdminPackage. Return value 1.
Action start 17:22:54: InstallFiles.
Action ended 17:22:54: InstallFiles. Return value 1.
Action start 17:22:54: InstallFinalize.
Action ended 17:22:59: InstallFinalize. Return value 1.
Action ended 17:22:59: ADMIN. Return value 1.
MSI (s) (7C:90) [17:22:59:536]: Product: Java 8 Update 25 -- Installation completed successfully.
MSI (s) (7C:90) [17:22:59:551]: Das Produkt wurde durch Windows Installer installiert. Produktname: Java 8 Update 25. Produktversion: 8.0.250.
Produktsprache: 1033. Hersteller: Oracle Corporation. Erfolg- bzw. Fehlerstatus der Installation: 0.
=== Logging stopped: 13.11.2014 17:22:59 ===
PS: Ich würde nichts lieber tun, als meine funktionierende .msi hier zum Download bereit zu stellen…
Aber aus rechtlichen Gründen bla bla bla…
Gegen eine persönliche Bitte und eine nachweisliche Spende für Ärzte ohne Grenzen kann ich aber eventuell ….