Softwarepaketierung Mit Dem Package-Launcher

Real Packaging GmbH
Eichenweg 9
3123 Belp
076 347 77 24
www.realpackaging.ch
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.1528.07.15
V1.5
Dominik Oberlin
SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC
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
Inhaltsverzeichnis
1
1.1
1.2
1.3
1.4
Vorwort .................................................................................................................... 6
Ziel und Zweck dieses Dokumentes ............................................................................. 6
Abgrenzungen............................................................................................................ 6
Legende ..................................................................................................................... 6
Vorarbeiten ................................................................................................................ 6
2
2.1
2.2
2.3
2.4
Methodische Betrachtung des Package-Launchers ................................................ 7

Umfang des Pakage-Launchers.................................................................................... 7
Updates und Upgrades ............................................................................................... 7
Revisionsupdates......................................................................................................... 8
Transaktionaler Installationsprozess ............................................................................. 9
3
3.1
3.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.4
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.6
3.7
3.7.1
3.7.2
3.7.3
3.7.4
3.8
3.9
3.9.1
3.9.2
3.9.3
3.9.4
3.9.5
3.9.6
3.10
3.10.1
3.11
3.12
3.13
3.14
3.14.1
Technische Betrachtung des Package-Launchers ................................................... 9

Hauptfunktionen des Package-Launchers .................................................................... 9
Bestimmen des richtigen Paket-Unterverzeichnisses ................................................... 10
Kommandozeilenoptionen ........................................................................................ 11
Folgende Kommandozeilenoptionen sind zulssig...................................................... 12
Kommandozeilen-Beispiele........................................................................................ 14
Kommandozeilenempfehlung fr die Integration in SCCM......................................... 15
Rckgabewerte ......................................................................................................... 15
Fehlermeldungen und History.LOG ............................................................................ 16
History.LOG .............................................................................................................. 16
Bedeutung von Fehlermeldungen .............................................................................. 17
INI-Datei ................................................................................................................... 20
Zusammenfassung der wichtigsten INI-Eintrge ......................................................... 20
Sectionproperties ...................................................................................................... 32
Realisierung eines Upgrades ...................................................................................... 33
Namensrichtlinien ..................................................................................................... 34
Bezeichnung von MSI und MST-Dateien .................................................................... 34
PreInstall und PostInstall ............................................................................................ 34
Bezeichnung des Security-Batch ................................................................................ 34
Bezeichnung der Build-Datei ..................................................................................... 34
Verwendung von PreInstall_00x.wse, PostInstall_00x.wse .......................................... 35
Einsatz von eigenen Scripts und Batchprogrammen ................................................... 36
Richtlinien beim Einsatz von Scripts ........................................................................... 36
Erstes Beispiel ........................................................................................................... 37
Scriptbezeichner ExecuteFile, ActiveSetupScript, PreScript & PostScript ....................... 38
Zustzliche Environmentvariablen whrend des Installationsprozess ........................... 40
History.LOG kompatible Fehlermeldungen erstellen ................................................... 41
Beispiele ................................................................................................................... 41
Formen der Ressourcen ............................................................................................. 43
Vereinfachtes Ablaufschema ..................................................................................... 45
MSI-Spezialflle minimale Aktualisierungen............................................................. 45
Anwendung von Patches und Transformationen ........................................................ 46
Build-Datei................................................................................................................ 47
Software-Inventarisierung ......................................................................................... 48
Die fr SCCM massgeblichen Schnittstellenregistrykeys ............................................. 48
2/122
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
Best-Practice Regeln und Limitierungen ............................................................... 50

Zielverzeichnis........................................................................................................... 50
Startmen und ShortCuts.......................................................................................... 50
Lizenzen ................................................................................................................... 50
Namensauflsung ..................................................................................................... 51
Abhngigkeiten (Middlewares) .................................................................................. 51
Versionshandling ...................................................................................................... 52
Umgang mit .HLP-Dateien......................................................................................... 52
Umgang mit VirtualStore........................................................................................... 52
Installationskontext ................................................................................................... 52
Firewall ..................................................................................................................... 53
Paketierungsarten ..................................................................................................... 53
Pfadlnge ................................................................................................................. 54
Automatisierung der Benutzereinstellungen .............................................................. 54
Keine automatischen Updates ................................................................................... 55
Sprachen und Spracheinstellungen ............................................................................ 55
Installation im Systemkontext .................................................................................... 56
Silent Installationen ................................................................................................... 56
Verwendung von variablen Servernamen ................................................................... 56
5
5.1
5.2
5.3
5.3.1
Handling der Upgrades und Revisionsupdates .................................................... 57

