HOWTO: Adobe Acrobat Reader DC 2015 " Classic Track " angepasstes Software Deployment mit WSUS Package Publisher

07/2015

 

 Vorbereitung

Im Frühjahr erschien die neue Generation des Adobe Acrobat Reader, der nicht etwa wie erwartet XII heißt, sondern " DC ", denn ein Product was nicht Cloud im Namen führt ist einfach nicht hipp. Und da das große Vorbild Microsoft mit W 10 auch ein völlig neues Updatesystem an den Start bringt mußte man natürlich auch bei Adobe alles im gleichen Stil umkrempeln was jahrelang funktionierte.

In Folge dessen gibt es jetzt ZWEI Adobed Reader.

Einmal den Adobe Reader DC Continuous ( Base DC ). Dieser bekommt frei weg Updates und neue Funktionen, ist Cloudangebunden und offeriert dieverse Extras gegen Bezahlung. Womit er in einer Firma schon mal nichts zu suchen hat.

Verfügbar ist er als .exe und .msi Installer.

 

Als zweites gibt es den Adobe Reader Classic ( Base 2015 ). Dieser bekommt zu festen Terminen Sicherheitsupdates, aber keine Featureupdates, diese gibt es nur bei neuen Hauptversionen.  Er enthält keine Bezahl- Features. Alle Updates, die quartalsweise erscheinen, sind zum Download verfügbar. Er ist per GPO administrierbar.

Damit ganz klar ein Fall für den Businesseinsatz.

Das Manko - aus einem unerfindlichen Grund gibt es ihn nur als .exe Installer. Außerdem ist wie bisher eine Katalogdatei verfügbar um ihn automatisiert bereitzustellen, dazu später mehr.

Das ganze Updatesystem ist also im wesentlichen ähnlich aufgebaut wie Microsoftupdates ab W 10 mit ihrem " SLOW" and "FAST" Ring. Die Bereitstellung vom Aufwand vergleichar mit der Anpassung von JAVA-.msi's .

 

 Gut. Los gehts. Was brauchen wir:

 

- Zunächst eine Adobe Lizenz für die Firma die es erlaubt das man deren Software verteilt. Die gibt es hier, ist per email in 1/2 h erledigt und kostenfrei.

- die richtige Datei entsprechend obigen Hinweisen, den Link bekomt man von Acrobat zugeschickt. TIP: Es exsistiert auch ein FTP Server durch den sie sich hangeln können. Die Datei hat die Form AcroRdr2015xxxxxxxxxx_MUI.exe  für die Classic Version  ( Base 2015 ).

- den Acrobat Customization Wizard DC ( ACWDC ) um eine individuelle Anpassung vornehmen zu können. Download hier.

- eine funktionierende WPP / WSUS Landschaft

-optional noch die Verbindung zum passenden Acrobat Katalog um die regelmäßigen Folgeupdates direkt importieren zu können. Dieser Katalog wird im WPP eingerichtet (Katalogverwaltung): http://fpdownload.adobe.com/arm-manifests/win/SCUP

 

Teil 1: MSI gewinnen und anpassen

Wir starten die AcroRdr2015xxxxxxxxxx_MUI.exe und warten bis zum Installationsfenster, dann ist die .exe entpackt.

Im Windows Explorer wechseln wir nach C:\ProgramData\Adobe\Setup\...\RDC\ und sollten dort unter anderem die entpackten Dateien finden.

Wir kopieren alle in das Verzeichnis welches für die Softwareverteilung verwendet wird, zB: c:\Softwareverteilung \Adobe\Acrobat DC

Dann starten wir den ACWDC, öffnen die .msi, und ändern je nach Firmen und Adminpolicity z.B. folgende Parameter:

- "Personalization Options” -> “EULA Option – Suppress Display End User License Agreement”  setzen

-“Installation Options” -> Default Viewer for PDF files: Make Reader the Default PDF viewer

