Softwarepaketierung mit dem Package-Launcher

  • Published on
    14-Dec-2015

  • View
    19

  • Download
    7

DESCRIPTION

Softwarepaketierung leichtgemacht: robuste Pakete, bersichtliche Prozesse und automatische SCCM Integration.

Transcript

  • Real Packaging GmbH

    Eichenweg 9

    3123 Belp 076 347 77 24 www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

    Datum: 28.07.2015

    Softwarepaketierung mit dem Package-Launcher 2012

    nderungskontrolle, Prfung, Genehmigung

    Wann Version Wer Beschreibung

    14.03.11 V1.0 Dominik Oberlin Initialversion

    01.02.12 V1.1 Dominik Oberlin Div. nderungen oder Erweiterungen in:

    Kapitel 1.2, 3.5, 3.9, 3.11, 6.21

    15.08.12 V1.2 Dominik Oberlin Div. Erweiterungen. Anpassungen zu PL2.2, Rev.007

    26.01.15 V1.3 Dominik Oberlin Div Erweiterungen zu PL 2012

    03.02.15 V1.4 Dominik Oberlin Div Erweiterungen

    24.03.15- 28.07.15

    V1.5 Dominik Oberlin Diverse allgemeine Anpassungen

    Kapitel 3.5.1 INI-Eintrge

    Kapitel 6.14.3 Umgang mit Abhngigkeiten

    Kapitel 6.14.4 TaskSequence-Eintrag

    Kapitel 6.16.5 Abhngigkeiten

    Kapitel 6.16.6 Refresh von Applications

    Kapitel 6.16.7 Update Content

    Kapitel 7.4 In Benutzung stehende Programme

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 2/122

    Inhaltsverzeichnis

    1 Vorwort .................................................................................................................... 6

    1.1 Ziel und Zweck dieses Dokumentes ............................................................................. 6 1.2 Abgrenzungen ............................................................................................................ 6 1.3 Legende ..................................................................................................................... 6 1.4 Vorarbeiten ................................................................................................................ 6

    2 Methodische Betrachtung des Package-Launchers ................................................ 7

    2.1 Umfang des Pakage-Launchers.................................................................................... 7 2.2 Updates und Upgrades ............................................................................................... 7 2.3 Revisionsupdates......................................................................................................... 8 2.4 Transaktionaler Installationsprozess ............................................................................. 9

    3 Technische Betrachtung des Package-Launchers ................................................... 9

    3.1 Hauptfunktionen des Package-Launchers .................................................................... 9 3.2 Bestimmen des richtigen Paket-Unterverzeichnisses ................................................... 10 3.3 Kommandozeilenoptionen ........................................................................................ 11 3.3.1 Folgende Kommandozeilenoptionen sind zulssig...................................................... 12 3.3.2 Kommandozeilen-Beispiele........................................................................................ 14 3.3.3 Kommandozeilenempfehlung fr die Integration in SCCM......................................... 15 3.3.4 Rckgabewerte ......................................................................................................... 15 3.4 Fehlermeldungen und History.LOG ............................................................................ 16 3.4.1 History.LOG .............................................................................................................. 16 3.4.2 Bedeutung von Fehlermeldungen .............................................................................. 17 3.5 INI-Datei ................................................................................................................... 20 3.5.1 Zusammenfassung der wichtigsten INI-Eintrge ......................................................... 20 3.5.2 Sectionproperties ...................................................................................................... 32 3.6 Realisierung eines Upgrades ...................................................................................... 33 3.7 Namensrichtlinien ..................................................................................................... 34 3.7.1 Bezeichnung von MSI und MST-Dateien .................................................................... 34 3.7.2 PreInstall und PostInstall ............................................................................................ 34 3.7.3 Bezeichnung des Security-Batch ................................................................................ 34 3.7.4 Bezeichnung der Build-Datei ..................................................................................... 34 3.8 Verwendung von PreInstall_00x.wse, PostInstall_00x.wse .......................................... 35 3.9 Einsatz von eigenen Scripts und Batchprogrammen ................................................... 36 3.9.1 Richtlinien beim Einsatz von Scripts ........................................................................... 36 3.9.2 Erstes Beispiel ........................................................................................................... 37 3.9.3 Scriptbezeichner ExecuteFile, ActiveSetupScript, PreScript & PostScript ....................... 38 3.9.4 Zustzliche Environmentvariablen whrend des Installationsprozess ........................... 40 3.9.5 History.LOG kompatible Fehlermeldungen erstellen ................................................... 41 3.9.6 Beispiele ................................................................................................................... 41 3.10 Formen der Ressourcen ............................................................................................. 43 3.10.1 Vereinfachtes Ablaufschema ..................................................................................... 45 3.11 MSI-Spezialflle minimale Aktualisierungen............................................................. 45 3.12 Anwendung von Patches und Transformationen ........................................................ 46 3.13 Build-Datei ................................................................................................................ 47 3.14 Software-Inventarisierung ......................................................................................... 48 3.14.1 Die fr SCCM massgeblichen Schnittstellenregistrykeys ............................................. 48

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 3/122

    4 Best-Practice Regeln und Limitierungen ............................................................... 50

    4.1 Zielverzeichnis ........................................................................................................... 50 4.2 Startmen und ShortCuts.......................................................................................... 50 4.3 Lizenzen ................................................................................................................... 50 4.4 Namensauflsung ..................................................................................................... 51 4.5 Abhngigkeiten (Middlewares) .................................................................................. 51 4.6 Versionshandling ...................................................................................................... 52 4.7 Umgang mit .HLP-Dateien ......................................................................................... 52 4.8 Umgang mit VirtualStore........................................................................................... 52 4.9 Installationskontext ................................................................................................... 52 4.10 Firewall ..................................................................................................................... 53 4.11 Paketierungsarten ..................................................................................................... 53 4.12 Pfadlnge ................................................................................................................. 54 4.13 Automatisierung der Benutzereinstellungen .............................................................. 54 4.14 Keine automatischen Updates ................................................................................... 55 4.15 Sprachen und Spracheinstellungen ............................................................................ 55 4.16 Installation im Systemkontext .................................................................................... 56 4.17 Silent Installationen ................................................................................................... 56 4.18 Verwendung von variablen Servernamen ................................................................... 56

    5 Handling der Upgrades und Revisionsupdates .................................................... 57

    5.1 Entwicklungsumgebung ............................................................................................ 59 5.2 Produktionsumgebung .............................................................................................. 59 5.3 Namensbezeichnungen ............................................................................................. 59 5.3.1 Limitierungen und Einschrnkungen .......................................................................... 59

    6 Phasen der Paketerstellung ................................................................................... 60

    6.1 Vorarbeiten .............................................................................................................. 60 6.2 CreatePackage .......................................................................................................... 60 6.3 Verwenden eines Hersteller MSIs ............................................................................... 62 6.3.1 Auspacken von Installationselementen aus einem Bootstrapper ................................. 62 6.3.2 Ermitteln des Paketierungsumfangs ........................................................................... 62 6.3.3 Protokolldatei analysieren.......................................................................................... 63 6.3.4 In-Place-Update von Patches (Splipstreaming) ............................................................ 63 6.3.5 Verwendung von InstallShield-Setups ........................................................................ 64 6.3.6 Installationssource kopieren ...................................................................................... 64 6.3.7 Erstellen einer MST-Datei fr alle weiteren Customizing-Arbeiten .............................. 64 6.3.8 Spezielle Einstellungen ber das Benutzerinterface des Herstellersetups ..................... 64 6.3.9 Wahl von Features mit INSTALLLEVEL ........................................................................ 65 6.3.10 ShortCuts ................................................................................................................. 65 6.3.11 Probleme mit der Silentinstallation............................................................................. 65 6.3.12 Verwendung von MakeCab.vbs ................................................................................. 65 6.4 Paket mit Wise Pakage Studio repaketieren ............................................................... 67 6.4.1 Regeln im Zusammenhang mit repaketierten Software-Paketen ................................. 67 6.4.2 Umgang mit Computerneustarts ............................................................................... 69 6.4.3 Snapshotprozess mit Wise Package Studio ................................................................. 69 6.4.4 Anschlussarbeiten ..................................................................................................... 71 6.5 Umgang mit Benutzerressourcen ............................................................................... 72 6.6 Grundregeln bei der Anwendung von MST Dateien ................................................... 72

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 4/122

    6.7 ACL Lockerungen ..................................................................................................... 73 6.7.1 Datei und Registrierungsvirtualisierung ...................................................................... 75 6.8 Custom Actions in MSI-Dateien ................................................................................. 75 6.8.1 Anpassungen in Pre- und PostInstall .......................................................................... 76 6.8.2 Isolierte Ausfhrung von Pre-/PostInstall ausserhalb einer Paketinstallation ................. 77 6.9 PreInstall-Pakete........................................................................................................ 77 6.9.1 Umgang mit Legacy-Setups, die nicht repaketiert werden .......................................... 77 6.10 Active Setup in Pre- & PostInstall ............................................................................... 78 6.11 Active Setup, zielend auf eine MSI-Datei.................................................................... 78 6.12 Active Setup, zielend auf ein Pre/PostInstall ............................................................... 79 6.13 Umgang mit Patchdateien ......................................................................................... 82 6.14 INI-Datei des Softwarepakets..................................................................................... 82 6.14.1 Upgrade-Handling .................................................................................................... 82 6.14.2 Lokaler Cache ........................................................................................................... 83 6.14.3 Umgang mit Abhngigkeiten durch Verwendung des Dependence-Eintrages ......... 84 6.14.4 Die Verwendung des TaskSequence-Eintrages ....................................................... 85 6.15 AddProperties ........................................................................................................... 87 6.15.1 Propertyanpassungen und zustzliche Erweiterungen ................................................ 88 6.15.2 Vereinfachte Ausfhrung .......................................................................................... 89 6.16 SCCMCreateApp automatisches berfhren in SCCM 2012 ................................... 90 6.16.1 Umfang der Objekte ................................................................................................. 91 6.16.2 Die verschiedenen Environments ............................................................................... 91 6.16.3 Vorbereitungen zur Bedienung von SCCMCreateApp ................................................ 92 6.16.4 berfhrung in DEV und PRD.................................................................................... 92 6.16.5 Abhngigkeiten ........................................................................................................ 93 6.16.6 Refresh von Applications ........................................................................................... 94 6.16.7 Update Content ........................................................................................................ 95 6.16.8 Deploymenteinstellungen .......................................................................................... 96 6.16.9 Schematische Darstellung der erstellten Objekte ........................................................ 96 6.16.10 Lschen von Applications .......................................................................................... 97 6.16.11 SCCMCreateApp.INI ................................................................................................. 98 6.17 Testen eines Softwarepaketes ................................................................................. 102 6.17.1 INSTALL, REPAIR, REMOVE ...................................................................................... 102 6.17.2 Upgrade testen ....................................................................................................... 102 6.17.3 Lizenz und Aktivierungsstatus testen ....................................................................... 102 6.17.4 Manuelles Installieren im Systemkontext .................................................................. 103 6.18 Paketdokumentation erstellen ................................................................................. 103 6.19 Signierung und Einbindung von Treibern ................................................................. 103

    7 Spezialflle und besondere Eigenschaften......................................................... 104

    7.1 Paketvarianten ........................................................................................................ 104 7.1.1 Instanzvarianten...................................................................................................... 105 7.2 Package-Launcher Restart Manager ......................................................................... 107 7.2.1 Restart Manager Service .......................................................................................... 107 7.2.2 Restart Manager UI ................................................................................................. 107 7.3 Package-Launcher Error Wizzard ............................................................................. 110 7.3.1 Dauerhaftes Einschalten des Package-Launcher Error Wizzard .................................. 111 7.4 In Benutzung stehende Programme und Prozesse .................................................... 112 7.4.1 Einstellungen ber die INI-Datei ............................................................................... 112

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 5/122

    7.4.2 Standardoptionen ................................................................................................... 112 7.4.3 Objektoptionen....................................................................................................... 113 7.4.4 Dialoge ................................................................................................................... 114 7.4.5 Beispiele ................................................................................................................. 116 7.4.6 Registryeinstellungen .............................................................................................. 118 7.4.7 Welche Einstellung gewinnt? .................................................................................. 120 7.4.8 Ablauf des AppShutdown Managers ....................................................................... 120 7.4.9 ActiveSetup mit AppShutdown=ALL ........................................................................ 121 7.4.10 SCCM Wartungsfenster .......................................................................................... 121

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 6/122

    1 Vorwort

    In der Softwarepaketierung und bei der Installation und Verwaltung von Softwarepaketen spielen einfaches Handling, eine transparente Implementation, Effizienz und klare sowie bersichtliche Schnittstellen eine grosse Rolle. Mit dem Real Packaging Package-Launcher erstellen Sie robuste Softwarepakete mit automatisierbaren Schnittstellen und verwalten Ihre Updates und Upgrades. Dabei bietet er zahlreiche Erleichterungen und Automatismen, die die Paketerstellung vereinfachen, eine transparente Softwareverwaltung ermglichen und den Support vereinfachen. Das Servicemodell verfolgt neben vielen anderen Vorteilen vor allem ein Hauptziel: Die Optimierung des Softwarebereitstellungs- und Verteilungsprozesses.

    1.1 Ziel und Zweck dieses Dokumentes

    Das vorliegende Dokument dient als Referenz und Grundlage im Zusammenhang mit Fragen aus dem Bereich des Package-Launchers. Es werden alle Einstellungen und Verfahren aufgezeigt, welche zu einer erfolgreichen Anwendung von Softwarepakettransaktionen erforderlich sind.

    1.2 Abgrenzungen

    Die abgebildeten Einstellungen und Methoden zielen auf einen reibungslosen Betrieb in der Softwarepaketierung und im -Deployment des aktuellen Unternehmens, um Softwarepakete zu installieren und zu deinstallieren. Die hier skizzierten Softwarepakete erwarten in ihrem Design gewisse Schnittstellen und knnen in dieser Form nur mit dem Package-Launcher betrieben werden.

    Zum Lieferumfang des Package-Launchers gehren Scripts, um die Qualitt des erstellten Softwarepakete zu prfen und das Paket auf logische Konstistenzen zu prfen. Zudem werden mit einem weiteren Sciptloader SCCMCreateApp_Link.vbs alle Objekte in der SCCM-Infrastruktur erstellt. Auf die Verwendung dieser Scripts wird in diesem Dokument nicht oder nur ansatzweise eingegangen.

    1.3 Legende

    In kursiv geschriebene Wrter sind Namen, Fremdsprach- und Fachausdrcke, sowie Kapitelverweise. Auf Kapitelverweisen kann man mit Ctrl. + Mausklick dem Link folgen.

    1.4 Vorarbeiten

    Der Package-Launcher verwendet lokale Elemente. Vor Benutzung des Package-Launchers muss gewhrleistet sein, dass das Softwarepaket RealPackaging-PackageLauncher-2012 lokal installiert ist.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 7/122

    2 Methodische Betrachtung des Package-Launchers

    2.1 Umfang des Pakage-Launchers

    Der Package-Launcher besteht aus verschiedenen Elementen, die nur in sich als Ganzes einen logischen Zusammenhang ergeben. Viele der Elemente sind zur optionalen Verwendung gedacht und werden sich daher nicht in jedem Softwarepaket wiederfinden. Grundstzlich bernimmt das Startmodul, das SCCM-Launcher.vbs das Auslesen des Paket-Wurzel-verzeichnisses und das bergeben der Kommandozeile an LocalLauncher.EXE. Dieser erledigt schliesslich die zentralen Aufgaben. Nach Bedarf wird zudem auf die optionalen, durch den Software-Paketierer zur Verfgung gestellten Umgebungsscripte zugegriffen.

    2.2 Updates und Upgrades

    Die in diesem Dokument verwendeten Formen des Softwareaktualisierungsprozesses sind in Updates und Upgrades unterteilt. Mit einem Update ist eine Aktualisierungsform gemeint, die eine bestehend installierte Software installiert belsst und diese erweitert oder Ressourcen daraus verndert. Demgegenber steht der Upgrade von Anwendungen. Bei einem Upgrade handelt es sich um eine Aktualisierungsform, die in der Regel ein Softwareprodukt deinstalliert, um schliesslich ein neues Produkt zu installieren. Meistens werden solche Aktualisierungsformen bei einem neuen Softwarerelease angewendet (Major-Upgrade).

    Der Package-Launcher untersttzt Updates in Form von Revisionen, sogenannte Revisionsupdates. Die Realisierung solcher Updates war eine der zentralen Anforderungen an den Package-Launcher. Neben dieser Form der Softwareaktualisierung werden Upgrades in Form einer vorgngigen Deinstallation eines Vorproduktes ber zwei verschiedene Verfahren realisiert: den Package-Upgrade, der durch den Package-Launcher selbst gesteuert wird und den Major-Upgrade, der auf die Windows Installer Technologie zurckgreift.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 8/122

    2.3 Revisionsupdates

    Das Hauptziel von Revisionsupdates ist es, vom Auftraggeber beauftragte nderungsabsichten, Erweiterungen und Herstellerupdates, die nach einer Produktivsetzung (RTM) eines Softwarepakets appliziert werden sollten, in einer zustzlichen Revision abzubilden, ohne das getestete und eingefhrte Basispaket abndern zu mssen. Der Umfang eines Softwarepakets wird dann neu auf die Summe aller Teilrevisionen (siehe Abbildung) erweitert.

    Alle Revisionsupdates werden chronologisch und transaktional installiert und deinstalliert. Bei der Anwendung zustzlicher Revisionen erkennt der Package-Launcher den lokalen Installationsstatus und ergnzt die lokale Installation mit allen fehlenden Revisionen. Dieses Verfahren ist individuell und kann im Verlauf von Computer zu Computer unterschiedlich sein: Sollte beispielsweise ein Computer A den Installationsstatus einer Software der Revision 001 haben und ein anderer Computer B den Installationsstatus der Revision 002, so wird bei der Anwendung des gleichen Revisionsupdates auf die Revision 003 Computer A die Revision 002 und 003 erhalten, whrend Computer B automatisch nur deren Differenz 003 erhlt. Die berfhrung auf Revision 003 ist also einheitlich, die einzelnen lokalen Transaktionen, die zu diesem Ziel fhren sind hingegen unterschiedlich. Der Package-Launcher wird automatisch die richtig installierte Revision an SCCM zurckmelden, damit dort der Status aktualisiert wird.

    Durch das Verfahren der Revisionsupdates werden im Softwarebereitstellungsprozess bei Herstellerupdates oder nachtrglichen Erweiterungen nicht mehr zwei Formen von Softwarepaketen erforderlich ein Vollpaket fr alle, die das Produkt noch nicht installiert bekamen und ein Updatepaket fr alle Clients, die bereits das Produkt ohne Update besitzen: Es kann lediglich das bestehende Softwarepaket mit einer neuen Revision ergnzt und die neue Paketrevision mittels automatischem Script SCCMCreateApp_Link.vbs in SCCM berfhrt werden. Mit dieser Realisierung sind alle ntigen Hausaufgaben gemacht.

    Erste Produkteinfhrung mit Revision 001:

    Update auf Revision 002 :

    Soft

    war

    epak

    et

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 9/122

    2.4 Transaktionaler Installationsprozess

    Der Package-Launcher installiert die Revisionen des Softwarepakets transaktional. Wenn whrend der Installation einer Revision ein Fehler auftritt, so wird der Zustand vor der Installation dieser Revision wiederhergestellt und der Fehler wird in einer zentralen Protokolldatei ausgewiesen. Zudem erfolgt eine Rckmeldung der genauen Fehlermeldung an SCCM, so dass nach fehlerhaften Verteilungsaufgaben konkrete Rckschlsse auf die lokal vorliegenden Probleme mglich werden.

    Eine transaktionale Installation bedeutet, dass der Package-Launcher jede Revision immer vollstndig oder gar nicht installiert und diesen effektiven Status auch an SCCM zurckmeldet. Durch dieses Modell wird verhindert, dass der Client in einen unverwaltbaren Mischzustand gert. Beim Support oder beim Lsen von Strungen ist oft die Ausgangsbasis entscheidend. Wenn nun Anwendungsinstallationen in einem halb installierten, bzw. halbaktualisierten Zustand resultieren, knnen gerade solche Geisterinstallationen zu weiteren Folgefehlern beim Betrieb der Software und auch bei folgenden Installationsttigkeiten fhren. Das transaktionale Modell dient letztlich zur Erhaltung eines konsistenten Systems und verhindert viele Folgefehler bereits im Keim.

    Das transaktionale Verhalten wird folgendermassen realisiert:

    Der Package-Launcher berprft seine Umgebung vor der Ausfhrung von schreibenden und lschenden Operationen nach Richtlinien, die zur erfolgreichen nderung des Installationsstatus eingehalten werden mssen. Sollten Abhngigkeiten fehlen oder andere Richtlinien verletzt werden, wird dies an SCCM und im History.LOG rapportiert und die laufende Operation bricht ohne nderung ab.

    MSI-Installationen erfolgen durch den Windows Installer von Grund auf transaktional. Die durch den Softwarepaketierer applizierten Implementationen in PostInstall_00x.wse lsen im Fehlerfall ein Rollback aus, damit der Zustand vor der Installation wiederhergestellt wird. Nachfolgeprozesse werden nicht mehr ausgefhrt.

    Installationen ohne MSI-Datei (bspl. PreInstall_00x.wse) werden im Fehlerfall abgebrochen und Nachfolgeprozesse werden nicht mehr ausgefhrt. Der Paketierer bemht sich innerhalb der PreInstall_00x.wse um die Einhaltung des transaktionalen Modells, insbesondere, wenn vor Auftreten des Fehlers bereits auswirkungsrelevante Installationsaufgaben durchgefhrt wurden.

    3 Technische Betrachtung des Package-Launchers

    3.1 Hauptfunktionen des Package-Launchers

    Folgende Ttigkeiten kommen mit der Verwendung des Package-Launchers in ihrem Grundsatz zur Anwendung:

    Soft

    war

    e-P

    acka

    ge

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 10/122

    Untersttzung von verschiedenen Betriebssystemplattformen (x86/x64) und verschiedener Sprachausprgungen im selben Softwarepaket und Ermittlung des richtigen Paketverzeichnisses in Abhngigkeit des Real Packaging/Package-Launcher/MainLanguage-Keys und des Betriebssystems.

    MSI-Installationen: Alle allgemeinen MST-Dateien, sowie allfllige ResolveConflicts.MST anwenden.

    Protokollieren der Transaktionen nach %WINDIR%\Logs\History.LOG und der Installationen/Deinstallationen nach ..\Logs\Install/Uninstall\_.log

    Rckmelden des Installationsstatus und allflliger einzeiliger Fehlermeldung an SCCM. (immer in 32 Bit Registry, auch bei 64 Bit Clients!)

    Rckgabe eines qualifizierten Rckgabewertes an SCCM, welches die erfolgreiche Installation von einer nicht erfolgreichen Installation so unterscheiden kann.

    Lokales Zwischenspeichern des Softwarepaketes, wenn dies in der INI-Datei vermerkt ist und Entfernen lokal zwischengespeicherter Softwarepakete bei der vollstndigen Deinstallation, sowie beim Upgrade.

    Mglichkeit der Prfung nach Softwarepaketen, die vorgngig installiert sein mssen.

    Mglichkeit der Prfung nach Softwarepaketen, die nicht lokal installiert sein drfen.

    Anwendung von Berechtigungsanpassungen (ffnen der Security).

    Untersttzung von Updates in Form von Revisionen und automatischen Upgrades durch den Package-Launcher.

    Untersttzung von Installationselementen, die vor, bzw. solche die nach der Hauptinstallation erfolgen sollen (PreInstall_00x.wse und PostInstall_00x.wse)

    Auslesen und Anwenden von allgemeinen Einstellungen und Vorgaben ber eine INI-Datei, die den Namen des Softwarepaketes trgt.

    Verwalten von Neustarts mit Interaktion mit dem Benutzer.

    Trennung zwischen Entwicklungsumgebung und Produktionsumgebung beim berfhren der Softwarepakete.

    3.2 Bestimmen des richtigen Paket-Unterverzeichnisses

    Der Package-Launcher ermittelt das richtige Paket-Unterverzeichnis anhand der vorliegenden Verzeichnisstruktur, der lokalen Spracheinstellung in der Registry (Real Packaging/Package-Launcher/MainLanguage), sowie der verwendeten Plattform (x86 oder x64). Zuerst wird ermittelt, ob ein Paketverzeichnis mit dem selben Plattform/Sprachkrzel vorhanden ist, wie die Kombination, die der Client selbst verwendet. Auf einem x86-Client, mit deutscher Einstellung (GE) kme beispielsweise primr ein Unterverzeichnis mit dem Namen x86-GE zur Anwendung. Wenn kein identisches Unterverzeichnis im Softwarepaket vorgefunden wird, dann wird versucht, das Unterverzeichnis mit einem identischen Plattformtyp und der fr die aktuelle Spracheinstellung am hnlichsten vorgefundenen Sprache zu ermitteln. Die Sortierreihenfolge, die hier angewendet wird, ist folgende:

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 11/122

    Client 2. Wahl 3. Wahl 4. Wahl 5. Wahl

    GE ML EN FR IT

    FR ML GE EN IT

    IT ML FR GE EN

    EN ML GE FR IT

    Ist beispielsweise die lokale Plattform x64 und die verwendete Spracheinstellung GE, existieren aber mit dem x64-Bezeichner nur zwei Unterverzeichnisse mit der Bezeichnung x64-EN und x64-FR, dann wird x64-EN angewendet. Wird fr den aktuellen Plattformbezeichner kein einziges Unterverzeichnis gefunden, so wird bei x64 (und nur bei x64!) die Suche nach x86-Paketen erweitert.

    Sollte gar kein regelkonformes Verzeichnis gefunden werden, protokolliert dies der Package-Launcher im History.LOG mit der folgenden Fehlermeldung:

    "Package folder for this language not found! (GE)"

    Achtung

    Diese Meldung kann auch daher kommen, wenn im Explorer das Softwarepaket per Doppelklick ausgefhrt wird und im Kontext des Administrators nach Besttigung der UAC-Meldung kein Zugriff auf den Ablagepfad des Softwarepakets mglich ist!

    Beispiele:

    Aktuelle Plattform

    Aktuelle Sprache

    Vorgefundene und gewhltes Unterverzeichniss/e (fett=gewhltes Verzeichnis)

    x86 GE x64-EN,x64-GE, x86-GE, x86-FR, x86-IT

    x86 GE x64-EN,x64-GE, x86-IT, x86-FR

    x64 FR x86-GE, x86-FR, x86-IT

    x86 FR x64-GE, x64-FR, x64-IT -> Fehlermeldung in History.LOG (kein gltiges Verzeichnis gefunden)

    Achtung: Es wird immer nur ein Unterverzeichnis ausgewhlt!

    3.3 Kommandozeilenoptionen

    Die Kommandozeilenoptionen, die mit dem Start des Package-Launchers bergeben werden knnen, sind kombinierbar und fehlertolerant. Beim Aufruf spielt es grsstenteils keine Rolle in welcher Reihenfolge die Optionen eingegeben werden, ob gross- oder klein geschrieben wird und ob "/" oder "-" als Optionenkennzeichner verwendet werden. Sogar in sich ausschliessende Varianten (/x und /i - Deinstallation und Installation) sind in gewissem Masse zulssig: Dann gewinnt einfach die letzte bergebene Option der ausschliessenden Optionen. Neben den uns gebruchlichen Varianten sind auch die Optionen des Windows Installers in seiner Terminologie zulssig. Zustzliche Windows Installer Properties fr MSI-Installationen knnen im Testumfeld einfach angefgt werden (PROPERTY=VALUE). Generell bersteuern Kommandozeilen-Optionen die Einstellungen, die in der INI-Datei abgespeichert sind. Mit /? werden die Kommandozeilenoptionen angezeigt.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 12/122

    3.3.1 Folgende Kommandozeilenoptionen sind zulssig

    Option Beschreibung

    /i Installiert oder reinstalliert Produkt mit Fortschrittsanzeige. Ist die Applikation bereits auf dem System installiert, so wird die Installation ab der nchstfolgenden Revision im Rahmen eines Revisionsupdates gestartet (Differenz der installierten Version zu der zu installierenden Version)

    Ist das Produkt in der gleichen Revision wie die maximal verfgbare Revision aus der Paket-Source bereits korrekt auf dem System installiert, so wird eine Reparatur aller Revisionen ab Revision 001 ausgelst.

    ohne Parameter Entspricht /i (Bspl. Doppelklick auf SCCM-Launcher.vbs)

    /i:00x Installiert und/oder reinstalliert Produkt ab der Revision 00x. Durch diesen Mechanismus kann genau vorgegeben werden, ab welcher Revision die Installation starten soll. Es ist zur Installationszeit keine Source < 00x erforderlich.

    Bspl.

    installiert Kommandozeile Auswirkung 003 /i:004 installiert ab Revision 004 003 /i:005 Fehlermeldung in History.LOG 003 /i:003 - 003 wird repariert - 004 wird installiert (UPDATE, wenn vor- handen), sofern vorhanden, UPDATE bis Ende .

    /i:-00x Installiert und/oder reinstalliert Produkt bis und mit Revision 00x. Diese Option erlaubt die Verteilung des Produktes losgelst von der Installation durchzufhren. Wird ein Job so initiiert, so hat man Gewhr, dass bis zu der mit 00x angegebenen Revision, unabhngig weiterer verfgbarer Source installiert wird.

    Bspl.

    Paket-Source verfgbar Kommandozeile Auswirkung 005 /i:-004 installiert bis Revision 004 005 /i:-009 installiert bis und mit Revision 005, dann Fehler im History.LOG 004 /i:-005 Fehler im History.LOG

    /i:00x /i:-00x Kombination von Beginn bis Ende Revision.

    /s (/q) Installiert oder deinstalliert ohne Benutzerinterface.

    /e bersteuerung der Fehlermeldung REMOVE action is only valid for products which are currently installed. D.h. Deinstallation wird weitergefhrt

    /f Reparatur wird ausgelst. Achtung: Wird gleichzeitig eine Initialrevision vorgegeben (Bspl: /i:003), dann gewinnt die Vorgabe der Initialrevision!

    /x Deinstallation des Produktes. Deinstalliert das Produkt vollstndig rckwrts ab der letzten erfolgreich installierten Revision (003 -> 002 -> 001).

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 13/122

    Sollte bei der Deinstallation ein Fehler auftreten, so gilt das Produkt nachwievor als installiert und zwar bis zur letzten erfolgreich deinstallierten Revision minus 001.

    Achtung: Die Deinstallation kann, muss aber nicht mit dem Startmodul SCCM-Launcher.vbs initiiert werden. Die bevorzugte Methode ist, LocalLauncher.EXE direkt anzusprechen. Dies ermglicht die Deinstallation von Softwarepaketen ohne verfgbare Source.

    Bspl:

    %WINDIR%\Package-Launcher\Bin\LocalLauncher.EXE Adobe-Reader-9.3 /x

    /x:-00x Deinstalliert ab installierter Revision rckwrts bis und mit Revision 00x. installiert Kommandozeile Auswirkung 005 /x:-003 deinstalliert Revision 005, dann 004, dann 003

    /g Ermglicht, dass nur ein Entfernen von Paketen realisiert wird.

    Bspl. LocalLauncher.exe /G Upgrade=Adobe-Reader

    MainLanguage Gibt fr den Package-Launcher die Clientsprache (MainLanguage) vor, anstatt dass dieser den Wert aus der Registry liest.

    Bspl. MainLanguage=GE

    ForcedMainLanguage Setzt die Clientsprache (Registrykey) temporr auf den bergebenen Sprachkrzel. So ist gewhrleistet, dass auch AppSearch-Implementationen aus MSI-Dateien und Pre- oder PostInstall-Anweisungen, sowie Scripts, die auf den Registrykey prfen, reibungslos funktionieren.

    Bspl. ForcedMainLanguage=FR

    INI-Eintrge Upgrade, RemoveIncompatibleMsi, PlatformLangChange, UpgradeExitIfFailed, CopyLocal, AppVAutoStopProcesses, AllowDowngrade, Dependence & Incompatibilities, AppShutdown

    knnen statt aus der INI-Datei auch als Kommandozeilenoption angegeben werden. Die Kommandozeilenoption bersteuert die INI-Datei.

    Bspl: SCCM-Launcher.vbs Dependence=-

    PROPERTY Windows Installer Properties knnen der Kommandozeile bergeben werden, indem die Property, das Gleichheitszeichen = und der Zuweisungswert angefgt werden. Enthlt der Zuweisungswert ein Leerzeichen, so ist der Zuweisungswert in Anfhrungszeichen einzufassen.

    Bspl.: SCCM-Launcher.vbs INSTALLDIR="C:\Program Files\MyDir"

    VARIANTEN Wird ein einzelnes Wort ohne / und ohne = dem Befehlszeilenaufruf angefgt, so interpretiert dies der Package-Launcher als Variante.

    Bspl: SCCM-Launcher.vbs ADMIN

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 14/122

    3.3.2 Kommandozeilen-Beispiele

    Aufruf Auswirkung

    Doppelklick auf ..\Pack\SCCM-Launcher.vbs

    Sofern das Paket noch nicht installiert wurde, wird das Paket in allen in der Paket-Source verfgbaren Revisionen installiert.

    Ist das Produkt hingegen in einer kleineren Revision, als in der Paket-Source verfgbar, auf dem System installiert, so wird ein Revisionsupdate ab der installierten Revision bis zu der in der Paket-Source verfgbaren Revision durchgefhrt.

    Ist das Produkt in der gleichen Revision, wie die maximal in der Paket-Source verfgbaren Revision installiert, so wird eine Reparatur aller Revisionen bis zu der in der Paket-Source verfgbaren Revision ausgelst.

    ..\Pack\SCCM-Launcher.vbs /i Das selbe Verhalten wie oben abgebildet.

    ..\Pack\SCCM-Launcher.vbs /i INSTALLDIR=D:\ Paket wird in allen verfgbaren Revisionen installiert. Die Installation erfolgt mit der erweiterten Property INSTALLDIR, welche auf D:\ gesetzt wird.

    ..\Pack\SCCM-Launcher.vbs /i:-003 Ist das Paket noch nicht auf dem Client installiert, so wird das Paket bis und mit Revision 003 vollstndig installiert.

    Ist das Paket bereits in einer Revision < 003 auf dem System vorhanden, so wird ein Revisions-update bis 003 ausgefhrt.

    Ist das Paket bereits in der Revision 003 auf dem System vorhanden, so wird eine Reparatur bis und mit 003 ausgefhrt.

    Ist das Paket sogar mit einer hheren Revision auf dem System installiert, so resultiert ein Abbruch mit Fehlerausweisung im History.LOG: ERROR: Given Last Revision (003) is < installed Revision (004)

    ..\Pack\SCCM-Launcher.vbs /i:003 /s Das Paket wird ab Revision 003 silent ohne Benutzer-interface installiert. Ist 003 grsser als die installierte Revision + 1, dann wird mit Fehler abgebrochen.

    ..\Pack\SCCM-Launcher.vbs /i:002 /i:-003 Das Paket wird ab Revision 002 bis Revision 003 instal-liert. Fr alle zu installierenden Revisionen, die bereits auf dem System installiert sind wird eine Reparatur ausgelst, fr alle anderen Revisionen, die zudem > 001 sind wird ein UPDATE (Revisionsupdate) ausgelst.

    ..\Pack\SCCM-Launcher.vbs /x oder %WINDIR%\Package..\Bin\LocalLauncher.EXE Byron-SALZ-1.0.3 /x

    Das Paket wird komplett (alle Revisionen) deinstalliert.

    Achtung: Deinstallationen knnen auch direkt ber LocalLauncher.EXE auch ohne verfgbare Source abgesetzt werden:

    ..\Pack\SCCM-Launcher.vbs /x:-003 Das Paket wird rckwrts bis und mit Revision 003 deinstalliert.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 15/122

    3.3.3 Kommandozeilenempfehlung fr die Integration in SCCM

    Installation:

    SCCM-Launcher.vbs /i /q

    Revisionsupdate:

    SCCM-Launcher.vbs /q /i:00x (bspl. SCCM-Launcher.vbs /q /i:002)

    Deinstallation:

    %WINDIR%\Package-Launcher\Bin\LocalLauncher.EXE Byron-SALZ-1.0.3 /x /q

    Die Parameter unterscheiden sich in den angebrachten SCCM-Beispielen neben der Initialrevision bei Revisionsupdates nur durch den Silent-Switch. Dadurch wird verhindert, dass bei SCCM-Jobs dem Benutzer eine Fortschrittsanzeige angezeigt wird (Beispielsweise durch PostInstall_00x-CustomActions).

    Deinstallationen knnen mit dem lokalen Launcher ohne Verfgbarkeit der Paket-Source ausgefhrt werden. Auf einen Download durch SCCM kann somit verzichtet werden. Das Uninstall-Advertisement wird durch das Script Create_SCCM_Package_Link.vbs (SCCM 2007) daher mit der Option ohne vorherigen Download erstellt:

    Achtung: Die vorgngig dokumentierten Kommandozeilenoptionen werden derzeit automatisch beim Erstellen der SCCM-Application mit SCCMCreateApp_Link.vbs generiert!

    3.3.4 Rckgabewerte

    Der Package-Launcher gibt 5 verschiedene Rckgabewerte zurck:

    Rckgabewert Bedeutung

    1 Fehler vor Ausfhrung der effektiven Installationsttigkeit

    2 Fehler im Befehlszeilenaufruf

    3 Standardfehler, Details in History.LOG und Registry ersichtlich

    999 Paket RealPackaging-PackageLauncher-2012 ist lokal nicht installiert

    1618 Abbruch nach Prfung von Prozessen (CheckProcesses) Fast Retry in SCCM2012

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 16/122

    In der Registry legt der Package-Launcher unter HKLM\Software\Real Packaging\Package-Launcher\Packages\\MsiExecReturn zudem den Rckgabewert der letzten nicht erfolgreich ausgefhrten Windows Installer Transaktion des entsprechenden Pakets ab.

    3.4 Fehlermeldungen und History.LOG

    Der Package-Launcher weist ein genaues Fehlermanagement auf und ermglicht die schnelle Erkennung von allen Installationsfehlern an einem zentralen Ort oder ber SCCM. Ein Fehler wird immer via LogWriter.EXE im History.LOG ausgewiesen und in die Registry geschrieben.

    Viele Erkenntnisse aus dem Paketierungsbetrieb flossen in die Erarbeitung des Package-Launchers. So ist es beispielsweise technisch nicht mglich, dass der Package-Launcher ber eine zweite Instanz versucht, gleichzeitig eine zweite Installation auf dem gleichen Client zu starten und so das transaktionale Modell unterlaufen knnte. Dieser Fehler wird vorher abgefangen. Auch Installationen von Produkten, die mit gleichem ProductCode bereits (oder noch?) auf dem System installiert sind (bspl. Handinstallationen), seien diese fr den Computer oder fr einen Benutzer installiert, werden erkannt und knnen wahlweise automatisch deinstalliert werden oder zum dokumentierten Abbruch der aktuellen Installation fhren. Auf die durch solche Fehler entstehende mhsame Fehlersuche kann daher knftig verzichtet werden. Problematisch wren solche Situationen vor allem dort gewesen, wo das Produkt in einer vernderten Fassung (keine erweiterten CustomActions, andere Einstellungen, etc.), beispielsweise wie vom Hersteller geliefert, ausserhalb der Mechanismen des Unternehmens (Package-Launcher) installiert wrden und dann das gleiche Produkt in Form eines Package-Launcher-Installationspakets htte installiert werden sollen. Dadurch, dass Windows Installer bei der Installation des Installationspakets auf die gecachete Variante zugreifen wrde, knnte nicht selten ein Zustand oder Abbruchsverhalten entstehen, welches schwer analysierbar und auch reparierbar wre. Daher wird per Standard im Einsatz mit dem Package-Launcher ein solcher Zustand im History.LOG ausgewiesen und die aktuelle Operation abgebrochen.

    Bei einem entstandenen Fehler durch den Windows Installer Installationsprozess erfolgt durch den Pakage-Launcher die Auswertung der Windows Installer Protokolldatei. Der ermittelte Reintext der Fehlermeldung wird nun an SCCM rapportiert und ebenfalls in der Datei History.LOG ausgewiesen. Dies gestattet einen einfacheren Support, kann in SCCM aber auch zu Statistikzwecken verwendet werden. Zudem wird erst dadurch eine robuste Verwaltung der Softwareinstallationen mittels SCCM mglich.

    3.4.1 History.LOG

    Die zentrale Protokolldatei zeigt bersichtlich den Transaktionsverlauf aller Softwareinstallationen dar. Ob, wann und wie eine Transaktion ausgefhrt wurde, dies alles finden wir in der zentralen Datei %WINDIR%\Logs\History.LOG. Aufgrund des transaktionalen Modells finden wir denn auch in der Regel genau eine Zeile pro Transaktion. Der Aufbau sieht folgendermassen aus:

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 17/122

    Ansicht History.Log mit dem History.LOG Viewer:

    Neben dem Status Error und Success kann der Software-Paketierer mittels Vorlagen im PreInstall_00x.wse und PostInstall_00x.wse auch noch eine Informationszeile (Information) ausgeben. Andere Statusmeldungen sind nicht erlaubt. Das History.LOG wird durch das externe Programm %WINDIR%\Package-Launcher\Bin\LogWriter.EXE geschrieben. Dadurch wird externen Prozessen der schreibende Zugriff auf das History.LOG ermglicht. Mittels %WINDIR%\Package-Launcher\Bin\LogViewer.EXE kann die Protokolldatei in bersichtlicher Form angezeigt werden.

    3.4.2 Bedeutung von Fehlermeldungen

    In der folgenden Tabelle werden einige History.LOG Fehlermeldungen beschrieben. Und zwar nur solche, die nicht aufgrund einer MSI-Fehlermeldung entstehen (alphabetisch aufsteigend sortiert):

    Fehlermeldung Bedeutung

    %WINDIR%\Logs not exist for package logfile Auf Logfile-Pfad kann nicht zugegriffen werden.

    abnormal Exception! ....... Aussergewhnlicher Fehler mit weiteren Angaben.

    A REPAIR can only be performed for products which are installed successfully!

    Das gewhlte, fr eine Reparatur vorgesehene Paket ist auf diesem Client gar nicht installiert.

    A REMOVE can only be performed for products which are installed successfully!

    Das gewhlte, fr eine Deinstallation vorgesehene Paket ist auf diesem Client gar nicht installiert.

    Cannot open package. Is it in use? Auf die MSI-Datei konnte nicht zugegriffen werden. Mglicherweise ist die Datei geffnet.

    Copy source to local drive failed! Das aufgrund der Einstellung CopyLocal=True beauftragte lokale Kopieren des Softwarepakets in das Verzeichnis %WINDIR%\PackageLauncher-\Cache konnte nicht durchgefhrt werden.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 18/122

    Error during determine ProductCode! Der ProductCode der zu installierenden An-wendung konnte nicht ermittelt werden.

    Given Initial Revision (003) is > Installed Revision (001) + 1

    Initialrevision (/i:003) muss Installed Revision (002)

    Ein ber /x:-003 angegebene Deinstallation kann nicht ausgefhrt werden, da die momentan installierte Revision kleiner ist, als die verlangte EndRevision.

    Given Last Revision (003) is < installed Revision (004)

    Lastrevision (/i:-003) muss >= aktuell installierte Revision betragen

    I/O Exception while copying HP-Soft-1.0_001.cmd Fehler beim Kopieren des Security-Batches.

    I/O Exception while copying files to ..\Package-Launcher\Scripts path!

    I/O Exception while sync files in ..\Package-Launcher\Scripts path!

    Fehler beim Aktualisieren oder Lschen von PreInstall,PostInstall Scripts-Verzeichnis.

    Incompatible Application installed (Byron-HIP-1.0) Ein in der INI-Datei unter Incompatibilities ver-merktes Softwarepaket wurde auf diesem Client installiert vorgefunden.

    Installation source for Revision 003 not exist Es konnte eine von Initalrevision (/i:003) oder LastRevision (/i:-003) verlangte Revision nicht in der Paket-Source vorgefunden werden.

    Invalid command line arguments for MSIEXEC.EXE.

    Falsche Kommandozeilenparameter wurden ber-geben oder wurden ber MsiInstallProperties in der INI-Datei deklariert.

    Invalid Installation/Remove command line arguments: overflow exception!

    Unzulssige Zeichen in der Kommandozeile ver-wendet.

    Nothing made! No valid source found! (argLine: Byron-HIP-1.0 c:\Temp /s /qb)

    Es wurde nichts ausgefhrt. Grnde sind un-bekannt (keine untersttzte Installationsdateien im Revisionsverzeichnis vorhanden?))

    Other Windows Installer process in progress! Try again later.

    Im Hintergrund luft bereits eine Installation oder eine Windows Installer Reparatur.

    Package folder for this language not found! (GE) Es konnte kein geeignetes Paket-Unterverzeichnis gefunden werden.

    PreRequisite Software not installed (Byron-HIP-1.0) Eine in der INI-Datei unter Dependence ber-gebene Applikationsabhngigkeit ist auf dem Client nicht installiert.

    REMOVE action is only valid for products that are currently installed. This Revision isn't installed at this time!

    Die Deinstallation der aktuellen Revision kann nicht ausgefhrt werden, da sie zurzeit gar nicht mehr installiert ist.

    REMOVE of incompatible MSI has returned with failure. Please check Byron-HIP-1.0_001.INCOMPATIBLE.TXT

    Fehler whrend der automatischen Deinstallation fremdinstallierter Software (Pakete, welche nicht durch den Package-Launcher auf dem System installiert wurden). Dieser Mechanismus wird ber den INI-Eintrag oder die Kommandozeilenoption RemoveIncompatibleMsi=True initiiert.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 19/122

    Terminalserver is in EXECUTE mode. Switch to INSTALL mode!

    Beim Installationsziel handelt es sich um einen Terminalserver. Der Terminalserver muss aber vor der Paketinstallation zuerst mit change USER /INSTALL in den Installation mode gebracht werden.

    The ProductCode of this Revision is used in other Revision (Byron-HIP-1.0_002)!

    Der Paketierer verwendet eine ungltige MSI-Datei in einem bestimmten Revisionsverzeichnis.

    The program cannot be started several times. LocalLauncher.EXE already running with following application: "Byron-HIP-1.0". Try again later.

    Es wurde versucht eine Installation zu ttigen, obwohl parallel oder im Hintergrund bereits eine Installation luft.

    This application is already installed by other package. Please remove other package (Adobe-Reader) and try again!

    Das Produkt ist unter einem anderen Paketnamen bereits auf diesem Client installiert. Bitte Paketierung melden!

    This application is already installed manually or by other processes. Please remove the product first (msiexec /x {1F6435C5-429D-42E5-B0B7-CBEAEE66EA0F}) or set INI entry RemoveIncompatibleMsi to 'True'

    Die Applikation wurde auf diesem System bereits in anderer Form, als durch eine regulre Paket-variante installiert oder die zu installierende Ver-sion wurde in installiertem Zustand unter anderem Namen vorgefunden.

    Durch Setzen des INI-Eintrages oder der Komman-dozeilenoption RemoveIncompatibleMsi=True kann ein automatisches vorgngiges Deinstallieren erwirkt werden.

    This package is installed in other language. Please remove old package first! (Old package: x86-GE This package x86-ML)

    Dieses Softwarepaket wurde auf diesem Client bereits installiert. Bei der letzten Installation wurde aber ein anderer Plattform/Sprachfolder verwen-det. Entfernen Sie das bestehende Paket zuerst.

    This package requires a reboot after the instal-lation of following products: Byron-HIP-1.0

    Gemss Vorgabe in der INI-Datei muss eine Ab-hngigkeit installiert und danach ein Reboot aus-gelst sein, damit dieses Softwarepaket installiert werden kann. Diese Bedingung trifft auf diesem Client nicht zu.

    Unable to determine if this installation is a Small Update or Minor Upgrade to installed Product {B23C702D-2BB9-42F7-818A-7EFE88BA7371}. Error while open cached msi ...

    Wenn ein Paket mit dem selben ProductCode bereits installiert ist, das lokal gecachte MSI aber nicht geffnet werden kann, erscheint diese Meldung.

    Unexpected Error during execution of PreInstall Nicht lokalisierbarer Fehler bei der Ausfhrung von PreInstall. PreInstall hat einen Fehlercode zu-rckgeliefert, der Fehlermeldungseintrag unter HKLM\...\Packages\PKG\Error fehlt aber.

    Unexpected Error during execution of install.msi (Return value 2099)

    Unbekannter Fehler whrend der Ausfhrung des MSIs. Die Ausfhrung von MSIEXEC lieferte nicht 0 zurck, in der Protokolldatei ist aber kein Fehlertext erkenntlich.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 20/122

    3.5 INI-Datei

    In der INI-Datei des Softwarepakets werden Einstellungen definiert, die fr die Installation des Softwarepakets relevant sind. Die INI-Datei wird im Wurzelverzeichnis des Softwarepakets abgebildet und trgt den Namen des Softwarepakets. Bspl. Byron-HIP-1.0.INI. Wie mit den wichtigsten Bezeichnern umgegangen wird und wie sie im Softwarepaket eingesetzt werden, finden Sie im Kapitel 6.14 INI-Datei des Softwarepakets.

    3.5.1 Zusammenfassung der wichtigsten INI-Eintrge

    Anbei finden sich die gngigen Keys unter der Section Install. Fr alle nicht unter der Section Install zu verwendenden Keys ist die Section in Klammer angegeben:

    Key InstallFile

    Einsatz Optional

    Beschreibung Hier kann die Bezeichnung der MSI-Datei angegeben werden. Der Wert ist optional. D.h., wenn er leer ist, dann wird vom Package-Launcher die erstbeste MSI-Datei verwendet, die im Revisionsverzeichnis vorgefunden wird. Ist der Eintrag angegeben, so wird primr nach der MSI-Datei gesucht, die wie angegeben benannt ist. Nur wenn keine solche gefunden wird, wird die Suche auf andere Dateinamen ausgeweitet.

    Eine Mglichkeit der Verwendung ist die, dass man im selben Revisionsverzeichnis neben einer Installations-MSI, noch eine MSI verwendet, die zur Installation von UserSettings vorgesehen ist und bei der durch den Package-Launcher initiierten Installation selbst nicht zu installieren ist. Der Package-Launcher wird dann angewiesen, die andere, im selben Verzeichnis befindliche MSI-Datei zu installieren.

    Beispiel InstallFile=install.msi

    Key CopyLocal

    Einsatz Optional (TrueFalse)

    Beschreibung Steht der Eintrag auf True, dann wird die Source des kompletten Softwarepaketes lokal nach %WINDIR%\Package-Launcher\Cache\ kopiert.

    Bei einer Active-Setup-Implementation kann so zum Beispiel gewhrleistet werden, dass die Source nach der Installation fr die Benutzerkonfiguration zur Verfgung steht.

    Achtung: Es kann nur ein komplettes Paket zwischengespeichert werden! Die lokale Source wird bei einer kompletten Deinstallation automatisch entfernt.

    Beispiel CopyLocal=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 21/122

    Key Reboot

    Einsatz Optional (TrueFalse)

    Beschreibung Steht der Eintrag auf True, dann wird nach der Installation des Softwarepaketes der Eintrag MakeReboot in der Registry gesetzt. Dieser Key wird vom Package-Launcher Restart Manager verwendet, um den Benutzer dafr aufzufordern, einen Neustart des Computers auszulsen. Im abgemeldeten Zustand wird der Neustart automatisch ausgelst.

    Achtung: Wird keine Revision am Bezeichner angegeben, so erfordert das Schreiben des Registrykeys nach Beendigung der kompletten Installation. Soll der Key nur bei einer spezifischen Revision geschrieben werden, so kann dies mittels Reboot_00x=True bewerkstelligt werden.

    Beispiel Reboot_002=True

    Key Logoff

    Einsatz Optional (TrueFalse)

    Beschreibung Steht der Eintrag auf True, dann wird nach der Installation des Softwarepaketes der Registry-Eintrag MakeLogoff in der Registry gesetzt. Dieser Key wird vom Package-Launcher Restart Manager verwendet, um den Benutzer dafr aufzufordern, sich neu anzumelden.

    Beispiel Logoff=True

    Key Dependence

    Einsatz Optional

    Beschreibung Dieser Bezeichner ist mit den Paketnamen zu ergnzen, welche als Abhngigkeit dieser Applikation fungieren. Ein einzelner Paketname kann auch nur eine Teilbezeichnung der Applikation enthalten. Die verschiedenen Abhngigkeiten sind mit einem Lehrzeichen aneinanderzufgen. Die Abhngigkeiten knnen mit dem OR Operator verknpft. Der Package-Launcher prft vor der Installation, ob all diese Abhngigkeiten lokal installiert sind. Beachten Sie auch die Ausfhrungen unter Kapitel 6.14.3 Umgang mit Abhngigkeiten.

    Neben dieser Funktionalitt werden ber den selben Bezeichner beim berfhren des Softwarepakets zustzlich die so deklarierten Abhngigkeiten in den Deploymenttype der Application eingetragen (SCCM 2012).

    Beispiel Dependence=Adobe-AcrobatReader Acresso-InstallScriptMSIEngine

    Key DependenceReboot

    Einsatz Optional

    Beschreibung Wie Primrfunktion aus Dependence, nur muss gewhrleistet sein, dass nach der Installation dieser Abhngigkeit bis zur Installation dieses Produktes mindestens ein Reboot des Computers ausgefhrt wird.

    Ergibt die Prfung durch den Package-Launcher False, dann wird folgende Meldung ins History.LOG geschrieben: This package requires a reboot after the installation of following products: PackageName-Version

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 22/122

    Key TaskSequence

    Einsatz Optional

    Beschreibung ber den Bezeichner TaskSequence ist es mglich, einen zum Dependence-Eintrag abweichenden Aufbau der Abhngigkeiten anzufhren, die fr die automatische Erstellung der Customized Task Sequence beim berfhren des Softwarepakets verwendet werden (SCCM 2007) und fr RPI-Installationen gelten soll. Die Abhngigkeiten werden der Reihe nach ausgewertet.

    Wird der Eintrag nicht verwendet, so wird stattdessen der Dependence-Eintrag interpretiert.

    Beispiel Dependence=SAP-SAPGUI TaskSequence= Microsoft-VCRedist-2008 SAP-SAPGUI

    Key Incompatibilities

    Einsatz Optional

    Beschreibung Ist mit den Paketnamen zu ergnzen, welche nicht installiert sein drfen. Der Paketname kann auch nur ein Teilstring der Applikation enthalten. Die verschiedenen zu dieser Applikation inkompatiblen Paketnamen sind mit einem Leerzeichen aneinanderzufgen. Die Incompatibilities knnen mit dem AND Operator verknpft werden (siehe 6.14 INI-Datei des Softwarepakets )

    Beispiel Incompatibilities=iTunes QuickTime

    Key Upgrade

    Einsatz Optional

    Beschreibung Dieser Key bestimmt, welche Softwarepakete der Package-Launcher in Form eines Package-Upgrades vor einer Installation entfernt. Dies ist die favorisierte Variante, Softwareprodukte im Rahmen eines Upgrades zu entfernen. Nicht Package-Launcher kompatible Pakete knnen durch Hinzufgen des oder der {ProductCodes} entfernt werden.

    Achtung: Fehlt dieser Key oder ist er leer, so wird bei der Ausfhrung von AddProperties.vbs die MS/MST-Datei modifiziert, um einen Major-Upgrade in Form von Windows Installer Erweiterungen zu applizieren!

    Fr die korrekte Bereinigung der Inventarisierungsregistrykeys ist im Rahmen eines Major-Upgrade eine Custom Actions zustndig wird hingegen ein Package-Upgrade durchgefhrt, so erledigt der Package-Launcher diese Aufgaben direkt.

    Beispiel Upgrade=Adobe-AcrobatReader Acresso-InstallScriptMSIEngine

    Key RemoveIncompatibleMsi RemoveIncompatibleMsiUPG

    Einsatz Optional

    Beschreibung Entfernt Produkte, die mit dem selben ProductCode ausserhalb der Mechanis-men des Package-Launchers installiert sind (RemoveIncompatibleMsi), bzw. entfernt im Rahmen eines Package-Upgrades alle MSI-Installationen, die den selben UpgradeCode (RemoveIncompatibleMsiUPG) verwenden.

    Beispiel RemoveIncompatibleMsi=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 23/122

    Key MsiInstallProperties

    Einsatz Optional

    Beschreibung Public Windows Installer Properties knnen so fr die Installation bergeben werden. Zwischen zwei Properties ist ein Leerzeichen einzufgen. Public Properties sind in Grossbuchstaben zu verwenden.

    Achtung: Durch Anfgen des Revisionsbezeichners knnen fr einzelne Revisionen unterschiedliche Properties bergeben werden. (Bspl. MsiInstallProperties_002=USER=Admin)

    Beispiel MsiInstallProperties=SERVER=SB0004

    Key MsiRepairProperties

    Einsatz Optional

    Beschreibung Public Windows Installer Properties knnen so fr die Reparatur bergeben werden. Zwischen zwei Properties ist ein Leerzeichen einzufgen. Public Properties sind in Grossbuchstaben zu verwenden.

    Achtung: Durch Anfgen des Revisionsbezeichners knnen fr einzelne Revisionen unterschiedliche Properties bergeben werden. (Bspl. MsiIRepairProperties_002=USER=Admin)

    Beispiel MsiRepairProperties=REINSTALLMODE=vomus (Das MSI wird recached)

    Key MsiRemoveProperties (Section Remove)

    Einsatz Optional

    Beschreibung Public Windows Installer Properties knnen so fr den Remove bergeben werden. Zwischen zwei Properties ist ein Leerzeichen einzufgen. Public Properties sind in Grossbuchstaben zu verwenden.

    Achtung: Durch Anfgen des Revisionsbezeichners knnen fr einzelne Revisionen unterschiedliche Properties bergeben werden. (Bspl. MsiIRemoveProperties_002=USER=Admin)

    Beispiel MsiRemoveProperties=SERVERDELETE=SB0004

    Key MsiPatchProperties

    Einsatz Optional

    Beschreibung Public Windows Installer Properties knnen so fr den Patch bergeben werden. Zwischen zwei Properties ist ein Leerzeichen einzufgen. Public Properties sind in Grossbuchstaben zu verwenden.

    Standardmssig werden fr die Anwendung von Patches folgende Properties verwendet (falls nicht angegeben): REINSTALL=ALL REINSTALLMODE=omus

    Achtung: Durch Anfgen des Revisionsbezeichners knnen fr einzelne Revisionen unterschiedliche Properties bergeben werden. (Bspl. MsiPatchProperties_002=USER=Admin)

    Beispiel MsiPatchProperties=REINSTALL=ALL REINSTALLMODE=omus INSTALLDIR=D:\

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 24/122

    Key UpgradeExitIfFailed

    Einsatz Optional (TrueFalse)

    Beschreibung Wenn im Rahmen eines Package-Upgrades eine vorher zu installierende Anwendung bei der Deinstallation einen Fehler auslst, wird ohne Angabe dieses Bezeichners, die Installation des fokussierten Pakets weiter fortgesetzt. Sollte der Softwarepaketierer hingegen einen Abbruch der Installation mit Meldung im History.LOG wnschen, dann setzt er den Eintrag auf True

    Beispiel UpgradeExitIfFailed =True

    Key PlatformLangChange

    Einsatz Optional

    Beschreibung Wird dieser Bezeichner in Form von PlatformLangChange=True implementiert, kann folgende Fehlermeldung bei einer Erweiterung eines Platform- oder Sprachverzeichnisses unterdrckt werden:

    This package is installed in other language. Please remove old package first!

    Das macht dann Sinn, wenn nach Einfhrung und Verteilung des RTM-Paketes durch den Softwarepaketierer nachtrglich neue Plattform- oder Sprachordner hinzugefgt werden, die kompatibel zur Vorgngerrevisin der anderen Plattform, bzw. Sprache sind. (Achtung: Deinstallation prfen, nachdem auf einem Gert die alte Ausprgung des Pakets mit der neuen Ausprgung geupdatet wurde).

    Beispiel PlatformLangChange=True

    Key UpgradeProperty

    Einsatz Optional

    Beschreibung Bei einem Package-Upgrade knnen fr die DeInstallation des alten Paketes zustzliche Properties bergeben werden. Diese sind diesem Bezeichner anzufgen.

    Beispiel UpgradeProperty=REBOOT=ReallySuppress

    Key UpgradeInRevision

    Einsatz Optional (TrueFalse)

    Beschreibung Soll eine Revision einen Major-Upgrade der Revision 001 durchfhren und wurde in der Revision 001 ein Pre- oder PostInstall verwendet, so verhindert dieser Bezeichner, wenn er auf True gesetzt ist, dass beim Installieren der neuen Revision die Inhalte aus dem Scripts, Security und Cache Verzeichnisses im Rahmen des Upgrades gelscht werden.

    INSTALL 001 INSTALL 002 REMOVE 001 (Inst. der Rev.003, die ein Major-Upgrade ausfhrt) INSTALL 003

    Beispiel UpgradeInRevision=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 25/122

    Key ScriptAdditionalUpgrades

    Einsatz Optional

    Beschreibung Hierbei handelt es sich um eine Anweisung fr das Script AddProperties.vbs! Unter dieser Property kann der Paketierer Namen von Softwarepaketen anfgen, die nach den Richtlinien fr Package-Launcher v2.2 Pakete erstellt wurden. Die UpgradeCodes dieser Namen werden durch AddProperties.vbs in der MSI/MST der Revision 001 unter der Upgrade-Tabelle angefgt, um zustzlich beim Major-Upgrade fremde Produkte zu deinstallieren. Auf die Versionsangabe kann optional verzichtet werden Dann werden alle Versions-Verzeichnisse bercksichtigt.

    Achtung: Beim standardmssig verwendeten Package-Upgrade kann auf den Einsatz dieses Bezeichners verzichtet werden!

    Beispiel ScriptAdditionalUpgrades=Byron-HIP

    Key ScriptUpgradeCode

    Einsatz Erforderlich

    Beschreibung Hierbei handelt es sich um eine Anweisung fr das Script AddProperties.vbs! Der Eintrag bestimmt den UpgradeCode des Produktes. Alle Produktrevisionen und alle Produktversionen, also die komplette Produktfamilie verwenden den selben UpgradeCode. Dieser Eintrag wird durch das Script AddProperties.vbs erstellt und sollte (ausser mit False nicht verndert oder gelscht werden!! Wird der Bezeichner auf 'False' gesetzt, wird der UpgradeCode im Original belassen!

    Beispiel ScriptUpgradeCode={1F6435C5-429D-42E5-B0B7-CBEAEE66EA0F}

    Key MultiVariants

    Einsatz Optional (TrueFalse)

    Beschreibung Wird ein Instanzvariantenpaket erstellt, welches die Installation von verschie-denen Ausprgungen von ein und demselben Paket untersttzt (siehe Kapitel 7.1.1 Instanzvarianten), dann ist dieser Bezeichner auf True zu setzen.

    Beispiel MultiVariants=True

    Key ReadMsiSectionPropertiesByREMOVE

    Einsatz Optional (TrueFalse)

    Beschreibung Standardmssig werden Sectionproperties bei der DeInstallation von Windows Installer MSI-Dateien nicht eingelesen. Wird dieser Bezeichner auf True gesetzt, werden die Windows Installer Properties auch bei der Deinstallation eingelesen und an msiexec.exe weitergegeben.

    Der Bezeichner existiert nur aus Grnden der Abwrtskompatibilitt.

    Beispiel ReadMsiSectionPropertiesByREMOVE=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 26/122

    Key ExecuteFile

    Einsatz Optional

    Beschreibung Mit diesem Bezeichner ist es mglich, Scripts im Revisionsverzeichnis des Softwarepakets oder ein lokales Programm auszufhren. Als Scripts knnen *.cmd, *.bat, *.ps1, *.vbs oder andere Varianten verwendet werden. Erforderlich ist, dass dem System die Dateierweiterung bekannt ist.

    Jeder im Script auswewiesene Rckgabewert (0 oder 3010 oder 1641) wird vom Package-Launcher als fehlerhafte Ausfhrung interpretiert und mit einer Fehlermeldung im History.LOG quittiert. Im Zweifelsfall ist der Rckgabewert als letzte Aktion im Script durch den Paketierer festzulegen (bspl. Exit 0 bei einem CMD). Sollen mehrere einzelne Steps mit einer Rckgabewertprfung installiert werden, kann das vorgesehene Script in mehrere Einzelscripts auf-geteilt werden:

    Bspl:

    ExecuteFile_001=install.cmd ExecuteFile_002=install.cmd

    Oder auch nur

    ExecuteFile=install.cmd, wenn ein einziges install.cmd in verschiedenen Revisionsverzeichnissen abgelegt wird, welches chronologisch zum Einsatz gelangen soll

    In der INI-Datei werden neben Standard-Environmentvariablen folgende Variablen untersttzt:

    %SOURCE%, %CACHE%, %PACKAGE%, %REVISION%, %LANGUAGE%, %LOGFILE%, %VARIANTSECTION%, %TASK%

    %SOURCE% enthlt den Sourcepfad der aktuellen Installation, bzw. deren Installation. Bspl. C:\Windows\ccmcache\4\ x86-ML\002. Wird CopyLocal=True verwendet, dann wird der zwischengespeicherte und fr die Installation massgebliche Pfad zurckgegeben: Bspl. C:\Windows\Package-Launcher\Cache\TWI-FBMS-1.0\x86-ML\002.

    %CACHE% enthlt bei Verwendung von CopyLocal=True das Revisions-verzeichnis des zwischengespeicherten Pfades. Wird CopyLocal=True nicht verwendet, ist die Variable leer.

    Der Bezeichner ExecuteFile kann in der [Install]- und [Uninstall]-Section ver-wendet werden.

    Achtung: Bei Verwendung eines im Paketverzeichnis abgelegten Scripts oder verwiesenen Daten, die im Paketverzeichnis abgelegt sind, auf welche im Rahmen einer Deinstallation zugegriffen werden soll, ist zustzlich die Anweisung CopyLocal=True notwendig.

    Achtung: Wird keine Revision am Bezeichner angegeben, so wird in allen vor-gefundenen Revisionsverzeichnissen nach dem Namen der in der INI angegebenen Datei gesucht. Werden in Revisionsverzeichnissen unterschied-liche Namen von Scripts verwendet, so kann dies mit dem Bezeichner ExecuteFile_00x= bewerkstelligt werden. Es wird generell der Einsatz des Revisionspostfixes empfohlen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 27/122

    Beispiel ExecuteFile=install.cmd "%CACHE%\Files" ExecuteFile_003=installx.cmd "%ProgramFiles%\Datango" ExecuteFile_004=regedit /s "%SOURCE%\test.reg"

    Key PreScript/PostScript

    Einsatz Optional

    Beschreibung Mit diesem Bezeichner ist es ebenfalls mglich, Scripts im Revisionsverzeichnis des Softwarepakets oder ein lokales Programm auszufhren. Es gelten die selben Regeln wie beim Bezeichner ExecuteFile. (Der Bezeichner PreScript darf nicht zusammen mit ExecuteFile verwendet werden (entweder oder).

    PreScript fhrt ein Script aus, welches vom Package-Launcher vor einer Installation von untersttzten MSI/MSP/MSU/APPV-Ressourcen im selben Revisionsverzeichnis zur Ausfhrung gelangt. Whrend das ber PostScript deklarierte Script im Anschluss einer untersttzten Ressource, die im selben Revisionsverzeichnis abgelegt ist, ausgefhrt wird.

    In Scripts und der INI-Datei knnen alle Environmentvariablen verwendet werden. Zustzlich stehen zum Ausfhrungszeitpunkt weitere Variablen zur Verfgung (%CACHE%, %REVISION%, %PAKAGE%, %LOGFILE%, etc.). Es kann auch auf lokal installierte Programme zugegriffen werden, indem diese als Einzeiler integriert werden.

    Beispiele [Install] PostScript_001=config.cmd PreScript_002=REG.exe ADD HKLM\Software\Lithium /v WarpSpeed /d "1" /f PostScript_003=%WINDIR%\sysnative\cmd.exe /c "C:\Program Files\XF\hf.exe" PostScript_004=powershell.exe "%CACHE%\MyScript.ps1"

    [UnInstall] ExecuteFile=cmd /c exit

    Key ActiveSetupScript_00x (Section Install)

    Einsatz Optional

    Beschreibung Hier kann ein Script oder lokales Programm angegeben werden, welches ausgefhrt werden soll. Dieses Script wird in der Registry in HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\ im Active-Setup eingetragen. So sind Benutzerressourcen applizierbar. Bei Verwendung eines im Paketverzeichnis abgelegten Scripts, ist zustzlich die Anweisung CopyLocal=True notwendig.

    In der INI-Datei werden neben Standard-Environmentvariablen folgende Variablen untersttzt:

    %SOURCE%, %CACHE%, %PACKAGE%, %REVISION%, %LANGUAGE%, %LOGFILE%, %VARIANTSECTION%, %TASK%

    %SOURCE% enthlt den Sourcepfad der aktuellen Installation, bzw. deren Installation. Bspl. C:\Windows\ccmcache\4\ x86-ML\002. Wird CopyLocal=True verwendet, dann wird der zwischengespeicherte und fr die Installation massgebliche Pfad zurckgegeben: Bspl. C:\Windows\APSPack\Cache\TWI-FBMS-1.0\x86-ML\002.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 28/122

    %CACHE% enthlt bei Verwendung von CopyLocal=True das Revisions-verzeichnis des zwischengespeicherten Pfades. Wird CopyLocal=True nicht verwendet, ist die Variable leer.

    In einem Script werden diese Environmentvariablen nicht direkt untersttzt, knnen aber via Kommandozeilenparameter dem Script bekannt gemacht werden. Der Revisionstoken _00x ist fr diesen Bezeichner zwingend!

    Beispiel ActiveSetupScript_001=myscript.cmd "%CACHE%\My Files" %PACKAGE%

    Key EnableMSU (Section Install & UnInstall)

    Einsatz Optional (TrueFalse)

    Beschreibung Durch diesen Bezeichner werden Hotfixe in Form von MSU-Dateien direkt untersttzt. Ab August 2012 wird der Bezeichner standardmssig implementiert. Fr alte Pakete, wo .MSU-Dateien durch ein PreInstall ausgefhrt werden, ist der Bezeichner auf False zu stellen. Mchte man die Deinstallation des Hotfixes im Rahmen der Paketdeinstallation nicht ausfhren, so kann der Bezeichner in der UnInstall-Sektion entfernt oder mit False gleichgesetzt werden.

    Beispiel EnableMSU=True

    Key REPAIR

    Einsatz Optional (EnableDisableDisableWithRetValue0)

    Beschreibung Soll eine Reparatur in einem Paket nicht oder nicht mehr untersttzt werden, so kann dies mittels dem neuen Bezeichner REPAIR in der INI-Datei des Soft-warepakets realisiert werden. So sind auch nachtrglich in einer knftigen Re-vision entstehende Anforderungen umsetzbar, indem einfach der Bezeichner der Install-Sektion hinzugefgt wird. Ist REPAIR=Disable, dann wird der Text REPAIR is not supported! in die Datei History.LOG geschrieben. Der Zu-weisungswert DisableWithRetValue0 veanlasst hierbei, dass dem bergeordne-ten Prozess (SW-Verteilungswerkzeug) der Exit-Code 0 zurckgegeben wird.

    Beispiel REPAIR=Disable

    Key CheckProcesses (Section Install & UnInstall)

    Einsatz Optional

    Beschreibung Prft vor der Transaktion, ob der oder die angegebenen Prozesse gestartet sind. Ist bei der Installation einer der angegebenen Prozesse gestartet, so wird dies in der Datei History.LOG quittiert und der Exit-Code 1618 zurckgegeben. Dieser definiert in SCCM 2012 den Fast Retry exit code, was SCCM 2012 dazu veranlasst, das Paket vor einem policy refresh nochmals zu installieren.

    Der Bezeichner soll nur Prozessnamen ohne Pfadangaben enthalten. Mehrere Prozesse knnen wie gewohnt durch ein Leerzeichen voneinander getrennt werden. Prozessnamen mit Leerzeichen sind in Anfhrungszeichen einzufassen. Der Bezeichner ist taskabhngig, kann also in der Install und der UnInstall-Sektion angewendet werden.

    Beispiel Checkprocesses=vmware.exe vmware-tray.exe "vmware special.exe"

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 29/122

    Key CommitRebootExitCode (Section Install & UnInstall)

    Einsatz Optional (FalseTrueEnhanced)

    Beschreibung Wird CommitRebootExitCode=True gesetzt, so werden alle 3010er (unterdrckter Neustart) und 1641er-Rckgabewerte (initiierter Neustart) von msiexec dem bergeordneten Prozess (SW-Verteilungswerkzeug) zum selbstndigen Handling zurckgegeben.

    Mit CommitRebootExitCode=Enhanced wird auch bei angeforderten Neustarts via dem Bezeichner Reboot=True der Rckgabewert 3010 zurckgegeben.

    Achtung: Der Bezeichner CommitRebootExitCode kann auch global in der Registry fr alle Softwarepakete vorgenommen werden. Die Prfung erfolgt nach dem Schema IS KEY IN (INI OR REGISTRY). Auch Rckgabewerte in Scripts (3010 und 1641) werden so durchgngig an das Software-verteilungswerkzeug bermittelt.

    Beispiel CommitRebootExitCode=True

    Key UpgradeAfterPreInst

    Einsatz Optional (TrueFalse)

    Beschreibung Sollen bei einer Paketinstallation im Rahmen eines Upgrades noch VOR einer allflligen Deinstallation eines Vorproduktes, gewisse programmatische Aufgaben ausgefhrt werden, so kann dies im neuen Softwarepaket mittels einer herkmmlichen PreInstall_001.EXE oder PreScript_001 realisiert werden, wenn zustzlich der Bezeichner UpgradeAfterPreInst=True in der INI-Datei angegeben wurde. Dadurch wird sichergestellt, dass chronologisch zuerst das PreInstall_001.exe/PreScript_001 (aus Rev. 001) ausgefhrt und erst danach die Deinstallation des Vorgngerproduktes ber den Upgrade ausgefhrt wird.

    Beispiel UpgradeAfterPreInst=True

    Key AllowDowngrade (Section Install)

    Einsatz Optional (FalseTrueEnhanced)

    Beschreibung Standardmssig steht diese Einstellung auf False auch wenn der Bezeichner fehlt. So werden Downgrades von Paketen verhindert, indem der Downgrade mit der folgenden History-Meldung quittiert wird:

    This package doesnt support to downgrade! (Upgrade targets PackageName) (exit with return code 0)

    Wird eine nicht konforme Versionierung verwendet, so kann die obige Fehlermeldung verhindert werden, indem in der Install-Section des neuen Pakets AllowDowngrade=True angegeben wird.

    Beispiel AllowDowngrade=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 30/122

    Key FastRetry

    Einsatz Optional (number)

    Beschreibung Unter SCCM 2012 kann mittels des Fast Retry Return value im Deployment Type automatisch eine Neuinstallation der Application vorgenommen werden, ohne auf den nchsten Deployment Evaluation Cycle warten zu mssen.

    Der Package-Launcher untersttzt ein solches Verhalten bei einigen Fehlermeldungen. Unter anderem bei folgenden History.LOG-Meldungen:

    The program cannot be started several times.

    Other Windows Installer process in progress! Try again later.

    Running processes not allowed! (%processname%)

    Another installation is already in progress! (Exitcode: xx)

    Standardmssig wird in solchen Fllen 1618 an SCCM zurckgegeben. Soll der Rckgabecode ndern, kann dieser durch den besprochenen Bezeichner abgendert werden.

    Beispiel FastRetry=1620

    Key enforceREMOVE (Section Install)

    Einsatz Optional (TrueFalse)

    Beschreibung Mit diesem Bezeichner kann ein aus der Kommandozeile bekanntes /e im Zusammenhang mit einer Deinstallation oder einem Upgrade direkt im Paket vorgesehen werden.

    bersteuerung der Fehlermeldung REMOVE action is only valid for products which are currently installed. D.h. Deinstallation wird weitergefhrt auch wenn die Source zur Deinstallation fehlt.

    Mit EnforceREMOVE=True wird sichergestellt, dass ein allflliges Paket mit Revisionslcken (MSI basierend) dennoch ber einen REMOVE entfernt werden kann. Revisionslcken knnen beispielsweise durch einen unkontrollierten Upgrade (bslpl. WSUS) entstehen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 31/122

    Key AppVAutoStopProcesses (Section Install)

    Einsatz Optional (TrueFalse), ohne Angabe ist die Einstellung True

    Beschreibung Standardmssig wird eine virtuelle App-V 5 Zielanwendung, die in Benutzung steht, vor einem REMOVE geschlossen, damit die Transaktion erfolgreich abgeschlossen werden kann. Soll dies verhindert werden, kann mit AppVAutoStopProcesses=False bewerkstelligt werden.

    Beispiel AppVAutoStopProcesses=False

    Key AppShutdown (Section Install & UnInstall)

    Einsatz Optional, Pattern

    Beschreibung Der Bezeichner AppShutdown kann in der Install und UnInstall-Sektion angewendet werden. Fehlt dieser bei einem REMOVE in der UnInstall-Sektion, wird auch dort die Install-Eigenschaft angewendet. Die Eigenschaft hat vier Objektausprgungen. Diese steuern das Verhalten im Zusammenhang mit Dateien die zu aktualisieren sind, die aber whrend der Installation vom Benutzer noch in Benutzung stehen:

    [DontAskForSave|AskForSave|Force];[DisableUserDisableShutdown];ALL|MSI;[[f:]Files]|False

    Fett geschriebene Texte sind Standardeinstellungen, die verwendet werden, wenn die Oder-Ausprgung in der Deklaration fehlt.

    ALL behandelt alle geffneten Benutzerprogramme, fragt den Benutzer zum Schliessen und setzt die Installation nach Besttigung fort. Whrend der Installation bleiben Startmen, Desktop und Taskleiste verborgen.

    MSI behandelt alle in der beabsichtigten Transaktion zu installierenden oder deinstallierenden Exe-Dateien, die in den MSI-Dateien referenziert sind. Das weitere Vorgehen entspricht dem von ALL. Der Desktop wird aber angezeigt.

    [f:]Files: Hier knnen Dateien angefgt werden (datei1.exe;datei2.exe; datei3.exe; ...), die geschlossen werden sollen. Einzelne Dateiangaben knnen mit dem Pattern MSI kombiniert werden

    AppShutdown=MSI;file1.exe;file2.exe;.

    Der Parameter "f:" fr 'force' vor der Datei bedeutet, dass die Datei.exe forciert ohne Dialog gekillt wird. In diesem Fall kann es sich auch um einen Systemprozess oder einen Prozess, deren Schliessen erhhte Rechte erfordert, handeln!

    False: Ohne jegliche Angabe in der INI, der Registry oder in der Kommandozeile, verwendet der Package-Launcher AppShutdown=MSI. Soll grundstzlich kein Dialog erscheinen, lsst sich das mit AppShutdown=False bewerkstelligen.

    Beispiel [Install] AppShutdown=MSI;myfile.exe;AWStream.exe

    Objektoptionen

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 32/122

    Key MaxExecuteTimeRTM und ExecuteTimeRTM MaxExecuteTime_00x und ExecuteTime_00x

    Einsatz Optional, Pattern, Section Install

    Beschreibung Mit den Bezeichner MaxExecuteTimeRTM und ExecuteTimeRTM, deklariert in der Install-Section, knnen die folgenden Optionen im Deployment Type (User Experiance) beim berfhren des Paketes in SCCM fr (RTM)-Applications vorgegeben, bzw. die Defaulteinstellungen (275/60) bersteuert werden.

    Eine Anpassung des Wertes MaxExecuteTimeRTM macht nur beim Einsatz von SCCM Wartungsfenster Sinn. Hingegen dient der Eintrag ExecuteTimeRTM zur Anzeige im Softwarecenter und kann individuell pro Paket abgefllt werden.

    Die Bezeichner MaxExecuteTime_00x und ExecuteTime_00x dienen demselben Ziel, mit dem Unterschied, dass diese fr die Applications der Revisionsupdates vorgesehen sind.

    Die Spannbreite bewegt sich zwischen 15 720 Minuten.

    Beispiel [Install] MaxExecuteTime_004=60 ExecuteTime_004=40

    3.5.2 Sectionproperties

    Neben den Implementationen in MsiInstallProperties (siehe letztes Kapitel) ist es auch mglich, Propertyausfhrungen ber sogenannte Sectionproperties zu gestalten. Diese erlauben insbesondere mit Paketvarianten (siehe Kapitel 7.1 Paketvarianten) eine differenziertere Steuerung von Windows Installer Properties. Die Sektion 99-STANDARD wird fr alle Standardpakete ohne Variantenbezeichner eingelesen und die dort abgebildeten Properties zum Installationszeitpunkt allen im Paket platzierten MSIs bergeben. Auf die massgebliche Sektion kann kann aber auch in WiseScript und in allen anderen Scripts ber die Variable %VARIANTSECTION% zugegriffen werden. Dadurch ist es mglich, die dort platzierten Variablen einzulesen und auszuwerten. Es knnen zudem bedingte Anweisungen in Scripts durch die Ausprgung der Variablen %VARIANTSECTION% realisiert werden (bspl. IF "%VARIANTSECTION%"=="99-ADMIN" GOTO ADMIN)

    Sind Properties erforderlich, die ein oder mehrere Leerzeichen enthalten, so ist der Propertyinhalt in Anfhrungszeichen einzufassen.

    Bspl. CONFIG= "User 2"

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 33/122

    3.6 Realisierung eines Upgrades

    Es gibt zwei Verfahren, um einen Upgrade auszulsen. Den Major-Upgrade, der sich vornehmlich der Techniken der Windows Installer Technologie bedient und der Package-Upgrade, welcher die Deinstallation von Softwarepaketen selber verwaltet. Das dringend empfohlene und fr den Softwarepaketierer einfacher zu realisierende und transparentere Verfahren stellt der Package-Upgrade dar. Die Steuerung der Art des Upgrades wird ber die INI-Datei des Softwarepakets gesteuert. Die massgeblichen Items sind folgende:

    Upgrade= ScriptAdditionalUpgrades= ScriptUpgradeCode={GUID}

    AddProperties.vbs liest die Zeilen ein und appliziert der MSI/MST-Datei in der Revision 001 die fr den Major-Upgrade erforderlichen Erweiterungen, sofern der Eintrag unter Upgrade leer ist (und nur dann!). Unter ScriptUpgradeCode wird durch AddProperties.vbs der zentrale UpgradeCode fr alle Revisionen dieses Softwarepakets und fr die gesamte Produktefamilie abgelegt. Jede Revision aus der kompletten Produktefamilie verwendet sprach- und Plattformbergreifend den selben UpgradeCode!

    Achtung: Der Eintrag ScriptUpgradeCode sollte durch den Softwarepaketierer nicht manipuliert werden! Das Servicemodell des Scriptes AddProperties.vbs verwaltet diesen Eintrag selbstndig!

    Beim Package-Upgrade, dem Standardverfahren, werden in der INI-Datei ber den Bezeichner Upgrade einfach die Namen der Softwarepakete oder Softwarefamilien angefgt, die man im Rahmen des Upgrades vorgngig deinstallieren mchte. Hier mssen nicht komplette Bezeichnungen der Softwarepakete ausgeschrieben werden. Es knnen auch Teilstrings appliziert werden. Zwischen zwei Anwendungen, bzw. Anwendungsfamilien ist ein Leerzeichen einzufgen:

    Bspl: Upgrade=Byron-HIP Adobe-Reader (deinstalliert Byron-HIP und Adobe-Reader unabhngig der lokal installierten Version im Rahmen eines Package-Upgrades)

    Achtung: Das Verfahren des Package-Upgrades ist das bevorzugte Modell zur Anwendung von Upgrades! Als Bezeichner knnen fr nicht Package-Launcher-kompatible Softwarepakete auch {ProductCodes} angefgt werden!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 34/122

    3.7 Namensrichtlinien

    Das Softwarepaket wird in der Regel mit dem Programm CreatePackage.EXE erstellt. Dadurch wird gewhrleistet, dass die richtige Struktur eingehalten wird. Viele Fehler werden hier bereits abgefangen.

    Folgende Regeln mssen generell eingehalten werden:

    1. Der komplette Paketnamen darf die Lnge von 39 Zeichen nicht berschreiten (SCCM 2007)

    2. Es drfen keine Leerzeichen im Paketnamen verwendet werden.

    3. Das Trennzeichen - darf im Paketnamen nicht verwendet werden.

    3.7.1 Bezeichnung von MSI und MST-Dateien

    Die Namensbezeichnung der MSI-Dateien im Revisionsverzeichnis ist frei. Die Bezeichnung der allgemeinen Transformationen (MST-Datei) ist ebenfalls frei. Wird durch den Conflict Explorer 2009 eine Transformation erstellt, so sollte diese ResolveConflicts.MST bezeichnet verwenden. Eine so benannte Datei wird dann durch den Package-Launcher automatisch als letzte Transformation angewendet.

    3.7.2 PreInstall und PostInstall

    Die Wise-Scripts sind nur mit den folgenden Namen im Revisionsverzeichnis gltig:

    PreInstall_00x.EXE und PostInstall_00x.EXE, wobei das 00x mit der tatschlichen Revision anzupassen ist, welches der Revisionsbezeichnung, bzw. dem Verzeichnisnamen entspricht.

    3.7.3 Bezeichnung des Security-Batch

    Eine Vorlage des Securitybatches wird durch CreatePackage.EXE in das Verzeichnis Work kopiert. Bei dieser Vorlage muss nur noch die Revision von 00x auf die tatschliche Revision angepasst und im Bedarfsfall in das Revisionsverzeichnis kopiert werden. Folgende Namensbezeichnung ist einzuhalten:

    _00x.CMD, bspl. Byron-HIP-1.0_001.cmd

    3.7.4 Bezeichnung der Build-Datei

    Die Build-Datei trgt den Namen des Softwarepakets, gefolgt vom Revisions-Bezeichner und der Erweiterung .BLD.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 35/122

    3.8 Verwendung von PreInstall_00x.wse, PostInstall_00x.wse

    Zur Applizierung von Spezialkonfigurationen oder zustzlichen Aufgaben sind in Umgebungen mit Wise Package Studio primr die Wise-Script-Vorlagen PreInstall_00x.wse und PostInstall_00x.wse vorgesehen. In Umgebungen, wo kein Wise Package Studio zur Verfgung steht, knnen stattdessen auch eigene Scripts (*.cmd, *.vbs, *.ps1, etc.) verwendet werden. Diese werden dann ber den INI-Bezeichner ExecuteFile ausgelst (siehe nchstes Kapitel).

    In den beiden WiseScript-Vorlagen werden Programm-Snipplets verwendet, die unter dem Register VorlagenScriptA, bzw. VorlagenScriptB zu erreichen sind. Die eigentlichen Programm-anweisungen sind im Register PreInstall_00x, bzw PostInstall_00x einzufgen. Hier finden wir drei verschiedene Abschnitte, die dem Installationstask entsprechen (INSTALL, REPAIR, REMOVE).

    Achtung: Viele Variablen (INST, SCRIPTS, etc.) werden standardmssig zum weiteren Gebrauch vorabgefllt. Diese sind in der Kopfzeile der Vorlagen nher erklrt. Sollte die Variable %INST% verwendet werden (Copy local), so ist darauf zu achten, dass diese nicht in jedem Installationstask den selben Wert aufweist:

    Beispiele:

    %INST% PreInstall_00x PostInstall_00x

    INSTALL ..\Pack\x86-GE\001 %WIN%\Package-Launcher\Scripts\Byron-Salz-1.0.3

    REPAIR ..\Pack\x86-GE\001 %WIN%\ Package-Launcher\Scripts\ByronSalz-1.0.3

    REMOVE %WIN%\Package-Launcher\Scripts\ByronSalz-1.0.3 %WIN%\ Package-Launcher\Scripts\ByronSalz-1.0.3

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 36/122

    Muss in einem eigenen Programmabschnitt ein Fehler ausgewiesen werden und soll die Installation mit einem Rckgabewert und der entsprechenden History.LOG Meldung abschliessen, dann verwenden Sie unbedingt das erste Programm-Snipplet aus dem VorlagenScript!

    3.9 Einsatz von eigenen Scripts und Batchprogrammen

    Steht im Unternehmen Wise Package Studio, bzw. WiseScript nicht zur Verfgung, knnen auch eigene Scripts fr Installationsanweisungen ausserhalb einer MSI-Datei verwendet werden. Dies ist mittels den Bezeichnern ExecuteFile, PreScript, PostScript und ActiveSetupScript ber die INI-Datei realisierbar siehe Kapitel 3.5.1 Zusammenfassung der wichtigsten INI-Eintrge. Hierbei ist sorgfltig vorzugehen und es sind zwingend die nachgefhrten Richtlinien einzuhalten!

    Solche Scripts knnen insbesondere zur Ausfhrung von Legacy-Setups dienen, wenn diese nicht repaketiert werden sollen und diese nicht einfach Windows Installer Bootstrapper sind, welche im Hintergrund eigene Hersteller-MSI-Dateien auspacken (siehe Kapitel 4.11 Paketierungsarten). Auch auf lokale Programme kann so direkt zugegriffen werden. Zudem werden verschiedene Variablen bei der Integration mit den Scriptbezeichnern untersttzt.

    3.9.1 Richtlinien beim Einsatz von Scripts

    1. Verwenden Sie keine Verweise und Anweisungen auf durch den Package-Launcher untersttzte Ressourcen (MSI, MSP, MST, App-V, MSU, etc.) siehe Kapitel 3.11 Formen von Ressourcen. Diese Ressourcen sollen direkt vom Package-Launcher angesprochen werden, da nur dadurch das Fehlerhandling und die Transaktionskonsistenz gewhrleistet sind.

    2. Verwalten Sie den Status der Transaktion ber den Rckgabewert! Nur ein Rckgabewert von 0 aus dem Script interpretiert der Package-Launcher als erfolgreichen Transaktions-abschluss. Prfen Sie nach der Ausfhrung ihrer Installationsanweisungen im Script den Erfolg ihrer Implementation und setzen Sie wenn ntig den Rckgabewert selber. (Bspl. fgen Sie bei einem Kommandozeilenbatch Exit 0 als letzte Anweisung hinzu, wenn die Installationsaufgaben erfolgreich durchgefhrt wurden.)

    Gewhrleistet ein von Ihnen in ein Kommandozeilenbatch integriertes Legacy-Setups selber, dass dieses bei Fehlern einen Rckgabewert 0 ausweist und bei einer erfolgreichen Installation 0 zurckgibt, knnen Sie auch auf die Implementation eines Rckgabewertes am Schluss des Scripts verzichten. Der Kommandozeilenprozessor bergibt in diesem Fall den Rckgabewert der ausgefhrten Exe-Datei an den Package-Launcher zurck.

    3. Das Ausfhrungsverzeichnis wird vom Package-Launcher vor der Ausfhrung Ihres Scripts auf das Revisionsverzeichnis gesetzt.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 37/122

    4. Verwenden Sie CopyLocal=True in der INI-Datei des Softwarepakets, wenn im Rahmen einer Deinstallation auf ein Script im Paket zugegriffen werden soll! Ohne diesen Bezeichner kann das Paket bei Vorhandensein eines Deinstallationsscripts nicht deinstalliert werden, wenn die Deinstallation direkt ber LocalLauncher.EXE gesteuert wird (Deinstallation ber SCCM oder Package-Upgrade).

    3.9.2 Erstes Beispiel

    In der folgenden Abbildung sehen wir die Eintrge aus der INI-Datei:

    In der hier verwendeten Ausfhrung regelt das Legacy-Setup den Rckgabewert selbstndig:

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 38/122

    3.9.3 Scriptbezeichner ExecuteFile, ActiveSetupScript, PreScript & PostScript

    Insgesamt stehen vier verschiedene Scriptbezeichner zur Verfgung, die in der [Install]- und [UnInstall]-Section verwendet werden knnen.

    1. ExecuteFile

    Soll ein lokales Programm oder ein einfaches Script ausgefhrt werden, welches in einem Revisionsverzeichnis abgelegt ist und welches ohne Rcksicht auf den Installationsablauf anderer Paketressourcen (bspl. MSI im selben Revisionsverzeichnis), installiert werden kann, ist dies der richtige Bezeichner.

    2. PreScript

    Mssen Scriptanweisungen vor der Installation von Installationselementen im selben Revisionsverzeichnis durchgefhrt werden, die durch den Package-Launcher direkt untersttzt werden (MSI, MSP, MSU, APPV), knnen diese mittels des Bezeichners PreScript zur Ausfhrung gelangen.

    3. PostScript

    Mssen Scriptanweisungen nach der Installation von Installationselementen im selben Revisionsverzeichnis durchgefhrt werden, die durch den Package-Launcher direkt untersttzt werden (MSI, MSP, MSU, APPV), knnen diese mittels des Bezeichners PostScript zur Ausfhrung gelangen.

    4. ActiveSetupScript

    Mittels dieses Bezeichners knnen Scripts, die im Revisionsverzeichnis abgelegt sind, im Kontext des Benutzers ausgefhrt werden. So werden Benutzerressourcen appliziert.

    Hierbei ist es bei Scriptverweisen, die auf ein Script im Paketverzeichnis verweisen (bspl. ActiveSetupScript_001=%CACHE%\MyActiveSetupScript.cmd) zwingend notwendig, dass auch CopyLocal=True in der INI-Datei, in der Install-Section gesetzt ist, damit das Script zum Ausfhrungszeitpunkt lokal verfgbar ist. Bei Verweisen auf lokal existierende Komponenten kann auf CopyLocal=True verzichtet werden (bspl. ActiveSetupScript_00=REG.exe ADD HKCU\Software). Beachten Sie, dass Sie in das Script keine Anweisungen integrieren knnen, die erhhte Rechte bentigen. So ist ein Schreiben der HKCU-Keys ohne Probleme mglich, nicht aber ein Schreiben der HKLM-Keys, sofern diese nicht per Security-Batch geffnet wurden.

    Das mittels dieses Bezeichners angegebene Script wird bei der nchsten Benutzeranmeldung einmalig ausgefhrt. Wird das Paket deinstalliert und neu installiert, "zieht" die Active Setup Implementation auch nach der zweiten Installation, da der Package-Launcher mittels Versionierung arbeitet. Bei der DeInstallation wird der Active Setup Key durch den Package-Launcher automatisch bereinigt, so dass bei neuen Benutzern danach das Script nicht mehr ausgefhrt wird. Siehe auch Kapitel 7.4.9 ActiveSetup mit AppShutdown=ALL.

    Alle Scriptbezeichner knnen mit oder ohne Revisionszusatz in der INI-Datei angegeben werden (beispielsweise ExecuteScript=install.cmd oder ExecuteScript_001=install.cmd). Es wird empfohlen, immer den Revisionszusatz zu verwenden, ausser bei der Planung des Paketes ist klar, dass alle knftigen Revisionen in ihrem Revisionsverzeichnis immer das selbe Script mit dem selben Namen verwenden werden.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 39/122

    Achtung

    Wird in einer Section eine PreScript-Zuweisung integriert, darf nicht gleichzeitig der Bezeichner ExecuteFile verwendet werden! In diesem Fall wren auch die fr ExecuteFile vorgesehenen Anweisungen in das Pre- oder PostScript-Element aufzunehmen.

    Alle Scriptbezeichner untersttzen auch die direkte Ausfhrung von Programmen, die lokal auf dem Computer abgespeichert sind.

    Zudem werden in der INI-Datei platzierte Environmentvariablen aufgelst:

    Wird in einer Revision nur ein Script bei der Installation angewendet, ohne dass sich weitere Ressourcen im Revisionsverzeichnis befinden, schlgt die DeInstallation fehl:

    Diese Meldung kann umgangen werden, indem in der UnInstall-Section ebenfalls ein Script angegeben wird. Mit dem folgenden Befehl, der keinen funktionellen Charakter hat, lsst sich dies bewerkstelligen:

    Merke

    Wird fr die DeInstallation ein im Paketrevisionsverzeichnis abgelegtes Script bentigt, muss im Paket in der Install-Section die Anweisung CopyLocal=True stehen, damit das Script bei der DeInstallation lokal zur Verfgung steht.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 40/122

    3.9.4 Zustzliche Environmentvariablen whrend des Installationsprozess

    Whrend des Installationsprozess kann in der INI-Datei und in Scripts auf zustzliche Environmentvariablen zugegriffen werden.

    Environmentvariable Beschreibung

    CACHE Entspricht dem Revisionsverzeichnis des lokal in %WINDIR%\Package-Launcher\Cache zwischengespeicherten Pakets (bspl. C:\Windows\-Package-Launcher\Cache\Acresso-ISSCRIPT-11.5\x86-EN\001). Wird CopyLocal=True in der INI-Datei verwendet, ist dies das primre Ausfhrungsverzeichnis der Installationsressourcen.Steht CopyLocal auf False ist der Bezeichner leer "".

    SOURCE Entspricht dem Revisions- und Ausfhrungsverzeichnis. Wird fr dieses Paket der Bezeichner CopyLocal=True eingesetzt, ist diese Variable der CACHE-Variable quivalent.

    Wird hingegen CopyLocal=False eingesetzt, entspricht SOURCE beim Installieren mit SCCM dem Revisionsverzeichnis des Pakets im lokalen SCCM-Cache, hingegen bei einer Installation ab Netzwerkshare dem Revisions- und Ausfhrungsverzeichnis des dort abgespeicherten Pakets. Bei einer DeInstallation mit SCCM und CopyLocal=False ist diese Variable leer "".

    PACKAGE Diese Variable trgt den Namen des Pakets. Bspl. RealPackaging-Demo-1.0

    REVISION Diese Variable entspricht der aktuellen, in diesem Moment zu installierenden Revision.

    LOGFILE Diese Variable ist vorgesehen, um in einem Script eine Protokolldatei anzulegen. Der Wert entspricht der Datei

    %WINDIR%\Logs\Install\%PACKAGE%_%REVISION%_CUSTOM.LOG

    Bei einer DeInstallation trgt die Variable einen Wert mit Pfad im UnInstall Verzeichnis.

    VARIANTSECTION Diese Variable kann bei Variantenpaketen verwendet werden, um auf die eingelesene Sektion in der INI-Datei zuzugreifen.

    Entspricht beispielsweise der Section "99-USER" oder "99-ADMIN" aus der INI-Datei.

    Dadurch lassen sich per Script verschiedene Installationsausprgungen desselben Pakets realisieren.

    TASK Der Wert dieser Variable enthlt "INSTALL", "UPDATE", "REPAIR" oder "REMOVE".

    PRODUCTCODE Mittels der Variablen PRODUCTCODE kann bei einer MSI-Installation auf den ProductCode der MSI-Datei zurckgegriffen werden. Wird er in der INI-Datei zusammen mit dem Bezeichner ActiveSetupScript_00x verwendet, entspricht der Wert dem ProductCode der in diesem Revisionsverzeichnis installierten MSI-Datei. (Siehe auch letztes Beispiel aus Kapitel 3.9.6 Beispiele)

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 41/122

    Achtung

    Auf diese Variablen kann man auch in Windows Installer Properties ber Variantensektionen der INI-Datei oder ber die Bezeichner MsiInstallProperties, MsiRepairProperties, etc. (Bspl. MsiInstallProperties=LOCALSOURCE=%CACHE%) platziert in der INI-Datei, zugreifen. Dane-ben sind sie auch whrend des MSI-Installationsprozess als Environmentvariablen verfgbar.

    3.9.5 History.LOG kompatible Fehlermeldungen erstellen

    Soll ein Script abgebrochen werden und mchte man eine spezifische Fehlermeldung in der Datei History.LOG erstellen, gengt es, im Script folgenden Registrykey zu schreiben:

    HKLM\Software\Real Packaging\Package-Launcher\Packages\%PACKAGE%\Error

    Wird das Script danach mit einem Exitcode beendet, zeigt der Package-Launcher dies in der Datei History.LOG an:

    3.9.6 Beispiele

    1. In diesem Beispiel wird vor der MSI-Installation ein cmd-Batch (install.cmd) ausgefhrt. Bei der Deinstallation erledigt ein vb-Script (uninstall.vbs) abschliessende Bereinigungsaufgaben. Beide Scripts befinden sich im Revisionsverzeichnis 001. Durch den Bezeichner CopyLocal=True wird sichergestellt, dass bei der Ausfhrung von uninstall.vbs die Source und das Script lokal vorliegend und zwischengespeichert sind.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 42/122

    2. Hier wird ein PowerShell-Script ausgefhrt, welches im Revisionsverzeichnis 001 abgespeichert ist.

    3. Erstellung eines Registrykeys vor Ausfhrung der MSI-Installation in Revision 002 durch Ausfhrung einer lokalen exe-Datei (REG.exe)

    4. Ausfhrung einer Exedatei, die unter x64 im Verzeichnis "C:\Program Files" abgespeichert ist. Durch Angabe des Alias "sysnative" kann auf x64 Clients aus 32 BIT Prozessen auf das Verzeichnis C:\Windows\System32 (anstatt auf C:\Windows\SysWOW64) zugegriffen werden. Durch das x64er cmd.exe wird ein Zugriff auf C:\Program Files (anstatt C:\Program Files (x86)) mglich.

    Da im Revisionsverzeichnis keine weiteren Ressourcen vorliegen, wird mit der Anweisung unter der Section [UnInstall] sichergestellt, dass das Paket ohne Fehlermeldung deinstalliert werden kann.

    5. Hier wird das lokal abgespeicherte msiexec.exe fr die Ausfhrung im Kontext des Benutzers bei der nchsten Anmeldung am Computer integriert. Fr die meisten Flle muss CopyLocal muss auf True stehen!

    Mittels der Variablen %PRODUCTCODE% kann der ProductCode aus der MSI-Datei derselben Revision verwendet werden. Diese Variable steht zum Integrationszeitpunkt zur Verfgung und wird durch den Package-Launcher bersetzt.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 43/122

    3.10 Formen der Ressourcen

    Im Revisionsverzeichnis knnen durch den Softwarepaketierer verschiedene Setup-Arten zur direkten Installation abgelegt werden. Direkt werden durch den Package-Launcher folgende Typen untersttzt:

    MSI Windows Installer Setup. Dies entspricht dem Standardtyp.

    MST Windows Installer Transformation. Diese kann nur zusammen mit einer MSI-Datei eingesetzt werden. Siehe Kapitel 3.7.1 MSI und MST Dateien

    PostInstall Befindet sich eine Datei mit der Bezeichnung PostInstall_00x.EXE im Revisions-verzeichnis wird diese im Rahmen einer MSI-Installation als Custom Action ausgefhrt. Das Script AddProperties.vbs integriert diese in die MSI-Datei. Die Ausfhrung erfolgt im Systemkontext mit erhhten Privilegien nach der Installation aller Ressourcen durch die MSI-Datei.

    MSP MSP-Dateien sind Windows Installer Patches. Diese knnen einzeln oder in Kombination mit einer MSI-Datei im selben Revisionsverzeichnis verwendet werden. Der Package-Launcher berprft das komplette Revisionsverzeichnis nach dem Vorkommen aller Patches. Sind mehrere Patchdateien im selben Revisionsverzeichnis vorhanden, werden alle Patches (gleichzeitig) dem Installationsprozess bergeben. Achtung: Dieses Verfahren ist erst ab Patches der Revision 3.x mglich! (siehe Kapitel 3.13 Anwendung von Patches und Transformationen). Wird im selben Verzeichnis sowohl eine MSI-Datei, als auch eine oder mehrere MSP-Dateien vorgefunden, so wird zuerst die MSI-Datei installiert und erst danach kommt der/die Patches zur Anwendung.

    Kommt eine neue Software zum Einsatz, die noch nicht verteilt ist, so wird das Erstellen eines In-Place-Updates als Vorbereitung empfohlen. D.h., dass in diesen Fllen eine MSP-Datei gleich auf die MSI-Datei angewendet, bzw. die MSI-Datei mit der/den MSP-Datei/en gepatcht wird. Ist die Software bereits verteilt, darf dieses Verfahren in der Vorbereitung nicht angewendet werden, hier ist die isolierte Patchdatei in einem neuen Revisionsverzeichnis abzulegen!

    PreInstall Befindet sich eine Datei mit der Bezeichnung PreInstall_00x.EXE im Revisions-verzeichnis, wird diese vor allen allflligen MSI oder MSP-Installationen ausge-fhrt. Befindet sie sich alleine im Verzeichnis, so werden nur die Programm-anweisungen, die dort aufgefhrt sind, ausgefhrt. PreInstall-Dateien eignen sich zudem fr den Aufruf von Legacy-Setups.

    Scripts Befindet sich ein Script im Revisionsverzeichnis und wurde dieses in der INI-Datei des Softwarepakets angegeben (ExecuteFile=), wird dieses vor allen allflligen MSI oder MSP-Installationen und auch vor einem allflligen PreInstall_00x.exe ausgefhrt. Befindet es sich alleine im Verzeichnis, so werden nur die Programmanweisungen, die dort aufgefhrt sind, ausgefhrt. Script-Dateien eignen sich fr den Aufruf von Legacy-Setups, wenn man nicht auf die WiseScript-Implementation via PreInstall zurckgegriffen will.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 44/122

    MSU Hotfixes in Form von .MSU-Dateien knnen einfach in das Revisionsverzeichnis abgelegt werden, sofern der INI-Bezeichner EnableMSU gesetzt wurden (durch CreatePackage standardmssig implementiert).

    App-V Es werden sowohl App-V 4.6, als auch App-V 5 Ressourcen untersttzt . Diese knnen nativ in das Revisionsverzeichnis 001 kopiert werden. Bei der Integration von App-V 5 Paketen gibt es zwei Varianten: Die App-V Full Integration, die ein Streaming untersttzt oder das standalone model, wo Pakete wie regulre Pakete behandelt werden. Im letzteren Modell kann das Paket mit den selben Tools verwaltet werden (RPI, History.LOG Viewer), wie gewhnliche Pakete.

    Achtung

    MSI oder Legacy?

    Das primre Setup-Format sollte aus Grnden der Transparenz, der Erweiterbarkeit, den Mglichkeiten zur Anpassung und zur Direktmanipulation durch den Paketierer, der Mglichkeit Softwarekonflikte zu ermitteln und mit dem Conflict Explorer 2009 zu beseitigen, der Rollback und Reparaturfhigkeit, der Verwaltung durch einen zentralen Dienst, etc. immer das MSI-Format sein. Ein Ausfhren eines Legacy-Setups wird nur dort empfohlen, wo es sich beim Setup um eine hardwarenahe Treiberanbindung oder hnliches handelt, die sich nicht oder nur sehr schwierig mittels Snapshottechniken aufzeichnen und in eine MSI-Datei berfhren lsst oder wo der Aufwand zur nativen Paketerstellung oder zur Paketerstellung mittels Snapshottechniken sehr gross ist!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 45/122

    3.10.1 Vereinfachtes Ablaufschema

    3.11 MSI-Spezialflle minimale Aktualisierungen

    Windows Installer kennt drei mgliche Aktualisierungsformen. Dies sind...

    Small Update (fr Aktualisierungen geringen Ausmasses)

    Minor Upgrade (fr grssere Aktualisierungen, die auch eine Erhhung der Minorversion gerechtfertigen)

    Major Upgrade (fr komplexe Aktualisierungen)

    Alle diese Aktualisierungsformen knnen mit dem Servicemodell des Package-Launchers verwendet werden. MSI-Basisinstallationen, welche ein neues Produkt darstellen (RTM), werden immer in Form eines Major Upgrades (bzw. Package-Upgrades) realisiert. Dieser enthlt einen neuen ProductCode und deinstalliert (wenn nicht das Verfahren des Package-Upgrades gewhlt ist) im Umfeld des Unternehmens allfllig vorliegende Vorversionen samt aller Revisionen.

    Minimale Aktualisierungen knnen in einer Revision angewendet werden. Unter diese Kategorie fallen Small Updates und Minor Upgrades. Minimale Aktualisierungen werden durch Windows Installer immer in Form einer Reinstallation und gleichzeitiger Anwendung des Recache-Flags angewendet. Die lokal vorliegende gecachte Version der Basisinstallation wird hierbei durch die neue Version ersetzt. Die entsprechende vorausgehende Revision kann daher im Installationsablauf bei einer Deinstallation nicht mehr wirklich vom System entfernt werden, da dies bereits mit dem Entfernen des Updatepaketes geschehen ist. Der Package-Launcher erkennt diese Situation automatisch und reagiert nach aussen transparent. D.h., dass wir also auch bei der Anwendung von minimalen Aktualisierungen entsprechende korrekte Eintrge im

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 46/122

    History.LOG finden und auch das SCCM-Softwareinventar korrekt ausgelst wird. Sogar Reparaturen (virtuell) der durch den Update ersetzten Revisionen lassen sich ausfhren, ohne Nebeneffekte auszulsen.

    Bei der Anwendung des Updatepakets wird automatisch die Windows Installer Property MSIENFORCEUPGRADECOMPONENTRULES auf 1 gesetzt, wodurch nur regelkonforme Aktualisierungen ermglicht werden. Das Aktualisierungspaket muss daher den Richtlinien ber die Erstellung von minimalen Aktualisierungen entsprechen. Werden die Richtlinien vom Aktualisierungspaket nicht eingehalten, erscheinen Fehlermeldungen im History.LOG wie diese:

    msiexec: Upgrade of feature MainFeature has a missing component. msiexec: New upgrade feature MainFeature must be a leaf feature.

    Die Anwendung der Property MSIENFORCEUPGRADECOMPONENTRULES kann man ber die MsiInstallProperties bersteuern. Dies wird aber nicht empfohlen! Die Erkennung, ob in einer Revision eine Minimale Aktualisierung vorliegt oder nicht, erledigt der Package-Launcher automatisch durch einen Vergleich verschiedener Properties (ProductCode, PackageCode, PLRevision, PLPackage) zwischen einem allfllig vorliegend installierten Produkt und einem durch die Revision anzuwendenden Paket. Sollte erkannt werden, dass ein allfllig vorliegend installiertes Produkt, den gleichen ProductCode registriert hat, wie das anzuwendende Paket, ist aber der PackageCode gleich oder die Property PLPackage verschieden oder die PLRevision gleich, so wird dieser Zustand hingegen so interpretiert, dass auf diesem Gert die gleiche Software durch anderweitige Mechanismen bereits installiert wurde (bspl. Handinstallat ion der Originalsoftware) und die Transaktion wird mit einer entsprechenden Fehlermeldung im History.LOG quittiert:

    This application is already installed manually or by other processes

    Achtung: bei minimalen Aktualisierungen kann keine neue Transformation verwendet werden! Es wird bei der Anwendung auf allfllig recachte MSTs der Basisinstallation zurckgegriffen, bzw. wenn bei der Installation einer Initialversion keine Transformation verwendet wurde, dann wird auch bei der Anwendung des Small Updates oder Minor Upgrades keine Transformation verwendet. Sollten zustzliche nderungen am Design der MSI innerhalb derselben MSI-Datei erfolgen, so knnte dies nur durch nur eine Anpassung des Update-MSIs unter Einhaltung der Richtlinien ber die Erstellung von minimalen Aktualisierungen erfolgen! Minimale Aktualisierungen bedeuten fr den Paketierer lediglich, dass das Updatepaket innerhalb einer neuen Revision zu implementieren ist. Es mssen keine Properties definiert oder spezielle Vorkehrungen vorgenommen werden!

    3.12 Anwendung von Patches und Transformationen

    Innerhalb der Revision werden alle vorgefundenen Patches Transformationen (bei Transformationen sind die Ausnahmen unter Kapitel 3.7.1 MSI und MST-Dateien beschrieben) in einer Transaktion angewendet. Die Zusammensetzung des/der Namen spielt fr den Package-Launcher an sich keine Rolle. Dieser verwendet alle im Paketverzeichnis vorgefundenen Transformationen und Patches.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 47/122

    Transformationen werden nach dem Sicherheitsmodell Secure-At-Source angewendet. Dadurch ist gewhrleistet, dass Transformationen die im lokalen Zwischenspeicher nicht zur Verfgung stehen, ausschliesslich aus dem Stammverzeichnis des Windows Installer Pakets (entspricht unserem Revisionsverzeichnis) verwendet werden. Diese Absicherung dient gegen unauthorisierten Gebrauch und gegen Missbrauch von Transformationsdateien. Die Verwendung mehrerer Patches innerhalb der selben Revision kann mit gutem Gewissen nur bei Patches der Version 3.x angewendet werden, da hier Implementationen durch den Windows Installer vorliegen, welche es dem Patchautor mit einfachen Bordmitteln ermglichen, nur eine Zielversion bei Vorliegen von mehreren Service Packs (Minor Upgrade Patch) anzugeben. Patchdateien der Version 3.x mssen eine Datenbanktabelle mit dem Namen MsiPatchSequence verwenden, wodurch der Patch als Patch der Version 3.x identifiziert werden kann. Der Paketierer kann dies durch ffnen des Patches mit File/Open der MSP-Datei in Orca erkennen. Bei der Anwendung mehrerer Patches der Version 2.0 muss gewhrleistet sein, dass es sich um einen Multi-Target Patch handelt. Wird keine gltige Zielversion erkannt, wird die Transaktion im History.log mit der Meldung

    msiexec: The installer cannot install the upgrade patch because the program being upgraded may be missing or the upgrade patch updates a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch

    quittiert (ERROR_PATCH_TARGET_NOT_FOUND).

    3.13 Build-Datei

    Mittels einer speziellen Build-Datei, abgelegt im Revisionsverzeichnis, kann der Build eines Softwarepakets erhht werden. Eine Build-Datei muss nur dann verwendet werden, wenn an einer produktiven Revision Vernderungen durch den Paketierer durchgefhrt werden. Wird bei der Erst-Inbetriebsetzung eines Softwarepakets (RTM) beispielsweise eine Konfiguration verwendet, die spter nicht im Rahmen eines Revisionsupdates korrigiert werden kann, sondern die Anpassung des bestehenden Paketes unerlsslich macht, so erstellt der Softwarepaketierer gleichzeitig eine Build-Datei (PACKAGE_REVISION.BLD) mit einer 4-stelligen Buildnummer, welche er im angepassten Revisionsverzeichnis anfgt. Die Buildnummer ist ein Zhler der sich auf das ganze Produkt inkl. aller Revisionen bezieht und pro Anpassung um 1 erhht wird (beginnend mit 0002 bei der ersten Korrektur). Dadurch lassen sich modifizierte Revisionen spter im Softwareverteilungswerkzeug identifizieren, wodurch Aussagen realisierbar sind, wer vorher die Software installiert hatte (Build 0001) und wer die neue Variante verwendet (bspl. Build 0002).

    Die Buildnummer wird unter dem Registrykey HKLM\Software\Real Packaging\Package-Launcher\Packages\\Build gefhrt und wird bei jeder Operation (INSTALL, REPAIR, REMOVE), erfolgreich oder nicht, neu geschrieben, solange das Produkt als installiert markiert ist.

    Achtung: Nach einer produktiven Softwareeinfhrung sind in der Regel alle nderungs- und Erweiterungsantrge kummulativ in einer neuen Revision abzubilden. Nur wenn dieses Vorhaben nicht realisierbar ist, darf die Vernderung bestehender, bereits produktiver Revisionen in Be-tracht gezogen werden!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 48/122

    3.14 Software-Inventarisierung

    Fr die korrekte Softwareinventarisierung ber SCCM ist der Package-Launcher zustndig. Der Package-Launcher ist der erste Prozess, der ber die nderung des Installationsstatus einer Software Bescheid weiss. Er agiert somit als Vermittlerinstanz gegenber SCCM und verwaltet den Status aller Softwareinstallationen.

    Die Aktualisierung des Softwareinventars an SCCM erfolgt als Delta nach jeder Software-Statusnderung und nur, wenn die Softwareinstallation nicht im Rahmen einer Computer-Erstinstallation (Environmentvariable _SMSTSType=2) erfolgt und der Registrykey HKLM\SOFTWARE\Real Packaging\Package-Launcher\Packages\StopLauncherInventory nicht mit einem Wert belegt ist. StopLauncherInventory kann folgende Ausprgungen besitzen:

    StopLauncherInventory = Leer oder False: Inventory wird durch den Package-Launcher ausgefhrt (Standardeinstellung).

    StopLauncherInventory = True Fr mindestens 2 Stunden ab der Installation des nchsten Softwarepakets wird das Inventory durch den Package-Launcher nicht mehr ausgefhrt (Standardausnahme).

    StopLauncherInventory = Always Das Inventory wird auf diesem Computer durch den Package-Launcher nie mehr ausgefhrt (nicht empfohlen).

    3.14.1 Die fr SCCM massgeblichen Schnittstellenregistrykeys

    Folgende Registrykeys werden im Rahmen der Inventarisierung an SCCM bermittelt:

    1. HKLM\Software\Real Packaging\Package-Launcher\Packages\\Revision

    Gibt den Installationsstatus wieder. Jeder Wert > 000 besagt, dass das Softwarepaket auf dem Computer installiert ist. Entsteht bei der Erstinstallation eines Softwarepakets bei der Revision 001 ein Fehler, so wird der Key danach immer noch leer sein (Revision=). Bei einer vollstndiger Deinstallation trgt der Key den Wert 000.

    2. HKLM\Software\Real Packaging\Package-Launcher\Packages\\Build

    Wird das Paket bei einer Korrektur nicht mit einer neuen Revision ergnzt, sondern Korrekturen an einer bestehenden Revision gemacht, erhht sich die Build-Nummer. Standardmssig steht dieser Eintrag nach einer Softwareinstallation auf 0001. Die Build-Nummer kann sich bei allen Installationstransaktionen nur erhhen. Siehe Kapitel 3.14 Build-Datei.

    3. HKLM\Software\Real Packaging\Package-Launcher\Packages\\Error

    Rckgabestring bei einer fehlerhaften Installationstransaktion. Der Package-Launcher gibt einen Rckgabewert > 0 zurck.

    Bei einer MSI-Installation enthlt dieser Key die Fehlermeldung aus der Windows Installer Protokolldatei als Reintext.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 49/122

    Bei Legacy-Installationen enthlt dieser Key die Fehlermeldung die vom Paketierer vorgesehen ist und in der PreInstall_00x.EXE abgebildet ist.

    Der Package-Launcher protokolliert allgemeine Fehler auch unter diesem Key als Reintext.

    4. HKLM\Softw..\Real Packaging\Package-Launcher\Packages\\LastAccess

    Der Ausfhrungszeitpunkt der letzten Transaktion dieses Softwarepakets

    5. HKLM\Softw..\Real Packaging\Package-Launcher\Packages\\Variant

    Die Bezeichnung der Paketvariante. Siehe Kapitel 7.1 Paketvarianten

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 50/122

    4 Best-Practice Regeln und Limitierungen

    Viele der hier skizzierten Empfehlungen sind als allgemeine Vorschlge zu betrachten und verstehen sich als Best-Practice-Regeln, die die Firma Real Packaging GmbH aus den Erfahrungen in Projekten aus mehreren Unternehmen gewinnen konnte.

    4.1 Zielverzeichnis

    In der Regel sollten alle Anwendungen in einem Unterverzeichnis von %ProgramFiles% installiert werden. Fr die Unterverzeichnisse in %ProgramFiles% werden die Standardvorgaben des Herstellers verwendet.

    In einzelnen Ausnahmefllen, wo dies nicht mglich ist (bspl. Oracle), muss dies entsprechend dokumentiert werden.

    4.2 Startmen und ShortCuts

    Es werden ausschliesslich Verknpfungen in Unterverzeichnissen vom All Users Startmen erstellt. Verknpfungen aus verschiedenen Softwarepaketen, die aber einen logischen Zusammenhang ergeben, werden falls mglich in einem gemeinsamen Unterordner abgelegt. Fr alle anderen Flle kann der Standardpfad des Anbieters bernommen werden.

    Beispiele von Unterverzeichnissen:

    Adobe, Microsoft

    Folgende Shortcuts werden falls mglich unterdrckt oder entfernt:

    Verknpfungen auf dem Desktop

    Online Updates

    Online Registrierung

    Online Help

    Deinstallation

    Sonstige Verknpfungen in das Internet

    Die Anpassungen erfolgen durch den Softwarepaketierer ber eine MST-Datei oder via Pre/PostInstall.

    4.3 Lizenzen

    Es knnen nur Programminstallationen automatisiert werden, welche einen interaktionslosen Installations-, Konfigurations- und ggf. Aktivierungsmechanismus bieten. Dies gilt speziell auch im Umfeld von Lizenzierungsvorgngen. Whrend des Installationsvorgangs selbst ist es in der Regel nicht mglich, eine entfernte, aber verfgbare Lizenzquelle (Server) zu prfen (Installation im Systemkontext!). Sofern die Setup-Routine der Anwendungssoftware ber einen interaktionslosen Aktivierungsvorgang verfgt, wird dieser in das Softwarepaket integriert. Bei

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 51/122

    repaketierten Softwarepaketen ist darauf zu achten, dass die integrierte Lizenzaktivierung nicht auf den Entwicklungscomputer und Entwicklungsbenutzer beschrnkt, sondern allgemein gltig ist.

    4.4 Namensauflsung

    Bentigt eine Anwendung Zugriff auf ein entferntes System, so sollte in den Verbindungseinstellungen der FQDN des Zielsystems konfiguriert werden. Der jeweilige Applikationsverantwortliche muss die entsprechenden Daten liefern und im Auftrag verwenden. Es drfen keine NetBIOS-Namen verwendet werden.

    Weiter ist folgendes einzuhalten:

    - Fr die Namensauflsung darf nur DNS zum Einsatz kommen

    - Die Windows-Konfigurationsdateien (%SystemRoot%\System32\Drivers\etc.) hosts, lmhosts, networks, protocol und services drfen grundstzlich von einer Paketinstallation nicht verndert werden. Allfllige zwingend ntige Anpassungen in einer dieser fnf Dateien mssen dokumentiert werden.

    4.5 Abhngigkeiten (Middlewares)

    Die Abhngigkeiten zwischen einzelnen Anwendungen mssen vom Softwarepaketierer erkannt und dokumentiert werden. Zu beachten ist, dass bei Herstellersetups oftmals im Hintergrund Abhngigkeiten installiert werden, deren Installation nicht offensichtlich ist. Da im Vorbereitungsprozess aus Sicht der Paketierung durch Applikationsverantwortliche oder Testmanager die Produkte nicht selten zu wenig analysiert werden, finden sich denn auch hufig weit mehr Abhngigkeiten, als im Auftrag dokumentiert ist.

    Abhngigkeiten werden in zwei Gruppen unterschieden:

    1. Globale Abhngigkeit: Abhngigkeiten, die von mehreren Softwarepaketen verwendet werden knnen: All diese Anwendungen mssen als eigenstndige einzelne Pakete behandelt und separat paketiert werden.

    2. Lokale Abhngigkeit Abhngigkeiten, Middleware und Produkte-Teilinstallationen, die nur von der zu paketie-renden Haupanwendung verwendet werden und auch knftig kaum von Drittapplikatio-nen installiert werden: Diese Abhngigkeiten werden in der Regel im selben Softwarepa-ket in einer Vorrevision platziert. So knnen bei der Gestaltung des initialen Softwarepa-kets auch mehr als nur eine Paket-Revision gleichzeitig implementiert werden.

    Beispiel:

    Revision 001 -> lokale Abhngigkeit 1 Revision 002 -> lokale Abhngigkeit 2 Revision 003 -> Hauptanwendung

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 52/122

    Auf die Mglichkeiten zur Lokalisation von Abhngigkeiten wird im Kapitel 6.3.1 Auspacken von Installationselementen aus einem Bootstrapper nher eingegangen.

    Im Kapitel 6.14.3 Umgang mit Abhngigkeiten durch Verwendung des Dependence-Eintrages finden wir zudem Hinweise, wie die Prfung auf Abhngigkeiten mit einem Softwarepaket realisiert wird.

    Schliesslich muss bei globalen Abhngigkeiten in SCCM noch eine Customized Task Sequence eingerichtet werden. In dieser werden die voneinander abhngigen SCCM-Pakete/Install-Programme in der korrekten Reihenfolge fr die Installation zusammengefasst. Das Script Create_SCCM_Package_Link.vbs (SCCM 2007) erstellt diese Task-Sequenz automatisch anhand der Dependence-Eintrge.

    4.6 Versionshandling

    Fr das Versionshandling wird folgende Anwendung empfohlen:

    Fr die Softwareablage und durch Scripts anschliessend auch fr SCCM bernommene Namens-, bzw. Versionsbezeichnung hat der Softwarepaketierer folgende Syntax zu verwenden:

    Major.Minor (bspl. 1.1, 12.2, aber auch 10.55)

    In der Regel wird die gekrzte technische Version aus der MSI-Datei (Property ProductVersion) als Basis fr die Versionsbezeichnung verwendet. Bei repaketierten Softwarepaketen kann als MSI-ProductVersion-Property die im Auftrag, in der Installationssource oder auf der Herstellerseite angegebene Version verwendet werden, welche schliesslich als Basis fr die Softwareablage zu verwenden ist.

    Allgemeine Namensrichtlinien sind im Kapitel 3.7 Namensrichtlinien dokumentiert.

    4.7 Umgang mit .HLP-Dateien

    Um 32-Bit-Hilfedateien mit der Dateinamenerweiterung ".HLP" auf Windows 7 anzeigen zu knnen, wird ein installiertes WinHlp32.exe bentigt. Diese Anwendung steht in Form eines Softwarepakets zur Verfgung, welches punktuell als Abhngigkeit bei diesen Softwarepaketen zu implementieren ist, wo zwingend ein Zugriff auf .HLP-Dateien bentigt wird. Zustzlich ist das Softwarepaket in den Dependence-Bezeichner der INI-Datei aufzunehmen, wodurch die Abhngigkeit nach berfhren mit SCCMCreateApp_Link.vbs auch in die Application eingebaut wird. Das Softwarepaket, welches WinHlp32.exe installiert heisst Microsoft-Helpfiles-KB917607.

    4.8 Umgang mit VirtualStore

    Siehe Kapitel 6.7.1 Datei- und Registrierungsvirtualisierung

    4.9 Installationskontext

    Es werden nur Installationen unter dem Kontext per-machine empfohlen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 53/122

    4.10 Firewall

    Die Ausnahme-Regelung wird global via Group-Policies gesteuert und innerhalb des Softwarepakets sind keine Ausnahmen zu definieren.

    Achtung: In einzelnen Fllen werden auch nur bei der manuellen Installation Verbindungen gestoppt. Firewall-Ausnahmen sind aber nur erforderlich, wenn diese fr den Betrieb der Software bentigt werden. In der Paketdokumentation ist auf die Ausnahmeregelung deutlich hinzuweisen!

    Tip: Portinformationen sind beispielsweise ber das Sysinternals-Tool TCPView ermittelbar. Beim Erscheinen der Firewall-Meldung wird mittels diesem Tool die Art des Protokolls und der Port einsehbar, auf den ein Programm zugreift.

    4.11 Paketierungsarten

    Grundstzlich kann ein Softwarepaket auf verschiedene Weise erstellt werden. Prinzipiell ist die erste Wahl die Verwendung von Hersteller-MSI-Dateien, die im Rahmen eines Customizing an die Unternehmensbedrfnisse angepasst werden. Oft befinden sich auch in Setup.EXE Dateien MSI-Dateien, die der Setup-Bootstrapper whrend der Installation auspackt (siehe Kapitel 6.3 Verwenden eines Hersteller MSIs.

    Zwar erlaubt die Repaketierung eines Setups ein einfaches und meist schnelles Erstellen von Softwarepaketen mit benutzerdefiniertem Verhalten. Es darf aber nicht vergessen werden, dass ein repaketiertes Setup eine komplett andere Logik, als das Herstellersetup aufweist und auch nur eine eingefrorene Zustandsnderung von Registrykeys, Dateien, Services, etc. beinhaltet. Windows Installer Setups sind meist viel komplexer aufgebaut, als dass sie nur eine Summe dieser besagten Ressourcen wren.

    Die Paketierungsart ist unbedingt nach der unten dokumentierten Reihenfolge zu whlen:

    1. Hersteller-MSI

    2. Snapshot-MSI (Repaketierung)

    3. Legacy-Setup, ausgefhrt ber Kommandozeilenparameter via PreInstall oder eigenem Script

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 54/122

    Ist die Verwendung eines Hersteller-MSIs nicht mglich (Legacy-Setup) oder ist diese Paketierungsart nur mit unverhltnismssig grossem Aufwand zu bewerkstelligen, so kann als zweite Wahl das Paket mittels Techniken der Repaketierung (Snapshot mit Wise Package Studio) erstellt werden. Bei diesem Verfahren erhlt man eine MSI-Datei, die gegenber einem direkt aufgerufenen Legacy-Setups immer noch folgende Vorteile bietet (nicht abschliessend):

    Sie ist transparent.

    Man kann globale Einstellungen (beispielsweise Einstellungen fr Add/Remove Program (ARP)) und Applikationseinstellungen (bspl. Servernamen) anpassen.

    Es knnen Dateien und Komponenten aus der Installation ausgeschlossen werden.

    Die Installation kann auf Softwarekonflikte getestet werden (Conflict Explorer 2009).

    Die Verwendung von Legacy-Setups ber einen Aufruf im PreInstall oder eigenem Script (INI:ExecuteFile) ist nur in Ausnahmefllen zulssig. Fr hardwarenahe Treibersoftware kann dies eventuell sinnvoller sein, als die Repaketierung des Legacy-Setups.

    4.12 Pfadlnge

    Die maximale Pfadlnge welche von NTFS untersttzt wird betrgt 32767 Zeichen (individuelle Elemente im Pfad: max. 255 Zeichen).

    Das eigentliche Windows API untersttzt aber nur 260 Zeichen fr die maximale Pfadlnge (http://msdn.microsoft.com/en-us/library/aa365247.aspx)! Das heisst, dass der Pfad zu den SCCM Paket-Sourcedateien diesen Wert nicht berschreiten darf.

    Bei Hersteller-MSI-Paketen, die externe Dateien in Unterverzeichnissen verwenden, wird zur Verkrzung der Pfadlnge die Verwendung von MakeCab.vbs empfohlen, damit man Cabinettdateien erstellen und die extern vorliegende Source anschliessend lschen kann. Die Ausfhrung ist zu diesem Zweck auf einem fixen Laufwerk empfohlen, damit man nicht auch bei der Ausfhrung von MakeCab an die Pfadlngengrenzen kommt. Siehe Kapitel 6.3.12 Verwendung von MakeCab.vbs

    4.13 Automatisierung der Benutzereinstellungen

    Notwendige Benutzereinstellungen sind nach Vorgabe zu implementieren. Zudem sollten unntige Dialogboxen, die whrend dem Starten der Anwendung erscheinen und die sich ausblenden lassen, automatisiert fr alle Benutzer ausgeblendet werden (Siehe auch Kapitel 6.5 Umgang mit Benutzerressourcen). Beispiel einer auszublendenden Anzeige:

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 55/122

    4.14 Keine automatischen Updates

    Bietet das Programm Einstellungen zur Auswahl, ob Updates automatisch heruntergeladen oder installiert werden sollen, so sind diese Einstellungen durch den Paketierer im Softwarepaket auf keine Updates hinunterladen/installieren zu setzen. Manchmal entspricht der Funktionalitt auch nur ein entsprechender Registrykey. Handelt es sich bei den Einstellungen um Benutzereinstellungen (bspl. HKCU), dann ist das Vorgehen aus Kapitel 6.5 Umgang mit Benutzerressourcen anzuwenden.

    4.15 Sprachen und Spracheinstellungen

    Handelt es sich bei der Software um eine MUI-fhige Version, wo die Sprache des GUI nicht automatisch ndert, sondern innerhalb der Applikation ausgewhlt werden kann und findet sich eine einfache Reprsentation der Einstellung in der Registry oder ber eine editierbare Konfigurationsdatei (bspl. INI-Datei), so ist das Design des Softwarepakets so vorzusehen, dass dieses die Standardsprache nach Sprachausprgung des Betriebssystems automatisch einstellt. In diesem Fall ist der Registrykey HKLM\Software\APS\MainLanguage auszulesen. Dieser Registrykey enthlt den Sprachcode GE, FR, IT oder EN. Je nach Inhalt dieses Registrykeys knnen nun die erforderlichen Einstellungen durch das Softwarepaket vorgenommen werden. Ein MUI-fhiges Softwarepaket ist im Paketunterverzeichnis Architektur-Sprache abzulegen, also beispielsweise unter x86-ML.

    Das gleiche Verfahren ist auch anzuwenden, wenn es sich nicht um eine MUI-fhige Software im klassischen Sinne handelt. D.h., wo die GUI-Sprache der Software zwar nach der Installation nicht vernderbar ist, wo aber das Installationssetup oder die Hersteller-MSI-Datei mehrere Sprachvarianten enthlt. In diesem Fall ist durch den Softwarepaketierer ebenfalls der Registrykey HKLM\Software\APS\MainLanguage auszulesen und die Sprachkomponenten sind dynamisch je nach Inhalt des Registrykeys zu installieren. Anbei finden Sie ein Beispiel zum Auslesen des MainLanguage-Registrykeys aus einer MSI-Datei mittels einer MST-Manipulation:

    Architektur-Sprache (x86|x64-ML)

    Revisionsverzeichnis mit den Installationsressourcen (MSI, MST, etc.)

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 56/122

    Werden hingegen verschiedene Sprachvarianten vom Hersteller geliefert (beispielsweise in Form verschiedener MSI-Dateien), so sind durch den Softwarepaketierer verschiedene Sprachverzeichnisse im Softwarepaket zu erstellen, wo die Ressourcen eingepflegt werden. Der Package-Launcher ermittelt hier automatisch, welche Installationsressourcen aus welchem Ordner bei der Installation angewendet werden sollen.

    Weitere Informationen zu der Ablagestruktur finden Sie im Kapitel 5.2 Entwicklungsumgebung.

    4.16 Installation im Systemkontext

    Softwarepakete mssen sich im Systemkontext installieren lassen. Zu beachten ist, dass im Systemkontext insbesondere der Zugriff auf externe Netzwerkressourcen und Netzwerkverzeichnisse nicht mglich ist. Es gibt Hersteller-Setups, die anders reagieren, wenn sie unter dem Systemkontext installiert werden!

    4.17 Silent Installationen

    Alle Softwarepakete mssen silent installierbar sein. Problematisch sind insbesondere auch Anzeigedialogboxen, die sich whrend einem Fehler zeigen und die die weitere Ausfhrung der Installation verhindern knnen, wenn diese Softwarepakete ohne Desktop mittels SCCM installiert werden.

    4.18 Verwendung von variablen Servernamen

    Servernamen sind nach Mglichkeit variabel ber die INI-Datei des Softwarepakets zu implementieren. Dadurch lsst sich bei einem Wechsel des Servernamens eine schnelle Anpassung des Softwarepakets an einem zentralen Ort bewerkstelligen (Siehe auch Kapitel 3.5 INI-Datei )

    Architektur-Sprache (fr jede Sprachausprgung)

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 57/122

    5 Handling der Upgrades und Revisionsupdates

    Der Package-Launcher verwaltet alle Installationen, Softwareupgrades und updates selbstndig. Fr den Softwarepaketierer bedeutet dies, dass er bei einem Updateauftrag all seine nderungs-absichten immer in einem (oder in Ausnahmefllen mehreren) zustzlichen Revisions-verzeichnis/sen abbilden muss. Das Vorgehen hierzu ist recht einfach: Durch das Kopieren der Installationsressourcen (MSI, MST, MSP, etc.) in das neue Revisionsverzeichnis ist nmlich ein grosser Teil der Aufgabe bereits erledigt.

    Fr den Softwarepaketierer ist es erforderlich, dass er die Grundlageninformationen aus dem Kapitel 2 & 3 gut kennt. Wir finden insbesondere im Kapitel 2.2 Updates und Upgrades und im Kapitel 3.6 Realisierung eines Upgrades weitere Ausfhrungen zu diesem Thema.

    Einige Beispiele der Umsetzung von Auftrgen in das Design des Softwarepakets: d

    Form des Softwarepakets: Initialversion

    Auftrag: Auftrag ber neue Software, die es in der Umgebung des Unternehmens in keiner anderen Version gibt und die kein Vorprodukt ablst. Sogenannte RTM (Release To Manufacturer)

    Umsetzungsbeispiel: Neue Version mit CreatePackage erstellen und Bedrfnisse dort in der Revision 001 (Unterverzeichnis 001) abbilden.

    Form des Softwarepakets: Upgrade

    Auftrag: Auftrag einer neuen Software, wo es in der Umgebung des Unternehmens ein Softwarepaket einer Vorversion gibt und wo sich die Bedrfnisse nicht in einem Revisionsupdate (siehe unten) abbilden lassen.

    Umsetzungsbeispiel: Neue Version mit der selben Namensbezeichnung wie das Softwarepaket der Vorversion (ohne Version) mit CreatePackage erstellen und Bedrfnisse dort in der Revision 001 (Unterverzeichnis 001) abbilden. Ev. Upgradefunktionalitt ber den Bezeichner Upgrade der Softwarepaket-INI-Datei anpassen. Siehe Kapitel 6.14.1 Upgrade Handling.

    Form des Softwarepakets: Revisionsupdate (Beispiel 1)

    Auftrag: Neue Software fr die es in der Umgebung des Unternehmens bereits ein Softwarepaket in einer Vorversion gibt und die in Form von Anpassungen und Erweiterungen zu dieser Vorversion implementiert werden kann (bspl. Kopieren zustzlicher oder neuerer Dateien, etc.). Der Auftrag selbst muss nicht zwingend als Updateauftrag bergeben worden sein!

    Umsetzungsbeispiel: Das Softwarepaket HP-Demo-1.0 existiert in der Revision 001. Nun kme ein Auftrag der Version 1.1, in der einige DLL-Dateien aktualisiert werden mssten. Hier kann das bestehende Softwarepaket HP-Demo-1.0 mit einer zustzlichen Revision 002 erweitert werden. In das neu zu erstellende Verzeichnis 002 kopiert der Softwarepaketierer die neue MSI-Datei, welche diese einzelnen Dateien kopiert. Die Bezeichnung des Version-Verzeichnisses wird nicht gendert (1.0)!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 58/122

    Form des Softwarepakets: Revisionsupdate (Beispiel 2)

    Auftrag: Nachdem fr eine Software ein Softwarepaket erstellt und dieses in die Produktion berfhrt wurde, mssen Anpassungen an Einstellungen (bspl. Registry, INI, Shortcuts, etc.) vorgenommen werden.

    Umsetzungsbeispiel: Das produktive Softwarepaket HP-Demo-1.0 existiert in der Revision 001. Die neuen Anforderungen sind nicht durch nderung in dieser Revision 001 umzusetzen! Auch hier kann das bestehende Softwarepaket HP-Demo-1.0 mit einer zustzlichen Revision 002 erweitert werden. In das neu zu erstellende Verzeichnis 002 kopiert der Softwarepaketierer die neue MSI-Datei, ein PreInstalloder Script, welches die nderungsaufgaben bernimmt. Die Bezeichnung des Version-Verzeichnisses wird nicht gendert (1.0)!

    Form des Softwarepakets: KeepRevision

    Auftrag: Nach der Verteilung eines Upgrades wurde ein Fehler festgestellt und der weitere Verteilungsauftrag gestoppt. In einer Revision 001 eines produktiven Softwarepakets, welches in Form eines Upgrades konzipiert wurde, sollte nun eine Korrektur gemacht werden, welche eine lokal unterschiedliche Einstellungsdatei der Vorversion der Software vor einer knftigen Upgradeinstallationen sichert und nach dem Upgrade wieder auf das Zielsystem kopiert.

    Die nderungsabsichten lassen sich nicht in einer zustzlichen Revision realisieren, da die zu sichernde Datei bei der chronologischen Installationsabfolge der Revisionen bei Beginn der letzten Revisionsinstallation bereits gelscht, bzw. mit dem Standardinhalt neu geschrieben wre.

    Umsetzungsbeispiel: Die nderungen sind am bestehenden Softwarepaket der Revision 001 vorzunehmen. Zustzlich wird eine (neue) Build-Datei in das Revisionsverzeichnis eingefgt, wo die nderungen gemacht wurden. In unserem Fall im Verzeichnis der Revision 001. Die Bezeichnung der Build-Datei unterliegt der Namenskonvention und trgt den Namen des Softwarepakets, gefolgt vom Revisions-Bezeichner und der Erweiterung .BLD (Bspl. HP-Demo-1.0_001.BLD). In der Datei ist ein fortlaufender, 4-stelliger Zhler anzufgen. Bei der ersten Vernderung wre dieser also auf 0002 zu stellen. Im Kapitel 3.14 Build-Datei ist die Verwendung der Build-Datei detaillierter erklrt.

    Achtung:

    Die Verwendung von KeepRevisionen sollte nur wenn zwingend ntig, ausnahmsweise zum Einsatz kommen!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 59/122

    5.1 Entwicklungsumgebung

    Fr die Entwicklung der Softwarepakete ist ein eigener Share vorgesehen. Die Erstellung der Ablagepfade der Paketentwicklung erledigt ein Tool mit dem Namen CreatePackage.EXE. Im Kapitel 6.2 CreatePackage wird auf die Bedienung dieses Tools eingegangen.

    Beispiel der Paketentwicklungsumgebung:

    5.2 Produktionsumgebung

    Die Ablagestruktur der Produktionsumgebung wird durch das Script SCCMCreateApp_Link.vbs automatisch erstellt und die fr dort erforderlichen Daten kopiert. Hierbei wird der Pack-Ordner inkl. Unterordner und der Rev-Ordner in einen Ordner/Unterordner des Produktionsshares berfhrt.

    5.3 Namensbezeichnungen

    Hersteller: Handelt es sich um eine Freeware (General Public License), so ist als Herstellernamen die Bezeichnung GPL zu verwenden. Falls der Herstellername nicht bekannt ist, ist die Bezeichnung Misc erforderlich. In allen anderen Fllen verwendet man den Namen des Herstellers.

    Produktename: Name der Software

    Version: Technische Versionsbezeichnung nach der Syntax Major.Minor. In der Regel verwendet man einstellig gekrzte Minorbezeichnungen. In Ausnamefllen kann aber auch eine mehrstellige Minorversion zum Einsatz kommen.

    5.3.1 Limitierungen und Einschrnkungen

    Die Gesamtzeichenanzahl ist auf 39 Zeichen (Hersteller, Name, Version, ohne Bindestriche) beschrnkt (nur SCCM 2007). Zudem sind folgende Zeichen bei den Namen nicht erlaubt:

    Leerzeichen Bindestrich - (Wird nur als Paketbezeichnungstrennzeichen Hersteller-Name-

    Version eingesetzt)

    Hersteller

    Produktename

    Version (Major.Minor)

    Dokumentationsverzeichnis

    Architektur-Sprache (x86|x64-GE|EN|FR|IT|ML)

    Revisionsverzeichnis, chronologisch aufsteigend, beginnend mit 001

    (Verzeichnis der Installationsressourcen. Bspl. MSI/MSP/MST)

    Verzeichnis mit isolierten Revisions/Pack-Ordner fr SCCM-Revisionsupdate

    Vorlagenordner Pre/PostInstall und Securitybatch

    Sicherungsverzeichnis fr Softwarepaketierer (bspl fr .WSI-Datei)

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 60/122

    6 Phasen der Paketerstellung

    Die Softwarepaketierung erfolgt in mehreren Schritten und fngt mit dem Auftragseingang, bzw. mit der Zuweisung dieses Auftrages an den Softwarepaketierer an und endet blicherweise nach diversen Abschlusstests und der Distribution auf die Integrations- oder Produktions-plattform.

    Die meisten der nachfolgenden Ausfhrungen dieses Kapitels werden in der Reihenfolge beschrieben, wie sie im Softwarepaketierungsprozess zum Einsatz kommen.

    6.1 Vorarbeiten

    Bevor mit der eigentlichen Softwarepaketierung begonnen wird, informiert sich der Softwarepaketierer, was er zu erledigen hat, indem er den Auftrag und allflligen Mailverkehr betreffend der zu implementierenden Anwendung studiert. Zudem macht sich der Softwarepaketierer ein Bild ber die Software, die er zu paketieren hat, indem er diese auf seiner VM-Guest gem. Anleitung installiert, die Anwendung startet und sich mit allflligen Eigenschaften des Produktes auseinandersetzt.

    6.2 CreatePackage

    Mit dem Tool CreatePackage.EXE kann die initiale Ablagestruktur der Softwarepaket-entwicklungsumgebung erstellt werden (Revision 001). Zudem werden alle fr den Software-paketierer notwendigen Vorlagen und Automatisierungsscripts kopiert.

    Wichtige Scripts fr die Arbeiten des Softwarepaketierers:

    Softwareinstallation

    analysieren/testen.

    CreatePackage

    ausfhren

    Softwarepaket

    bauen

    Softwarepaket

    integrieren

    Softwarepaket

    testen

    Fgt Standardproperties dem Paket hinzu

    Erstellt SCCM Pkg/Collection/Advertisement

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 61/122

    Im Wurzelverzeichnis des PLPackDEV-Shares befindet sich das Startscript zum Aufruf von CreatePackage. Mit einem Doppelklick starten Sie das Programm:

    Geben Sie anschliessend die erforderlichen Kenndaten ein. Unter Sprache und Architektur knnen mehrere Optionen gleichzeitig gettigt werden. Wird ein Paket erstellt, welches mehrsprachig ist oder die Sprachausprgung in einer Softwareeinstellung durch den Benutzer gewhlt werden kann oder wo die Software die Clientsprache selbstndig erkennt und dadurch die Spracheinstellungen fr die Software selbstndig vornimmt, ist als Sprachvariante einzig Mehrsprachig zu whlen.

    Die Architekturoptionen beziehen sich auf die Installationsinstanz und das Setup. Zielt das Setup auf x86 Rechner, ist hier x86 zu whlen (solche Setups knnen auch unter x64 eingesetzt werden). Ist das Design des Setups hingegen fr x64 Rechner ausgelegt (volle x64er Kompatibilitt), whlt man x64 (solche Setups knnen nur unter x64 installiert werden). Paketiert der Paketierer beide Varianten in einem Paket (zwei verschiedene Setups), so sind beide Optionen auszuwhlen.

    Die Option AppV Paket fgt dem Paketnamen zustzlich noch ein (V) an.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 62/122

    6.3 Verwenden eines Hersteller MSIs

    Wird vom Hersteller die Installation ber eine MSI-Datei angeboten, so sind diese Ressourcen als Basis fr das Softwarepaket zu verwenden. Siehe auch Kapitel 4.11 Paketierungsarten. In solchen Fllen wenden wir keine Repaketierung an. Ausserdem ist der direkte Einsatz einer Hersteller-MSI-Datei auch der Installation eingebetteter MSI-Dateien via Bootstrapper vorzuziehen. Bootstrapper (Setup.EXE) sind daher immer darauf zu analysieren, ob diese eingebettete MSI-Dateien zur Installation enthalten, welche fr die Paketierung verwendet werden knnen! Zudem wird in der Regel erst durch eine solche Analyse ersichtlich, welche Abhngigkeiten von der Produkteinstallation vorausgesetzt und installiert werden. Siehe hierzu auch Kapitel 4.5 Abhngigkeiten (Middlewares).

    Liegt die bergebene Source bereits in Form von MSI-Dateien vor, so kann mit Kapitel 6.3.3 Protokolldatei analysieren weitergefahren werden. Ist hingegen nur eine Setup.EXE verfgbar, so sind die Arbeitsschritte der nchst folgenden Kapitel durchzuarbeiten.

    6.3.1 Auspacken von Installationselementen aus einem Bootstrapper

    Analysieren Sie jedes Setup! Oft werden Windows Installer Setups nicht als native MSI-Dateien angeboten, sondern sind in Bootstrapper eingepackt, welche die zum Betrieb der Applikation erforderlichen Abhngigkeiten installieren (Redistributables), bevor dann die effektive MSI-Datei abgearbeitet wird.

    Wenn sich die MSI-Datei nicht ber Parameter auspacken lsst, so findet man die extrahierte Source nach dem Starten des Setups mit Benutzer-Interface und nach Erscheinen des ersten Windows Installer Dialogs lokal auf dem Client. Starten Sie das Setup.EXE hierzu auf einer Clean Machine, damit Sie auch erkennen knnen, welche Abhngigkeiten durch das Setup installiert werden. Siehe auch Kapitel 4.5 Abhngigkeiten (Middlewares). Der Initialisierungsteil des Client-Prozesses von Windows Installer, der whrend der Abarbeitung der Dialoge aktiv ist, kopiert die MSI-Datei als eine der ersten Operationen vom (extrahierten) Quellenverzeichnis in den %TEMP%-Ordner. Lokalisieren Sie daher beim Erscheinen der ersten Windows Installer Dialogmaske auf dem Client die extrahierte MSI-Datei. Erweitern Sie Ihre Suche aber auch auf andere Orte der Festplatte. Es kann sein, dass sich extern vorliegende Cabinett-Daten und andere zur Installation gehrende Ressourcen in einem anderen Verzeichnis befinden. Wenn Sie die MSI-Datei, samt ihren zustzlich bentigten Daten gefunden haben, kopieren Sie diese in ein sicheres Arbeitsverzeichnis. Die Dateien im %TEMP%-Verzeichnis werden nach Beendigung des Setups automatisch gelscht! Achten Sie auch darauf, dass sie nur Dateien kopieren, die Sie zur Ausfhrung der MSI-Datei bentigen. Denn Bootstrapper erstellen in der selben Struktur oft auch andere temporre Dateien, die fr das Customizing nicht ntig sind (InstMsi*.EXE, etc.). Zudem werden whrend der Ausfhrung des Setups auch Daten aus der Binary-Tabelle der MSI-Datei ausgepackt, auf welche wir getrost auch verzichten knnen (CustomActions, Dateien der InstallScript Engine, etc.).

    6.3.2 Ermitteln des Paketierungsumfangs

    Wurden alle MSI-Dateien, die ausgepackt wurden, beiseite kopiert, dann kann mit Orca ermittelt werden, um was fr MSI-Dateien es sich bei dieser Installation handelt. Zur Analyse knnen auch die im %TEMP%-Verzeichnis entstandenen Protokolldateien (bei eingeschalteter Protokollierung

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 63/122

    Logging=voicewarmupx in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\-Installer) analysiert werden. Unterteilen Sie die Source in die zwei Kategorien

    1. Abhngigkeiten

    2. Installation der Anwendung

    und identifizieren, bzw. trennen Sie lokale von globalen Abhngigkeiten (siehe Kapitel 4.5 Abhngigkeiten (Middlewares)). Prfen Sie zudem, welche der Abhngigkeiten im Umfeld des Unternehmens schon paketiert sind und notieren Sie deren Namen fr die Implementation in der zur Zielanwendung gehrenden INI-Datei (Dependence-Eintrag).

    6.3.3 Protokolldatei analysieren

    Oft werden durch den Bootstrapper auch Properties bergeben, die sich in der temporren Protokolldatei %TEMP%\MSI?????.LOG wiederfinden (bei eingeschalteter Protokollierung Logging=voicewarmupx). Diese Datei ist auf die bergebenen Properties im Startbereich unter Command Line: zu prfen. Die erweiterten Properties knnen spter mittels der INI-Datei oder der MST-Datei bergeben werden. In dieser Phase sind diese zumindest zu notieren. (Achtung: CURRENTDIRECTORY, CLIENTUILEVEL, CLIENTPROCESSID, %HOMEPATH, %HOMEDRIVE und %HOMESHARE knnen dabei ignoriert werden. Diese Properties sind in jeder bergabezeile zu finden)

    6.3.4 In-Place-Update von Patches (Splipstreaming)

    Wird ein initiales Softwarepaket erstellt, also nicht ein Update (Revisionsupdate) eines bestehen-den produktiven Pakets, und werden beim gelieferten Herstellersetup MSP-Patches mitgeliefert, bzw. lassen sich diese aus der Setup.EXE auspacken, so kann und sollte die Hersteller-MSI-Datei gleich mit allen erforderlichen MSP-Dateien chronologisch in Form von In-Place-Updates gepatcht werden (sofern mglich). Der Vorteil dieses Verfahrens ist der, dass die MSI-Installation und der Patch spter in einer einzigen Installationstransaktion installiert werden knnen.

    1. Zu diesem Zweck ist eine Administrativinstallation zu erstellen:

    msiexec /a TARGETDIR= /L*v /qb-

    Verwenden Sie unbedingt ein TARGETDIR, welches sich vom Verzeichnis von unterscheidet, ansonsten wird die administrative Installation mit einer Fehlermeldung quittiert.

    Achtung: Ist das Attribut-Flag in der Components-Tabelle irgend einer Komponente auf Never-Overwrite (128) gesetzt und sind diese so markierten Komponenten auf dem System registriert, wo die administrative Installation ausgefhrt wird, so entpackt der Parameter /a die damit verbundenen Dateien nicht. Bei spteren Zugriffen wrde diese Datei fehlen und man knnte das Produkt auch nicht mehr fehlerfrei rekompilieren (erneutes Erstellen von Cabinett-Dateien).

    2. Schliesslich wird das In-Place-Update auf die Administrativinstallation angewendet:

    msiexec /p /a

    Dieser Vorgang ist fr jede MSP-Datei in der richtigen Reihenfolge durchzufhren. Die so entstandenen Ressourcen knnen dann als Basis fr das Softwarepaket verwendet werden und sind zustzlich im Work-Ordner des Softwarepakets zu sichern. Nach Anwendung eines In-Place-Updates ist bei der erstmaligen Installation der so entstandenen MSI-Datei die Anwendung darauf zu prfen, ob diese den ntigen Patch-Level ausweist!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 64/122

    6.3.5 Verwendung von InstallShield-Setups

    Auch viele InstallShield-Setups enthalten eine lauffhige MSI-Datei, die entpackt und anstelle des Setup-Bootstrappers verwendet werden kann. Beim Paketieren eines InstallShield-Setups ist dieses zwingend auf das Vorliegen einer eingebetteten MSI-Datei zu analysieren. Sollte eine MSI-Datei zu entpacken sein, so ist diese Datei anstelle des Bootstrappers zu verwenden. Die MSI-Datei kann mit entsprechender MST-Datei in das Revisionsverzeichnis eingefgt werden.

    Grundstzlich ist auch hier das im Kapitel 6.3.1 Auspacken von Installationselementen aus einem Bootstrapper und die in den Kapitel 6.3.2-6.3.3 beschriebenen Verfahren anzuwenden. Zustzlich ist die MSI-Datei nach dem Auspacken auf das Vorkommen der CustomActions ISVerifyScriptingRuntime und OnCheckSilentInstall zu prfen. Wenn diese in der MSI-Datei zum Einsatz kommen, dann kann die Property ISSETUPDRIVEN=1 in die Propertytabelle der zu erstellenden MST-Datei eingefgt werden, um einen Installationsablauf ohne Setup-Bootstrapper zu ermglichen. Die CustomActions wrden dazu dienen, eine Fehlermeldung anzuzeigen, wenn die Installation ohne Setup.EXE ausgefhrt wird.

    6.3.6 Installationssource kopieren

    Fr jedes im Rahmen dieses Auftrages zu erstellende einzelne Softwarepaket (Zielanwendung inkl. Abhngigkeiten) ist die durch Auspacken entstandene Source in das Revisionsverzeichnis des Softwarepakets zu kopieren. Zum Erstellen der Ablagestruktur verwenden Sie CreatePackage (siehe Kapitel 6.2 CreatePackage)

    6.3.7 Erstellen einer MST-Datei fr alle weiteren Customizing-Arbeiten

    nderungen an der jetzt eingepflegten MSI-Datei sind aus Grnden der Transparenz in eine MST-Datei zu implementieren. Zudem verfllt in vielen Fllen der Herstellersupport, wenn Anpassungen direkt in der MSI-Datei erfolgen wrden. Weitere Details im Zusammenhang mit MST-Dateien ersehen Sie aus dem Kapitel 6.6 Grundregeln bei der Anwendung von MST Dateien.

    6.3.8 Spezielle Einstellungen ber das Benutzerinterface des Herstellersetups

    Mssen Eingabeoptionen ber Setup-Dialogfelder konfiguriert werden, so empfiehlt sich der Einsatz von InstallTailor (Wise Package Studio). Mit diesem Tool kann man ber Response Transforms eine sog. Antwortdatei erstellen. In dieser Betriebsart werden die Setupdialoge abgearbeitet und Property-Vernderungen aufgezeichnet. Hierbei wird die Speicherung einer temporren MST-Datei empfohlen, wo die fr den Paketierer wichtigen Property-Eintrge

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 65/122

    anschliessend mit Orca in die bestehende STANDARD.MST oder eine neue leere MST-Datei eingefgt werden. Diese Bereinigungsarbeit ist ntig, damit nicht willkrliche Setup-Anpassungen eingefroren werden, die sich aus dem Anpassungsvorgang zum Zeitpunkt des Betriebs von InstallTailor ergeben. Zudem ist eine bereinigte MST-Datei viel transparenter fr Nachfolgeaufgaben, als die, die direkt entstehen wrde.

    Eine andere Mglichkeit zur Ermittlung von Propertyvernderungen ist die Analyse der Protokolldatei nach manueller Ausfhrung des Setups (bei eingeschalteter Protokollierung Logging=voicewarmupx. Alle Vernderungen der Properties, ausser diese die ber MsiHiddenProperties in der Propertytabelle der MSI-Datei vermerkt sind, sollten so ermittelbar sein. Die so ermittelten Propertyvernderungen sind dann in die MST-Datei zu bertragen.

    6.3.9 Wahl von Features mit INSTALLLEVEL

    Fr einfachere Wahl/Abwahl von Features verwenden Sie die INSTALLLEVEL-Property. https://msdn.microsoft.com/en-us/library/aa369536(v=vs.85).aspx)

    Level-Eintrge in der Feature Tabelle grsser der INSTALLLEVEL-Property in der Property-Tabelle deselektiert das entsprechende Feature bei der Installation.

    6.3.10 ShortCuts

    Lschen oder Verndern Sie die Shortcuts nach Vorgaben des Applikationsverantwortlichen und den Regeln, die im Kapitel 4.2 Startmen und ShortCuts dokumentiert sind. Die Vernderungen sind in der MST-Datei in der ShortCut-Tabelle anzuwenden. Fr alle Vernderungsabsichten, die nicht direkt in der MST-Datei durchgefhrt werden knnen, ist die Umsetzung ber die Pre- oder PostInstall_00x.wse empfohlen.

    6.3.11 Probleme mit der Silentinstallation

    Sollten sich betriebsauswirkende Unterschiede im Installationsablauf ergeben, je nachdem, ob die Ausfhrung silent initiiert oder das Setup mit BenutzerInterface gestartet wurde, dann mssen sie sich Gedanken darber machen, was denn nun mit der UI anders luft als ohne:

    berprfen Sie die Conditions in der LaunchCondition-, Condition-, Component- und InstallExecuteSequence-Tabelle nach Verweisen auf den UILevel oder auf Properties, die in der ControlEvent-Table gesetzt werden. berprfen Sie vor allem auch die ControlEvent-Tabelle nach DoAction-Ereignissen, welche auf Controls in Ihren ausgewhlten Dialogen folgen. berprfen Sie so ermittelte CustomActions auf Existenz in der InstallExecuteSequence und fgen Sie diese falls erforderlich dort ber die Transformdatei ein. berlegen Sie sich gut, in welcher Sequenz sie diese einfgen. Wenn es sich um benutzerdefinierten Aktionen aus Dialogen vor der effektiven Installation handelt, so sind diese Aktionen am besten vor der Scripterstellung, vor InstallInitialize einzufgen. Andere CustomActions die erst ber einen Abschlussdialog zur Ausfhrung kmen, wren nach InstallFinalize einzutragen.

    6.3.12 Verwendung von MakeCab.vbs

    Von externen Ressourcen, die im Rahmen einer Administrativinstallation entstanden sind oder in dieser Form vom Hersteller geliefert wurden, knnen mit dem Script MakeCab.vbs Cabinett-

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 66/122

    dateien erstellt werden, ohne dass die MSI-Datei des Herstellers mit Wise Package Studio - unter der nachteiligen Erweiterung der MSI-Datei mit zustzlichen Anpassungen um vieler Properties und Tabellen - kompiliert werden muss.

    Zur Ausfhrung ist eine Kommandozeile mit dem Script MakeCab.vbs und der Verwendung des MSI-Pfades in einer DOS-Konsole abzusetzen:

    Das Script erstellt dann die Cabinettdateien im Wurzelverzeichnis der MSI-Datei. Die externen Source-Daten knnen nach der Operation ins Work-Verzeichnis verschoben werden.

    Grsse der Cabinettdateien

    Standardmssig werden durch das Script 100MB externe Cabinett-Dateien erstellt. Auf Wunsch kann aber die Grsse mittels einer zweiten Kommandozeilenoption angepasst werden. Hier wre die Grsse der Cabinett-Datei in Kilobyte anzugeben.

    Achtung: Die Grsse einer Cabinettdatei ist auf 2GB beschrnkt!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 67/122

    6.4 Paket mit Wise Pakage Studio repaketieren

    Ist in den Installationsmedien keine eingebettete MSI-Datei vorhanden und ist durch den Hersteller auch keine MSI-Datei verfgbar, so wird ein Softwarepaket repaketiert. Als Repaketierung wird der Prozess bezeichnet, welcher verwendet wird, um bei einem Legacy-Setup oder bei Rohdaten per Snapshot-Verfahren ein Windows Installer Setup zu erhalten.

    6.4.1 Regeln im Zusammenhang mit repaketierten Software-Paketen

    Bei der Repaketierung gelten alle im Kapitel 4 Best-Practice Regeln und Limitierungen aufge-fhrten Regeln. Zustzlich sind folgende Regeln einzuhalten:

    6.4.1.1 Selbstregistrierung von Dateien und Verwendung von Advertising-Tabellen

    Die Einbindung von SelfReg-Informationen in der SelfReg-Tabelle der .WSI/.MSI-Datei ist abzuschalten. SelfReg-Informationen sollen nur ber die Registry-Tabelle implementiert werden. Auch alle anderen Advertising-Tabellen mssen nach dem Snapshot-Prozess leer sein: AppID, ClassID, Extension, Mime, ProgID, SelfReg, TypeLib, Verb.

    Wise Package Studio verhindert das Abfllen dieser Tabellen durch die Wahl der folgenden Option: Advertising Setting: Retain registry information as-is:

    Diese Option sollte bei einer Standardinstallation von Wise Package Studio bereits so eingestellt sein.

    6.4.1.2 Keine virtualisierten Daten (VirtualStore)

    Whrend des Snapshot-Prozesses drften eigentlich keine virtualisierten Daten entstehen, da dieser als Administrator gestartet wird. Vorsichtig muss man erst bei einer nach der Anwendungsinstallation durchzufhrenden Konfiguration sein. Alle Prozesse, die dann im Rahmen einer Konfiguration gestartet werden, beispielsweise auch der Start der

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 68/122

    Hauptapplikation, mssen als Administrator ausgefhrt werden, um eine allfllige Datei- und Registrierungsvirtualisierung zu verhindern.

    Zudem sind beim Anzeigen der Ressourcen nach dem After-Snapshot, diese auf Eintrge im VirtualStore zu prfen. Dort vorgefundene Ressourcen im VirtualStore sind zwingend im Originalverzeichnis/Originalregistryhive zu implementieren! Gegebenenfalls ist der Repaketierungsprozess neu zu starten.

    6.4.1.3 Mergemodule

    Mergemodule werden von Real Packaging GmbH beim Repaketierungsprozess in der Umgebung des Unternehmens nicht empfohlen.

    6.4.1.4 Umgang mit Abhngigkeiten

    Auch bei einer Repaketierung sind Software-Abhngigkeiten aus dem Legacy-Setup zu identifizieren und zu isolieren. Erkennt der Softwarepaketierer eine Abhngigkeit, die mit dem Setup installiert wird, welche sich entweder separat verpacken lsst oder wovon vom Hersteller ein isoliertes Setup erhltlich ist, so ist dieses einzeln zu paketieren.

    Zudem sind allfllige Abhngigkeiten vor dem Snapshot der fokussierten Hauptapplikations-installation auf das System zu installieren und die Abhngigkeit ist in der Softwarepaket-INI-Datei als Dependence-Erweiterung anzubringen (bei globalen Abhngigkeiten). Ferner wird die Erstellung einer Customized Task Sequence in SCCM erforderlich. Siehe dazu auch das Kapitel 4.5 Abhngigkeiten (Middlewares).

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 69/122

    6.4.2 Umgang mit Computerneustarts

    Wenn ein technischer Computerneustart whrend des Repaketierungsprozesses fr den Betrieb der Applikation notwendig ist, so fhren Sie diesen nach Abschluss der Installation, aber vor einer allflligen Softwarekonfiguration und vor allem vor dem Abschluss von SetupCapture aus, ohne den Dialog von SetupCapture selbst zu beenden.

    Nach einem Computerneustart startet unter Windows 7 dann Wise Package Studio Workbench automatisch. Da SetupCapture ein Elevated-Prozess ist, muss dieser aber unter Windows 7 manuell aus dem Startup-Ordner gestartet werden!

    6.4.3 Snapshotprozess mit Wise Package Studio

    Ein Snapshot wird mit Wise Package Studio SetupCapture erstellt. Starten Sie den Prozess ber die Wise Package Studio Workbench:

    (Zu den hier gemachten Angaben gelten die generellen Repackaging Best-Practice Regeln von Wise Package Studio: wps_repkg_basics_whitepaper.pdf)

    Beim nach dem Start von SetupCapture erscheinenden Dialog ist die Einstellung wichtig, dass die Source-Dateien whrend des Setups kopiert werden (siehe Bild rechts).

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 70/122

    Wenn als Ziel (Target Installation) ein lokales .WSI gewhlt wird, so sind diese Ressourcen im Anschluss der Repaketierung in das Softwarepaketverzeichnis im Work-Ordner (am besten unter dem entsprechenden Revisionsverzeichnis) abzulegen.

    Ist der Initialscan des Computers beendet, kann das Setup als Administrator gestartet und anschliessend - nur falls erforderlich die Konfiguration der Anwendung ausgebt werden. Beachten Sie, dass ein Start der Anwendung und anderer Konfigurationswerkzeuge in dieser Phase immer als Administrator ausgefhrt werden! Ist keine Benutzerkonfiguration oder Einstellungsnderung innerhalb der Applikation vorzunehmen, so sollte auf den Start der Anwendung in dieser Phase verzichtet werden. Oftmals werden beim erstmaligen Start div. Benutzerressourcen durch die Anwendung geschrieben, die man mglicherweise nicht mit in den Snapshot implementieren mchte, wenn die Zielanwendung eigene Automatismen dazu verwendet, um diese dem Benutzer zur Verfgung zu stellen.

    Zum Schluss berprfen Sie noch die Verknpfungen, ob diese den im Kapitel 4.2 Startmen und ShortCuts dokumentierten Regeln entsprechen. Korrigieren Sie, sofern ntig.

    Mit Next/Next schliessen Sie den Snapshot ab.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 71/122

    6.4.4 Anschlussarbeiten

    Die wichtigste Ttigkeit nach einem Snapshot ist die Bereinigung der MSI-Installation. Ziel ist es, nur diese Ressourcen im erstellten Softwarepaket zu implementieren, die direkt fr die Anwendungsinstallation notwendig sind. Viele Prozesse, die der Paketierer oder das System whrend des Aufzeichnungsverfahrens startet, hinterlassen Spuren, die der Softwarepaketierer jetzt identifizieren und lschen muss.

    Achten Sie in dieser Phase auch auf virtualisierte Ressourcen, die mglicherweise durch den Snapshot aufgezeichnet wurden (siehe Kapitel 6.4.1.2 Keine virtualisierten Daten (VirtualStore)).

    Mit Next/Next schliessen Sie schliesslich Ihren Snapshot ab. berprfen Sie hier Ihre Ressourcen erneut. Kontrollieren Sie auch, ob Ihr Benutzername nativ in irgendwelchen Tabellen eingetragen wurde und lschen Sie diesen oder verwenden eine variable Benutzerbezeichnung.

    Ist der Prozess der Anschlussarbeiten abgeschlossen, so knnen Sie die .WSI-Datei kompilieren und in das Softwarepaketverzeichnis im Work-Ordner (am besten unter dem entsprechenden Revisionsverzeichnis) ablegen, sofern dies noch nicht erfolgt ist. Zudem Kopieren Sie die beim Kompilierungsprozess erstellte MSI-Datei in das Revisionsverzeichnis des Softwarepakets.

    Alle weiteren Customizing-Aufgaben sind in der Regel in einer MST-Datei abzuspeichern, damit die Transparenz und Lesbarkeit gewhrleistet ist.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 72/122

    6.5 Umgang mit Benutzerressourcen

    Zweifelsohne ist eines der heikelsten Anforderungen an das Softwarepaket die Umsetzung der Installation von Benutzerressourcen (HKCU, %APPDATA%, etc.). In Umgebungen, die den Package-Launcher einsetzen, knnen solche Benutzerressourcen neben der Implementation ber die Reparatur des Basisproduktes im Benutzerkontext, auch ber PostInstall_00x.wse-Erweiterungen hinzugefgt werden. Diese knnen in Form von vorbereiteten Snipplets abgerufen werden. Das Verfahren stellt meist die einfachere Implementationsmglichkeit dar.

    Fr das Design von MST/MST-Dateien, die Benutzerressourcen in Form einer Windows Installer Reparatur installieren sollen (bspl. ber advertised Shortcuts), ist auf folgende Punkte zu achten:

    Die Benutzerressourcen sind in einem eigenen Windows Installer Feature isoliert abzubilden Dieses Feature ist als Top-Level Feature zu markieren. Als Name des Features eignet sich ein sprechender Name wie CurrentUser

    Der KeyPath der den Benutzerressourcen zugewiesenen Komponenten muss auf einen Re-gistrykey in HKCU verweisen. Dies ist insbesondere auch bei Dateiressourcen so zu bewerk-stelligen. Es ist zu gewhrleisten, dass der Registrykey, der als KeyPath verwendet wird, nicht von der Anwendung oder durch Anwendungselemente selbst geschrieben werden kann (beispielsweise, wenn der Benutzer die EXE-Datei der Applikation in der Konsole oder ber Start/Ausfhren startet). Im Zweifelsfall ist ein entsprechender Dummy-Key durch den Softwarepaketierer in HKCU durch die MST-Anpassung selbst zu implementieren.

    Das Initiieren einer Active Setup-Benutzerinstallation ist durch die WiseScript-Vorlage PostInstall_00x.wse zu erledigen. Dort finden sich Snipplets, die fr diese Aufgabe verwendet werden knnen. Siehe Kapitel 6.10 Active Setup in Pre- & PostInstall

    Achten Sie auf die Verfgbarkeit aller Benutzerressourcen, auf die das Softwarepaket zum Zeitpunkt der Benutzerinstallation zugreift. Applikationstests sind daher unbedingt auch im Kontext des Benutzers, ohne Administratorrechte und ohne Zugriff auf die primre Instal -lationssource durchzufhren. Mit dem Bezeichner CopyLocal=True in der INI-Datei des Soft-warepakets kann angegeben werden, dass der Package-Launcher die Source des Softwarepakets vor der Erstinstallation lokal zwischenspeichert (sekundre Installations-source) und die Installation von dort ausfhrt. Siehe Kapitel 6.14.2 Lokaler Cache.

    Oftmals bentigen Applikationen zur Installationszeit keine Benutzerressourcen. Es wird daher vor allem bei repaketierten Anwendungen empfohlen, Benutzerressourcen beim ersten Installationsversuch des Pakets testweise nicht mit zu installieren.

    6.6 Grundregeln bei der Anwendung von MST Dateien

    Grundstzlich sind alle Customizing-Arbeiten durch den Softwarepaketierer in der MST-Datei und nicht in der MSI-Datenbank zu vollziehen. Dies gilt auch bei repaketierten Softwarepaketen, nachdem die Bereinigungsarbeiten erledigt wurden. So wird die Transparenz erhht.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 73/122

    Zur Erstellung und Pflege der MST-Dateien wird Orca empfohlen, da dieses Tool die Umsetzung der Bedrfnisse sauberer umsetzt. Wise Package Studio erweitert MST-Dateien mit einer Reihe von Properties und zustzlichen Tabellen, so dass die Lesbarkeit fr andere Personen und die Wartung darunter leidet.

    Generell wendet der Package-Launcher bei der Installation alle im Revisionsverzeichnis des Softwarepakets befindlichen MST-Dateien an.

    Die einfachste Variante liegt vor, wenn zunchst keine MST-Datei vorliegend ist und man allgemeine Bedrfnisse umsetzen mchte. Hier wre das Script AddProperties.vbs auszufhren. Dieses erstellt eine Standard-MST-Datei mit der Bezeichnung STANDARD.MST. Fr alle weiteren Anpassungen knnte diese MST-Datei entsprechend erweitert werden.

    Liegt hingegen durch den Hersteller bereits eine MST-Datei mit Anpassungen vor, so ist diese vorgngig auf STANDARD.MST umzubenennen, bevor weitere Ergnzungen durch den Softwarepaketierer hinzugefgt werden. Im Allgemeinen ist dies die bevorzugte Variante. Nur, wenn der Softwarepaketierer, die allgemeinen Anpassungen vom Hersteller gegenber den eigenen Erweiterungen abgrenzen mchte, behlt er die Hersteller-MST-Datei bei und fgt dem Softwarepaket mit AddProperties.vbs eine neue STANDARD.MST hinzu.

    6.7 ACL Lockerungen

    Im Einsatz des Package-Launchers werden im Softwarepaketierungsprozess ACL-Lockerungen am Dateisystem und der Registry mittels eines Security-Batches vorgenommen, der Bestandteil des Package-Launchers ist. Der Security-Batch ist in der unter Kapitel 3.7.3 Bezeichnung des Security-Batch dokumentierten Namensgebung im entsprechenden Revisionsverzeichnis zu verwenden.

    Das Programm CreatePackage.EXE (siehe Kapitel 6.2 CreatePackage) kopiert eine ent-sprechende Vorlage des Security-Batches in das Work-Verzeichnis. Diese Vorlage kann nun in das Revisionsverzeichnis kopiert und der Name der Datei mit dem Revisionsbezeichner ergnzt werden.

    Vergewissern Sie sich, dass der in der Datei verwendete Revisionsbezeichner dem Revisionsbezeichner des Revisionsverzeichnisses genau bereinstimmt. Ansonsten wird der Package-Launcher diese Datei nicht anwenden!

    Eine Anpassung implementiert der Softwarepaketierer schliesslich, indem in der Customizing-Section im oberen Teil der Vorlage der Doppelpunkt : am Beginn des Batches entfernt und das zu ffnende Zielverzeichnis am Ende der Zeile anpasst wird ("%PROGRAM_FILES%\myFolder"). Bei Anpassungsvorhaben, die auf die Registry zielen, ist im dritten Block der Customizing-Section nach genau gleichem Muster vorzugehen. Hier ist am Ende der Zeile der zu ffnende Registryhive anzugeben ("HKLM\SOFTWARE\MyApp\User")

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 74/122

    Achtung

    Wird in einer Nachfolgerevision eine Korrektur des ursprnglichen Batches notwendig, dann muss eine neue Variante des Batches in das neue Revisionsverzeichnis kopiert werden, die die alten Inhalte, sowie die Erweiterungen enthlt. Der Package-Launcher kopiert diese neue CMD-Datei bei der Installation der Revision, sofern die Datei neuer ist, als die lokal gespeicherte CMD-Datei. Lokal liegt immer nur eine ACL-CMD-Datei pro Softwarepaket vor.

    Die Anpassungen werden durch den Package-Launcher im Verzeichnis %WINDIR%\Logs in die Datei SetAcl.LOG geschrieben.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 75/122

    6.7.1 Datei und Registrierungsvirtualisierung

    Durch Programme im Kontext des Benutzers durchgefhrte Schreiboperationen, die in die Verzeichnisse %PROGRAMFILES%, %WINDIR%, oder %WINDIR%\System32, sowie in die Registry unter HKLM\Software zielen, werden unter Windows Vista / 7 nach %LOCAL-APPDATA%\VirtualStore, bzw. HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE umgeleitet. Diese Umleitung birgt fr die Softwarepaketierung gewisse Risiken, vor allem im Hinblick mit dem Upgrade von Ressourcen, die auf Clients virtualisiert vorliegend sind. Weitere Informationen findet man unter folgendem Link.

    Zur Reduzierung dieser Risiken werden folgende Massnahmen empfohlen, die der Softwarepaketierer umsetzen soll:

    1. Die Berechtigungen von Verzeichnissen, Dateien und Registrierungsschlssel sind gem.

    Auftrag zu ffnen, sofern die ACL-Lockerungen zum erfolgreichen Betrieb der

    Software ntig sind.

    2. Eine ACL-Lockerung ist unaufgefordert fr alle Ressourcen aus oben beschriebenen

    Verzeichnissen/Registrierungsbereichen vorzunehmen, die auf dem Computer zentral

    nur einmal abgelegt sein drfen (bspl. zentrale Datenbankdatei, die in einer

    Mehrbenutzerumgebung von verschiedenen Benutzern gepflegt wrde).

    3. Eine ACL-Lockerung ist unaufgefordert fr alle Ressourcen aus oben beschriebenen

    Verzeichnissen/Registrierungsbereichen vorzunehmen, die zum Installationsumfang

    gehren und die durch den Softwarepaketierer als betriebsbeeinflussende und

    vernderliche Konfigurationsdateien interpretiert werden knnen (bspl. INI-

    Dateien), unabhngig davon, ob die Datei bei einem Schnelltest der Software

    durch den Softwarepaketierer virtualisiert wird oder nicht.

    6.8 Custom Actions in MSI-Dateien

    Natrlich funktionieren alle Standardimplementationen von Custom Actions in MSI-Dateien (vb-Script, DLL-Funktion, etc.) auch im Prozessablauf mit dem Package-Launcher. Dennoch ist mit dem Einsatz des Package-Launchers bei Eigenimplementationen ein anderes Verfahren vorgesehen, um die Nachvollziehbarkeit durch andere Personen besser zu gewhrleisten (bspl. QS, Paketierer eines Folgeauftrages), allgemein die Transparenz zu verbessern und eine wirtschaftliche und rationelle Umsetzung sicherzustellen: Alle Erweiterungen sollten durch den Paketierer in Form einer Wise Script Custom Action auf Grundlage der im Work-Ordner vorbereiteten und von CreatePackage.EXE abgelegten Vorlage PostInstall_00x.wse erstellt werden! Auch hier ist nach dem Kopieren der Datei vom Work-Ordner in den Ordner des Revisionsverzeichnisses der Namen der Datei mit dem Revisionsbezeichner anzupassen:

    Die kompilierte PostInstall.EXE-Datei wird nach Ausfhrung oder Wiederausfhrung von AddProperties.vbs in die MST-Datei/en zur Ausfhrung als Deferred Custom Action automatisch eingebettet. Wie der Name schon sagt, handelt es sich um Implementationen, die nach der Installation der Ressourcen aus der MSI-Datei zur Ausfhrung gelangen. Bei einem durch den

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 76/122

    Softwarepaketierer vorgesehenen Fehlerabbruch erfolgt automatisch ein Rollback der MSI-Installation.

    Sollen Bedrfnisse vor einer MSI-Installation abgebildet werden, so verwendet der Softwarepaketierer ein PreInstall_00x.wse, welches nach dem oben beschriebenen Verfahren ins Revisionsverzeichnis kopiert wird.

    6.8.1 Anpassungen in Pre- und PostInstall

    Alle Anpassungen sind durch den Softwarepaketierer im ersten Register (PostInstall_00x) zwischen Beginn und Ende der Customizing Section im entsprechenden Abschnitt fr INSTALL, REPAIR, und REMOVE einzufgen. Alle anderen Register drfen nicht verndert werden!

    Im Register VorlagenScript befinden sich Snipplets fr hufige Aufgaben, die genau mit dieser Ausprgung ins erste Register bernommen werden knnen. Zum Teil sind dann nur noch kleine Anpassungen vornehmen. Der Abbruch-Handler, der ein Rollback auslsen und eine Fehlermeldung in die Datei History.LOG schreiben soll, ist also durch den Softwarepaketierer genau so zu implementieren wie im VorlagenScript ausgewiesen und unten dargestellt:

    Der Aufbau der PreInstall_00x.wse und der PostInstall_00x.wse ist praktisch identisch, der Kontext der Installationsausfhrung aber ein anderer. PreInstall wird vom Package-Launcher selbst in erster Instanz vor der MSI-Installation ausgefhrt, PostInstall kommt hingegen im Rahmen der Windows Installer Installation in Form einer Custom Action zum Einsatz.

    Hier ist das Fenster/Register abgebildet, wo der Softwarepaketierer die fr die Installation erforderlichen zustzlichen Bedrfnisse abbildet:

    Weitere Hinweise finden Sie im Kapitel 3.8 Verwendung von PreInstall_00x.wse, PostInstall_00x.wse.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 77/122

    6.8.2 Isolierte Ausfhrung von Pre-/PostInstall ausserhalb einer Paketinstallation

    Zu Testzwecken kann das Pre/PostInstall_00x.EXE auch ausserhalb der Softwarepaketinstallation zur Ausfhrung gebracht werden. Folgende Kommandozeile ist hier zu verwenden:

    Pre/PostInstall_00x.EXE

    Achtung: Dieses Vorgehen ersetzt nicht den Test des Installationsablaufs des kompletten Softwarepakets! Zu beachten ist auch, dass durch dieses Verfahren keine History.LOG-Eintrge generiert werden.

    6.9 PreInstall-Pakete

    Softwarepakete ohne MSI-Ressourcen knnen mit dem Package-Launcher mittels einer PreInstall-Datei abgebildet werden. Beachten Sie, dass auf die Ausfhrung einer PreInstall-Datei keine PostInstall-Datei folgen muss, bzw. dies im Rahmen eines PreInstall-Paketes ohne Ausfhrung einer MSI-Datei gar nicht zulssig wre.

    6.9.1 Umgang mit Legacy-Setups, die nicht repaketiert werden

    Legacy-Setups werden ber ein PreInstall-Paket initiiert. Das zu verwendende Setup.EXE muss im Revisionsverzeichnis abgelegt werden und in der INI-Datei des Softwarepakets ist der Bezeichner CopyLocal auf True zu stellen.

    Zur Umsetzung der Anforderungen ist das Vorlagen-Snipplet aus dem Register VorlagenScriptB in die bentigte Sektion aus dem ersten Register zu kopieren und die Variablen SETUP und LE-GACY_CMDLINE entsprechend abzufllen. Bei Bedarf kann nach der Ausfhrung der Setup.EXE direkt nach Execute %SETUP% %LEGACY_CMDLINE% mittels Verwendung der Variablen PROCEXITCODE der Rckgabewert abgefragt und gegebenenfalls ein Abbruch initiiert werden.

    Im PreInstall_00x.WSE sind keine Vorkehrungen betreffend dem Kopieren oder Lschen der Sourcedaten (Setup.EXE) vorzusehen, da dies bei der geschilderten Umsetzung der Package-Launcher selbstndig erledigt.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 78/122

    6.10 Active Setup in Pre- & PostInstall

    Die Einrichtung eines Active-Setup-Befehls kann sehr einfach mittels einer Pre- und PostInstall-Implementation erfolgen. Wir unterscheiden hierbei drei verschiedene Mglichkeiten:

    1. Active Setup zielend auf die in dieser Revision zugrundeliegenden MSI-Datei.

    2. Active Setup auf PreInstall initiiert im PreInstall_00x.wse

    3. Active Setup auf PostInstall initiiert im PostInstall_00x.wse

    Es ist unerheblich, in welcher Section die Implementation vorgenommen wird (egal, ob in erster INSTALL-Sektion oder in INSTALL OR REPAIR-Sektion). Es knnen auch alle drei Varianten (Active Setup zielend auf MSI/PreInstall/PostInstall) gleichzeitig eingesetzt werden.

    6.11 Active Setup, zielend auf eine MSI-Datei

    Das Implementationsvorgehen fr den Paketierer kann in einem Schritt vollzogen werden. Hierzu ist nur das Remark-Zeichen vor dem Include-Script (ActiveSetup-MSI.wse) zu entfernen.

    REPAIR-Beschrnkung auf ein einzelnes Feature

    Ohne weiteres Zutun wird eine Reparatur des Produktes ber msiexec /fub %PRODUCTCODE% implementiert. In gewissen Fllen kann es aber Sinn machen, dass man die Reparatur auf ein

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 79/122

    Feature begrenzt. In solchen Fllen (und nur dann) ist der Block um folgenden Eintrag zu erweitern. Hier ist der Property ADDLOCAL das gewnschte Feature anzufgen:

    6.12 Active Setup, zielend auf ein Pre/PostInstall

    Die Verwendung eines Pre/postInstalls in Form eines Active Setups ist oft schneller bewerkstelligt, als die Integration ber die MSI/MST-Datei. Zudem ist oft die Ausfhrung im Benutzerkontext viel schlanker und schneller erledigt, was die Benutzerakzeptanz erhhen sollte

    Das Vorgehen ist in wenigen Schritten vollzogen. Durch Abwhlen des Remark-Zeichens

    wird die Implementation ausgefhrt. Danach sind aber noch die Anweisungen anzufgen, die der Paketierer whrend der Ausfhrung der Active Setup-Implementation im Benutzerkontext wnscht. Hierzu ist der Block USERREPAIR entsprechend zu erweitern. Die Implementation selbst fhrt zu folgendem Active Setup-Eintrag:

    "%SCRIPTS%\PostInstall_%REVISION%.EXE" %PACKAGE% %REVISION% USERREPAIR %VARIANT% %VARIANTSECTION%

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 80/122

    Beispiel einer USERREPAIR-Implementation

    In diesem Beispiel sollen CurrentUser-Registrykeys erweitert und Dateien aus dem lokalen Profil fr alle Benutzer kopiert werden.

    1. Die HKCU-Registrykeys werden mit Edit Registry in den Block USERREPAIR eingefgt.

    2. Beim ffnen des Dialogs knnen bestehende vorbereitete HKCU-Registrykeys importiert werden:

    3. Zielverzeichnis fr zu kopierende Benutzerdateien bestimmen

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 81/122

    4. Dateien ins %APPDATA%-Verzeichnis kopieren

    5. Aussehen des Registers PostInstall_00x nach Manipulation durch den Softwarepaketierer:

    Achtung: Wenn ein Pre/Postinstall mit Benutzerressourcen verwendet werden soll, drfen in der Sektion USERREPAIR keine Aktionen implementiert werden, die administrative Rechte bentigen!

    Das gleiche wie das soeben beschriebene Vorgehen ist anzuwenden, wenn ein Active Setup, zielend auf ein PreInstall impementiert werden soll. Hier sind die Manipulationen in der Datei PreInstall_00x.wse anzufgen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 82/122

    6.13 Umgang mit Patchdateien

    Ein erstes Kapitel ber die Integration von Patchdateien in einer initialen Revision war bereits einmal Thema in diesem Dokument (siehe Kapitel 6.3.4 In-Place-Update von Patches (Splipstreaming)). Mssen weitere Patches integriert werden, nachdem ein Softwarepaket in die Produktion berfhrt wurde, kann dies mittels einem Revisionsupdate erfolgen. Hier sind die MSP-Patchdateien einfach in das Revisionsverzeichnis zu kopieren. Es knnen dabei mehrere Patchdateien in das selbe Revisionsverzeichnis eingefgt werden.

    Weitere Aktionen sind nicht erforderlich. Beachten Sie auch die Einschrnkungen, die im Betriebshandbuch Setup-Launcher im Kapitel 3.13 Anwenden von Patches und Transformationen dokumentiert sind.

    6.14 INI-Datei des Softwarepakets

    In der INI-Datei des Softwarepakets werden Einstellungen definiert, die fr die Installation des Softwarepakets relevant sind. Die INI-Datei wird im Wurzelverzeichnis des Softwarepakets abgebildet und trgt den Namen des Softwarepakets. Bspl. Byron-HIP-1.0.INI.

    Das Kapitel 3.5 INI-Datei widmet sich mit der Ausgestaltung dieser INI-Datei. An dieser Stelle wollen wir nur kurz auf einige wenige Bezeichner eingehen.

    6.14.1 Upgrade-Handling

    ber den Bezeichner Upgrade=xxxx bestimmt der Softwarepaketierer, welche Softwarepakete der Package-Launcher in Form eines Package-Upgrades vor einer Installation entfernen soll. Dies ist die favorisierte Variante, Softwareprodukte im Rahmen eines Upgrades zu entfernen. Standardmssig erstellt CreatePackage.EXE einen Paketbezeichner ohne Version, so dass die Deinstallation aller Softwarepakete aus der gleichen Produktfamilie im Rahmen eines Package-Upgrades erfolgt.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 83/122

    6.14.1.1 Eindeutiger Upgradebezeichner

    Ist der Name eines Softwarepakets im Namen eines anderen Softwarepakets enthalten, beispielsweise Adobe-IllustratorCS4 in Adobe-IllustratorCS4LanguagePack, so ist in der INI-Datei des krzeren (Paketname) Softwarepakets beim Upgradebezeichner ein Bindestrich anzufgen -, wenn dieses Softwarepaket nur Vorversionen seiner eigenen Produktefamile entfernen soll.

    6.14.2 Lokaler Cache

    ber eine Einstellung in der INI-Datei lsst sich vorgeben, den Package-Launcher anzuweisen, das Softwarepaket vor der Installation lokal zwischenzuspeichern (CopyLocal=True). Dies ist insbesondere fr Softwarepakete notwendig, die Dateien oder andere Ressourcen whrend einer Benutzerreparatur bentigen (siehe Kapitel 6.5 Umgang mit Benutzerressourcen). Auch bei Legacy-Setups, deren Ausfhrung ber ein PreInstall-Paket mittels der Standardvorlage vorgesehen ist, ist eine lokale Zwischenspeicherung erforderlich (siehe Kapitel 6.9.1 Umgang mit Legacy-Setups, die nicht repaketiert werden)

    Der lokale Cache wird bei einer kompletten Deinstallation des Softwarepakets mit all seinen Revisionen durch den Package-Launcher wieder gelscht. Zu beachten ist zudem, dass nur das komplette Softwarepaket (mit all seinen Revisionen) zwischengespeichert werden kann.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 84/122

    Das Cache-Verzeichnis befindet sich auf %WINDIR%\Package-Launcher\Cache:

    In PreInstall_00x.wse und in allen Scriptausprgungen steht fr den Zugriff auf dieses Verzeichnis eine Variable mit dem Namen CACHE zur Verfgung.

    Der Bezeichner zur Anweisung der Zwischenspeicherung in der INI-Datei heisst CopyLocal und ist beim Caching auf True zu setzen:

    6.14.3 Umgang mit Abhngigkeiten durch Verwendung des Dependence-Eintrages

    Mit dem Dependence-Eintrag berprft der Package-Launcher den Computer vor der Basisinstallation auf installierte Abhngigkeiten. Der Dependence-Eintrag ist dabei mit den Paketnamen zu ergnzen, welche als Abhngigkeit dieser Applikation fungieren. Der Paketname kann auch nur ein Teilstring der Applikation enthalten. In der Regel verwendet man den Namen der Paketfamilie, also Hersteller-Name, ohne Versionsangabe, damit die Prfung nicht auf die Version fixiert und auch spter gltig ist.

    Die verschiedenen Abhngigkeiten sind hier mit einem Leerzeichen aneinanderzufgen. Die Abhngigkeiten knnen mit dem OR Operator verknpft werden (siehe Kapitel 3.5 INI-Datei). Wenn der OR-Operator verwendet wird, muss der linke und rechte Bezeichner mit einer Klammer einfasst werden. Bspl. (Adobe-Reader OR Adobe-Acrobat)

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 85/122

    Der Dependence-Eintrag wird auch von SCCMCreateApp whrend der automatischen Erstellung der SCCM-Objekte ausgelesen. Durch diesen Bezeichner werden alle erforderlichen Paketabhngigkeiten in der (RTM)-Application platziert.

    Merke

    Verwenden Sie mit SCCM 2012 keine Abhngigkeiten in einer flachen Hierarchie! Wird beispielsweise fr eine Software C eine Software B bentigt und fr den einwandfreien Betrieb der Middleware B wre A erforderlich, so wre die Deklaration Dependence=A B C in der Software C das falsche Vorgehen! Verwenden Sie stattdessen hierarchische Abhngigkeiten im Dependence-Eintrag!

    Software C: Dependence=B Software B: Dependence=A

    Der Grund hierfr liegt in der Tatsache, dass mit SCCM 2012 und dem Application model nur so eine korrekte Reihenfolge gesteuert werden kann. Wrden die Abhngigkeiten in einer flachen Hierarchie angewendet, wre die Reihenfolge nicht vorhersehbar.

    Korrekte Dependence-Umsetzung:

    6.14.4 Die Verwendung des TaskSequence-Eintrages

    Als Ergnzung zum Dependence-Eintrag steht optional der TaskSequence-Eintrag zur Verfgung. Dieser Bezeichner ermglicht insbesondere bei hierarchischen Abhngigkeiten (siehe oben), diese auch fr die Installation mit dem Remote Package Installer (RPI) vorzubereiten. Der RPI verlangt im Gegensatz zu SCCM 2012 eine flache Hierarchie der Abhngigkeitsimplementation. Dort mssen Sie also Abhngigkeiten zustzlich chronologisch aneinandergereiht ber den TaskSequence-Eintrag einfgen.

    Des Weiteren werden auch automatisch erstellte optionale Customized Task Sequences bevorzugt ber diesen Bezeichner realisiert (wenn vorhanden).

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 86/122

    6.14.4.1 Bercksichtigung von Nicht-Package-Launcher-konformen Paketen

    Fr die Verwaltung Nicht-Package-Launcher-konformer Pakete sind im Zusammenhang mit der INI-Datei vier verschiedene Bezeichner von Wichtigkeit. Dies sind Dependence, Upgrade, RemoveIncompatibleMsi und RemoveIncompatibleMsiUPG. Auf die Implementation der nachfolgenden Ausfhrungen knnen Sie verzichten, wenn in Ihrer produktiven Umgebung nur Package-Launcher-konforme Softwarepakete eingesetzt werden.

    Dependence

    Beim Erweitern des Dependence-Bezeichners kann dieser auch mit den Paketen erweitert werden, die als Nicht-Package-Launcher-konforme Paketausprgung vorliegen und die installiert sein knnten. Und zwar nach der Form Dependence=(neu OR incompatible) (neu2 OR incompatible2)

    Fr Nicht-Package-Launcher-konforme Paketausprgungen sind nur Eintrge mit {ProductCodes} zu verwenden. Anbei sehen Sie ein Beispiel:

    Achtung

    Die automatische SCCM-Objekterstellung beim berfhren der Pakete in SCCM untersttzt keine Nicht-Package-Launcher-konformen Softwarepakete! Dies bedeutet, dass alle Eintrge in der Form von {ProductCodes} beim berfhrungsprozess ausgefiltert werden und in der Abhngigkeitsimplementation unbercksichtigt bleiben.

    Upgrade

    Sind mit einem Upgrade auch produktive, Nicht-Package-Launcher-konforme Softwarepakete zu aktualisieren, so ist nach einem hnlichen Muster vorzugehen. Hier erweitert der Softwarepaketierer den Upgradebezeichner mit allflligen {ProductCodes} der entsprechenden produktiven Versionen:

    RemoveIncompatibleMsi

    RemoveIncompatibleMsi sollte immer gesetzt werden, wenn es das gleiche Softwarepaket auch in einer nicht Package-Launcher-kompatiblen Version gibt. Dieser Bezeichner sorgt in diesem Fall dafr, dass die Verteilung des neuen Pakets auf Grundlage des Package-Launchers auf einem

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 87/122

    Client, wo noch eine inkompatible Version installiert ist, vorgngig die inkompatible Version entfernt. Der Bezeichner ist auf RemoveIncompatibleMsi=True zu stellen:

    RemoveIncompatibleMsiUPG

    Mit dem Bezeichner RemoveIncompatibleMsiUPG kann man per Windows Installer installierte Produkte automatisch im Rahmen eines Package-Upgrades deinstallieren lassen, wenn diese den selben UpgradeCode im Paket verwenden. Gerade in Umgebungen, wo mehrere Paketarten (Package-Launcher Paket und andere Formen der gleichen Pakete) zum Einsatz kommen knnten, empfiehlt sich dieser Bezeichner.

    6.15 AddProperties

    AddProperties.vbs ist ein Script, welches bei MSI-Ressourcen alle fr das Unternehmen erforderlichen Windows Installer Propertyanpassungen vornimmt und Erweiterungen in den anderen Windows Installer Datenbanktabellen anfgt, die fr den robusten Betrieb mit dem Package-Launcher notwendig sind. Das Script kann mehrfach per Doppelklick (befindet sich im Stammverzeichnis des Softwarepakets) ausgefhrt werden. Die Anpassungen werden dann automatisch in eine MST-Datei geschrieben. Handelt es sich um ein repaketiertes Softwarepaket, so erscheint ein Benutzerdialog, wo der Softwarepaketierer die Erweiterung auch gleich in die MSI-Datei bernehmen knnte. Aus Grnden der Transparenz ist auch hier die Wahl einer MST-Datei empfohlen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 88/122

    Merke

    Verwenden Sie in Ihrer Zielrevision keine MSI-Datei, sondern nur andere Ressourcen, dann knnen Sie auf die Ausfhrung von AddProperties_Link.vbs verzichten.

    6.15.1 Propertyanpassungen und zustzliche Erweiterungen

    Folgende Werte werden durch AddProperties.vbs standardmssig verndert und sind in jedem MSI/MST erforderlich:

    Property Inhalt Beispiel Kurzbeschreibung

    ALLUSERS 1 Per-machine Installation erzwingen

    ROOTDRIVE C:\ Systemlaufwerk. Kann Probleme geben, wenn nicht angegeben

    ARPNOREPAIR 1 Reparatur in Add/Remove fr Benutzer abschalten

    ARPNOREMOVE 1 Remove in Add/Remove fr Benutzer abschalten

    ARPNOMODIFY 1 Maintenance in Add/Remove fr Benutzer abschalten

    REBOOT ReallySuppress Computerneustart verhindern

    PLPackageEngineer Dominik Oberlin Informations-Property

    PLPackage Adobe-Reader-9.3 Paketnamen, erforderlich fr Package-Launcher

    PLRevision 001 Revision, erforderlich fr Package-Launcher

    (ARPSYSTEMCOMPONENT) 1 Optional, bei allen Revisionen > 001, damit diese zustzliche Revision nicht in Add/Remove erscheint

    Error

    0 {{Fatal error: }} Erforderlich fr Launcher Log-Einlesen

    1 {{Error [1]. }} Erforderlich fr Launcher Log-Einlesen

    1708 Installation operation failed. Erforderlich fr Launcher Log-Einlesen

    CustomAction

    CA_CleanUpByRemove 70|PL_Binary|CleanUp Erforderlich fr Package-Launcher Upgrade

    InstallExecuteSequence

    RemoveExistingProducts NEVER Windows Installer Upgrade verhindern

    CA_CleanUpByRemove UPGRADINGPRODUCTCODE Erforderlich fr Package-Launcher Upgrade

    Binary

    PL_Binary [Binary Data] Vb-Script Custom Action fr Upgrade

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 89/122

    Zustzlich zu diesen Angaben bettet AddProperties.vbs ein allfllig vorliegendes PostInstall_00x.EXE als externe Custom Action ein und implementiert falls ntig, wenn ber die INI-Datei des Softwarepaketes angegeben, einen Windows Installer Major-Upgrade der auf die Vorversionen zielt (nicht empfohlen).

    Standardmssig bt AddProperties.vbs die Anpassungen auf die letzte Revision aus. Wenn mehrere Architektur-Sprachfolder zum Einsatz kommen, werden alle letzten Revisionen fokussiert (aus allen Sprach- und Plattformverzeichnissen). Das heisst, dass dann auch mehrere Abschlussmeldungen angezeigt werden. Sollte man AddProperties.vbs auf eine andere Revision, als die letzte anwenden wollen, so kann die MSI-Datei aus der entsprechenden Revision als Kommandozeilenparameter bergeben werden. Zustzlich kann optional als zweite Kommandozeilenoption auch noch die Transformation selektiert werden, auf die die Erweiterungsabsichten zielen.

    Aus dem folgenden Bild sind die Kommandozeilenoptionen ersichtlich. Auf den vollstndigen Pfadnamen wurde hier aufgrund der Darstellungsmglichkeit verzichtet.

    6.15.2 Vereinfachte Ausfhrung

    Prinzipiell ist fr jede integrierte Revision AddProperties_Link.vbs auszufhren. Existiert nur eine Revision 001 oder zielen die Anpassungsabsichten auf die letzte Revision, so reicht ein Doppel-klick auf das Script:

    Bei mehreren neu eingesetzten Revisionen kann alternativ zu dem auf der letzten Seite beschrie-benen Verfahren auch nur die Revision als Kommandozeilenoption angefgt werden. Fr jede Revision ist so vorzugehen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 90/122

    Achtung

    Werden Anweisungen in der PostInstall_00x.wse vorgenommen, um diese im Nachgang der MSI-Installation vorzusehen, dann ist zwingend nach der Kompilierung der Datei PostInstall_00x.wse das Script AddProperties_Link.vbs neu auszufhren. Gleich verfahren Sie, wenn Sie ein PostInstall_00x.exe aus dem Revisionsverzeichnis lschen, welches Sie frher integriert haben. Durch den erneuten Aufruf entfernen Sie in der MST-Datei die Custom-Action-Implementation.

    6.16 SCCMCreateApp automatisches berfhren in SCCM 2012

    Nach Abschluss der Paketierungsaufgaben wird mit dem Script SCCMCreateApp_Link.vbs (befindet sich im Stammverzeichnis des Softwarepakets) ein Softwarepaket als Application in das Softwareverteilungswerkzeug SCCM 2012 berfhrt. Hauptziel von SCCMCreateApp ist es, die notwendigen Aufgaben rationeller und einheitlicher zu erledigen, als wenn diese durch den Softwarepaketierer in manuellen Transaktionen erzeugt werden mssten.

    Das Script SCCMCreateApp_Link.vbs befindet sich im Stammverzeichnis jedes Softwarepakets:

    .

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 91/122

    6.16.1 Umfang der Objekte

    SCCMCreateApp erstellt folgende Standard-Objekte:

    1. Application: Grundstzlich werden bei der Erstberfhrung von Standardpaketen (alle ausser AppV Full Integration) 3 verschiedene Applications gebaut: Eine (RTM)-Application, die alle Paketressourcen zu diesem Zeitpunkt enthlt. Weiter werden zwei logische (Full)-Applications erstellt. Diese werden fr die Zuweisung bentigt.

    Im Rahmen eines Revisionsupdates werden inbesondere bei der produktiven befhrung noch Revisionsapplications gebaut, wo isolierte Revisionen integriert sind.

    2. DeploymentType: Im DeploymentType wird eine konforme und einheitliche DetectionMethod integriert und die Abhngigkeiten aus dem Dependence-Eintrag der INI-Datei implementiert.

    3. Deployment: Eines fr eine komplette versionierte Installation (Full), eines fr eine unversionierte (Full)-Zuweisung und nur in PRD eines fr die Deinstallation (Full).

    4. Collection: Eine fr eine komplette versionierte Installation (Full Install), eine fr eine unversionierte (Full Install)-Zuweisung und nur in PRD eine fr die Deinstallation (Full Uninstall).

    Wenn sich in der Datei SCCMCreateApp.INI im Bezeichner PLPackDEV= kein Eintrag befindet, werden die Objekte fr Revisionsupdates nur in der PRD-Umgebung erstellt.

    6.16.2 Die verschiedenen Environments

    Damit in einer produktiven Umgebung nach dem berfhren und Verteilen eines Softwarepakets in Form von Applications auch nderungen und Updateerweiterungen an diesem Paket mglich sind, ohne dass diese Arbeiten inkl. deren Tests die produktive Ausprgung der Applications stren, sind verschiedene Environments vorgesehen.

    Im Allgemeinen sind im Ablauf folgende Schritte zu vollziehen:

    1. Der Softwarepaketierer erstellt, ndert oder updatet sein Paket auf dem Development-Share PLPackDEV

    2. Der Softwarepaketierer berfhrt sein fertiges Paket mittels SCCMCreateApp_Link.vbs im Environment DEV

    3. Die Software wird ber die SCCM-Objekte in DEV getestet.

    4. Eventuell ergeben sich Korrekturen und die Schritte 1-3 werden wiederholt

    5. Ist die Abnahme erfolgreich, erstellt der berfhrungsoperator zum Verteilungszeitpunkt die SCCM-Objekte mittels SCCMCreateApp_Link.vbs im Environment PRD

    6. Der berfhrungsoperator weist bei einer RTM-Integration (Erstberfhrung) die Software den Benutzern zu

    7. Die Applications werden automatisch installiert

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 92/122

    6.16.3 Vorbereitungen zur Bedienung von SCCMCreateApp

    Wie in diesem Hauptkapitel skizziert, wird die berfhrung durch das Script SCCMCreateApp_Link.vbs aus dem Stammverzeichnis des Softwarepakets, eingeleitet.

    Bei der ersten Ausfhrung der Software kann folgende Fehlermeldung einmalig erscheinen:

    Danach sind im Fenster zuerst die SCCM-Site, danach das Environment auszuwhlen:

    Fr die nchste Ausfhrung werden diese Schritte durch SCCMCreateApp automatisch gespeichert.

    6.16.4 berfhrung in DEV und PRD

    Doppelklicken Sie im Stammverzeichnis des Softwarepakets auf SCCMCreateApp_Link.vbs, whlen Sie das Environment und klicken dann auf Create Applications

    Innert weniger Sekunden werden alle erforderlichen SCCM Objekte auf der Infrastruktur erstellt.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 93/122

    Dabei werden die Objekte in SCCM standardmssig in separaten Environment-Folders gespeichert. Auch in den Namen der Objekten finden wir das Environment wieder.

    6.16.5 Abhngigkeiten

    Abhngigkeiten sind unter Bercksichtigung der Hierarchien einzupflegen (siehe Merke im Kapitel 6.14.3 Umgang mit Abhngigkeiten durch Verwendung des Dependence-Eintrages)!

    SCCMCreateApp integriert grundstzlich alle in der Paket-INI-Datei implementierten Abhngigkeiten (Bezeichner Dependence) im DeploymentType der (RTM)-Application, ausser Eintrge in der Form von {ProductCodes}. Es ist daher erforderlich, dass solche Abhngigkeiten vorgngig auf der Infrastruktur integriert wurden.

    Sollte folgende Fehlermeldung erscheinen

    ist dies darauf zurckzufhren, dass die notwendigen Abhngigkeiten noch nicht berfhrt wurden. Brechen Sie den Dialog ab und integrieren zuerst die Abhngigkeiten. Danach knnen Sie abermals das Zielpaket berfhren. Jetzt sollte die Fehlermeldung nicht mehr erscheinen.

    Verwenden Sie in der INI-Datei Abhngigkeiten mit dem OR-Operator, werden diese ent-sprechend der Anweisung und Reihenfolgsprfung im Deployment Type der Application integriert.

    Ausprgung INI-Datei:

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 94/122

    Ansicht Dependence im Deployment Type der Application nach der berfhrung des obigen Paketes:

    6.16.6 Refresh von Applications

    Wird SCCMCreateApp fr ein Paket ein zweites Mal ausgefhrt, so erscheint ein Dialog der folgendet Art:

    Hier haben Sie die Mglichkeit, anzugeben, was genau aktualisiert werden soll. Da SCCMCreateApp nicht weiss, was Sie zwischen der letzten berfhrung und der jetzt beabsichtigten Integration fr nderungen angebracht haben, ist dieser Dialog zur korrekten Umsetzung Ihrer Absichten erforderlich.

    Haben Sie Inhalte oder Ressourcen in bestehenden Revisionsverzeichnissen gendert, die zum Umfang der Erstberfhrung gehrten, so ist die Option Aktualisiere initiale (RTM) Application zu markieren.

    Gab es nderungen in der Anzahl an Revisionen oder vernderten Sie Deploymenteinstellungen (siehe nchstes Kapitel), so ist die Option Aktualisieren alle (Full) Applications zu markieren. Bei Refreshoperationen von Revisionsupdates haben Sie zudem die Mglichkeit anzugeben, ob die Aktualisierung nur die letzte Revision betrifft oder ob Sie auch auf alte Revisionen (KeepRevision) angewendet werden soll (Aktualisiere alle (00x) Revisionsapplications). In der Regel sind die standarmssig markierten Optionen richtig.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 95/122

    Optionen der Aktualisierung von Revisionen:

    6.16.7 Update Content

    Wenn Sie seit der letzten berfhrung keine nderungen in der Anzahl an Revisionen, im Deployment (siehe nchstes Kapitel) und in Abhngigkeiten aus der INI-Datei (Dependence) vor-genommen haben und eine Aktualisierung des Pakets mit SCCMCreateApp vorgenommen wird, so whlen Sie beim angezeigten Dialog Aktualisiere nur Content und schliessen Ihre Einga-be mit OK ab.

    Dies entspricht der Funktion Update Content auf dem Deployment Type der Application.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 96/122

    6.16.8 Deploymenteinstellungen

    Sollen fr einen Einzelfall die Einstellungen des Deployments gendert werden, kann durch die Markierung der Option Erweiterte Einstellungen auf einige untersttzte Eigenschaften zurckgegriffen werden:

    Befinden sich App-V-5 Ressourcen im Revisionsverzeichnis 001, kann mittels der Option AppV Full Integration eine Integration mit Streaming ermglicht werden. Markiert der berfhrungsoperator diese Option nicht, wird das Paket ber das standalone model wie bliche Applications integriert.

    Sollen Deploymenteinstellungen dauerhaft fr alle knftigen berfhrungen gendert werden, so sind diese ber Eigenschaften in der Datei SCCMCreateApp.INI (mit Vorsicht) vorzunehmen.

    6.16.9 Schematische Darstellung der erstellten Objekte

    Ein Standard-Applicationprodukt setzt sich initial aus einer Application Manufacturer-Name-Version (RTM) mit dem Content aller Revisionen zum Zeitpunkt der initialen Erstellung, einer Manufacturer-Name-Version (Full) und einer unversionierten (Full)-Application zuammen. Im Deployment Type der Full-Applications wird ein symbolischer Content verwendet, der fr eine erfolgreiche Integration von Applications in Task-Sequenzen erforderlich ist.

    Die versionierte (Full)-Application verweist im Deployment Type initial als Abhngigkeit auf die (RTM)-Application. Die unversionierte (Full)-Application hat eine Abhngigkeit auf die versionierte (Full)-Application. Produktabhngigkeiten werden durch SCCMCreateApp im Deployment Type der (RTM)-Application eingebaut.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 97/122

    Revisionsupdate

    Bei einem Revisionsupdate wird fr das Update eine neue Application Manufacturer-Name-Version (00x) erstellt.

    Ansicht der neuen Updateapplications:

    Zustzlich wird die Detection Method im Deployment Type der (Full)-Application auf den Wert der aktuellen Revision angepasst und dort die bestehende Abhngkeit auf Manufacturer-Name-Version (RTM) gelscht, bzw. durch Manufacturer-Name-Version (003) ersetzt.

    Schematische Darstellung der Updates mit Abhngigkeitsverweisen:

    Der Vorteil dieser verketteten Integration ist, dass so eine Reihenfolge in der Abhngigkeitsinstallation vorgegeben werden kann. SCCM 2012 ermglicht standardmssig keine Steuerung der Reihenfolge von Abhngigkeiten in der selben Hierarchie!

    6.16.10 Lschen von Applications

    Mchten Sie Package-Launcher Produkte in der Infrastruktur lschen, gehen Sie wiefolgt vor:

    1. Lschen Sie alle Collections des zu Lschen vorgesehenen Produktes im Environment. Auch die unter _EXCLUDES. Sie knnen dort alle Collections gleichzeitig markieren und in einem Schritt lschen. Die Lschoperation lscht gleichzeitig auch alle Deployments.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 98/122

    2. Lschen Sie die Applications nacheinander in der hier abgebildeten Reihenfolge:

    a. unversionierte (Full)-Application

    b. versionierte (Full)-Application

    c. wenn vorhanden, Revisionen chronologisch absteigend

    d. (RTM)-Application

    3. Lschen Sie den Ordner des Pakets auf dem Zielenvironment, inkl. der darin befindlichen PRD-Status.INI.

    6.16.11 SCCMCreateApp.INI

    In der Datei SCCMCreateApp.INI sind in der Regel keine nderungen vorzunehmen. Zudem sollten nderungen nur wohlberlegt und mit grosser Vorsicht durchgefhrt werden.

    Einige Bezeichner:

    Key AskForEnvironment

    Einsatz Erforderlich: Text;Text

    Beschreibung Mittels dieses Bezeichners knnen die Namen der Development- und der produktiven Umgebung vorgegeben werden. Standardmssig und empfohlen sind die Namen wie im Beispiel unten.

    Beispiel AskForEnvironment=DEV;PRD

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 99/122

    Key Scope

    Einsatz Erforderlich: Verbindung

    Beschreibung Dies sind die Verbindungseigenschaften fr den Configuration Manager

    Beispiel Scope=\\G0RSRW-SCCMPS01.source.local\root\Sms\Site_P01

    Key Site

    Einsatz Erforderlich: Name der Site

    Beschreibung Verbindungsoption Site. Erforderlich fr die korrekte Applicationerstellung

    Beispiel Site=P01

    Key TopLevelFolderCol

    Einsatz Optional: Foldername

    Beschreibung Der Name des Top Level Folders in der Collectionstruktur, worin die Collections erstellt werden sollen.

    Beispiel TopLevelFolderCol=Software

    Key TopLevelFolderApp

    Einsatz Optional: Foldername

    Beschreibung Der Name des Top Level Folders in der Applicationstruktur, worin die Applications erstellt werden sollen.

    Beispiel TopLevelFolderApp=Application

    Key ExcludeDistributionPoint

    Einsatz Optional: Name;Name

    Beschreibung Namen der Distributionpoints, die beim berfhren ausgeschlossen werden sollen.

    Beispiel ExcludeDistributionPoint=SB032010;SB022010

    Key DEVPRDFolder

    Einsatz Erforderlich: TrueFalse

    Beschreibung Sollen die Environmentsnamen als Folder in Collections und Applications eingesetzt werden, so ist dieser Bezeichner auf True zu stellen. Default=True

    Beispiel DEVPRDFolder=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 100/122

    Key ManufacturerFolder

    Einsatz Optional: TrueFalse

    Beschreibung Sollen pro Hersteller separate Folders in Collections und Applications erstellt werden, ist dieser Bezeichner auf True zu stellen. Default=False.

    Beispiel ManufacturerFolder=False

    Key UseColSubFolder

    Einsatz Optional: Pattern;Pattern;Pattern

    Beschreibung Sollen gewisse Collections, die nicht oft gebraucht werden, in einen Subfolder verschoben werden, kann dies mit diesem Bezeichner bewerkstelligt werden.

    Es werden folgende Variablen untersttzt:

    [Versioned] Dies entspricht der versionierten Collection [Unversioned] Dies entspricht der unversionierten Collection [Rev] Dies entspricht einer Revisionscollection

    Beispiel UseColSubFolder=(RTM);[Versioned];[Rev]

    Key ExpliciteDontUseSubFolder

    Einsatz Optional: Pattern;Pattern;Pattern

    Beschreibung Die Regel UseColSubFolder kann fr einzelne Namen verhindert werden.

    Beispiel ExpliciteDontUseSubFolder=(APPV)

    Key UseColSubFolderName

    Einsatz Optional: Name

    Beschreibung Namen des Exclude Subfolders in Collections.

    Beispiel UseColSubFolderName=_EXCLUDES

    Key Usercollections

    Einsatz Optional: TrueFalse

    Beschreibung Sollen auf der selektierten Infrastruktur User- oder Devicecollections erstellt werden?

    Dieser Bezeichner kann auch mit vorangestelltem Environmentbezeichner verwendet werden, um auf einer Developmentumgebung andere Deploymenteigenschaften zu verwenden, als auf einer produktiven Umgebung. Bspl DEV_Usercollections=False

    Beispiel Usercollections=False

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 101/122

    Key DeploymentDefaultScheduleDay=10

    Einsatz Optional: Anzahl Tage (1-99)

    Beschreibung spezifische REQUIRED-Wartezeit in Tagen fr Environment einlesen

    Dieser Bezeichner kann auch mit vorangestelltem Environmentbezeichner verwendet werden, um auf einer Developmentumgebung andere Deploymenteigenschaften zu verwenden, als auf einer produktiven Umgebung. Bspl DEV_DeploymentDefaultScheduleDay=10

    Beispiel DeploymentDefaultScheduleDay=10

    Key DeploymentRequiredINSTALL

    Einsatz Optional: TrueFalseMixed

    Beschreibung Einstellungen, ob Deployment Required oder Available.

    Dieser Bezeichner kann auch mit vorangestelltem Environmentbezeichner verwendet werden, um auf einer Developmentumgebung andere Deploymenteigenschaften zu verwenden, als auf einer produktiven Umgebung. Bspl DEV_DeploymentRequiredINSTALL=True

    Beispiel DeploymentRequiredINSTALL=True

    Key DeploymentRequiredUNINSTALL

    Einsatz Optional: TrueFalse

    Beschreibung Einstellungen, ob UnInstall-Deployment Required oder Available.

    Beispiel DeploymentRequiredUNINSTALL=True

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 102/122

    Key SourceDEV

    Einsatz Optional: Share

    Beschreibung Name des PLPackDEV-Shares. Auf diesem Share/Ablage befinden sich die Softwarepakete, die in Entwicklung sind. Ist unter diesem Bezeichner kein Share/Ablage verzeichnet, werden in der DEV-Umgebung nur volle Applications mit allen Revisionen im Inhalt erstellt. Ein Updatemechanismus funktioniert in diesem Fall nicht.

    Beispiel SourceDEV=\\SERVER\PLPackDEV

    Key SourcePRD

    Einsatz Erforderlich: Share

    Beschreibung Name des PLPackPRD-Shares. Auf diesem Share/Ablage befinden sich die produktiven Softwarepakete. SCCMCreateApp kopiert das Softwarepaket bei der berfhrung in PRD auf diesen PLPackPRD-Ordner.

    Beispiel SourceDEV=\\SERVER\PLPackDEV

    6.17 Testen eines Softwarepaketes

    Das Testen des Softwarepakets ist eine zentrale Aufgabe des Softwarepaketierers. Nur durch ein Testing knnen allfllige Fehler vor einer Paketverteilung erkannt und korrigiert werden.

    Der Testablauf kann von Fall zu Fall unterschiedlich ausfallen und sind unternehmensspezifisch.

    6.17.1 INSTALL, REPAIR, REMOVE

    Das Softwarepaket ist zwingend im Installationskontext INSTALL, REPAIR und REMOVE zu prfen. Zum Teil reagiert eine Installation beim REPAIR anders als bei der Initialinstallation. Geprft wird, ob der Prozess positiv abgeschlossen wird und ob keine Fehlermeldungen in der Datei History.LOG ersichtlich sind.

    6.17.2 Upgrade testen

    Die Implementationen, die in der INI-Datei des Softwarepakets zum Einsatz kommen, sind zu prfen. Insbesondere stellt der Softwarepaketierer bei einer Initialrevision auch ein Upgrade nach, wenn eine Vorversion in der Umgebung des Unternehmens vorliegend ist.

    6.17.3 Lizenz und Aktivierungsstatus testen

    Wurde im Paket eine Lizenzaktivierung implementiert, ist die Software darauf zu prfen, ob dieser Aktivierungsprozess erfolgreich war. Durch temporres Verstellen der Systemzeit auf ein in der Zukunft liegendes Datum kann geprft werden, ob die Lizenz auf eine gewisse Zeit nach der Installation beschrnkt ist.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 103/122

    6.17.4 Manuelles Installieren im Systemkontext

    Das Softwarepaket ist unbedingt mittels einer Testinstallation mit SCCM auf einem produktionsnahen Testgert zu prfen. Treten Probleme auf, die im Ausfhrungskontext vermutet werden, kann eine weitere Analyse und ein Schnelltest mit dem Remote Package Installer oder mit den PSTools von Microsoft (ehemals SysInternals) hilfreich sein. Mit dem folgenden Aufruf startet man mit psexec eine Kommandozeile mit lokalen Systemrechten:

    psexec -i -s cmd.exe

    6.18 Paketdokumentation erstellen

    Aus Sicht der spteren Reproduzierbarkeit (beispielsweise bei einer neuen Version) sollten alle Vernderungen, die der Softwarepaketierer implementiert hat, bzw. den Ablauf der bei der Paketierungsarbeit zielfhrend war, dokumentieren! Das Verzeichnis Doc ist fr die Dokumentation vorgesehen.

    6.19 Signierung und Einbindung von Treibern

    Zur Signierung von Treibern mit einem entsprechenden Zertifikat ist gem. Anleitung von Microsoft vorzugehen: http://technet.microsoft.com/en-us/library/cc754052.aspx.

    Das Einbinden eines Treibers in ein Softwarepaket kann am einfachsten mit DPInst.EXE erledigt werden, welches in einem Pre- oder PostInstall oder einem Script zur Ausfhrung kommt. Fr die Signierung von Treibern existiert von Real Packaging GmbH ein separates Dokument.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 104/122

    7 Spezialflle und besondere Eigenschaften

    7.1 Paketvarianten

    Mit dem Package-Launcher sind auch Paketvarianten realisierbar. Das bedeutet, dass aus ein und demselben Softwarepaket verschiedene Ausprgungen realisiert werden knnen. So sind aus der selben Paketsource von Office beispielsweise das Office, aber auch ein Sharepointdesigner und auch ein Visio realisierbar. Die Paketvariante wird hierbei einfach dem Aufrufescript als zustzliche Kommandozeilenerweiterung bergeben.

    Der Softwarepaketierer hat nun die Aufgabe mittels dieser bergebenen Variante Installationsanweisungen zu implementieren. Die Variantenbezeichnung steht jedem PreInstall- und PostInstall-Script in Form einer WiseScript-Variablen zur Verfgung (%VARIANT%). So kann eine bedingte Anweisung aufgrund der Ausprgung dieser Variablen vorgenommen werden:

    Fr eine Umsetzung via Scripts (ExecuteFile, PreScripts, PostScripts, etc.) steht zum Ausfhrungszeitpunkt %VARIANTSECTION% zur Verfgung, woraus die bergebene Variante ableitbar wird. Aus dem Variantenaufruf ADMIN resultiert 99-ADMIN in der Variable %VARIANTSECTION%.

    Aber auch Ausprgungen von Windows Installer Properties knnen sich je nach vorgesehener Variante unterscheiden. Hier plaziert der Softwarepaketierer die Properties in der INI-Datei des Softwarepakets.

    Bei der Ausfhrung von SCCM-Launcher.vbs /i ADMIN werden im obigen Beispiel die Windows Installer Properties auf ADDLOCAL=Admin;Desktop SERVER=fv903773 gesetzt. Zudem steht dem Pre- und PostInstall neben der Variablen %VARIANT% auch die Variable %VARIANTSECTION% zur Verfgung. Diese Variable enthlt den Sectionbezeichner 99-ADMIN,

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 105/122

    der vom Package-Launcher ausgelesen wurde. Somit kann auch aus einem Pre- und PostInstall und aus Scripts auf die Inhalte der angewendeten Properties zugegriffen werden.

    Ansicht WiseScript mit Beispiel eines Zugriffs auf die Variable %VARIANTSECTION%:

    Die Anpassungen fr die Varianten mssen in SCCM manuell gettigt werden. Mit dem berfhrungsscript SCCMCreateApp_Link.vbs werden zunchst nur die Standardobjekte erstellt. Diese knnen im Nachgang angepasst werden (ndern der Kommandozeilenoption). Alle zustzlichen Varianten mssen komplett manuell erstellt werden.

    7.1.1 Instanzvarianten

    Die Variantengestaltung ist vermutlich eher die Ausnahme als die Regel in der Softwarepaketierung. Dennoch ergeben sich so zum Teil elegantere Realisierungsmglichkeiten. Die soeben beschriebene Standardvariantenimplementation geht von einer Entweder-Oder-Installation aus. Das bedeutet, dass auf einem Client entweder die eine oder die andere Ausprgung (Variante) zum Einsatz kommen soll.

    Ist es erforderlich, dass zwei Varianten parallel installierbar sein sollen, so kann dies ber Instanzvarianten realisiert werden. Diese werden im Gegensatz zu den regulren Varianten durch den Package-Launcher separat und eigenstndig registriert.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 106/122

    1. Implementieren Sie den Bezeichner MultiVariants=True in der Install-Sektion der INI-Datei:

    2. ndern Sie die Properties ber die Paket-INI-Datei oder verwenden Sie eine Pre/PostInstall fr die Variantenabbildung gemss dem Vorgehen aus letztem Kapitel.

    3. Installieren Sie die Instanzvariante wie gewohnt mit einer Kommandozeilenerweiterung:

    4. Fr die Deinstallation verwenden Sie fr eigene Tests die folgende Mglichkeit:

    5. Fr die SCCM-Integration ist aber bei der Deinstallation der Instanzvariante auf folgende Kommandozeile zurckzugreifen: "%WINDIR%\Package-Launcher\Bin\LocalLauncher.EXE" RealPackaging-Demo-1.0-ADMIN /x /q

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 107/122

    7.2 Package-Launcher Restart Manager

    Der Package-Launcher Restart Manager verwaltet Neustarts, die von der Installation von Softwarepaketen gefordert werden. Folgende Ereignisse lsen die Neustart- und Anmeldeverwaltung aus:

    1. Installation eines Softwarepakets mit Reboot=True in der INI-Datei

    2. Installation eines Softwarepakets mit Logoff=True in der INI-Datei

    3. Rckgabewert von 3010 (ERROR_SUCCESS_REBOOT_ REQUIRED) aus einer Windows Installer Transaktion (MSI/MSP-Installation/Repair/Deinstallation).

    7.2.1 Restart Manager Service

    Der Restart Manager Service ist fr die Verwaltung von Neustarts zustndig, die durch die Installation oder Deinstallation vom Softwarepaket angefordert wurden. Ein automatischer Neustart erfolgt nur, wenn niemand am Computer arbeitet (abgemeldeter Client auf dem keine Remotesitzungen geffnet sind).

    Der Restart Manager Service prft einmal pro Minute, ob der Registrykeys HKLM\Software\Real Packaging\Package-Launcher\MakeReboot einen Zeitstempel enthlt. Sollte diese Bedingung zutreffen, wird nach 5 mintiger Wartezeit das Gert automatisch neu gestartet, sofern im Hintergrund keine Installation ausgefhrt wird. Sollte LocalLauncher.EXE oder msiexec.exe noch Installationsttigkeiten vornehmen, wird mit einer Frequenz von fnf Minuten erneut geprft, ob die Installationsttigkeit abgeschlossen ist und der Neustart wird dann im Anschluss ausgefhrt.

    Der Restart Manager Service lscht die Registrykeys MakeReboot und MakeLogoff bei jedem Neustart des Gerts, d.h. wenn dieser vom Service selbst ausgelst, aber auch, wenn dieser vom Benutzer ausgefhrt wird.

    7.2.2 Restart Manager UI

    Das Restart Manager User Interface bernimmt die Kommunikation von anstehenden Neustarts mit dem Benutzer. Diese Kommunikation luft ber BallonTips am rechten Seitenrand des Computerbildschirms.

    7.2.2.1 Neustartmeldung

    Folgende Meldung erscheint bei anstehendem Neustart:

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 108/122

    7.2.2.2 Neuanmeldemeldung

    Folgende Meldung erscheint bei anstehender Neuanmeldung:

    7.2.2.3 Warnmeldetypen

    Wird ein gewisser Zeitabschnitt berschritten, so ndern die Warnungen von Soft-Warnings zu Strong-Warnings. Dies ist gekennzeichnet, dass die Warnungen in 6 mal krzeren Zeitabschnitten erscheinen und die Warnung ein anderes Erscheinungsbild annimmt (rotes Fehlersymbol)

    7.2.2.4 Benutzerdialog

    Wird auf den BalloonTip geklickt, erscheint folgender Dialog, worber der Benutzer den Neustart oder die Neuanmeldung auslsen kann:

    Das gleiche Fenster erscheint auch beim Klick auf das Icon im Benachrichtigungsfeld (Notification area).

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 109/122

    7.2.2.5 Steuerung des Verhaltens

    Die Eigenschaft des Verhaltens kann drei Zustnde annehmen:

    1. soft mit dieser Einstellung wird bei Soft- und Strong-Warnings kein Benutzerdialog angezeigt

    2. aggressive mit dieser Einstellung wird bei Strong-Warnings gleichzeitig mit dem BalloonTip ein Benutzerdialog angezeigt.

    3. extreme mit dieser Einstellung wird bei Soft- und Strong-Warnings gleichzeitig mit dem BalloonTip ein Benutzerdialog angezeigt.

    Diese Eigenschaften knnen ber den folgenden Registrykey definiert werden:

    HKLM\Software\Real Packaging\Package-Launcher\RestartManagerUIBehavior (soft oder aggressive oder extreme)

    7.2.2.6 Sprachausprgungen

    Der Package-Launcher Restart Manager untersttzt drei Sprachen Deutsch, English und Franzsisch:

    Die Sprache kann ber die Systemsteuerung umgestellt werden und entspricht der System-sprache die der aktuelle Benutzer gewhlt hat.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 110/122

    7.2.2.7 Registrykeys

    Alle Registrykeys befinden sich unter HKLM\Software\Real Packaging\Package-Launcher. Diese Registrykeys knnen nach Bedarf ber GPO gendert werden.

    RestartManagerUIBehavior softaggressiveextreme

    Mit diesem Key wird das Verhalten des zustzlichen Benutzerdialogs gesteuert (siehe letztes Kapitel)

    RestartManagerUITimer Zahl (600000) Frequenz in Millisekunden mit welcher die Prfung auf die

    Registrykeys MakeReboot und MakeLogoff erfolgen soll und die BalloonTips angezeigt werden (Soft-Warning 6 x lnger). Standardmssig sind 10 Minuten eingestellt (600000). Das bedeutet, dass Soft-Warnings jede Stunde einmal angezeigt werden, Strong-Warnings einmal pro 10 Minuten.

    RMSoftWarningInHour Zahl (8) Wechsel in Stunden nachdem von Soft-Warnings zu Strong-

    Warnings gewechselt werden soll. Nach 8 Stunden erscheinen nur noch Strong-Warnings in 6 x krzerer Frequenz.

    7.3 Package-Launcher Error Wizzard

    Der Package-Launcher Error Wizzard soll dem Benutzer oder der fr das initiale Gerteaufsetzen verantwortlichen Person, allfllige Fehlermeldungen, die durch das Installieren entstanden sind, aufzeigen. Nach dem Anmelden erscheint einmalig pro Benutzer bei einem im History.LOG ausgewiesenen Fehler, die Anzeige des Package-Launcher Error Wizzards als modalen Dialog:

    Mit einem Klick auf Ok oder Details>> wird die Kenntnisnahme besttigt und das Fenster verschwindet. Der Klick auf Details>> startet den lokalen History.LOG Viewer, um weitere Informationen einzuholen.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 111/122

    Die Anzeige im Package-Launcher Error Wizzard ist sprachabhngig (Deutsch, Franzsich, Englisch). Die Sprache wird hierbei durch die aktuellen Benutzereinstellungen gesteuert.

    Damit der Package-Launcher Error Wizzard funktioniert, muss dieser ber das Paket RealPackaging-PackageLauncher-2012 installiert werden. Inbesondere ist es erforderlich, dass die Berechtigungen des Registrykeys HKLM\SOFTWARE\Real Packaging\Package-Launcher\-Display Error Wizzard fr Schreibzugriffe des Benutzers geffnet sind (erledigt durch Paketinstallation).

    7.3.1 Dauerhaftes Einschalten des Package-Launcher Error Wizzard

    Um den Package-Launcher Error Wizzard anzuweisen, dass dieser immer erscheinen soll, wenn ein Fehler in der Installation entdeckt wird (also nicht nur bei der Erstanmeldung, sondern dauerhaft whrend Betriebszeiten), kann der Registrykeys HKLM\SOFTWARE\Real Packaging\Package-Launcher\Display Error Wizzard\DisplayError auf True gesetzt werden.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 112/122

    7.4 In Benutzung stehende Programme und Prozesse

    Der richtige Zeitpunkt zum Installieren und Verteilen von Software ist bis heute eines der herausfordendsten Themen in der Softwarebereitstellung in Unternehmen. Mit SCCM 2012 lassen sich zwar Wartungsfenster konfigurieren, um die Produktivitt des einzelnen Mitarbeiters und die des Unternehmens bei Softwareinstallationen mglichst nicht zu beeintrchtigen, bzw. eine fehlerfreie Installation dadurch zu gewhrleisten, dass diese zu Zeiten durchgefhrt wird, wo der Benutzer nicht mit Programmen am arbeiten ist. Auch die Installation per Wake On LAN zielt darauf, die Softwareinstallation zu Zeiten auszufhren, wo der Benutzer nicht angemeldet ist und es somit whrend der Installationstransaktion zu keiner Beeintrchtigung durch geffnete Programme kommt.

    Es gibt auch Verteilszenarien, wo die Installation im abgemeldeten Clientzustand durchzufhrt wird oder wo man whrend der Installation selbst den Mechanismen des Windows Installer Restart Managers oder denen der Pending Files Rename queue (PFR) zum Ersetzen von in-use-Dateien vertraut.

    Oft reichen die letztgenannten Varianten aber nicht aus und es kommt durch Installations- und Deinstallationsprozesse, zu Zeiten, wo die Benutzer Programme am Computer geffnet haben, zu Seiteneffekten So, dass

    1. die Installation oder Deinstallation mit Fehler und/oder Rollback abgebrochen wird oder

    2. die Software nach der Installation mit Fehler im Funktionsumfang reagiert

    Mit dem Package-Launcher App Shutdown Manager lassen sich solche Strungen auf elegante Weise verhindern. Denn er ermglicht das sichere Schliessen von Anwendungen kurz vor der geplanten Installation. Er lsst sich ber die INI-Datei des Softwarepakets, die Registry und ber Kommandozeilenoptionen steuern.

    7.4.1 Einstellungen ber die INI-Datei

    Es gibt ein Paket-INI-Bezeichner in der Install und UnInstall-Sektion (wird UnInstall Sektion weggelassen, wird die Install-Eigenschaft angewendet) mit vier Ausprgungen. Dieser steuert das Verhalten im Zusammenhang mit Dateien die zu aktualisieren sind, die aber whrend der Installation vom Benutzer noch in Benutzung stehen.

    AppShutdown=[DontAskForSave|AskForSave|Force];[DisableUserDisableShutdown];ALL|MSI;[[f:]Files]|False

    Fett geschriebene Texte sind Standardeinstellungen, die verwendet werden, wenn die Oder-Ausprgung in der Deklaration komplett fehlt.

    7.4.2 Standardoptionen

    Pattern DontAskForSave

    Einsatz Optional

    Beschreibung Schliesst vorgngig automatisch (ohne Dialog) alle Benutzeranwendungen, die keine zu speichernden Dokumente geffnet haben.

    Objektoptionen Standardoptionen

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 113/122

    Pattern AskForSave

    Einsatz Optional, Standardeinstellung, wenn DontAskForSave und Force nicht angegeben wurden

    Beschreibung Schliesst vorgngig keine Benutzeranwendungen, die keine zu speichernden Dokumente geladen haben.

    Pattern Force

    Einsatz Optional

    Beschreibung Schliesst automatisch alle offenen Benutzeranwendungen ohne Dialog.

    Pattern DisableUserDisabledShutdown

    Einsatz Optional

    Beschreibung Verhindert, dass Benutzer beim Dialog die Checkbox Anwendung bei Installation nicht automatisch schliessen zur Verfgung bekommt.

    7.4.3 Objektoptionen

    Pattern ALL

    Einsatz Optional

    Beschreibung Mit diesem Bezeichner wird der Benutzer fr heikle Pakete nach dem Download der SCCM Pakete oder Applications, whrend der Installation ber eine fixe Laufzeit darauf hingewiesen, dass er all seine offenen Doku-mente speichern soll. Der Hinweis erfolgt nur, wenn Benutzerprogramme geffnet sind. Die Paketinstallation wartet dann im Hintergrund auf die Benutzerinteraktion und bricht nicht mit Fehler ab. Die Dialogbox erscheint Top-Level immer zuvorderst und kann nur durch die Wahl einer der zwei Buttons zum Verschwinden gebracht werden. Falls der Zeitpunkt fr den Benutzer ungnstig ist, ermglicht die Wahl auf Installation um 30 Minuten verschieben ein temporres Verbannen des Dialogs in den Hinter-grund. Innerhalb 4h muss er die Installation zum Abschluss bringen, andernfalls die Programme, ohne Dokumente zu speichern, in Eigenregie heruntergefahren werden. Die letzten verbleibenden 90 Sekunden werden akustisch untermalt. Nach der Wahl Installation fortsetzen werden automatisch alle Benutzerprogramme geschlossen und der Benutzer wird daran gehindert, whrend der kurzen Installation, wieder Programme zu ffnen. Auch die Desktopshortcuts und der Startknopf verschwinden temporr. Wird der Dialog in einer Benutzersession des Computers besttigt, gilt dies auch fr alle andern Benutzersessions auf demselben Computer, d.h. dass auch deren Anwendungen geschlossen werden!

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 114/122

    Pattern MSI

    Einsatz Optional,Standardeinstellung, wenn False oder ALL nicht angegeben wurde

    Beschreibung Es werden alle in der Installation auf dem Client geplanten Revisionen oder fr die Deinstallation vorgesehenen MSIs nach ausfhrbaren Exe-Dateien abgesucht (aus allen MSI-Dateien) . Nur, falls diese automatisch ermittelten Dateien durch einen Benutzer gerade geffnet sind, wird dieser zum Schliessen dieser spezifischen Applikation aufgefordert. Ansonsten entspricht der Vorgang dem letzten Beispiel.

    Pattern [f:]Files

    Einsatz Optional

    Beschreibung Hier knnen Dateien angefgt werden (datei1.exe;datei2.exe; datei3.exe; ...), die geschlossen werden sollen.

    Der Parameter "f:" fr 'force' vor der Datei bedeutet, dass die Datei.exe forciert ohne Dialog gekillt wird. In diesem Fall kann es sich auch um einen Systemprozess oder einen Prozess, deren Schliessen erhhte Rechte erfordert, handeln!

    AppShutdown=unredmon.exe;f:ShellMail.exe;redrun.exe;"FreePDFde Loader.exe"

    Das Pattern kann zudem mit anderen Objektoptionen zusammen verwendet werden: AppShutdown=MSI;unredmon.exe;f:ShellMail.exe;redrun.exe

    Pattern False

    Einsatz Optional

    Beschreibung Ohne jegliche Angabe in der INI, der Registry oder in der Kommandozeile, verwendet der Package-Launcher AppShutdown=MSI. Soll generell kein Dialog erscheinen, lsst sich das mit AppShutdown=False bewerkstelligen.

    7.4.4 Dialoge

    Sind alle Benutzer abgemeldet, setzt die Installation unverzglich ohne Fortschrittsanzeige und Dialoge fort. Sind Benutzer angemeldet, aber keine Anwendungen geffnet, setzt die Installation blicherweise mit der Fortschrittsanzeige fort. Ein Schliessdialog erscheint also nur, wenn zum Installationszeitpunkt betroffene Benutzeranwendungen geffnet sind.

    Schliessdialog

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 115/122

    Der Schliessdialog kann durch den Computerbenutzer temporr in den Hintergrund verbannt werden, wenn dieser vorher noch ungestrt Arbeiten erledigen will. Zu diesem Zweck klickt dieser auf Installation um 30 Minuten verschieben.

    Der Dialog verschwindet danach. Durch einen Klick auf das Icon in der Taskbar kann der Dialog wieder in den Vordergrund gebracht werden:

    Wird whrend 30 Minuten nicht auf das Icon in der Taskbar geklickt, so erscheint danach die Dialogbox automatisch wieder auf dem Bildschirm. Ein Hinauszgern um jeweils 30 Minuten ist innerhalb eines Zeitfensters von 4h (Erstdialog der Installationstransaktion) mglich. Danach erfolgt ein automatisches Schliessen der betroffenen Anwendungen mit anschliessender Installation des Zielpakets.

    Nach dem Klick auf Installation fortsetzen >> oder nach berschreiten der maximalen Wartezeit von 4h werden alle verbleibenden und betroffenen Anwendungen geschlossen und die Installation des Zielpakets beginnt.

    In dieser Phase wird dem Benutzer der Status der Installation mitgeteilt:

    Durch einen Doppelklick auf die Statusinformation (im obigen Beispiel beispielsweise auf

    ) ffnet sich der History.LOG Viewer, um erweiterte Infor-mationen anzuzeigen. Stand die Objektoption in AppShutdown auf ALL, so wird whrend der Installation ein leerer Bildschirm ohne Startmen und Taskbar angezeigt. Zudem fehlt der OK Knopf in der Fortschrittsanzeige.

    Fortschritssanzeige Abschlussdialog

    Fortschrittsanzeige bei Objektoption ALL

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 116/122

    7.4.5 Beispiele

    Beispiel AppShutdown=MSI

    Beschreibung Fragt zum Schliessen von in Benutzung stehenden Exe-Dateien, die in den zu installierenden/deinstallierenden MSI's referenziert sind.

    Diese Option entspricht der Standardeinstellung, die auch ohne Verwendung des Keys AppShutdown eingesetzt wird.

    Beispiel AppShutdown=ALL

    Beschreibung Fragt zum Schliessen von in Benutzung stehenden Benutzerprogrammen, wenn solche geffnet sind.

    Nach dem Klicken auf Installation fortsetzen werden alle Benutzer-programme geschlossen, Startmen und Taskbar verschwinden und es wird bis zum Abschluss der Installation nur noch die Fortschrittsanzeige angezeigt.

    Beispiel AppShutdown=file1.exe;file2.exe

    Beschreibung Fragt zum Schliessen dieser angegebenen Exe-Dateien.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 117/122

    Beispiel AppShutdown=MSI;file1.exe;file2.exe

    Beschreibung Fragt zum Schliessen von in Benutzung stehenden Exe-Dateien, die in den zu installierenden/deinstallierenden MSI's referenziert sind, inklusive file1.exe und file2.exe.

    Beispiel AppShutdown=MSI;file1.exe;file2.exe;f:myprog.exe

    Beschreibung Fragt zum Schliessen von in Benutzung stehenden Exe-Dateien, die in den zu installier./deinstall. MSI's referenziert sind, inklusive file1.exe + file2.exe.

    Vorgngig wird die Datei myprog.exe forciert ohne Dialog gekillt. Fr forciert zu killende Prozesse (f:) kann es sich auch um einen Systemprozess oder einen Prozess, deren Schliessen erhhte Rechte erfordert, handeln!

    Beispiel AppShutdown=DontAskForSave;MSI

    Beschreibung Schliesst vorgngig automatisch alle angegebenen Dateien inkl. aller aus den MSI's ausgelesenen Exe-Dateien, welche keine zu speichernden Dokumente geffnet haben.

    Fragt erst danach zum Schliessen von in Benutzung stehenden Exe-Dateien, die in den zu installierenden/deinstallierenden MSI's referenziert sind und welche zu speichernde Dokumente geffnet haben.

    Beispiel AppShutdown=Force;ALL

    Beschreibung Schliesst alle Dateien automatisch und ungefragt! Ermglicht das Speichern von Dokumenten nicht.

    Hinweis

    Prozesse, die mit erhhten Rechten gestartet wurden (UAC elevated), werden nicht automatisch geschlossen. Hingegen bewirkt die Besttigung des Buttons Installation fortsetzen

    ein Schliessen der Benutzerprogramme (Anwendungen mit Fenster) auch ausserhalb der gerade aktiven Session. Das bedeutet, dass der Benutzer, der den Button klickt, systemweit die Verantwortung zum Schliessen aller Benutzeranwendungen bernimmt!

    Folgende Prozesse werden generell nicht geschlossen (ausser ber das Pattern f:):

    cmd.exe, wscript.exe, powershell.exe, plrestartmgrui.exe, logviewer.exe, remote package installer.exe, psexec.exe, msiexec.exe, (explorer.exe), shellexperiencehost.exe

    Fr App-V5 Pakete wird die Zielanwendung automatisch geschlossen. Das Verhalten kann dort zustzlich ber den Bezeichner AppVAutoStopProcesses gesteuert werden.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 118/122

    7.4.6 Registryeinstellungen

    Key HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\ShowProgressDialog

    Option True|False|User, Default ohne Angabe=User

    Beschreibung Ist ShowProgressDialog in der Registry nicht angegeben (Default) oder steht sie auf ShowProgressDialog=User, so wird die Fortschrittsanzeige bei Paketen angezeigt, wo die MSI Exe-Ressourcen enthlt oder dort wo die INI:AppShutDown-Option Anweisungen beinhaltet. Zudem kann der Benutzer die Fortschrittsanzeige ber das Kontrollkstchen fr alle Transak-tionen ausser ALL selber abstellen.

    Mit ShowProgressDialog=True wird bei jeder Installationstransaktion die Fortschrittsanzeige angezeigt, ohne dass sie der Benutzer abstellen kann. Steht der Wert auf False, dann wird bei Transaktionen, wo bei Beginn der Installation keine betroffenen Anwendungen geffnet sind, keine Fortschrittsanzeige angezeigt.

    berdies kann mit dem Registrykey ShowProgressAlways=True die Wir-kungsweise von ShowProgressDialog=User oder True verstrkt werden, indem dann die Fortschrittsanzeige immer bei jeder Transaktion kommt (nicht nur bei Paketen mit MSI Exe-Ressourcen, Datei- oder ALL-Einstellung).

    Hinweis Die Fortschrittsanzeige kann in jedem Fall durch Klick auf Dialog Beenden, Whlen von Enter oder der Escape-Taste zum Verschwinden gebracht werden.

    Es wird empfohlen, den Benutzer selber entscheiden zu lassen, ob er diese Anzeige wnscht (ShowAlwaysProgressDialog=User oder nicht gesetzt). Er kann die Einstellung im Fortschrittsanzeigedialog ndern.

    Key HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\ShowProgressAlways

    Option True|False, Default ohne Angabe=False

    Beschreibung Mit ShowProgressAlways=True wird veranlasst, dass die eingeschaltete Fortschrittsanzeige immer bei jeder Transaktion kommt (nicht nur bei Paketen mit MSI Exe-Ressourcen und Datei- oder ALL-Einstellung).

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 119/122

    Key HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\DisableShutdownGlobal

    Option Disable

    Beschreibung Mit DisableShutdownGlobal=Disable wird systemweit verhindert, dass Benutzer beim Dialog die Checkbox Anwendung bei Installation nicht automatisch schliessen zur Verfgung bekommen.

    Diese Einstellung wird durch ein allflliges AppShutdown-Pattern Disable-UserDisabledShutdown, welches in der Paket-INI, der Kommandozeile oder der Registry unter HKLM\Software\...\Package-Launcher\ShutdownMgr\-AppShutdown angegeben oder eben nicht angegeben wurde, bersteuert.

    Key HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\IniWinsAgainstReg

    Option Optional, True|False, Default ohne Angabe=True

    Beschreibung Mit dieser Option kann die Reihenfolge der Einstellungsapplizierung gendert werden. Siehe nchstes Kapitel.

    Beispiel 1 IniWinsAgainstReg=False AppShutdown=False

    Mit diesem Bezeichner wird in Kombination mit dem Registrykey AppShut-down die AppShutdown-Funktionalitt global abgeschaltet. Siehe unten.

    Key HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\AppShutdown

    Option Alle Optionen wie in Kapitel 7.4.1 Einstellungen ber die INI-Datei erlutert

    Beschreibung Mit dieser Option knnen abweichende Standards definiert werden. Beispielsweise

    AppShutdown=False.

    Zudem kann mit dem zustzlichen optionalen Registrykey IniWins-AgainstReg=False erwirkt werden, dass alllllige Paket-INI-Einstellungen mit dieser Registryeinstellung bersteuert werden.

    In jedem Fall wird die Einstellung aber durch das AppShutdown-Pattern einer Kommandozeile (beispielsweise in einer Task-Sequenz) bersteuert.

    Beispiel 1 AppShutdown=False, IniWinsAgainstReg nicht gesetzt:

    Bei Paketen, die in der INI kein AppShutdown deklariert haben, wird kein Anwendungsschliessdialog erscheinen (AppShutdown=False). Bei diesen Paketen, wo AppShutdown in der INI verwendet wird, gewinnt die Einstellung des Pakets.

    Beispiel 2 AppShutdown=False und IniWinsAgainstReg=False:

    Bei allen Paketen wird die AppShutdown-Funktionalitt ausgeschaltet und der Anwendungsschliessdialog kommt nie zur Anzeige, auch wenn in der INI AppShutdown deklariert wurde.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 120/122

    LocalLauncher.EXE

    PLRestartMgrUI.EXE

    Kein Benutzer

    ist angemeldet

    Benutzer

    ist angemeldet

    7.4.7 Welche Einstellung gewinnt?

    Der Bezeichner AppShutdown kann ber die INI-Datei (standardmssiges Vorgehen), die Registry oder ber die Kommandozeile vorgegeben werden. Bei Mehrfachdeklaration gewinnt, falls vorhanden, die Einstellung aus der Kommandozeile. Danach wird fr gewhnlich mit der Einstellung aus der INI-Datei fortgefahren und als letztes wird, sofern noch keine AppShutdown-Einstellung vorgefunden wurde, die Registry aufgelst. Folgende Reihenfolge wird standardmssig angewendet, bis zur erst mglichen Zuweisung einer Eigenschaft zu AppShutdown:

    1. Kommandozeile

    2. INI-Datei

    3. Registry

    Die Rnge aus der INI oder Registry knnen dynamisch ber den Registrykey IniWinsAgainstReg getauscht werden. Wird IniWinsAgainstReg=False angegeben ergibt sich folgende Reihenfolge:

    1. Kommandozeile

    2. Registry

    3. INI-Datei

    7.4.8 Ablauf des AppShutdown Managers

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 121/122

    7.4.9 ActiveSetup mit AppShutdown=ALL

    Ein zustzlicher Vorteil der Option AppShutdown=ALL ist, dass damit automatisch alle pendenten ActiveSetup-Implementationen im Anschluss der Installation in allen geffneten Sitzungen durchgefhrt werden, ohne dass sich der Benutzer abmelden muss. Ein zustzliches Logoff=True in der Paket-INI erbrigt sich dadurch.

    7.4.10 SCCM-Wartungsfenster

    Im Configuration Manager knnen in Collections spezielle Wartungsfenster definiert werden, um Installationen in die Nacht oder in Randzeiten zu verlegen, so dass diese zu Zeiten durchge-fhrt werden, wo der Benutzer nicht arbeitet, bzw. keine Programme geffnet sind.

    Hier kommt die maximal bentigte Zeit fr die Installation der Applications ins Spiel. Im Deployment Type der Application kann die maximale Zeit definiert werden, die fr die Installation bentigt wird. Hier handelt es sich um die Zeit fr die betroffene Application, ohne deren Abhngigkeiten.

  • Softwarepaketierung mit dem Package-Launcher www.realpackaging.ch

    SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC 122/122

    Wird eine Application nun ber eine Collection mit Wartungsfenster zugewiesen, ist darauf zu achten, dass die Summe der maximalen Zeiten der Zielapplication, inkl. deren erforderlichen Abhngigkeiten, das ber das Wartungsfenster zur Verfgung gestellte Zeitfenster nicht berschreitet. Wird der Wert berschritten, kann die Application nicht installiert/deinstalliert werden!

    Aus dieser Ausgangslage ergibt sich beim Einsatz von Wartungsfenster schnell mal das Bedrfnis, mglichst kleine Werte im Deployment Type anzugeben.

    Eine Reduktion der Werte unter 275 Minuten bedeutet aber unter Umstnden, dass bei einem allflligen Schliessdialog des Package-Launcher App Shutdown Managers dieser nicht die volle Verzgerungszeit (4h) zur Verfgung bekommt. Das kann bedeuten, dass ein stehengelassener Schliessdialog nach Ablauf der im Deployment Type deklarierten Zeit ungefragt schliesst, ohne dass die Installation fortgesetzt wird. Eine Fortsetzung der Installation kme wohl erst wieder beim nchsten verfgbaren Zeitfenster oder nach einem Policyrefresh in Betracht.

    Das ist an sich keine Tragdie, wenn dies im Einklang mit den Firmenrichtlinien und der Verteilungskultur stattfindet. Grundstzlich zielen beide Mechanismen das Wartungsfenster und die vollstndige Untersttzung des App Shutdown Managers auf eine Reduktion der betrieblichen Probleme aufgrund der Installationen whrend Betriebszeiten. Es wird empfohlen die beiden Mechanismen nicht gleichzeitig gemeinsam zu nutzen, sondern sich auf die eine oder andere Mglichkeit zu beschrnken.

    Sollte der Einsatz von SCCM Wartungsfenster im Vordergrund stehen, kann mit dem Paket-INI-Bezeichner MaxExecuteTimeRTM ein kleinerer Wert, als vorgesehen vorgegeben werden. Die Spannbreite bewegt sich zwischen 15 720 Minuten. Folgendes Beispiel veranschaulicht den Einsatz:

    [Install]

    MaxExecuteTimeRTM=60

    Zudem kann in einem solchen Szenario das dauerhafte Abschalten des App Shutdown Managers zielfhrend sein. Dies knnen Sie mit folgenden Registrykeys erreichen:

    HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\AppShutdown=False HKLM\Software\Real Packaging\Package-Launcher\ShutdownMgr\ IniWinsAgainstReg=False

Recommended

View more >