Entwicklungsumgebung............................................................................................ 59
Produktionsumgebung.............................................................................................. 59
Namensbezeichnungen ............................................................................................. 59
Limitierungen und Einschrnkungen .......................................................................... 59
6
6.1
6.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
6.3.8
6.3.9
6.3.10
6.3.11
6.3.12
6.4
6.4.1
6.4.2
6.4.3
6.4.4
6.5
6.6
Phasen der Paketerstellung ................................................................................... 60

Vorarbeiten .............................................................................................................. 60
CreatePackage .......................................................................................................... 60
Verwenden eines Hersteller MSIs ............................................................................... 62
Auspacken von Installationselementen aus einem Bootstrapper ................................. 62
Ermitteln des Paketierungsumfangs ........................................................................... 62
Protokolldatei analysieren.......................................................................................... 63
In-Place-Update von Patches (Splipstreaming) ............................................................ 63
Verwendung von InstallShield-Setups ........................................................................ 64
Installationssource kopieren ...................................................................................... 64
Erstellen einer MST-Datei fr alle weiteren Customizing-Arbeiten .............................. 64
Spezielle Einstellungen ber das Benutzerinterface des Herstellersetups ..................... 64
Wahl von Features mit INSTALLLEVEL ........................................................................ 65
ShortCuts ................................................................................................................. 65
Probleme mit der Silentinstallation............................................................................. 65
Verwendung von MakeCab.vbs ................................................................................. 65
Paket mit Wise Pakage Studio repaketieren ............................................................... 67
Regeln im Zusammenhang mit repaketierten Software-Paketen ................................. 67
Umgang mit Computerneustarts ............................................................................... 69
Snapshotprozess mit Wise Package Studio................................................................. 69
Anschlussarbeiten ..................................................................................................... 71
Umgang mit Benutzerressourcen............................................................................... 72
Grundregeln bei der Anwendung von MST Dateien ................................................... 72
3/122
6.7
6.7.1
6.8
6.8.1
6.8.2
6.9
6.9.1
6.10
6.11
6.12
6.13
6.14
6.14.1
6.14.2
6.14.3
6.14.4
6.15
6.15.1
6.15.2
6.16
6.16.1
6.16.2
6.16.3
6.16.4
6.16.5
6.16.6
6.16.7
6.16.8
6.16.9
6.16.10
6.16.11
6.17
6.17.1
6.17.2
6.17.3
6.17.4
6.18
6.19
ACL Lockerungen ..................................................................................................... 73

Datei und Registrierungsvirtualisierung ...................................................................... 75
Custom Actions in MSI-Dateien ................................................................................. 75
Anpassungen in Pre- und PostInstall .......................................................................... 76
Isolierte Ausfhrung von Pre-/PostInstall ausserhalb einer Paketinstallation ................. 77
PreInstall-Pakete........................................................................................................ 77
Umgang mit Legacy-Setups, die nicht repaketiert werden .......................................... 77
Active Setup in Pre- & PostInstall ............................................................................... 78
Active Setup, zielend auf eine MSI-Datei.................................................................... 78
Active Setup, zielend auf ein Pre/PostInstall ............................................................... 79
Umgang mit Patchdateien......................................................................................... 82
INI-Datei des Softwarepakets..................................................................................... 82
Upgrade-Handling .................................................................................................... 82
Lokaler Cache ........................................................................................................... 83
Umgang mit Abhngigkeiten durch Verwendung des Dependence-Eintrages ......... 84
Die Verwendung des TaskSequence-Eintrages ....................................................... 85
AddProperties ........................................................................................................... 87
Propertyanpassungen und zustzliche Erweiterungen ................................................ 88
Vereinfachte Ausfhrung .......................................................................................... 89
SCCMCreateApp automatisches berfhren in SCCM 2012 ................................... 90
Umfang der Objekte ................................................................................................. 91
Die verschiedenen Environments ............................................................................... 91
Vorbereitungen zur Bedienung von SCCMCreateApp ................................................ 92
berfhrung in DEV und PRD.................................................................................... 92
Abhngigkeiten ........................................................................................................ 93
Refresh von Applications ........................................................................................... 94
Update Content ........................................................................................................ 95
Deploymenteinstellungen.......................................................................................... 96
Schematische Darstellung der erstellten Objekte ........................................................ 96
Lschen von Applications .......................................................................................... 97
SCCMCreateApp.INI ................................................................................................. 98
Testen eines Softwarepaketes ................................................................................. 102
INSTALL, REPAIR, REMOVE ...................................................................................... 102
Upgrade testen ....................................................................................................... 102
Lizenz und Aktivierungsstatus testen ....................................................................... 102
Manuelles Installieren im Systemkontext .................................................................. 103
Paketdokumentation erstellen ................................................................................. 103
Signierung und Einbindung von Treibern ................................................................. 103
7
7.1
7.1.1
7.2
7.2.1
7.2.2
7.3
7.3.1
7.4
7.4.1
Spezialflle und besondere Eigenschaften......................................................... 104