-“Installation Options” -> Remove all versions of Reader

-“Installation Options” -> Enable Optimization

-“Installation Options” -> Enable Caching of installer files on local hard drive

-“Installation Options” -> Run Installation: Silenty (no Interface)

-“Installation Options” -> If reboot required at the end of installation: Suppress reboot

-“Installation Options” -> Application Languages: German (Germany)

-“Shortcuts” -> Desktopverknüpfung

-“Online Services and Features” -> Disable product Updates

-“Online Services and Features” -> Disable Upsell

-“Online Services and Features” ->Disable all services

- weitere Optionen anwählen oder abwählen je nach gusto

Zum Schluss das Ganze abspeichern, der .mst einen Namen geben der deutlich macht das sie spezifisch angepasst wurde ( Firma_AcroRead.mst).

Unsere Reader ist jetzt fertig zur Updateerstellung im WPP.

 

Teil 2: Firmen-Reader über WPP/WSUS bereitstellen

Wir starten den WPP, und wer bisher schon Acrobat Reader verteilt hat wechselt in das entsprechene Update-Verzeichnis. Alle Einsteiger wählen im Menü  Updates / Update erstellen....

- wir wählen die .msi, sowie unter weitere Dateien die erzeugte .mst sowie die Data1.cab.

-(eventuell vorsichtshalber noch den  Transformers Ordner ) aber vermutlich benötigt man den nicht

-> WEITER 

 - Hersteller: Adobe Systems, Inc. ( Das der Name genau so lauten sollte merkt man wenn man später zusätzlich noch Updates per Katalogimport einbinden möchte.)

- Produkte: Abobe Reader .

- Titel: Adobe Acrobat Reader DC MUI Classic 2015

- den Rest durchklicken, das Update wird erzeugt

- "zur Installation freigeben" des Updates für die im WSUS angelegte Mitgliedsgruppe "Adobe Reader"

 

Teil 3: spätere Updates

Neben der Hauptinstallation fallen natürlich später noch die Programmupdates und Sicherheitsupdates an. Diese sollte man sich der Bequemlichkeit halber direkt aus der oben angesprochenen Katalogdatei holen.

 

Alternativen