Paketvarianten ........................................................................................................ 104
Instanzvarianten...................................................................................................... 105
Package-Launcher Restart Manager......................................................................... 107
Restart Manager Service .......................................................................................... 107
Restart Manager UI ................................................................................................. 107
Package-Launcher Error Wizzard ............................................................................. 110
Dauerhaftes Einschalten des Package-Launcher Error Wizzard .................................. 111
In Benutzung stehende Programme und Prozesse .................................................... 112
Einstellungen ber die INI-Datei............................................................................... 112
4/122
7.4.2
7.4.3
7.4.4
7.4.5
7.4.6
7.4.7
7.4.8
7.4.9
7.4.10
Standardoptionen ................................................................................................... 112

Objektoptionen....................................................................................................... 113
Dialoge ................................................................................................................... 114
Beispiele ................................................................................................................. 116
Registryeinstellungen .............................................................................................. 118
Welche Einstellung gewinnt? .................................................................................. 120
Ablauf des AppShutdown Managers ....................................................................... 120
ActiveSetup mit AppShutdown=ALL ........................................................................ 121
SCCM Wartungsfenster .......................................................................................... 121
5/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.
6/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-Wurzelverzeichnisses 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 MajorUpgrade, der auf die Windows Installer Technologie zurckgreift.
7/122
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.
Softwarepaket
2.3
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 :
8/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:
9/122
Untersttzung von verschiedenen Betriebssystemplattformen (x86/x64) und

verschiedener Sprachausprgungen im selben Softwarepaket und Ermittlung des
richtigen Paketverzeichnisses
in
Abhngigkeit
des
Real Packaging/PackageLauncher/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\<Paketname>_<Revision>.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 INIDatei, die den Namen des Softwarepaketes trgt.
Verwalten von Neustarts mit Interaktion mit dem Benutzer.
Trennung zwischen Entwicklungsumgebung

berfhren der Softwarepakete.
3.2
und
Produktionsumgebung
beim
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/PackageLauncher/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:
10/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 x64FR, 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 PackageLauncher 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 UACMeldung 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
FR
x86-GE, x86-FR, x86-IT

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.
11/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
003
003
003
Kommandozeile
/i:004
/i:005
/i:003
Auswirkung
installiert ab Revision 004
Fehlermeldung in History.LOG
- 003 wird repariert
- 004 wird installiert (UPDATE, wenn
vorhanden), 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
005
005
004
Kommandozeile Auswirkung
/i:-004
installiert bis Revision 004
/i:-009
installiert bis und mit Revision 005,
dann Fehler im History.LOG
/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).
12/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 SCCMLauncher.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
005
/g
Kommandozeile
/x:-003
Auswirkung
deinstalliert Revision 005, dann 004, dann 003
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
13/122
3.3.2
Kommandozeilen-Beispiele
Aufruf
Doppelklick auf
..\Pack\SCCM-Launcher.vbs
Auswirkung
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 Revisionsupdate 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 Benutzerinterface 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 installiert. 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
Das Paket wird komplett (alle Revisionen) deinstalliert.
oder
%WINDIR%\Package..\Bin\LocalLauncher.EXE
Byron-SALZ-1.0.3 /x
..\Pack\SCCM-Launcher.vbs /x:-003
Achtung: Deinstallationen knnen auch direkt ber

LocalLauncher.EXE auch ohne verfgbare Source
abgesetzt werden:
Das Paket wird rckwrts bis und mit Revision 003
deinstalliert.
14/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_00xCustomActions).
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
Fehler im Befehlszeilenaufruf
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
15/122
In der Registry legt der Package-Launcher unter HKLM\Software\Real Packaging\PackageLauncher\Packages\<PackageName>\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 PackageLaunchers. 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:
16/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.
17/122
Error during determine ProductCode!
Der ProductCode der zu installierenden Anwendung konnte nicht ermittelt werden.
Given Initial Revision (003) is > Installed Revision

(001) + 1
Initialrevision (/i:003) muss <= aktuell installierte

Revision + 1 betragen.
Given last REMOVE Revision (003) is > 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!
Fehler beim Aktualisieren oder Lschen von

PreInstall,PostInstall Scripts-Verzeichnis.
I/O Exception while sync files in

..\Package-Launcher\Scripts path!
Incompatible Application installed (Byron-HIP-1.0)
Ein in der INI-Datei unter Incompatibilities vermerktes 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 bergeben oder wurden ber MsiInstallProperties in

der INI-Datei deklariert.
Invalid Installation/Remove command line

arguments: overflow exception!
Unzulssige Zeichen in der Kommandozeile verwendet.
Nothing made! No valid source found! (argLine:

Byron-HIP-1.0 c:\Temp /s /qb)
Es wurde nichts ausgefhrt. Grnde sind unbekannt (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 bergebene 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-HIP1.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.
18/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 MSIDatei 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 (AdobeReader) 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-B0B7CBEAEE66EA0F}) or set INI entry
RemoveIncompatibleMsi to 'True'
Die Applikation wurde auf diesem System bereits

in anderer Form, als durch eine regulre Paketvariante installiert oder die zu installierende Version wurde in installiertem Zustand unter anderem
Namen vorgefunden.
Durch Setzen des INI-Eintrages oder der Kommandozeilenoption 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 verwendet. Entfernen Sie das bestehende Paket zuerst.
This package requires a reboot after the installation of following products: Byron-HIP-1.0
Gemss Vorgabe in der INI-Datei muss eine Abhngigkeit installiert und danach ein Reboot ausgelst 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 zurckgeliefert, 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.
19/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\<PackageName> 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
20/122
Key
Reboot
Einsatz
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
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 PackageLauncher 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
21/122
Key
TaskSequence
Einsatz
Optional
Beschreibung
ber den Bezeichner TaskSequence ist es mglich, einen zum DependenceEintrag 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 DependenceEintrag 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 Mechanismen 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
22/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

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

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