wer keine Lust hat die .msi zu modifizieren, für den exsistiert noch eine weitere Möglichkeit die Installation von Adobe Reader DC Classic zu beeinflussen. Adobe stellt ein .admx Template  ( ftp://ftp.adobe.com/pub/adobe/acrobat/win/Acrobat2015/misc/ ) für die Gruppenrichtlinien bereit, in diesem sind ebenfalls eine paar rudimentäre Konfigurationsoptionen enthalten.

 

Einige Anleitungen beschreiben auch ein Vorgehen mittels Verteilung von geslippstreamten Versionen. Dabei wird zunächst eine administrative Installation erstellt, diese mit den aktuellen Updates versorgt, und dann daraus ein neues Installationspaket geschnürt.  Für die Versorgung von neuen Systemen macht dies womöglich Sinn, bei bestehenden Installationen eher nicht, alleine wegen des Aufwandes und des großen entstehenden Updatepaketes.

Kommentar schreiben

Kommentare: 12
  • #1

    Robert Fischer (Montag, 22 Februar 2016 18:16)

    Die Anleitung ist sehr gut geschrieben und alles funktioniert genau so, wie beschrieben. Respekt. Danke für diese Hilfe!

  • #2

    Max T (Donnerstag, 17 März 2016 17:00)

    Hey, ich hab eine frage: Was soll man bei den Regeln eintragen, "ist Installiert" bzw "schau ob es installierbar ist"?
    Endweder überlese ich das oder ich mach was falsch :/

  • #3

    (Freitag, 18 März 2016 10:50)

    Bei einer Verteilung von .msi Installationen empfehle ich da gar nichts einzutragen. Der MSI Installer bringt bereits eigene Regeln mit die das prüfen. Einfach "Weiter" klicken. Man kann es natürlich mit eigenen Regeln kombinieren, aber das birgt erst mal nur "Geht-Nicht" - Risiko.

  • #4

    Jens (Mittwoch, 15 Juni 2016 09:33)

    Der Link zum FTP ist falsch: http://ftp//ftp.adobe.com/pub/adobe/acrobat/win/Acrobat2015/misc/
    Sollte heissen: ftp://ftp.adobe.com/pub/adobe/acrobat/win/Acrobat2015/misc/

  • #5

    (Mittwoch, 15 Juni 2016 13:34)

    Danke für den Hinweis.
    Jimdo hat sich da zickig mit ftp Links, ich habe die Adresse im Klartext eingefügt.

  • #6

    enzyme (Donnerstag, 18 August 2016 14:22)

    Hi!

    Danke für die Anleitung, die mir als Überprüfung der richtigen Schritte galt. Ich bin nach einem WSUS-Problem und dessen Neueinrichtung vom LUP auf den WPP umgestiegen und wollte nun meine Updates wieder einbinden. 7zip, Mozilla funktionieren problemlos bezüglich Statusrückgabe.
    Aber die Adobe-Produkte Reader DC /11 und Flash Player in allen Varianten liefern komische Statusmeldungen. Größtenteils liefern die Clients den Status "nicht verfügbar" zurück oder halt im WSUS "nicht zutreffend". Das betrifft auch Clients, bei denen das Update bereits installiert ist. Hier Beispiel Reader DC.
    Bei einem Update (msp) auf die neuste Reader-Version zeigen die Clients sogar an, dass das Update installiert wäre, was es aber nicht ist.

    Hast du da eine Idee? :/ Habe alle Standards durchgeklickt und keine eigenen Regeln hinterlegt. Update neueinlegen, SoftwareDistribution leeren... hilft alles nichts.

  • #7

    (Donnerstag, 18 August 2016 15:21)

    Als erstes fiele mir ein zu prüfen ob die richtigen Dateien verwendet wurden. Die Anleitung verwendet den Classic Track, da wäre die aktuelle Version des letzten Updates: 2015.006.30201.
    Lässt du die Dateien aus dem Katalog laden oder machst du es selber? Wenn du die falschen Updates verwendest, bzw die falsche/andere Version in der Grundinstallation verteilt hast würde es das "nicht verfügbar" erklären.
    Was ist mit der Grundinstallation des Reader? Im Classic Track ist das die Version 15.006.30033.

    Was passiert wenn du ein System ohne Reader nimmst, und dort zunächst die Grundinstallation und dann das Update zuweist? Er wird ja wohl nicht behaupten es wäre schon installiert :-)

    Beim Flash Player kann das aber so nicht vorkommen. Eigentlich gibt es nichts Simpleres in der Verteilung als den Flash Player. Verwendest du da Katalogimport?

    Ich gebe zu das meine Umstellung auch etwas holprig war, aber wenn es erst mal läuft ist Adobe absolut easy in der Pflege. Nicht wie JAVA.

  • #8

    enzyme (Freitag, 19 August 2016 10:56)

    Danke für die schnelle Rückmeldung!

    Es war ein ganz banaler (peinlicher?) Fehler. Ich hatte in einem der Tutorials gelesen, dass man bei msi's unter den Regeln bei package level rules "Leere Regel" anklickt und hatte das dann ganz schnell in meinem Workflow drin.
    Das darf man aber scheinbar nicht. Ich hatte auch gesehen, dass dann die msi-Versions-Abfrage gelöscht wird, aber hinten bei den Anwendungsmetadaten auf der letzten Seite war der Code ja noch drin, also habe ich mir dabei nichts gedacht.
    Warum dann 7zip noch ging, ist mir zwar ein Rätsel, aber nun funktioniert alles. Jetzt muss ich nur noch den Endgegner Java besiegen, aber da war ja eher immer das mst das Problem ;-) Da habe ich eine funktionierende Version.

    Viele Grüße

  • #9

    enzyme (Freitag, 19 August 2016 11:05)

    Ach wo wir hier gerade so schön reden... Muss ich eigentlich für jedes Update ein neues mst erstellen oder funktioniert z.B. das mst von Flash 1.01 auch für 1.02? Das frage ich mich jedes Mal und ich erstelle meist kein neues.

  • #10

    (Freitag, 19 August 2016 11:27)

    Na schön das sich das so simple geklärt hat. :-)

    Ich kann jetzt gerade nicht verstehen warum jemand für Flash Updates überhaupt modifizierte .msts erstellen sollte. Die lädt man aus dem Katalog/lädt sie runter, gibt sie frei, und fertig.

    Für Java sehe ich die Frage jedoch durchaus. Und da lautete die Antwort früher : JA, man muss. Allerdings wäre es mal einen Test Wert wie das ist seit dem Oracle die Geschichte umgebaut hat.

    Für WPP&JAVA habe ich die Woche gerade zwei Einträge im Blog geschrieben da mich JAVA seit Monaten ärgert. Eventuell interessierts ja.

  • #11

    enzyme (Freitag, 19 August 2016 12:14)

    Ich verteile darüber die Optionen
    ISCHECKFORPRODUCTUPDATES = 0
    AgreeToLicense = YES
    und dann noch mal ein paar über eine mms.cfg mittels GPO. War auch nur ein Beispiel, sinnvoller ist es sicher bei Java. Ob die Optionen heute noch sinnvoll sind, weiß ich nicht. Aber früher gab es immer Update-Probleme, wenn der User kein Admin war. Für Firefox z.B. wurde das irgendwann mal umgestellt.

    Ok, dann schaue ich mir die msts lieber jedes Mal an, danke!
    Ja bei Java ist ein Glücksspiel, ob sich im Hintergrund mal wieder etwas geändert hat oder man weiterhin sein Verfahren verwenden kann. Ich verteile seit Version 8.20 z.B. ein CommonAppData-Verzeichnis mit.
    Du schreibst in deinem Artikel, dass "zur Deinstallation genehmigen" nicht funktioniert. Im LUP hatte ich damit nie Probleme und habe so alte Versionen entfernt. Ich werde das mal testen. Wenn nicht, hast du ja eine weitere Lösung beschrieben.

    Der Rest deiner Artikel scheint auch sehr interessant. Großes Lob und bis bald mal wieder ;-)

  • #12

    (Freitag, 19 August 2016 17:02)

    Bei einem Update die Option ISCheckforProductUpdates=0 zu setzen macht eigentlich keinen Sinn, das ist ein Fall für die Grundinstallation. Ebenfalls ist für ein Update das Abnicken der Lizenz nicht erforderlich. Wenn die Grundinstallation entsprechend konfiguriert ist kannst du das getrost weglassen und dir die Arbeit sparen. Wegen der zusätzlichen .cfg sollte man ggf prüfen ob die benötigten Dinge nicht in den Adobe .admx Templates enthalten sind so das man es direkt per GPO setzen kann.
    Ich mein das Leben ist schon kompliziert genug und so.... :-)

    Ja mir ist auch nicht ganz klar warum das "zur Deinstallation genehmigen" nicht funktioniert, ich hab das immer gerne benutzt und bis 8U20 funktionierte es ja auch. Dann baute Oracle um. In die Ausführungen von Oracle zu dem Thema kann man interpretieren das der Uninstaller, der auch die alten Versionen entfernt, von der .EXE aus aufgerufen wird und über die .MSI nicht adressierbar ist. Möglicherweise hängt es damit zusammen. Womöglich lässt es sich durch irgendwelche Modifikationen oder Regelwerk auch zum laufen bringen, habe dazu aber noch nichts gefunden. Außer das andere das gleiche Problem hatten :-)