Standardmssig werden fr die Anwendung von Patches folgende Properties
verwendet (falls nicht angegeben): REINSTALL=ALL REINSTALLMODE=omus
Revisionen
unterschiedliche
Properties
bergeben
werden.
(Bspl. MsiPatchProperties_002=USER=Admin)
Beispiel
MsiPatchProperties=REINSTALL=ALL REINSTALLMODE=omus INSTALLDIR=D:\
23/122
Key
UpgradeExitIfFailed
Einsatz
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
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
INSTALL
REMOVE
INSTALL
Beispiel
001
002
001
003
(Inst. der Rev.003, die ein Major-Upgrade ausfhrt)
UpgradeInRevision=True
24/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
Beschreibung
Wird ein Instanzvariantenpaket erstellt, welches die Installation von verschiedenen 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
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
25/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 aufgeteilt 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\PackageLauncher\Cache\TWI-FBMS-1.0\x86-ML\002.
%CACHE% enthlt bei Verwendung von CopyLocal=True das Revisionsverzeichnis des zwischengespeicherten Pfades. Wird CopyLocal=True nicht
verwendet, ist die Variable leer.
Der Bezeichner ExecuteFile kann in der [Install]- und [Uninstall]-Section verwendet 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 vorgefundenen Revisionsverzeichnissen nach dem Namen der in der INI
angegebenen Datei gesucht. Werden in Revisionsverzeichnissen unterschiedliche Namen von Scripts verwendet, so kann dies mit dem Bezeichner
ExecuteFile_00x=<Name.ext> bewerkstelligt werden. Es wird generell der
Einsatz des Revisionspostfixes empfohlen.
26/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 ActiveSetup 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\TWIFBMS-1.0\x86-ML\002.
27/122
%CACHE% enthlt bei Verwendung von CopyLocal=True das Revisionsverzeichnis 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
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 Softwarepakets realisiert werden. So sind auch nachtrglich in einer knftigen Revision 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 Zuweisungswert DisableWithRetValue0 veanlasst hierbei, dass dem bergeordneten 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"
28/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 Softwareverteilungswerkzeug bermittelt.
Beispiel
CommitRebootExitCode=True
Key
UpgradeAfterPreInst
Einsatz
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
PackageName) (exit with return code 0)
downgrade!
(Upgrade
targets
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
29/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
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.
30/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
Objektoptionen
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
31/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
3.5.2
[Install]
MaxExecuteTime_004=60
ExecuteTime_004=40
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"
32/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 PackageUpgrade, 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 INIDatei des Softwarepakets gesteuert. Die massgeblichen Items sind folgende:
Upgrade=<Package-Family>
ScriptAdditionalUpgrades=<Package-Family>
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!
33/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:
<Package>_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.
34/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 Programmanweisungen 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
35/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 INIDatei 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 Transaktionsabschluss. 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.
36/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:
37/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 PackageLauncher 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.
38/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.
39/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%\PackageLauncher\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)
40/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. Daneben 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.
41/122
2. Hier wird ein PowerShell-Script ausgefhrt, welches im

abgespeichert ist.
Revisionsverzeichnis 001
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.
42/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 MSIDatei eingesetzt werden. Siehe Kapitel 3.7.1 MSI und MST Dateien
PostInstall
Befindet sich eine Datei mit der Bezeichnung PostInstall_00x.EXE im Revisionsverzeichnis 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 MSIDatei 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 Revisionsverzeichnis, wird diese vor allen allflligen MSI oder MSP-Installationen ausgefhrt. Befindet sie sich alleine im Verzeichnis, so werden nur die Programmanweisungen, 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 INIDatei des Softwarepakets angegeben (ExecuteFile=<Script.ext>), 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.
43/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!
44/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
45/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 PackageLauncher an sich keine Rolle. Dieser verwendet alle im Paketverzeichnis vorgefundenen
Transformationen und Patches.
46/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\PackageLauncher\Packages\<PACKAGE>\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 Betracht gezogen werden!
47/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 SoftwareStatusnderung und nur, wenn die Softwareinstallation nicht im Rahmen einer ComputerErstinstallation (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 PackageLauncher ausgefhrt (Standardeinstellung).
StopLauncherInventory = True
Fr mindestens 2 Stunden ab der Installation des nchsten

Softwarepakets wird das Inventory durch den PackageLauncher 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\<PACKAGE>\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\<PACKAGE>\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 BuildNummer kann sich bei allen Installationstransaktionen nur erhhen. Siehe Kapitel 3.14
Build-Datei.
3. HKLM\Software\Real Packaging\Package-Launcher\Packages\<PACKAGE>\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.
48/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\<PACKAGE>\LastAccess
Der Ausfhrungszeitpunkt der letzten Transaktion dieses Softwarepakets
5. HKLM\Softw..\Real Packaging\Package-Launcher\Packages\<PACKAGE>\Variant
Die Bezeichnung der Paketvariante. Siehe Kapitel 7.1 Paketvarianten
49/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
50/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 paketierenden Haupanwendung verwendet werden und auch knftig kaum von Drittapplikationen installiert werden: Diese Abhngigkeiten werden in der Regel im selben Softwarepaket 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
Revision 002
Revision 003
-> lokale Abhngigkeit 1

-> lokale Abhngigkeit 2
-> Hauptanwendung
51/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/InstallProgramme 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-HelpfilesKB917607.
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.
52/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
53/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:
54/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 ArchitekturSprache abzulegen, also beispielsweise unter x86-ML.
Architektur-Sprache (x86|x64-ML)
Revisionsverzeichnis mit den Installationsressourcen (MSI, MST, etc.)
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:
55/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.
Architektur-Sprache (fr jede Sprachausprgung)
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 )
56/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 nderungsabsichten immer in einem (oder in Ausnahmefllen mehreren) zustzlichen Revisionsverzeichnis/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.

Auftrag:
Upgrade
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.
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 VersionVerzeichnisses wird nicht gendert (1.0)!
57/122

Auftrag:
Revisionsupdate (Beispiel 2)
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 MSIDatei, ein PreInstalloder Script, welches die nderungsaufgaben
bernimmt. Die Bezeichnung des Version-Verzeichnisses wird
nicht gendert (1.0)!
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 RevisionsBezeichner und der Erweiterung .BLD (Bspl. HP-Demo1.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!
58/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:
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
Sicherungsverzeichnis fr Softwarepaketierer (bspl fr .WSI-Datei)
Vorlagenordner Pre/PostInstall und Securitybatch
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-NameVersion eingesetzt)
59/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 Produktionsplattform.
Softwareinstallation
analysieren/testen.
CreatePackage
ausfhren
Softwarepaket
bauen
Softwarepaket
integrieren
Softwarepaket
testen
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 Softwarepaketentwicklungsumgebung erstellt werden (Revision 001). Zudem werden alle fr den Softwarepaketierer notwendigen Vorlagen und Automatisierungsscripts kopiert.
Wichtige Scripts fr die Arbeiten des Softwarepaketierers:
Fgt Standardproperties dem Paket hinzu

Erstellt SCCM Pkg/Collection/Advertisement
60/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.
61/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 ClientProzesses 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 MSIDatei 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
62/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 bestehenden 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 <msipath\msiname> TARGETDIR=<AdminPoint> /L*v <logdatei> /qbVerwenden Sie unbedingt ein TARGETDIR, welches sich vom Verzeichnis von <msipath>
unterscheidet, ansonsten wird die administrative Installation mit einer Fehlermeldung quittiert.
Achtung: Ist das Attribut-Flag in der Components-Tabelle irgend einer Komponente auf NeverOverwrite (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 <msppath\mspname> /a <msipath\msiname>
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-PlaceUpdates ist bei der erstmaligen Installation der so entstandenen MSI-Datei die Anwendung
darauf zu prfen, ob diese den ntigen Patch-Level ausweist!
63/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 MSIDatei zu entpacken sein, so ist diese Datei anstelle des Bootstrappers zu verwenden. Die MSIDatei 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 SetupBootstrapper 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
64/122
anschliessend mit Orca in die bestehende STANDARD.MST oder eine neue leere MST-Datei
eingefgt werden. Diese Bereinigungsarbeit ist ntig, damit nicht willkrliche SetupAnpassungen 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 Preoder 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-
65/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!
66/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 LegacySetup 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 aufgefhrten 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
67/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 Hauptapplikationsinstallation auf das System zu installieren und die Abhngigkeit ist in der Softwarepaket-INIDatei 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).
68/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).
69/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.
70/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.
71/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.wseErweiterungen 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 Registrykey in HKCU verweisen. Dies ist insbesondere auch bei Dateiressourcen so zu bewerkstelligen. 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 Softwarepakets kann angegeben werden, dass der Package-Launcher die Source des
Softwarepakets vor der Erstinstallation lokal zwischenspeichert (sekundre Installationssource) 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.
72/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 entsprechende 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 CustomizingSection 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")
73/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.
74/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 %LOCALAPPDATA%\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. INIDateien), 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 (vbScript, 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
75/122
Softwarepaketierer vorgesehenen Fehlerabbruch erfolgt automatisch ein Rollback der MSIInstallation.

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

PostInstall_00x.wse.
Sie
im
Kapitel
3.8
Verwendung
von
PreInstall_00x.wse,
76/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 <PACKAGE> <REVISION> <TASK> <opt. VARIANT>
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 LEGACY_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 PackageLauncher selbstndig erledigt.
77/122
6.10 Active Setup in Pre- & PostInstall

Die Einrichtung eines Active-Setup-Befehls kann sehr einfach mittels einer Pre- und PostInstallImplementation 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
78/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%
79/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
80/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.
81/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 PackageUpgrades erfolgt.
82/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.
83/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)
84/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).
85/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
86/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 MSTDatei empfohlen.
87/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
Per-machine Installation erzwingen
ROOTDRIVE
C:\
Systemlaufwerk. Kann Probleme geben,

wenn nicht angegeben
ARPNOREPAIR
Reparatur in Add/Remove fr Benutzer

abschalten
ARPNOREMOVE
Remove in Add/Remove fr Benutzer

abschalten
ARPNOMODIFY
Maintenance in Add/Remove fr Benutzer

abschalten
REBOOT
ReallySuppress
Computerneustart verhindern
PLPackageEngineer
Dominik Oberlin
Informations-Property
PLPackage
Adobe-Reader-9.3
Paketnamen, erforderlich fr PackageLauncher
PLRevision
001
Revision, erforderlich fr Package-Launcher
(ARPSYSTEMCOMPONENT)
Optional, bei allen Revisionen > 001, damit

diese zustzliche Revision nicht in
Add/Remove erscheint
{{Fatal error: }}
Erforderlich fr Launcher Log-Einlesen
{{Error [1]. }}
1708
Installation operation failed.
70|PL_Binary|CleanUp
Erforderlich fr Package-Launcher Upgrade
RemoveExistingProducts
NEVER
Windows Installer Upgrade verhindern
CA_CleanUpByRemove
UPGRADINGPRODUCTCODE
Erforderlich fr Package-Launcher Upgrade
[Binary Data]
Vb-Script Custom Action fr Upgrade
Error
CustomAction
CA_CleanUpByRemove
InstallExecuteSequence
Binary
PL_Binary
88/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 Doppelklick auf das Script:
Bei mehreren neu eingesetzten Revisionen kann alternativ zu dem auf der letzten Seite beschriebenen Verfahren auch nur die Revision als Kommandozeilenoption angefgt werden. Fr jede
Revision ist so vorzugehen.
89/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 CustomAction-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:
90/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
91/122
6.16.3
Vorbereitungen zur Bedienung von SCCMCreateApp
Wie in diesem Hauptkapitel skizziert, wird die berfhrung durch das

SCCMCreateApp_Link.vbs aus dem Stammverzeichnis des Softwarepakets, eingeleitet.
Script
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.
92/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 entsprechend der Anweisung und Reihenfolgsprfung im Deployment Type der Application
integriert.
Ausprgung INI-Datei:
93/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.
94/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) vorgenommen haben und eine Aktualisierung des Pakets mit SCCMCreateApp vorgenommen wird,
so whlen Sie beim angezeigten Dialog Aktualisiere nur Content und schliessen Ihre Eingabe mit OK ab.
Dies entspricht der Funktion Update Content auf dem Deployment Type der Application.
95/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-NameVersion (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.
96/122
Revisionsupdate
Bei einem Revisionsupdate wird fr das Update eine neue Application Manufacturer-NameVersion (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-NameVersion (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.
97/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
98/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
99/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]
[Unversioned]
[Rev]
Dies entspricht der versionierten Collection

Dies entspricht der unversionierten Collection
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
100/122
Key
DeploymentDefaultScheduleDay=10
Einsatz
Optional: Anzahl Tage (1-99)
Beschreibung
spezifische REQUIRED-Wartezeit in Tagen fr Environment einlesen

Umgebung. Bspl DEV_DeploymentDefaultScheduleDay=10
Beispiel
DeploymentDefaultScheduleDay=10
Key
DeploymentRequiredINSTALL
Einsatz
Optional: TrueFalseMixed
Beschreibung
Einstellungen, ob Deployment Required oder Available.

Umgebung. Bspl DEV_DeploymentRequiredINSTALL=True
Beispiel
DeploymentRequiredINSTALL=True
Key
DeploymentRequiredUNINSTALL
Einsatz
Optional: TrueFalse
Beschreibung
Einstellungen, ob UnInstall-Deployment Required oder Available.
Beispiel
DeploymentRequiredUNINSTALL=True
101/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.
102/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.
103/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 PreInstallund 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,
104/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-OderInstallation 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.
105/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
106/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:
107/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).
108/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 Systemsprache die der aktuelle Benutzer gewhlt hat.
109/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 StrongWarnings 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.
110/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.
111/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-useDateien 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
Standardoptionen
Objektoptionen
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.
112/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 Dokumente 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 Hintergrund. 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!
113/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
114/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:
Fortschritssanzeige
Abschlussdialog
Durch einen Doppelklick auf die Statusinformation (im obigen Beispiel beispielsweise auf
) ffnet sich der History.LOG Viewer, um erweiterte Informationen 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.
Fortschrittsanzeige bei Objektoption ALL
115/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,

Verwendung des Keys AppShutdown eingesetzt wird.
die
auch
ohne
Beispiel
AppShutdown=ALL
Beschreibung
Fragt zum Schliessen von in Benutzung stehenden Benutzerprogrammen,

wenn solche geffnet sind.
Nach dem Klicken auf Installation fortsetzen werden alle Benutzerprogramme 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.
116/122
Beispiel
AppShutdown=MSI;file1.exe;file2.exe
Beschreibung

zu installierenden/deinstallierenden MSI's referenziert sind, inklusive
file1.exe und file2.exe.
Beispiel
AppShutdown=MSI;file1.exe;file2.exe;f:myprog.exe
Beschreibung

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.
117/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 Transaktionen 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 Wirkungsweise 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).
118/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 DisableUserDisabledShutdown, 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 AppShutdown 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 IniWinsAgainstReg=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.
119/122
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 AppShutdownEinstellung 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
Kein Benutzer
ist angemeldet
Benutzer
ist angemeldet
PLRestartMgrUI.EXE
LocalLauncher.EXE
120/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 durchgefhrt 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.
121/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-INIBezeichner 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
122/122

Softwarepaketierung Mit Dem Package-Launcher

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Softwarepaketierung Mit Dem Package-Launcher

Hochgeladen von

Copyright:

Verfügbare Formate

Real Packaging GmbH

Softwarepaketierung mit dem

nderungskontrolle, Prfung, Genehmigung

Div. nderungen oder Erweiterungen in:

Div. Erweiterungen. Anpassungen zu PL2.2, Rev.007

Div Erweiterungen zu PL 2012

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Diverse allgemeine Anpassungen

Softwarepaketierung mit dem Package-Launcher

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

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

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

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

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

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

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

ACL Lockerungen ..................................................................................................... 73

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

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

Standardoptionen ................................................................................................... 112

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

Ziel und Zweck dieses Dokumentes

In kursiv geschriebene Wrter sind Namen, Fremdsprach- und Fachausdrcke, sowie

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

2 Methodische Betrachtung des Package-Launchers

Umfang des Pakage-Launchers

Updates und Upgrades

Die in diesem Dokument verwendeten Formen des Softwareaktualisierungsprozesses sind in

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

Das Hauptziel von Revisionsupdates ist es, vom Auftraggeber

Alle Revisionsupdates werden chronologisch und transaktional

Erste Produkteinfhrung mit Revision 001:

Update auf Revision 002 :

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

Der Package-Launcher installiert die Revisionen des Softwarepakets transaktional. Wenn

Installationen ohne MSI-Datei (bspl. PreInstall_00x.wse) werden im Fehlerfall

3 Technische Betrachtung des Package-Launchers

Hauptfunktionen des Package-Launchers

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

Untersttzung von verschiedenen Betriebssystemplattformen (x86/x64) und

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

Protokollieren der Transaktionen nach %WINDIR%\Logs\History.LOG und der

Rckmelden des Installationsstatus und allflliger einzeiliger Fehlermeldung an SCCM.

Rckgabe eines qualifizierten Rckgabewertes an SCCM, welches die erfolgreiche

Anwendung von Berechtigungsanpassungen (ffnen der Security).

Verwalten von Neustarts mit Interaktion mit dem Benutzer.

Trennung zwischen Entwicklungsumgebung

Bestimmen des richtigen Paket-Unterverzeichnisses

Der Package-Launcher ermittelt das richtige Paket-Unterverzeichnis anhand der vorliegenden

SW-PAKETIERUNG MIT DEM PACKAGE-LAUNCHER.DOC

Softwarepaketierung mit dem Package-Launcher

Vorgefundene und gewhltes Unterverzeichniss/e

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

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

x86-GE, x86-FR, x86-IT