MSI: Inside Windows Installer

Inhaltsverzeichnis
Inhaltsverzeichnis
Einleitung
Fr wen ist dieses Buch gedacht?
Beispieldateien
Support
Danksagung
1. Grundlagen der Windows Installer-Technologie
berblick
Aufbau und Struktur des Installationspaketes
Physische Betrachtung
Logische Betrachtung
Installationsarten und Installationsphasen
Clientinstallation
Administrative Installation
Angekndigte Installation
Installationsphasen
Analyse des Installationsprozesses
Aktivitten des Client-Prozesses
Aktivitten im Server-Prozess
Inhalt der Skriptdateien
Individuelle Erweiterungen
Custom Action-Server
Grundlegende Betrachtungen
Fazit
2. Windows Installer-XML
Installation und Integration
Hierarchische Strukturen
Installation von Windows Installer-XML
Integration in Visual Studio
Dokumentenstruktur und Sprachmerkmale
Grundlegende Deklarationen
Manueller und automatisierter Buildprozess
Variablen und Prprozessoren
2
9
10
10
11
11
14
14
17
17
28
32
33
37
38
39
41
42
46
52
58
58
63
71
72
72
73
74
75
77
77
81
83
Persnliche Ausfertigung fr Martin Martinsson
Inhaltsverzeichnis
Lokalisierte Installationspakete
Fragmente
Modularitt und Zusammenspiel
Erzeugen der Quelldateien
Kompilieren und Linken
Erweiterte Erstellvorgnge
Erweiterungsbibliotheken
Arten und Verwendung
Individuelle Erweiterungsbibliothek
Bibliothek zur Darstellung einer Benutzeroberflche
Komplexe Erweiterungsbibliotheken
Fazit
3. Windows Installer und 64-Bit-Betriebssysteme
Architekturen
Dateisystem und Systemregistrierung
WOW64-Subsystem
Verhalten bei der Installation
Eigenschaften
Allgemeine Hinweise
Benutzerdefinierte Aktionen
Richtlinien
Fazit
4. Deployment Tools Foundation
Allgemeine Informationen
Funktionalitt
Installation und Bestandteile
Struktur und Objektmodell
Datenbank und Session
Inventarisierung
Interne Ablufe
Erstellen einer benutzerdefinierten Aktion
Optimierung des Erstellungsvorgangs
Debuggen
Erweiterte Implementierungen
Fazit
5. Benutzerkontensteuerung in Windows Vista und Windows Server 2008
88
91
93
96
103
109
117
117
119
120
122
131
132
132
136
136
140
143
144
144
146
148
149
149
149
150
151
153
158
161
162
163
166
168
169
174
176
Inhaltsverzeichnis
berblick ber den Windows Installer 4.0
Sicherheit
Sicherheitskontext
Zugriffstoken unter Windows Vista
Anwendungen fr Windows Vista und Windows Server 2008
Absicherung des Systems
Virtualisierung
Installationen in geschtzten Umgebungen
Verwaltete und privilegierte Installationen
Installationen unter Windows Vista und Windows Server 2008
Interaktion mit der Benutzerkontensteuerung
Verwenden eines Bootstrappers
Standardbenutzerinstallationen
Anwenden von Windows Installer-Patches
Kompatibilitt mit lteren Installer-Versionen
Installation fr den Benutzer oder fr den Computer
Voraussetzungen fr die Installation
Absicherung der Installationsquellen
Windows Installer und der Schild
Identifizieren von Problemquellen
Fazit
6. Computerneustarts im Installationsprozess
Ursachen fr einen Computerneustart
Neustarts im Installationsprozess
Kontrollieren und berwachen des Neustartverhaltens
Neustart durch Dateien in Verwendung
Ersetzen von verwendeten Dateien
Startvorgang des Systems
Unterdrcken des Computerneustarts
Funktionsweise des Neustart-Managers
Identifikation der verwendeten Ressourcen
Beenden und Starten der Prozesse
Verwendung des Neustart-Managers durch den Windows Installer
Voraussetzungen fr die Verwendung des Neustart-Managers
Interaktion mit dem Windows Installer
176
178
179
184
188
191
197
201
204
208
208
210
212
216
224
224
227
230
230
233
238
241
243
243
245
245
251
255
256
258
260
264
268
272
273
279
282
Inhaltsverzeichnis
Problemfall Benutzerkontensteuerung
Bootstrapper
Fazit
7. Sicherheit, Sprachen und Troubleshooting
Windows-Ressourcenschutz
Funktionsweise
Programmtechnischer Zugriff
Installation
Installationsprotokoll
Protokollierung aus dem Paket
Informationen im Protokoll
Strategien fr die Fehlersuche
Mehrsprachige Benutzeroberflchen
Mehrsprachige Anwendung
Ressource-Bibliotheken
Erstellen des Installationspaketes
Fazit
8. Paketbergreifende Transaktionen
Trends in der Softwareinstallation
Konkurrierende Installationen
Mergemodule
Bootstrapper
Funktionalitt des Chainers
Transaktionen
Transaktionalitt des Windows Installers
Phasen der Installation
Transaktionen mit dem Installer 4.5
Programmtechnische Implementierungen
Beschreibung der Funktionen
Installationen und Konfigurationen
Transaktionsklasse
Eingebetteter Chainer
Rollback- und Neustart Verhalten
Szenarien fr einen Rollback
Neustarts und Transaktionen
Einbindung der Benutzerkontensteuerung
288
290
291
293
293
294
295
297
298
299
301
305
307
308
310
314
318
320
320
323
323
325
327
334
338
339
340
343
345
346
349
351
353
357
358
362
366
Inhaltsverzeichnis
Fazit
9. Externe Benutzeroberflchen
Grnde fr die Verwendung
Vorgehensweise und Nutzung
Registrieren der externen Oberflche
Darstellung der internen Oberflche
Programmtechnische Umsetzung
Beeinflussung des Installationsprozesses
Darstellung der Informationen
Integrierte externe Benutzeroberflche
Integration
32-Bit und 64-Bit
Deaktivieren der integrierten Benutzeroberflche
Interne Ablufe
Anwendungsszenarien
Fazit
10. Optimierungen im Servicemodell
Softwareaktualisierungen
Minimale Aktualisierungen
Komplexe Aktualisierungen
Struktur und Verwendung von Patchpaketen
Anwenden von Patches
Anatomie eines Patches
Anwendungsreihenfolge von Patches
Erstellen von Patches
Klassischer Lsungsansatz
Objektbibliothek patchwiz.dll
Programmtechnischer Zugriff auf die Metainformationen
Optimierungen
Pseudoinstallierte Patches
Deinstallation von Patches
Fazit
Anhang A: Glossar
Anhang B: Tools und Anwendungen fr den Windows Installer
Windows Installer-XML
Windows Installer-SDK
367
368
369
371
371
375
377
378
381
392
393
396
404
405
405
411
415
416
416
420
424
425
425
427
432
434
434
437
448
450
451
456
464
466
470
470
470
Orca
Deployment Tools Foundation
InstEd
Windows NT DocFile Viewer
SharpDevelop
Microsoft Cabinet Software Development Kit
Bootstrapper Manifest-Generator
IExpress
MSI LogfileAnalyzer
Windows Installer-Suite 2008
Windows Installer-Debugger 2008
Logo Testing Tools for Windows
Visual Studio 2008
Anhang C: Limitierungen
Anhang D: Aktualisierung von .NET Assemblies
Anhang E: Datenbanktabellen des Windows Installers 4.5
Anhang F: Systemrichtlinien
Computerkonfiguration
Benutzerkonfiguration
Anhang G: Automatische Reparaturen und das Microsoft Active Setup
Automatische Reparatur
Halbautomatische Vorgehensweise
Anhang H: Struktur und Inhalt des Beispielarchivs
Stichwortverzeichnis
Der Autor
470
470
470
470
471
471
471
471
471
471
471
471
472
473
475
478
487
487
490
492
492
493
495
498
511
Fr Werner und Bernd.

Ich werde Euch nie vergessen.
Einleitung
Einleitung

Beispieldateien
Support
Danksagung
9
10
11
11
Die Softwareinstallation hat sich seit dem Erscheinen des Windows Installers im Jahre 1999 extrem
gewandelt. Zum damaligen Zeitpunkt waren monolithische Anwendungen stark verbreitet, so dass zur
Installation auch groe und komplexe Installationspakete verwendet wurden. Hieraus ergab sich die bis
heute gltige Anwendungsstrategie des Windows Installers, die mit One-Package-One-Product
umschrieben wird. Diese Strategie besagt, dass ein Produkt durch ein Windows Installer-Paket
dargestellt wird, also zur Installation eines Produktes somit ein Paket bentigt wird. Aktuell sind neue
Trends in der Softwareinstallation zu verzeichnen. Ein Produkt besteht heutzutage nicht mehr nur aus
einem Paket, sondern aus einer Vielzahl von Paketen, die als Micro-Packages bezeichnet werden.
Einen weiteren gravierenden Wandel hat es im Sicherheitsbewusstsein der Anwender und der
Hersteller gegeben. Hieraus entstanden sind Betriebssysteme und Anwendungen die in der aktuellen
Generation ber einen sehr hohen Sicherheitsstandard verfgen, der natrlich auch im Rahmen des
Installationsprozesses zu bercksichtigen ist.
Dieses Buch widmet sich natrlich den sicherheitsrelevanten Implementierungen und den neuen
Funktionen des Windows Installer 4.5, wobei die als Multi-Package-Transaktion bezeichnete
Funktionalitt einen sehr hohen Stellenwert einnimmt. Aber begonnen wird an anderer Stelle. Im
ersten Teil des Buches geht es um allgemeine Informationen zum Windows Installer. Hier werden
Themen wie der Installationsprozess, das Installationspaket und benutzerdefinierte Aktionen erlutert.
Abgerundet wird dieser Teil des Buches mit einer detaillierten Betrachtung der Installationen auf 64Bit-Plattformen, sowie den Toolsammlungen Windows Installer-XML und Deployment Tools
Foundation. Der zweite Teil des Buches ist der Installation unter den Betriebssystemen Windows Vista
und Windows Server 2008 gewidmet. Hierbei werden Technologien wie die Benutzerkontensteuerung,
der Neustart-Manager und der Windows-Ressourcenschutz betrachtet und die Auswirkungen dieser
Funktionalitten auf den Installationsprozess skizziert. Darber hinaus werden an dieser Stelle auch
Szenarien fr eine effektive Problemanalyse vorgestellt und Lsungen fr die Erstellung und
Installation von mehrsprachigen Anwendungen erarbeitet. Der letze Teil dieses Buches befasst sich
schlielich mit den neuen Funktionen des Windows Installer 4.5. Den Schwerpunkt bilden hierbei
natrlich die paketbergreifenden Transaktionen mit all Ihren Ausprgungen und Facetten, wobei die
Verwendung einer zentralen Benutzeroberflche eine relevante Rolle einnimmt. Den Abschluss nicht
nur dieses Teils, sondern des ganzen Buches bilden die Windows Installer-Patches, wobei der
Schwerpunkt auf den Optimierungen im Servicemodell und im Erstellvorgang liegt. Zustzlich
erhalten Sie noch Informationen zu Technologien, die nicht direkt mit dem Windows Installer in
Verbindung stehen, diesen allerdings in bestimmten Szenarien ergnzen und somit den
Einleitung
Installationsprozess einfacher und effektiver gestalten.

Dieses Buch richtet sich in erster Linie an Designer von Installationsroutinen, Systemadministratoren
und Softwareentwickler, die mehr ber die Windows Installer-Technologie erfahren mchten. Zur
effektiven Verwendung dieses Buches sollten Grundkenntnisse der Windows Installer-Technologie
vorhanden sein.
Viele der neuen Funktionalitten des Windows Installers 4.5 sind im eher im Entwicklerumfeld
anzusiedeln als im administrativen Segment. Aus diesem Grund werden viele programmtechnische
Implementierungen vorgestellt, die Zugriffsmglichkeiten auf die Windows Installer-Plattform bieten
und somit Lsungsanstze zur Nutzung der Funktionalitt ermglichen. Diese programmtechnischen
Zugriffe wurden in der Programmiersprache Microsoft Visual C# verfasst, so dass Kenntnisse dieser
Programmiersprache zum besseren Verstndnis uerst hilfreich wren.
Die Toolsammlung Windows Installer-XML ermglicht die Erstellung von Installationspaketen und
weiterer Windows Installer-Dateien durch die Verwendung spezieller XML-Dokumente. Um mit
dieser Toolsammlung effektiv arbeiten zu knnen sollten Kenntnisse dieser Metasprache vorhanden
sein.
Beispieldateien
Der Quellcode fr alle Rezepte des Buchs ist online unter http://www.microsoft-press.de/support.asp
verfgbar. Tragen Sie im Eingabefeld fr die ISBN-Nummer die Zahl 431 ein. Klicken Sie auf Suchen.
Nach kurzer Wartezeit erscheint das Suchergebnis. Klicken Sie im Suchergebnis auf den angezeigten
Link. Klicken Sie auf den Link neben Downloads und speichern Sie die Datei auf Ihrem Computer.
Whlen Sie dabei direkt den Ordner, in den Sie die bungsdateien installieren mchten.
Die Beispielanwendungen wurden mit Microsoft Visual Studio 2008 erstellt. Einige Beispiele wurden
so konfiguriert, dass sie mit dem Microsoft .NET Framework 2.0 verwendet werden knnen. Andere
Beispiele verwenden hingegen neue Funktionalitten, wie beispielsweise LINQ (Language Integrated
Query), so dass diese die Version 3.5 des Microsoft .NET Frameworks voraussetzen. Die
Installationsdateien wurden ausschlielich mit Anwendungen der Toolsammlung Windows InstallerXML erstellt, die wiederum auch das Microsoft .NET Framework 2.0 bentigt. Zur manuellem
Erstellung der Installationsausgaben ist es erforderlich, dass der Ordner, der die Binrdateien von
Windows Installer-XML enthlt, durch die Umgebungsvariable MSIWIX ansprechbar ist. Weiterhin ist
der Ordner ebenfalls der Umgebungsvariablen Path anzufgen.
Die Beispiele und bungen aus Teil A sind allgemeiner Natur und verlangen keine explizite Version
des Windows Installers und auch kein spezielles Betriebssystem. Anders verhlt es sich bei den
Szenarien aus Teil B. Hierfr sind die Betriebssysteme Windows Vista oder Windows Server 2008,
sowie der Windows Installer in der Version 4.0 und hher erforderlich. In Teil C werden letztlich die
Funktionalitten des Windows Installer 4.5 erlutert, so dass diese Version zur Verwendung der
Beispiele auch erforderlich ist. Als Betriebssysteme knnen hierbei Windows XP, Windows Vista,
Windows Server 2003 und Windows Server 2008 verwendet werden.
10
Einleitung
Support
Es wurden alle Anstrengungen unternommen, um die Korrektheit dieses Buches zu gewhrleisten.
Microsoft Press bietet Kommentare und Korrekturen fr seine Bcher im Web unter
http://www.microsoft-press.de/support.asp an.
Wenn Sie Kommentare, Fragen oder Ideen zu diesem Buch haben, senden Sie diese bitte per E-Mail an
presscd@microsoft.com oder per Post an:
Microsoft Press Deutschland
Konrad-Zuse-Strae 1
85716 Unterschleiheim
Bitte beachten Sie, dass ber diese Adressen kein Support fr Microsoft-Produkte angeboten wird.
Wenn Sie Hilfe zu Microsoft-Produkten bentigen, kontaktieren Sie bitte den Microsoft Online
Support unter http://support.microsoft.com. Wenn Sie Support fr die Tools von Drittanbietern
bentigen, wenden Sie sich bitte an den jeweiligen Hersteller des Tools. Verwenden Sie dazu die
Website, die auf der Download-Seite des entsprechenden Tools aufgefhrt ist.
Danksagung
Ein Buch zu schreiben ist sehr hufig eine einsame Angelegenheit, dennoch sind eine Vielzahl von
Personen daran beteiligt. Dieses Buch stellt da keine Ausnahme dar, denn es wre ohne die
Untersttzung von zahlreichen groartigen Personen nicht realisierbar gewesen. Das fngt zunchst auf
der technischen und fachlichen Ebene an, geht ber die gestalterische Ebene und endet letztlich auf der
sozialen Ebene.
Wie bei meinem letzten Buch mchte ich mich zunchst bei Carolyn Napier von der Microsoft
Corporation bedanken. Carolyn hat mir unermdlich alle Fragen zu der Windows InstallerTechnologie beantwortet und darber hinaus viele Lsungsanstze gegeben, die nirgendwo
dokumentiert waren und auf die man alleine nicht gekommen wre. Danke meinen Kolleginnen und
Kollegen vom Premier Support for Developers der Microsoft Deutschland GmbH, die mich in allen
Belangen untersttzt haben. Ein besonderes Dankeschn gilt Franz Robeller fr die Informationen zur
64-Bit-Technologie und Oliver Niehus fr die Antworten zu Windows Vista und zur
Benutzerkontensteuerung. Danke auch an Marcel Kulicke, der mich durch geschickte Fragen in den
letzten Monaten immer wieder gezwungen hat, mich noch intensiver mit bestimmten Themen zu
befassen. Vielen Dank an Hans Stanglmayr und Daniel von Wilcken, die mich immer untersttzt und
motiviert haben.
Ich danke allen Mitarbeitern von Microsoft Press, allen voran Thomas Braun-Wiesholler, Florian
Helmchen und Thomas Pohlmann, die mir geholfen haben dieses Buch zu schreiben und die mir
wertvolle Tipps fr die Gestaltung und den Aufbau des Buches gegeben haben. Ein Dank gilt auch
meinem Fachlektor Georg Weiherer, der es bereits bei meinen frheren Bchern verstanden hat, die
eigenwilligen Formulierungen, Gedankensprnge und Intentionen eines Programmierers in ein lesbares
Format umzuwandeln.
Danke auch meiner groartigen Tochter Daria, die mir aus der Entfernung immer wieder Mut
zugesprochen hat und dieses Mal, meine Nerven nicht zu sehr strapaziert hat. Ein besonderes und
11
Einleitung
riesen groes Danke gilt meiner ber alles geliebte Ehefrau, Partnerin und Freundin Ute, ohne deren
Hilfe dieses Buch nur in der Phantasie existieren wrde.
12
Teil A
Allgemeines zum
Windows Installer
Kapitel 1
Grundlagen der Windows Installer-Technologie
Grundlagen der Windows InstallerTechnologie
berblick
Fazit
14
17
32
41
58
71
Erstklassige Software zu entwickeln ist die eine Seite der Medaille, ein professionelles Setup dafr zu
erstellen ist hingegen die andere Seite. Hufig werden sehr viele Ressourcen und Innovationen in die
Entwicklung neuer Software investiert, aber die Erstellung eines professionellen Setups wird nicht mit
dem gleichen Engagement betrieben, obwohl das eigentlich erforderlich wre. Das Setup ist der erste
Berhrungspunkt des Kunden mit der neuen Software. Ein nicht funktionierendes oder einfach
ausgedrckt ein schlechtes Setup, lsst die beste Anwendung nur in einem migen Licht erstrahlen.
Das muss nicht so sein, denn mit Hilfe des Windows Installers und einiger zustzlicher Tools ist es
keine Hexerei, ein professionelles und zukunftsorientiertes Setup zu erstellen.
berblick
Der Windows Installer ist eine Technologie zur Verwaltung des Installationsstatus einer oder mehrerer
Anwendungen. Es ist damit mglich eine Anwendung erstmalig auf einem System zu installieren, den
Funktionsumfang der Anwendung zu verndern, die Installation zu reparieren und zu aktualisieren und
am Ende des Produktlebenszyklus dieses zu deinstallieren. Der Windows Installer wurde erstmalig
1999 zur Installation von Microsoft Office 2000 eingesetzt. Hierzu war es erforderlich, den Windows
Installer zunchst selbst zu installieren. Heutzutage ist der Windows Installer integraler Bestandteil des
Betriebssystems, wodurch er bei der Installation vorausgesetzt werden kann.
Derzeitig existieren unterschiedliche Versionen des Windows Installers mit unterschiedlichen
Funktionserweiterungen. Die Betriebssysteme Windows Vista und Windows Server 2008 enthalten
standardmig den Windows Installer der Version 4.0, die Betriebssysteme Windows XP und
Windows Server 2003 setzen hingegen standardmig den Windows Installer 3.1 ein. Fr alle die
gerade genannten Betriebssysteme steht der Windows Installer 4.5 als optionales Installationspaket zur
Verfgung. Fr Windows 2000 steht der Windows Installer 3.1 und fr die lteren Betriebssysteme
Windows NT 4.0 und Windows 9x die Windows Installer-Version 2.0 zur Verfgung. Eine
Aufstellung aller Windows Installer-Versionen zeigt Tabelle 1.1.
14
Kapitel 1
Release
Version
Anmerkungen
Windows Installer 1.0
1.0.5104.0
Enthalten in Office 2000 und verffentlicht als

Installationspaket.
1.10.1029.0
Enthalten in Windows 2000.
1.10.1029.1
Verffentlicht als Installationspaket.
1.11.1314.0
Enthalten in Windows 2000 Service Pack 1.
1.11.2405.0
Enthalten in Windows 2000 Service Pack 2.
1.20.1410.0
Enthalten in Windows Millennium Edition.
1.20.1827.1
2.0.2600.0
Enthalten in Windows XP.
2.0.2600.1
Enthalten im Windows 2000 Service Pack 3.
2.0.2600.2
2.0.2600.1106
Enthalten in Windows XP Service Pack 1.
2.0.2600.1183
Enthalten im Windows 2000 Service Pack 4.
2.0.3754.0
Enthalten in Windows Server 2003.
3.0.3790.2180
Enthalten in Windows XP Service Pack 2 und verffentlicht

als Installationspaket.
3.1.4000.1823
3.1.4000.1830
Enthalten in Windows Server 2003 Service Pack 1.
3.1.4000.2435
Verffentlicht als Installationspaket. Behebt den in Q898628

beschriebenen Fehler.
4.0.6000.16386
Enthalten in Windows Vista.
4.0.6001.18000
Enthalten in Windows Vista Service Pack 1 und Windows

Server 2008.
4.5.6000.18000
Verffentlicht als Installationspaket fr Windows Vista.
4.5.6001.18000
Verffentlicht als Installationspaket fr Windows Vista

Service Pack 1, Windows Server 2008, Windows XP Service
Pack 2 und hher, Windows Server 2003 Service Pack 1 und
hher.
Tabelle 1.1: Verfgbare Versionen des Windows Installers
Heutige Anwendungsinstallationen sind durch den Umstand geprgt, dass sie vornehmlich auf der
Windows Installer-Technologie basieren. Die Begeisterung fr diese Technologie hat in den letzten
Jahren extrem zugenommen, so dass sie heute durchaus als State of the Art bezeichnet werden kann.
Derzeitig existieren aber auch noch andere Installationsformen, die als skriptbasierte
Installationssysteme umschrieben werden knnen. Ein hierauf beruhender Installationsprozess ist
dadurch gekennzeichnet, dass die Installationssoftware eine eigenstndige Anwendung darstellt, die
sowohl die Installationslogik als auch die Beschreibung der Installationsttigkeiten enthlt. Eine
15
Kapitel 1
eigenstndige Anwendung ist jedoch hinsichtlich des Zugriffs auf systeminterne Funktionen
beschrnkt und bietet auch nicht den Lsungsansatz fr ein systemweit konsistentes
Installationsspektrum. Jeder, der mit skriptbasierten Installationssystemen bereits zu tun hatte kennt die
Phnomene, dass durch die Deinstallation einer Anwendung eine andere Anwendung in einen nicht
funktionsfhigen Zustand versetzt wurde.
Die Windows Installer-Technologie beruht hingegen auf einer Trennung zwischen der
Installationslogik und der Beschreibung der Installationsttigkeiten. Die Installationslogik befindet sich
in einer Komponente des Betriebssystems, die als Windows Installer-Service bezeichnet wird. Der
Windows Installer-Service ist fr jede zu installierende Anwendung identisch und stellt damit sicher,
dass fr alle Installationen identische Regeln und Verfahren gelten. Er ist zudem das einzige Element
im Installationsprozess, das nderungen am System vornehmen kann. Die Beschreibung der
Installationsttigkeiten wird hingegen in einer Datei vorgenommen, die als Windows Installer-Paket
bezeichnet wird. Beim Windows Installer-Paket handelt es sich um den Baustein der Installation, der
den eigenen Vorgaben entsprechend angepasst werden kann. Das Paket enthlt eine Beschreibung der
durchzufhrenden Ttigkeiten und ebenfalls alle Ressourcen, die im Installationsprozess bentigt
werden.
Abbildung 1.1: Trennung von Code und Beschreibung beim Windows Installer
Durch die Verwendung einer Betriebssystemkomponente zur Installation und durch die Trennung der
Installationslogik von der Installationsbeschreibung wird die Stabilitt des Betriebssystems und der
Anwendungen in den Vordergrund gestellt. Darber hinaus bietet der Windows Installer weitere
interessante Funktionalitten, die ganz neue Mglichkeiten whrend der Installationsentwicklung und
im Installationsprozess erffnen. Diese Basisfunktionalitt des Installers lsst sich hierdurch bedingt
wie folgt skizzieren:
Transaktionalitt: Fr jede
durchgefhrt wird, wird
zurckzunehmen. Falls es
durchgefhrten nderungen
zurck versetzt.
Aktion, die vom Windows Installer zur Modifikation des Systems

eine gegenstzliche Aktion erzeugt um diese nderungen
zu einem Fehler whrend der Installation kommt, werden die
zurckgenommen und das System in den ursprnglichen Zustand
Selbstheilung: Wird zur Laufzeit der Anwendung festgestellt, dass eine als kritisch eingestufte
Datei (Schlsseldatei) oder ein unbedingt erforderlicher Schlssel der Systemregistrierung fehlt,
kann der Windows Installer diese Datei oder diesen Schlssel wieder herstellen. Dieses kann
sowohl automatisch beim Starten der Anwendung geschehen oder manuell vom Benutzer
16
Kapitel 1
veranlasst werden.
Installation bei Bedarf: Hierbei wird ein Bestandteil der Anwendung nur installiert, wenn es auch
tatschlich bentigt wird. Ein Beispiel dafr wre die Rechtschreibberprfung von Microsoft
Office oder die Online-Dokumentation einer beliebigen Anwendung. In beiden Fllen wird diese
Funktionalitt standardmig nicht mit installiert, erst wenn der Benutzer die Dokumentation
aufruft oder die Rechtschreibung berprft, wird sie automatisch installiert.
Installation in gesperrten Umgebungen: In gesperrten Umgebungen fehlen einem
Standardbenutzer im Normalfall die erforderlichen Privilegien zum Durchfhren einer Installation.
In dem meisten Fllen hat ein solcher Benutzer keinen Schreibzugriff auf den Ordner
%ProgramFiles% oder den Systemregistrierungsschlssel HKEY_LOCAL_MACHINE. Mit dem
Windows Installer ist eine Installation in gesperrten Umgebungen dennoch mglich, da ein
Systemadministrator entsprechende Autorisierungen vornehmen kann. Hierdurch werden die
erhhten Systemprivilegien des Windows Installers, anstelle der eingeschrnkten Rechte des
Standardbenutzers verwendet.
Status-Management: Durch den Windows Installer werden eine Vielzahl von Funktionen
angeboten, mit denen der Status des Systems und somit der Anwendung abgefragt werden kann.
Hiermit wird es mglich, den aktuellen Installationsstatus zu bestimmen, die Reparatur einer
Anwendung durchzufhren und eine Anwendung in einen anderen Status zu berfhren.
Einige dieser Funktionalitten werden im Rahmen dieses Buches betrachtet, andere wiederum nicht.
Dieses Buch zielt schwerpunktmig auf die neuen Funktionen und die genderten Ablufe bei den
Windows Installer-Versionen 4.0 und 4.5 ab und setzt Kenntnisse der Windows Installer-Technologie
voraus. Dennoch mchte ich in diesem Kapitel auf allgemeine Informationen, Ablufe und
Verhaltensweisen des Windows Installers eingehen, wobei diese generisch zu betrachten sind und
somit auf alle Versionen des Windows Installers projiziert werden knnen.

Beginnen mchte ich mit dem Windows Installer-Paket. Hierbei handelt es sich um das Element der
Windows Installer-Technologie, in dem die Intentionen des Setupentwicklers umgesetzt werden. Die
Betrachtung wird nach physischen und logischen Gesichtspunkten ausgefhrt. Die physische
Betrachtung zielt ausschlielich auf die interne Struktur und die enthaltenen Elemente ab. Die logische
Betrachtung zeigt den deklarativen Ansatz des Windows Installers zur Durchfhrung der tatschlichen
Installation.
Physische Betrachtung
Physisch betrachtet handelt es sich bei einem Windows Installer-Paket um ein Verbunddokument
(Compound Document). Dieses Dokumentformat lsst sich am einfachsten durch ein Dateisystem
innerhalb einer physischen Datei umschreiben, also um eine Datei, die aus Ordnern (Storages) und
Dateien (Streams) besteht. Die Struktur dieser Verbunddokumente wurde mit einer frhen Version von
Microsoft Office eingefhrt und sie bildete die Grundlage zur Speicherung von OLE-Informationen
(Object Linking and Embedding). Alle Versionen von Microsoft Office 1) verwenden noch immer
1
Microsoft Office 2007 untersttzt noch aus Kompatibilittsgrnden das Format, verwendet aber standardmig ein auf XML
17
Kapitel 1
dieses Format zum Speichern der Informationen.

Beim Windows Installer-Paket handelt es sich ebenfalls um ein solches Dokument, allerdings kann es
nicht mit Microsoft Word oder Microsoft Excel geffnet werden, obwohl die internen Strukturen
identisch sind. Diese interne bereinstimmung resultiert daher, da alle Verbunddokumente ber einen
einheitlichen Speicherbereich verfgen, der auch als Summary Information Stream bezeichnet wird. In
diesem Speicherbereich befindet sich unter anderem eine Kennzeichnung, mit der die Art des
Dokumentes bestimmt werden kann. Programmtechnisch ist es mglich den generischen
Datenspeicher eines jeden Verbunddokumentes zu ffnen und anhand der ermittelten Kennzeichnung
das Format des Dokumentes zu bestimmen, wie dieses in Listing 1.1 auch gezeigt wird.
internal static Guid GetStorageCLSID(string fileName)
{
// Prfen ob Storage-Datei
if (NativeMethods.StgIsStorageFile(fileName) == 0)
{
IStorage storage;
uint subOpenMode = (uint)(NativeMethods.STGM.READ | NativeMethods.STGM.SHARE_EXCLUSIVE);
int hr = NativeMethods.StgOpenStorage(fileName, IntPtr.Zero, subOpenMode,
IntPtr.Zero, 0, out storage);
if (hr == 0)
{
STATSTG statsg = new STATSTG();
storage.Stat(ref statsg, 0);
Guid clsid = statsg.clsid;
// Release
Marshal.ReleaseComObject(storage);
return clsid;
}
else
{
Marshal.ThrowExceptionForHR(hr);
return Guid.Empty;
}
}
else
{
throw new InvalidComObjectException("Keine Storage-Datei");
}
}
Listing 1.1: Bestimmung der Art eines Verbunddokumentes
Das Ergebnis des Funktionsaufrufs ist eine GUID, da in diesem Format die Kennzeichnungen definiert
werden. Die nachfolgende Tabelle 1.2 enthlt eine Auswahl von GUIDs, die zur Kennzeichnung von
Verbunddokumenten verwendet werden.
Art des Dokumentes
Kennzeichnung (GUID)
basierendes Format.
18
Word Dokument (97 2003)
{00020906-0000-0000-c000-000000000046}
Excel Workbook (97 2003)
{00020820-0000-0000-c000-000000000046}
Powerpoint Prsentation (97 2003)
{64818d10-4f9b-11cf-86ea-00aa00b929e8}
Windows Installer-Paket (.msi)
{000C1084-0000-0000-C000-000000000046}
Windows Installer-Patch (.msp)
{000C1086-0000-0000-C000-000000000046}
Windows Installer-Transformation (.mst)
{000C1082-0000-0000-C000-000000000046}
Kapitel 1
Tabelle 1.2: Arten von Verbunddokumenten (Auswahl )
Das Windows Installer-Paket ist so strukturiert, dass alle fr den Installationsprozess bentigten
Informationen und Ressourcen innerhalb einer Datei abgelegt werden knnen. Zu diesem Zweck
enthlt das Windows Installer-Paket die folgenden Datenspeicher:
Summary Information Stream
Relationale Datenbank
Direkte oder indirekte Quelldateien
Ressourcen fr die Installation (Optional)
Transformationen (Optional)
Der Summary Information Stream ist ein Speicherbereich, den alle Verbunddokumente enthalten. Er
enthlt zustzlich zur Kennzeichnung der Art des Dokuments noch allgemeine und spezifische
Informationen. Die allgemeinen Informationen sind ausschlielich beschreibender Natur und knnen
auch ber den Dateieigenschaftendialog des Windows Explorers abgerufen werden. Die spezifischen
Informationen sind von der Art des Dokumentes abhngig. Bei einem Word-Dokument fallen in diese
Kategorie die Anzahl der Wrter oder Zeichen. Bei einem Windows Installer-Paket ist die Version des
Windows Installers hierzu zu zhlen, die zur Installation auf dem Zielsystem vorhanden sein muss. Das
Windows Installer-Paket enthlt weiterhin eine relationale Datenbank, die aktuell aus mehr als 80
Tabellen besteht. Im Rahmen des Installationsprozesses werden die Inhalte dieser Datenbank vom
Windows Installer-Service verwendet, um das Produkt wie beabsichtigt auf dem System abzubilden.
Das Paket enthlt natrlich auch die zu installierenden Ressourcen, die sich direkt in der physischen
Datei befinden knnen. Es ist auch mglich die Ressourcen als Extern zu kennzeichnen, so dass das
Paket nur Referenzen darauf enthlt. Die gerade vorgestellten Datenspeicher mssen in jedem
Installationspaket vorhanden sein. Darber hinaus ist es mglich weitere optionale Elemente in das
Paket zu integrieren. Dieses knnen Ressourcen sein, die fr die Installation bentigt werden, wie
Bilder die in der Benutzeroberflche angezeigt werden oder auch eingebettete Windows InstallerTransformationen wie dieses auch in Abbildung 1.2 dargestellt wird.
19
Kapitel 1
Abbildung 1.2: Interne Struktur eines Windows Installer-Paketes

Wie bereits angedeutet handelt es sich beim Summary Information Stream um das Kernobjekt bei
Verbunddokumenten, dass fr die strukturierte Speicherung unerlsslich ist. Der Summary Information
Stream enthlt allgemeine Informationen zum Basisdokument, die ber den Dialog Eigenschaften des
Windows-Explorers betrachtet werden knnen. Zustzlich enthlt der Summary Information Stream
noch spezifische Informationen, die von der Art des Basisdokumentes abhngig sind. In einer Datei,
die fr die Windows Installer-Technologie erstellt wurde, sind diese Informationen fr die Festlegung
von Installationsoptionen notwendig. Hierbei handelt es sich u.a. um die Festlegung der
Verwendungsart der Quelldateien und die bentigte Windows Installer-Version, wie auch in
Abbildung 1.3 dargestellt wird.
20
Kapitel 1
Abbildung 1.3: Informationen im Summary Information Stream
Die Relevanz des Summary Information Streams ergibt sich aus der frhzeitigen Ermittlung der
Installationsfhigkeit eines Paketes, ohne auf spezifische Windows Installer-Funktionen angewiesen
sein zu mssen. Die ersten Ttigkeiten des Installationsprozesses erstrecken sich auf eine Prfung, ob
das jeweilige Paket auf der aktuellen Plattform tatschlich installiert werden kann. Zu diesem Zweck
mssen Informationen im Windows Installer-Paket abgelegt werden, die explizit festlegen, welche
Plattform-Architektur und welche Windows Installer-Version erforderlich sind, um das Paket
verwenden zu knnen. Wren diese Informationen in Speicherbereichen zu finden, die ausschlielich
ber Funktionalitten des Windows Installers zugnglich wren, knnte dieses zu einigen Problemen
fhren. Es msste vorausgesetzt werden, dass das Paket von der installierten Windows InstallerVersion geffnet werden kann und die entsprechenden Informationen ermittelt werden knnen. Der
effektivere Weg ist hierbei die Verwendung eines Speicherbereichs, auf den immer zugegriffen werden
kann, da ein Zugriff keine speziellen Windows Installer-Funktionen erfordert, sondern durch
allgemeine Windows-Funktionen realisiert werden kann. Nachdem hierdurch die erforderlichen
Informationen ermittelt wurden, ist es sehr einfach zu prfen, ob es sich um ein gltiges Paket fr die
jeweilige Plattform handelt. In diesem Fall knnen fr den weiteren Ablauf im Installationsprozess
problemlos die notwendigen Windows Installer-Funktionen verwendet werden.
Windows Installer-Datenbank
Die Windows Installer-Datenbank ist relational aufgebaut und enthlt eine Vielzahl von Tabellen. In
der Datenbank werden die zu installierende Ressourcen, die Darstellungsobjekte der
Benutzeroberflche und die Aktionen des Installationsprozesses definiert. Wie bei relationalen
Datenbanken blich, steht eine Vielzahl der Tabellen miteinander in Beziehung, die durch identische
21
Kapitel 1
Werte in den Primr- und Fremdschlsselfeldern der jeweiligen Tabellen realisiert wird.
Fremdschlsselfelder sind in den Tabellen daran zu erkennen, dass der Feldname mit einem
Unterstrich endet.
Abbildung 1.4: Beziehungen der Tabellen innerhalb einer Windows Installer-Datenbank (Auszug)
Bei der Betrachtung der Tabellenschemas in Abbildung 1.4 ist auffllig, dass einige Tabellennamen
mit dem Prfix Msi beginnen. Dieses ist darauf zurck zufhren, dass Tabellen mit diesem Prfix
versehen werden, die seit dem Windows Installer 2.0 dem Datenbankschema hinzugefgt wurden.
22
Kapitel 1
Internes Tabellenformat
Die interne Betrachtung der Tabellen bezieht sich zwangslufig wieder auf das Verbunddokument und
die strukturierte Speicherung der erforderlichen Objekte. Jede Tabelle der Windows InstallerDatenbank wird durch ein Storage-Objekt dargestellt und persistiert. Jedes Storage-Objekt enthlt
mehrere separate Stream-Objekte in denen die enthaltenen Tabellendaten, die Tabellendefinition und
die Indizes gespeichert werden. In der Tabellendefinition sind Informationen zu den Spaltennamen,
Datentypen und der Feldgre abgelegt. Die Primr- und Fremdschlssel werden ber die
Indexauflistung persistiert. Die tatschlichen Tabellendaten werden in einem zweidimensionalen Array
abgelegt, das allerdings ausschlielich Daten vom Typ Short Integer aufnehmen kann. Eine Vielzahl
der Informationen in einer Windows Installer-Tabelle ist vom Typ Short Integer, so dass diese
Informationen problemlos in das Array bertragen werden knnen. Daten vom Typ Long Integer,
wie die Spalte FileSize der Tabelle File, knnen hingegen nicht direkt in das Array bertragen werden,
da der bentigte Wertebereich berschritten wird. Solche Daten werden aus diesem Grund in zwei
zusammenhngenden Spalten des Arrays abgelegt. Da sich die gltigen Werte fr dieses Array
ausschlielich auf Ganzzahlen erstrecken, handelt es sich bei Null um einen ungltigen Wert. Um
solche Werte ebenfalls in dem Array zu speichern, wird Null durch den Wert 0x8000 dargestellt.
Zeichenfolgen knnen ebenfalls nicht direkt in das Array bertragen werden, so dass sie in einem
speziellen Speicherbereich abgelegt werden mssen, der als Stringpool bezeichnet wird. Die Elemente
des Stringpools werden ber einen Index identifiziert, der wiederum in das Array bertragen wird.
Speicherbereich fr Zeichenfolgen
Die Installationsdatenbank enthlt einen Speicherbereich mit der Bezeichnung _StringData, in dem die
Zeichenfolgen aller Tabellen abgelegt werden und der demzufolge von allen Tabellen der Datenbank
gemeinsam verwendet wird. Durch diesen Mechanismus wird jede Zeichenfolge nur einmal in der
Datenbank gespeichert, wodurch die Datenbankgre minimiert und die Performance optimiert wird.
Es existiert ein weiterer Speicherbereich der als _StringPool bezeichnet ist und in dem die Lnge der
Zeichenfolgen und die Referenzen jeder Zeichenfolge abgelegt sind.
Auf den gemeinsamen Speicherbereich kann ber den Index zugegriffen werden, wobei der Index 0
fr einen Null-String reserviert ist, der jedoch statisch ist und somit nicht im Stringpool abgelegt
werden muss. An Stelle der Zeichenfolgeninformationen fr den Index 0 wird hier die Codepage
gespeichert, die fr die Darstellung der Zeichenfolgen verwendet werden soll. Zur Vermeidung von
Problemen, die auf einer ungltigen Codepage basieren, sollten nur Zeichenfolgen verwendet werden,
die aus Zeichen der neutralen Codepage zusammengesetzt sind. Ist es erforderlich auf Zeichen des
erweiterten Zeichensatzes zuzugreifen, muss zur fehlerfreien Darstellung die passende Codepage
festgelegt werden.
Zur Anzeige von Textinformationen verwendet der Windows Installer die nachfolgenden Regeln zur
Ermittlung der Codepage und die darauf aufbauende Bestimmung der kompatiblen Schriftarten und
des Zeichensatzes:
Daten, die mit dem System verknpft sind (Dateien und Eintrge in der Systemregistrierung):
Die Codepage des Benutzers wird verwendet.
Zeichenfolgen der Windows Installer-Datenbank, wobei die Datenbank-Codepage nicht neutral
(0) ist: Die Codepage der Windows Installer-Datenbank wird verwendet.
Zeichenfolgen der Windows Installer-Datenbank, wobei die Datenbank-Codepage neutral ist:
Die Codepage des Benutzers wird verwendet.
Steuerelemente die statischen Text enthalten: Standardmig wird die Datenbank-Codepage
23
Kapitel 1
verwendet. Allerdings kann durch das Attribut UsersLanguage eines solchen Steuerelements die
Codepage des Benutzers verwendet werden.
Die Festlegung der Datenbank-Codepage kann bei der Erstellung des Installationspaketes erfolgen. Es
besteht auch die Mglichkeit diese nachtrglich zu verndern, wozu Tools wie Orca zu verwenden
sind.
Hinweis Beginn
Jede Windows Installer-Transformation verfgt ber einen eigenen Stringpool, so dass hierfr eine
eigene Codepage definiert werden kann. Whrend der Installation werden die Zeichenfolgen der
Datenbank unter Verwendung der Datenbank-Codepage dargestellt. Zur Darstellung der Zeichenfolgen
der Transformation wird hingegen die Codepage der Transformation verwendet.
Hinweis Ende
berprfen des Stringpools

Wie bereits dargestellt, verwendet der Windows Installer die Speicherbereiche _StringData und
_StringPool zum Speichern und Referenzieren der Zeichenfolgen einer Datenbank. Bei der
Verwendung von unterschiedlichen Speicherbereichen muss jedoch sichergestellt werden, dass die
enthaltenen Daten konsistent sind und die Zeichenfolgen fehlerfrei verwendet werden knnen.
Weiterhin ist zu erkennen, dass die nderung der Codepage erhebliche Auswirkungen auf die
Darstellbarkeit dieser Zeichenfolgen nehmen kann. Zur Vermeidung von Problemen, die auf den
gerade geschilderten Verhaltensmustern basieren, sollte vor der Auslieferung des Windows InstallerPaketes bzw. bei auftretenden Problemen der Stringpool berprft werden. Zur Durchfhrung der
Stringpool-Validierung befindet sich im Windows Installer-SDK das Tool msiinfo.exe. Verwenden Sie
die folgende Befehlszeile, um die berprfung durchzufhren:
msiinfo.exe <Pfad zur MSI-Datei> /D
Sollten bei der berprfung fehlerhafte Daten entdeckt werden, wird ein Identifikationsmerkmal der
Zeichenkette ausgegeben. Um die Zeichenkette bestimmen zu knnen, mssen Sie sich den Inhalt des
Stringpools ebenfalls anzeigen lassen. Verwenden Sie hierzu die folgende Syntax:
msiinfo.exe <Pfad zur MSI-Datei> /B /D
Im Rahmen der berprfung werden die gltige Verwendung des Referenzzhlers sowie ein
entsprechender Zeichenkettentest durchgefhrt.
Referenzzhlertest: Im Stringpool werden alle verwendeten Zeichenketten nur einmal abgelegt und
mit einer ID versehen. Es wird ebenfalls ein Zhler implementiert, der die Anzahl der Referenzen
enthlt. Im Rahmen der Stringpool-Validierung wird dieser Referenzzhler mit der tatschlichen
Anzahl der Zeichenketten verglichen. Bei einer Differenz dieser beiden Werte, wird eine
entsprechende Meldung angezeigt. Weist die geprfte Datenbank ein Problem hinsichtlich der
Referenzzhlung auf, knnen diese Inkonsistenz mit dem Tool msidb.exe behoben werden. Hierzu ist
die Datenbank mit dem erwhnten Tool zu ffnen und alle Tabellen sind zu exportieren. Danach ist
eine leere Datenbank zu erstellen in die alle Tabellen wieder zu importieren sind.
Achtung Beginn
24
Kapitel 1
Das Manipulieren von Daten einer Windows Installer-Datenbank, die ber eine inkonsistente
Referenzzhlung verfgt, kann zu erheblichen Datenverlusten fhren.
Achtung Ende
DBCS-Zeichenkettentest: Beim DBCS-Zeichenkettentest (Double Byte Character Set) wird jede

Zeichenfolge der Datenbank auf Inkonsistenz zu der verwendeten Codepage geprft. Bei Paketen mit
einer neutralen Codepage (Codepage = 0) wird geprft, ob Zeichen aus dem erweiterten Zeichensatz
(ASCII grer als 127) verwendet werden. Bei Paketen, die eine spezifische Codepage verwenden,
werden alle Zeichenketten auf Verwendung eines fr diese Codepage unzulssigen Zeichens geprft.
Sollte in Ihrem Windows Installer-Paket der DBCS-Zeichenkettentest ungltige Zeichenfolgen
aufzeigen, sollten Sie auf Zeichen des erweiterten Zeichensatzes bei Verwendung einer neutralen
Codepage verzichten oder eine spezifizierte Codepage verwenden. Das Ergebnis der Validierung wird
wie nachfolgend dargestellt, ausgegeben:
String ID size: 2
Code page: 0
String 3 has characters with high-bit set, but codepage is not set.
...
String 1585 has characters with high-bit set, but codepage is not set.
+++String Pool Entries+++
...
Id:
3 Refcnt:
1 String: Der Schlssel [2] ist ungltig.
...
Id: 1585 Refcnt:
1 String: String~1|Stringpool Test
Im ersten Bereich der Ausgabe finden Sie Hinweise auf die Zeichenketten, die in diesem Beispiel
Zeichen des erweiterten Zeichensatzes verwenden. Darunter folgt eine komplette Auflistung der
Zeichenketten des Stringpools mit der Anzahl der Referenzen und der IDs.
Installierbare Ressourcen
Die wesentliche Aufgabe im Rahmen der Installation erstreckt sich auf das Kopieren von Dateien auf
das Zielsystem. Hierzu ist es erforderlich, dass diese mit dem Installationspaket bereitgestellt werden.
Der Windows Installer bietet mehrere Mglichkeiten die zu installierenden Ressourcen in das
Windows Installer-Paket zu integrieren. Die Quelldateien knnen hierbei entweder im komprimierten
oder im nicht komprimierten Zustand verwendet werden. Auch eine Kombination dieser beiden
Optionen ist mglich. Die Einstellung ber die Art der verwendeten Quelldateien, sowie das Format
der Dateinamen wird ber die Eigenschaft PID_WORDCOUNT des Summary Information Streams
festgelegt.
Nicht komprimierte Quellen: Die Quelldateien werden in Ihrem nicht komprimierten Originalformat
verwendet und knnen sowohl mit kurzen (8.3) als auch mit langen Dateinamen benutzt werden. Die
Quelldateien werden in einer Ordnerstruktur abgelegt, die in der Tabelle Directory festgelegt werden
muss. Bei Verwendung von nicht komprimierten Quellen muss das Attribut fr komprimierte
Quelldateien aus der Eigenschaft PID_WORDCOUNT des Summary Information Streams entfernt oder
auf Dateiebene in der Tabelle File gesetzt werden.
Komprimierte Quellen: Bei der Verwendung von komprimierten Quelldateien, mssen sich diese in
einer Kabinett-Datei befinden. Dieses Kabinett kann entweder direkt in das Windows Installer-Paket
integriert oder als externe Datei verwendet werden. Bei der direkten Integration in das Windows
25
Kapitel 1
Installer-Paket wird die Kabinettdatei der Systemtabelle _Stream hinzugefgt. Bei der externen
Verwendung muss sich diese Datei im Stammverzeichnis der Ordnerstruktur der Dateiquelle befinden,
das in der Tabelle Directory definiert ist. Alle verwendeten Kabinettdateien mssen in der Tabelle
Media aufgelistet werden. Bei Verwendung von komprimierten Quellen muss das Attribut fr
komprimierte Quelldateien der Eigenschaft PID_WORDCOUNT des Summary Information Streams
hinzugefgt oder auf Dateiebene in der Tabelle File gesetzt werden.
Gemischte Verwendung: Sie knnen in einem Windows Installer-Paket auch komprimierte und nicht
komprimierte Quellen gemeinsam verwenden. Vergeben Sie in der Tabelle File das Attribut
msidbFileAttributesCompressed fr die Dateien, die im komprimierten Zustand, und das Attribut
msidbFileAttributesNoncompressed fr die Dateien, die im nicht komprimierten Zustand verwendet
werden sollen. Vergeben Sie dieses Attribut nur fr die Dateien, die von der Eigenschaft
PID_WORDCOUNT des Summary Information Stream abweichen. Wurde beispielsweise die
Eigenschaft PID_WORDCOUNT zur Verwendung von komprimierten Dateien gesetzt, mssen Sie fr
jede Datei, die im nicht komprimierten Zustand verwendet werden soll, das Attribut
msidbFileAttributesNoncompressed in der Tabelle File setzen. Diese Dateien mssen im
Stammverzeichnis, der in der Tabelle Directory definierten Ordnerhierarchie, abgelegt werden.
Erstellen von Kabinettdateien
Zur Verwendung von komprimierten Dateien mssen diese in einer Kabinettdatei gespeichert werden.
Groe Dateien knnen auf mehrere Kabinettdateien aufgeteilt werden. Bei einer solchen Aufteilung
drfen sich maximal 15 Dateien in einem Kabinett befinden, dass fortgesetzt wird. Werden
beispielsweise drei Kabinettdateien verwendet drfen das erste und das zweite Kabinett jeweils nur 15
Dateien enthalten. Die dritte Kabinettdatei ist hierdurch nicht eingeschrnkt, sondern muss die
generischen Limitierungen einhalten, die in Anhang C aufgefhrt sind.
Bei der Erstellung eines Installationspaketes werden die erforderlichen Kabinettdateien durch die
verwendeten Tools und Anwendungen normalerweise automatisch erzeugt. Fr manuelle Anstze
eignen sich Tools wie makecab.exe oder auch Visual Studio. Visual Studio stellt im Rahmen der Setup
und Weitergabeprojekte den Projekttyp CAB-Projekt hierfr zur Verfgung. Bei makecab.exe
handelt es sich um ein Befehlszeilentool fr diese Zwecke, dass im Windows Installer-SDK und im
Microsoft Cabinet Software Development Kit enthalten ist.
Verwenden von Kabinettdateien
Auch wenn die Erstellung der Kabinettdateien und die Verknpfung mit dem Installationspaket
automatisch erfolgen, mchte ich dennoch die erforderliche Vorgehensweise zur Erstellung eines
solches Archivs skizzieren. Weiterhin mchte ich auf die Beziehung zwischen dieser Datei und der
Windows Installer-Datenbank eingehen und die Mglichkeiten aufzeigen eine Kabinettdatei in ein
Windows Installer-Paket zu integrieren.
Verwenden Sie ein geeignetes Tool, um die Quelldateien zu komprimieren und diese in einer
Kabinettdatei zusammenzufassen.
Die Kabinettdatei muss entweder im Windows Installer-Paket oder zur externen Verwendung im
Stammverzeichnis der definierten Ordnerhierarchie gespeichert werden.
Legen Sie fest, ob alle Dateien im komprimierten Zustand verwendet werden sollen oder ob eine
gemeinsame Verwendung von komprimierten und nicht komprimierten Dateien fr Ihr Vorhaben
geeignet ist. Entsprechend mssen Sie das jeweilige Attribut in der Eigenschaft
PID_WORDCOUNT des Summary Information Streams setzen.
26
Kapitel 1
Fgen Sie fr jede in der Kabinettdatei enthaltene Datei, einen Datensatz der Tabelle File hinzu.
Verwenden Sie als Schlssel in der Tabelle exakt den gleichen Namen, unter dem diese Datei auch
in der Kabinettdatei gespeichert ist. Beachten Sie, dass der Schlssel zwischen Gro- und
Kleinschreibung unterscheidet. Stellen Sie sicher dass die Sequenznummer in der Tabelle File
identisch ist, mit der Sequenz im Kabinett.
Fgen Sie fr jedes verwendete Kabinett einen Datensatz der Tabelle Media hinzu. Legen Sie den
Wert fr das Feld DiskID fest; beachten Sie, dass dieser Wert grer ist als der hchste Wert der
bereits erfassten Datenstze dieser Tabelle. Geben Sie den Namen der Kabinettdatei in das
entsprechende Datenfeld ein. Beachten Sie, dass Sie bei der Verwendung eines internen Kabinetts,
dem Kabinettnamen das Zeichen # voranstellen mssen. Bei der Namensvergabe bei internen
Kabinettdateien muss die Gro- und Kleinschreibung beachtet werden. Bei der Verwendung von
externen Kabinettdateien ist dies nicht der Fall.
Bestimmen Sie die grte Sequenznummer, indem Sie die Spalte Sequence der Tabelle File
berprfen. Geben Sie diesen Wert in das Feld LastSequence der Tabelle Media ein.
Im letzten Schritt muss die Kabinettdatei in das Windows Installer-Paket integriert werden. Hierzu
bietet sich die Verwendung von Tools aus dem Windows Installer-SDK an. Verwenden Sie zu
diesem Zweck das Tool msidb.exe. Um eine Kabinettdatei mit der Bezeichnung cab1.cab in ein
Installationspaket mit der Bezeichnung rtm.msi zu integrieren, ist der folgende Befehl zu
verwenden:
msidb.exe -d rtm.msi -a cab1.cab
Hierbei wird die Kabinettdatei unter der Bezeichnung cab1.cab in einem Speicherbereich des
Windows Installer-Paketes abgelegt.
Tipp Beginn
Das Windows Installer-SDK enthlt die Skriptdatei WiMakCab.vbs, die es ermglicht, eine
Kabinettdatei auf Grundlage der Informationen eines Windows Installer-Paketes zu erstellen.
Tipp Ende
Zusammenspiel der Kabinettdatei mit der Datenbank

Die Tabelle File enthlt eine komplette Liste aller Dateien fr die Installation. Diese Dateien knnen
entweder im nicht komprimierten Zustand gespeichert oder komprimiert in Form einer Kabinettdatei
abgelegt werden. Die Sequenznummern der Tabelle File legen in Verbindung mit dem Feld
LastSequence der Tabelle Media die Installationsreihenfolge fest, und definieren das Quellmedium, in
dem die Dateien enthalten sind. Jeder Datensatz der Tabelle Media stellt ein Quellmedium dar, das die
Dateien enthlt, deren Sequenznummer kleiner oder gleich des Wertes LastSequence des aktuellen
Mediums und grer als der Wert LastSequence des vorherigen Mediums ist. Bei der Verwendung von
nicht komprimierten Dateien, die sich auf einem Medium befinden, braucht die Sequenz in der Tabelle
File keine eindeutigen Werte aufweisen.
Hinweis Beginn
Die maximale Anzahl von Dateien, die in der Tabelle File angegeben werden knnen ist 32.767. Zur
Erstellung grerer Pakete mssen Modifikationen an der Datenbankstruktur vorgenommen werden.
Hinweis Ende
27
Kapitel 1
Zur Verdeutlichung mchte ich das folgende Beispiel verwenden. Zur Verwendung sollen zwei
Quellmedien kommen, wobei auf Disk 1 nicht komprimierte Dateien und eine Kabinettdatei und auf
Disk 2 lediglich eine nicht komprimierte Datei zu finden sind. In diesem Fall mssen die nicht
komprimierten Dateien und die Dateien des Kabinetts kleinere Sequenznummern aufweisen, als die
Dateien auf Disk 2. Die Tabelle Media dieses Beispiels ist in Tabelle 1.3 dargestellt.
DiskId
LastSequence
DiskPrompt
10
15
Cabinet
VolumeLabel
Disk 1
cab1.cab
Disk 1
Disk 2
Tabelle 1.3: Beispieltabelle Media bei gemischter Verwendung
Die Zuordnung der Dateien zu einem Medium wird durch die Sequenznummern realisiert, die in der
Spalte Sequence der Tabelle File festgelegt werden.
File
Sequence
F1
F2
F3
F4
11
Tabelle 1.4: Ausschnitt der Beispieltabelle File
Die Betrachtung der gerade dargestellten Tabellen ergibt, dass sich die Dateien F1 und F2 im nicht
komprimierten Zustand auf dem Quellmedium Disk 1 befinden. Die Datei F3 befindet sich in der
externen Kabinettdatei cab1.cab ebenfalls auf Disk 1. Die Datei F4 befindet sich hingegen im nicht
komprimierten Zustand auf Disk 2.
Logische Betrachtung
Die physische oder interne Betrachtung eines Installationspaketes bezieht sich immer auf die
notwendigen Ressourcen oder Einstellungen, die zur Durchfhrung des Installationsprozesses bentigt
werden. Die logische Sichtweise ermglicht hingegen die strukturierte Gestaltung des
Installationspaketes. Eine logische Betrachtung ist erforderlich, um die nachfolgenden Fragen zu
beantworten, die Grundlage eines jeden Installationsdesigns sein sollten. Dieses ist in sofern relevant,
da bei der Durchfhrung der Installation ein deklarativer Ansatz gefahren wird. Das bedeutet, dass im
Installationspaket nicht beschrieben wird, wie bestimmte Szenarien umgesetzt werden sollen, sondern
lediglich das Ergebnis der Installation modelliert wird.
Was soll alles installiert werden?
Welche Abhngigkeiten bestehen zwischen den zu installierenden Elementen?
Sind alle Elemente zur Programmausfhrung notwendig oder kann der Benutzer bestimmte
Programmteile optional installieren?
Die Beantwortung der Fragen ist in vielen Fllen nicht trivial, da im Entwicklungsprozess viele
Informationen zum Zeitpunkt der logischen Grundgestaltung des Installationspaketes noch nicht
vorliegen. Zu diesem Zweck verwendet der Windows Installer zur strukturierten Gestaltung des
28
Kapitel 1
Installationspaketes ein uerst flexibles und erweiterbares Modell, das auf mehreren logischen
Kategorien basiert.
Ressourcen
Ressourcen sind alle Objekte, die whrend des Installationsprozesses dem Zielsystem hinzugefgt
werden knnen. Hierzu zhlen Dateien, Registrierungseintrge, Dateiverknpfungen, ODBCDatenquellen, Betriebssystemdienste und andere vergleichbare Objekte. Eine besondere Art von
Ressourcen stellen die so genannten Aktivierungspunkte (Entry Points) dar. Hierbei handelt es sich um
eine besondere Art von Ressource, die fr die Installation bei Bedarf und die Selbstheilung bentigt
werden, wie auch Anhand D verdeutlicht. Zu den Aktivierungspunkten gehren:
Dateiverknpfungen
Dateinamenerweiterungen
CLSID
Die Installation bei Bedarf wird durch eine Benutzeraktion ausgelst. Der Benutzer aktiviert
beispielsweise eine Dateiverknpfung, die whrend des Installationsvorganges zur Installation bei der
ersten Verwendung markiert worden ist. In diesem Fall handelt es sich bei der Dateiverknpfung um
den Aktivierungspunkt, der die Installation der entsprechenden Ressourcen veranlasst. Ein
Aktivierungspunkt ist immer mit einem Feature verknpft, so dass bei einer Aktivierung immer die
Ressourcen des jeweiligen Features installiert werden.
Komponenten
Bei den Windows Installer-Komponenten handelt es sich um Elemente, die die grundlegenden
Informationen fr die Installation enthalten. Eine Komponente fasst Dateien, Registrierungseintrge,
Verknpfungen und weitere Ressourcen zu einer logischen Einheit zusammen, die nur gemeinsam
installiert und deinstalliert werden knnen. Komponenten sind fr den Endanwender nicht sichtbar.
Eine Versionsberprfung wird immer gegen Komponenten ausgefhrt, so dass Sie sicherstellen
sollten, dass eine Ressource niemals von mehr als einer Komponente verwendet wird. Soll eine Datei
von mehreren Anwendungen genutzt werden, sollte die entsprechende Komponente in ein Windows
Installer-Mergemodul ausgelagert werden, so dass jedes Installationsprogramm die gleichen
Installationsoptionen dafr verwendet.
Eine Komponente wird immer vollstndig installiert oder deinstalliert. Komponenten enthalten keine
Versionskennungen, so dass eine Ressource dieser Komponente entsprechende Informationen zur
Verfgung stellen muss. Eine Datei, die diese Informationen fr die Komponente bereitstellt, wird als
Schlsselressource bezeichnet. Das Festlegen einer solchen Datei erfolgt ber die
Komponenteneigenschaft KeyPath. Typischerweise wird fr diese Schlsselressource eine Datei
verwendet; es knnen jedoch auch Registrierungseintrge und ODBC-Datenquellen verwendet werden.
Als Installationspfad der Komponente wird immer der Pfad zu der Schlsselressource zurckgegeben.
Der Windows Installer-Dienst prft das Vorhandensein der Schlsselressource, um den
Installationsstatus der Komponente festzustellen. Wird die Schlsselressource nicht gefunden, handelt
es sich aus Sicht des Windows Installers um eine fehlerhafte Komponente und die Reparatur wird
automatisch gestartet.
Das fehlerfreie Verwalten von Anwendungen, also die Installation, Deinstallation und das Einspielen
von Updates setzt eine gewisse Disziplin im Umgang mit Komponenten voraus. Komponenten sind die
kleinste installierbare Einheit einer Installation. Ressourcen werden in Komponenten zusammengefasst
29
Kapitel 1
und diese werden durch eine eindeutige ID gekennzeichnet, die als ComponentId bezeichnet wird. Bei
dieser ID handelt es sich um eine GUID, wodurch die Eindeutigkeit garantiert wird. Komponenten mit
identischer ComponentId mssen identische Ressourcen beinhalten, um eine effektive Verwaltung
bereits installierter Ressourcen seitens des Windows Installers zu gewhrleisten. Wird eine
existierende Komponente verndert, sei es durch das Austauschen, Hinzufgen oder Entfernen einer
Datei oder des Festlegens eines anderen Standardzielverzeichnisses muss die ComponentId verndert
werden. Aus Sicht des Windows Installers handelt es sich dann um eine neue Komponente.
Im Gegensatz zu anderen Installationstechnologien verwaltet der Windows Installer niemals Dateien
oder andere Ressourcen direkt. Der Windows Installer-Dienst verwaltet Anwendungen auf Basis der
Komponenten, was bedeutet, dass zwei Ressourcen, die in einer Komponente zusammengefasst sind,
niemals separat installiert oder deinstalliert werden knnen. Die berwachung von Komponenten, die
von mehreren Anwendungen verwendet werden, wird nicht durch Referenzzhler vorgenommen. Der
Windows Installer speichert fr jede Komponente die Identifikationsmerkmale der Produkte, von
denen diese verwendet wird. Die Komponente wird erst vom Computer entfernt, wenn kein Produkt
diese Komponente mehr verwendet. Die berwachung installierter Ressourcen ist durch diese
Vorgehensweise nicht nur auf Dateien beschrnkt, sondern erstreckt sich auf beliebige Ressourcen.
Windows Installer-Komponenten werden in der Tabelle Component der Windows Installer-Datenbank
definiert.
Features
Ein Windows Installer-Feature ist die kleinste installierbare Einheit aus Sicht des Benutzers. Bei den
Features handelt es sich um eine Zusammenfassung von Windows Installer-Komponenten, die der
Benutzer einzeln zur Installation auswhlen kann. Whlt ein Anwender die benutzerdefinierte
Installationsoption, wird ein Dialogfeld zur Auswahl der zu installierenden Programmelemente
dargestellt. Jedes hier aufgelistete Element korrespondiert mit einem Windows Installer-Feature. Ein
Feature kann auch weitere Features enthalten, wodurch es ermglicht wird, ein installierbares Produkt
hierarchisch zu gliedern. Das Installationspaket von Microsoft Office enthlt beispielsweise ein
Feature mit der Bezeichnung Korrekturhilfen, das wiederum untergeordnete Features fr
verschiedene Sprachen enthlt. Falls ein Benutzer ein solches Feature zur Installation markiert, werden
alle zugeordneten Windows Installer-Komponenten installiert. Die folgende Abbildung 1.5 stellt diese
Auswahlmglichkeit dar,
30
Kapitel 1
Abbildung 1.5: Windows Installer-Features in Microsoft Office 2007
Wie bereits an vorheriger Stelle verdeutlicht, werden alle Verwaltungsaufgaben des Windows
Installers auf Komponentenebene durchgefhrt. Auf Basis dieser Implementierung ist es nicht
erforderlich, eindeutige Windows Installer-Features zu definieren, vielmehr besteht die Mglichkeit
eine Komponente einem oder mehreren Features zuzuordnen. Dieses ist uerst relevant, denn eine
ordentlich konzipierte Feature - Komponentenstruktur stellt die Basis fr robuste und erweiterbare
Windows Installer-Pakete dar.
Produkt
Ein Windows Installer-Produkt stellt eine einzelne Anwendung wie Microsoft Project oder eine
Gruppe von Anwendungen wie Microsoft Office dar. Produkte bestehen aus einem oder mehreren
Windows Installer-Features und stellen somit die grte installierbare Einheit dar. Produkte werden
durch die Eigenschaft ProductName bezeichnet und durch einen eindeutigen ProductCode
identifiziert. Bei dem ProductCode handelt es sich ebenfalls um eine GUID, die in der Tabelle
Property der Windows Installer-Datenbank abgelegt ist.
Ein Produkt ist eine Gruppierung von Features, und somit natrlich auch eine Sammlung von
Windows Installer-Komponenten, die wiederum aus Ressourcen zusammengesetzt sind. Abbildung
1.6 enthlt einen Teilausschnitt aus der logischen Struktur des Installationspaketes von Microsoft
Office 2007. In dieser Abbildung ist das Zusammenspiel der Features und Komponenten sehr gut zu
erkennen. Es existiert hierbei eine gemeinsame Komponente, die automatisch bei der Auswahl eines
der bergeordneten Features installiert wird. Im Weiteren sind die unterschiedlichen Sichtweisen
erkennbar. Die Komponenten mit den enthaltenen Ressourcen spiegeln die Sichtweise des Entwicklers
des Installationspaketes wieder. Das Produkt und die untergeordneten Features reprsentieren letztlich
31
Kapitel 1
die Sicht des Benutzers, da dieser daran nderungen vornehmen kann.
Abbildung 1.6: Logische Betrachtung eines Installationspaketes
Bei der Installation eines Produktes wird der Auswahlstatus der Features geprft, und letztlich die
zugeordneten Komponenten installiert. Bei der Installation der Windows Installer-Komponenten wird
geprft, ob sich diese bereits auf dem System befinden. Ist dies der Fall, wird der ProductCode des zu
installierenden Produkts der Auflistung der Produkte, die diese Komponente verwenden, hinzugefgt.
Ist die Komponente noch nicht installiert, wird fr die Komponente ein Eintrag in die
Systemregistrierung geschrieben, und der ProductCode diesem Eintrag angefgt. Bei der
Deinstallation wird der ProductCode von den entsprechenden Komponenten entfernt und diese ggf.
gelscht. Der ProductCode wird vom Windows Installer auch bentigt um festzustellen, ob dieses
Produkt bereits auf dem System installiert wurde. Die installierten Produkte werden ebenfalls unter
einem Registrierungsschlssel gespeichert.
Hinweis Beginn
Bei der Erstellung eines Installationspaketes und der Konstruktion einer Feature- und
Komponentenstruktur sind bestimmte Limitierungen zu beachten, die in Anhang C aufgezeigt sind.
Hinweis Ende

Im Installationspaket ist in erster Linie das finale Ergebnis der Installation modelliert. Darber hinaus
enthlt es aber auch Informationen, die festlegen, auf welche Weise dieses Endergebnis erreicht
32
Kapitel 1
werden soll. Zur Auswertung dieser Informationen und der letztlichen Umsetzung wird schlielich der
Windows Installer-Service bentigt. Wie bereits angedeutet handelt es sich hierbei um einen
Betriebssystemdienst, der fr die Installation, Deinstallation, Modifikation und Aktualisierung von
Anwendungen bentigt wird. Dieser Betriebssystemdienst trgt die Bezeichnung MSIServer und
wird im Wesentlichen durch die ausfhrbare Datei msiexec.exe reprsentiert. Der Dienst wird nicht
automatisch vom System gestartet, sondern muss manuell durch einen Aktivierungsmechanismus
aufgerufen werden. Diese Aktivierung kann auf unterschiedliche Arten erfolgen:
Durch die Verwendung der Befehlszeilenoptionen des Windows Installers.
Durch das Doppelklicken auf eine MSI-Datei oder MSP-Datei, da diese Dateinamenerweiterungen
mit dem Windows Installer verknpft sind.
Durch die Funktionen der Programmierschnittstelle des Windows Installers.
Durch Softwareverteilungstechnologien wie Microsoft Systems Management Server (SMS) und
Microsoft System Center Configuration Manager (SCCM) oder die auf Gruppenrichtlinien
basierenden Technologien, die in Windows 2000 Server, Windows Server 2003 und Windows
Server 2008 integriert sind (Active Directory).
Durch die Option Software der Systemsteuerung von Windows 2000, Windows XP, Windows
Server 2003, Windows Vista und Windows Server 2008.
Durch Anwendungen, die Windows Installer-Technologien direkt nutzen.
Unabhngig davon, auf welche Weise der Windows Installer aufgerufen und somit der
Installationsprozess gestartet wurde, wird beim Aufruf immer eine Referenz auf das zu verwendende
Installationspaket bergeben. Die ersten Schritte im Installationsprozess erstrecken sich auf die
Auswertung der Informationen des Summary Information Streams. So wird an dieser Stelle zunchst
geprft, ob das Installationspaket auf dem aktuellen System berhaupt verwendet werden kann, indem
die definierte Version des Windows Installers und die jeweilige Plattform-Architektur auf
bereinstimmung geprft werden. Im Anschluss wird das Installationspaket in den Arbeitsspeicher
geladen, so dass direkt auf die notwendigen Informationen der Windows Installer-Datenbank
zugegriffen werden kann. Nachfolgend werden nun die Aufrufparameter ausgewertet und darber
hinaus geprft, ob sich das Produkt bereits auf dem System befindet. Anhand dieser Informationen
wird die tatschliche Installationsart festgelegt. In Abhngigkeit zu der ermittelten Installationsart
werden Windows Installer-Patches und Windows Installer-Transformationen auf das Paket
angewendet, weitere Systemkonfigurationen geprft und schlielich die in der Windows InstallerDatenbank definierten Installationsabfolgen ausgefhrt.
Dieser sehr schematische Installationsablauf wird an spterer Stelle in diesem Kapitel weiter przisiert.
Allerdings sind diese Informationen fr den Moment ausreichend um die Aufrufmglichkeiten der
einzelnen Installationsarten zu erlutern.
Clientinstallation
Die Clientinstallation ist die am hufigsten verwendete Installationsart. Es handelt sich hierbei um den
bekannten Prozess, in dem Ressourcen vom Quellmedium auf den Zielcomputer bertragen werden,
mit dem Ziel eine funktionsfhige Anwendung zu erhalten. Eine spezielle Form der Clientinstallation
ist der Wartungsmodus. In diesen Modus wird automatisch verzweigt, falls eine Clientinstallation
gestartet wird und das jeweilige Produkt auf dem System bereits vorhanden ist. Der Wartungsmodus
wird ebenfalls verwendet, falls eine Aktualisierung des Produktes ausgefhrt, eine Reparatur des
Produktes veranlasst oder das Produkt deinstalliert wird. Im Installationsprotokoll lsst sich eine
33
Kapitel 1
Clientinstallation am einfachsten an der Eigenschaft ACTION erkennen, die bei dieser Installationsart
ber den Wert INSTALL verfgen muss.
Property(S): ACTION = INSTALL
Wird eine Clientinstallation von einem administrativen Installationspunkt ausgefhrt (Post-AdminInstall), so wird whrend der Installation die Eigenschaft IsAdminPackage auf den Wert 1 festgelegt.
Diese Information kann ebenfalls der Eigenschaftsauflistung des Installationsprotokolls entnommen
werden.
Basisinstallation
Zum Durchfhren einer Clientinstallation ist dem Befehlszeilenaufruf das Argument /i (Install) oder
/package anzufgen. In beiden Fllen ist zustzlich eine Referenz auf das zu verwendende
Installationspaket erforderlich. Bei einer Basisinstallation ist hierzu der vollstndige Pfad zum
Installationspaket nach dem folgenden Schema zu verwenden. Diese Referenz kann auch als UNCName (Universal Naming Convention) oder als URL (Uniform Resource Locator) bergeben werden.
Ein Doppelklick auf eine MSI-Datei resultiert immer in einer Basisinstallation, da durch die
Erweiterungen der Windows-Shell automatisch diese Argumente gesetzt werden.
msiexec.exe /i <Pfad zum Installationspaket>
msiexec.exe /package <Pfad zum Installationspaket>
Im Installationsprotokoll ist die Durchfhrung einer Basisinstallation anhand der nachfolgenden
Eintragungen zu erkennen:
MSI (s) (40:54) [15:58:41:665]: Product not registered: beginning first-time install
MSI (s) (40:54) [15:58:41:665]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'.
Die dargestellten Befehlszeilenaufrufe knnen noch weiter qualifiziert werden, um den

Installationsprozess zustzlich zu beeinflussen. Weiterhin knnen zustzliche Argumente angefgt
werden, um die Darstellungsform der Benutzeroberflche zu definieren. Der Windows Installer
untersttzt vier Ebenen zur Darstellung der Benutzeroberflche. Diese Ebenen sind wie folgt definiert:
None: Installation ohne Benutzeroberflche (Unbeaufsichtigter Modus).
Basic: Zeigt nur die Fortschrittsanzeige und Fehlermeldungen. Die Darstellung erfolgt durch
Dialoge, die vom Windows Installer zur Verfgung gestellt werden und sich in der der msi.dll
befinden.
Reduced: Es werden nur die nicht modalen Dialoge, der im Installationspaket definierten
Oberflche, verwendet.
Full: Zeigt alle Dialoge und die Fortschrittsanzeigen. Hierbei wird die im Paket definierte
Benutzeroberflche verwendet.
Die Darstellungsformen und die in Tabelle 1.5 aufgefhrten Mglichkeiten der Festlegung sind nicht
nur auf die Clientinstallation beschrnkt sondern gelten fr andere Installationsformen entsprechend.
Argument
Beschreibung
/q, /qn oder /quit
Installation ohne Benutzeroberflche (Unbeaufsichtigter Modus).
34
Kapitel 1
/qn+
Zeigt nur einen Dialog am Ende der unbeaufsichtigten Installation.
/qb
Verwendet die Basisdarstellung. Die Option /qb! kann verwendet werden, um die
Schaltflche Abbrechen zu deaktivieren. Anstelle von /qb! kann auch /passive
verwendet werden, wobei zustzlich der Eigenschaft REBOOTPROMPT der Wert S
zugewiesen wurde.
/qb+
Verwendet die Basisdarstellung und zeigt einen Dialog am Ende der Installation. Der
Dialog wird nicht angezeigt, wenn der Anwender die Installation abbricht. Die Optionen
/qb+! oder /qb!+ knnen verwendet werden, um die Schaltflche Abbrechen zu
deaktivieren.
/qb-
Verwendet die Basisdarstellung allerdings ohne modale Dialoge. Das bedeutet, dass nur
die Fortschrittsanzeige angezeigt wird. Beim Auftreten von Fehlern oder Warnungen
wird kein Dialog angezeigt, sondern die Informationen dem Protokoll (falls verwendet)
angefgt. Die Optionen /qb-! oder /qb!- knnen verwendet werden, um die
Schaltflche Abbrechen zu deaktivieren.
/qr
Verwendet die reduzierte Benutzeroberflche. Ein Dialog am Ende der Installation wird
nicht angezeigt.
/qf oder ohne
Verwendet die vollstndige Benutzeroberflche.
Tabelle 1.5: Argument zur Darstellung der Benutzeroberflche
Eine Basisinstallation kann auch programmtechnisch durchgefhrt werden, indem die Funktion
MsiInstallProduct() der Windows Installer-Programmierschnittstelle aufgerufen wird. Die Darstellung
der Benutzeroberflche kann in diesem Zusammenhang durch MsiSetInternalUI() festgelegt werden.
Wartungsmodus
Als Ergnzung zu der Clientinstallation verfgt der Windows Installer ber die Mglichkeit,
nachtrgliche Modifikationen an der installierten Basis vorzunehmen. Diese Modifikationen knnen
sich auf drei Bereiche erstrecken:
Der Anwender mchte neue Programmteile hinzufgen oder bereits installierte Teile entfernen.
Der Anwender mchte die Anwendung reparieren, da diese ein Problem verursacht.
Der Anwender mchte die Anwendung deinstallieren.
Diese drei Mglichkeiten sind unter dem Begriff der Wartungsmodus oder Maintenance Installation
zusammengefasst. In den Wartungsmodus wird automatisch verzweigt, falls die Installation nach dem
vorherigen Schema gestartet wird und das Produkt sich bereits auf dem System befindet. Optional
kann hierbei anstelle des Pfades zum Installationspaket auch der ProductCode des jeweiligen
Produktes angegeben werden. Darber hinaus ist es auch mglich, eine Reparatur oder eine
Reinstallation des Produktes ber einen Befehlszeilenaufruf zu starten, der letztlich wieder im
Wartungsmodus mndet. Der Reparaturmodus wird hierbei durch das Argument /f (Fix) eingeleitet
und um die durchzufhrenden Reparaturoptionen ergnzt wird.
msiexec.exe /f[Reparatur Optionen] <Pfad zum Paket oder ProductCode>
Die Festlegung der Reparaturoptionen wird durch eine Verkettung der in Tabelle 1.6 dargestellten
Zeichen ermglicht.
35
Kapitel 1
Argument
Beschreibung
Ausschlieliche Reinstallation der fehlenden Dateien.
Reinstallation, wenn eine Datei fehlt oder in einer lteren Version vorliegt.
Reinstallation von fehlenden Dateien oder von Dateien, deren Versionsnummer kleiner oder
gleich ist.
Reinstallation von fehlenden Dateien oder von Dateien mit abweichenden Versionsnummern.
Reinstallation von fehlenden Dateien oder von Dateien, bei denen die gespeicherte Checksumme
nicht mit dem berechneten Wert bereinstimmt. Dies gilt nur fr Dateien, bei denen das Attribut
msidbFileAttributesChecksum in der Tabelle File gesetzt worden ist.
Reinstallation aller Dateien ohne Beachtung der Versionen und Checksummen.
Wiederherstellung aller benutzerspezifischen Registrierungseintrge unter

HKEY_CURRENT_USER und HKEY_USERS.
Wiederherstellung aller computerspezifischen Registrierungseintrge unter

HKEY_LOCAL_MACHINE und HKEY_CLASSES_ROOT. Schreiben aller Informationen der
Tabellen Class, Verb, PublishComponents, ProgID, MIME, Icon, Extension und AppID.
Reinstallation aller qualifizierten Komponenten.
Reinstallation aller Verknpfungen im Startmen.
Erzwingt das erneute Ausfhren vom Originalmedium und aktualisiert das im Cache vorhandene
Windows Installer-Paket.
Tabelle 1.6: Befehlszeilenargumente zur Reparatur einer Installation
Die Reparatur eines Produktes kann darber hinaus durch die Funktion MsiReinstallProduct() der
Windows Installer-Programmierschnittstelle realisiert werden. Weiterhin ist es mglich, durch
Optionen innerhalb des Dialogs Software der Systemsteuerung, die Reparatur eines installierten
Produktes durchzufhren. In diesem Fall wird die Reparatur unter Verwendung der Optionen
ocmusv ausgefhrt.
Die Verwendung des Wartungsmodus lsst sich anhand des Installationsprotokolls feststellen. Die
relevanten Eintragungen sind in den Protokolleintrgen des Server-Prozesses zu finden. Diese sind an
dem Prfix MSI (s) zu erkennen. Die verwendeten Reparaturoptionen knnen der Eigenschaft
REINSTALLMODE entnommen werden, die dem Eintrag mit dem Prfix Command Line: angefgt
ist. Weiterhin werden sie auch in der Eigenschaftsauflistung am Ende des Protokolls angezeigt. Ein
weiterer wichtiger Indikator ist die Eigenschaft REINSTALL. Diese enthlt die Auflistung an Features,
die repariert werden sollen oder die Zeichenfolge ALL, die die Reparatur aller Features
kennzeichnet. Dieses ist darauf begrndet, dass eine Reparatur oder Reinstallation immer auf Ebene
der Features und nicht der Komponenten durchgefhrt wird. Dieses Verfahren basiert auf der
Annahme, dass ein Feature ein in sich konsistentes Gebilde ist, so dass die enthaltenen Elemente
bereinstimmen mssen. Das vornehmste Ziel einer Reparatur ist das Versetzen der Anwendung in
einen funktionsfhigen Zustand, wobei diese Annahme zu bercksichtigen ist.
MSI (s) (40:68) [16:13:17:751]: Command Line: REINSTALL=ALL REINSTALLMODE=omus CURRENTDIRECTORY=D:\Setup
CLIENTUILEVEL=2 CLIENTPROCESSID=1704
Property(S): REINSTALLMODE = omus
Property(S): REINSTALL = ALL
36
Kapitel 1
Der Wartungsmodus ist darber hinaus explizit durch die Zeichenfolge entering maintenance mode
gekennzeichnet.
MSI (s) (40:68) [16:13:17:751]: Product registered: entering maintenance mode
MSI (s) (40:68) [16:13:17:751]: PROPERTY CHANGE: Adding ProductState property. Its value is '5'.
Sie erhalten sogar die notwendigen Informationen, ob das Produkt im Benutzer- oder
Maschinenkontext installiert wurde. Hierzu jedoch mehr im Kapitel 5.
MSI (s) (40:68) [16:13:17:752]: Determined that existing product (either this product or the product being
upgraded with a patch) is installed per-machine.
Interessant ist auch die Eigenschaft Installed, die das Installationsdatum des Produktes enthlt.
Property(S): Installed = 2008/09/01 16:13:17
Hinweis Beginn
Die Reparaturmglichkeit eines Produktes durch die Optionen im Dialog Software kann nur
angewendet werden, falls bei der Produktinstallation die Eigenschaft ARPNOREPAIR nicht gesetzt
wurde.
Hinweis Ende
Deinstallation
Die Deinstallation eines Produktes wird durch die Argumente /x oder /uninstall realisiert, wobei
die Referenz auf das Produkt durch die Pfadangabe zum Installationspaket oder den ProductCode
festgelegt werden kann.
msiexec.exe /x <Pfad zum Installationspaket oder ProductCode>
msiexec.exe /uninstall <Pfad zum Installationspaket oder ProductCode >
Die Deinstallation eines Produktes ist ebenfalls anhand des Installationsprotokolls zu erkennen. Der
relevante Eintrag wird wiederum vom Server-Prozess erstellt und durch den Prfix Command Line:
eingeleitet. Das wesentliche Argument ist hierbei die Eigenschaft REMOVE, die auf den Wert ALL
festgelegt wird.
MSI (s) (4C:E8) [17:16:45:830]: Command Line: REMOVE=ALL CURRENTDIRECTORY=D:\Setup CLIENTUILEVEL=2
CLIENTPROCESSID=3456
Die Deinstallation kann ebenfalls ber die Funktion MsiInstallProduct() der Windows InstallerProgrammierschnittstelle ausgefhrt werden. Hierzu ist es erforderlich, die Zeichenfolge
REMOVE=ALL der Eigenschaftsauflistung der Funktion anzufgen. Weiterhin knnen hierfr auch
die Funktionen MsiConfigureProduct() und MsiConfigureProductEx() verwendet werden.
Bei einer administrativen Installation wird die Anwendung in keinen ausfhrbaren Zustand versetzt,
sondern ein administratives Abbild wird angelegt. Das bedeutet, dass das Installationspaket und die
zugehrenden Dateien in ein Zielverzeichnis kopiert werden. Von diesem Punkt aus kann direkt die
37
Kapitel 1
Clientinstallation gestartet werden. Whrend der administrativen Installation ndert der Windows
Installer bestimmte Eigenschaften der Datenbank. Weiterhin werden Dateien die sich im
komprimierten Zustand befinden extrahiert und in einer Ordnerstruktur abgelegt. Eine administrative
Installation kann von der Befehlszeile mit Hilfe des Arguments /a gestartet werden.
msiexec.exe /a <Pfad zum Paket> TARGETDIR=<Zielverzeichnis> /qb
Wird eine administrative Installation im unbeaufsichtigten Modus oder unter Verwendung der
Basisdarstellung durchgefhrt, muss das Zielverzeichnis ber die Befehlszeile angegeben werden.
Dieses ist erforderlich da keine Dialoge zum Festlegen angezeigt werden. Falls dieses nicht beachtet
wird, wird automatisch das Stammverzeichnis des Laufwerks mit dem meisten verfgbaren
Speicherplatz als Zielverzeichnis verwendet.
Im Installationsprotokoll lsst sich eine administrative Installation wiederum anhand der Eigenschaft
ACTION erkennen. Bei dieser Installationsart wird die Eigenschaft auf den Wert ADMIN gesetzt.
Property(S): ACTION = ADMIN
Eine administrative Installation kann durch die Funktion MsiInstallProduct() der Windows InstallerProgrammierschnittstelle ausgefhrt werden. Hierzu ist es erforderlich, die Zeichenfolge
ACTION=ADMIN der Eigenschaftsauflistung der Funktion anzufgen.
Die angekndigte Installation bezeichnet die Mglichkeit Installationsteile anzumelden, ohne aktuell
bentigte Dateien physisch zu installieren. Hierbei wird zwischen dem Zuweisen (Assign) und dem
Verffentlichen (Publish) unterschieden. Um ein Produkt anzukndigen, ist das Argument /j mit
Angabe zustzlicher Parameter und Angabe des Windows Installer-Paketes zu verwenden. Ein
wesentlicher Punkt ist hierbei die Angabe des Kontexts, fr den das Produkt angekndigt werden soll.
Aus diesem Grund ist das Argument /j weiter zu qualifizieren, um dadurch den Benutzer- oder
Maschinenkontext zu bestimmen. Die mglichen Befehlszeilenaufrufe knnen wie folgt definiert
werden.
msiexec.exe /j[u|m] <Pfad zum Paket>
msiexec.exe /j[u|m] <Pfad zum Paket> /t <Transformation>
msiexec.exe /j[u|m] <Pfad zum Paket> /g <Sprach-ID>
Zu erkennen ist hierbei dass die Installation bei Bedarf immer mit dem Argument /j eingeleitet wird,
wobei das j fr Just-In-Time steht. Hieran muss der Kontext angefgt werden, wobei u fr
User steht und somit den aktuellen Benutzer kennzeichnet und m (maschine) den
Maschinenkontext. Im Installationsprotokoll lsst sich eine Installation bei Bedarf anhand der
Eigenschaft ACTION erkennen. Bei dieser Installationsart wird die Eigenschaft auf den Wert
ADVERTISE gesetzt.
Property(S): ACTION = ADVERTISE
Eine Installation bei Bedarf kann darber hinaus durch die Funktionen MsiAdvertiseProduct() und
38
Kapitel 1
MsiAdvertiseProductEx() der Windows Installer-Programmierschnittstelle gestartet werden.
Installationsphasen
Nach dem Aufruf des Installationspaketes beginnt der Windows Installer die notwendigen
Informationen zur Durchfhrung der Installation zu sammeln. Dieser Abschnitt der Installation wird
als Acquisition-Phase bezeichnet. Nach dieser Phase werden die gesammelten Daten an den ServerProzess bergeben, der anschlieend die entsprechenden Installationsskripte generiert und die
eigentliche Installation durchfhrt. Dieser Abschnitt der Installation wird als Execution-Phase
bezeichnet. Wird die Execution-Phase fehlerfrei durchlaufen, findet der Wechsel in die Commit-Phase
statt, in der die Installation abgeschlossen wird. Kommt es jedoch im Rahmen der Installation zu
Problemen, wird die Rollback-Phase ausgefhrt, wodurch der Computer wieder in den ursprnglichen
Zustand zurckgesetzt wird. Das Zusammenspiel der Acquisition- und der Execution-Phase wird in
Abbildung 1.7 dargestellt.
Abbildung 1.7: Phasen im Installationsprozess
Die erwhnte Rollback- und Commit-Phase werden an dieser Stelle nicht betrachtet. Eine Erluterung
folgt in Kapitel 8.
Acquisition-Phase
Die Acquisition-Phase dient im Wesentlichen dazu, Informationen fr den Installationsprozess zu
beschaffen und diese dem Ausfhrungsmodul (Execution Engine) zur Verfgung zu stellen. Die
Acquisition-Phase wird immer mit den Privilegien des aktuellen Benutzers durchgefhrt. Die
Zuweisung von Systemprivilegien ist fr diese Phase nicht mglich.
Sehen Sie zunchst das folgende Beispiel: Der Benutzer fhrt im Windows-Explorer einen Doppelklick
auf eine MSI-Datei durch. Dateien mit einer solchen Endung sind standardmig mit dem Windows
Installer-Dienst verknpft, so dass hierdurch die folgende Befehlszeile konstruiert und aufgerufen
39
Kapitel 1
wird:
%windir%\system32\msiexec.exe /i <Pfad zum Installationspaket>
Es wird zunchst der Client-Prozess gestartet und diesem ein Verweis auf das Installationspaket
bergeben. Optional sind hierbei auch die bergabe von Windows Installer-Patches oder
Transformationen mglich. Der Client-Prozess ldt das Installationspaket in den Arbeitsspeicher und
wendet alle Patches und Transformationen darauf an, die der Befehlszeile angefgt wurden und fr
dieses Paket gltig sind. Im Folgenden wird die Initialisierung ausgefhrt, in der unter Anderem der
Speicherbedarf ermittelt und der Status der Features berprft wird. Anschlieend wird die
Benutzeroberflche angezeigt und es findet die Interaktion mit dem Benutzer statt. Nachdem alle
Eingaben vorgenommen wurden, wird der Server-Prozess gestartet. Diesem Prozess werden alle
bereits ermittelten Informationen in Form einer Befehlszeile bergeben. In einem Installationsprotokoll
ist diese Aktion als Switching to server bezeichnet.
MSI (c) (1C:E8) [16:14:09:186]: Switching to server: INSTALLLOCATION="C:\Program Files (x86)\Football 2008\"
TARGETDIR="F:\" CURRENTDIRECTORY="D:\Setup" CLIENTUILEVEL="0" CLIENTPROCESSID="2332"
USERNAME="Andreas Kerl" COMPANYNAME="Microsoft Deutschland GmbH" SOURCEDIR="D:\Setup\" ACTION="INSTALL"
EXECUTEACTION="INSTALL" ROOTDRIVE="F:\" INSTALLLEVEL="1" WIXUI_INSTALLDIR_VALID="1" SECONDSEQUENCE="1"
ADDLOCAL=Application
Sie erkennen in dem Ausschnitt des Installationsprotokolls, dass ausschlielich die ffentlichen
Eigenschaften an den Server bergeben werden. Verfgt der Benutzer ber administrative Privilegien
werden alle ffentlichen Eigenschaften bergeben. Handelt es sich bei dem Benutzer um keinen
Administrator und wird die Installation mit erhhten Anwenderprivilegien ausgefhrt, werden nur die
als sicher erachteten Eigenschaften (SecureCustomProperties) bergeben.
Hinweis Beginn
Wird die Installation mit der Standardbenutzeroberflche (Basic-UI) oder ohne Anzeige einer
Benutzeroberflche durchgefhrt, wird der Server-Prozess direkt aufgerufen.
Hinweis Ende
Im Server-Prozess werden die vorliegenden Informationen ausgewertet und in Verbindung mit

zustzlichen Daten wie beispielsweise dem Systemstatus kombiniert. Aus diesen verfgbaren
Informationen werden Operationsanweisungen generiert und in das Installationsskript bertragen.
Diese Anweisungen beschreiben letztlich wie das System aktualisiert werden soll.
Nachdem die Skriptdatei erstellt wurde, wird die Befehlsausfhrung von der Acquisition-Phase an die
Execution-Phase bergeben. Hierzu wird der Konfigurationsmanager aufgerufen und diesem der Pfad
zum Installationsskript zugewiesen.
Hinweis Beginn
Whrend der Acquisition-Phase werden keine Modifikationen am System vorgenommen werden.

Hinweis Ende
Zusammenfassend betrachtet lsst sich erkennen, dass die Acquisition-Phase sowohl im Client- als
auch im Server-Prozess ausgefhrt wird. Das Ergebnis des Client-Prozesses ist eine Befehlszeile, die
an den Server bergeben wird. Das Resultat des Server-Prozesses ist ein Installationsskript, das an dem
Konfigurationsmanager zugewiesen wird.
40
Kapitel 1
Execution-Phase
Die Execution-Phase ist der Teil des Installationsprozesses in dem das Zielsystem physisch modifiziert
wird. Dem Konfigurationsmanager wird das Installationsskript vom serverseitigen Installationsmodul
bergeben. Das Ausfhrungsmodul wird geladen und die Operationsanweisungen des Skriptes werden
ausgefhrt. In dieser Phase werden die Modifikationen am Dateisystem und in der Systemregistrierung
vorgenommen.
Die Execution-Phase wird im Kontext des lokalen Systemkontos ausgefhrt, da hierdurch
sichergestellt werden kann, dass der Installationsprozess die bentigten Rechte besitzt, um
Eintragungen in allen Bereichen der Systemregistrierung und des Dateisystems vorzunehmen. Dieses
bedeutet nicht, dass die vollstndige Installation mit Privilegien ausgefhrt wird, ber die der aktuelle
Benutzer nicht verfgt. Vielmehr wird fr die Execution-Phase ein Identittswechsel auf den aktuellen
Benutzer ausgefhrt, falls es sich um einen Standardbenutzer handelt. Die Installationsaufgaben
werden demzufolge mit den Anwenderprivilegien ausgefhrt. Der Windows Installer legt jedoch
zustzliche Konfigurationsdaten in Bereichen des Zielsystems ab, auf die ein Standardbenutzer keinen
Zugriff hat. Diese Konfiguration wird mit den Privilegien des lokalen Systems vorgenommen.
Hinweis Beginn
Der Administrator kann veranlassen, dass eine Installation mit erhhten Anwenderprivilegien
ausgefhrt wird. Diese erhhten Privilegien beziehen sich ausschlielich auf die Execution-Phase.
Hinweis Ende

Wie bereits im letzten Abschnitt erlutert, werden zur Durchfhrung der Installation zwei unabhngige
Prozesse verwendet, die als Client- und Server-Prozess bezeichnet werden. Einfach ausgedrckt ist der
Client-Prozess fr die Interaktion mit dem Benutzer verantwortlich und der Server-Prozess fhrt die
physischen Modifikationen des Zielsystems durch. Diese Trennung in mehrere Prozesse ist im
Windows Task-Manager ebenfalls zu erkennen, obwohl beide Prozesse die Bezeichnung msiexec.exe
tragen. Der Client-Prozess ist daran zu erkennen dass er im Kontext des aktuellen Benutzers ausgefhrt
wird; der Server-Prozess wird hingegen im Kontext des lokalen Systemkontos ausgefhrt, wie dieses
auch in Abbildung 1.8 dargestellt wird.
41
Kapitel 1
Abbildung 1.8: Installationsprozesse im Windows Task-Manager
In der Abbildung ist auch erkennbar, dass noch weitere Prozesse mit der Bezeichnung msiexec.exe
ausgefhrt werden. Bei den zustzlichen Prozessen handelt es sich um sogenannte Custom ActionServer. Zur Unterscheidung des regulren Installationsprozess von dem Custom Action-Server, muss
die Befehlszeile ausgewertet werden. Die Custom Action-Server verfgen hierbei ber das Argument
-Embedding, dem eine GUID angefgt ist.
Fr die Erluterung der Ablufe im Installationsprozess wird davon ausgegangen, dass die Installation
unter Verwendung einer vollstndigen oder reduzierten Benutzeroberflche durchgefhrt wird. Dieses
ist in sofern relevant, da nur hierbei der Client-Prozess vollstndig verwendet wird. Bei der Installation
im unbeaufsichtigten Modus oder unter Verwendung der Basisdarstellung ist dieses nicht der Fall. Der
Client-Prozess existiert in diesem Szenario zwar, aber die hierauf abzielenden Aktionen im
Installationspaket, werden nicht ausgefhrt. Dieses wird auch im Installationsprotokoll durch die
folgende Eintragung vermerkt.
MSI (c) (B4:E4) [09:00:21:040]: Client-side and UI is none or basic: Running entire install on the server.
Der Client-Prozess wird in diesen Szenarien lediglich als Reprsentationsebene bentigt. Bei
Installation unter Verwendung der Basisdarstellung werden die Dialoge durch den Server-Prozess
verwaltet. Allerdings luft der Server-Prozess in einer anderen Session, so dass diese Dialoge auf
Anforderung des Server-Prozesses durch den Client-Prozess dargestellt werden. Im Weiteren ist der
Client-Prozess in diesen Szenarien fr die Protokollierung zustndig. Das bedeutet auch hier, dass der
Server-Prozess den Client-Prozess anweist, Eintragungen im Protokoll vorzunehmen.
Aktivitten des Client-Prozesses

Nach dem Starten der Installation kommt zunchst der Client-Prozess ins Spiel. Als erstes wird der
aktuelle Systemstatus abgerufen, wodurch berprft wird, ob das zu installierende Produkt bereits auf
dem lokalen System vorhanden ist. Ist das Produkt bereits installiert, wird das im Verzeichnis
42
Kapitel 1
%windir%\installer zwischengespeicherte Paket fr den weiteren Installationsprozess verwendet. Wird

festgestellt, dass das Produkt bereits installiert wurde, jedoch das zwischengespeicherte Paket nicht zur
Verfgung steht, wird das Originalpaket im Ordner %windir%\installer abgelegt. Hierzu wird das
Paket aus dem Installationsverzeichnis verwendet, das in den Konfigurationsdaten fr das Produkt
definiert wurde. Wird hingegen festgestellt, dass das Produkt noch nicht installiert wurde, wird das
referenzierte Installationspaket in den Ordner fr temporre Dateien des aktuellen Benutzers
(%temp%) kopiert.
Sicherstellung der Ausfhrung

Bevor die im Installationspaket definierten Aktionen ausgefhrt werden, wird das Paket hinsichtlich
der Richtlinien fr Softwareeinschrnkungen (SAFER) geprft. Durch die Richtlinien fr
Softwareeinschrnkungen kann die Ausfhrung eines Installationsprogrammes mit Bedingungen
verknpft werden. So kann in Abhngigkeit zum Pfad des Paketes, der Internetzone, eines Hashes oder
eines Zertifikates die Ausfhrung erlaubt oder verweigert werden. Alle diesbezglichen
berprfungen werden durch die SAFER-Infrastruktur ausgefhrt, bei der ein Identittswechsel des
angemeldeten Benutzers durchgefhrt wird. Hierdurch wird sichergestellt, dass die benutzerbezogenen
Richtlinien ordnungsgem angewendet werden knnen. Prozesse, die unter dem lokalen Systemkonto
ausgefhrt werden, werden durch SAFER nicht geprft. Eine SAFER-berprfung wird nicht
durchgefhrt, wenn das Produkt bereits installiert ist, und das zwischengespeicherte Installationspaket
verwendet wird. Die SAFER-berprfung wird dem Installationsprotokoll wie folgt angefgt:
MSI (c) (5C:5C) [18:20:42:232]: SOFTWARE RESTRICTION POLICY: Verifying package -->
'D:\Setup\FB.msi' against software restriction policy
MSI (c) (5C:5C) [18:20:42:232]: SOFTWARE RESTRICTION POLICY: D:\Setup\FB.msi has a digital signature
MSI (c) (5C:5C) [18:20:42:291]: SOFTWARE RESTRICTION POLICY: D:\Setup\FB.msi is permitted
to run at the 'unrestricted' authorization level.
Durchfhren der Initialisierung

Nachdem die SAFER-berprfung abgeschlossen ist und das Paket zu Ausfhrung akzeptiert wurde,
wird vom Installationsmodul die Initialisierung durchgefhrt, bei der auch die Argumente der
Befehlszeile ausgewertet werden. Hierbei werden zunchst die Eigenschaften ausgewertet, die
Windows Installer-Patches oder Transformationen referenzieren. Ist das Produkt bereits installiert,
werden nur registrierte Transformationen verwendet, da nur im Rahmen der Basisinstallation einem
Produkt entsprechende Transformationen zugeordnet werden knnen. Windows Installer-Patches
knnen hingegen zu jeder Zeit auf das Produkt angewendet werden.
Transformationen und Windows Installer-Patches werden bei der Auswertung der Befehlszeile in
folgender Reihenfolge auf das Produkt angewendet:
Kompatibilittstransformationen, die fr das Produkt bentigt werden.
Instanztransformationen
Eingebetteten Sprachtransformationen
Transformationen eines Patches
Transformationen, die durch die Eigenschaft TRANSFORMS definiert wurden.
Kompatibilittstransformationen, die fr den Patch bentigt werden.
Whrend der Initialisierungsphase werden Systemeigenschaften wie die Systemordner, der VirtuellePersnliche Ausfertigung fr Martin Martinsson
43
Kapitel 1
und Physische Speicher, der Prozessor oder die verwendete Plattform abgerufen. Die Datenbank wird
im schreibgeschtzten Modus geffnet, um ein berschreiben der definierten Werte zu verhindern.
Damit trotzdem Modifikationen an den definierten Eigenschaften vorgenommen werden knnen, wird
eine temporre Tabelle zur Aufnahme der Eigenschaften mit der Bezeichnung _Property im Speicher
abgelegt. Das Installationsmodul prft die Gltigkeit des Schemas des Installationspaketes, also ob die
bentigte Windows Installer-Version auf dem System vorhanden ist und ob es sich um eine gltige
Systemarchitektur handelt. Die Installation eines 64-Bit Paketes auf einem 32-Bit Windows wird somit
an dieser Stelle abgebrochen.
Als nchstes werden die Eigenschaften ausgewertet, die im Speicherbereich AdminProperties abgelegt
wurden. Dieser Speicherbereich wird im Installationspaket im Rahmen einer administrativen
Installation erstellt. Im Folgenden berprft das Installationsmodul, ob die notwendigen Privilegien zur
Installation des Produktes vorhanden sind, ob die Installation mit erhhten Anwenderprivilegien
erfolgen soll und ob die Installation nicht durch die Systemrichtlinie DisableMsi verhindert wird.
Nachdem die Transformationen und Patches angewendet wurden, werden die weiteren Eigenschaften
der Befehlszeile auf das Produkt angewendet. Dieses bedeutet, dass die bergebenen Werte in die
temporre Tabelle _Property bertragen werden. Wird die Installation mit erhhten Privilegien
ausgefhrt, sind hierbei nur die Eigenschaften zulssig, die als sicher erachtet werden. Als sicher
erachtete Eigenschaften mssen in der Eigenschaft SecureCustomProperties der Tabelle Property
definiert werden. Der Windows Installer verfgt bereits ber einen Standardvorrat an Eigenschaften,
die bereits als sicher erachtet werden. Diese Einschrnkung kann durch die Eigenschaft
EnableUserControl oder durch die gleichnamige Systemrichtlinie auer Kraft gesetzt werden. In
diesem Fall werden alle ffentlichen Eigenschaften an den Server-Prozess bergeben. Nachdem noch
einige weitere Eigenschaften verarbeitet wurden ist die Initialisierungsphase des Client-Prozesses
abgeschlossen.
Verarbeitung der Sequenztabellen

Nach der Initialisierung wird der eigentliche Installationsprozess durch den Aufruf einer der drei TopLevel-Aktionen gestartet, indem alle Aktionen der zugehrigen Sequenztabelle fr die
Benutzeroberflche ausgefhrt werden. Die folgenden Tabellen werden bei der jeweiligen Aktion
verwendet:
INSTALL: InstallUISequence
ADMIN: AdminUISequence
ADVERTISE: AdvtUISequence
Hinweis Beginn
Eine Benutzeroberflche ist whrend der Produktankndigung (ADVERTISE) nicht verfgbar. Die
Tabelle AdvtUISequence enthlt aus diesem Grund keine Eintragungen.
Hinweis Ende
44
Kapitel 1
Abbildung 1.9: Verwendete Tabellen in Abhngigkeit zur Top-Level-Aktion
Die gerade vorgestellten Sequenztabellen enthalten Informationen zur Anzeige der

Benutzeroberflche, sowie zur Darstellung von Fehler- und anderen Meldungen. Weiterhin knnen
einige Standardaktionen und auch benutzerdefinierte Aktionen in diesen Tabellen verwendet werden.
In vielen Installationspaketen sind hier Standardaktionen zur berprfung der Systemvoraussetzungen,
zur Suche nach abhngigen Komponenten und zur Berechnung des bentigten Speicherbedarfs
implementiert. Die Berechnung des bentigten Speichers wird durch die nachfolgenden
Standardaktionen ausgefhrt:
CostInitialize
FileCost
CostFinalize
Durch diese Aktionen wird ebenfalls der Installationsstatus der Features und Komponenten festgestellt
und die Installationsverzeichnisse bestimmt. Beim Design eines Installationspaketes ist daher zu
bercksichtigen, dass diese Aktionen vor der Anzeige eines Dialoges zur Auswahl der
Installationsverzeichnisse oder zum Festlegen der Features ausgefhrt werden.
Nach Abschluss der Aktion CostFinalize werden die ermittelten Informationen, sowie ein Abbild der
Tabelle Directory dem Installationsprotokoll angefgt, wie der folgende Ausschnitt zeigt:
MSI (c) (5C:5C) [18:20:42:400]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.
MSI (c) (5C:5C) [18:20:42:400]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.
MSI (c) (5C:5C) [18:20:42:400]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is
'0'.
MSI (c) (5C:5C) [18:20:42:400]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'F:\'.
MSI (c) (5C:5C) [18:20:42:400]: PROPERTY CHANGE: Adding INSTALLLOCATION property.
Its value is 'C:\Program Files (x86)\Football 2008\'.
MSI (c) (5C:5C) [18:20:42:400]: Target path resolution complete. Dumping Directory table...
MSI (c) (5C:5C) [18:20:42:400]: Note: target paths subject to change (via custom actions or browsing)
MSI (c) (5C:5C) [18:20:42:400]: Dir (target): Key: TARGETDIR, Object: F:\
MSI (c) (5C:5C) [18:20:42:400]: Dir (target): Key: DesktopFolder, Object: C:\Users\Public\Desktop\
MSI (c) (5C:5C) [18:20:42:400]: Dir (target): Key: ProgramFilesFolder, Object: C:\Program Files (x86)\
MSI (c) (5C:5C) [18:20:42:400]: Dir (target): Key: INSTALLLOCATION,
Object: C:\Program Files (x86)\Football 2008\
45
Kapitel 1
Wechsel zum Server-Prozess

Die wichtigste Aktion in der jeweiligen UI-Sequenztabelle ist ExecuteAction. Beim Ausfhren dieser
Aktion wird die Befehlsausfhrung an den Server-Prozess bergeben. ExecuteAction stellt hierzu eine
Verbindung zum Konfigurationsmanager des Server-Prozesses her, indem CoCreateInstance()
aufgerufen wird. Das Installationsmodul des Client-Prozesses prft daraufhin, ob der Mutex
_MsiExecute bereits existiert. Ist dies der Fall, wird die Installation mit dem Fehler
ERROR_INSTALL_ALREADY_RUNNING abgebrochen. Dieses ist dadurch bedingt, dass der Windows
Installer die Verwendung von mehreren Client-Prozessen untersttzt, jedoch nur die Ausfhrung eines
Server-Prozesses erlaubt. Der Client-Prozess fhrt daraufhin einen Remoteprozeduraufruf zum Server
durch, um die eigentliche Installation einzuleiten.
Aktivitten im Server-Prozess
Die Initialisierung des Server-Prozesses geschieht auf eine hnliche Weise wie die des Clients. Die
primre Komponente dieses Prozesses ist der Konfigurationsmanager. Der Konfigurationsmanager
empfngt die Installationsaufforderung vom Client, wozu ihm der ProductCode, die Top-LevelAktion, die Befehlszeile, Informationen zur Protokollierung und eine Referenz auf den UI-Handler
bergeben werden. Zunchst wird erneut geprft ob der Mutex _MSIExecute existiert. Im Anschluss
wird das Installationsmodul erstellt und der Installationsprozess gestartet. Weiterhin wird der
Systemstatus analysiert und eine berprfung des Paketes hinsichtlich der Richtlinien fr
Softwareeinschrnkungen (SAFER) durchgefhrt. Falls das Produkt noch nicht installiert ist, wird das
Installationspaket im Verzeichnis %windir%\installer gespeichert.
Der Server-Prozess kann keine Benutzeroberflche darstellen. Aus diesem Grund werden Meldungen
zum Client gesendet, die dann vom clientseitigen UI-Handler ausgewertet und dargestellt werden.
Ausgenommen hiervon ist die unbeaufsichtigte Installation; hierbei werden keine Dialoge durch den
Client angezeigt und es wird somit die Mglichkeit gegeben auch Installationen durchzufhren, ohne
dass ein interaktiver Benutzer am System angemeldet ist. Benutzerspezifische Eintragungen werden in
einem solchen Fall im Systemprofil (%windir%\system32\config\systemprofile) abgelegt.
Der Client-Prozess bergibt dem Server neben vielen Informationen auch die aktuelle Top-LevelAktion. In Abhngigkeit zu dieser Aktion wird die Tabelle fr die Ausfhrungssequenz bestimmt und
die darin enthaltenen Aktionen ausgefhrt. Folgende Tabellen werden hierzu in Abhngigkeit zur TopLevel-Aktion verwendet (Siehe auch Abbildung 1.9):
INSTALL: InstallExecuteSequence
ADMIN: AdminExecuteSequence
ADVERTISE: AdvtExecuteSequence
Wie im clientseitigen Prozess werden zunchst die Aktionen zur Bestimmung der
Installationsinformationen ausgefhrt. Im ersten Teil werden hier die Systemvoraussetzungen
(LaunchCondition) geprft und nach abhngigen Ressourcen gesucht (AppSearch). Es knnen auch
benutzerdefinierte Aktionen in diesem Teil zur Anwendung kommen. Im weiteren Verlauf werden die
Aktionen zur Berechnung des Speicherbedarfs (CostInitialize, FileCost und CostFinalize) ausgefhrt
Berechnung des Speicherbedarfs

Die Relevanz bei der Berechnung des Speicherbedarfs liegt in einer wesentlichen Vorgabe des
Windows Installer begrndet, nmlich keine Installation zu starten, wenn der erforderliche
46
Kapitel 1
Speicherplatz nicht vorhanden ist. Bei dieser Prfung ist die Kenntnis der Zielverzeichnisse uerst
relevant. Aus diesem Grund werden zu diesem Zeitpunkt auch die symbolischen Verzeichnisnamen
innerhalb des Paketes gegen die absoluten Pfade ausgetauscht. Somit werden innerhalb dieser Phase
zwei wesentliche Aktivitten verrichtet, dessen Realisierung durch die folgenden Objekte erfolgt:
SelectionManager: Verwaltet den Status der Features und Komponenten, die im Installationspaket
definiert wurden. Hierbei werden der Systemstatus und die individuelle Konfiguration der Features
bercksichtigt.
DirectoryManager: Bestimmt die tatschlichen Zielverzeichnisse anhand der Systemkonfiguration
und der Definition im Installationspaket.
Bei der Berechnung des Speicherbedarfs wird sichergestellt, dass das Zielsystem ber ausreichend
Speicherplatz auf den Datentrgern verfgt. Hierbei werden Szenarien fr die lokale Installation von
Komponenten, die Ausfhrung von Komponenten vom Quellmedium und fr Komponenten, die nicht
installiert werden sollen, getrennt bercksichtigt. Die Werte werden jeweils fr Rollback-Szenarien
und fr Szenarien in denen kein Rollback ausgefhrt wird, berechnet. Zur Ermittlung des tatschlichen
Installationsumfangs und somit der Bestimmung des erforderlichen Festplattenspeichers werden die
folgenden Informationen zu den betreffenden Komponenten bentigt:
Installationsstatus (InstallState): Der bisherige Status der Komponente auf dem Zielsystem.
Anforderungsstatus (RequestState): Der Status der Komponente, der nach der Installation
hergestellt sein soll.
Aktionsstatus (ActionState): Die Aktion, die ausgefhrt werden muss, um die Komponente vom
Installationsstatus in den Anforderungsstatus zu berfhren.
Nachdem der bentigte Speicherbedarf ermittelt wurde, wird whrend der Aktion InstallValidate
geprft, ob ausreichend Festplattenspeicher zur Verfgung steht. Weiterhin wird geprft, ob zu
ersetzende Dateien in Verwendung sind. Die Aktion InstallInitialize schliet die Initialisierungsphase
letztlich ab, wie auch der Auszug aus dem Protokoll zeigt.
Action ended 12:06:30: CostFinalize. Return value 1.
MSI (s) (3C:80) [12:06:30:123]: Feature: Application; Installed: Absent; Request: Local; Action: Local
MSI (s) (3C:80) [12:06:30:123]: Component: C__Football.exe; Installed: Absent; Request: Local; Action: Local
MSI (s) (3C:80) [12:06:30:123]: Component: __C__Football.exe65; Installed: Null; Request: Local; Action:
Local
Action start 12:06:30: InstallValidate.

MSI (s) (3C:80) [12:06:30:126]: PROPERTY CHANGE: Modifying CostingComplete property.
Its current value is '0'. Its new value: '1'.
MSI (c) (5C:E0) [12:06:30:137]: RESTART MANAGER: Detected that application with id 4620,
friendly name 'Football2008', of type RmMainWindow and status 1 holds file[s] in use.
MSI (s) (3C:80) [12:06:30:138]: RESTART MANAGER: Successfully shut down all applications in
the service's session that held files in use.
MSI (c) (5C:E0) [12:06:30:138]: RESTART MANAGER: Successfully shut down all applications
that held files in use.
Action ended 12:06:30: InstallValidate. Return value 1.
Action ended 12:06:30: InstallInitialize. Return value 1.
Bei der Betrachtung des Protokolls fallen einige Eintrge besonders auf. Zu Beginn finden sich die
47
Kapitel 1
Statusinformationen zu den Features und Komponenten und danach wird der Abschluss des
Berechnungsprozesses signalisiert, indem die Eigenschaft CostingComplete auf den Wert 1 gesetzt
wurde. Im Folgenden geht es um die Ermittlung von bereits verwendeten Dateien, wozu der NeustartManager verwendet wird. Beim Neustart-Manager handelt es sich um eine neue Technologie in
Windows Vista und Windows Server 2008, der ein eigenes Kapitel in diesem Buch gewidmet wurde.
Aber nochmal zurck zum Beginn des Protokollauszugs. Bei Betrachtung der Komponenten ist
auffllig, dass die Komponente C__Football.exe zustzlich in einer augenscheinlich modifizierten
Darstellung dort aufgefhrt ist, obwohl eine Komponente mit der Bezeichnung
__C__Football.exe65 im Installationspaket nicht vorhanden ist. Diese zustzliche virtuelle
Komponente ist fr die Berechnung des Speicherplatzes erforderlich. Grundstzlich ist eine
Komponente mit einem Installationsverzeichnis verknpft, so dass dieses Installationsverzeichnis in
die Speicherberechnung einfliet. Nun gibt es Szenarien, in denen zustzliche
Installationsverzeichnisse in die Berechnung einflieen mssen, da sie indirekt verwendet werden.
Eine Komponente enthlt beispielsweise eine Datei und eine Dateiverknpfung. Das
Installationsverzeichnis wird durch die Spalte Directory_ der Tabelle Component bestimmt und fliet
in die Berechnung direkt ein. Die Dateiverknpfung wird hingegen in einem anderen Verzeichnis wie
beispielsweise dem Windows-Desktop erzeugt. Somit muss auch dieses Verzeichnis in den
Berechnungsprozess einbezogen werden.
Fr jedes alternative Verzeichnis erzeugt der Windows Installer eine temporre Komponente. Die
Bezeichnung beginnt mit einem doppelten Unterstrich, dem die ersten 40 Zeichen der Bezeichnung der
primren Komponente folgen. Abgeschlossen wird die Bezeichnung mit einer Nummer, die bei 65
beginnt und bei jeder Unter-Komponente erhht wird.
MSI (s) (3C:80) [12:06:30:123]: Component: Simple7890123456789012345678901234567890123456789012345;
Installed: Absent; Request: Local; Action: Local
MSI (s) (3C:80) [12:06:30:123]: Component: __Simple789012345678901234567890123456789065;
Installed: Null; Request: Local; Action: Local
Dieser Mechanismus wird als Cost-Linking bezeichnet und wird bei Gebrauch der Tabellen Shortcut,
RemoveFile, MoveFile (Fr Quell- und Zielverzeichnisse), DuplicateFile, Registry, IniFile und
ReserveCost verwendet. Weiterhin kommt er auch bei der Installation von globalen Assemblies und
bei der Verwaltung des Baseline-Caches fr Windows Installer-Patches zum Einsatz.
Entfernen existierender Produkte

Im Rahmen der Aktualisierung eines Produktes kann die alte Produktversion automatisch entfernt
werden. Hierzu sind die Aktion RemoveExistingProducts und einige weitere Einstellungen in der
Installationsdatenbank erforderlich. Die Aktion RemoveExistingProducts kann an unterschiedlichen
Positionen in der Sequenztabelle eingeordnet werden. Falls sie jedoch an dieser Stelle, also unmittelbar
nach InstallFinalize eingeordnet wurde, wird zunchst geprft, ob die Deinstallation eines Produktes
erforderlich und fr den aktuellen Benutzer auch zulssig ist. Eine Deinstallation ist nur mglich, wenn
mindestens eine der folgenden Bedingungen erfllt ist:
Der Anwender verfgt ber Administratorenrechte.
Die Richtlinie AlwaysInstallElevated ist fr den Computer und den Anwender aktiviert.
Installation wird fr den Benutzer ausgefhrt (Per-User Installation).
Ist keine dieser Bedingungen zutreffend, so ist eine Deinstallation auch nicht erlaubt und die
Installation wird abgebrochen.
48
Kapitel 1
Erstellen des Installationsskriptes

Im nchsten Schritt wird ein System-Wiederherstellungspunkt erzeugt, allerdings nur, wenn die
Installation nicht im unbeaufsichtigten Modus ausgefhrt wird. Anschlieend wird der Server gesperrt,
indem
der
Registrierungsschlssel
Schlssel
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress erstellt
wird. Existiert dieser Schlssel bereits, kann die Installation nicht fortgesetzt werden, da bereits eine
weitere Installation aktiv ist. Zustzlich wird eine Datei zur Aufnahme von Informationen erstellt, die
im Falle eines Computerneustarts bentigt werden. Hierbei handelt es sich um ein Verbunddokument,
dass im Ordner %windir%\installer erstellt und als IPI-Datei (In-Progress-Information) bezeichnet
wird. Der Pfad zu dieser Datei wird in dem gerade dargestellten Schlssel der Systemregistrierung
abgelegt, wie auch Abbildung 1.10 zeigt.
Abbildung 1.10: Schlssel InProgress in der Systemregistrierung
Die Installation wird nun mit den Aktionen (InstallFiles, WriteRegistryValues etc.) fortgesetzt, die
Operationsanweisungen erstellen. Unter einer Operationsanweisung wird die nicht mehr weiter zu
unterteilende Teilaufgabe verstanden, die zur Durchfhrung einer Aktion erforderlich ist. Das bedeutet,
dass beispielsweise der Kopiervorgang einer Datei in einzelne Aktionen wie dem Festlegen der
Ordner, dem Wechsel des Quellmediums und letztlich dem tatschlichen Kopieren unterteilt wird.
SetTargetFolder(Folder=C:\Program Files (x86)\Football 2008\)
SetSourceFolder(Folder=1\qadx0pjx\|Football 2008\)
ChangeMedia(,MediaPrompt=Please insert the disk: ,MediaCabinet=Data.cab,BytesPerTick=32768,CopierType=2,
ModuleFileName=C:\Windows\Installer\c62407.msi,,,,,IsFirstPhysicalMedia=1)
FileCopy(SourceName=Football.exe,SourceCabKey=F__Football.exe,DestName=Football.exe,Attributes=512,
FileSize=44032,PerTick=32768,,VerifyMedia=1,,,,, ,Version=1.0.0.0,Language=0,InstallMode=58982400,,,)
Die Operationsanweisungen werden einem Skript angefgt, dass im Ordner %windir%\installer erstellt
wird. Der Dateiname wird aus einer temporren Zeichenfolge mit dem Prfix Msi gebildet. Der Typ
der Skriptdatei ist abhngig vom jeweiligen Ausfhrungsmodus der Installation. Als erste Eintragung
wird der Skriptdatei die Operationsanweisung Header angefgt, deren Inhalte in Tabelle 1.7
dargestellt werden.
Name
Beispiel
Beschreibung
Signature
Signature = 1397708873
Konstanter Wert (Immer 0x534f5849)
Version
Version = 405
Version des Windows Installers.
Timestamp
Timestamp = 957117450
Zeitstempel
LangId
LangId = 1031
Sprache des Paketes.
Platform
Platform = 0
Plattform
ScriptType
ScriptType = 1
Typ des Skriptes.
49
Kapitel 1
ScriptMajorVersion und
ScriptMinorVersion
ScriptMajorVersion = 21,
ScriptMinorVersion = 4
Felder zur Festlegung der Kompatibilitt des

Skriptes.
ScriptAttributes
ScriptAttributes = 0
Zustzliche Informationen zur Ausfhrung des

Skriptes wie Elevate oder UseTSRegistry
Tabelle 1.7: Informationen im Header eines Installationsskriptes
Nach dem Header werden Informationen zum Produkt und zum verwendeten Installationspaket dem
Skript angefgt, wie dieses auch nachfolgend dargestellt wird.
Header(Signature=1397708873,Version=405,Timestamp=958626599,LangId=1033,Platform=0,ScriptType=1,
ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
ProductInfo(ProductKey={0BC4E7F4-8840-4D23-9AF9-C68CFFDC7C0E},ProductName=Football 2008,
PackageName=FB001.msi,Language=1033,Version=16777216,Assignment=1,ObsoleteArg=0,
ProductIcon=I__Football.exe,,PackageCode={74D8403A-F2A5-47DB-B819-78316452A1B3},,,InstanceType=0,
LUASetting=1,RemoteURTInstalls=0,ProductDeploymentFlags=3)
Nun aber zurck zu der Verarbeitung der Aktionen der Sequenztabelle. Das Installationsmodul enthlt
ein Objekt zum Auswerten der Bedingungen von Standardaktionen. Gibt eine Bedingung den Wert
True zurck, wird fr diese Aktion eine Operationsanweisung in das Skript bertragen. Die
Operationsanweisung wird in Abhngigkeit zum Installationsstatus, zum Anforderungsstatus und zum
Aktionsstatus der Features und Komponenten aus einem Satz von vordefinierten Anweisungen fr
diese Aktion bestimmt. Allerdings verfahren nicht alle Standardaktionen nach diesem Schema. So
existieren durchaus einige Standardaktionen, die zwischen InstallInitialize und InstallFinalize
angeordnet sind, aber dennoch keine Eintragungen im Skript vornehmen, sondern direkt die
entsprechende Aktion ausfhren.
InstallExecute und InstallExecuteAgain: Die Aktion InstallExecute und InstallExecuteAgain mssen
zwischen den Aktionen InstallInitialize und InstallFinalize definiert werden. Durch den Aufruf von der
Aktionen werden alle im Skript befindlichen Aktionen seit dem Start der Installation oder dem letzten
Aufruf von InstallExecute oder InstallExecuteAgain ausgefhrt und das System wird hierdurch
aktualisiert ohne jedoch die Transaktion zu beenden. Die Aktion InstallExecuteAgain ist identisch mit
der Aktion InstallExecute. Es wurde lediglich einen andere Bezeichnung gewhlt, da es aufgrund einer
Schlsselverletzung nicht mglich ist, eine Aktion mehrfach in einer Tabelle zu definieren.
Diese beiden Aktionen sind in bestimmten Situationen uerst kritisch zu betrachten. Wird eine dieser
Aktionen ausgefhrt, wird das bisher generierte Skript verwendet und das System wird physisch
modifiziert. Kommt es im Folgenden zu einem Fehler innerhalb der Commit-Phase, werden nur die
nderungen zurckgenommen, die nach InstallExecute und InstallExecuteAgain durchgefhrt wurden.
Die Modifikationen, die davor durchgefhrt wurden bleiben bestehen. Dieses teilweise problematische
Verhaltensmuster wurde mit dem Windows Installer 4.5 verndert; hiermit werden alle Modifikationen
wie erwartet zurckgenommen.
ScheduleReboot und ForceReboot: Die Aktion ScheduleReboot veranlasst einen Computerneustart
nach dem Abschluss der Installation. Die Aktion ForceReboot hingegen, veranlasst einen umgehenden
Neustart des Systems. Dem Anwender wird hierzu eine Dialogbox angezeigt, falls die
Darstellungsform der Benutzeroberflche dies erlaubt. Beim Ausfhren von ForceReboot werden alle
vorherigen im Skript befindlichen Aktionen abgeschlossen. Der Installer erstellt den
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce und fgt den
Produktcode oder den Namen des Installationspaketes als Wert hinzu. Der Installer erstellt ebenfalls
50
Kapitel 1
eine Befehlszeile, die diesem Schlssel als Wert hinzugefgt wird. Diese Befehlszeile verfgt ber den
folgenden Aufbau:
AFTERREBOOT=1 RUNONCEENTRY=[Name des Eintrages]
Der Eintrag RUNONCEENTRY enthlt einen Verweis auf einen speziellen RunOnce-Schlssel fr den
Windows
Installer,
der
unter
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\RunOnceEntries
angelegt wird. Diese Informationen werden bentigt, um die Installation auf Basis der IPI-Datei nach
dem Neustart fortzusetzen.
Wichtig Beginn
Bei der Verwendung der paketbergreifenden Transaktionen mit den Windows Installer 4.5 existieren
abweichende Verhaltensmuster bei den Aktionen ForceReboot und ScheduleReboot, die im Kapitel 8
detailliert erlutert werden.
Wichtig Ende
Modifikation des Zielsystems

Nachdem alle Operationsanweisungen dem Installationsskript angefgt wurden, wird dieses durch die
Anweisung End abgeschlossen. Die Execution-Phase wird nun eingeleitet wozu das
Ausfhrungsmodul (Script Executor) erstellt wird und dem die folgenden Argumente bergeben
werden:
ScriptFile: Referenz auf das Installationsskript
MessageHandler: Referenz auf das Objekt zur Darstellung der Meldungen.
DirectoryManager: Referenz auf das Objekt zur Verwaltung der Verzeichnisse.
RollbackEnabled: Boolescher Wert der festlegt, ob der Rollback aktiviert ist oder nicht.
Die Kontrolle wird hierdurch vom Installationsmodul an das Ausfhrungsmodul bergeben, wobei
auch ein Identittswechsel durchgefhrt wird. Das Ausfhrungsmodul prft zunchst ob die
Installation mit erhhten Rechten ausgefhrt werden muss, indem die in der Operationsanweisung
Header definierten Attribute ausgewertet werden. Das Ausfhrungsmodul fhrt nun die
Operationsanweisungen des Skriptes aus und modifiziert hierbei das Zielsystem.
Die Ausfhrung des Skriptes wird im Installationsprotokoll ebenfalls vermerkt. Hierbei wird der
Beginn durch die Zeichenfolge Running Script und das Ende durch die Operationsanweisung End
gekennzeichnet, wie auch der nachfolgende Ausschnitt zeigt:
MSI (s) (80:8C) [17:21:46:698]: Doing action: InstallFinalize
MSI (s) (80:8C) [17:21:46:699]: Running Script: C:\Windows\Installer\MSIB40E.tmp
MSI (s) (80:8C) [17:21:46:702]: Executing op: Header(Signature=1397708873,Version=405,Timestamp=958630584,
LangId=1033,Platform=0,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (80:8C) [17:21:46:770]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=68032)
Zur Realisierung des transaktionalen Verhaltens erstellt der Konfigurationsmanager ein weiteres
Ausfhrungsmodul um das Rollback-Skript auszufhren, falls dieses nicht deaktiviert wurde
(DISABLEROLLBACK). Wird die Installation abgebrochen oder durch einen Fehler beendet, werden
51
Kapitel 1
die Aktionen des Rollback-Skriptes ausgefhrt. Wird die Installation fehlerfrei durchgefhrt werden
die Commit-Aktionen ausgefhrt, die sich ebenfalls im Rollback-Skript befinden.
Wichtig Beginn
Bei der Verwendung von paketbergreifenden Transaktionen mit dem Windows Installer 4.5, kommt
es zu einem genderten Ablauf, da die Commit-Phase erst nach der Installation aller Pakete aufgerufen
wird. Detaillierte Informationen dazu sind im Kapitel 8 zu finden.
Wichtig Ende
Installation abschlieen
Nachdem die Modifikation des Zielsystems abgeschlossen wurde, wird die Erstellung des
Wiederherstellungspunktes beendet. Weiterhin wird die Sperrung des Installationsmoduls aufgehoben,
indem der Schlssel InProgress der Systemregistrierung und die IPI-Datei gelscht werden. Diese
Aktionen werden im Kontext des lokalen Systemkontos ausgefhrt. Das Installationsmodul wird
anschlieend terminiert. Die Terminierung wird jedoch aufgeschoben, bis alle benutzerdefinierten
Aktionen abgeschlossen sind, die asynchron ausgefhrt wurden. Benutzerdefinierte Aktionen, die eine
ausfhrbare Datei verwenden (Typ 2, 18, 50, 51), sind hiervon jedoch ausgenommen.
Der Rckgabewert der Skriptausfhrung wird ausgewertet, um festzustellen, ob ein Computerneustart
erforderlich ist. Die Anforderung fr den Neustart wird an den Client bertragen und dem Benutzer in
einer Dialogbox angezeigt. Wird die Installation ohne Darstellung einer Benutzeroberflche
ausgefhrt, erfolgt der Computerneustart automatisch. Dieses gilt jedoch nur, falls der Neustart nicht
durch die Eigenschaft REBOOT unterdrckt wurde. Anschlieend werden das Installationsskript und
alle temporren Kabinettdateien gelscht. Wurde im Rahmen der Installation ein entsprechendes
Produkt deinstalliert, werden diese Daten ebenfalls entfernt. Die Aktionen zum Entfernen der Daten
werden auch unter dem lokalen Systemkonto ausgefhrt. Wurde festgestellt, dass ein
Computerneustart erforderlich ist, empfngt der Server die Anforderung hierzu und fhrt schlielich
den Computerneustart aus.
Inhalt der Skriptdateien

In den bisherigen Ausfhrungen zu den Ablufen im Installationsprozess, wurde auf die Verwendung
von Skriptdateien bereits hingewiesen. Durch die Verwendung von Skriptdateien ist es mglich, den
Installationsprozess transaktional aufzubauen. Das bedeutet, dass jede durchzufhrende Aktivitt
zunchst im Skript beschrieben wird. Nachdem alle Aktionen im Skript vermerkt sind, wird es
abgearbeitet. Hierbei wird fr jede durchzufhrende Aktion, eine gegenstzliche Aktion konstruiert,
die in ein fr den Fehlerfall bentigtes Rollback-Skript geschrieben wird. Im Fehlerfall wird dieses
Rollback-Skript verwendet und in umgekehrter Reihenfolge durchlaufen, um somit die durchgefhrten
nderungen zurckzunehmen. Durch diese Szenarien wird die Konsistenz des Systems sichergestellt.
Wie bereits erlutert, wird das Installationsskript durch das den Server-Prozess generiert und im
geschtzten Ordner %windir%\installer abgelegt. Dieses Skript enthlt Operationsanweisungen, die
auf Basis des Installationspaketes, den Eingaben des Benutzers und dem aktuellen Systemstatus
generiert wurden. Dem Skript wird weiterhin der ermittelte Installationskontext angefgt. Mgliche
Typen hierfr sind:
Per-User-Unmanaged: Benutzerinstallation mit den Rechten des Benutzers
Per-User-Managed: Benutzerinstallation mit den Rechten des lokalen Systemkontos
52
Kapitel 1
Per-Machine: Computerinstallation mit den Rechten des lokalen Systemkontos

Bei der Initialisierung wird auf Basis dieser Informationen festgelegt, ob das Ausfhrungsmodul im
Kontext des aktuellen Benutzers oder des lokalen Systemkontos ausgefhrt werden soll. Whrend der
Initialisierung wird ebenfalls ein Rollback-Skript erstellt und im Installationsmodul registriert. Jede
Operationsanweisung des Installationsskriptes wird nun ausgefhrt. Es werden hierbei einige Aktionen
immer mit den Rechten des lokalen Systemkontos ausgefhrt, um auf geschtzte Bereiche des Systems
zugreifen zu knnen. Hierbei handelt es sich jedoch nur um Aktionen, die der Windows Installer selbst
bentigt, um die Registrierung des Produktes vorzunehmen. Der Windows Installer legt beispielsweise
eine modifizierte Kopie des Installationspaketes auf dem lokalen System ab. Diese Kopie wird immer
im Verzeichnis %windir%\installer gespeichert, auf das ein Benutzer ohne administrative Privilegien
keinen Schreibzugriff hat. Das bedeutet, dass bei einer Installation, die mit den eingeschrnkten
Rechten eines Standardbenutzers ausgefhrt wird, fr die Zugriffe auf das Windows InstallerRepository die Systemprivilegien verwendet werden. Alle anderen Aktionen werden mit den
Privilegien des Benutzers ausgefhrt. Anders verhlt es sich bei Benutzern, die ber administrative
Privilegien verfgen. Hierbei werden alle Aktivitten mit den Privilegien des lokalen Systemkontos
ausgefhrt. Lediglich fr den Zugriff auf Netzwerkressourcen wird ein Identittswechsel vollzogen, da
das Systemkonto nur lokale Berechtigungen besitzt.
Das Installationsskript enthlt alle Operationsanweisungen die erforderlich sind, um die
Produktkonfiguration vorzunehmen. Nachfolgend finden Sie einen Auszug aus dem zur Verfgung
stehenden Vorrat an Operationsanweisungen.
Metadaten fr die Skriptausfhrung

Diese Operationsanweisungen sind lediglich fr die Skriptausfhrung notwendig. Eine Aktualisierung
des Systems wird hierdurch nicht vorgenommen.
Header
Die Operationsanweisung Header ist die erste Anweisung im Installationsskript und ist wie folgt
aufgebaut:
Header(Signature, Version, Timestamp, LangId, Platform, ScriptType, ScriptMajorVersion,
ScriptMinorVersion, ScriptAttributes)
Anhand dieser Anweisung wird die korrekte Version des Ausfhrungsmoduls geprft und die zu
verwendenden Privilegien werden ermittelt. Das Argument ScriptType legt die Art des
Installationsskriptes fest. Die mglichen Werte sind in Tabelle 1.8 aufgefhrt.
ScriptType
Beschreibung
Standardinstallation (Install).
Rollback-Installation (Rollback)
Ankndigung des Produktes (Advertise).
Clientinstallation die von einer administrativen Installation ausgefhrt wird (PostAdminInstall).
Administrative Installation (AdminInstall)
Tabelle 1.8: Definition der Art des Installationsskriptes
Das Argument ScriptAttributes legt unter anderem fest, ob die Installation mit den Privilegien des
53
Kapitel 1
aktuellen Benutzers oder des lokalen Systemkontos (Elevated Installation) ausgefhrt wird. Hierbei
handelt es sich um ein Bit-Feld, in dem die Installation mit Systemprivilegien durch den Wert 1
ausgedrckt wird.
ProductInfo
Bei der Operationsanweisung ProductInfo handelt es sich immer um die zweite Anweisung im
Installationsskript. Die Anweisung enthlt Informationen zu dem Produkt, das installiert werden soll
und ist wie folgt aufgebaut:
ProductInfo(ProductKey, ProductName, PackageName, Language, Version, Assignment, ObsoleteArg,
ProductIcon, PackageMediaPath, PackageCode, AppCompatDB, AppCompatID, InstanceType, LUASetting,
RemoteURTInstalls, ProductDeploymentFlags)
Die Informationen werden vom Ausfhrungsmodul bentigt, um den Installationstyp zu ermitteln und
hierdurch den Ort festzulegen, an dem die Informationen zur Produktverffentlichung und zur
Registrierung eventueller COM-Komponenten abgelegt werden. Der Installationstyp wird auf Basis
des Argumentes Assignment festgelegt. Gltige Werte hierfr sind in Tabelle 1.9 aufgefhrt:
Assignment
Beschreibung
Anwenderbezogene Installation
Maschinenbezogene Installation
Tabelle 1.9: Mgliche Werte fr das Argument Assignment
Verfgt das Argument Assignment ber den Wert 1, wird zunchst geprft, ob das Produkt fr
diesen Installationstyp (Computer) bereits auf dem lokalen System angekndigt wurde. Ist dieses nicht
zutreffend, wird geprft, ob der aktuelle Benutzer ber administrative Privilegien verfgt, oder ob der
Installationsprozess mit erhhten Rechten ausgefhrt wird. Ist eine der Bedingungen zutreffend,
werden die Daten zur Produktverffentlichung in der Systemregistrierung unter
HKLM\Software\Classes\Installer abgelegt. Informationen von COM-Komponenten werden unter
HKLM\Software\Classes gespeichert. Im Ordner %windir%\installer\<Productcode> werden
Symboldateien fr Dateiverknpfungen und alle Arten von Transformationen gespeichert. Ist keine der
Bedingungen zutreffend wird der Benutzer informiert, dass seine Berechtigungen fr diese
Installationsart nicht ausreichend sind und die Installation wird vom Ausfhrungsmodul abgebrochen.
Wurde das Argument Assignment hingegen auf den Wert 0 festgelegt, wird ebenfalls geprft, ob das
Produkt fr diesen Installationstyp (Benutzer) bereits angekndigt wurde. Ist dieses nicht zutreffend,
wird geprft, ob der Installationsprozess mit erhhten Rechten ausgefhrt wird. In diesem Fall wird die
Installation Per-User-Managed ausgefhrt und die Daten zur Produktverffentlichung werden unter
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Managed\<User-SID>\Installer
gespeichert. COM-Komponenten werden hierbei unter HKCU\Software\Classes abgelegt. Wird der
Installationsprozess hingegen mit den Privilegien des Benutzers ausgefhrt, handelt es sich um eine
Per-User-Unmanaged Installation. Die Daten zur Produktverffentlichung werden unter
HKCU\Software\Microsoft\Installer und die COM-Informationen unter HKCU\Software\Classes
abgelegt. In beiden Fllen werden Symboldateien fr Dateiverknpfungen und fr Transformationen,
die nicht als sicher erachtet werden, im Ordner %appdata%\Microsoft\Installer\<Productcode>
gespeichert.
54
Kapitel 1
End
Die Operationsanweisung End markiert das Ende des jeweiligen Skriptes und ist somit die letzte
Anweisung im Skript. Diese Operationsanweisung verfgt ber keine Argumente.
Aktualisierung der Systemregistrierung

Diese Anweisungen werden verwendet, um die Systemregistrierung zu aktualisieren. Bei der
Ausfhrung des Installationsskriptes wird fr jede dieser Anweisungen eine gegenstzliche Anweisung
in das Rollback-Skript geschrieben, so dass die Modifikationen zurckgenommen werden knnen. Die
Aktionen im Installationsskript werden entweder im Kontext des Benutzers oder des Systemkontos
ausgefhrt. Die Zuordnung richtet sich nach dem Installationstyp, der durch Operationsanweisungen
Header und ProductInfo definiert wurde. Die erstellten Anweisungen des Rollback-Skriptes werden
immer mit den erhhten Rechten des Systemkontos ausgefhrt.
Hinweis Beginn
Zugriffssteuerungslisten (Access Control List, ACL) von vorhandenen Schlsseln, werden whrend
des Schreibens der Registrierungswerte gespeichert.
Hinweis Ende
Bei einer Installation mit erhhten Rechten wird kein Identittswechsel durchgefhrt, wenn auf
HKEY_CURRENT_USER zugegriffen werden muss. Der Windows Installer ldt den Stamm des
aktuellen Benutzers als eigenen HKEY_CURRENT_USER Stamm.
Registrierung der Installationskomponenten

Hierbei handelt es sich um Operationsanweisungen die zur Verffentlichung des Produktes, der
Komponenten und weiteren Ressourcen verwendet werden. Diese Anweisungen werden durch
Aktionen generiert, die sich in den Ausfhrungstabellen befinden. Im Falle einer angekndigten
Installation wird ein Advertise-Skript (ScriptType = 3) erzeugt. Das Advertise-Skript enthlt ebenfalls
Anweisungen zur Verffentlichung und zur Ankndigung des Produktes. Weiterhin befinden sich in
diesem Skript die Anweisungen um Klassen, Dateierweiterungen und Dateiverknpfungen als
Aktivierungspunkte fr die Installation bei Bedarf zu registrieren.
Einige dieser Operationsanweisungen verfgen ber gegenstzliche Anweisungen, andere wie
beispielsweise ProductRegister nicht. Das hat damit zu tun, dass diese Anweisung ausschlielich aus
Aktionen bestehen, die die Systemregistrierung betreffen. Somit werden im Rollback-Skript die
Einzelaktionen aufgefhrt. Zur Registrierung eines Produktes wird beispielsweise die folgende
Operationsanweisung dem Installationsskript hinzugefgt.
ProductRegister(UpgradeCode={DBC3A49F-67B4-4BCE-A596-660D365DBFD8},VersionString=1.00.0000,,,,
InstallSource=D:\Setup\,Publisher=Microsoft Deutschland GmbH,,,,NoModify=1,,,,,,,,EstimatedSize=32,)
Im Installationsskript findet sich eine Vielzahl von Eintrgen, mit denen die Registrierung aufgehoben
wird. Ein Auszug davon wird nachfolgend angefgt.
RegOpenKey(Root=-2147483646,
Key=Software\Classes\Installer\Products\4F7E4CB0048832D4A99F6CC8FFCDC7E0,,BinaryType=1,)
RegRemoveValue(Name=DeploymentFlags,Value=#3,)
RegRemoveValue(Name=AuthorizedLUAApp,Value=#1,)
RegRemoveValue(Name=InstanceType,Value=#0,)
RegRemoveValue(Name=ProductIcon,
Value=C:\Windows\Installer\{0BC4E7F4-8840-4D23-9AF9-C68CFFDC7C0E}\I__Football.exe,)
55
Kapitel 1
RegRemoveValue(Name=AdvertiseFlags,Value=#388,)
RegRemoveValue(Name=Assignment,Value=#1,)
RegRemoveValue(Name=Version,Value=#16777216,)
RegRemoveValue(Name=Language,Value=#1033,)
RegRemoveValue(Name=PackageCode,Value=A3048D475A2FBD748B91871346251A3B,)
RegRemoveValue(Name=ProductName,Value=Football 2008,)
RegOpenKey(Root=-2147483646,
Key=Software\Classes\Installer\Products\4F7E4CB0048832D4A99F6CC8FFCDC7E0,,BinaryType=1,)
RegRemoveKey()
Es existiert aber dennoch die Operationsanweisung ProductUnregister. Diese wird allerdings nur fr
die Deinstallation verwendet und nicht fr einen Rollback. Zu den relevanten Operationsanweisungen
dieser Kategorie gehren somit ProductRegister, ProductUnregister, ProductPublish,
ProductUnpublish, FeaturePublish und ComponentPublish.
Aktualisierung von Dateien

Die Operationen zur Aktualisierung von Dateien werden bei einer nicht verwalteten Installation mit
den Rechten des aktuellen Benutzers ausgefhrt. Bei einer Installation mit erhhten Rechten werden
lokale Dateien mit den Rechten des lokalen Systemkontos aktualisiert. Dateien die sich im Netzwerk
befinden werden hingegen mit den Rechten des Benutzers modifiziert.
Kopieren und Entfernen von Dateien
Im Ersten Schritt wird geprft, ob die zu kopierende Datei bereits auf dem Zielsystem existiert. Ist dies
der Fall und werden dieser Datei keine besonderen Zugriffssteuerlisten durch Eintrge der Tabelle
LockPermissions zugewiesen, werden die Zugriffsteuerlisten der existierenden Datei gesichert und
spter auf die neue Datei angewendet. Ist die Datei auf dem Zielsystem noch nicht vorhanden, wird
lediglich die Operationsanweisung zum Entfernen der Datei in das Rollback-Skript bertragen. Sollte
die Datei existieren, wird sie vor dem Entfernen fr einen eventuellen Rollback gesichert. Hierzu wird
zunchst der Ort bestimmt, an dem die gesicherte Datei abgelegt werden soll. Als Erstes wird geprft
ob der Ordner config.msi im Stammverzeichnis des Laufwerks erstellt werden kann, auf dem sich die
Datei befindet und ob in diesen Ordner geschrieben werden kann. Ist dieses nicht der Fall wird die
Datei unter einem abweichenden Namen im Originalverzeichnis gesichert. Lsst sich der Ordner
config.msi hingegen erstellen, wird die zu sichernde Datei in diesen Ordner verschoben, wobei die
Datei umbenannt wird. Falls beim Verschieben Probleme auftreten, wird zunchst die Datei kopiert
und anschlieend die existierende gelscht. Schlgt der Lschvorgang fehl wird, die Datei nach dem
nchsten Computerneustart gelscht (siehe auch Kapitel 6).
Zu den relevanten Operationsanweisungen dieser Kategorie gehren SetSourceFolder,
SetTargetFolder, ChangeMedia, FileCopy und FolderCreate.
Patchen von Dateien
Die Aktion zum Patchen von Dateien wird durch die Operationsanweisungen FileCopy und
PatchApply realisiert. Whrend der Kopieraktion wird zunchst geprft, ob die zu patchende Datei
bereits auf dem Zielsystem existiert. Ist dieses der Fall wird geprft, ob der Patch auf diese Datei
angewendet werden kann. Wird festgestellt, dass die zu patchende Datei nicht existiert, wird diese
zunchst auf das System kopiert. Hierbei ist ein Zugriff auf die Originalinstallationsquelle erforderlich,
falls die Datei im Baseline-Cache nicht zur Verfgung steht. Die Operationsanweisung PatchApply
wird nun auf diese Datei angewendet, wobei diese Anweisung eine Referenz auf die Datei und auf den
56
Kapitel 1
Patch enthlt. Die Anzahl der Patches die auf diese Datei angewendet werden sollen, wurde bereits
durch FileCopy ermittelt und wird nun bentigt, um bestimmte Aktionen fr diese Datei zu
berspringen. Dieses ist erforderlich falls die Datei bereits in Teilen gepatcht wurde.
Im Folgenden wird der Patch zunchst in einen Sicherungsordner gespeichert und anschlieend auf die
Datei angewendet. Das Ergebnis, also die gepatchte Datei, wird ebenfalls in dem Sicherungsordner
abgelegt. Alle weiteren Patches werden nun auf diese temporre Datei angewendet. Nachdem alle
erforderlichen Patches angewendet wurden, wird die Datei in das eigentliche Zielverzeichnis kopiert.
Ausfhrung von benutzerdefinierten Code

Die nachfolgend aufgefhrten Operationsanweisungen ermglichen die Ausfhrung von
benutzerdefinierten Code whrend der Installation. Das Ausfhrungsmodul stellt hierbei sicher, dass
diese Aktionen in einem separaten Prozess ausgefhrt werden, der vom Installationskontext abhngig
ist. Die Aktionen werden bei einer Installation vom Typ Per-User-Managed oder Per-Machine im
Kontext des lokalen Systems, bei einer Installation vom Typ Per-User-Unmanaged im Kontext des
aktuellen Benutzers ausgefhrt. Der separate Prozess ist erforderlich, um bei einem potentiellen Fehler
im benutzerdefinierten Code, den Installationsprozess nicht zu beeintrchtigen.
OPCode
Beschreibung
Argumente
CustomActionSchedule
Benutzerdefinierte Aktion mit

verzgerter Ausfhrung.
Action, ActionType, Source, Target,

CustomActionData
CustomActionCommit

verzgerter Ausfhrung die nur
beim Commit ausgefhrt wird.

CustomActionData
CustomActionRollback

verzgerter Ausfhrung, die nur
beim Rollback ausgefhrt wird.

CustomActionData
Tabelle 1.10: Operationsanweisungen zur Ausfhrung von benutzerdefinierten Code
Benutzerdefinierte Aktionen mit verzgerter Ausfhrung werden in so genannten Custom ActionServern ausgefhrt, die von der Art der benutzerdefinierten Aktion und vom Installationskontext
abhngig
sind.
Nur
benutzerdefinierte
Aktionen
die
mit
dem
Attribut
msidbCustomActionTypeNoImpersonate markiert wurden, werden bei einer Installation vom Typ PerUser-Managed oder Per-Machine von dem Custom Action-Server ausgefhrt, der im Kontext des
lokalen Systemkontos ausgefhrt wird. In allen anderen Szenarien wird der benutzerdefinierte Code in
dem
impersonierten
Custom
Action-Server
ausgefhrt.
Die
Operationsanweisungen
CustomActionCommit und CustomActionRollback werden immer im Rollback-Skript abgelegt. Die
Anweisung CustomActionRollback wird ausschlielich in Rollback-Szenarien ausgefhrt, whrend
CustomActionCommit nur ausgefhrt wird, wenn die Installation erfolgreich abgeschlossen wurde.
Wichtig Beginn
Dadurch, dass die Operationsanweisung CustomActionCommit in das Rollback-Skript eingetragen

wird, kann eine Commit Custom Action nicht ausgefhrt werden, wenn der Rollback deaktiviert
(DISABLEROLLBACK) wurde. Bei Verwendung der paketbergreifenden Transaktionen mit dem
Windows Installer 4.5 kann der Rollback nicht deaktiviert werden.
Wichtig Ende
57
Kapitel 1
Selbstregistrierung von Modulen

Operationen zur Selbstregistrierung von Modulen werden vom Ausfhrungsmodul als
benutzerdefinierte Aktion (msidbCustomActionTypeExe + msidbCustomActionTypeInScript)
implementiert. Die Aktion ist bei einer Installation vom Typ Per-User-Managed oder Per-Machine mit
dem Attribut msidbCustomActionTypeNoImpersonate versehen, so dass sie mit erhhten Rechten
ausgefhrt werden kann. In Szenarien, in denen ein Netzwerkzugriff erforderlich ist, wird ber einen
speziellen Mechanismus die Registrierung im Kontext des aktuellen Benutzers ermglicht.
Der Windows Installer stellt fr die normalen Installationsttigkeiten einen Vorrat an Aktivitten zur
Verfgung, die als Standardaktionen bezeichnet werden. In Verbindung mit den Sequenztabellen der
Windows Installer-Datenbank werden hiermit die Ablufe im Installationsprozess modelliert. Die
Zielsetzung heutiger Installationsszenarien geht jedoch weit ber diese Ttigkeiten hinaus und verlangt
vielfach die Ausfhrung von individuellen Codefragmenten, um zielgerichtete Anforderungen zu
ermglichen. Zur Realisierung dieser Anforderungen stellt der Windows Installer eine Schnittstelle zur
Verfgung, durch die eine eigene Programmlogik in den Installationsablauf integriert werden kann.
Custom Action-Server
Die Ausfhrung von benutzerdefinierten Aktionen zhlt unbestreitbar zu den komplexesten und
kritischsten Vorgngen im gesamten Installationsprozess. Dieses resultiert zum einen aus der
Forderung individuellen Programmcode in unterschiedlichen Formaten zu untersttzen und zum
anderen die Stabilitt des Installationsprozesses nicht zu beeintrchtigen. Zur Realisierung dieser
Anforderung wurden speziellen Objekte in den Windows Installer-Service integriert, die es
ermglichen, individuellen Programmcode in einer geschtzten Umgebung unter Verwendung
unterschiedlicher Sicherheitsmodelle auszufhren. Diese speziellen Objekte werden als Custom
Action-Server bezeichnet. Custom Action-Server knnen nach dem verwendeten Sicherheitsmodell
wie folgt kategorisiert werden:
Impersoniert: Der individuelle Programmcode wird in einem solchen Custom Action-Server
immer im Kontext des Benutzers ausgefhrt, auch wenn die Installation mit erhhten Rechten
erfolgt.
Elevated: Falls die Installation im privilegierten Kontext ausgefhrt wird, wird der Programmcode
in einem solchen Custom Action-Server ebenfalls mit erhhten Rechten ausgefhrt. Wird die
Installation in einem nicht privilegierten Kontext ausgefhrt, erfolgt die Ausfhrung der
benutzerdefinierten Aktionen, wie beim impersonierten Server, ebenfalls im Kontext des
Benutzers.
Wie bereits dargestellt, versteht man unter einem Custom Action-Server einen Host-Prozess, in dem
benutzerdefinierter Code im Rahmen des Installationsvorgangs ausgefhrt wird. In vielen Fllen ist es
hierbei erforderlich, auf die Informationen der aktiven Installationssession zuzugreifen und somit
Einstellungen fr die Ausfhrung der benutzerdefinierten Aktion zu erhalten. Die Problematik ergibt
sich hierbei durch die Mglichkeit, individuellen Code in unterschiedlichen Formaten zu verwenden,
wodurch bestimmte Einschrnkungen bei der Kommunikation zwischen den Prozessen vorgegeben
sind. Tabelle 1.11 zeigt die Zugriffsmglichkeit auf die aktive Installationssession durch die
58
Kapitel 1
unterschiedlichen Arten von benutzerdefinierten Aktionen.

Format / Typ
Einsprungpunkt
Interaktion
Objektbibliothek (.dll)
Enthlt einen Einsprungpunkt, dem

ein Handle auf die
Installationssession als einziges
Argument bergeben wird.
Verwenden der Funktionen des

Windows Installer-API, die durch
das Handle, auf die aktive
Installationssession zugreifen
knnen.
VBScript / JScript
Entweder eine benannte Funktion

oder das vollstndige Skript.
Verwenden des Objektes Session

der Automatisierungsschnittstelle.
Anwendung (.exe)
Befehlszeile
Die Interaktion kann ausschlielich

ber den Rckgabewert der
Anwendung erfolgen.
Tabelle 1.11: Formate und Interaktionsmglichkeiten von benutzerdefinierten Aktionen
Zu erkennen sind die unterschiedlichen Formate, die vom Custom Action-Server zur Ausfhrung von
individuellem Programmcode untersttzt werden. Der Windows Installer verwendet die Custom
Action-Server jedoch nicht nur zum ausfhren von individuellen Programmcode, sondern auch zur
Ausfhrung von nativen Operationen, die durch Standardaktionen abgebildet werden, wie das
Registrieren von COM-Komponenten (SelfReg) und von ODBC-Datenquellen.
Architektur
Der Windows Installer verwendet einen isolierten Prozess im dem benutzerdefinierten Aktionen vom
Typ Objektbibliothek und Skript ausgefhrt werden. Auf einer 64-Bit-Plattform knnen maximal sechs
dieser Prozesse vorhanden sein, auf einer 32-Bit-Plattform lediglich drei, die wie folgt skizziert
werden:
Impersoniert im Client-Prozess (32-Bit und 64-Bit)
Impersoniert im Server-Prozess (32-Bit und 64-Bit)
Elevated im Server-Prozess (32-Bit und 64-Bit)
Von diesen Custom Action-Servern wird lediglich der Elevated Server im Kontext des lokalen
Systemkontos ausgefhrt. Alle anderen Custom Action-Server werden immer im Kontext des aktuellen
Benutzers ausgefhrt, wie dieses auch in Abbildung 1.11 dargestellt wird.
59
Kapitel 1
Abbildung 1.11: Architektur zur Ausfhrung von benutzerdefinierten Aktionen
Der komplizierteste Vorgang zur Ausfhrung von individuellem Programmcode liegt in der Erstellung
des Custom Action-Servers und der Zuordnung des neuen Servers zu dem aufrufenden Prozess. Fr
einen solchen Server der mit den Privilegien des Benutzers ausgefhrt gestaltet sich der Vorgang wie
folgt:
1. Der gesamte Prozess zum Erzeugen eines Custom Action-Server wird durch das Installationsmodul
eingeleitet. Dieses prft beim Abarbeiten der Tabelle InstallExecuteSequence die einzelnen
Aktionsarten. Handelt es sich um eine benutzerdefinierten Aktion, wird der Typ abgerufen und der
Custom Action-Manager aufgefordert, diese benutzerdefinierte Aktion auszufhren. Das folgende
Szenario bezieht sich auf eine 32-Bit-Objektbibliothek, die sich im Binr-Stream des
Installationspaketes befindet und im Kontext des Benutzers ausgefhrt werden soll.
2. Der Custom Action-Manager prft daraufhin ob ein impersonierter 32-Bit-Custom Action-Server
bereits existiert. In einem solchen Fall, sind keine weiteren Aktionen erforderlich.
60
Kapitel 1
3. Im anderen Fall fordert der Custom Action-Manager den Konfigurationsmanager auf, einen
impersonierten 32-Bit-Custom Action-Server zu erstellen.
4. Der Konfigurationsmanager erstellt daraufhin den Custom Action-Server, wozu er die Funktion
CreateProcessAsUser() verwendet. Hierdurch wird der Server im Sicherheitskontext des aktuellen
Benutzers ausgefhrt. Allerdings werden beim Erzeugen des Servers die folgenden Faktoren
bercksichtigt:
Bei dem erstellten Prozess handelt es sich um eine zustzliche Instanz von msiexec.exe.
Bei dem verwendeten Token handelt es sich um den Token des Benutzers, der jedoch zur
Untersttzung der SAFER-Infrastruktur modifiziert wird.
Die Befehlszeile enthlt ein Argument um msiexec.exe mitzuteilen, dass die Ausfhrung als
Custom Action-Server erfolgt. Weiterhin wird der Befehlszeile ein zufllig generierter Cookie
angefgt, wodurch der Server bei spteren Aufrufen identifiziert werden kann. Ein Beispiel
dafr wre msiexec.exe -Embedding 7156B6D0201299D4C0BB0553B7FB17C1.
Die Umgebungsvariablen (Environment Block) des Benutzers werden verwendet, wobei die
Variable PATH des Systemumgebungsblocks verwendet wird.
Die Sicherheitsbeschreibung (Security Descriptor) wird angepasst, um den Zugriff des
Benutzers auf diesen Prozess einzuschrnken.
5. Der Custom Action-Server wird gestartet und fr den aufrufenden Prozess registriert. Hierbei
werden der Cookie, der Typ der benutzerdefinierten Aktion und ein Interface-Pointer auf das
Remote-API dem Custom Action-Server bergeben.
6. Der Custom Action-Manager fordert im Anschluss den neu erstellten Custom Action-Server auf,
die benutzerdefinierte Aktion auszufhren.
Die dargestellte Beschreibung bezog sich auf einen impersonierten Custom Action-Server, der vom
Server-Prozess aufgerufen wird. Bei den anderen Arten der Custom Action-Server ist der Vorgang
zum Erstellen nahezu identisch, allerdings sind an einigen Position Abweichungen festzustellen.
Beim Elevated Custom Action-Server wird der Aufruf der Funktion CreateProcessAsUser()
abweichend ausgefhrt. Hierbei wird nicht der Token des Benutzers bergeben, sondern ein
modifizierter Token des lokalen Systemkontos. Die Modifikation ist hierbei wieder in Bezug auf die
Untersttzung der SAFER-Infrastruktur zurckzufhren. Zustzlich wird der Token des aktuellen
Benutzers an den Custom Action-Server bergeben, der diesen an einen sicheren Ort
zwischenspeichert und ihn in bestimmten Anwendungsfllen, wie das Registrieren von ODBCKomponenten und die Ausfhrung in einer Terminal-Session, verwenden kann.
Die Erstellung des Custom Action-Servers des Client-Prozesses funktioniert exakt so wie die
Erstellung des impersonierten Servers des Server-Prozesses. Auch hierbei wird die Erstellung des
Custom Action-Servers durch den Konfigurationsmanager initiiert, wozu die Aufforderung natrlich
vom Client-Prozess erfolgt. Die Registrierung erfolgt letztlich fr den Client-Prozess, wodurch der
Interface-Pointer auf das Remote-API des Client-Prozesses dem Custom Action-Server bergeben
wird.
Verwenden einer Objektbibliothek

Nachdem ein geeigneter Custom Action-Server erstellt wurde, kann dieser zum Ausfhren der
benutzerdefinierten Aktionen verwendet werden. Hierzu sind wiederum mehrere Aktionen notwendig.
61
Kapitel 1
Ermitteln der richtigen Objektbibliothek

Der erste Schritt im Ausfhrungsprozess ergibt sich aus der Ermittlung der zu verwendenden
Objektbibliothek. Dieses ist erforderlich, da es der Windows Installer dem Autor eines
Installationspaketes ermglicht, den Speicherort dieser Bibliothek sehr flexibel festzulegen. Die
mglichen Optionen hierfr sind:
Gespeichert im Binr-Stream des Installationspaketes: Bei einer solchen Verwendung wird der
Stream in eine temporre Datei mit der Bezeichnung msixxx.tmp extrahiert, die im Installer-Ordner
%windir%\installer gespeichert wird. Auf dieses Verzeichnis haben Administratoren und das
lokale Systemkonto Vollzugriff und der normale Benutzer ausschlielich Leseberechtigungen.
Wird die benutzerdefinierte Aktion vom Client-Prozess aufgerufen, wird die Datei im Ordner fr
temporre Dateien des Benutzers abgelegt. Der Pfad zu der temporren Datei wird anschlieend an
den Custom Action-Server bergeben.
Installation mit dem Produkt: In diesem Fall verwendet der Windows Installer seine internen
Informationen, wie die Tabellen File und Directory zur Ermittlung des Installationsverzeichnisses
der Objektbibliothek. Der hieraus resultierende Pfad wird anschlieend an den Custom ActionServer bergeben. Hierbei gilt es allerdings zu beachten, dass der Windows Installer beim Kopieren
der Dateien die Versionierungsregeln anwendet. Somit kann nicht garantiert werden, dass die im
Installationspaket befindliche Objektbibliothek tatschlich fr die Ausfhrung verwendet wird.
Wichtig Beginn
Die Verwendung einer benutzerdefinierten Aktion, die mit dem Produkt installiert wird, offenbart viele
potentielle Fehlerquellen. Aus diesem Grund ist hiervon abzuraten und die Integration als BinrStream anzustreben.
Wichtig Ende
Nachdem die jeweilige Objektbibliothek ermittelt wurde, muss schlielich noch der Einsprungpunkt
identifiziert werden. Bei dem Einsprungpunkt handelt es sich um die aufzurufende Funktion der
Bibliothek, die nach folgendem Schema definiert sein muss:
UINT __stdcall CustomAction(MSIHANDLE hInstall)
Die Ermittlung des Einsprungpunktes ist relativ einfach, da dieser direkt aus der Tabelle CustomAction
des Installationspaketes abgelesen werden kann. Nachdem die entsprechende Objektbibliothek
ermittelt und der Einsprungpunkt identifiziert wurde, werden diese Informationen an den Custom
Action-Manager bermittelt. Gleichzeitig erfolgt die Aufforderung zur Ausfhrung der
benutzerdefinierten Aktion.
Ausfhren der Aktion
In Abhngigkeit zur Art der benutzerdefinierten Aktion, wird deren Ausfhrung entweder durch das
Installationsmodul oder durch das Ausfhrungsmodul veranlasst. Hierzu wird eine spezifische
Funktion im Custom Action-Manager aufgerufen, wobei der Pfad zu der jeweiligen Objektbibliothek,
der Name des Einsprungpunktes und der Typ des erforderlichen Custom Action-Servers mit bergeben
werden. Der Custom Action-Manager prft daraufhin die Existenz eines verwendbaren Custom
Action-Servers. Im Folgenden wird die Ausfhrung der benutzerdefinierten Aktion, durch einen
Funktionsaufruf im Custom Action-Server veranlasst. Diesem Funktionsaufruf werden der Pfad zu der
Objektbibliothek und der Name des Einsprungpunktes angefgt. Der Custom Action-Server ldt
daraufhin die Objektbibliothek in den Speicherbereich und ermittelt die Adresse des festgelegten
62
Kapitel 1
Einsprungpunktes durch die Funktion GetProcAdresss(). Im Anschluss wird die ermittelte Funktion
aufgerufen, wobei das Handle auf die aktive Installationssession bergeben wird.
Falls eine Anwendung ber das Windows Installer-API mit einer Installationssession kommuniziert,
werden das Handle und alle weiteren Session-Informationen fr den aktuellen Prozess erstellt, so dass
sich alle Funktionsaufrufe auf den tatschlichen Installationsprozess beziehen. Im Falle einer
benutzerdefinierten Aktion ist dieses kein gewnschtes Verhalten, da hierdurch auf den Prozess
zugegriffen wird in dem der Custom Action-Server ausgefhrt wird und nicht auf den Prozess der
Installationssession. Aus diesem Grunde wird ein Mechanismus verwendet, der als Remote-API
bezeichnet wird und durch den die Interprozesskommunikation stattfinden kann. Beim Remote-API
handelt es sich schlielich um eine Schnittstelle, durch die Funktionsaufrufe aus einer
benutzerdefinierten Aktion, mit zustzlichen Metainformationen versehen und an den jeweiligen
Installationsprozess weiter geleitet werden. Diese Schnittstelle wird allen Custom Action-Servern nach
deren Erstellung vom Konfigurationsmanager zur Verfgung gestellt.
Abschlieen der Ausfhrung
Nachdem die Ausfhrung der benutzerdefinierten Aktion abgeschlossen ist, wird ein Rckgabewert an
den aufrufenden Prozess gegeben. Die Objektbibliothek wird anschlieend entladen. Der Custom
Action-Server wird hingegen nicht terminiert, sondern fr weitere benutzerdefinierte Aktionen der
identischen Installationssession weiter verwendet. Erst nach Abschluss der tatschlichen
Installationssession werden alle Custom Action-Server zerstrt.
Verwenden eines Skriptes

Die Ausfhrung von skriptbasierten benutzerdefinierten Aktionen funktioniert in identischer Weise
wie die Verwendung einer Objektbibliothek. Allerdings macht es diese Art von benutzerdefinierten
Aktionen erforderlich, ein zustzliches Objekt zu verwenden um das Skript tatschlich ausfhren zu
knnen. Zu diesem Zweck wird eine Scripting-Engine unter Verwendung der Funktion
CoCreateInstance() durch den Custom Action-Server erstellt. Zur Ausfhrung wird der ScriptingEngine der vollstndige Skripttext als Zeichenfolge bergeben. Die Kommunikation mit der
Installationssession findet hingegen ber das Windows Installer-Automatisierungsmodell unter
Verwendung der Schnittstelle IDispatch statt. Dieses Automatisierungsmodell enthlt ebenfalls eine
Implementierung zur Interprozesskommunikation.
Hinweis Beginn
Zur Ausfhrung von benutzerdefinierten Aktionen vom Typ Skript ist der Windows Scripting Host
(WSH) nicht erforderlich. Der Windows Installer verwendet zur Ausfhrung ausschlielich die
Systemdateien vbscript.dll und jscript.dll, die jedoch die Systemdatei scrrun.dll zur Ausfhrung
bentigen.
Hinweis Ende
Grundlegende Betrachtungen
Es wurde bereits darauf hingewiesen, dass der Installationsprozess in die Acquisition-Phase und die
Execution-Phase unterteilt ist. Whrend der Execution-Phase findet die tatschliche Modifikation des
Zielsystems statt whrend die Acquisition-Phase lediglich zur Beschaffung von Informationen fr den
Installationsprozess bentigt wird. Die Execution-Phase wird ausschlielich durch den Server-Prozess
gesteuert, die Acquisition-Phase ist sowohl im Client- als auch im Server-Prozess zu finden. Das
63
Kapitel 1
Ergebnis der Acquisition-Phase des Client-Prozesses ist eine Befehlszeile, die an den Server-Prozess
bergeben wird. Das Ergebnis der Acquisition-Phase des Server-Prozesses ist ein Installationsskript,
das an das Ausfhrungsmodul bergeben wird. Diese Phasen sind uerst relevant fr die Verwendung
von benutzerdefinierten Aktionen im Installationsprozess.
Einordnen in den Installationsprozess

Wie bereits vorhergehend erlutert, wird die tatschliche Installation in einer Transaktion ausgefhrt.
Hierdurch wird sichergestellt, dass bei einem Installationsabbruch die bereits gettigten nderungen
zurckgenommen werden knnen. Die Transaktion wird durch die Aktionen InstallInitialize und
InstallFinalize gekennzeichnet. Beim Erreichen der Aktion InstallInitialize wird zunchst mit der
Erstellung eines Installationsskriptes begonnen. Fr nahezu alle Standardaktionen, die sich zwischen
InstallInitialize und InstallFinalize befinden, werden Operationsanweisungen generiert, die in das
Installationsskript bertragen werden. Beim Erreichen der Aktion InstallFinalize wird das
Installationsskript an das Ausfhrungsmodul bergeben und dort abgearbeitet. Bei der Ausfhrung der
einzelnen Operationsanweisungen werden vom Ausfhrungsmodul gegenstzliche Anweisungen in das
Rollback-Skript geschrieben, das im Falle eines Installationsabbruchs zur Rekonstruktion des
Ursprungszustandes des Systems verwendet wird.
Das Verhalten einer benutzerdefinierten Aktion ist an dieser Stelle abweichend von der
Standardaktion. Befindet sich eine relevante Standardaktion zwischen InstallInitalize und
InstallFinalize wird diese nicht direkt ausgefhrt, sondern eine resultierende Operationsanweisung in
das Installationsskript eingetragen. Befindet sich hingegen eine nicht besonders gekennzeichnete,
benutzerdefinierte Aktion zwischen den entsprechenden Aktionen wird sie sofort ausgefhrt und nicht
ins Installationsskript eingetragen. Sie wird demzufolge als Benutzerdefinierte Aktion mit sofortiger
Ausfhrung (Immediate Execution) bezeichnet. Natrlich ist es mglich eine benutzerdefinierte Aktion
zu erstellen, die in das Installationsskript eingetragen und erst im Rahmen der Skriptausfhrung
verwendet wird. Diese wird hingegen als Benutzerdefinierte Aktion mit verzgerter Ausfhrung
(Deferred Execution) bezeichnet. Der gravierende Unterschied zu Standardaktionen ergibt sich daraus,
dass eine Standardaktion immer 2 in das Skript eingetragen wird, wenn sie in der Sequenztabelle
zwischen den Aktionen InstallInitialize und InstallFinalize definiert ist. Eine benutzerdefinierte Aktion
muss ebenfalls zwischen diesen Aktionen in die Sequenztabelle eingefgt werden, allerdings muss sie
darber hinaus explizit fr die Skriptausfhrung gekennzeichnet werden. Hieraus lsst sich ableiten,
dass whrend der Execution-Phase nur benutzerdefinierte Aktionen mit verzgerter Ausfhrung zum
Einsatz kommen drfen. Whrend der Acquisition-Phase finden hingegen ausschlielich
benutzerdefinierte Aktionen mit sofortiger Ausfhrung ihre Verwendung.
Sofortige Ausfhrung
Benutzerdefinierte Aktionen mit sofortiger Ausfhrung (Immediate Execution) werden auch als
Aktionen beschrieben, die im Rahmen der Skripterzeugung ausgefhrt werden. Allerdings ist diese
Beschreibung leicht irritierend, da diese Art von benutzerdefinierten Aktionen auch whrend der
clientseitigen Acquisition-Phase zum Einsatz kommt. Benutzerdefinierte Aktionen mit sofortiger
Ausfhrung werden immer im impersonierten Custom Action-Server ausgefhrt, wobei der dem
Prozess zugeordnete Server verwendet wird. Die Ausfhrung dieser benutzerdefinierten Aktionen kann
veranlasst werden, indem eine Referenz auf die Aktion in die jeweilige Sequenztabelle eingefgt wird,
Mit Ausnahme der Aktionen InstallExecute, InstallExecuteAgain, ForceReboot und ScheduleReboot.
64
Kapitel 1
wobei
die
Tabellen
AdminUISequence,
InstallUISequence,
AdminExecuteSequence,
AdvtExecuteSequence und InstallExecuteSequence verwendet werden knnen. Darber hinaus ist es
auch mglich, die Ausfhrung einer solchen Aktion durch das Steuerelementereignis DoAction oder
den Funktionsaufruf MsiDoAction() zu veranlassen.
Benutzerdefinierten Aktionen mit sofortiger Ausfhrung, knnen auf alle Elemente der aktiven
Installationssession zugreifen und nderungen an den Einstellungen fr den Installationsprozess
vornehmen. Dieser Zugriff wird realisiert, da der benutzerdefinierten Aktion eine Referenz auf die
aktuelle Installationssession bergeben wird, wobei die Art der Referenz von dem jeweiligen Format
der benutzerdefinierten Aktion abhngig ist. Wird ein Skript als benutzerdefinierte Aktion verwendet,
verweist das Objekt Session auf die tatschliche Installationssession. Dieses Objekt enthlt eine
Vielzahl von Eigenschaften um den Installationsprozess zu beeinflussen. So ermglich beispielsweise
die Eigenschaft Session.Property den Zugriff auf die Eigenschaft der Installationssession, um diese
abzurufen oder auch erneut festzulegen.
Bei der Verwendung von Objektbibliotheken gestaltet sich die Gestaltung von benutzerdefinierten
Aktionen abweichend, da hierbei das Windows Installer-API zum Zugriff auf die Informationen der
Installationssession verwendet wird. Wie bereits zu Beginn dieses Abschnitts erlutert, muss die
Funktionsdefinition einer Objektbibliothek nach dem folgenden Schema erfolgen:
UINT __stdcall CustomAction(MSIHANDLE hInstall)
Das Handle wird beim Aufruf der Aktion durch den Windows Installer automatisch zugewiesen, so
dass hierber auf die Informationen der Installationssession zugegriffen werden kann.
Verzgerte Ausfhrung (msidbCustomActionTypeInScript)
Benutzerdefinierte Aktionen mit verzgerter Ausfhrung (Deferred Execution) werden auch als
Aktionen beschrieben, die whrend der Skriptausfhrung verarbeitet werden. Nachdem der Windows
Installer das Installationsskript erstellt hat, wird mit der Abarbeitung dieses Skripts begonnen. Die
gesamte Skriptausfhrung erfolgt innerhalb der Aktion InstallFinalize. Whrend dieser Phase werden
benutzerdefinierte Aktionen mit verzgerter Ausfhrung, zusammen mit allen Standardaktionen
aufgerufen, die ins Installationsskript eingetragen wurden. Die Aktionen werden in der Reihenfolge
ausgefhrt, in der sie im Skript whrend der Erzeugungsphase abgelegt wurden, allerdings nur, wenn
ihre Bedingung zum Zeitpunkt der Skripterzeugung erfllt gewesen ist. Da diese Phase von einem
separaten Modul ausgefhrt wird, knnen benutzerdefinierte Aktionen mit verzgerter Ausfhrung
nicht direkt auf Eigenschaftswerte der Installations-Session zugreifen. Benutzerdefinierte Aktionen mit
verzgerter Ausfhrung knnen nur whrend der Execution-Phase ausgefhrt werden, so dass sie nur
aus den Tabellen AdminExecuteSequence, AdvtExecuteSequence und InstallExecuteSequence
aufgerufen werden knnen, wenn sie zwischen den Aktionen InstallInitialize und InstallFinalize
angeordnet wurden.
Der abweichenden Verwendung von benutzerdefinierten Aktionen mit verzgerter Ausfhrung kommt
bei der tatschlichen Entwicklungsttigkeit eine besondere Bedeutung zu. Kann bei den Aktionen zur
sofortigen Ausfhrung auf alle Informationen der aktiven Installationssession zugegriffen werden, ist
bei verzgert ausgefhrten Aktionen nur ein Teilzugriff mglich. Dieses begrndet sich darin, dass die
Ausfhrung dieser benutzerdefinierten Aktionen vom Ausfhrungsmodul und nicht vom
Installationsmodul gesteuert wird. Dem Ausfhrungsmodul stehen jedoch nur Informationen des
Installationsskriptes zur Verfgung, so dass Informationen, die von der benutzerdefinierten Aktion
bentigt werden, ebenfalls dem Installationsskript hinzugefgt werden mssen. Diese Vorgehensweise
ist relativ einfach zu realisieren und lsst sich durch mehrere Mechanismen durchfhren. Hierbei muss
65
Kapitel 1
einer Eigenschaft eine Zeichenfolge bergeben werden, die die bentigten Informationen enthlt. Der
Name der Eigenschaft muss identisch mit dem Namen der benutzerdefinierten Aktion mit verzgerter
Ausfhrung sein. Soll beispielsweise durch die benutzerdefinierte Aktion CreateUser ein
Benutzerkonto dem lokalen System hinzugefgt werden, so mssen der Eigenschaft CreateUser zuvor
die bentigten Werte zugewiesen werden. Durch diese Vorgehensweise werden die jeweiligen
Informationen der Operationsanweisung zur Ausfhrung der benutzerdefinierten Aktion als Argument
angefgt. Eine benutzerdefinierte Aktion mit verzgerter Ausfhrung wird im Installationsskript als
CustomActionSchedule gekennzeichnet, wie der nachfolgende Auszug eines solchen Skriptes zeigt.
CustomActionSchedule(Action=CreateUser,ActionType=3073,Source=BinaryData,Target=AddAccount,
CustomActionData=Name=MSI;Description=Windows Installer-Testaccount)
Es ist zu erkennen, dass der Name fr das Benutzerkonto und eine entsprechende Beschreibung, der
Eigenschaft CustomActionData angefgt werden. Vom Programmcode der benutzerdefinierten Aktion
muss nun auf diese Eigenschaft zugegriffen werden, damit die bentigten Informationen fr die
Ausfhrung der Aktion verwendet werden knnen. Allerdings steht hierzu nur ein eingeschrnkter
Funktionsvorrat zur Verfgung, der in Tabelle 1.12 zusammengefasst ist.
Funktion
Methode
Beschreibung
MsiGetProperty()
Session.Property
Ermglicht den Zugriff auf bestimmte Informationen

des Installationsskriptes. Es knnen jedoch nur die
Informationen der Eigenschaften ProductCode und
CustomActionData abgerufen werden.
MsiFormatRecord()
Session.FormatRecord
Ermglicht die Formatierung eines Datensatzes,

wobei nur die Eigenschaften ProductCode und
CustomActionData verwendet werden knnen.
MsiGetMode()
Session.Mode
Diese Funktion gibt den Wert True zurck, wenn als

Parameter MSIRUNMODE_SCHEDULED,
MSIRUNMODE_COMMIT oder
MSIRUNMODE_ROLLBACK bergeben wurden und
die benutzerdefinierte Aktion in einem dieser Modi
ausgefhrt wird.
MsiGetLanguage()
Session.Language
Gibt die Sprach-ID des aktuellen Prozesses zurck.
MsiProcessMessage()
Session.ProcessMessage
Ermglicht das Senden einer Fortschritts- oder

Fehlermeldung
Tabelle 1.12: Eingeschrnkter Funktionsvorrat bei der Verwendung von benutzerdefinierten Aktionen mit
verzgerter Ausfhrung
Die wahrscheinlich am hufigsten verwendete Funktion innerhalb einer benutzerdefinierten Aktion mit
verzgerter Ausfhrung ist MsiGetProperty(). Hierdurch ist es mglich die zur Verfgung gestellten
Informationen aus dem Installationsskript zu lesen. Allerdings kann hierbei nur auf die Eigenschaften
ProductCode und CustomActionData zugegriffen werden. Die Eigenschaft CustomActionData enthlt
hierbei die zuvor zugewiesenen Informationen, die als Zeichenfolge abgelegt werden. Hieraus lsst
sich ableiten, dass in die benutzerdefinierte Aktion eine Logik implementiert werden muss, um die
Zeichenfolge wieder in Ihre einzelnen Elemente zu zerlegen.
Wie bereits zuvor erlutert, stehen fr den Server-Prozess sowohl ein impersonierter als auch ein
Elevated Custom Action-Server zur Verfgung. Eine benutzerdefinierte Aktion mit verzgerter
66
Kapitel 1
Ausfhrung wird standardmig im Impersonierten Custom Action-Server ausgefhrt, wozu ein

Identittswechsel auf den aktuellen Benutzer durchgefhrt wird und somit alle Ttigkeiten in dessen
Kontext ausgefhrt werden. Es besteht jedoch die Mglichkeit, diesen Identittswechsel zu umgehen
und somit die benutzerdefinierte Aktion im Elevated Custom Action-Server, also im Kontext des
lokalen Systemkontos, auszufhren. Die Ausfhrung in diesem Kontext setzt allerdings eine
Installation mit erhhten Rechten voraus. Ist eine benutzerdefinierte Aktion zur Ausfhrung im
Systemkontext definiert und wird der aktuelle Installationsprozess mit den Rechten des normalen
Benutzers ausgefhrt, wird die benutzerdefinierte Aktion weiterhin im Impersonierten Custom ActionServer ausgefhrt.
Hinweis Beginn
An dieser Stelle gibt es Abweichungen, falls die Installation bei aktivierter Benutzerkontensteuerung
unter den Betriebssystemen Windows Vista und Windows Server 2008 ausgefhrt wird. Nhere Infos
finden Sie daher im Kapitel 5.
Hinweis Ende
Die bisherige Betrachtung der benutzerdefinierten Aktion mit verzgerter Ausfhrung bezog sich
bisher auf den normalen Installationsprozess. Der Windows Installer stellt zustzlich zwei
Sonderformen dieses Aktionstyps zur Verfgung, die fr bestimmte Einsatzszenarien konzipiert
wurden.
Rollback-Ausfhrung
(msidbCustomActionTypeRollback):
Beim
Ausfhren
jeder
Operationsanweisung des Installationsskriptes wird eine gegenstzliche Anweisung in das RollbackSkript geschrieben, um im Falle eines Installationsabbruchs, die durchgefhrten nderungen
zurckzusetzen. Diese Eintragungen im Rollback-Skript beziehen sich jedoch nur auf
Standardaktionen, da die interne Implementierung einer benutzerdefinierten Aktion fr den Windows
Installer nicht bekannt ist und somit keine gegenstzlichen Aktionen erzeugt werden knnen. Der
Windows Installer stellt jedoch eine Mglichkeit zur Verfgung, eine benutzerdefinierte Aktion so zu
kennzeichnen, dass sie ausschlielich whrend des Rollbacks verwendet wird.
Grundstzlich stellt sich jedoch an dieser Stelle die Frage, ob eine solche benutzerdefinierte Aktion
berhaupt erforderlich ist. Die Antwort auf diese Frage ist wiederum von der Methode abhngig, durch
die das Zielsystem modifiziert wird. Wird das Zielsystem auf direkte Art modifiziert, ist eine
benutzerdefinierte Aktion fr die Rollback-Ausfhrung erforderlich, findet hingegen eine indirekte
Modifikation statt, ist eine solche Implementierung nicht erforderlich. Zur Verdeutlichung dieser
Modifikationsarten soll ein kleines Beispiel dienen.
Sie erstellen ein Installationspaket das zustzlich zu den normalen Installationsvorgngen individuelle
Eintragungen in der Systemregistrierung vornehmen soll. Diese Eintragungen sind abhngig von
bestimmten Systeminformationen, die durch eine benutzerdefinierte Aktion abgerufen werden. Die
hieraus resultierenden Eintragungen der Systemregistrierung knnen nun durch eine benutzerdefinierte
Aktion mit verzgerter Ausfhrung vorgenommen werden, indem die Systemregistrierung durch die
entsprechenden Windows-Funktionen modifiziert wird. In diesem Fall findet eine direkte Modifikation
des Zielsystems statt, so dass eine gegenstzliche Aktion erstellt werden muss, die beim Rollback
verwendet wird. Ein anderes Realisierungskonzept verwendet hierfr eine benutzerdefinierte Aktion
zur sofortigen Ausfhrung. Diese Aktion hat einen vollstndigen Zugriff auf die aktuelle
Installationssession und somit auch auf die Windows Installer-Datenbank. Unter Verwendung der
spezifischen Windows Installer-Funktionen knnen die erforderlichen Informationen nun der Tabelle
Registry temporr angefgt werden. Die tatschliche Modifikation des Zielsystems findet hingegen
durch die Standardaktion WriteRegistryValues statt, fr die der Windows Installer gegenstzliche
67
Kapitel 1
Aktionen ins Rollback-Skript einfgt. Bei dieser indirekten Modifikation ist die Erstellung einer
benutzerdefinierten Aktion fr den Rollback nicht erforderlich
Es ist zu erkennen, dass bei einer direkten Modifikation des Zielsystems durch eine benutzerdefinierte
Aktion mit verzgerter Ausfhrung unbedingt eine gegenstzliche Aktion fr den Rollback erstellt
werden muss. Eine solche Aktion ist bei der Definition besonders zu kennzeichnen und in der
jeweiligen Sequenztabelle unmittelbar vor der korrespondierenden Aktion einzufgen. Bei der
Kennzeichnung ist wiederum darauf zu achten, dass der Ausfhrungskontext ebenfalls der
gegenstzlichen Aktion entspricht.
Commit-Ausfhrung
(msidbCustomActionTypeCommit):
Diese
besondere
Art
von
benutzerdefinierten Aktionen wird nur ausgefhrt, wenn die Ausfhrung des Installationsskriptes
erfolgreich abgeschlossen wurde. Sie eignen sich hervorragend um Ttigkeiten auszufhren, die keinen
Einfluss auf den Installationserfolg haben, wie das Entfernen von temporren Daten im
Installationsprozess. Ttigkeiten, die von Commit-Aktionen durchgefhrt werden, knnen durch
Rollback-Aktionen nicht zurckgenommen werden. Dieses begrndet sich darauf, dass CommitAktionen nicht ins Installationsskript, sondern ins Rollback-Skript eingetragen werden und die
Skripterstellung bei der Ausfhrung der Commit-Aktionen bereits abgeschlossen ist. Wie auch die
Rollback-Aktionen sind Commit-Aktionen besonders zu kennzeichnen, wobei wiederum der
Ausfhrungskontext festgelegt werden kann.
Hinweis Beginn
Rollback-Aktionen und Commit-Aktionen werden nicht ausgefhrt, falls auf dem Zielcomputer der
Rollback deaktiviert wurde (DisableRollback).
Hinweis Ende
Rckgabewerte
Eine benutzerdefinierte Aktion kann einen Rckgabewert an den aufrufenden Prozess geben und
diesen darber informieren, ob die Ausfhrung der Aktion erfolgreich war oder nicht. Bei der
Definition einer benutzerdefinierten Aktion wird festgelegt, ob der Rckgabewert fr den weiteren
Installationsprozess relevant ist und ob entsprechend reagiert werden soll. Wird der Rckgabewert als
Relevant eingestuft, wird der Installationsprozess beendet, sobald die Funktion einen Fehler oder einen
Abbruch durch den Benutzer zurckliefert. Bei der Verwendung einer Objektbibliothek als
benutzerdefinierte Aktion sind die folgenden Rckgabewerte mglich:
Rckgabewert
Wert
Beschreibung
ERROR_FUNCTION_NOT_CALLED
1626
Aktion konnte nicht aufgerufen werden.
ERROR_SUCCESS
Aktion wurde ordnungsgem beendet.
ERROR_INSTALL_USEREXIT
1602
Benutzer hat die Aktion vorzeitig beendet.
ERROR_INSTALL_FAILURE
1603
Nicht behebbarer Fehler aufgetreten.
ERROR_NO_MORE_ITEMS
259
berspringen der ausstehenden Aktionen. Kein Fehler.
Tabelle 1.13: Rckgabewerte von benutzerdefinierten Aktionen

Hinweis Beginn
Beachten Sie, dass ausfhrbare Dateien einen Wert von 0 bei erfolgreicher Ausfhrung zurckgeben
mssen. Alle anderen Werte werden als fehlerhafte Ausfhrung interpretiert.
68
Kapitel 1
Hinweis Ende
Ebenso wie bei den gerade dargestellten Rckgabewerten von Objektbibliotheken knnen auch
Skriptfunktionen entsprechende Rckgabewerte liefern. Bei der Verwendung von Skriptcode wird das
Windows Installer-Automationsmodell verwendet, das die folgenden Konstanten bereitstellt:
Konstante
Wert
Beschreibung
msiDoActionStatusNoAction
Aktion wurde nicht ausgefhrt.
msiDoActionStatusSuccess
Aktion wurde ordnungsgem beendet.
msiDoActionStatusUserExit
Benutzer hat die Aktion vorzeitig beendet.
msiDoActionStatusFailure
Nicht behebbarer Fehler ist aufgetreten.
msiDoActionStatusSuspend
Aktion wird unterbrochen und spter fortgesetzt.
msiDoActionStatusFinished
berspringen der ausstehenden Aktionen. Kein Fehler.
Tabelle 1.14: Rckgabewerte von Skriptfunktionen
Die Rckgabewerte aller Aktionen werden dem Installationsprotokoll angefgt. Hierbei gilt es zu
beachten, dass der Windows Installer die Rckgabewerte beim Anfgen ins Installationsprotokoll
umwandelt, so dass eine erfolgreiche Aktion durch den Wert 1 im Protokoll gekennzeichnet wird.
Eine vollstndige Auflistung der umgewandelten Werte sind in Tabelle 1.15 zu finden.
Konstante
Rckgabewert
Wert im Protokoll
Beschreibung
1626
Aktion konnte nicht

aufgerufen werden.
ERROR_SUCCESS
Aktion wurde
ordnungsgem
beendet.
1602
Benutzer hat die

Aktion vorzeitig
beendet.
1603
Nicht behebbarer
Fehler ist aufgetreten.
ERROR_INSTALL_SUSPEND
1604
Aktion wurde
unterbrochen und wird
spter fortgesetzt.
ERROR_SUCCESS
Aktion wurde
ordnungsgem
beendet.
ERROR_INVALID_HANDLE_STATE
1609
Ungltiger Status fr
das Handle.
ERROR_INVALID_DATA
1626
Daten sind ungltig.
Tabelle 1.15: Darstellung der Rckgabewerte im Installationsprotokoll
69
Kapitel 1
Bedingungen und Deinstallation

Unabhngig davon, welche Art von benutzerdefinierter Aktion Sie gewhlt und an welche Stelle Sie
diese in die Installationssequenz eingeordnet haben, sollte die Ausfhrung auf einer definierten
Bedingung basieren. Fgen Sie beispielsweise ein neues Benutzerkonto dem System hinzu, wird die
hierfr verantwortliche benutzerdefinierte Aktion bei jeder Installationsttigkeit, also bei der
Reparatur, bei der Deinstallation oder beim Anwenden eines Patches ausgefhrt. In vielen Fllen ist
dieses Verhalten nicht gewnscht, so dass in der Spalte Condition der Tabelle, in der die
benutzerdefinierte Aktion referenziert wird, eine Bedingung dieses verhindern sollte. Falls eine direkte
Modifikation des Zielsystems durch eine benutzerdefinierte Aktion erfolgt ist, muss hierzu eine
gegenstzliche Aktion erstellt werden, die bei der Deinstallation des Produktes ausgefhrt wird. Auch
diese Aktion muss mit einer Bedingung versehen werden, damit sie nur whrend der Deinstallation
ausgefhrt wird.
Die effektivste Mglichkeit zur Zuordnung einer Bedingung zu einer benutzerdefinierten Aktion, liegt
in der Verwendung des Aktionsstatus einer Windows Installer-Komponente, wie auch in Tabelle 1.16
gezeigt wird.
Action
Condition
Sequence
RemoveAccounts
$C__Account=2
6025
RollbackAccounts
$C__Account>2
6035
InstallAccounts
$C__Account>2
6045
CommitAccount
$C__Account>2
6055
Tabelle 1.16: Bedingungen bei benutzerdefinierten Aktionen
Die Ausfhrung smtlicher benutzerdefinierter Aktionen der Tabelle ist abhngig vom Aktionsstatus
der Komponente C__Account. Der Aktionsstatus legt fest, welche Ttigkeit fr die Komponente im
Installationsprozess erfolgen soll. Die Definition der Bedingung erfordert demzufolge die Verwendung
des Prfix fr den Aktionsstatus $, den Namen der Komponente und die Zuordnung der jeweiligen
Ttigkeit. Die Aktion RemoveAccounts verfgt ber die Bedingung $C__Account=2, wobei der Wert
2 angibt, dass die Komponente entfernt wird (INSTALLSTATE_ABSENT). Alle anderen Aktionen
wurden mit der Bedingung $C__Account>2 versehen, so dass die Bedingung erfllt ist, wenn die
Komponente lokal installiert (INSTALLSTATE_LOCAL) oder zur Ausfhrung vom Quellmedium
(INSTALLSTATE_SOURCE) konfiguriert wird. Selbstverstndlich ist es auch mglich, die Ausfhrung
einer benutzerdefinierten Aktion von dem Wert einer Umgebungsvariablen abhngig zu machen.
Hierzu muss der Name der Umgebungsvariablen mit dem Prfix % als Bedingung angegeben
werden.
Hinweis Beginn
Auf das Thema der benutzerdefinierten Aktionen werde ich im weiteren Verlauf dieses Buches
mehrfach zurckkommen. So enthlt das Kapitel 2 zustzliche Erluterungen zu vordefinierten
Aktionen, die mit der Toolsammlung Windows Installer-XML bereitgestellt werden. Kapitel 3 befasst
sich mit der 64-Bit-Architektur, wobei auch benutzerdefinierte Aktionen betrachtet werden. In Kapitel
4 wird schlielich die Erstellung und Integration von benutzerdefinierten Aktionen erlutert und
Kapitel 5 stellt abweichende Verhaltensmuster bei der Verwendung von Windows Vista und Windows
Server 2008 heraus.
Hinweis Ende
70
Kapitel 1
Fazit
Der Windows Installer verwendet zwei Prozesse, um eine Produktinstallation auszufhren. Der ClientProzess wird hierbei immer mit den Privilegien des aktuellen Benutzers ausgefhrt. Durch diesen
Prozess werden die Interaktion und die Kommunikation mit dem Benutzer sichergestellt. Die
tatschlichen Installationsaufgaben, also das Kopieren von Dateien oder das Eintragen von Werten in
die Systemregistrierung werden vom Server-Prozess ausgefhrt. Dieser Prozess generiert zunchst ein
Installationsskript, in das die auszufhrenden Aktionen eingetragen werden. Im Anschluss wird dieses
Skript vom Ausfhrungsmodul verarbeitet, wobei gegenstzliche Aktionen in ein Rollback-Skript
bertragen werden. Dieses Rollback-Skript wird ausgefhrt, falls die Installation nicht fehlerfrei
beendet wurde, um die durchgefhrten nderungen rckgngig zu machen. Die durchzufhrenden
Aktivitten sind im Windows Installer-Paket beschrieben und knnen noch durch eigene
Implementierungen erweitert werden, so dass der Flexibilitt kaum Grenzen gesetzt werden.
71
Kapitel 2

Fazit
72
77
93
117
131
Die Anzahl der verfgbaren Tools und Anwendungen zum Erstellen von Windows Installer-Paketen
und anderen Windows Installer-Dateien hat in den letzten Jahren stndig zugenommen. Es sind Tools
verfgbar, die nahezu allen Anforderungen und Vorlieben entgegen kommen. Alle Tools verfgen
ber komfortable und intuitive Benutzeroberflchen, so dass die Erstellung von Windows InstallerDateien auf einfache Weise realisierbar ist. Was auf den ersten Blick als durchaus positiv angesehen
werden kann, offenbart beim nheren Hinsehen doch problematische Elemente. Der Entwickler kann
den Build-Vorgang gar nicht oder nur eingeschrnkt beeinflussen, wodurch ihm viele
Implementierungen und Umsetzungen verborgen bleiben. Hierdurch wird es im Fehlerfall sehr
schwierig, die eigentliche Problemquelle zu identifizieren und das Problem effektiv zu beheben.
Weiterhin ist es in der heutigen Zeit vielfach erforderlich, die Erstellung der entsprechenden Windows
Installer-Dateien in einem automatisierten Build-Prozess zu integrieren. Der Nachteil der verfgbaren
Tools liegt in der unzureichenden Untersttzung solcher automatisierter Prozesse, so dass eine
individuelle Lsung entwickelt werden msste. Das Erstellen einer solchen Lsung ist durch das
Windows Installer-API zwar mglich, allerdings ist die Implementierung mit sehr viel Aufwand
verbunden, wozu auch ein hohes Ma der Technologieverstndnisse erforderlich ist.

Windows Installer-XML ist die Bezeichnung fr ein Framework, mit dessen Hilfe die Erstellung von
Installationspaketen fr den Windows Installer ermglicht wird. Wie der Name bereits vermuten lsst,
spielt in diesem Framework die Extensible Markup Language (XML) eine tragende Rolle. Das
bedeutet einfach ausgedrckt, dass die erforderlichen Inhalte einer Windows Installer-Datei in Form
eines oder mehrerer XML-Dokumente beschrieben werden. Der groe Vorteil dieser Vorgehensweise
liegt auf der Hand. Jeder Entwickler denkt quasi in XML, wodurch das Verstndnis fr den Aufbau
und die Logik eines solchen XML-Dokumentes vorausgesetzt werden kann. Ein weiter groer Vorteil
betrifft die Verfgbarkeit von Windows Installer-XML. Windows Installer-XML ist ein nicht
kommerzielles Produkt. Es ist frei verfgbar und unterliegt der Common Public License, wodurch es
den Entwicklern gestattet wird, den Code zu modifizieren und das Produkt auch in kommerziellen
Projekten zu verwenden. Derzeitig sind zwei Versionen von Windows Installer-XML verfgbar; die
Version 2 hat hierbei einen stabilen Zustand erreicht. Die Version 3 befindet sich hingegen noch in der
72
Kapitel 2
Entwicklung, so dass die einzelnen Releases noch als unstable gekennzeichnet sind. Auch wenn die
Version 3 noch keinen finalen Zustand erreicht hat, wird diese Version bei der weiteren Betrachtung
innerhalb dieses Buches verwendet. Anzumerken ist auch, dass die nchste Version der
Entwicklungsumgebung Visual Studio (Codename: Rosario) ber eine eingeschrnkte Version von
Windows Installer-XML verfgen wird. Hier ist es geplant Windows Installer-XML, Version 3
zustzlich zu den bereits bekannten Setup-Projekten zu integrieren.
Hierarchische Strukturen
Bevor ich auf die sehr umfangreiche Funktionalitt der Toolsammlung Windows Installer-XML
eingehe, mchte ich noch einen Problempunkt aufgreifen, der mir beim Design von
Installationspaketen immer wieder begegnet. Hiermit gemeint ist die Speicherung der Daten in einem
relationalen Format. Dieses ist dadurch kompliziert, dass in der realen Welt berwiegend hierarchische
Strukturen vorliegen, wie das beispielsweise im Dateisystem und in der Systemregistrierung der Fall
ist. Die berfhrung von hierarchischen Strukturen in eine relationale Darstellung ist hufig nur sehr
schwer nachvollziehbar und anwendbar. Jeder der mit dem Windows Installer-Tabelleneditor Orca
bereits versucht hat, die Tabelle Directory eines komplexen Installationspaketes zu analysieren, wird
mir hier zustimmen. Anders ist das mit Windows Installer-XML, denn hier wird zur Beschreibung der
Installation ein wohlgeformtes XML-Dokument verwendet. Der Vorteil ist offensichtlich ein
wohlgeformtes XML-Dokument ist selbst hierarchisch aufgebaut, so dass die Aufnahme hierarchischer
Daten einfacher, bersichtlicher und effektiver realisierbar ist. Zur Verdeutlichung soll die
Ordnerstruktur Windows Installer XML v3 aus Abbildung 2.12 betrachtet werden.
Abbildung 2.12: Installationsverzeichnis und Ordnerstruktur
Die Ordnerstruktur und die Ablage der Dateien sind in der Abbildung sehr gut nachvollziehbar. Anders
verhlt es sich bei der Umsetzung dieser Struktur im nativen Format des Windows Installers, wie
dieses in Tabelle 2.17 gezeigt wird.
Directory
Directory_Parent
DefaultDir
APPLICATIONFOLDER
TARGETDIR
WIX30|Windows Installer XML v3
BinDir
APPLICATIONFOLDER
bin
DocDir
APPLICATIONFOLDER
doc
73
Kapitel 2
SdkDir
APPLICATIONFOLDER
SDK
SdkDir_x64
SdkDir
x64
SdkDir_x86
SdkDir
x86
SdkIncDir
SdkDir
inc
SdkLibDir
SdkDir
lib
TARGETDIR
SourceDir
Tabelle 2.17: Tabelle Directory der Windows Installer-Datenbank
Es wird deutlich, dass die bersichtlichkeit und die Lesbarkeit der Daten leidet und die tatschliche
berfhrung der Daten in eine hierarchische Struktur einiges an Aufwand bedeutet. Es gilt zu
bedenken, dass die im Beispiel verwendete Struktur nicht sehr komplex ist, dennoch gilt zu
bercksichtigen, dass bei steigender Komplexitt natrlich auch die Problemfaktoren entsprechend
anwachsen werden. Im Gegensatz dazu zeigt Listing 2.2 die Ordnerstruktur innerhalb eines XMLDokumentes. Das Dokument ist sofort lesbar und die definierte Struktur lsst sich problemlos auf ein
reales Dateisystem berfhren.
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="APPLICATIONFOLDER" Name="Windows Installer XML v3" ShortName="WIX30">
<Directory Id="BinDir" Name="bin"/>
<Directory Id="DocDir" Name="doc"/>
<Directory Id="SdkDir" Name="SDK">
<Directory Id="SdkIncDir" Name="inc"/>
<Directory Id="SdkLibDir" Name="lib"/>
<Directory Id="SdkDir_x86" Name="x86"/>
<Directory Id="SdkDir_x64" Name="x64"/>
</Directory>
</Directory>
</Directory >
Listing 2.2:Ordnerstruktur im WiX-Dokument
Installation von Windows Installer-XML

Wie bereits angedeutet befindet sich Windows Installer-XML, Version 3 noch in der Entwicklung. Das
bedeutet auch, dass Sie versuchen sollten, immer das aktuellste Release von Windows Installer-XML
zu verwenden. Im Normallfall werden wchentliche Releases zur Verfgung gestellt, die Sie von
http://wix.sourceforge.net/releases/ herunterladen knnen. Um kein Release zu versumen empfiehlt es
sich den RSS-Feed dieser Seite zu abonnieren, der Sie ber die Verfgbarkeit neuer Versionen
informiert.
Fr die Installation von Windows Installer-XML stehen zwei Installationspakete zur Verfgung, die
plattformabhngig zu verwenden sind. Hierbei ist zu beachten, dass entweder Visual Studio 2008 oder
Visual Studio 2005 auf dem System vorhanden sein mssen. Bei der Verwendung von Visual Studio
2005 ist als Systemvoraussetzung der Microsoft Visual Studio ProjectAggregator2 erforderlich.
Hierbei handelt es sich um eine verteilbare Komponente die mit dem Visual Studio 2005 SDK zur
Verfgung gestellt wird. Eine Installation wird erforderlich, falls benutzerdefinierte Projekttypen
verwendet werden, die auf dem Managed Package Framework basieren, wie das bei der Integration
von Windows Installer-XML in Visual Studio 2005 der Fall ist. Das Installationspaket dieser
Erweiterung fr Visual Studio trgt die Bezeichnung projectaggregator2.msi und wird ebenfalls auf
74
Kapitel 2
der Webseite zum Download angeboten. Auf der Webseite finden sie weiterhin den Quellcode von
Windows Installer-XML und die Binrdateien. Die Binrdateien werden ohne Installationsprogramm
angeboten, so dass auch die Einrichtung auf Computern ohne Visual Studio mglich ist, wie das
beispielsweise bei speziellen Build-Systemen der Fall sein knnte.
Integration in Visual Studio

Obwohl XML-Dokumente mit nahezu jedem Editor erzeugt und bearbeitet werden knnen, ist es
dennoch angebracht, die Integration von Windows Installer-XML in Visual Studio vorzunehmen, da
der Komfort durch IntelliSense und Quellcodefrbung wesentlich verbessert wird. Starten Sie hierzu
die Installation von Windows Installer-XML, indem sie das Installationspaket wix3.msi oder
wix3_x64.msi aufrufen. Bei der Auswahl der Funktionalitten stellen sie sicher, dass die jeweilige
Integrationsform ausgewhlt wurde, wie das in Abbildung 2.13 dargestellt wird.
Abbildung 2.13: Integration von Windows Installer-XML in Visual Studio 2008
Nach der Installation knnen die WXS-Dokumente direkt in der Entwicklungsumgebung bearbeitet
werden, wobei die Eingabe der erforderlichen Informationen durch IntelliSense und Quellcodefrbung
vereinfacht wird. Zustzlich werden verschiedene Projekttypen angeboten, bei deren Verwendung die
notwendigen Schritte zur Erzeugung des Installationspaketes automatisiert werden. Die neuen
Projekttypen sind in Abbildung 2.14 zu finden. Verwenden Sie die Vorlage WiX Project um ein
Windows Installer-Paket (.msi) oder ein Patch Creation Property File (.pcp) zu erstellen; verwenden
Sie das WiX Merge Module Project zur Erzeugung eines Windows Installer-Mergemoduls (.msm).
Durch die Verwendung des Projekttyps WiX Library Project wird hingegen keine Windows
Installer-Datei erzeugt, sondern eine vorkompilierte Bibliothek (.wixlib) fr Windows Installer-XML.
75
Kapitel 2
Abbildung 2.14: Verfgbare Projektvorlagen von Windows Installer-XML
Ganz entscheidend und enorm hilfreich ist jedoch, dass die von Visual Studio erzeugte Projektdatei
(.wixproj) oder die Projektmappendatei (.sln) kompatibel mit der Microsoft Build Engine (msbuild.exe)
sind, so dass automatisierte Builds hiermit oder auch mit dem Visual Studio Team Foundation Server
sehr einfach realisierbar sind. Darber hinaus kann zur Entwicklung der Anwendungen und des
Installationsprogramms die gleiche Oberflche verwendet werden, so dass keine neue
Einarbeitungszeit erforderlich ist. Vereinfachend ist in diesem Zusammenhang auch der modulare
Aufbau von Windows Installer-XML, der eine ideale Integration in den regulren
Softwareerstellungsprozess ermglicht.
76
Kapitel 2
Abbildung 2.15: Integration in den Softwareerstellungsprozess
Die Orientierung am klassischen Softwareerstellungsprozess lsst sich sehr gut an dem

Ablaufdiagramm nachvollziehen, dass in Abbildung 2.15 dargestellt wurde. Zu Beginn ist natrlich
der Quellcode zu erstellen, wobei es zunchst unerheblich ist, in welcher Programmiersprache oder
allgemein in welcher Sprache dieses erfolgt. Ausschlaggebend ist die verwendete Sprache erst
whrend des Kompiliervorgangs. Auf Ebene von Windows Installer-XML werden beim Kompilieren
entsprechende Plausibilitts- und Syntaxprfungen durchgefhrt, Variablen und Referenzen aufgelst
und letztlich eine Zwischendatei erzeugt. Der Linker verwendet diese Zwischendatei und erzeugt damit
die entsprechende Ausgabedatei. Hierbei greift er natrlich auch auf externe Ressourcen zu, da diese in
die Ausgabedatei integriert werden mssen.

Ich werde Ihnen zu einem spteren Zeitpunkt noch andere Optionen aufzeigen, ein Installationspaket
zu erstellen oder besser ausgedrckt, den Quellcode dafr zu erzeugen. Zunchst mchte ich doch den
manuellen Ansatz skizzieren, wobei Visual Studio als Entwicklungsumgebung verwendet wird.
Grundlegende Deklarationen
Nachdem die Projektvorlage WiX Project ausgewhlt wurde, wird automatisch ein entsprechendes
Projekt fr Visual Studio angelegt und die Datei wixproject1.wxs im Quellcodeeditor angezeigt. Das
77
Kapitel 2
Stammelement in diesem Dokument lautet <Wix/> und das untergeordnete Element lautet
<Product/>, da es sich bei der Ausgabedatei um ein Windows Installer-Paket (.msi) handelt. Mgliche
Elementtypen an dieser Stelle wren noch <Module/>, <Patch/>, <PatchCreation/> und
<Fragment/>. Es ist erkennbar, dass das Element <Product/> ber zahlreiche Attribute verfgt, mit
deren Hilfe das zu erzeugende Zielprodukt modelliert wird. Das bedeutet, dass diese Attributwerte in
die Tabelle Property des fertigen Installationspaketes bertragen werden. Das Attribut Name entspricht
hierbei der Eigenschaft ProductName und die Id entspricht dem ProductCode, der im Format einer
GUID vorliegt. Ein weiteres wichtiges aber hufig verkanntes Attribut ist Codepage, das zur
Festlegung der Datenbank-Codepage erforderlich ist. Wird dieses Attribut nicht angegeben wird der
Datenbank die neutrale Codepage zugewiesen. Das bedeutet dass nur Zeichen des
Standardzeichensatzes in die Windows Installer-Datenbank bertragen werden; Zeichen aus dem
erweiterten Zeichensatz werden durch Platzhalter ersetzt, was vielfach zu Problemen fhren kann.
Da es sich bei Windows Installer-XML um keine Prozedursprache handelt, sondern um eine
Deklarationssprache, mssen nicht die Schritte beschrieben werden, die ausgefhrt werden mssen, um
die Installation zu realisieren. Vielmehr muss in dem WXS-Dokument das Ergebnis der erfolgreichen
Installation modelliert werden. Hierzu ist es auch erforderlich, sehr viele Elemente mit einem
eindeutigen Identifizierungsmerkmal zu versehen, wozu der Windows Installer eine GUID vorsieht.
Da die Erzeugung einer GUID und das Einfgen an eine bestimmte Position sehr hufig durchgefhrt
werden muss, empfiehlt es sich diese Aktionen zu automatisieren, wozu das in Listing 2.3 dargestellte
Visual Studio-Makro verwendet werden kann.
Sub InsertGuid()
Dim textSelection As EnvDTE.TextSelection
textSelection = CType(DTE.ActiveDocument.Selection(), EnvDTE.TextSelection)
textSelection.Text = System.Guid.NewGuid().ToString()
End Sub
Listing 2.3: Makro zum Einfgen von GUIDs
Das Element <Product/> kann mehrere Unterelemente aufnehmen, von denen <Package/> eine
wichtige Rolle einnimmt, da es die Inhalte des Summary Information Streams bestimmt. Die
Richtlinien zum Design von Installationspaketen sehen vor, dass die Eigenschaft PackageCode bei
jeder Modifikation des Paketes zu verndern ist. Windows Installer-XML kann aus diesem Grund
angewiesen werden, den PackageCode bei jedem Kompiliervorgang neu zu generieren. Hierzu ist es
ausreichend dem Attribut Id des Elementes <Package/> die Zeichenfolge * zuzuweisen. Diese
automatische Generierung ist ebenfalls fr die Identifizierungsmerkmale der Elemente <Component/>,
<Patch/> und <Product/> anwendbar. Eine weitere wichtige Rolle kommt dem Summary Information
Stream in Verbindung mit der Benutzerkontensteuerung von Windows Vista und Windows Server
2008 zu, wie in einem spteren Kapitel noch verdeutlicht wird. An dieser Stelle wird definiert, ob zur
Installation des Paketes administrative Privilegien erforderlich sein mssen oder ob die Rechte des
Standardbenutzers ausreichend sind. Im WXS-Dokument ist hierfr das Attribut InstallPrivileges
zustndig; die mglichen Werte sind elevated und limited.
<?xml version="1.0" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

<Product UpgradeCode="2501DE56-6CC9-4078-B87E-F6664896125F" Manufacturer="Microsoft Deutschland GmbH"
Language="1031" Version="1.00.0000" Name="MSI Demo" Id="7BF40BDA-E554-4949-8A6E-10297BD30BB6"
Codepage="1252">
78
Kapitel 2


<Package Id="*" Keywords="Microsoft Windows Installer, MSI"
Description="MSI Demo" Manufacturer="Andreas Kerl" InstallerVersion="400" Compressed="yes"
Platform="x86" Languages="1031" SummaryCodepage="1252" InstallPrivileges="elevated" />

<Condition Message="Das Microsoft .NET Framework ist zur Ausfhrung der Applikation unbedingt
erforderlich.">MsiNetAssemblySupport</Condition>
<Condition Message='Bentigt Microsoft Windows Vista oder ein neueres Betriebssystem'>
VersionNT >= 600</Condition>
<Condition Message ='Die Verwendung dieses Installationspaketes als Nested Installation wird
nicht untersttzt.'>Not ParentProductCode</Condition>
<Property Id="INSTALLLEVEL" Value="3" />
<Property Id="ApplicationUsers" Value="ME" />

<Icon Id="AdminIcon.exe" SourceFile="..\Binaries\Admin.ico.exe" />

<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="MSI Demo">

<Component Id="Admin.exe" Guid="3E935EC1-F26F-432B-B198-3E648371B6EC">
<File Id="Admin.exe" Source="..\Binaries\" Name="Admin.exe" AssemblyManifest="Admin.exe"
AssemblyApplication="Admin.exe" Assembly=".net" DiskId="1" KeyPath="yes" />
<Shortcut Id="Admin.exe" Directory="DesktopFolder" Name="MSI-Demo" Target="Application"
Hotkey="0" Icon="AdminIcon.exe" IconIndex="0" Show="normal" />
</Component>

<Component Id="Forms.Vista.dll" Guid="4FF6CAE1-DE0B-4232-8B90-F8B08747DEB7">
<File Id=" Forms.Vista.dll" Source="..\Binaries\" Name="Forms.Vista.dll" KeyPath="yes"
AssemblyManifest="Forms.Vista.dll" AssemblyApplication="Forms.Vista.dll"
Assembly=".net" DiskId="1" />
</Component>
</Directory>
</Directory>
<Directory Id="DesktopFolder" />
</Directory>

<Feature Id="Application" Title="Anwendung" Display="expand" Level="3">
<ComponentRef Id="Admin.exe" />
<ComponentRef Id="Forms.Vista.dll" />
</Feature>

<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
79
Kapitel 2
</Product>
</Wix>
Listing 2.4: Installationspaket als WXS-Dokument
Nahezu jedes Installationsprogramm legt auf dem Zielsystem mindestens eine Datei an. Da Windows
Installer-XML mit einem deklarativen Ansatz arbeitet, wird in dem WXS-Dokument die
Beschaffenheit der Verzeichnisstruktur definiert, wie sie spter auf dem Zielsystem zu finden sein soll.
Theoretisch mssten der skizzierten Verzeichnisstruktur die zu installierenden Dateien nun angefgt
werden. Dieses ist jedoch nicht so einfach mglich, da der Windows Installer komponentenbasiert
arbeitet. Dass bedeutet, dass eine oder mehrere Ressourcen zu einer Gruppe zusammengefasst werden,
die als Komponente bezeichnet wird. Hierbei ist die Art der Ressource nicht relevant, so dass eine
Komponente beispielsweise aus einer Datei, einer Dateiverknpfung und einem Eintrag der
Systemregistrierung bestehen kann. Der Vorteil dieser Funktionalitt liegt klar auf der Hand; der
Windows Installer betrachtet die Komponente als Einheit und verwaltet daher die einzelnen
Ressourcen als zusammenhngendes Gebilde. Fr die Definition im WXS-Dokument bedeutet dieses,
dass zunchst die Komponente innerhalb der Ordnerstruktur anzulegen ist, wozu das Element
<Component/> bentigt wird. Zur Definition der Komponente sind die Attribute Id und Guid
unbedingt erforderlich. Innerhalb der Komponente knnen nun die Ressourcen angelegt werden, wie
dieses auch in Listing 2.4Fehler! Verweisquelle konnte nicht gefunden werden. dargestellt wird.
Eine Datei wird hierbei durch das Element <File/> beschrieben; der Dateiname wird mit Hilfe des
Attributs Name definiert. An dieser Stelle hat es im Vergleich zur Version 2 von Windows InstallerXML eine gravierende nderung gegeben. Bei der Version 2 musste der Dateiname dem Attribut
Name immer im kurzen Format (8.3) bergeben werden, optional konnte ein langer Dateiname dem
Attribut LongName zugewiesen werden. In Version 3 ist diese komplizierte und unzeitgeme
Vorgehensweise nicht mehr erforderlich, da ein kurzer Dateiname automatisch erzeugt wird, falls
dieses erforderlich ist. Es ist somit ausreichend dem Attribut Name den Dateinamen zuzuweisen,
wobei dieser 260 Zeichen nicht berschreiten darf. Handelt es sich hierbei um einen langen
Dateinamen, wird whrend des Build-Vorgangs automatisch ein kurzer Dateiname generiert, falls
dieser nicht explizit durch das Attribut ShortName festgelegt wurde. Es wird an dieser Stelle hufig die
Frage gestellt, warum der kurze Dateiname direkt oder indirekt (durch Automatismus) berhaupt noch
anzugeben ist, da ja die aktuelle Betriebssystemgeneration vollstndig lange Dateinamen untersttzt.
Grundstzlich ist dieses richtig, aber das Zielsystem kann so konfiguriert sein, dass bestimmte Teile
des Dateisystems sich auf einem File-Server befinden, der nur kurze Dateinamen kennt. Um auch
solche Szenarien effektiv zu untersttzen verlangt der Windows Installer seit jeher die Angabe der
Dateinamen in dem folgenden Format:
Short Filename|Long FileName
Diese Formatierung gilt nicht nur fr Dateinamen, sondern ist analog auch auf Ordnernamen
anzuwenden, wie die Beispiele in Tabelle 2.17 auch zeigen. Was noch fehlt ist die Zuordnung einer
Datei zu einem Installationsmedium, wozu das Element <Media/> bereitgestellt wird. Die Zuordnung
kann entweder auf Datei- oder auf Komponentenebene erfolgen. Die Verwendung mehrerer MediaElemente ermglicht die Verteilung der zu installierenden Ressourcen auf mehrere Datentrger.
Noch ein Wort zu den Komponenten. Jede Komponente erwartet ein eindeutiges
Identifizierungsmerkmal in Form einer GUID. Dieser als ComponentId bezeichnete Identifikator ist
fr die Modellierung spterer Updates uerst relevant. Aus diesem Grund existieren Regeln, die
festlegen, wann eine solche GUID zu verndern ist. Da es whrend der Entwicklungsphase sehr hufig
80
Kapitel 2
zu einer nderung der GUID kommen kann, besteht die Mglichkeit, diese nderung automatisch bei
jeder Kompilierung vorzunehmen, wie bereits zuvor angedeutet. Hierzu ist es erforderlich dem Attribut
Guid des Elementes <Component/> die Zeichenfolge * zuzuweisen. Allerdings funktioniert diese
Automatik nicht fr alle Komponentenstrukturen; die folgenden Limitierungen sind daher zu beachten:
Es wir nur eine Datei pro Komponente untersttzt, die auch als Schlssel-Ressource (KeyPath=yes)
festgelegt sein muss. Die Komponente kann diverse andere Arten von Ressourcen, mit Ausnahme
von ODBC-Datenquellen, zustzlich enthalten.
Mehrere Komponenten, die eine identische Datei installieren werden nicht untersttzt.
Was zur Erzeugung eines funktionsfhigen Installationspaketes noch fehlt ist die Definition der
Feature-Struktur. Unter einem Feature versteht man den kleinsten installierbaren Teil des
Softwareproduktes aus Sicht des Endanwenders. Dem entgegenzusetzen ist die Komponente; hierunter
ist der kleinste installierbare Teil des Produktes aus Sicht des Entwicklers zu verstehen. Es ist somit
erforderlich eine Zuordnung von Komponenten zu Features vorzunehmen, wozu die Elemente
<ComponentRef/> oder <ComponentGroupRef/> zu verwenden sind. Hierdurch wird letztlich
bestimmt welche Komponente physisch installiert werden muss, wenn der Anwender ein bestimmtes
Feature zur Installation vorsieht. Die Auswahl der zu installierenden Features erfolgt standardmig in
einem dafr definierten Dialog im Installationsprozess der auch in Abbildung 2.13 zu erkennen ist.
Manueller und automatisierter Buildprozess

Im Prinzip ist es das gewesen ein sehr einfaches aber funktionsfhiges Installationspaket wurde mit
Windows Installer-XML modelliert. Zur Erstellung des finalen Windows Installer-Paketes muss
lediglich der Buildprozess gestartet werden, wozu in Visual Studio die bekannten Menpunkte und
Schaltflchen herangezogen werden knnen. Es besteht natrlich noch die Mglichkeit, die Ablufe
des Buildprozesses zu beeinflussen, indem entsprechende Einstellungen vorgenommen werden.
Analog zu den anderen Visual Studio-Projekten steht hierzu ein uerst komfortabler Dialog zur
Verfgung, wie auch Abbildung 2.16 zeigt.
81
Kapitel 2
Abbildung 2.16: Windows Installer-XML Projekteinstellungen in Visual Studio 2008
Mit Hilfe dieses Einstellungsdialoges knnen Ausgabeoptionen und Variablendefinitionen festgelegt

werden. Zustzlich knnen Post- und Prbuildereignisse, Einstellungen fr die Anwendungen und
Suchpfade definiert werden. Interessant sind auch Optionen zum Festlegen der zu verwendenden
Kultur. Anhand dieser Angabe erfolgt die Sprachauswahl der von Windows Installer-XML
verwendeten Benutzeroberflche, so dass die mehrsprachige Erstellung sehr einfach realisierbar ist.
Zu Beginn dieses Kapitels habe ich bereits die Integrationsmglichkeit in automatisierte Buildprozesse
angedeutet. Alle vorgenommenen Einstellungen werden wie blich in der jeweiligen Projektdatei
abgelegt, so natrlich auch bei Windows Installer-XML. Die erzeugte Projektdatei (.wixproj) und
natrlich auch die Microsoft Visual Studio Projektmappe (.sln) sind kompatibel mit der Microsoft
Build Engine, so dass durch die nachfolgenden Aufrufe die entsprechenden Ausgaben erzeugt werden:
msbuild.exe <Projektdatei>
msbuild.exe <Projektmappendatei>
Wie bereits erwhnt, ist es jedoch nicht mglich, Windows Installer-XML auf einem System zu
installieren, auf dem Visual Studio nicht vorhanden ist. Auf den meisten Build-Systemen wird dieses
aber der Fall sein, so dass eine entsprechende manuelle Konfiguration des jeweiligen Systems
82
Kapitel 2
vorgenommen werden muss. Eine Mglichkeit dazu wre die direkte Verwendung der Binrdateien
von der Webseite. Einfacher ist es jedoch, die bentigten Dateien von einem Computer zu verwenden,
auf dem Windows Installer-XML installiert wurde.
Installieren Sie hierzu Windows Installer-XML auf dem Entwicklungssystem
Erstellen Sie im Quellcodeverwaltungssystem einen Ordner, in dem die Tools von Windows
Installer-XML gespeichert werden knnen.
Kopieren Sie den Inhalt des Ordners %ProgramFiles%\Windows Installer XML v3\bin in dieses
neu angelegte Verzeichnis.
Verfahren Sie mit dem Verzeichnis %ProgramFiles%\MSBuild\Microsoft\WiX\v3.0 auf identische
Weise.
Weiterhin sind die jeweiligen Projektdateien anzupassen, damit beim Buildvorgang auch die
erforderlichen Dateien gefunden werden. Hierzu ist die entsprechende Projektdatei mit einem
Texteditor zu ffnen und die folgenden Informationen sind dem Element <Project/> anzufgen.
Hierbei ist zu beachten, dass dieses vor dem Element <Import/> erfolgen muss. Um die notwendige
Flexibilitt zu erreichen, sollten keine absoluten Pfadangaben verwendet werden. Es empfiehlt sich die
erforderliche Ordnerstruktur an die Gegebenheiten des Build-Systems anzupassen. So sollte bei der
Verwendung der Microsoft Build Engine auf variable Ordnerbezeichnungen wie
MSBuildExtensionsPath oder MSBuildBinPath zurckgegriffen werden.
<Project>
<PropertyGroup>
<WixToolPath>$(MSBuildExtensionsPath)\wix\3.0.4311.0</WixToolPath>
<WixTargetsPath>$(WixToolPath)\Wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)\wixtasks.dll</WixTasksPath>
</PropertyGroup>
<Import Project="" />
</Project>
Listing 2.5: Anpassen einer Projektdatei zur Verwendung auf einem Build-Server
Identisches gilt fr Build-Vorgnge mit dem Visual Studio Team Foundation Server. Nachdem
Windows Installer-XML auf dem Server eingerichtet wurde, kann der Team Foundation Server auch
diese Projekte erzeugen. Die Anpassung sollte auf identische Weise erfolgen, wobei spezifische
Umgebungsvariablen wie BinariesRoot verwendet werden knnen.
Tipp Beginn
In der Dokumentation von Windows Installer-XML sind die einzelnen Tasks und Parameter erlutert,
mit denen der Buildprozess unter Verwendung der Microsoft Build Engine gesteuert werden kann.
Tipp Ende
Variablen und Prprozessoren

Zur Erlangung der grtmglichen Flexibilitt bei der Gestaltung von WXS-Dokumenten, bietet
Windows Installer-XML die Mglichkeit, Prprozessor-Elemente in dem Dokument zu verwenden. Je
nach Art des Prprozessor-Elementes wird dieses entweder durch den Compiler oder durch den Linker
aufgelst. Unabhngig davon besteht hierdurch die Mglichkeit einer individuellen
Produktkonfigurationen, die ber den Befehlszeilenaufruf oder die Projekteinstellungen gesteuert
werden kann. Ein Typ dieser Prprozessor-Elemente sind die Variablen, von denen Windows InstallerPersnliche Ausfertigung fr Martin Martinsson
83
Kapitel 2
XML die folgenden Typen kennt:

Umgebungsvariablen
Systemvariablen
Benutzerdefinierte Variablen
Unabhngig von der zu verwendenden Art der Variablen, sind diese nach dem Schema
$(Typ.<Variable>) im Dokument zu verwenden, wobei als Typ fr Umgebungsvariablen die
Zeichenfolge env, fr Systemvariablen sys und fr benutzerdefinierte Variablen var zu
verwenden ist. Soll beispielsweise die Umgebungsvariable %Path% im WXS-Dokument referenziert
werden, so wird dieses durch Verwendung der Zeichenfolge $(sys.Path) ermglicht. Systemvariablen
werden vom Windows Installer-XML zur Verfgung gestellt und enthalten Informationen ber das
jeweilige WIX-Projekt. In der momentanen Version von Windows Installer-XML stehen die
Systemvariablen CURRENTDIR, SOURCEFILEPATH und SOURCEFILEDIR zur Verfgung. Zu
beachten ist hierbei, dass Systemvariablen ausschlielich in Grobuchstaben definiert sind und das
hierbei die Gro- und Kleinschreibung zu bercksichtigen ist. Windows Installer-XML bietet auch die
Mglichkeit, benutzerdefinierte Variablen im jeweiligen Dokument zu verwenden. So ist es
beispielsweise mglich, die Quelldateien bzw. den Ordner der die Quelldateien enthlt durch eine
benutzerdefinierte Variable zu beschreiben:
<File Id="MyDemo" Source="$(var.SourceFolder)\Demo.exe" Name="Demo.exe" KeyPath="yes"
AssemblyManifest="Demo.exe" AssemblyApplication="Demo.exe"
Die verwendete Variable muss zuvor im Dokument definiert werden, wozu das Element <? define ?>
nach dem folgenden Schema zu verwenden ist:
<?define SourceFolder = ".\Binaries\" ?>
Zur effizienten Verwaltung der benutzerdefinierten Variablen bietet Windows Installer-XML

zustzlich die Mglichkeit so genannte Includedateien zu verwenden. Diese Dateiart ist vergleichbar
mit den Headerdateien (h) in C++, verfgt jedoch ber die Dateiendung .wxi.
<?xml version="1.0" encoding="utf-8"?>
<Include xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define SourceFolder
= ".\Binaries\" ?>
<?define HelpGuid
<?define ReadmeGuid
= "079D5F69-A2B5-4760-AEF9-6644F8F246A0" ?>
= "4E7D6BDD-6B35-4731-9474-1C028F446F65" ?>
<?if $(var.Config) = "debug" ?>

<?define ProductName
= "MSI Demo 1.0 (Debug)"?>
<?define ProductId
<?define AppBinariesGuid
<?define LibBinariesGuid
= "C418DE3A-7B13-426A-A054-E9793DD583FA" ?>
= "17F1A33F-BF41-4681-8E4E-2DA613244015" ?>
= "26518869-8F1F-4A9F-9EB1-AF6E240423D8" ?>
<?define BinaryFolder
= ".\Binaries\Debug\" ?>
<?else ?>
<?define ProductName
84
= "MSI Demo 1.0"?>
Kapitel 2
<?define ProductId
<?define AppBinariesGuid
<?define LibBinariesGuid
= "4916154D-6FA2-4729-945B-C34018467549" ?>
= "B7656789-A32E-463D-B7E7-9920BB9765AE" ?>
= "82B76300-2A08-4B6A-8773-1CACD9D1D8D1" ?>
<?define BinaryFolder
= ".\Binaries\Release\" ?>
<?endif ?>
</Include>
Listing 2.6: Definition von Variablen in einer Includedatei
Listing 2.6 zeigt ein Beispiel fr eine Includedatei, in der die benutzerdefinierte Variable
$(var.Config) zur Festlegung von Anwendungseinstellungen verwendet wird. Der Wert dieser
Variablen ist in dem Beispiel jedoch nicht definiert, sondern wird erst beim tatschlichen
Kompiliervorgang gesetzt. Bei der Verwendung von Visual Studio ist es erforderlich den
entsprechenden Wert in den Projekteinstellungen fr den Compiler zu definieren, wie dieses auch in
Abbildung 2.16 dargestellt wird. Ich werde an spterer Stelle noch auf die einzelnen Tools von
Windows Installer-XML eingehen. An dieser Stelle mchte ich nur darauf hinweisen, dass die
Erzeugung einer entsprechenden Ausgabedatei auch durch Befehlszeilentools mglich ist. Zum
Kompilieren ist die Anwendung candle.exe und zum Linken die Anwendung light.exe zu verwenden.
Hieraus folgt auch, dass beim Kompilieren ber die Befehlszeile, der entsprechende Wert einer
Variablen dem Befehlszeilenaufruf angefgt werden muss:
candle.exe
wixproject1.wxs -dConfig=debug
Windows Installer-XML enthlt in der Version 3 eine weitere Variablen-Form, die als WiXVariable
bezeichnet wird. Der groe Vorteil dieser Variablen liegt in der Flexibilitt, da sie bereits im WXSDokument definiert und mit einem Standardwert belegt werden kann. Dieser Standardwert kann jedoch
berschrieben werden, indem der neue Wert dem Befehlszeilenaufruf des Linkers angefgt wird. Es ist
ebenfalls mglich diesen neuen Wert in den Projekteinstellungen von Visual Studio zu definieren.
Nachfolgend wird die Definition einer WiXVariblen, sowie deren Verwendung im weiteren Projekt
verdeutlicht.

<WixVariable Id="TargetFolder" Value="Demo" Overridable="yes"/>
<Directory Id="INSTALLLOCATION" Name="!(wix.TargetFolder)">
Es ist zu beachten, dass im Gegensatz zu den bisher erluterten Variablen, eine WixVariable durch
!(wix.<Variable>) im Dokument zu referenzieren ist. Im Vergleich mit den bisherigen Variablen
bleibt zu bemerken, dass diese bereits whrend des Kompilierens bentigt wurden; ein aktualisierter
Wert fr die WiXVariable muss hingegen erst beim Linken vorhanden sein. Hieraus ergeben sich
interessante Anwendungsformen, da auf Basis einer Objektdatei mehrere individuelle Zielprodukte
erstellt werden knnen.
Zustzlich zu den Variablen stehen unter Windows Installer-XML auch die Prprozessor-Elemente
Bedingung und Iteration zur Verfgung, wobei Iterationen durch For-Each-Statements realisiert
werden knnen. Zur Definition von Bedingungen knnen die folgenden Elemente verwendet werden:
85
Kapitel 2
<?if ?>
<?ifdef ?>
<?ifndef ?>
<?else?>
<?elseif ?>
<?endif?>
Durch die Verwendung der Bedingungen ist es beispielsweise mglich, den Umfang der zu
installierenden Ressourcen anhand bestimmter Konfigurationseinstellungen einzuschrnken oder zu
erweitern:

<?if $(var.Config) = "debug" ?>
<File Id="SymbolFile" Source="$(var.BinaryFolder)" Name="Demo.pdb" KeyPath="no" DiskId="1" />
<?endif ?>
Zustzlich knnen auch Fehlermeldungen oder Warnungen ausgegeben werden, bei denen die
Voraussetzungen auf Basis der Bedingungen geprft werden. In dem vorherigen Beispiel kann geprft
werden, ob die Variable Config berhaupt definiert wurde. Ist das nicht der Fall, wird der
Kompiliervorgang beendet und eine entsprechende Fehlermeldung ausgegeben.
<?ifndef Config ?>
<?error Erforderliche Variable 'Config' wurde nicht definiert ?>
<?endif?>
Weitere Prprozessor-Elemente ergeben sich bei der Verwendung in Visual Studio. Hier besteht die
Mglichkeit das WIX-Projekt in eine Projektmappe zu integrieren und Elemente der anderen Projekte
zu referenzieren. Voraussetzung hierfr ist die Festlegung eines Verweises auf das entsprechende
Projekt, wie dieses auch in Abbildung 2.17 gezeigt wird.
86
Kapitel 2
Abbildung 2.17: Hinzufgen einer Referenz mit Visual Studio
Die weitere Referenzierung ist vergleichbar mit der Verwendung von Variablen, wobei der Name des
zu verwendenden Projektes angegeben werden muss. Soll beispielsweise eine Datei des Projektes
FootballChainer in ein Installationspaket integriert werden, so kann die folgende Definition
verwendet werden.
<File Id="AppFile" Name="$(var.FootballChainer.TargetFileName)"
Source="$(var.FootballChainer.TargetPath)" DiskId="1"/>
Eine Auflistung der mglichen Prprozessor-Variablen ist in Tabelle 2.18 zusammengefasst. Hierbei
gilt
es
zu
bercksichtigen,
dass
projektspezifische
Variablen
in
der
Form
$(var.<Projekt>.<Variable>) und Variablen, die auf die Projektmappe abzielen in der Form
$(var.<Variable>) zu verwenden sind.
Prprozessor-Variable
Beispiel
Ergebnis
var.Projektname.Configuration
$(var.App.Configuration)
Debug oder Release
var.Projektname.FullConfiguration
$(var.App.FullConfiguration)
Debug | AnyCPU
var.Projektname.Platform
$(var.App.Platform)
AnyCPU, x86, x64 oder ia64
var.Projektname.ProjectDir
$(var.App.ProjectDir)
D:\Setup\App\
var.Projektname.ProjectExt
$(var.App.ProjectExt)
.csproj
87
Kapitel 2
var.Projektname.ProjectFileName
$(var.App.ProjectFileName)
App.csproj
var.Projektname.ProjectName
$(var.App.ProjectName)
App
var.Projektname.ProjectPath
$(var.App.ProjectPath)
D:\Setup\App\App.csproj
var.Projektname.TargetDir
$(var.App.TargetDir)
D:\Setup\App\Bin\Debug\
var.Projektname.TargetExt
$(var.App.TargetExt)
.exe
var.Projektname.TargetFileName
$(var.App.TargetFileName)
App.exe
var.Projektname.TargetName
$(var.App.TargetName)
App
var.Projektname.TargetPath
$(var.App.TargetPath)
D:\Setup\App\Obj\Debug\App.exe
var.SolutionDir
$(var.SolutionDir)
D:\Setup\
var.SolutionExt
$(var.SolutionExt)
.sln
var.SolutionFileName
$(var.SolutionFileName)
MyApps.sln
var.SolutionName
$(var.SolutionName)
MyApps
var.SolutionPath
$(var.SolutionPath)
D:\Setup\MyApps.sln
Tabelle 2.18: Prprozessor-Variablen bei der Verwendung von Visual Studio
Bei der Verwendung der Microsoft Build Engine ist bei der Referenzierung eines anderen Projektes
immer die Projektmappen-Datei (.sln) als Quelle anzugeben. Die Angabe der Projektdatei (.wixproj)
fhrt zum Fehler, da die Projektreferenzen nicht aufgelst werden knnen.
Die Lokalisierung, also die Bereitstellung eines Installationspaketes in mehrere Sprachen ist mit den
gerade bezeichneten Mglichkeiten der Variablen und Includedateien problemlos mglich. Dennoch
stellt Windows Installer-XML fr diese Zwecke spezielle Sprachdateien zur Verfgung, die durch die
Dateiendung .wxl gekennzeichnet sind. Diese WXL-Dateien sind vergleichbar mit RessourceDateien der klassischen Softwareentwicklung. Der groe Vorteil der Sprachdateien begrndet sich
darin, dass Sie erst whrend des Linkens bentigt werden. Eine benutzerdefinierte Variable muss
bereits zur Kompilierzeit definiert sein, so dass die erzeugte Objektdatei bereits den endgltigen Wert
dieser Variablen enthlt. Bei der Verwendung von Sprachdateien wird die Definition der Variablen
hingegen erst whrend des Linkens geprft und ausgewertet. Hierdurch ist es mglich eine
sprachneutrale Objektdatei durch den Compiler erstellen zu lassen und diese zu einem spteren
Zeitpunkt als Quelle fr die lokalisierten Pakete zu verwenden, was vom zeitlichen Aspekt natrlich
uerst effizient ist. Sprachdateien sind ebenfalls im XML-Format zu definieren, wobei das
Stammelement <WixLocalization/> zu verwenden ist. Ich mchte die Verwendung der Sprachdateien
anhand eines Beispiels verdeutlichen, bei dem ich auch Includedateien verwende. Zunchst ist eine
WXL-Datei mit der Bezeichnung 1031.wxl zu erstellen, die deutschsprachige Zeichenfolgen enthlt,
wie dieses in Listing 2.7 dargestellt wird.
<?xml version="1.0" encoding="windows-1252"?>
<WixLocalization xmlns='http://schemas.microsoft.com/wix/2006/localization' Codepage="1252" Culture="de-DE" >
<String Id="Lang">1031</String>
<String Id="Name">MSI-Demo 1.0 (Deutsch)</String>
<String Id="Comment">Dieses Installationspaket enthlt die Daten des Produktes "MSI-Demo 1.0".</String>
88
Kapitel 2
<String Id="InstallFolder">MSI-Demo 1.0 (Deutsch)</String>

<String Id="FeatureTitle">Vollstndig</String>
<String Id="FeatureDescription">Installiert die Anwendung</String>
<String Id="FrameworkExist">Das Microsoft .NET Framework ist erforderlich.</String>
</WixLocalization>
Listing 2.7: Inhalt der deutschen Sprachdatei des Beispiels
Zustzlich ist eine weitere Sprachdatei erforderlich, die entsprechende englischsprachige Texte enthlt.
Diese ist in Listing 2.8 dargestellt und wird als 1033.wxl gespeichert.
<WixLocalization xmlns='http://schemas.microsoft.com/wix/2006/localization' Codepage="1252" Culture="en-US" >
<String Id="Lang">1033</String>
<String Id="Name">MSI Demo 1.0 (English)</String>
<String Id="Comment">This installer database contains the logic required to install "MSI Demo".</String>
<String Id="InstallFolder">MSI Demo 1.0 (English)</String>
<String Id="FeatureTitle">Complete</String>
<String Id="FeatureDescription">Installed all Features</String>
<String Id="FrameworkExist">This setup requires the .NET Framework version.</String>
</WixLocalization>
Listing 2.8: Inhalt der englischen Sprachdatei des Beispiels
Eine Includedatei kann verwendet werden um Variablen zu deklarieren und Konstanten festzulegen.
Die Verwendung als externe Datei ermglicht sehr flexible Lsungsanstze, da ein Austausch der
Datei mglich ist, ohne nderungen im Hauptdokument vorzunehmen. In dem Beispiel habe ich die
Includedatei config.wxi erstellt um das Verzeichnis der Binrdateien zu bestimmen und
Identifizierungsmerkmale festzulegen.
<Include>
<?define SourceFolder
= ".\Binaries\" ?>
<?define HelpGuid
= "B593614E-5EE5-415B-8DD9-8A8CD6A78826"
<?define ReadmeGuid
= "C0642C4A-B634-4F40-BD17-F7CECFB65087"
<?define ProductId
= "D5645496-67E7-4A07-9D85-14F857DB0BD1"
<?define AppBinariesGuid = "C708824B-7AF6-4DAC-ACF7-BDCBFAC95238"
<?define LibBinariesGuid = "123B06EC-4364-4876-9E68-99127BD9BABF"
</Include>
?>
?>
?>
?>
?>
Listing 2.9: Konfiguration unter Verwendung einer Includedatei
Letztlich sollen die Informationen aus den Sprachdateien und der Includedatei beim Erstellen der
Ausgabedatei verwendet werden, wozu sie in der jeweiligen WXS-Datei zu referenzieren sind, wie
dieses in Listing 2.10 dargestellt wird. Die lokalisierten Informationen werden im Hauptdokument wie
Variablen verwendet, wobei als Typ loc anzugeben ist. Um beispielsweise auf die Zeichenfolge
Name der Sprachdatei aus Listing 2.7 oder Listing 2.8 zuzugreifen ist im Hauptdokument die
Referenz $(loc.Name) zu verwenden.

<?include Config.wxi ?>
89
Kapitel 2
<Product UpgradeCode="4BE21D77-BA5D-42EC-9A1F-BCE9F3B5D82B" Manufacturer="Microsoft Deutschland GmbH"

Language="!(loc.Lang)" Version="1.00.0000" Name="!(loc.Name)" Id="$(var.ProductId)" Codepage="1252">
<Package Keywords="Microsoft Windows Installer, MSI
Description="!(loc.Name)" Comments="!(loc.Comment)"
Manufacturer="Andreas Kerl" InstallerVersion="200" Platform="x86" Languages="!(loc.Lang)"
Compressed="yes" SummaryCodepage="1252" InstallPrivileges="elevated" />
<Condition Message="!(loc.FrameworkExist)">MsiNetAssemblySupport</Condition>

<Icon Id="AppIcon.exe" SourceFile="$(var.SourceFolder)AppIcon.exe" />
<Directory Id="INSTALLLOCATION" Name="!(loc.InstallFolder)">
<Component Id="Hilfe.chm" Guid="$(var.HelpGuid)">
<File Id="Hilfe.chm" Source="$(var.SourceFolder)" Name="Hilfe.chm" KeyPath="yes" DiskId="1" />
</Component>
<Component Id="Readme.txt" Guid="$(var.ReadmeGuid)">
<File Id="Readme.txt" Source="$(var.SourceFolder)" Name="Readme.txt" KeyPath="yes" DiskId="1" />
</Component>
<Component Id="DD.exe" Guid="$(var.AppBinariesGuid)">
<File Id="DD.exe" Source="$(var.SourceFolder)" Name="DD.exe" KeyPath="yes" DiskId="1" />
<Shortcut Id="DD.exe" Directory="ProgramMenuFolder" Name="!(loc.InstallFolder)"
Target="Application" Hotkey="0" Icon="AppIcon.exe" IconIndex="0" Show="normal" />
</Component>
<Component Id="Common.dll" Guid="$(var.LibBinariesGuid)">
<File Id="Common.dll" Source="$(var.SourceFolder)" Name="Common.dll" KeyPath="yes" DiskId="1" />
</Component>
</Directory>
</Directory>
<Directory Id="ProgramMenuFolder" />
</Directory>

<Feature Id="Application" Title="!(loc.FeatureTitle)" Description="!(loc.FeatureDescription)" Level="1">
<ComponentRef Id="DD.exe" />
<ComponentRef Id="Common.dll" />
<ComponentRef Id="Readme.txt" />
<ComponentRef Id="Hilfe.chm" />
</Feature>
</Product>
</Wix>
Listing 2.10: Referenzieren von Sprachinformationen und Variablen in einem WXS-Dokument
Die Erstellung der Ausgabedatei kann natrlich wieder ber die Befehlszeile erfolgen. Werden
90
Kapitel 2
Sprachdateien im Projekt verwendet, mssen diese der Befehlszeile des Linkers mit dem Argument loc bergeben werden.
candle.exe Product.wxs
light.exe -out 1031.msi Product.wixobj -loc 1031.wxl
light.exe -out 1033.msi Product.wixobj -loc 1033.wxl
Einfacher und im Hinblick auf automatisierte Buildprozesse auch flexibler, ist die Erstellung mit
Visual Studio. Hierzu ist zunchst ein entsprechendes Visual Studio-Projekt zu erstellen, wie es in
Abbildung 2.18 dargestellt wird.
Abbildung 2.18: Struktur des Beispielprojektes
Der Buildvorgang kann nun durch die bekannten Mechanismen gestartet werden. Es werden
standardmig zwei Installationspakete erzeugt, da auch zwei Sprachdateien vorhanden sind. ber die
Projekteinstellungen, kann der Umfang der zu erstellenden Installationspakete hinsichtlich der Kultur
eingeschrnkt werden.
Fragmente
Gerade bei der Arbeit in Entwicklungsteams besteht die Anforderung, das Gesamtdokument zur
Erstellung der Installationsdatei, in mehrere physische Dateien aufzuteilen. Die involvierten
Entwickler knnten hierdurch die installationsspezifischen Beschreibungen, der von Ihnen
entwickelten Komponente selbst vornehmen, wobei erst im spteren Buildprozess diese Informationen
in das Gesamtdokument einflieen. Dies ist ohne Probleme mglich, denn Windows Installer-XML
stellt fr solche Zwecke einen Building-Block zur Verfgung, der als Fragment bezeichnet wird und
die folgenden Vorteile bietet:
Das Gesamtdokument kann funktional getrennt werden. Hierdurch ist es beispielsweise mglich
die Darstellung von der Implementierung unabhngig zu entwickeln und zu pflegen.
Komponenten, die von mehreren Installationsprogrammen bentigt werden, knnen separat
entwickelt werden, wodurch die Fehleranflligkeit minimiert wird. Diese wiederverwendbaren
Teilkomponenten, zu denen auch die Benutzeroberflche gehrt, knnen vorkompiliert werden,
wodurch der Buildprozess beschleunigt werden kann.
91
Kapitel 2
Die Aufteilung des Gesamtdokumentes in mehrere physische Dateien ermglicht den effektiven
Einsatz in Entwicklungsteams. Die involvierten Entwickler knnen bei solchen Voraussetzungen
die installationsspezifischen Beschreibungen, der von Ihnen entwickelten Komponente selbst
vornehmen, wobei erst im spteren Buildprozess diese Informationen in das Gesamtdokument
einflieen.
Die Definition eines Fragmentes erfolgt durch den WIX-Elementtyp <Fragment/>, der wiederum
diverse Unter-Elemente aufnehmen kann. Diese untergeordneten Elemente knnen vom
Hauptdokument referenziert werden. Es ist ebenfalls mglich auf Informationen des Hauptdokumentes
zuzugreifen. Weiterhin ist natrlich auch ein Zugriff zwischen mehreren Fragmenten mglich. Zur
Referenzierung stehen die Elementtypen <UIRef/>, <DialogRef/>, <BinaryRef/>, <PropertyRef/>,
<CustomActionRef/>,
<FeatureRef/>,
<DirectoryRef/>,
<DirectorySearchRef/>,
<EmbeddedChainerRef/>, <FeatureGroupRef/>, <FileSearchRef/>, <IconRef/>, <MergeRef/>,
<PatchFamilyRef/>, <RegistrySearchRef/>, <ComponentRef/> oder <ComponentGroupRef/> zur
Verfgung. Im folgenden Listing 2.11 ist das Hauptdokument eines Projektes zu sehen. Interessant ist
hierbei die Ordnerstruktur, da diese nur modelliert wurde, jedoch keine Komponenten enthlt. Anders
ist es bei der Feature-Struktur. Hier findet sich eine Referenz auf ein untergeordnetes Feature, das in
dem Dokument gar nicht definiert ist und sich somit in einem Fragment befinden muss.

<Product UpgradeCode="4BE21D77-BA5D-42EC-9A1F-BCE9F3B5D82B" Manufacturer="Microsoft Deutschland GmbH"
Language="1031" Version="1.00.0000" Name="MSI-Test 1.0"
Id="AA387173-BADA-4261-8B81-40207CDD14EB" Codepage="1252">

<Package Keywords="Microsoft Windows Installer, MSI" Description="MSI-Test 1.0"
Manufacturer="Andreas Kerl" InstallerVersion="200" Platform="x86" Languages="1031"
Compressed="yes" SummaryCodepage="1252" />

<Directory Id="INSTALLLOCATION" Name="MSI-Test 1.0">
</Directory>
</Directory>
</Directory>
<Feature Id="Application" Title="Anwendung" Description="Installiert die Anwendung" Level="1">
<FeatureRef Id="SubApplication"/>
</Feature>

</Product>
</Wix>
Listing 2.11: Hauptdokument zur Verwendung eines Fragments
Das Fragment ist wesentlich einfacher aufgebaut als das Hauptdokument. In Listing 2.12 sind die zu
installierenden Komponenten erkennbar. Die Zuordnung zu einem Zielverzeichnis erfolgt durch eine
92
Kapitel 2
Referenzierung zu einer Definition im Hauptdokument. Zustzlich ist ein neues Feature definiert, dem
diese Komponenten zugeordnet wurden. Dieses Feature wird wie bereits erwhnt vom Hauptdokument
referenziert.
<?xml version="1.0" encoding="UTF-8"?>
<Fragment>

<DirectoryRef Id="INSTALLLOCATION">
<Component Id="DD.exe" Guid="6ABBEDC4-3D20-4901-BBAE-D6D16127571A">
<File Id="DD.exe" Source=".\Binaries\" Name="DD.exe" KeyPath="yes" DiskId="1" />
</Component>
<Component Id="Common.dll" Guid="332C7990-C503-4992-8494-4151FEF834AB">
<File Id="Common.dll" Source=".\Binaries\" Name="Common.dll" KeyPath="yes" DiskId="1" />
</Component>
</DirectoryRef>

<Feature Id="SubApplication" Title="DD" Level="3">
<ComponentRef Id="DD.exe" />
<ComponentRef Id="Common.dll" />
</Feature>
</Fragment>
</Wix>
Listing 2.12: Aufbau und Struktur eines Fragmentes
Beim Kompilieren und beim Linken ist zu beachten, dass die physische Datei, in der das Fragment
definiert wurde, den entsprechenden Befehlszeilen anzufgen ist.
candle.exe Product.wxs Fragment.wxs
light.exe -out Product.msi Product.wixobj Fragment.wixobj
Bei Verwendung von Visual Studio ist es zur Erstellung eines neuen Fragments ausreichend, ein neues
Element vom Typ WiX File dem Projekt hinzuzufgen. Es ist erkennbar, dass dieses neue
Dokument bereits als Fragment gekennzeichnet ist, so dass die erforderlichen Daten in diesem
Dokument direkt erfasst werden knnen.
Hinweis Beginn
Es ist nicht erforderlich, ein Fragment in eine separate Datei auszulagern. Es besteht natrlich auch die
Mglichkeit mehrere Fragmente in einer physischen Datei zusammenzufassen oder Fragmente mit
dem Hauptprojekt zu verknpfen.
Hinweis Ende

Es ist natrlich nicht immer erforderlich oder gewnscht den Buildprozess mit Visual Studio oder der
Microsoft Build Engine durchzufhren. Die Modularitt von Windows Installer-XML ermglicht auch
die Erstellung durch Befehlszeilentools, wie dieses bereits angedeutet wurde. Das Windows InstallerPersnliche Ausfertigung fr Martin Martinsson
93
Kapitel 2
XML Framework enthlt eine Vielzahl von Tools, Anwendungen, Spezifikationen und
Dokumentationen, von denen die wichtigsten in Tabelle 2.19 zusammengefasst sind.
Tool
Beschreibung
candle.exe
Kompiliert WiX-Quelldateien in Objektdateien (.wixobj).
dark.exe
Konvertiert eine Windows Installer-Datei (.msi oder .msm) in WXS-Dateien.
heat.exe
Tool zum Erzeugen von Windows Installer-XML-Dateien.
light.exe
Erstellt aus den Objektdateien die konfigurierten Windows Installer-Dateien (.msi

oder .msm).
lit.exe
Tool zum Erzeugen von Windows Installer-XML-Bibliotheken.
pyro.exe
Tool zum Erzeugen von Patches.
melt.exe
berfhrt Mergemodule in Komponentengruppen einer WXS-Quelldatei.
smoke.exe
Tool zum Validieren von Windows Installer-Paketen.
torch.exe
Tool zum Erzeugen von Transformationen.
wixcop.exe
Tool zum Validieren von WiX-Dokumenten und zum konvertieren in das Format der
Version 3.
wix.chm
Hilfedatei zu Windows Installer-XML.
wix.dll
Bibliothek die alle Funktionalitten enthlt und daher fr programmtechnische

Anstze verwendet werden kann.
*extension.dll
Erweiterungsbibliotheken zur Verwendung in unterschiedlichen Szenarien.
*.xsd
Diverse XML-Schemata.
Tabelle 2.19: Wichtige Tools und Anwendungen in Windows Installer-XML
Die berwiegende Anzahl der Anwendungen kann vllig eigenstndig verwendet werden, wie das
beispielsweise bei smoke.exe oder dark.exe der Fall ist. Auf der anderen Seite bauen einige Tools
aufeinander auf, wodurch die Ausgabe des einen Tools als Eingabe eines anderen Tools zu verwenden
ist. Das Zusammenspiel der einzelnen Tools zeigt Abbildung 2.19.
94
Kapitel 2
Abbildung 2.19: Zusammenspiel der Bestandteile von Windows Installer-XML
Aus dem Ablaufdiagramm wird ebenfalls deutlich, dass unterschiedliche Dateien und Dateitypen von
den jeweiligen Tools bentigt werden. Die mit Windows Installer-XML erzeugten und verwendeten
Dateitypen zeigt Tabelle 2.20.
Erweiterung
Typ
Beschreibung
.wxi
Include-Datei
Hierbei handelt es sich um die bereits beschriebene Include-Datei. Das

Root-Element dieser Datei ist <Include/>.
.wxl
LokalisierungsDatei
Eine solche Datei enthlt lokalisierte Zeichenfolgen. Hiermit ist es

mglich die allgemeinen Informationen von den sprachspezifischen
Merkmalen zu trennen. Das Root-Element dieser Datei ist
<WixLocalization/>.
.wxs
Quellcode-Datei
Dieses ist die Quellcode-Datei. Das Root-Element dieser Datei ist

<Wix/>.
.wixobj
Objekt-Datei
Eine solche Datei wird fr jede Quellcode-Datei durch den Compiler

erzeugt. Sie enthlt Symbole und Referenzen.
95
Kapitel 2
.wixout
XMLAusgabedatei
Eine solche Datei wird durch den Linker erzeugt. Diese Dateiart ist die
XML-Reprsentation der finalen Ausgabe.
.wixlib
WiX-Bibliothek
Hierbei handelt es sich um eine vorkompilierte Bibliotheksdatei, die

beim Linken als Quelle angegeben werden kann.
.wixpdb
Symboldatei
Eine solche Datei wird fr jede Ausgabedatei durch den Linker erzeugt.
Sie enthlt Debugging-Informationen.
.wixmsp
XML-Patchdatei
Dieses ist die XML-Reprsentation, die durch den Linker beim

Erzeugen eines Patches erstellt wird.
.wixmst
XMLTransformation
Hierbei handelt es sich um die XML-Reprsentation der Differenz

zweier Ausgabedateien.
Tabelle 2.20: Von Windows Installer-XML erzeugte und verwendete Dateitypen
Erzeugen der Quelldateien

Wie in dem Ablaufdiagramm ersichtlich besteht der erste Schritt darin, den Quellcode zu erzeugen.
Hiermit gemeint ist das WXS-Dokument, in dem die Darstellung des spteren Installationsergebnisses
beschrieben ist. Die individuelle Erstellung einer solchen Datei erfolgt in vielen Fllen auf manuelle
Art. Allerdings gibt es im Internet eine Vielzahl von Anwendungen mit denen sehr komfortabel solche
Dateien erzeugt werden knnen. Auch die Integration von Windows Installer-XML fr Visual Studio
soll in diese Richtung weiter entwickelt werden. Hier ist geplant einen hierarchischen Designer zum
Verwalten von Features, Komponenten, Dateien und Schssel der Systemregistrierung zu integrieren.
Weiterhin soll es auch irgendwann mglich sein, dass Design der Benutzeroberflche zu gestalten und
Installationen unter Verwendung eines Debuggers zu testen.
Ich mchte an dieser Stelle andere Optionen aufzeigen, entsprechende Quelldokumente zu erhalten. So
sind in Windows Installer-XML einige Tools enthalten, mit denen entsprechende Dokumente erzeugt
werden knnen, wobei diese unterschiedliche Quellen verwenden.
WixCop.exe
Mit diesem Tool ist es mglich, bestehende WXS-Dokumente einer lteren Version von Windows
Installer-XML in das Format der Version 3 zu konvertieren. Eine andere Aufgabe betrifft die
berprfung des vorliegenden Dokumentes auf Probleme hinsichtlich der XML-Struktur und die
Formatierung eines Dokumentes. Die Erzeugung eines WXS-Dokumentes kann mit jedem Texteditor
erfolgen, wodurch das Ergebnis hinsichtlich der Darstellung unterschiedlich ausfallen kann. Mit
wixcop.exe ist es mglich, das Dokument automatisch zu formatieren um hier ein einheitliches
Erscheinungsbild zu bekommen. Wird als Quelldatei ein WXS-Dokument verwendet, das mit einer
lteren Version von Windows Installer-XML erstellt wurde, kann dieses in die neue Version
konvertiert werden. Die Aufrufsyntax gestaltet sich wie folgt:
wixcop.exe [Optionen] Quelldatei [Quelldatei ...]
Beim Aufruf knnen mehrere Quelldateien angegeben werden, wobei auch Platzhalter fr die Namen
erlaubt sind. Werden bei der berprfung keine Fehler festgestellt, wird wixcop.exe mit dem ExitCode 0 beendet. Kommt es zu einem Fehler bei der Programmausfhrung wird 1 zurckgeliefert.
96
Kapitel 2
Wird hingegen festgestellt, dass das Dokument einen Fehler aufweist wird das Tool mit 2 beendet.
Die folgende Tabelle zeigt die Optionen, mit denen die berprfung beeinflusst werden kann.
Schalter
Beschreibung
-?
Zeigt die Hilfe
-f
Fehler in den zu berprfenden Dokumenten werden automatisch behoben, wenn die

Dateien nicht schreibgeschtzt sind.
-s
Sucht nach Quelldateien auch in Unterverzeichnissen.
-indent:n
berschreibt den Standardwert fr den Einzug, der auf 4 Leerzeichen festgelegt ist.
-set1filename
Ldt eine primre Konfigurationsdatei. Es ist zu beachten, dass zwischen dem Schalter und
dem Pfad der Einstellungsdatei keine Leerzeichen eingefgt werden drfen.
-set2filename
Ldt eine zustzliche Konfigurationsdatei. Die hier vorgenommenen Einstellungen

berschreiben die Einstellungen der primren Datei.
Tabelle 2.21: Befehlszeilenoptionen von wixcop.exe
In den Befehlszeilenoptionen wurde auf die Verwendung von Konfigurationsdateien hingewiesen.

Hierdurch ist es mglich, die berprfung des Dokumentes zu beeinflussen. Die primre
Konfigurationsdatei sollte verwendet werden um globale Vorgaben zu definieren. Die sekundre Datei
kann verwendet werden um projektbezogene Einstellungen zu definieren, die somit die globalen
Vorgaben ergnzen oder berschreiben. In den Einstellungsdateien kann festgelegt werden, dass
bestimmte Fehler zu ignorieren sind, wozu das Element <IgnoreErrors/> zu verwenden ist. Das
Element <ErrorsAsWarnings/> ist nicht ganz so stringent bei der berprfung. Hiermit kann
festgelegt werden, dass bestimmte Fehler lediglich als Warnung interpretiert werden. Als letztes
ermglicht das Element <ExemptFiles/> noch den Ausschluss bestimmter Dateien aus dem
Prfvorgang. Ein Beispiel fr eine solche Konfigurationsdatei zeigt Listing 2.13.
<Settings>
<IgnoreErrors>
<Test Id="WhitespacePrecedingNodeWrong" />
</IgnoreErrors>
<ErrorsAsWarnings>
<Test Id="WhitespacePrecedingEndElementWrong" />
<Test Id="DeclarationMissing" />
</ErrorsAsWarnings>
<ExemptFiles>
<File Name="foo.wxs" />
<File Name="bar.wxs" />
</ExemptFiles>
</Settings>
Listing 2.13: Konfiguration des berprfungsumfangs mit wixcop.exe
Die Dokumentation von Windows Installer-XML enthlt eine Auflistung aller Prfungen, die von
wixcop.exe durchgefhrt werden. Hier finden sich auch die IDs, die in den entsprechenden
Konfigurationsdateien zu verwenden sind.
Heat.exe
Das wahrscheinlich unscheinbarste Tool ist heat.exe, dessen Funktionsumfang allerdings nicht
97
Kapitel 2
unterschtzt werden sollte. Bei heat.exe handelt es sich um einen sogenannten Harvester, also ein
Tool zum Sammeln von Informationen fr die Installation. Nehmen Sie als Beispiel ein einfaches
Installationspaket, das lediglich Dateien installieren soll. Hierzu muss zunchst ein WXS-Dokument
erzeugt werden, in dem die entsprechenden Dateien definiert werden mssen. Zunchst ist eine
Komponente zu erzeugen und dieser Komponente muss die Datei mit den entsprechenden
Metainformationen zugeordnet werden. Das bedeutet natrlich auch, dass in Abhngigkeit zum
Dateityp unterschiedliche Betrachtungsweisen erfolgen mssen. Handelt es sich beispielsweise um
eine COM-Komponente, mssen die zugehrenden Registrierungsinformationen ebenfalls ausgelesen
und im WXS-Dokument entsprechend abgelegt werden. Handelt es sich um ein .NET-Assembly, sind
die spezifischen Assembly-Attribute dem Element <File/> anzufgen. Handelt es sich um eine Datei
mit Versionsangabe, mssen die Versionsinformationen bernommen werden. Verfgt die Datei ber
keine Versionsinformationen ist ein Hash zu berechnen und der entsprechenden Tabelle zuzuordnen.
Es wird deutlich, dass der Aufwand zum Ermitteln dieser Informationen und deren Speicherung im
WXS-Dokument nicht zu unterschtzen ist. An dieser Stelle kommt heat.exe ins Spiel. Das Tool
ermittelt automatisch alle erforderlichen Informationen und erstellt daraus ein WXS-Dokument.
Hierbei ist es mglich, die Informationen fr eine einzelne Datei oder ein komplettes Verzeichnis
abzurufen, wozu die folgenden Befehlszeilenaufrufe zu verwenden sind:
heat.exe dir [Optionen] [Verzeichnis] -out Datei.wxs
heat.exe file [Optionen] [Dateiname] -out Datei.wxs
Durch die Optionen kann beispielsweise gesteuert werden, welches Format die Ausgabedatei besitzen
soll, ob die GUIDs fr die Komponenten automatisch generiert werden sollen und in welcher Form die
COM-Informationen abgespeichert werden sollen. Eine vollstndige Auflistung der Schalter ist in
Tabelle 2.22 zu finden.
Schalter
Beschreibung
-ag
Automatische Generierung von GUIDs fr Komponenten, aber erst beim Kompilieren

des Projektes.
-gg
Automatische Generierung von GUIDs fr die Komponenten.
-ke
Leere Verzeichnisse werden ebenfalls bernommen. Dieser Schalter ist nur auf
Ordnerebene verfgbar.
-out
Festlegen der Ausgabedatei.
-pog:<Gruppe>
Festlegen der zu verwendenden Informationen eines Visual Studio-Projektes. Mgliche

Optionen sind: Binaries, Symbols, Documents, Satellites, Sources oder Content.
-scom
Alle COM-Informationen werden der Tabelle Registry angefgt; die COM-Tabellen

(Class, TypeLib, etc.) werden nicht verwendet.
-sfrag
Die Speicherung der Informationen als einzelne Fragment-Abschnitte wird unterdrckt.
-sreg
Es werden keine Daten aus der Systemregistrierung bernommen.
-suid
Die Erstellung eindeutiger Bezeichner fr Dateien, Verzeichnisse und Ordner wird

unterdrckt.
-template:product
Die Ausgabe erfolgt in ein Dokument vom Typ <Product/>. Alle Ordner werden
98
Kapitel 2
hierbei unter TARGETDIR angeordnet und alle Komponenten werden dem StandardFeature angefgt.
-template:module
Die Ausgabe erfolgt in ein Dokument vom Typ <Module/>.
-template:fragment
Die Ausgabe erfolgt in ein Dokument vom Typ <Fragment/>.
Tabelle 2.22: Schalter zum Ermitteln von Informationen mit heat.exe
Im Installationsverzeichnis von Windows Installer-XML befindet sich unter anderem die Datei
mergemod.dll. Die Ermittlung von Informationen zu dieser Datei kann mit dem folgenden Befehl
durchgefhrt werden:
heat.exe file -template:fragment -gg -sfrag mergemod.dll -out mm.wxs
Das Ergebnis dieses Aufrufs ist ein WXS-Dokument vom Typ Fragment, das in Listing 2.14
dargestellt ist.
<Fragment>
<Directory Id="bin" Name="bin">
<Component Id="mergemod.dll" Guid="{E202E2EF-D3F5-476D-9473-EDE11FDDA2A8}">
<File Id="mergemod.dll" Name="mergemod.dll" KeyPath="yes"
Source="C:\Program Files (x86)\Windows Installer XML v3\bin\mergemod.dll">
<Class Id="{0ADDA830-2C26-11D2-AD65-00A0C9AF11A6}" Context="InprocServer32"
Description="MSM Merge COM Server" ThreadingModel="both">
<ProgId Id="MSM.Merge.1" Description="MSM Merge COM Server">
<ProgId Id="MSM.Merge" Description="MSM Merge COM Server" />
</ProgId>
</Class>
<Class Id="{F94985D5-29F9-4743-9805-99BC3F35B678}" Context="InprocServer32"
Description="MSM Merge Extended COM Server" ThreadingModel="both">
<ProgId Id="MSM.Merge2.1" Description="MSM Merge Extended COM Server">
<ProgId Id="MSM.Merge2" Description="MSM Merge Extended COM Server" />
</ProgId>
</Class>
</File>
<RegistryValue Root="HKLM"
Key="Software\Classes\Interface\{0ADDA827-2C26-11D2-AD65-00A0C9AF11A6}\ProxyStubClsid"
Value="{00020424-0000-0000-C000-000000000046}" Type="string" Action="write" />
<RegistryValue Root="HKLM"
Key="Software\Classes\TypeLib\{0ADDA82F-2C26-11D2-AD65-00A0C9AF11A6}\2.0"
Value="Microsoft MSM Merge Type Library" Type="string" Action="write" />
</Component>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ComponentGroup1">
<ComponentRef Id="mergemod.dll" />
</ComponentGroup>
</Fragment>
</Wix>
99
Kapitel 2
Listing 2.14: Ermittelte Informationen zu einer Datei
Mit heat.exe ist es auch mglich, Informationen aus Visual Studio-Projekten zu extrahieren. Die
folgende Codezeile erstellt auf Basis eines Visual Studio-Projektes ein WXS-Dokument, dem die
Quell- und Binrdateien des Projektes hinzugefgt werden.
heat.exe project -gg -pog:Sources -pog:Binaries substg.csproj -out out.wxs
Zustzlich zu den Informationen auf Datei-, Ordner und Projekt-ebene, kann heat.exe auch
Informationen von Websites sammeln und ablegen.
Dark.exe
Ein weiteres sehr interessantes Tool ist dark.exe. Dieses Tool ist fr den Personenkreis sehr
interessant, der bereits andere Anwendungen oder Technologien zum Erzeugen von Windows
Installer-Dateien einsetzt und nun zu Windows Installer-XML wechselt. Bei dark.exe handelt es sich
um einen Decompiler fr Windows Installer-Dateien, also um eine Anwendung, die aus einem
Installationspaket das zugrunde liegende WXS-Dokument konstruiert. Die generelle Aufrufsyntax
gestaltet sich wie folgt
dark.exe [-?] [-nologo] Datenbank.msi [Ausgabe.wxs]
Es knnen verschiedene Optionen verwendet werden, um das Zielprodukt, also das WXS-Dokument,
ergebnisorientiert anzupassen. Es besteht die Mglichkeit, die im Paket enthaltenen Ressourcen zu
extrahieren oder auf den Export der Informationen zur Darstellung der Benutzeroberflche gnzlich zu
verzichten. Eine vollstndige Auflistung der Optionen ist in Tabelle 2.23 zu finden.
Schalter
Beschreibung
-nologo
Die Anzeige des Logos der Anwendung wird unterdrckt.
-notidy
Die temporren Dateien werden nicht gelscht. Diese Option ist beim Debugging hilfreich.
-o[ut]
Festlegen der Ausgabedatei. Standardmig wird ein WXS-Dokument im aktuellen Verzeichnis

erstellt.
-sct
Es werden keine benutzerdefinierten Tabellen bertragen.
-sdet
Standardmig werden leere Tabellen nicht im WXS-Dokument definiert. Durch diese Option
werden auch leere Tabellen bertragen, indem diese mit dem Element EnsureTable
gekennzeichnet werden.
-sras
Standardmig werden die Aktionen relativ zueinander angeordnet. Mit dieser Option ist es
mglich, eine absolute Anordnung zu erreichen, indem die Sequenznummern bertragen werden.
-sui
Es werden keine Tabellen bertragen, die zur Darstellung der Benutzeroberflche dienen.
-sw[N]
Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1059 -sw1067)
-v
Gibt zustzliche Informationen mit aus.
-wx[N]
Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert
100
Kapitel 2
(Beispiel: -wx1059 -wx1067)

-x <Pfad>
Exportiert die Inhalte der Kabinettdateien und die eingebetteten Binrdateien in den angegebenen
Ordner.
-xo
Anstelle eines WXS-Dokumentes wird ein WIXOUT-Dokument erstellt. Diese Dokumentart ist
hilfreich zur Erstellung von Transformationen und Patches.
Tabelle 2.23: Schalter um Dekompilieren einer Windows Installer-Datei mit dark.exe
Die nachfolgende Befehlszeile erzeugt aus dem Installationspaket wix3.msi ein entsprechendes WXSDokument, wobei die Informationen zur Gestaltung der Benutzeroberflche ignoriert werden.
Gleichzeitig werden die im Paket enthaltenen Ressourcen extrahiert und in dem Unterordner bin
abgelegt.
dark.exe wix3.msi wix3.wxs -sui -x .\bin
Das Tool dark.exe entscheidet anhand des vorliegenden Formates in welchen Dokumenttyp die
Informationen umgewandelt werden. Ein Windows Installer-Paket (.msi) wird hierbei in ein Dokument
vom Typ Product umgewandelt. Ein Windows Installer-Mergemodul (.msm) in ein Dokument vom
Typ Module und ein Patch Creation Property File (.pcp) in den Typ PatchCreation. Die so erzeugten
Dateien knnen mit dem Compiler und Linker wieder in eine entsprechende Windows Installer-Datei
berfhrt werden.
Anders verhlt es sich bei Ursprungsdateien vom Typ Windows Installer-Patch (.msp) und Windows
Installer-Transformation (.mst). Diese werden direkt in ein WIXOUT-Dokument verwandelt und
knnen danach mit dem Linker in die entsprechende Windows Installer-Datei berfhrt werden. Die
folgende Befehlszeile erstellt aus der Windows Installer-Transformation diff.mst die entsprechende
Ausgabedatei.
dark.exe diff.mst -out diff2.wxs
Da es sich bei der Ausgabedatei um eine Textdatei im XML-Format handelt, kann diese natrlich sehr
einfach wieder modifiziert werden. Anschlieend gengt ein Aufruf des Linkers um diese Datei wieder
in einer regulre Transformation umzuwandeln.
light.exe diff2.wxs -out diff2.mst
Es wird deutlich, dass die Verwendung von dark.exe auch mit speziellen Windows Installer-Dateien
durchaus seine Vorteile bietet. Denn eine solche nderungsmglichkeit bei Transformationen sucht
man bei klassischen Anstzen ber das Windows Installer-SDK vergebens.
Melt.exe
Mergemodule dienen zum speichern und verwalten von wiederverwendbaren Teilen des
Installationspaketes und sind daher uerst hilfreich. Dennoch existieren einige gravierende Probleme
mit Mergemodulen, die noch an spterer Stelle in diesem Buch erlutert werden. An dieser Stelle ist
101
Kapitel 2
jedoch ein Kritikpunkt besonders gravierend, der auf das proprietre Dateiformat des Mergemoduls
abzielt. Hierbei handelt es sich um ein Binrformat, so dass eine effektive Verwaltung in
Versionskontrollsystemen nur uerst schwierig realisierbar ist. Dieses begrndet sich darauf, dass es
beim Binrformat nicht mglich ist, eine exakte Visualisierung der nderungen zu erhalten, die im
Entwicklungszeitraum vorgenommen werden. Eine solche Funktionalitt ist nur mit Dateien im
Textformat problemlos erreichbar. An dieser Stelle kommt nun melt.exe ins Spiel. Mit diesem Tool ist
es mglich, den Inhalt eines Mergemoduls in ein WXS-Dokument vom Typ Fragment zu bertragen.
Es wird aber auch deutlich, dass dieses Tool hnlichkeiten mit dark.exe aufweist. Allerdings
verwendet dark.exe einen generischen Ansatz und zielt somit auf unterschiedliche Dateiarten ab. Mit
dark.exe ist es jedoch nicht mglich eine Konvertierung vorzunehmen, so dass ein Mergemodul
hiermit immer in ein Dokument vom Typ Module berfhrt wird. Bei der Verwendung von melt.exe
findet hingegen eine Konvertierung statt. Die Inhalte eines Mergemoduls werden in ein Fragment
bertragen, dass wiederum mit einem Produkt zusammengefhrt werden kann oder unter Verwendung
von lit.exe in eine Windows Installer-XML-Bibliothek kompiliert werden kann. Die Aufrufsyntax ist
nachfolgend dargestellt.
melt.exe [-?] [-nologo] Datenbank.msm Ausgabe.wxs
Wie auch bei allen anderen Tools lassen sich die Ausgabeoptionen weiter beeinflussen. Hierzu stehen
die in Tabelle 2.24 aufgefhrten Schalter zur Verfgung. Es ist nicht verwunderlich, dass diese
hnlichkeiten zu dark.exe aufweisen.
Schalter
Beschreibung
-id Name
Anstelle der Modul-Id kann ein anderes Identifizierungsmerkmal angegeben werden.
-nologo
-notidy
Die temporren Dateien werden nicht gelscht. Diese Option ist beim Debugging hilfreich.
-sw[N]
-v
-wx[N]

-x <Pfad>
Exportiert die Inhalte der Kabinettdateien und die eingebetteten Binrdateien in den
angegebenen Ordner.
Tabelle 2.24: Schalter zum Konvertieren eines Mergemoduls mit melt.exe
Die Toolsammlung Logo Testing Tools for Windows enthlt mehrere Mergemodule, die im Rahmen
der Zertifizierung verwendet werden. Eines davon wird zum Testen der Rollback-Funktionalitt
bentigt und trgt die Bezeichnung FailInstallFromDeferredCustomAction.msm. Die Umwandlung mit
melt.exe kann durch die folgende Befehlszeile realisiert werden.
Melt.exe FailInstallFromCommitCustomAction.msm output.wxs
Das Ergebnis ist das WXS-Dokument output.wxs vom Type Fragment, dass in Listing 2.15 dargestellt
102
Kapitel 2
wird. Zu erkennen sind hierbei sehr gut die Identifizierungsmerkmale des Mergemoduls, die jedoch im
Rahmen der Konvertierung angepasst werden knnen.
<Fragment>
<Binary Id="FailHere.156F8A4A_069C_403C_A1DD_3D624343D812"
SourceFile="D:\003\Binary\FailHere.156F8A4A_069C_403C_A1DD_3D624343D812" />
<ComponentGroup Id="VistaLogoFailHereTestModule.156F8A4A_069C_403C_A1DD_3D624343D812" />
<CustomAction Id="FailHere.156F8A4A_069C_403C_A1DD_3D624343D812"
BinaryKey="FailHere.156F8A4A_069C_403C_A1DD_3D624343D812" DllEntry="FailHere" Execute="deferred" />
<DirectoryRef Id="VistaLogoFailHereTestModule.156F8A4A_069C_403C_A1DD_3D624343D812" />
<Property Id="VistaLogoFailHereTestModule.156F8A4A_069C_403C_A1DD_3D624343D812"
Value="VistaLogoFailHereTestModule.156F8A4A_069C_403C_A1DD_3D624343D812" />
<InstallExecuteSequence>
<Custom Action="FailHere.156F8A4A_069C_403C_A1DD_3D624343D812" Before="InstallFinalize" />
</InstallExecuteSequence>
</Fragment>
</Wix>
Listing 2.15: In ein Fragment konvertiertes Mergemodul
Dieses Fragment kann nun wie zuvor erlutert, von einem anderen Dokument aus referenziert werden,
so dass die Informationen whrend des Buildprozesses auch in das Zielprodukt einflieen.
Kompilieren und Linken

Nachdem die erforderlichen Informationen in ein WXS-Dokument bertragen wurden, sind alle
Voraussetzungen geschaffen, diese in eine Windows Installer-Datei zu berfhren. Die Art der hierbei
erzeugten Datei ist vom Typ des verwendeten WXS-Dokumentes abhngig. Wie in Abbildung 2.15
verdeutlicht, orientiert sich Windows Installer-XML beim erzeugen dieser Datei am klassischen
Erstellungsprozess fr Software. Hierdurch ergibt sich, dass im ersten Schritt eine Kompilierung der
zugrundeliegenden Dateien erfolgt, wozu der Compiler candle.exe bentigt wird.
Candle.exe
Innerhalb der Kompilierphase werden die Informationen der WXS-Dokumente auf Gltigkeit geprft,
die Variablen aufgelst und die Ergebnisse in WIXOBJ-Dateien abgelegt. Der Wesentliche Aspekt
innerhalb dieses Vorgangs ist das Prfen der Daten auf Gltigkeit, wozu primr die Schemadatei
wix.xsd verwendet wird. Weitere Schemadateien wie beispielsweise netfx.xsd oder util.xsd werden
verwendet, falls beim Kompilieren zustzliche Erweiterungs-Bibliotheken bentigt werden. Der
Kompiliervorgang wird gestartet, indem der Compiler candle.exe ber die folgende Befehlszeile
aufgerufen wird und der Befehlszeile die erforderlichen Argumente, wie die Referenz auf das WXSDokument bergeben werden.
candle.exe [-?] [-nologo] [-out Ausgabe] Quelle1.wxs [Quelle2.wxs ...]
Es ist erkennbar, dass mehrere Quelldateien angegeben werden knnen. Es ist hingegen nicht mglich,
mehrere Ausgabedateien zu spezifizieren, so dass grundstzlich auf die Definition einer Ausgabedatei
verzichtet werden sollte. Wird keine Ausgabedatei definiert, verwendet candle.exe den Namen der
Quelldatei und ergnzt diesen um die Dateierweiterung .wixobj. Als Ausgabeoption kann jedoch ein
103
Kapitel 2
Verzeichnis angegeben werden, in das die erzeugten Ausgabedateien abgelegt werden. Der Name des
zu verwendenden Verzeichnisses muss hierzu mit einem Backslash abgeschlossen werden. Der
Kompiliervorgang lsst sich natrlich noch weiter beeinflussen, wozu die in Tabelle 2.25 aufgefhrten
Schalter verwendet werden knnen.
Schalter
Beschreibung
-arch
Festlegen der Architektur. Mgliche Werte sind x86, intel, x64, intel64 oder ia64.
Der Standardwert ist x86. Dieser Schalter wird nur bercksichtigt, wenn die
Architektur nicht im WXS-Dokument definiert wurde.
-d<name>[=<Wert>]
Hiermit knnen Parameter fr den Prprozessor definiert werden. Befindet sich im

WXS-Dokument eine Variable mit der Bezeichnung config, kann diese
durch -dconfig=Test auf den Wert Test gesetzt werden.
-ext
Hiermit kann eine zustzliche Erweiterungs-Bibliothek angegeben werden.
-I<Ordner>
Hiermit knnen Ordner definiert werden, die dem Suchpfad fr Includedateien

hinzugefgt werden. Um mehrere Ordner zu definieren, ist dieser Schalter mehrfach
zu verwenden.
-nologo
-pedantic
Es findet eine genauere Prfung des Dokumentes statt. Wird im WXS-Dokument

beispielsweise eine GUID verwendet, die auch Kleinbuchstaben enthlt, wird
standardmig darauf nicht hingewiesen und die Ausgabedatei erzeugt. Durch die
Verwendung dieses Schalters wird eine entsprechende Information ausgegeben und
der Kompiliervorgang mit einem Fehler beendet.
-sfdvital
Standardmig werden alle Dateien als Vital gekennzeichnet, wenn dieses Attribut
im Dokument nicht explizit gesetzt wurde. Durch diesen Schalter erfolgt diese
automatische Kennzeichnung nicht.
-ss
Die berprfung auf Basis des Schemas wird bersprungen (Performancegewinn).
-sw[N]
-trace
Bei Fehlern, Warnungen und zustzlichen Informationen wird die exakte Position
der Problemquelle im WXS-Dokument ausgegeben.
-v
-wx[N]

Tabelle 2.25: Schalter zur Beeinflussen des Kompiliervorgangs bei candle.exe
Nachdem der Kompiliervorgang erfolgreich abgeschlossen wurde, kann aus den erstellten
Objektdateien schlielich die Windows Installer-Datei erzeugt werden, wozu der Linker light.exe
verwendet werden kann. Es besteht auch die Mglichkeit der Erzeugung einer Windows InstallerXML Bibliothek, wozu das Tool lit.exe zu verwenden ist.
Light.exe
Beim Linken werden die Inhalte einer oder mehrerer Objektdateien (.wixobj) ausgewertet, mit den
Metainformationen externer Dateien kombiniert und in die Windows Installer-Datei bertragen.
Weiterhin werden whrend dieses Vorgangs die Kabinettdateien erstellt und diese und weitere
104
Kapitel 2
Ressourcen wie beispielsweise die Bitmaps zur Darstellung der Benutzeroberflche in die Windows
Installer-Datei integriert. Das Zusammenfhren der Dateien und das Schreiben der notwendigen
Informationen wird durch einen Linker realisiert, der in Windows Installer-XML die Bezeichnung
light.exe trgt. Der Linker kann ber die folgende Befehlszeile aufgerufen werden:
light.exe [-?] [-b Pfad] [-nologo] [-out Ausgabe] Objekt1 [Objekt2 ...]
Nach dem Erstellen einer Ausgabedatei im Format eines Windows Installer-Paketes und eines
Windows Installer-Mergemoduls wird automatisch eine vollstndige ICE-Validierung durchgefhrt.
Fehler bei dieser Validierung verhindern die Erstellung der Datei, so dass hierdurch ein Maximum an
Stabilitt des Installationspaketes erreicht wird. Diese Standardvorgabe kann jedoch beeinflusst
werden, wie auch eine groe Anzahl weiterer Erstellungsoptionen. Die mglichen Einstellungen sind
in Tabelle 2.26 aufgefhrt.
Schalter
Beschreibung
-ai
Die Verwendung identischer Zeilen ist mglich. Die Zeilen werden als Warnung
ausgegeben.
-b <Pfad>
Ermglicht die Definition eines Basisverzeichnisses zum Auffinden aller Dateien.

Standardmig wird das aktuelle Verzeichnis verwendet.
-bcgg
Aus Grnden der Abwrtskompatibilitt wird der ursprngliche Algorithmus zum

Erzeugen von GUIDs verwendet.
-bf
Dateien werden in das WIXOUT-Dokument bertragen. Dieser Schalter ist nur gltig,
falls -xo ebenfalls gesetzt wurde.
-cc <Pfad>
Legt ein Verzeichnis fest in dem die erstellten Kabinettdateien zwischengespeichert

werden. Das Verzeichnis wird nach dem Linken nicht gelscht.
-ct <N>
Legt die Anzahl der Threads fest, die beim Erstellen der Kabinettdateien verwendet
werden sollen. Standardmig wird hierzu die Umgebungsvariable
%NUMBER_OF_PROCESSORS% herangezogen.
-cub <Datei.cub>
Festlegen einer zustzlichen Validierungsdatenbank.
cultures:<Kulturen>
Ermglicht das Festlegen von Kulturen um lokalisierte Installationspakete zu erzeugen.

Es knnen mehrere Kulturen durch Semikolon getrennt, angegeben werden.
-d<name>=<Wert>
Definition einer WIX-Variablen.
-dcl:level
Ermglicht die Festlegung der Kompressionsstufe beim Erzeugen der Kabinettdatei.

Mglich Werte sind low, medium, high, none, mszip, wobei mszip die
Standardeinstellung ist.
-dut
Nicht reale Tabellen werden aus der Ausgabe entfernt.
-ext
-fv
Der Tabelle MsiAssemblyName wird ebenfalls das Attribut FileVersion angefgt.
-ice:<ICE>
Ein spezifischer Validierungstyp (ICE) wird ausgefhrt.
-loc <loc.wxl>
Festlegen eines WXL-Dokumentes, aus dem lokalisierte Zeichenfolgen verwendet
105
Kapitel 2
werden.
-nologo
-notidy
Die temporren Dateien werden nicht gelscht. Diese Option ist beim Debugging
hilfreich.
-o[ut]
Festlegen einer Ausgabedatei. Standardmig verwendet light.exe das aktuelle

Verzeichnis.
-pdbout
<output.wixpdb>
Festlegen einer Symboldatei. Standardmig verwendet light.exe den Namen der

Ausgabedatei und fgt die Erweiterung .wixpdb an.
-pedantic
Wie beim Kompilieren, findet hierdurch eine genauere Prfung der Quelldateien statt.
-reusecab
Kabinettdateien werden nicht neu erzeugt, sondern aus dem Cache verwendet.
-sa
Es werden keine Informationen der Tabelle MsiAssemblyName angefgt.
-sacl
Es werden keine Zugriffssteuerlisten (ACL) zurck gesetzt.
-sadmin
Die Sequenztabellen AdminUISequence und AdminExecuteSequence werden nicht

erstellt.
-sadv
Die Sequenztabelle AdvtExecuteSequence wird nicht erstellt.
-sf
Es werden keine Dateiinformationen ermittelt und bernommen und auch keine

Informationen der Tabelle MsiAssemblyName angefgt. Identisch mit der
Kombination -sa und -sh.
-sh
Es werden keine Dateiinformationen (Version, Gre, Hash) ermittelt und bernommen.
-sice:<ICE>
Die Ausfhrung der Prfroutine wird unterbunden.
-sma
Es werden keine Informationen der Tabelle MsiAssembly angefgt.
-spdb
Es werden keine WIXPDB-Dateien erstellt.
-ss
-sui
Aktionen der entsprechenden UI-Sequenztabellen werden nicht angefgt.
-sv
Die berprfung auf abweichende Dateiversionen wird nicht ausgefhrt.
-sval
Es wird kein ICE-Validierung bei Windows Installer-Paketen und Windows InstallerMergemodulen durchgefhrt.
-sw[N]
-v
-wx[N]

-xo
Anstelle der Windows Installer-Datei wird ein WIXOUT-Dokument erstellt.
Tabelle 2.26: Schalter zum Beeinflussen des Erstellungsvorgangs durch light.exe
Nach dem Linken ist der Erstellungsprozess abgeschlossen und es wurde die entsprechende Windows
Installer-Datei erzeugt. Wie bereits angedeutet wird standardmig eine Validierung durchgefhrt, die
jedoch auch deaktiviert werden kann. Dennoch sollte immer der Grundsatz gelten, eine Datei ohne
106
Kapitel 2
Validierung niemals auszuliefern, so dass die Validierung nachgeholt werden muss. Hierzu knnen
natrlich die Tools des Windows Installer-SDK verwendet werden, aber in der Toolsammlung von
Windows Installer-XML ist smoke.exe fr diese Zwecke enthalten.
Smoke.exe
Die Validierung eines Installationspaketes stellt sicher, dass dieses Paket den definierten
Implementierungsregeln entspricht, dass die interne Konsistenz der Datenbank gewhrleistet ist und
dass keine fehlerhaften Daten vorhanden sind. Durch die Tools des Windows Installer-SDK ist es
mglich unterschiedliche Prfmethoden auszufhren, von denen die Prfung der internen
Datenbankkonsistenz durch so genannte Internal Consistency Evaluators (ICE) die komplexeste und
effektivste Mglichkeit darstellt. Die Grundlage dieser berprfung bilden benutzerdefinierte
Aktionen, die in einer zweckoptimierten Windows Installer-Datenbank mit der Dateiendung .cub
abgelegt sind. Eine solche ICE-Validierung kann mit sehr vielen Tools durchgefhrt werden, von
denen smoke.exe durch den folgenden Befehlszeilenaufruf zu verwenden ist.
smoke.exe [-?] Datenbankdatei [Datenbankdatei ...]
Anhand der Aufrufsyntax ist erkennbar, dass mehrere Datenbankdateien angegeben werden knnen,
wodurch sich smoke.exe hervorragend im Rahmen einer Batchverarbeitung verwenden lsst. Mit
smoke.exe knnen Windows Installer-Pakete (.msi) und Windows Installer-Mergemodule (.msm)
validiert werden. Die Einstelloptionen fr die Validierung zeigt Tabelle 2.27.
Schalter
Beschreibung
-cub <Datei.cub>
Festlegen einer zustzlichen Validierungsdatenbank.
-ext
-ice:<ICE>
Festlegen eines spezifischen Validierungstyps (ICE), der ausgefhrt werden soll.
-nodefault
Die standardmige Validierungsdatenbank fr MSI-Dateien und MSM-Dateien wird

nicht automatisch bercksichtigt.
-nologo
-notidy
hilfreich.
-pdb
Pfad zu den korrespondierenden PDB-Dateien.
-sice:<ICE>
Die Ausfhrung der Prfroutine wird unterbunden.
-sw[N]
-v
Gibt zustzliche Informationen, sowie die gerade durchgefhrte Validierungsart aus.
-wx[N]

Tabelle 2.27: Einstellungen fr die Validierung mit smoke.exe
Durch die Validierung wird sichergestellt, dass das Installationspaket den formalen Vorgaben und
Richtlinien entspricht. Selbstverstndlich ist die Fehleranflligkeit eines solchen Installationspaketes
107
Kapitel 2
reduziert, aber ein Freibrief fr eine fehlerfreie Installation ist die Validierung natrlich nicht.
Lit.exe
Wie schon angedeutet besteht auch die Mglichkeit, aus den Objektdateien eine Windows InstallerXML Bibliothek zu erzeugen, indem lit.exe verwendet wird. Hierbei handelt es sich um einen
zustzlichen Optimierungsfaktor von Windows Installer-XML, der hervorragend in Verbindung mit
Fragmenten verwendet werden kann. Es ist mglich, diese in eine Windows Installer-XML Bibliothek
(.wixlib) zu bersetzen, so dass diese vorkompilierte Bibliothek auch fr andere Installationsprojekte
verwendet werden kann. Der Vorteil liegt hierbei in Wiederverwendbarkeit, der Reduzierung der
Fehleranflligkeit und der hheren Geschwindigkeit im Buildprozess. Die Fehleranflligkeit wird
reduziert, da der Quellcode nur einmalig verwaltet werden muss, wodurch Inkonsistenzen vermieden
werden. Die Performance im Buildprozess wird erhht, da die Bibliothek bereits vorkompiliert ist und
somit nur whrend des Linkens bentigt wird. Eine solche Bibliothek liegt dennoch im Textformat vor,
so dass die effiziente Nutzung durch Quellcodesysteme unproblematisch ist. Zur Erstellung einer
solchen Bibliothek, sind die folgenden Befehlszeilen zu verwenden:
candle.exe WiXLibrary.wxs -out
lit.exe -out WiXLibrary.wixlib WiXLibrary.wixobj
Zur Verwendung dieser Bibliothek aus dem Hauptprojekt heraus, muss ein entsprechender Verweis
dem Aufruf des Linkers beim Erzeugen der Windows Installer-Datei angefgt werden:
candle.exe Product.wxs
light.exe -out Product.msi Product.wixobj WiXLibrary.wixlib
Anhand der folgenden Syntax zum Aufruf von lit.exe wird deutlich, dass mehrere Objektdateien als
Quellen angegeben werden knnen, die dann zu einer Bibliothek kombiniert werden.
lit.exe [-?] [-nologo] [-out libraryFile] objectFile [objectFile ...]
Diese Anwendung ist vom Prinzip mit dem Linker vergleichbar, wodurch auch hnlichkeiten bei den
Einstelloptionen vorhanden sind. Die in Tabelle 2.28 aufgefhrten Schalter, ermglichen eine
individuelle Anpassung des Erstellungsvorgangs.
Schalter
Beschreibung
-b <Pfad>
Ermglicht die Definition eines Basisverzeichnisses zum Auffinden aller Dateien.

Standardmig wird das aktuelle Verzeichnis verwendet.
-bf
Ressourcen werden der Bibliotheksdatei hinzugefgt. Soll durch eine WIX-Bibliothek,

eine Ressource beispielsweise der Tabelle Binary hinzugefgt werden, mssen diese
Ressourcen beim spteren Linken des Hauptprojektes extern verfgbar sein. Wird dieser
Schalter beim Erzeugen der Bibliothek verwendet, werden die Ressourcen in die Datei
integriert. Beim Linken des Hauptprojektes wird nur noch die Bibliothek bentigt.
108
Kapitel 2
-ext
-loc <loc.wxl>
Festlegen eines WXL-Dokumentes, aus dem lokalisierte Zeichenfolgen verwendet

werden.
-nologo
-o[ut]
Festlegen einer Ausgabedatei. Standardmig verwendet light.exe das aktuelle

Verzeichnis.
-pedantic
Wie beim Linken erfolgt hierdurch eine genauere Prfung der Quelldateien.
-ss
-sv
Die berprfung auf abweichende Dateiversionen wird nicht ausgefhrt.
-sw[N]
-v
-wx[N]

Tabelle 2.28: Einstelloptionen zur Erzeugung einer Bibliothek mit lit.exe
Zur Erstellung von Windows Installer-XML Bibliotheken ist nicht ausschlielich das
Kommandozeilentool lit.exe erforderlich; es ist auch mglich diese direkt mit Visual Studio zu
erzeugen. Hierzu ist die Projektvorlage WiX Library Project zu verwenden.
Erweiterte Erstellvorgnge
Im ersten Schritt wurden die Quelldateien erzeugt, die dann im zweiten Schritt kompiliert und in
entsprechende Windows Installer-Dateien berfhrt wurden. Der Linker ermglichte hierbei die
Erstellung von Windows Installer-Paketen (.msi) und Windows Installer-Mergemodulen (.msm), er
enthlt jedoch keine direkte Option zur Erstellung von Windows Installer-Patches (.msp) und
Windows Installer-Transformationen (.mst). Dieses ist auch nicht verwunderlich, denn die Erstellung
dieser Dateitypen ist abweichend zu betrachten, was auch damit zu tun, dass es sich hierbei um
Differenzdateien handelt. Ein Windows Installer-Patch ist die Differenz zweier oder mehrerer
Windows Installer-Pakete und eine Windows Installer-Transformation, die Differenz zweier Windows
Installer-Datenbanken.
Torch.exe
An dieser Stelle ein kurzes Wort zum Erstellen von Transformation. Um mit den Bordmitteln des
Windows Installer-SDK eine Transformation zu erzeugen, sind immer zwei Installationspakete
erforderlich. Ein Haupteinsatzgebiet von Transformationen liegt in der Bereitstellung des
Installationspaketes in unterschiedliche Sprachen. Das bedeutet, dass zunchst ein neutrales
Installationspaket bentigt wird und eines mit den lokalisierten Texten. Eine Transformation zwischen
diesen Paketen wrde letztlich die sprachspezifischen Zeichenfolgen enthalten. Kommen jedoch
mehrere Sprachen zum Einsatz, so erhht sich zwangslufig auch der Aufwand beim Erstellen der
Installationspakete, denn fr jede untersttze Sprache wird ein solches bentigt. Strend erscheint
hierbei, dass die Installationspakete, mit Ausnahme des Originals, nach dem Erstellen der
Transformation nicht mehr bentigt werden.
109
Kapitel 2
Um solche Szenarien effektiver umzusetzen enthlt die Toolsammlung Windows Installer-XML die
Anwendung torch.exe. Die Einsatzszenarien dieses Tools sind sehr vielseitig. So ist es hiermit
natrlich mglich, eine Transformation zwischen zwei Installationspaketen zu erstellen, also analog zu
den Tools des Windows Installer-SDK. Allerdings kann torch.exe so konfiguriert werden, dass keine
Windows Installer-Transformation (.mst) erzeugt wird, sondern die XML-Reprsentation einer
Transformation. Eine solche Datei kann jederzeit mit dem Linker light.exe in eine echte Windows
Installer-Transformation umgewandelt werden. Der Vorteil ist offensichtlich, denn die XML-Datei
kann problemlos verndert werden, so dass neue Transformationen erstellt werden knnen, ohne
zunchst korrigierte Installationspakete erzeugen zu mssen.
Zum besseren Verstndnis mchte ich ein Beispiel anfhren. Es existieren zwei WXS-Dokumente vom
Typ Product mit denen zwei Installationspakete erzeugt werden knnen. Diese Dokumente sind
bezeichnet mit product1.wxs und product2.wxs. Die Unterscheidung beider Installationspakete liegt
lediglich in einer Zeichenfolge der Tabelle LaunchCondition. So wird lediglich darauf hingewiesen,
dass zur Installation das .NET Framework erforderlich ist. Bei product1.wxs wird diese Meldung in
englischer und bei product2.wxs in deutscher Sprache ausgegeben. Mit den bekannten Mglichkeiten
des Compilers und des Linker werden hieraus nun die Installationspakete product1.wxs und
product2.wxs erzeugt. Im nchsten Schritt geht es nun darum, die Transformation zu erzeugen. Der
klassische Ansatz wrde hierzu msitran.exe aus dem Windows Installer-SDK verwenden. Dieses ist
auch mit torch.exe durch den folgenden Befehlszeilenaufruf mglich:
torch.exe product1.msi product2.msi -out diff.mst
Hierdurch wird eine Transformation klassischer Art erzeugt. Aber torch.exe kann an dieser Stelle
weitaus mehr. Durch den folgenden Aufruf wird die XML-Reprsentation einer Transformation
erzeugt.
torch.exe product1.msi product2.msi -xo -out diff.wixout
Bei dieser in Listing 2.16 dargestellten XML-Reprsentation handelt es sich um ein WIXOUTDokument, dass jederzeit vom Linker in eine Windows Installer-Datei umgewandelt werden kann.
Aber hier liegt nun die Differenz der Dateien in einem Textformat vor, so dass auch manuelle
nderungen vorgenommen werden knnen, die letztlich als Basis fr eine neue Transformation
dienen. Hierdurch ist es nicht mehr erforderlich, zur Erzeugung von Transformationen zunchst neue
Installationspakete zu erzeugen.
<wixOutput type="Transform" codepage="1252" version="3.0.2002.0"
xmlns="http://schemas.microsoft.com/wix/2006/outputs">
<tableDefinitions xmlns="http://schemas.microsoft.com/wix/2006/tables">
<tableDefinition name="LaunchCondition">
<columnDefinition name="Condition" type="string" length="255" primaryKey="yes" localizable="yes"
category="condition" description="Expression which must evaluate to TRUE in
order for install to commence." />
<columnDefinition name="Description" type="localized" length="255" category="formatted"
description="Localizable text to display when condition fails and install must abort."
escapeIdtCharacters="yes" />
</tableDefinition>
110
Kapitel 2
</tableDefinitions>
<table name="LaunchCondition" xmlns="http://schemas.microsoft.com/wix/2006/objects">
<row op="modify" sectionId="/" sourceLineNumber="D:\Torch\Product2.msi">
<field>MsiNetAssemblySupport</field>
<field modified="yes">Das Microsoft .NET Framework ist zur Ausfhrung erforderlich.</field>
</row>
</table>
</wixOutput>
Listing 2.16: Auszug aus der XML-Reprsentation einer Transformation
Aber es geht noch weiter. Im Prinzip ist es ja ausreichend, lediglich fr die sprachneutrale Variante ein
Installationspaket zu erzeugen. Bei allen weiteren sprachspezifischen Dokumenten ist dieses nicht
mehr erforderlich, da sie nicht eigenstndig installiert werden, sondern nur als Transformation
verwendet werden. Durch den folgenden Befehlszeilenaufruf, wird eine Windows InstallerTransformation zwischen zwei XML-Dateien erzeugt, wobei diese als WIXOUT- oder WIXPDBDokument vorliegen mssen. Der anschlieende Aufruf des Linkers erzeugt eine Transformation
klassischer Art.
torch.exe product1.wixpdb product2.wixpdb -xi -out diff.wixout
light.exe diff.wixout -out diff.mst
Die bereits in den Beispielen dargestellte Aufrufsyntax von torch.exe gestaltet sich wie folgt:
torch.exe [-?] [Optionen] Zieldatei Aktualisierungsdatei -out Ausgabe
Auch hier gibt es wieder einige Einstelloptionen, die in den Beispielen bereits angesprochen wurden.
So ist es mglich, das Ausgabeformat der Transformation zu bestimmen und natrlich knnen auch
Validierungsbedingungen und Optionen zur Fehlerbehandlung definiert werden, wie Tabelle 2.29
zeigt.
Schalter
Beschreibung
-a
Die Erstellung der Transformation basiert auf administrativen Abbildern der

Installationspakete. Wird automatisch bei der Option -ax verwendet.
-ax
Administratives Abbildung und Extrakation der Binrdateien.
-ext
-nologo
-notidy
hilfreich.
-p
Der XML-Ausgabedatei werden nicht nur die Differenzen angefgt, sondern auch nicht
vernderte Informationen.
-serr <L>
Festlegen der Optionen fr die Fehlerbehandlung. Die Optionen sind a, b, c, d, e und f.

Die Erluterungen erhalten sie beim Aufruf von torch.exe -?.
-sw[N]
Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1009 sw1103)
111
Kapitel 2
-t <Typ>
Ermglicht die automatische Zuordnung von Validierungsbedingungen, die vom Typ der
Transformation abhngig sind. Mgliche Typen sind language, instance, patch.
-v
-val <L>
Festlegen der Validierungsbedingungen. Die Optionen sind g, l, r, s, t, u, v, w, x, y und z.

Die Erluterungen erhalten sie beim Aufruf von torch.exe -?.
-wx[N]
Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert (Beispiel: -wx1011
wx1012)
-x <Pfad>
Binrdateien werden in dem entsprechenden Ordner abgelegt.
-xi
Anstelle einer Windows Installer-Datei werden XML-Dateien (.wixout oder .wixpdb) als
Eingabe verwendet.
-xo
Anstelle einer klassischen Transformation erfolgt die Ausgabe als WIXOUT-Dokument.

Dieses ist der Standard bei Verwendung der Option -xi.
Tabelle 2.29: Einstelloptionen beim Erstellen einer Transformation mit torch.exe
Wie bereits angesprochen enthlt eine Transformation die Differenz zweier Windows InstallerDatenbanken. Das bedeutet, dass nderungen am Summary Information Stream oder den anderen
Datenspeichern eines Paketes nicht in die Transformation einflieen. Anders ist es bei einem Patch.
Dieser enthlt die Unterschiede zweier oder mehrerer Installationspakete. Windows Installer-XML
enthlt das Tool pyro.exe zum Erzeugen von Windows Installer-Patches.
Pyro.exe
Beim Patching handelt es sich um eine alternative Technologie, ein Produkt in einen neuen
Installationsstatus zu berfhren. Die Produktaktualisierung erfolgt hierbei durch die Anwendung
eines Windows Installer-Patches auf ein bereits installiertes Produkt. Bei einem Windows InstallerPatch handelt es sich um eine Datei mit der Endung .msp, die lediglich die Differenz der
Installationspakete enthlt. Zur Erstellung von Windows Installer-Patches werden die
Installationspakete der bisherigen- und der neuen Produktversion bentigt. Hierbei ist es erforderlich,
dass die enthaltenen Ressourcen in einem dekomprimierten Zustand vorliegen, wie das bei einer
administrativen Installation der Fall ist. Im Weiteren ist ein Tool oder eine Implementierung
erforderlich, um die Differenz der Installationspakete zu ermitteln und daraus einen Windows InstallerPatch zu generieren. Das Windows Installer-SDK enthlt zu diesem Zweck das Befehlszeilentool
msimsp.exe, dass intern die Bibliothek patchwiz.dll aufruft. Zum Erzeugen eines Patches wird darber
hinaus eine Steuerdatei bentigt, in der die Verweise auf die Installationspakete und weitere
Einstellungen enthalten sind. Bei der Steuerdatei handelt es sich um ein speziell fr diese Zwecke
strukturiertes Windows Installer-Paket, das als Patch Creation Property File bezeichnet wird und ber
die Dateiendung .pcp verfgt.
Die gerade dargestellte Mglichkeit zur Erzeugung von Patches ist sehr effektiv, falls hiermit sehr
umfangreiche Modifikationen an der installierten Softwarelsung durchgefhrt werden. Sollen jedoch
nur wenige Modifikationen durchgefhrt werden, wie das bei einem Hotfix oder Security Fix der Fall
wre, ist diese Methode ineffizient. Es gilt zu beachten, dass bei dieser Vorgehensweise immer die
administrativen Abbilder der alten und der neuen Softwareversion erstellt werden mssen. Zustzlich
muss patchwiz.dll alle verwendeten Ressourcen analysieren, um festzustellen, welche Ressourcen
modifiziert wurden, damit diese in den Patch integriert werden. Die Dauer dieses Vorgangs ist
zwangslufig von der Anzahl der Ressourcen abhngig, die sich in den Windows Installer-Paketen
112
Kapitel 2
befinden. Eine genaue Beschreibung der Vorgehensweise beim Erzeugen eines Patches zeigt Kapitel
10.
Windows Installer-XML enthlt eine neue Implementierung zur Erstellung von Patches, bei der keine
zustzlichen Bibliotheken verwendet werden. Ein Vorteil ist hierbei, dass in dem entsprechenden
XML-Dokument direkt definiert wird, welche Windows Installer-Komponente verndert wurde,
wodurch der Analysevorgang der patchwiz.dll berflssig wird. Weiterhin bentigt die neue
Implementierung von Windows Installer-XML keine administrativen Abbilder mehr, sondern greift
direkt auf generierte XML-Dateien zu. Ein weiterer Pluspunkt ist eine exaktere Adressierung der zu
aktualisierenden Ressourcen. Mit der konventionellen Methode ist es nur mglich einen Patch zu
erzeugen, der alle nderungen zwischen den Installationspaketen beinhaltet. Mitunter kann es jedoch
angebracht sein, die Modifikationen auf mehrere Patches aufzuteilen, was mit der neuen Methode von
Windows Installer-XML mglich ist.
Die Verwendung der nativen Patching-Funktionalitt von Windows Installer-XML ist recht einfach.
Beim Linken des Installationspaketes ist zunchst ein WIXOUT-Dokument zu erzeugen. Hierbei
handelt es sich um eine Datei, die eine XML-Reprsentation der Daten, der Referenzen auf die
Ressourcen, sowie binre Informationen enthlt. Im ersten Schritt muss das Tool torch.exe verwendet
werden, um eine WIX-Transformation zwischen den WIXOUT-Dateien des alten und des neuen
Paketes zu erzeugen. Das Ergebnis ist eine Datei, die alle Differenzen zwischen den Paketen im XMLFormat, sowie die binren Ressourcen enthlt. Diese Datei wird zuknftig als Basis fr die Erstellung
der Patches fungieren.
Wie auch bei der Erluterung der Transformationen sollen zwei Installationspakete dienen, die im
WXS-Format vorliegen. Beide Dateien installieren eine identische Anwendung, allerdings sind
unterschiedliche Versionen der Ressourcen enthalten. Die relevanten Abschnitte des Dokumentes zeigt
Listing 2.17.

<Icon Id="I__Colors.exe" SourceFile=".\$(var.Version)\Colors.ico" />
<Directory Id="INSTALLLOCATION" Name="Colors">
<Component Id="C__Colors.exe" Guid="1ACC3C89-9E07-418a-B4DD-9D1DA89C3E4F">

<File Id="F__Colors.exe" Source=".\$(var.Version)\" Name="Colors.exe" KeyPath="yes" DiskId="1" />

<Shortcut Id="S__Colors.exe" Directory="DesktopFolder" Name="Colors 1.0" Target="Application"
Hotkey="0" Icon="I__Colors.exe" IconIndex="0" Show="normal" />
</Component>
</Directory>
</Directory>
</Directory>
Listing 2.17: Auszug aus einem Dokument zum Erzeugen von Installationspaketen
Es wird deutlich, dass hier Variablen verwendet werden, um den Pfad zu den Quelldateien zu
definieren. Beim Erstellen des Paketes werden den Variablen unterschiedliche Werte zugewiesen,
wodurch unterschiedliche Dateiversionen in die Pakete integriert werden. Letztlich beziehen sich die
nderungen auf die Datei colors.exe und die Symboldatei colors.ico. Der Erstellvorgang wird auf den
bekannten Wegen gestartet.
113
Kapitel 2
ECHO *** Version 1.0

candle.exe -dVersion=1.0 product.wxs -out product1.wixobj
light.exe product1.wixobj -xo -out product1.wixout
light.exe product1.wixobj -out product1.msi
ECHO *** Version 2.0
candle.exe -dVersion=2.0 product.wxs -out product2.wixobj
light.exe product2.wixobj -xo -out product2.wixout
Beim Aufruf des Linkers der Version 2.0 wird deutlich, dass hierbei kein Windows Installer-Paket
erzeugt wird, sondern ausschlielich ein WIXOUT-Dokument. Dieses ist ausreichend, da ein Patch
zwischen zwei solchen Dokumenten erzeugt werden kann. Die Version 1.0 wird hingegen zustzlich
als klassisches Paket erstellt, da dieses ja auch als Basispaket auf den Systemen installiert werden
muss. Im nchsten Schritt muss zunchst eine Windows Installer-XML-Transformation erstellt
werden, in der die Differenzen beider Dateien abgelegt werden. Die Vorgehensweise hierzu unter
Verwendung der folgenden Befehlszeilen wurde bereits erlutert.
torch.exe -p -xi product1.wixout product2.wixout -out qfe1.wixmst
Zur Modellierung des Patches muss nun ein WXS-Dokument erstellt werden. In diesem Dokument
sind Identifikationsmerkmale des Patches, sowie zustzliche Metainformationen anzugeben. Die
Besonderheit bezieht sich jedoch auf die Definition der Ressourcen, die durch den Patch aktualisiert
werden sollen. Hierzu existiert zunchst Element <PatchFamily/>, durch das die
Anwendungsreihenfolge der Patches definiert wird. Diesem Element knnen Unterelemente angefgt
werden, die auf die Ressourcen verweisen, die durch den Patch aktualisiert werden sollen. In Listing
2.18 wird hierbei eine Referenz auf die Komponente C__Colors.exe durch das Element
<ComponentRef/> hergestellt. Hierbei handelt es sich um die Komponente, die die aktualisierte Datei
colors.exe enthlt. Wie zuvor dargestellt, wurde auch die Symboldatei colors.ico verndert, so dass
diese an dieser Stelle ebenfalls zu referenzieren ist. Diese explizite Referenzierung bewirkt, dass nur
die hier definierten Ressourcen in den Patch einflieen; Modifikationen an anderen Stellen in den
Installationspaketen werden nicht bercksichtigt. Dieses ist der groe Vorteil gegenber der
klassischen Vorgehensweise beim Erstellen eines Patches. Der klassische Ansatz ermittelt die
Unterschiede zwischen den Paketen automatisch, was gerade bei komplexen Paketen sehr zeitintensiv
sein kann. Letztlich flieen alle festgestellten Unterschiede in den Patch ein. Bei der nativen Methode
von Windows Installer-XML werden die Ressourcen manuell definiert, wodurch eine automatische
Ermittlung nicht durchgefhrt wird. Weiterhin flieen nur die so spezifizierten Ressourcen in den
Patch ein. Das Optimierungspotential sollte erkennbar sein. Bei Hotfixes werden hufig nur eine oder
zwei Dateien ausgewechselt. Nimmt man nun ein Installationspaket von der Kategorie eines Visual
Studio 2008 mit mehr als 14.000 Dateien, so mssten beim klassischen Ansatz alle diese Dateien
analysiert werden um letztlich die beiden abweichenden Daten zu erhalten. Natrlich ist diese
Automatik in einigen Szenarien sehr hilfreich. Gerade wenn eine groe Anzahl von Ressourcen in den
Patch einfliet oder wenn die abweichenden Ressourcen nicht bekannt sind. Somit ist es auch nicht
114
Kapitel 2
verwunderlich, dass diese Automatik auch von Windows Installer-XML genutzt werden kann. Hierzu
ist dem Element <PatchFamily/> keine Referenz anzufgen.
Interessant ist auch das Element <Media/>. Hier muss zunchst eine Sequenznummer definiert
werden. Diese Sequenznummer ist der Ausgangswert, der beim Hinzufgen von Dateien zur Tabelle
File verwendet wird. Sie haben beispielsweise ein Installationspaket, in dem 110 Dateien in der
Tabelle File definiert wurden. Somit verfgen diese Dateien normalerweise ber die Sequenznummern
1 bis 110. Wird nun durch einen Patch der Anwendung eine neue Datei hinzugefgt, wird diese Datei
temporr der Tabelle File angefgt. Hier muss natrlich die Sequenznummer beachtet werden. Der
nchste freie Wert wre 111, der dann als Id dem Element <Media/> hinzuzufgen ist. Hier kann
natrlich auch ein hherer Wert verwendet werden, um flexibel auf komplexe Szenarien reagieren zu
knnen. Wird als Id ein Wert verwendet, der bereits im Installationspaket vorhanden ist, wie
beispielsweise 1, wird automatisch der nchste freie Wert verwendet. An dieser Stelle wird auch die
Kabinettdatei zur Aufnahme der Ressourcen bestimmt, da diese ja auch ber die Sequenznummer
zugeordnet wird. Weiterhin ist als Unterelement hier <PatchBaseline/> zu finden, dass ber ein
Identifizierungsmerkmal verfgt. Hiermit knnen unterschiedliche Validierungsbedingungen und
Fehlerbehandlungsmethoden festgelegt werden. Es ist mglich mehrere Elemente vom Typ
<PatchBaseline/> zu definieren, um hierdurch flexibel auf unterschiedliche Anwendungsszenarien zu
reagieren. Erst beim Erstellen des Patches, wird ber die Befehlszeile letztlich die anzuwendende Id
angegeben.
<?xml version="1.0" encoding="UTF-8"?>
<Patch AllowRemoval="yes" Classification="Hotfix" Codepage="1252"
Description="Dieser Patch aktualisiert das Produkt Colors 1.0."
DisplayName="QFE1" Id ="*" OptimizedInstallMode="yes" Manufacturer="Microsoft Deutschland GmbH"
MoreInfoURL ="http://www.microsoft.com/germany" >

<Media Id="1" Cabinet="RTM.cab">
<PatchBaseline Id="RTM">
<Validate IgnoreAddExistingRow="yes" IgnoreAddExistingTable ="yes" ProductId ="yes"
ProductVersion ="Update" ProductVersionOperator ="LesserOrEqual"/>
</PatchBaseline>
</Media>

<PatchFamily Id="RM" Version ="1.0.0.100" Supersede="no">
<IconRef Id="I__Colors.exe"/>
<ComponentRef Id="C__Colors.exe"/>
</PatchFamily>

<PatchProperty Name="MinimumRequiredMsiVersion" Value="300"/>
<PatchProperty Name="TrustMSI" Value="1"/>
<PatchProperty Name="AllowLaxValidateFlags" Value ="0"/>

<OptimizeCustomActions SkipAssignment="yes" SkipDeferred="yes" SkipImmediate="yes" />
</Patch>
</Wix>
115
Kapitel 2
Listing 2.18: Dokument zur Erstellung eines Patches mit pyro.exe
Aus diesem Dokument muss nun eine XML-Reprsentation des Patches erzeugt werden, indem der
Compiler und der Linker nach dem folgenden Schema verwendet werden.
candle.exe qfe1.wxs
light.exe qfe1.wixobj -out qfe1.wixmsp
Zum jetzigen Zeitpunkt sind alle Vorbereitungen abgeschlossen und die erforderlichen Dateien
qfe1.wixmsp und qfe1.wixmst liegen vor. Nun kommt pyro.exe ins Spiel und kann es kann der
Windows Installer-Patch qfe1.msp durch den folgenden Befehl erzeugt werden:
pyro.exe qfe1.wixmsp -out qfe1.msp" -t RTM qfe1.wixmst
Die dargestellte Befehlszeile sieht etwas ungewhnlich aus, was mit der Baseline zu tun hat, die durch
den Parameter -t angegeben wurde, wie die nachfolgende Syntax zeigt.
pyro.exe [-?] Eingabedatei -out Ausgabedatei [-t baseline Transformation]
Der Buildprozess zur Erzeugung des Patches kann natrlich weiter beeinflusst werden. So ist es auch
mglich festzulegen ob ein vollstndiger Patch (Full-File-Patch) oder ein Binr-Patch (Byte-LevelPatch) erzeugt werden soll. Die mglichen Einstelloptionen zeigt Tabelle 2.30.
Schalter
Beschreibung
-cc <Pfad>
Legt ein Verzeichnis fest in dem die erstellten Kabinettdateien zwischengespeichert

werden. Das Verzeichnis wird nach dem Linken nicht gelscht.
-delta
Erstellt einen Byte-Level-Patch anstelle eines Full-File-Patches.
-ext
-nologo
-notidy
hilfreich.
-o[ut]
Festlegen einer Ausgabedatei.
-pdbout
<output.wixpdb>
Festlegen einer Symboldatei. Standardmig verwendet pyro.exe den Namen der

Ausgabedatei und fgt die Erweiterung .wixpdb an.
-reusecab
Kabinettdateien werden nicht neu erzeugt, sondern aus dem Cache verwendet.
-sa
Es werden keine Informationen der Tabelle MsiAssemblyName angefgt.
-sf
Es werden keine Dateiinformationen ermittelt und bernommen und auch keine

Informationen der Tabelle MsiAssemblyName angefgt. Identisch mit der
Kombination -sa und -sh.
-sh
Es werden keine Dateiinformationen (Version, Gre, Hash) ermittelt und bernommen.
116
Kapitel 2
-spdb
Es werden keine WIXPDB-Dateien erstellt.
-sw[N]
-t Baseline
Festlegen der zu verwendenden Transformationen und Definition der Baseline.
-v
-wx[N]

Tabelle 2.30: Einstelloptionen zur Erzeugung von Patches mit pyro.exe
Bevor jedoch die technische Erstellung eines Patches durchgefhrt wird, gilt es einige
Vorberlegungen anzustellen und bestimmte Vorgaben zu bercksichtigen. Im letzten Kapitel dieses
Buches geht es im Wesentlichen um Erweiterungen in Patching-Szenarien durch den Windows
Installer 4.5. Hier finden sich aber auch allgemeine Informationen zur generellen Verwendung und
Anwendung von Patches.
Windows Installer-XML verfgt ber einen erstaunlichen Funktionsvorrat. Wie das aber bei jeder
Technologie der Fall ist, reicht auch die komplexeste Anwendung nicht aus, allen Anforderungen
gerecht zu werden. Aus diesem Grund kann der Funktionsvorrat von Windows Installer-XML durch
individuelle Implementierungen erweitert weitern. Hiermit sind zunchst Erweiterungen gemeint, die
sich mit den Tools verwenden lassen, die im vorherigen Abschnitt erlutert wurde.
Arten und Verwendung

Die Funktionalitt der meisten Tools, die im vorherigen Abschnitt dargestellt wurden, lsst sich
erweitern. Hierzu ist die zu verwendende Erweiterungsbibliothek dem Parameter -ext des
Befehlszeilenaufrufs anzufgen. Soll beispielsweise die in Windows Installer-XML enthaltene
Erweiterungsbibliothek zur Integration einer Benutzeroberflche verwendet werden, ist diese dem
Aufruf des Linkers wie folgt anzufgen:
light.exe
-out
product.msi
"%MSIWIX%\WixUIExtension.dll"
product.wixobj
-ext
Sollen mehrere Erweiterungsbibliotheken verwendet werden, ist der Parameter -ext mehrfach zu
verwenden. Die in dem Beispiel verwendete benutzerdefinierte Umgebungsvariable %MSIWIX%
verweist auf den Ordner %ProgramFiles%\Windows Installer XML v3\bin, in dem auch die
referenzierte Bibliothek zu finden ist. Bei der Verwendung von Visual Studio mssen die zu
verwendenden Erweiterungsbibliotheken ebenfalls angegeben werden. Hierzu ist der Dialog zum
Hinzufgen von Referenzen zu verwenden, wie Abbildung 2.20 zeigt.
117
Kapitel 2
Abbildung 2.20: Hinzufgen einer Erweiterungsbibliothek mit Visual Studio
Erweiterungsbibliotheken knnen nicht nur in Verbindung mit dem Linker verwendet werden; die
Nutzung ist auch mit anderen Tools mglich. Windows Installer-XML kennt und untersttzt die
folgenden Erweiterungsarten:
Prprozessor: Eine solche Erweiterung ermglicht die Modifikation der Quelldateien, bevor sie
vom Compiler verwendet werden.
Compiler: Hierdurch wird es mglich, die Quelldatei in eine interne Reprsentation zu berfhren,
bevor die binre Ausgabe erfolgt.
Binder: Ermglicht die Modifikation des Verhaltens whrend des Bindens.
Decompiler: Ein solche Erweiterung kann verwendet werden um benutzerdefinierten Tabellen ins
XML-Format zu bersetzen.
Validator: Standardmig werden Ausgaben bei der Validierung im Konsolenfenster ausgegeben.
Durch die Erweiterung kann die Ausgabe umgeleitet werden.
Harvester: Das Verhalten des Harvesters (heat.exe) kann hiermit verndert werden.
Unbinder: Ermglicht die Modifikation des Verhaltens whrend des Un-Bindens.
Es ist erkennbar, dass viele Mglichkeiten existieren eine Erweiterungsbibliothek zu platzieren. Ich
mchte in einem kurzen Beispiel die Entwicklung einer Erweiterung fr den Decompiler erlutern.
118
Kapitel 2
Individuelle Erweiterungsbibliothek
Die Zielsetzung dieser individuellen Erweiterungsbibliothek soll darin liegen, eine Dokumentation der
Tabellenstruktur eines Installationspaketes zu erstellen. Zunchst ist in Visual Studio ein Projekt vom
Typ Klassenbibliothek zu erzeugen. Diesem ist eine Referenz auf die Datei wix.dll anzufgen. Da
eine Erweiterung fr den Decompiler erstellt werden soll, wird eine Klasse bentigt, die von
Microsoft.Tools.WindowsInstallerXml.DecompilerExtension abgeleitet ist, wie dieses in Listing 2.19
aufgezeigt wird.
/// <summary>
/// Decompiler zur Ausgabe der Tabelleninformationen
/// </summary>
public class CustomDecompiler : DecompilerExtension
{
public override void InitializeDecompile(TableCollection tables)
{
// Temporre Datei erstellen und ffnen
string fileName = Path.GetTempFileName();
using (StreamWriter sw = new StreamWriter(fileName))
{
// Iteration durch alle Tabellen
foreach (Table table in tables)
{
// Name der Tabelle, Anzahl der Datenstze und Definition ausgeben
sw.WriteLine(table.Name);
sw.WriteLine("Rows: " + table.Rows.Count.ToString());
sw.WriteLine(table.Definition.ToIdtDefinition(false));
}
}
// Funktion in der Basisklasse aufrufen
base.InitializeDecompile(tables);
}
}
Listing 2.19: Benutzerdefinierter Decompiler zur Ausgabe von Tabelleninformationen
Die Basisklasse stellt diverse Methoden zur Verfgung, die berschrieben werden knnen. Zur
Erstellung der Dokumentation wird die Funktion InitializeDecompile() berschrieben. Dieser Funktion
wird nun der individuelle Code angefgt, der in dem Beispiel natrlich sehr einfach ausfllt. Es wird
zunchst eine temporre Datei erstellt, anschlieend werden der Name und die Struktur der Tabellen
dieser Datei angefgt. Zum Schluss wird noch die Funktion der Basisklasse aufgerufen, damit die
regulre Bearbeitung der Tabellen erfolgen kann.
Im nchsten Schritt muss die tatschliche Erweiterung erstellt werden. Hierbei muss ebenfalls
festgelegt werden, welchen Erweiterungstypen in der Bibliothek enthalten sind. Hierzu wird wiederum
eine Klasse erstellt, die diesmal von Microsoft.Tools.WindowsInstallerXml.WixExtension abgeleitet ist,
wie Listing 2.20 zeigt.
/// <summary>
/// Benutzerdefinierte Erweiterung
/// </summary>
public class CustomExtension : WixExtension
{
public override DecompilerExtension DecompilerExtension
119
Kapitel 2
{
get
{
// Instanz der Erweiterung fr den Decompiler erstellen
if (this.decompilerExtension == null)
this.decompilerExtension = new CustomDecompiler();
return this.decompilerExtension;
}
}
private CustomDecompiler decompilerExtension;
}
Listing 2.20: Erweiterung des Funktionsvorrats durch einen individuellen Decompiler
Wiederum stellt die Basisklasse diverse Methoden und Eigenschaften zur Verfgung, die
berschrieben werden knnen. Hierbei finden sich Eigenschaften fr die einzelnen Erweiterungstypen
wie BinderExtension, PreprocessorExtension oder die fr diese Zwecke relevante
DecompilerExtension. Es ist erkennbar, dass in der Implementierung eine Instanz der Klasse
CustomDecompiler() erzeugt und zurckgegeben wird. Im Prinzip ist es das gewesen, mehr
Programmcode ist nicht erforderlich um eine einfache Erweiterungsbibliothek zu erzeugen. Eine kleine
Sache fehlt allerdings noch. Die erstellte Bibliothek muss noch als Erweiterungsbibliothek fr
Windows Installer-XML gekennzeichnet werden. Hierzu ist es erforderlich, dass Assembly mit dem
Attribut AssemblyDefaultWixExtension() zu versehen, wie die folgende Programmzeile zeigt:
[assembly: AssemblyDefaultWixExtension(typeof(CustomExtension))]
Anschlieend kann das Projekt kompiliert und verwendet werden. Hierzu muss die
Erweiterungsbibliothek dem Aufruf des Decompilers angefgt werden. Im Rahmen der
Dekompilierung wird eine temporre Datei erzeugt, der die Tabellendefinition angefgt werden.
dark.exe product.msi -ext "%MSIWIX%\WixCustomExtension.dll"
Dieses einfache Beispiel sollte den grundlegenden Aufbau einer Erweiterungsbibliothek skizzieren und
Denkanste fr individuelle Implementierungen geben. Die sich hierdurch bietenden Mglichkeiten
sind nahezu grenzenlos und laden frmlich dazu ein, mal wieder einige Programmzeilen zu schreiben.
Bibliothek zur Darstellung einer Benutzeroberflche

Es ist natrlich generell mglich, die Benutzeroberflche eines Installationspaketes in einem WXSDokument zu beschreiben. Fr diese Zwecke steht das Element <UI/> zur Verfgung. Die
Dialogdefinition erfolgt durch das Element <Dialog/>, dem mehrere Attribute zur Modellierung des
Dialogs angefgt werden knnen. Diese Werte werden beim Kompilieren und Linken in die Windows
Installer-Tabelle Dialog bertragen. Das Element <Dialog/> kann weiterhin untergeordnete Elemente
vom Typ <Control/> aufnehmen, mit denen die Steuerelemente des Dialogs definiert und die spter in
die Tabelle Control des Installationspaketes bertragen werden. Abhngig von der Art des
Steuerelementes sind weitere Definitionen erforderlich. So erwartet beispielsweise ein Steuerelement
vom Typ ListBox eine Auflistung der Elemente, die zur Auswahl angeboten werden sollen. Darber
hinaus kann der Element-Typ <Control/> noch weitere untergeordnete Elemente aufnehmen, um
120
Kapitel 2
hiermit die Verhaltensmuster des Controls zu beeinflussen.

Es wird deutlich, dass die Gestaltung einer Benutzeroberflche nicht ganz trivial ist, da zustzlich zum
grafischen Aufbau noch die dynamische Steuerung des Installationsprozesses zu bercksichtigen ist.
Erschwerend kommt hinzu, dass die Toolsammlung Windows Installer-XML derzeitig noch keinen
grafischen Designer fr diese Zwecke zur Verfgung stellt. Es luft also darauf hinaus, das
Erscheinungsbild in XML zu modellieren, was alles andere als interessant und zeitgem ist. Es muss
sich aber auch die Frage nach der Notwendigkeit gestellt werden. Muss denn jedes Mal eine eigene
Benutzeroberflche entwickelt werden oder gibt es vorgefertigte Modelle die benutzt werden knnen?
Diese Frage kann eindeutig mit Ja beantwortet werden, denn Windows Installer-XML stellt bereits
vordefinierte Benutzeroberflchen in mehreren Sprachen zur Verfgung. Diese Benutzeroberflchen
sind in der bereits zu Beginn dieses Abschnitts erwhnten Erweiterungsbibliothek WixUIExtension.dll
enthalten. Aktuell stehen die Benutzeroberflchen in den Sprachen Deutsch (de-DE), Englisch (enUS), Spanisch (es-ES) und Niederlndisch (nl-NL) zur Auswahl. Weitere Sprachen befinden sich
derzeitig in der Entwicklung. Wie bereits eingehend erlutert, muss diese Erweiterungsbibliothek dem
Aufruf des Linkers angefgt werden. Selbstverstndlich kann auch die Sprache der Benutzeroberflche
festgelegt werden, indem der Parameter -cultures verwendet wird.
candle.exe product.wxs
light.exe
-out
1031.msi
"%MSIWIX%\WixUIExtension.dll"
product.wixobj
-cultures:de-DE
-ext
Bevor der Buildprozess gestartet werden kann, ist dem WXS-Dokument allerdings eine Referenz auf
die zu verwendende Benutzeroberflche zuzufgen. Hierzu ist dem Element <UIRef/> der Name der
Benutzeroberflche zuzuordnen. Windows Installer-XML stellt unterschiedliche Benutzeroberflchen
zur Verfgung, die in Tabelle 2.31 zusammengefasst werden.
Name
Beschreibung
WixUI_Mondo
Enthlt den vollstndigen Umfang an verfgbaren Dialogen, also WelcomeDlg,

LicenseAgreementDlg, SetupTypeDlg und CustomizeDlg. Weiterhin sind die
Dialoge fr den Wartungsmodus enthalten.
WixUI_FeatureTree
Eine einfachere Form von WixUI_Mondo. Es wird nach dem Lizenzdialog direkt
zur Auswahl der Features gewechselt.
WixUI_InstallDir
Ermglicht keine Auswahl von Features sondern nur die Festlegung eines
Installationsverzeichnisses.
WixUI_Minimal
Ganz einfache Form der Benutzeroberflche mit wenigen Dialogen. Ermglicht

die Installation durch einen Mausklick, da der WelcomeDlg auch die
Lizenzbestimmungen enthlt.
WixUI_Advanced
Analog zu WixUI_Minimal enthlt der WelcomeDlg auch die

Lizenzbestimmungen, so dass die Installation mit einem Klick gestartet werden
kann. Zustzlich lsst sich in einen erweiterten Modus wechseln, um das
Installationsverzeichnis und die zu installierenden Features zu bestimmen.
WixUI_ErrorProgressText
Dieses Element ist zustzlich zu den Oberflchendefinitionen zu verwenden.

Hierdurch werden die lokalisierten Texte den Tabellen Error und ActionText
angefgt.
121
Kapitel 2
Tabelle 2.31: In Windows Installer-XML enthaltene Benutzeroberflchen
Die Darstellung der Benutzeroberflchen kann natrlich noch angepasst oder erweitert werden, wozu
entsprechende WIX-Variablen zu verwenden sind. So ist es mglich eine eigene Lizenzdatei
einzubinden, indem diese der Variablen WixUILicenseRtf zugeordnet wird. Zustzlich ist es mglich,
andere grafische Elemente wie Bitmaps und Symboldateien fr die Darstellung festzulegen. Hierfr
sind die Variablen WixUIBannerBmp, WixUIDialogBmp, WixUIExclamationIco, WixUIInfoIco,
WixUINewIco und WixUIUpIco zu verwenden. Standardmig werden die lokalisierten Fehler- und
Aktionstexte den Tabellen Error und ActionText der Windows Installer-Datenbank nicht hinzugefgt.
Um dieses dennoch zu erreichen ist eine zustzliche Referenz auf das Oberflchenelement
WixUI_ErrorProgressText erforderlich, wie dieses auch in dem Auszug eines WXS-Dokumentes in
Listing 2.21 gezeigt wird.

<UIRef Id="WixUI_InstallDir" />
<UIRef Id="WixUI_ErrorProgressText" />

<Property Id="WIXUI_INSTALLDIR" Value="APPLICATIONFOLDER" />

<WixVariable Id="WixUIBannerBmp" Value=".\Banner.jpg" />
<WixVariable Id="WixUIDialogBmp" Value=".\Dialog.jpg" />

<WixVariable Id="WixUILicenseRtf" Value=".\Eula.rtf"/>
Listing 2.21: Anpassen der integrierten Benutzeroberflche
Es besteht natrlich auch die Mglichkeit die vordefinierte Benutzeroberflche um eigene Dialoge zu
erweitern. Sehr viele Informationen dazu sind in der Dokumentation zu finden. Darber hinaus sind
Beispiele auch auf http://www.wixwiki.com/index.php?title=UiExtension vorhanden.
Komplexe Erweiterungsbibliotheken
Alle bisher vorgestellten Erweiterungen kamen ausschlielich whrend der Entwicklung des
Installationspaketes zu Einsatz. Es gibt jedoch auch Erweiterungen, die whrend der Installation
angewendet werden, um Aktivitten durchzufhren, die ber das Grundportfolio des Windows
Installers hinausgehen. Einfach ausgedrckt knnte man diese Form der Erweiterungen mit
benutzerdefinierten Aktionen vergleichen, wenngleich die Erweiterungen wesentlich komplexer sind.
Die Erweiterungen stellen auch individuellen Code zur Verfgung, mit dem zweckorientierte
Aufgaben im Installationsprozess zu verrichten sind. Der Entwickler kommt jedoch mit diesem Code
nicht in Berhrung, sondern referenziert die jeweilige Erweiterung und beschreibt das beabsichtigte
Installationsergebnis im WXS-Dokument. Whrend des Buildprozesses werden diese individuellen
Ergnzungen dann umgesetzt und das finale Produkt um benutzerdefinierte Tabellen erweitert, die von
benutzerdefinierten Aktionen verwendet werden. Der Vorteil liegt auf der Hand. Die Entwicklung von
benutzerdefinierten Aktionen bedeutet einiges an Aufwand. Dieser wird dadurch verursacht, da nicht
nur eine Aktion fr den Installationsfall zu erstellen ist, sondern auch entsprechende Aktionen fr die
Deinstallation und den Fehlerfall. Im Weiteren sind ausfhrliche Tests notwendig, damit eine solche
individuelle Aktion in einen produktiven Status berfhrt werden kann. Das Ganze kombiniert mit
einer eleganten Struktur und einer Trennung zwischen Implementierung und Daten ist ebenfalls nicht
trivial. Betrachtet man das tatschliche Einsatzspektrum von benutzerdefinierten Aktionen, so ist
122
Kapitel 2
auffallend, dass viele Aktivitten immer wieder kehren, also in unterschiedlichen Installationsszenarien
verwendet werden. Fr viele dieser generischen Anwendungsflle stellt Windows Installer-XML
bereits vorgefertigte Bibliotheken zur Verfgung, die neben dem ausfhrbaren Code auch noch eine
XML-Schemaerweiterung enthalten, so dass Datendefinitionen im XML-Dokument sehr elegant
durchgefhrt werden kann.
Beschaffung von Informationen

Nicht jede benutzerdefinierte Aktion, oder jede Erweiterung soll das Zielsystem verndern. Viel
hufiger sind Implementierungen anzutreffen, mit denen die Installationsvoraussetzungen geprft
werden. Hierbei sind ganz triviale Prfungen anzutreffen, aber auch sehr komplexe und hchst
individuelle Algorithmen bilden keine Ausnahme.
Lassen Sie mich mit einigen augenscheinlich trivialen Anforderungen beginnen, die bei der Installation
zu bercksichtigen sind. Das erste Installationspaket soll sich nur installieren lassen, falls es sich bei
der Zielplattform um die Media Center Edition von Microsoft Windows handelt. Falls das erfllt ist,
sollen die entsprechenden Dateien in den Ordner Videos abgelegt werden. Auf den ersten Blick
erscheint das nicht sonderlich kompliziert, da der Windows Installer ja selbst eine Vielzahl von
Systemeigenschaften zur Verfgung stellt. Die Ernchterung kommt jedoch schnell; weder zur
Bestimmung des Ordners Videos noch zur Bestimmung der Media Center Edition stellt der
Windows Installer entsprechende Funktionalitten bereit. Der Ausweg liegt somit in der Verwendung
einer benutzerdefinierten Aktion. Das bedeutet, dass zunchst die API-Funktionen ermittelt werden
mssen, mit denen die Eigenschaften abgerufen werden knnen. Im Anschluss ist der Programmcode
zu erstellen, die Objektbibliothek muss getestet werden und schlielich muss sie dem
Installationspaket hinzugefgt werden. Bei der Erstellung des Programmcodes ist natrlich darauf zu
achten, dass die ermittelten Werte dem Windows Installer-Paket zugnglich gemacht werden, so dass
innerhalb des Installationsprozesses diese bercksichtigt werden knnen. Es ist erkennbar dass der
Aufwand zur programmtechnischen Ermittlung dieser beiden Werte enorm ist.
Windows Installer-XML enthlt die Erweiterung WixUtilExtension.dll, mit deren Hilfe die Ermittlung
der gerade dargestellten Eigenschaften problemlos mglich ist. Zur Ermittlung der
Systemeigenschaften ist es ausreichend, den bentigten Eigenschaftsnamen innerhalb des WXSDokumentes zu referenzieren wie dieses auch Listing 2.22 zeigt.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" >
<Product UpgradeCode="{692D893C-ADD5-49b7-8B59-B1C751450199}" Manufacturer="Microsoft Deutschland GmbH"
Language="1031" Version="1.00.0000" Name="WiXQueryOS"
Id="{7908E714-05AD-4d4d-BC36-0C115722343B}" Codepage="1252">
<Package Description=" WiXQueryOS" Manufacturer="Andreas Kerl" InstallerVersion="200"
Platform="x86" Languages="1031" Compressed="yes" SummaryCodepage="1252" />

<PropertyRef Id="WIX_SUITE_MEDIACENTER" />
<PropertyRef Id="WIX_DIR_MYVIDEO" />

<Condition Message="Windows Media Center Edition wird bentigt.">WIX_SUITE_MEDIACENTER</Condition>
123
Kapitel 2

<Directory Id="WIX_DIR_MYVIDEO">
<Component Id="C__Video" Guid="{2DD50F42-64EA-454d-913F-A41973CF990D}">
<File Id="F__Video" Source ="..\Source\Dummy.avi" Name="Dummy.avi" KeyPath="yes" DiskId="1" />
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="Application" Title="Anwendung" Level="1">
<ComponentRef Id="C__Video" />
</Feature>

<Property Id="WIXUI_INSTALLDIR" Value="WIX_DIR_MYVIDEO" />
</Product>
</Wix>
Listing 2.22: Systemeigenschaften mit der WixUtilExtension.dll ermitteln
Damit noch nicht genug; die Anforderungen werden exotischer. Die Installation einer XMLSchemadatei soll im Schema-Verzeichnis von Visual Studio 2008 (standardmig
%ProgramFiles%\Microsoft Visual Studio 9.0\Xml\Schemas) erfolgen. Hieraus folgt, dass zunchst
geprft werden muss, ob Visual Studio 2008 berhaupt installiert ist. Des Weiteren soll die Installation
nur mglich sein, wenn es sich mindestens um die Standard-Edition des Produktes handelt und wenn
das Projektsystem fr Visual C# installiert wurde. Auch hier gilt identisches wie bei dem vorherigen
Beispiel; die Implementierung ist nicht trivial, aber auch hierfr stellt Windows Installer-XML
entsprechende Funktionalitten bereit. Diese befinden sich in der Erweiterungsbibliothek
WixVSExtension.dll. In Listing 2.23 wird die Verwendung der geeigneten Eigenschaften dargestellt;
eine vollstndige Beschreibung der Eigenschaften ist in der Hilfe zu Windows Installer-XML zu
finden. Mit Hilfe dieser Bibliothek ist es auch mglich entsprechende Eigenschaftswerte der
Entwicklungsumgebungen Visual Studio 2003 und Visual Studio 2008 abzurufen, sowie
Konfigurationen an diesen Produkten vorzunehmen.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" >
<Product UpgradeCode="{B201DAC9-1849-4038-8A18-815B17A6DDC2}" Manufacturer="Microsoft Deutschland GmbH"
Language="1031" Version="1.00.0000" Name="WixVSExtension"
Id="{47B5EC24-ADE7-4983-9711-D8253C73877E}" Codepage="1252">
<Package Description="WixVSExtension" Manufacturer="Andreas Kerl" InstallerVersion="200"
124
Kapitel 2

<PropertyRef Id="VS90_SCHEMAS_DIR" />
<PropertyRef Id="VS90DEVENV" />
<PropertyRef Id="VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED" />
<Condition Message="Microsoft Visual Studio 2008 ist erforderlich.">VS90DEVENV</Condition>
<Condition Message="Das Visual C# Projektsystem wurde nicht
gefunden.">VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED</Condition>
<Directory Id="VS90_SCHEMAS_DIR">
<Component Id="C__Schema" Guid="{26CB42ED-289D-48f7-8772-63526BC04A05}">
<File Id="F__Schema" Source ="..\Source\Dummy.xml" Name="Dummy.xml" KeyPath="yes" DiskId="1" />
</Component>
</Directory>
</Directory>
</Directory>
<ComponentRef Id="C__Schema" />
</Feature>

<Property Id="WIXUI_INSTALLDIR" Value="VS90_SCHEMAS_DIR" />
</Product>
</Wix>
Listing 2.23: Eigenschaften der Entwicklungsumgebung mit WixVSExtension.dll abrufen
Eine Vielzahl der heutigen Anwendungen basieren auf dem .NET Framework, wodurch die Existenz
sichergestellt werden muss. Geht es lediglich darum festzustellen, ob diese Laufzeitumgebung
vorhanden ist, gengt die Verwendung der Windows Installer-Eigenschaft MsiNetAssemblySupport.
Diese Eigenschaft enthlt die Versionsnummer des installierten Frameworks, so dass auch hierdurch
weiter gehende Prfungen erfolgen knnen. Vielfach besteht jedoch die Anforderung die Existenz
einer bestimmten Version des .NET Frameworks zu prfen und gleichzeitig festzustellen ob ein
entsprechender Service Pack und ein Sprachpaket vorhanden sind. Diese Anforderungen bersteigen
den Standardvorrat des Windows Installers, so dass wieder individuelle Mechanismen zu verwenden
sind. Auch an dieser Stelle hilft Windows Installer-XML weiter, denn durch die
Erweiterungsbibliothek NetFxExtension.dll werden solche Funktionalitten zur Verfgung gestellt.
Modifikation des Zielsystems

Die bisher vorgestellten Erweiterungen dienten lediglich dazu Systeminformationen abzurufen. Hierbei
125
Kapitel 2
wurde im schreibgeschtzten Modus auf das System zugegriffen; eine Modifikation des Zielsystems
wurde nicht vorgenommen. Eine solche darf gem den Windows Installer-Richtlinien nur im Rahmen
der Installationstransaktion erfolgen. Denn nur hierdurch kann sichergestellt werden, dass die
nderungen bei einem Installationsfehler zurckgenommen werden knnen. Ist es erforderlich das
Zielsystem durch individuelle Implementierungen zu modifizieren, so sind hierzu benutzerdefinierte
Aktionen mit verzgerter Ausfhrung zu verwenden. Hierunter sind Aktionen zu verstehen, die
ebenfalls im Rahmen der Transaktion ausgefhrt werden und deren nderungen rein theoretisch
ebenfalls zurckgenommen werden knnen. Ich sage hier bewusst theoretisch, denn einen
Automatismus wie bei den Standardaktionen gibt es hierfr nicht. Der Windows Installer hat keine
Kenntnis ber die physischen Modifikationen am Zielsystem und kann diese somit auch nicht
automatisch zurcknehmen. Es ist somit erforderlich, gegenstzliche Aktionen zu erstellen, die im
Fehlerfall und auch bei der Deinstallation die durchgefhrten nderungen zurcknehmen. Es wird
deutlich, dass der Aufwand zum Entwickeln einer solchen benutzerdefinierten Aktion sehr hoch ist,
zumal auch einige programmtechnische Besonderheiten zu bercksichtigen sind.
Ein einfaches Beispiel fr eine solche Aktion ist das Anlegen eines Benutzerkontos im Rahmen der
Installation. Was auf den ersten Blick sehr einfach aussieht, gestaltet sich beim nheren hinsehen
komplexer als ursprnglich gedacht, da die folgenden Fragen in das Design einbezogen werden sollten:
Was soll geschehen, wenn das anzulegende Benutzerkonto bereits existiert? Denkbare Optionen
wren ein Abbruch der Aktion oder die Aktualisierung des existierenden Kontos.
Was soll beim Rollback geschehen? Hierbei sollte auch der Fall betrachtet werden, in dem das
Konto bereits vorhanden ist.
Was soll bei der Deinstallation geschehen? Soll das Konto entfernt werden oder soll es auf dem
System verbleiben?
Soll das Benutzerkonto noch bestimmten Benutzergruppen hinzugefgt werden?
Welche zustzlichen Optionen sollen bei der Erstellung des Kontos bercksichtigt werden? Darf
der Benutzer beispielsweise das Kennwort verndern oder nicht.
Es wird deutlich, dass eine programmtechnische Implementierung in Form einer benutzerdefinierten
Aktion sehr umfangreich wird, wenn die gerade vorgestellten Faktoren bercksichtigt werden sollen.
Die exakte Vorgehensweise zur Erstellung eines Installationspaketes mit dieser Funktionalitt ist im
Windows Installer-SDK beschrieben; weiterhin ist der erforderliche Programmcode ebenfalls im SDK
zu finden. Bei der Betrachtung dieses Beispiels fllt auf, dass der Windows Installer-Datenbank eine
benutzerdefinierte Tabelle mit der Bezeichnung CustomUserAccounts hinzugefgt wurde. In dieser
Tabelle werden die zu erstellenden Benutzerkonten erfasst; die programmtechnische Implementierung
greift beim Ausfhren der benutzerdefinierten Aktion auf diese Datenbanktabelle zurck. Es ist
erkennbar dass hierdurch die Datenhaltung von der Implementierung getrennt wurde, so dass sich das
Gesamtdesign sehr strukturiert und einfach darstellt.
Windows Installer-XML verwendet einen identischen Ansatz; auch hier werden die Daten von der
Implementierung getrennt. Allerdings ist die gesamte Vorgehensweise zur Verwendung einer solchen
Aktion wesentlich einfacher und komfortabler realisiert als in dem Beispiel des SDK. Im Wesentlichen
sind nur drei Schritte durchzufhren:
Das XML-Schema http://schemas.microsoft.com/wix/UtilExtension ist im WXS-Dokument zu
referenzieren, wodurch Elemente und Attribute zur Definition des Benutzerkontos bereitgestellt
werden. Im Weiteren wird hierdurch auch die IntelliSense-Funktionalitt bereitgestellt.
Das zu erstellende Benutzerkonto ist durch das Element <User/> zu modellieren. Zustzlich
126
Kapitel 2
knnen Zuordnungen zu Benutzergruppen durch die Elemente <Group/> und <GroupRef/>

hergestellt werden.
Beim Kompilieren und beim Linken ist die WixUtilExtension.dll als Erweiterungsbibliothek
anzugeben.
Im folgenden Listing 2.24 wurden diese Vorgaben umgesetzt. Es ist erkennbar, dass das Schema der
Erweiterung mit dem Namensraum util verknpft wurde. Hierdurch ist es mglich unter Verwendung
dieses Prfix die Schemaelemente zu verwenden. Hierbei steht natrlich IntelliSense zur Verfgung.
Der anzulegende Benutzer wird durch das Element <util:User/> verkrpert. Diesem Element knnen
eine Vielzahl von Attributen zugeordnet werden, mit denen die Eigenschaften des Benutzerkontos
individuell zu modellieren sind.
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product Id="{2169403C-327B-4d8c-A812-B005D0F0169E}" Name="WiXAccount" Language="1031" Version="1.0.0.0"
Manufacturer="Microsoft Deutschland GmbH" Codepage="1252"
UpgradeCode="{D778550E-8CB9-4169-BF23-2D3394969A71}">
<Package Description="WiXAccount" Manufacturer="Andreas Kerl" InstallerVersion="200"

<Property Id="PASSWORD" Value="ABCDE*1" Secure="yes" Hidden="yes"/>
<Property Id="ACCOUNTNAME" Value="WIXUser" Secure="yes"/>

<util:Group Id="UserGroup" Name="Users" />
<Directory Id="INSTALLLOCATION" Name="WiXAccount">
<Component Id="C__Account" Guid="{D971321A-749C-436f-A780-BE5D4DE9042F}">
<File Id="F__Dummy" Source="..\Source\Dummy.txt" Name="Dummy.txt" DiskId="1" />

<util:User Id="U__User1" Name="[ACCOUNTNAME]" Password="[PASSWORD]" CreateUser="yes"
PasswordNeverExpires="yes" RemoveOnUninstall="yes" UpdateIfExists="yes"
PasswordExpired="yes" FailIfExists="no">
<util:GroupRef Id="UserGroup"/>
</util:User>
</Component>
</Directory>
</Directory>
</Directory>
<ComponentRef Id="C__Account" />
</Feature>
127
Kapitel 2


<UIRef Id="WixUI_Minimal" />
</Product>
</Wix>
Listing 2.24: Verwenden der WixUtilExtension.dll zum Hinzufgen eines Benutzerkontos
Das erstellte WXS-Dokument kann nun unter Verwendung des Compilers und Linkers in ein Windows
Installer-Paket umgewandelt werden. Hierbei ist zu beachten, dass dem Aufruf des Compilers und des
Linkers eine Referenz auf die Bibliothek WixUtilExtension.dll angefgt werden muss. Da eine
Benutzeroberflche generiert werden soll, muss die Referenz auf die Bibliothek WixUIExtension.dll
dem Linkeraufruf ebenfalls angefgt werden. Darber hinaus ist es noch mglich, die zu verwendende
Kultur zu definieren. Diese Kultur hat nicht nur Einfluss auf die Sprache der Benutzeroberflche,
sondern bezieht sich auch auf die Bibliothek WixUtilExtension.dll. Das bedeutet, dass hiermit auch die
Sprache der Meldungen festgelegt wird, die beispielsweise beim fehlerhaften Anlegen eines Benutzers
angezeigt oder ausgegeben werden.
candle.exe account.wxs -ext "%MSIWIX%\WixUtilExtension.dll"
light.exe -out account.msi account.wixobj -ext WixUtilExtension.dll -ext
WixUIExtension.dll -cultures:de-DE
Die Vorgehensweisen zum Anlegen eines Benutzers durch Verwendung der entsprechenden Elemente
im WXS-Dokument sind relativ einfach und berschaubar. Interessant ist hingegen die tatschliche
Umsetzung im finalen Installationspaket. An dieser Stelle offenbaren sich die gesamte Komplexitt
und die elegante Umsetzung der Implementierung. So finden sich neue Tabellen wie Group, User und
UserGroup die letztlich die Daten zur Konfiguration des Benutzers enthalten. Die tatschliche
Modifikation wird in Form von benutzerdefinierten Aktionen vorgenommen, wobei auch Aktionen fr
die Deinstallation und den Fehlerfall vorhanden sind.
Ich mchte noch ein hnliches Beispiel konstruieren und hierbei auch die bereits vorgestellten
Bibliotheken zum Abrufen von Systeminformationen einbeziehen. Es soll eine Netzwerkfreigabe fr
das Installationsverzeichnis erstellt werden, wobei Mitglieder der Gruppe Benutzer ausschlielich
lesend darauf zugreifen drfen. Der Zugriff fr Mitglieder der Administratorengruppe soll hingegen
nicht eingeschrnkt werden. Was auf den ersten Blick einfach aussieht, gestaltet sich beim nheren
Hinsehen jedoch uerst aufwendig. Das hat damit zu tun, dass sich der Name der Benutzergruppen in
Abhngigkeit zur Sprache des Betriebssystems verndert. Es wre jetzt natrlich mglich
entsprechende lokalisierte Texte in dem Installationspaket verwenden, aber der zu betreibende
Aufwand wre riesengro und das Ergebnis nicht zufriedenstellend. Der Windows Installer hilft an
dieser Stelle auch nicht weiter, denn nur in der Tabelle LockPermissions knnen die Bezeichnungen
Administrators und Everyone symbolisch verwendet werden. Aber wie ich es bereits angedeutet habe,
hilft an dieser Stelle auch Windows Installer-XML weiter. Die Erweiterungsbibliothek
WixUtilExtension.dll enthlt lokalisierte Bezeichnungen fr die Benutzergruppen der Administratoren,
der Benutzer und der Gste, sowie fr die Konten des lokalen Systemkontos (local system), des
128
Kapitel 2
lokalen Dienstes (local service) und des Netzwerkdienstes (network service).

Das folgende Listing 2.25 ist hnlich aufgebaut, wie das vorherige Beispiel. Auch hier wird wieder das
Erweiterungsschema referenziert, so dass die entsprechenden XML-Elemente zur Verfgung stehen.
Die Netzwerkfreigabe kann durch das Element <util:FileShare/> erzeugt werden. Diesem Element
knnen untergeordnete Elemente vom Typ <util:FileSharePermission/> zugeordnet werden, die
letztlich die Zugriffsrechte regeln. Weiterhin ist erkennbar, dass Referenzen auf die Eigenschaften
WIX_ACCOUNT_USERS und WIX_ACCOUNT_ADMINISTRATORS abgerufen und verwendet
werden. Hierbei handelt es sich um die symbolischen Namen der Benutzergruppen, die whrend der
Installation durch eine benutzerdefinierte Aktion sprachspezifisch aufgelst werden.
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product Id="{F1E93279-C5AE-43e0-9A32-B72B3E198170}" Name="WiXFileShare" Language="1031" Version="1.0.0.0"
Manufacturer="Microsoft Deutschland GmbH" Codepage="1252"
UpgradeCode="{2A237E39-5AA9-4d77-8368-CB704B8D1A00}">
<Package Description="WiXFileShare" Manufacturer="Andreas Kerl" InstallerVersion="200"
<PropertyRef Id="WIX_ACCOUNT_USERS" />
<PropertyRef Id="WIX_ACCOUNT_ADMINISTRATORS" />

<util:User Id="USERS" Name="[WIX_ACCOUNT_USERS]" />
<util:User Id="ADMINS" Name="[WIX_ACCOUNT_ADMINISTRATORS]"/>
<Directory Id="INSTALLLOCATION" Name="WiXFileShare">
<Component Id="C__Share" Guid="{64B06B96-CE5A-480d-9274-561C1BF55FF1}">
<File Id="F__Dummy" Source="..\Source\Dummy.txt" Name="Dummy.txt" DiskId="1" />

<util:FileShare Id="FS_TestShare" Name="TestShare" Description="Dieses ist ein Testshare">
<util:FileSharePermission User="USERS" Read="yes" Synchronize="yes" />
<util:FileSharePermission User="ADMINS" GenericAll="yes" Synchronize="yes" />
</util:FileShare>
</Component>
</Directory>
</Directory>
</Directory>
<ComponentRef Id="C__Share" />
</Feature>

129
Kapitel 2

<Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" />
</Product>
</Wix>
Listing 2.25: Verwenden der WixUtilExtension.dll zum Erstellen einer Netzwerkfreigabe
Zu Beginn des Abschnitts zu den Erweiterungsbibliotheken, wurde der interne Aufbau anhand eines
kleinen Beispiels skizziert. So wurde in der von Microsoft.Tools.WindowsInstallerXml.WixExtension
abgeleiteten Klasse festgelegt, welche Art von Erweiterung bereitgestellt werden soll. In dem Beispiel
war das eine Erweiterung fr den Decompiler. Es ist nicht verwunderlich, dass die gerade vorgestellte
WixUtilExtension.dll eine Erweiterung fr den Compiler enthlt, damit die Informationen des
Dokumentes umgesetzt werden knnen. Darber hinaus ist ebenfalls eine Erweiterung fr den
Decompiler vorhanden. Das hat den groen Vorteil, dass beim Dekompilieren eines
Installationspaketes die Inhalte durch diese Bibliothek zustzlich ausgewertet und umgesetzt werden.
Betrachten Sie das durch Listing 2.25 erzeugte Installationspaket. Dieses enthlt eine
benutzerdefinierte Tabelle mit der Bezeichnung FileShare. Die Inhalte dieser Tabelle wrden bei einer
Dekompilierung ohne diese Erweiterungsbibliothek in ein generisches Element vom Typ
<CustomTable/> berfhrt. Da jedoch die Erweiterungsbibliothek automatisch herangezogen wird,
werden die spezifischen Informationen letztlich wider im Element <FileShare/> abgebildet, so dass
sie komfortabel weiter verwendet werden knnen.
Weitere Mglichkeiten
Eine Zielsetzung von Windows Installer-XML ist die Bereitstellung von Implementierungen fr alle
gngigen Installationsanforderungen. Die technische Umsetzung hierzu erfolgt durch
Erweiterungsbibliotheken, von denen eine im vorherigen Abschnitt vorgestellt wurde. Dieses ist
jedoch nur die Spitze des Eisberg, denn der derzeitig zur Verfgung gestellte Funktionsvorrat ist
bereits so gro, dass eine detaillierte Betrachtung ein eigenes Buch fllen wrde. Aus diesem Grund
mchte ich im Folgenden lediglich einen kurzen Abriss ber die weiteren Erweiterungsbibliotheken
und den primren Verwendungszweck geben.
Bibliothek
Beschreibung
WixComPlusExtension.dll
Installation und Konfiguration von COM+ Anwendungen und Rollen.
WixDifxAppExtension.dll
Installation und Konfiguration von Gertetreibern unter Verwendung des

Driver Installation Frameworks.
WixDirectXExtension.dll
berprfen der DirectX-Fhigkeiten der installierten Grafikkarte.
WixFirewallExtension.dll
Registrieren von Programmen oder Ports als Ausnahmen der Windows

Firewall.
WixGamingExtension.dll
Registrieren eines Spiels im Spiele-Explorer von Windows Vista.
WixIIsExtension.dll
Installation von Webanwendungen und Konfiguration des Webservers.
WixIsolatedAppExtension.dll
Installation von isolierten Anwendungen.
130
Kapitel 2
WixMsmqExtension.dll
Konfiguration von Elementen der Microsoft Message Queue.
WixNetFxExtension.dll
Erstellen von Native Images fr Microsoft .NET 2.0 und hher. Weiterhin
bereitstellen von Systeminformationen zum installierten Framework.
WixOfficeExtension.dll
Installation von Add-Ins fr Microsoft Office.
WixPSExtension.dll
Installation von Snap-Ins fr die Windows PowerShell.
WixSqlExtension.dll
Erstellen von Datenbanken und Ausfhren von SQL-Skripten auf einem

Microsoft SQL Server.
WixUIExtension.dll
Integration einer Benutzeroberflche in das Installationspaket.
WixVSExtension.dll
Installation von Hilfedateien im Format HTML-Help 2.0 und Abrufen von

Visual Studio-Eigenschaften.
WixUtilExtension.dll
Allgemeine Funktionen wie das Hinzufgen von Benutzerkonten,

Modifizieren von XML-Dateien, Installation von Leistungsindikatoren,
Schlieen von Anwendungen, Registrieren von Ereignisprotokollen.
Weiterhin Funktionalitten zum Simulieren von Installationsabbrchen.
Tabelle 2.32: Erweiterungsbibliotheken in Windows Installer-XML
Wie bereits angedeutet, wird der Funktionsvorrat von Windows Installer-XML stndig erweitert, so
dass beim Erscheinen dieses Buches der Umfang der Erweiterungsbibliotheken wahrscheinlich weiter
zugenommen hat.
Fazit
Bei der Toolsammlung handelt es sich um ein nicht kommerzielles Produkt, dass fast vollstndig in der
Programmiersprache Microsoft Visual C# entwickelt wurde. Windows Installer-XML ist frei verfgbar
und unterliegt der Common Public License, wodurch es auch in kommerziellen Projekten verwendet
werden darf.
Der technische Ansatz ist elegant gelst, denn jeder Entwickler denkt in XML, wodurch der bergang
zu einer darauf basierenden Deklarationssprache zum Erzeugen von Installationspaketen extrem
vereinfacht wird. Windows Installer-XML ist ein mchtiges Werkzeug zum Erzeugen von
Installationspaketen, das hinsichtlich der Flexibilitt und der Einbindung in automatisierte
Buildprozesse seines gleichen sucht. Dieses ist aber lngst nicht alles, denn Windows Installer-XML
enthlt auch ein SDK mit dem es mglich ist, programmtechnisch auf Windows InstallerFunktionalitten zuzugreifen. Dieses SDK trgt die Bezeichnung Deployment Tools Foundation und
wird in Kapitel 4 dieses Buches betrachtet.
131
Kapitel 3
Windows Installer und 64-Bit-Betriebssysteme
Windows Installer und 64-BitBetriebssysteme
Architekturen
Richtlinien
Fazit
132
136
144
146
148
Viele Unwgbarkeiten fhrten in der Vergangenheit dazu, dass die 64-Bit Plattform nicht den
Stellenwert eingenommen hat, den sie vom technischen und funktionellen Standpunkt aus htte
einnehmen knnen. Unterschiedliche und inkompatible Prozessorarchitekturen, teure Hardware und
fehlende Software waren einige der Grnde dafr. Im Gegensatz dazu war der Markt durchaus
vorhanden, denn Software, die eine hohe Rechenleistung fordert oder sehr viel Arbeitsspeicher
bentigt, waren und sind absolut keine Seltenheit. Vereinfacht dargestellt bedeutet 64-Bit, dass die
Prozessoren durch ihre Bauart so ausgelegt sind, dass 64-Bit, also 8 Byte whrend eines
Prozessortaktes verarbeitet werden knnen. Hierdurch sind natrlich effektivere Rechenleistungen
gerade im Bereich hoher Ganzzahlen mglich, so dass Vorteile bei Verschlsselungsalgorithmen, bei
grafischen Berechnungen und im Multimediaumfeld zu verzeichnen sind. Weitere Vorteile liegen in
der Gre des Adressraums, da hierbei nicht mehr die Begrenzung bei 4 Gigabyte liegt, sondern
theoretisch bei 264 Byte, also 16 Exabyte, die direkt adressiert werden knnen. Dieses ist jedoch nur ein
theoretischer Wert, denn praktisch ist die Verwendung eines so groen Adressraums noch nicht
mglich. Aktuelle Betriebssysteme in 64-Bit-Architektur wie der Windows Server 2008 untersttzen
Adressrume bis zu 2 Terabyte. Die Vorzge sind dennoch offensichtlich und auch die erforderliche
Hardware wird nun zu erschwinglichen Preisen angeboten, so dass die breite Nutzung perspektivisch
mglich scheint. Die Verfgbarkeit geeigneter Betriebssysteme und Anwendungen sollte die
Verbreitung von 64-Bit Systemen zustzlich vorantreiben.
Architekturen
Bei der Erstellung eines Installationspaketes ist festzulegen, welche Plattform untersttzt werden soll.
Diese Informationen werden in der Eigenschaft PID_TEMPLATE des Summary Information Streams
abgelegt. Es ist denkbar einfach eine 32-Bit Plattform als Ziel fr ein Installationspaket auswhlen. Bei
einer 64-Bit Plattform sieht das Ganze auf den ersten Blick doch etwas verwirrend aus, was ihren
Ursprung in dem Namenswirrwarr bei den um 64-Bit-Funktionen erweiterten x86-Prozessoren findet.
Es stellt sich zunchst die Frage, was sich hinter Begriffen wie x86, AMD64, IA64, EM64T oder IA64
verbirgt und welche Unterschiede vorhanden sind.
132
Kapitel 3
x86: Bei x86 handelt es sich um die klassische Prozessor-Architektur, also 32-Bit Prozesse die auf
einem 32-Bit Windows-Betriebssystem ausgefhrt werden.
AMD64: Hierbei handelt es sich um die von Advanced Micros Devices Inc. geschaffene
Mglichkeit 32-Bit Code auf einem 64-Bit System nativ auszufhren. Das bedeutet, dass ein 32-Bit
Windows Betriebssystem auf einer AMD64-Maschine nativ ausgefhrt werden kann. Technisch
gesehen ist der Chip ein vollwertiger 32-Bit-Prozessor, dessen Register im 64-Bit-Modus
verbreitert wurden. Er ist dadurch uneingeschrnkt zu heutiger 32-Bit und sogar alter 16-Bit
Software kompatibel. Zustzlich steht ein 64-Bit Modus zur Verfgung, der vor allem die
Adressierung eines greren Speicherbereichs ermglicht und Performance-Verbesserungen durch
breite Register mit sich bringt. Mit AMD64 leitete AMD daher einen sanften bergang von 32- auf
64-Bit-Umgebungen ein. Frher wurde diese Architektur auch als x86-64 bezeichnet.
IA64: IA64 steht fr Intel Architecture 64-Bit und ist eine 64-Bit-Architektur und ein Befehlssatz
von Intel fr die Prozessorgenerationen Itanium und Itanium 2. Hierbei wird 64-Bit Code nativ
ausgefhrt, 32-Bit Code wird emuliert. Es ist somit nicht mglich, ein 32-Bit Betriebssystem auf
einem IA64-System zu installieren. Hierfr mssen Betriebssysteme wie Windows Server 2003 for
64-bit Itanium-based Systems oder Windows Server 2008 for Itanium-based Systems verwendet
werden.
Intel64: Intel 64 (frher auch Extended Memory 64 Technology, abgekrzt EM64T), bezeichnet die
Erweiterung der Architektur um die Fhigkeit mehr als 4 Gigabyte Speicher direkt zu adressieren
und die 64-Bit AMD64-Befehle auszufhren. Dieser Prozessor untersttzt ebenso die native
Ausfhrung von 32-Bit-Code wie ein AMD64.
x64: Dieses ist die von Microsoft verwendete Bezeichnung um Prozessoren zu definieren, die 32und 64-Bit-Code nativ, also ohne Emulation ausfhren knnen. Somit sind hierunter die beiden
Prozessoren Intel64 (EM64T) und AMD64 zu verstehen.
Nun kommt wieder der Windows Installer ins Spiel und die Verwirrung wird noch grer. Windows
Installer 4.5 kennt zum Definieren der Zielplattform die Eigenschaften Intel, Intel64, AMD64 und x64.
Der Windows Installer untersttzt seit der Version 2.0 bereits die Installation auf der IA64-Plattform
und seit der Version 3.0 auf der AMD64-Plattform. Damals konnte noch nicht vorhergesagt werden,
dass Intel eine weitere 64-Bit-Architektur untersttzen wrde, so dass zum damaligen Zeitpunkt
passende Eigenschaftsbezeichnungen gewhlt wurden, die bis heute aus Grnden der Kompatibilitt
beibehalten wurde. Um ein Installationspaket fr die Ausfhrung auf einer IA64-Plattform zu
konfigurieren, ist die Eigenschaft PID_TEMPLATE des Summary Information Streams auf Intel64
zu setzen; fr die Installation auf der AMD64-Plattform hingegen auf AMD64. Mit dem Windows
Installer 3.1 wurde der zustzliche Wert x64 eingefhrt. Da Intel jedoch durch die EM64T-Architektur
kompatibel zur AMD64-Architektur ist, handelt es sich hierbei nur um Kosmetik, um hiermit die
Unabhngigkeit zum Hersteller der Prozessoren darzustellen. Es ist somit unerheblich, ob der
Eigenschaftswert x64 oder AMD64 gesetzt wird; das Paket lsst sich auf einer x64-Plattform
anwenden. Der Eigenschaftswert AMD64 ist durch den generischen Wert x64 berflssig geworden
und befindet sich nur noch aus Grnden der Kompatibilitt mit lteren Installationspaketen im
Eigenschaftsvorrat des Windows Installers.
Hinweis Beginn
Auch bei Mergemodulen muss die Eigenschaft PID_TEMPLATE des Summary Information Streams
auf die entsprechende Prozessorarchitektur gesetzt werden. Hierbei ist zu beachten, dass sich
Mergemodule, die mit Intel64 gekennzeichnet sind, natrlich auch nur in die identisch
gekennzeichneten Installationspakete integrieren lassen. Gleiches gilt fr die Kennzeichnung mit x64
133
Kapitel 3
Und AMD64. Mergemodule, die fr die 32-Bit-Verwendung gekennzeichnet sind, lassen sich hingegen
in jedes Installationspaket integrieren.
Hinweis Ende
Abbildung 3.21: Plattform-Architektur im Summary Information Stream
Bei der Erstellung eines Paketes mit Windows Installer-XML ist die zu verwendende Architektur dem
Attribut Platform des Elementes <Package/> anzufgen, wie dieses auch in Listing 3.26 dargestellt
wird.
<?xml version="1.0" encoding="Windows-1252"?>
<Product UpgradeCode="{DBC3A49F-67B4-4bce-A596-660D365DBFD8}" Manufacturer="Microsoft Deutschland GmbH"
Language="1033" Version="1.00.0000" Name="Football 2008" Id="{0BC4E7F4-8840-4d23-9AF9-C68CFFDC7C0E}"
Codepage="1252">
<Package Keywords="Microsoft Windows Installer, MSI" Description="Football 2008"
Manufacturer="Andreas Kerl" InstallerVersion="200" Platform="x64" Languages="1033"
Compressed="yes" SummaryCodepage="1252" InstallPrivileges="elevated" />

</Product>
</Wix>
Listing 3.26: Festlegen der Plattform-Architektur mit Windows Installer-XML
Zur Festlegung der Architektur mit Windows Installer-XML stehen die Werte Intel, Intel64, x86, x64
134
Kapitel 3
und ia64 zur Verfgung. Beim Kompilieren des WXS-Dokuments wird bei Verwendung von Intel und
Intel64 eine Warnung ausgegeben und darauf hingewiesen, dass diese Werte nicht mehr zu verwenden
sind.
D:\Draft\Product.wxs(12)
has been deprecated.
D:\Draft\Product.wxs(12)
has been deprecated.
: warning CNDL1111 : The value "intel64" for the Package/@Platform attribute

Please use "ia64" instead.
: warning CNDL1111 : The value "intel" for the Package/@Platform attribute
Please use "x86" instead.
Diese Manahme trgt ganz entscheidend zur bersichtlichkeit bei und stellt die Konsistenz zu den
regulren Bezeichnungen wieder her, wie auch in der Gegenberstellung der Bezeichnungen
aufgezeigt wird.
Architektur
Windows Installer
x86
Intel
x86
AMD64
AMD64 oder x64
x64
Intel64
AMD64 oder x64
x64
IA64
Intel64
ia64
x64
AMD64 oder x64
x64
Tabelle 3.33: Gegenberstellung der Kennzeichnungen bei den Plattform-Architekturen
Ein Installationspaket muss als 32-Bit oder 64-Bit-Paket spezifiziert werden. Die Mglichkeit der
Kennzeichnung als neutrales Paket ber einen generischen Eigenschaftswert besteht nicht. Es wird
somit deutlich, dass es nicht mglich ist, ein Installationspaket fr unterschiedliche Zielplattformen zu
definieren. Auch die Kombination mehrerer Eigenschaftswerte ist nicht erlaubt.
Es ist nicht mglich, ein Windows Installer-Paket so zu kennzeichnen, dass die Plattformen Intel64
und x64 untersttzt werden. Der Eigenschaftswert Intel64,x64 ist ungltig.
Es ist nicht mglich, ein Windows Installer-Paket so zu kennzeichnen, dass die 32-Bit und die 64Bit Plattform untersttzt werden. Der Eigenschaftswert Intel,x64 oder Intel,Intel64 ist
ungltig.
Falls versucht wird ein 64-Bit-Paket auf einer 32-Bit-Plattform zu installieren, wird der
Installationsversuch durch den Fehler 1633 (ERROR_INSTALL_PLATFORM_UNSUPPORTED)
abgebrochen. Auf einen 64-Bit-Plattform wird der Windows Installer in einem 64-Bit-Prozess
ausgefhrt, so dass sowohl 32-Bit als auch 64-Bit-Pakete installiert werden knnen. Hierbei gibt es
drei Arten ein Installationspaket zu definieren und zu konstruieren.
Ein 32-Bit-Paket, das ausschlielich 32-Bit-Komponenten enthlt.
Ein 64-Bit-Paket, das einige 32-Bit-Komponenten enthlt.
Ein 64-Bit-Paket, das ausschlielich 64-Bit-Komponenten enthlt.
Hier stellt sich nun die Frage, warum eine plattformspezifische Kennzeichnung berhaupt
vorgenommen werden muss. Die Installation eines 32-Bit Paketes auf einer 64-Bit Plattform scheint ja
auf den ersten Blick zu funktionieren, denn es kommt zu keinen diesbezglichen Installationsfehlern.
Wre dieses nicht ein geeigneter generischer Ansatz?
135
Kapitel 3

Die Frage des letzten Abschnitts kann nicht pauschal beantwortet werden, denn dieses ist in erster
Linie natrlich von der Anwendung und dem Installationspaket abhngig. Die Installation sollte
problemlos erfolgen, allerdings kann es geschehen, dass Komponenten mitunter nicht richtig installiert
werden, so dass die Ausfhrung der Anwendung nicht sichergestellt werden kann. Hiermit ist nicht der
tatschliche Installationsprozess gemeint, sondern der Zugriff auf Ordner und die Systemregistrierung
von der Anwendung aus. Hier findet sich auch die gravierende Anforderung zur Verwendung
unterschiedlicher Pakete fr unterschiedliche Plattformen. Nur durch die geeignete Kennzeichnung
wird sichergestellt, dass 64-Bit-Dateien in den richtigen Verzeichnissen abgelegt und der Zugriff auf
die Systemregistrierung durch 64-Bit-Komponenten ermglicht wird. Bei der Installation einer 32-BitAnwendung auf einem 64-Bit-Betriebssystem werden die Ordnerzugriffe und Zugriffe auf die
Systemregistrierung umgeleitet, so dass von der Anwendung auch auf die zutreffenden Bereiche
zugegriffen werden kann.
WOW64-Subsystem
Gerade die letzte Aussage sollte noch ein wenig verdeutlich werden. Alle 64-Bit-Versionen von
Windows enthalten ein Subsystem zur Ausfhrung von 32-Bit-Anwendungen, das als WOW64
(Windows-On-Windows 64-Bit) bezeichnet wird. Der hauptschliche Zweck liegt in der Bereitstellung
einer 32-Bit-Umgebung, in der smtliche Schnittstellen zur Verfgung stehen, die 32-Bit-WindowsAnwendungen bentigen, um ohne Anpassungen auf einem 64-Bit-System zu laufen. Dieses ist der
ganz entscheidenden Punkt, denn eine 32-Bit-Anwendung muss nicht explizit verndert werden. Das
Betriebssystem stellt automatisch fest, wenn es sich um eine 32-Bit-Anwendung handelt und fhrt
diese dann im Subsystem aus.
Mitunter kann es innerhalb einer Anwendung erforderlich werden, herauszufinden, ob sie als 64-Bit
oder 32-Bit-Prozess ausgefhrt wird. Dieses kommt besonders bei .NET-Abwendungen zum Tragen,
die nicht fr eine spezifische Architektur kompiliert wurden, sondern fr die generische Verwendung
auf unterschiedlichen Plattformen. Hierbei wird beim Kompilieren lediglich ein Zwischencode
(Microsoft Intermediate Language) erzeugt, der im Rahmen JIT-Kompilierung (Just-In-Time) erst auf
dem Zielsystem fr die jeweilige Architektur angepasst wird. Ob ein Assembly fr die
plattformunabhngige Verwendung konfiguriert wurde oder ob bereits beim Kompilieren eine
spezifische
Architektur
festgelegt
wurde,
lsst
sich
ber
die
Eigenschaft
System.Reflection.Assembly.ProcessorArchitecture abrufen. Diese Eigenschaft kann die in Tabelle
3.34 aufgefhrten Werte zurckliefern.
Wert
Beschreibung
MSIL
Neutrales Format zur plattformunabhngigen Verwendung.
X86
Kann auf einer 32-Bit-Plattform oder im WOW64-Subsystem einer 64-Bit-Plattform verwendet

werden.
IA64
Kann auf einer IA64-Plattform verwendet werden.
Amd64
Kann auf einer X64-Plattform verwendet werden.
Tabelle 3.34: Kennzeichnung der Architektur bei einem .NET-Assembly
Wird ein plattformunabhngiges Assembly (MSIL) auf einem 64-Bit-System ausgefhrt, wird es auch
136
Kapitel 3
als 64-Bit-Anwendung kompiliert und entsprechend verwendet. Identisches gilt fr die Ausfhrung auf
einem 32-Bit-System. Das Betriebssystem stellt die Kernel-Funktion IsWow64Process()fr solche
Prfmechanismen zur Verfgung. Allerdings existiert die Funktion nur bei 64-Bit-Betriebssystemen,
so dass eine plattformunabhngige Prfmethode nur sehr aufwndig und unter Bercksichtigung von
Fehlercodes mglich ist. Einfacher gestaltet sich eine Prfung, bei die Gre bestimmter Objekte
geprft wird. Die Struktur System.IntPtr ist plattformabhngig und wird zur Reprsentation eines
Zeigers oder eines Handles verwendet, so dass sich die Gre der Struktur in Abhngigkeit zur
verwendeten Architektur ndert. Innerhalb eines 64-Bit-Prozesses ist die Struktur 8 Byte gro ist;
innerhalb eines 32-Bit-Prozesses hingegen nur 4 Byte. Dieser Umstand lsst sich ausnutzen und auf
einfache Weise zur Prfung der Architektur heranziehen, wie auch Listing 3.27 zeigt.
// Gibt True zurck, falls es sich um einen 64-Bit-Prozess handelt
public static bool Is64Bit
{
get { return (IntPtr.Size == 8); }
}
Listing 3.27: Ermittelt die Architektur des Prozesses
Das WOW64-Subsystem isoliert 32-Bit-Binrdateien von den 64-Bit-Binrdateien, indem es

spezifische Registrierungs- und Dateisystemaufrufe umleitet. Das WOW64-Subsystem isoliert diese
Dateien, um zu verhindern, dass eine 32-Bit-Binrdatei zufllig auf Daten aus einer 64-Bit-Binrdatei
zugreift. Eine 32-Bit-Anwendung, die eine Objektbibliothek aus dem Ordner %systemroot%\system32
ausfhrt, knnte beispielsweise zufllig versuchen, auf eine 64-Bit-Objektbibliothek zuzugreifen, die
natrlich mit der Anwendung nicht kompatibel ist. Um dies zu verhindern, leitet das Subsystem den
Zugriff vom Ordner %systemroot%\system32 auf den Ordner %systemroot%\SysWOW64 um.
Hierdurch werden Kompatibilittsprobleme vermieden, da die Objektbibliothek in diesem Fall speziell
fr die Verwendung mit 32-Bit-Programmen entwickelt wurde. Was hinsichtlich der Namensgebung
auf den ersten Blick merkwrdig aussieht, ist aus Grnden der Kompatibilitt erforderlich. Der Ordner
%systemroot%\system32 beinhaltet die 64-Bit-Komponenten und die 32-Bit-Komponenten werden im
Ordner %systemroot%\SysWOW64 abgelegt.
Ein hnliches Bild ergibt sich auch beim Global Assembly Cache, der Assemblies in Abhngigkeit zur
Architektur isoliert betrachtet und verwaltet. So existieren Speicherbereiche fr Assemblies die zur
Ausfhrung auf einer 64-Bit-Plattform kompiliert wurden und natrlich auch fr solche die fr die 32Bit-Plattform vorgesehen wurde. Zustzlich existiert ein Speicherbereich, der plattformunabhngige
Assemblies aufnimmt. Die Zuordnung welcher Speicherbereich verwendet wird, erfolgt automatisch
und orientiert sich an der bereits beschriebenen Kennzeichnung innerhalb des Assemblies. Die
jeweilige Zuordnung wird auch im Windows-Explorer dargestellt, wie dieses in Abbildung 3.22
gezeigt wird.
137
Kapitel 3
Abbildung 3.22: Kennzeichnung der Architektur im Global Assembly Cache
Was fr das Dateisystem gilt auch fr die Systemregistrierung. Auch hier wurde das Layout gendert,
so dass die Eintrge wiederum isoliert voneinander abgelegt werden. Das bedeutet, dass ein 32-BitProzess auf einen anderen Bereich der Systemregistrierung zugreift, als ein 64-Bit-Prozess. Greift ein
64-Bit-Prozess auf den Registrierungsschlssel HKEY_LOCAL_MACHINE\Software zu, werden die
Informationen auch aus diesem Schlssel verwendet. Greift hingegen ein 32-Bit-Prozess auf diesen
Schlssel
zu,
findet
eine
Umleitung
statt
und
die
Informationen
von
HKEY_LOCAL_MACHINE\Software\WOW6432node werden verwendet. Dieses funktioniert
automatisch und wird als Registry Redirection bezeichnet. Diese Unterteilung lsst sich hervorragend
mit dem Registrierungs-Editor betrachten. Starten Sie diesen auf einem 64-Bit-System, indem sie den
Befehl regedit.exe im Dialogfeld Ausfhren eingeben. Wechseln Sie nun zu
HKEY_LOCAL_MACHINE\Software. Starten Sie anschlieend den 32-Bit-Registrierungs-Editor,
indem sie im Dialog Ausfhren den Befehl %systemroot%\SysWOW64\regedit.exe -m eingeben. Das
Argument -m ermglicht das ffnen mehrerer Instanzen des Editors. Bei der Betrachtung des
identischen Schlssels, sind die Unterschiede offensichtlich, wie auch Abbildung 3.23 zeigt.
138
Kapitel 3
Abbildung 3.23: Unterschiedliche Ansichten mit dem Registrierungs-Editor
Die Systemregistrierung verfgt noch ber weitere interessante Erweiterungen, wie die Verwendung
gemeinsamer Eintrge und die sogenannte Spiegelung von Eintrgen. Die gemeinsamen Eintrge
gelten sowohl fr den 32-Bit-Bereich, als auch fr den 64-Bit-Bereich. Das bedeutet, dass fr diese
Eintrge keine Umleitung durchgefhrt wird. Die gemeinsam verwendeten Eintrge sind alle unter
HKEY_LOCAL_MACHINE\Software zu finden. Nachfolgend findet sich ein Auszug aus den
Registrierungsschlsseln, die fr beide Sichten gelten:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Non-Driver Signing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Software\Microsoft\Shared Tools\MSInfo
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup
HKEY_LOCAL_MACHINE\SOFTWARE\Policies
Die Zielsetzung der Spiegelung (Registry Reflection) ist eine Andere und liegt in der Duplizierung
eines Eintrages, der in beiden Sichten synchron gehalten wird. Wird also ein Eintrag im 64-Bit-Bereich
angelegt, wird automatisch ein Duplikat im 32-Bit-Bereich der Registrierung abgelegt. Dieses
139
Kapitel 3
Verfahren gilt bei den folgenden Registrierungsschlsseln:

HKEY_LOCAL_MACHINE\Software\Classes
HKEY_LOCAL_MACHINE\Software\Microsoft\COM3
HKEY_LOCAL_MACHINE\Software\Microsoft\EventSystem
HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
HKEY_USERS\{SID}\Software\Classes
HKEY_USERS\{SID}_Classes
Hierbei ist aber zu beachten, dass dieses Szenario immer von beiden Seiten betrachtet werden muss.
Das bedeutet, dass sich ein Eintrag im 64-Bit-Bereich auf den 32-Bit-Bereich genauso auswirkt wie die
umgekehrte Reihenfolge. Also ein Eintrag im 32-Bit-Bereich wird auch im 64-Bit-Bereich
vorgenommen. Es gewinnt immer der letzte Eintrag.
Verhalten bei der Installation

Im Rahmen der Entwicklung des Installationspaketes sind ebenfalls einige Faktoren zu beachten, damit
die Installation auch wie erwartet durchgefhrt wird. Zunchst ist fr das gesamte Paket die zu
verwendende Plattform-Architektur zu bestimmen. Das bedeutet, dass die Eigenschaft
PID_TEMPLATE des Summary Information Streams auf den Wert x64 oder Intel64 festzulegen
ist. Die Vorgehensweise dafr wurde bereits erlutert. Durch diese Definition wird der
Installationsprozess nicht wesentlich beeinflusst. Allerdings fhrt diese nderung bereits dazu, dass
die Registrierung des Produktes im 64-Bit-Bereich der Systemregistrierung vorgenommen wird.
Weiterhin wird diese Eigenschaft automatisch beim Starten der Installation ausgewertet, um ein
Prfung der Systemarchitektur durchzufhren. Hiermit kann beispielsweise ausgeschlossen werden,
dass das Produkt auf einem 32-Bit-System installiert wird. Darber hinaus muss die Eigenschaft
PID_PAGECOUNT des Summary Information Streams auf einen Wert von mindestens 200 gesetzt
werden. Dieser Wert besagt, dass zur Installation der Windows Installer mindestens in der Version 2.0
vorhanden sein muss. Diese Version ist erforderlich, da vorherige Versionen des Windows Installers
keine 64-Bit-Untersttzung enthielten. Dieses waren die Definitionen auf Paketebene, die unbedingt
durchzufhren sind. Weitere Festlegungen beziehen sich auf Komponentenebene, wobei der Umfang
dieser Einstellungen vom Aufbau der Anwendung und des Gesamtpaketes abhngig sind. Hierbei muss
jede 64-Bit-Komponente auch als solche gekennzeichnet werden, damit die Komponentenregistrierung
an der richtigen Position ausgefhrt wird. Zur Kennzeichnung ist das Attribut
msidbComponentAttributes64bit der Spalte Attributes der Tabelle Component anzufgen. Die
Definition bei der Verwendung von Windows Installer-XML erfolgt durch das Attribut Win64 wie das
folgende Beispiel zeigt.
<Component Id="C__DD.exe" Guid="6ABBEDC4-3D20-4901-BBAE-D6D16127571A" Win64="yes">
<File Id="F__DD.exe" Source=".\Binaries\" Name="DD.exe" KeyPath="yes" DiskId="1" />
</Component>
Diese Einstellungen sind fr die Zugriffe auf die Systemregistrierung uerst relevant. Bei Zugriff auf
das Dateisystem ist dieses nicht der Fall, denn die Definition der Ablagestruktur erfolgt durch die
folgenden Eigenschaften:
CommonFiles64Folder
140
Kapitel 3
CommonFilesFolder
ProgramFiles64Folder
ProgramFilesFolder
System64Folder
SystemFolder
Bei der Betrachtung der Eigenschaften fllt auf, dass es sich um die 32-Bit und 64-BitReprsentationen bestimmter Systemordner handelt. Vom logischen Gesichtspunkt her, sollte davon
ausgegangen werden, dass durch die Eigenschaft ProgramFiles64Folder der Ordner C:\Program
Files und durch ProgramFilesFolder der Ordner C:\Program Files (x86) definiert werden. Vom
Prinzip her ist diese Annahme richtig, dennoch entspricht sie nicht der Realitt, denn es muss ebenfalls
die Paketdefinition einbezogen werden. Das bedeutet, dass bei einer 64-Bit-Komponente, dessen
Installationsverzeichnis auf ProgramFiles64Folder festgelegt wurde, eine Umleitung auf
ProgramFilesFolder stattfindet, falls es sich um ein 32-Bit-Installationspaket handelt. Dieses wird bei
der Betrachtung des Installationsprotokolls besonders deutlich. Hier ist erkennbar, dass der
ProgramFiles64Folder zunchst richtig gesetzt, dieser aber anschlieend wieder auf das quivalente
32-Bit Verzeichnis zurckgesetzt wird.
MSI (s) (24:18) [18:20:30:922]: WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters
in 'C:\Program Files\' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).
MSI (s) (24:18) [18:20:30:922]: PROPERTY CHANGE: Modifying ProgramFiles64Folder property. Its current value
is 'C:\Program Files\'. Its new value: 'C:\Program Files (x86)\'.
Dieses Verhalten zeigt die Relevanz, die die Festlegung der jeweiligen Plattform auf Ebene der
Paketdefinition einnimmt. Hier ist noch anzumerken, dass dieses Verhalten fr alle der oben
skizzierten Ordner gilt, wie auch Tabelle 3.35 aufzeigt.
Ordner
32-Bit-Paket auf x86

Plattform

Plattform

Plattform
CommonFiles64Folder
Null
C:\Program Files
(x86)\Common Files\
C:\Program Files\Common
Files\
CommonFilesFolder
C:\Program
Files\Common Files\
C:\Program Files
(x86)\Common Files\
C:\Program Files
(x86)\Common Files\
ProgramFiles64Folder
Null
C:\Program Files (x86)\
C:\Program Files\
ProgramFilesFolder
C:\Program Files\
System64Folder
Null
C:\Windows\SysWOW64\
C:\Windows\system32\
SystemFolder
C:\Windows\system32\
Tabelle 3.35: Ordnerpfade in Abhngigkeiten zur Zielplattform und zum Installationspaket
Der Zugriff auf die Systemregistrierung gestaltet sich einfacher, da hierbei keine speziellen Variablen
zu verwenden sind. Der tatschliche Ablageort orientiert sich ausschlielich an dem Attribut
msidbComponentAttributes64bit. Schreibt eine so gekennzeichnete Komponente unter
HKEY_LOCAL_MACHINE\Software, werden die Informationen auch an dieser Stelle abgelegt.
Handelt es sich um eine Komponente ohne diese Kennzeichnung, also eine 32-Bit-Komponente, wird
der Eintrag unter HKEY_LOCAL_MACHINE\Software\Wow6432Node abgelegt. Eine 64-Bit
141
Kapitel 3
Komponente schreibt somit in den 64-Bit Bereich und eine 32-Bit Komponente natrlich in den 32-Bit
Bereich der Systemregistrierung. Im Installationsprotokoll lassen sich diese Unterscheidungen an den
Parametern der Operationsanweisung RegOpenKey nachvollziehen. Bei 32-Bit Komponenten ist dem
Parameter BinaryType der Wert 0 zugeordnet, bei 64-Bit Komponenten hingegen der Wert 1.
MSI (s) (F8:C4) [18:52:52:776]: Executing op: RegOpenKey(Root=2147483646,Key=SOFTWARE\MsiTest,,BinaryType=0,)
MSI (s) (F8:C4) [18:52:52:776]: Executing op: RegAddValue(Name=Typ,Value=32-Bit-Komponente,)
MSI (s) (F8:08) [18:52:03:782]: Executing op: RegOpenKey(Root=2147483646,Key=SOFTWARE\MsiTest,,BinaryType=1,)

MSI (s) (F8:08) [18:52:03:782]: Executing op: RegAddValue(Name=Typ,Value=64-Bit-Komponente,)
An einer vorherigen Stelle wurde bereits die Spiegelung von Registrierungsschlsseln (Registry
Reflection) erlutert. Hierbei werden Registrierungsschlssel automatisch dupliziert und
synchronisiert. Falls dieses nicht gewnscht ist, kann der Mechanismus auer Kraft gesetzt werden.
Hierzu
ist
die
entsprechende
Komponente
mit
dem
Attribut
msidbComponentAttributesDisableRegistryReflection zu versehen ist. Es gilt zu beachten, dass dieses
Attribut erst mit dem Windows Installer 4.0 bereitgestellt wurde und auch nur fr Windows Vista und
Windows Server 2008 gltig ist. Auf allen anderen Betriebssystemen und auf 32-Bit-Plattformen wird
das Attribut ignoriert.
Die Definition mit Windows Installer-XML ist wiederum sehr einfach, wie nachfolgend auch
nachfolgend dargestellt wird. Hierbei ist das Attribut DisableRegistryReflection des Elements
Component zu verwenden.
<Component Id="C__C1" Guid="26076C98-F5F3-4BD6-9547-F0252D6DB801" Win64="yes" DisableRegistryReflection="no">
<RegistryValue Id="R__Typ" Root="HKLM" Key="SOFTWARE\Classes\Msi.Demo" Value="Demo"
Type="string"></RegistryValue>
</Component>
Das dargestellte Beispiel konstruiert eine 64-Bit-Komponente, bei der das Attribut
DisableRegistryReflection nicht gesetzt wurde und somit das Standardverhalten reprsentiert. Das
bedeutet dass in dem Beispiel die folgenden Eintrge in der Systemregistrierung erzeugt und synchron
gehalten werden.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Msi.Demo
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\Msi.Demo
Das gleiche Ergebnis wird auch erreicht, wenn es sich um eine 32-Bit-Komponente handelt. Wird nun
bei der 64-Bit-Komponente das Attribut DisableRegistryReflection aktiviert, wird der folgende
Schlssel erzeugt:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Msi.Demo
Wird hingegen bei einer 32-Bit-Komponente das Attribut DisableRegistryReflection aktiviert wird
auch nur der folgende 32-Bit-Schlssel erzeugt.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\Msi.Demo
Die bisherigen dargestellten Mglichkeiten bezogen sich auf den schreibenden Zugriff auf die
Systemregistrierung, also auf die Modifikation. Soll jedoch im Rahmen der Installation lesend auf die
Systemregistrierung zugegriffen werden, steht zu diesem Zweck die Tabelle RegLocator zur
Verfgung. Die Eintrge dieser Tabelle sind mit keiner Komponente verknpft, so dass ber diesen
142
Kapitel 3
Mechanismus nicht der Bit-Spezifische Teilbereich der Systemregistrierung spezifiziert werden kann.
Aus diesem Grund muss der Eintrag der Tabelle RegLocator weiter qualifiziert werden, um somit eine
Unterscheidung zwischen dem 32-Bit-Bereich und dem 64-Bit-Bereich zu treffen. Zu diesem Zweck
steht das Attribut msidbLocatorType64bit zur Verfgung, dass mit Windows Installer-XML wie folgt
umgesetzt wird.
<Property Id="DOTNET64BITENABLED">
<RegistrySearch Id="RegSearch" Root="HKLM" Key="SOFTWARE\Microsoft\.NETFramework"
Name="Enable64Bit" Type="raw" Win64="yes"/>
</Property>
Listing 3.28: Durchsuchen des 64-Bit-Bereichs der Systemregistrierung
Eigenschaften
Zur Beeinflussung des Installationsprozesses und zur Modellierung des Installationsergebnissen stehen
natrlich auch Eigenschaften zur Verfgung, die plattformspezifische Informationen enthalten. Somit
ist es mglich diese in Bedingungen zu verwenden und somit Fallunterscheidungen zu treffen.
Mitunter kann es erforderlich werden, die Installation einer Komponente von der Plattformarchitektur
abhngig zu machen, so dass diese mit einer Bedingung zu versehen ist. Im einfachsten Fall knnen
hierzu die Eigenschaften VersionNT oder VersionNT64 verwendet werden. Beide Eigenschaften
werden auf die Versionsnummer des Betriebssystems gesetzt. Die Eigenschaft VersionNT ist auf jeder
Plattform verfgbar. Die Eigenschaft VersionNT64 wird hingegen nur auf einer 64-Bit-Plattform
gesetzt; auf einer 32-Bit-Plattform ist diese Eigenschaft gar nicht vorhanden.
Ist diese Unterscheidung nicht ausreichend und ist es erforderlich, die tatschliche Prozessorarchitektur
innerhalb der Bedingung zu prfen, so muss auf andere Eigenschaften ausgewichen werden. Bei der
Installation werden vom Windows Installer spezifische Eigenschaften gesetzt, die Auskunft ber die
verwendeten Prozessorarchitekturen geben. Der angefgte Wert wird auf den numerischen ProzessorLevel (wProcessorLevel) der Windows-Struktur SYSTEM_INFO gesetzt, also 4 fr 486, 5 fr P5
und 6 fr P6. Die folgenden Eigenschaften knnen hierfr verwendet werden:
Intel: Diese Eigenschaft wird gesetzt, wenn die Installation auf einem Intel-Prozessor (32-Bit)
ausgefhrt wird. Wird die Installation auf einem x64-Prozessor ausgefhrt, wird diese Eigenschaft
ebenfalls gesetzt, da der 64-Bit-Prozesor die 32-Bit-Befehlsstze nativ untersttzt.
Intel64: Diese Eigenschaft wird nur bei einem Itanium-Prozessor, also IA64 gesetzt. Bei einem
x64-Prozessor wird die Eigenschaft hingegen nicht gesetzt. Diese Eigenschaft ist verfgbar seit
Windows Installer 2.0.
MsiAMD64: Wird gesetzt, falls die Installation auf einem x64-Prozessor ausgefhrt wird. Diese
Eigenschaft ist verfgbar seit Windows Installer 3.0. Sie ist jedoch nur noch aus Grnden der
Kompatibilitt vorhanden.
Msix64: Wird gesetzt, falls die Installation auf einem x64-Prozessor ausgefhrt wird. Diese
Eigenschaft ist verfgbar seit Windows Installer 3.1.
Entscheidend wird hierbei in den wenigsten Fllen der tatschliche Eigenschaftswert sein, sondern
lediglich die Existenz der Eigenschaft. Wird die Installation beispielsweise auf einem x64-System
durchgefhrt, sind die Eigenschaften Intel, MsiAMD64 und Msix64 gesetzt. Die Eigenschaft Intel64 ist
hingegen gar nicht vorhanden.
143
Kapitel 3
Allgemeine Hinweise
Darber hinaus existieren noch allgemeine Hinweise, die sich auf die Verwendung von Komponenten
beziehen. Beim Design eines Installationspaketes, das sowohl 32-Bit, als auch 64-Bit-Dateien enthlt,
sind die Verzeichnispfade so zu whlen, dass es hierdurch zu keiner Beeintrchtigung kommt. Hiermit
ist gemeint, dass sich einerseits die Dateien im Rahmen der klassischen Installation nicht
berschreiben. Auf der anderen Seite ist natrlich auch die Festlegung der Quellverzeichnisse nicht
uninteressant, denn im Rahmen einer administrativen Installation werden diese verwendet. Somit ist
auch hierbei darauf zu achten, dass sich die Dateien nicht gegenseitig berschreiben. Weiterhin ist zu
beachten, dass es sich bei 32-Bit und 64-Bit-Komponenten aus Sicht des Windows Installers um
unterschiedliche Komponenten handelt, so dass sie auch ber eine unterschiedliche Komponenten-ID
verfgen mssen. Identisches gilt auf Ebene des Produktes; auch hier sind unterschiedliche
Produktcodes zu verwenden.
Bei Mergemodulen muss ebenfalls die Eigenschaft PID_TEMPLATE des Summary Information
Streams auf die entsprechende Prozessorarchitektur gesetzt werden. Hierbei ist zu beachten, dass sich
Mergemodule, die mit Intel64 gekennzeichnet sind, natrlich auch nur in die identisch
gekennzeichneten Installationspakete integrieren lassen. Gleiches gilt fr die Kennzeichnung mit x64.
Mergemodule, die fr die 32-Bit-Verwendung gekennzeichnet sind, lassen sich hingegen in jedes
Installationspaket integrieren.
Die bisherigen Ausfhrungen haben gezeigt, dass es problemlos mglich ist eine 32-Bit-Datei in ein
64-Bit-Verzeichnis zu kopieren und umgekehrt. Weiterhin stellte es auch kein groes Problem dar, die
Zugriffe auf die Systemregistrierung durch die Eigenschaft msidbComponentAttributes64bit zu
beeinflussen. Diese Vorgehensweisen sind natrlich problemlos im Rahmen der Installation
durchzufhren, so dass rein formal eine funktionsfhige Anwendung installiert werden knnte. Dieses
kann jedoch nicht verallgemeinert werden, denn im Rahmen der Installation fehlt natrlich die
Betrachtung des tatschlichen Ausfhrungsverhaltens der Anwendung. So kann es geschehen, dass die
Anwendung fehlerfrei installiert wurde, sich aber in keinem funktionsfhigen Zustand befindet, da das
Installations-Layout ungeeignet war. Anders verhlt es sich bei der Verwendung von
benutzerdefinierten Aktionen, denn hierbei tauchen solche Probleme direkt bei der Installation auf. Das
bedeutet auch, dass ein nicht ordentlich konzipiertes Installationspaket zwangslufig zu einem
Installationsfehler fhren wird. Eine 64-Bit-Datei kann problemlos auf ein 32-Bit-System kopiert
werden, aber eine 64-Bit-Datei kann nicht als benutzerdefinierte Aktion bei der Installation auf einem
32-Bit-System verwendet werden.
Benutzerdefinierte Aktionen werden nicht im eigentlichen Installationsprozess ausgefhrt, sondern in
einem fr diese Flle speziellen Host-Prozess, der als Custom Action-Server bezeichnet wird. Auf einer
64-Bit Plattform existieren Custom Action-Server sowohl in 32-Bit, als auch in 64-Bit Ausprgung.
Die Zuordnung zum jeweiligen Host-Prozess wird nicht durch die Konfiguration des Paketes
vorgenommen, sondern orientiert sich am tatschlichen Format der hierfr zu verwendenden Datei.
Eine 32-Bit-Objektblibliothek wird demzufolge automatisch im 32-Bit Custom Action-Server
ausgefhrt und eine 64-Bit-Bibliothek im 64-Bit-Server. Diese automatische Zuordnung funktioniert
jedoch nur fr Dateien, die ber ein PE-Header (Portable Executable File Format) verfgen, also auch
bei Objektbibliotheken. Mit Hilfe des Windows Task-Mangers kann festgestellt werden, welcher
144
Kapitel 3
Custom Action-Server hierfr verwendet wird. Wie bereits im Kapitel 1 erlutert wurde, existieren
mehrere Prozesse mit der Bezeichnung msiexec.exe. Die Host-Prozesse zum Ausfhren der
benutzerdefinierten Aktion, verfgen ber die identische Bezeichnung. Zur Identifizierung ist der
Befehlszeilenaufruf auszuwerten, denn diesen Prozessen wurde das Argument -Embedding
bergeben. Auf einem 64-Bit-System werden die 32-Bit-Prozesse durch die Zeichenfolge *32
gekennzeichnet. Dieses gilt natrlich auch fr die Custom Action-Server, wie die folgende Abbildung
3.24 zeigt.
Abbildung 3.24: Kenzeichnung eines 32-Bit Custom Action-Servers im Windows Task-Manger
Das Installationsprotokoll ist an dieser Stelle auch eine sehr groe Hilfe, denn hieraus kann direkt
abgelesen werden, in welchem Custom Action Server der Code ausgefhrt wird.
MSI (s) (74:14) [11:04:43:203]: Executing op: CustomActionSchedule(Action=CA_OutputString32,
ActionType=1025,Source=BinaryData,Target=OutputString,)
MSI (s) (74:14) [11:04:43:203]: Creating MSIHANDLE (1) of type 790536 for thread 3604
MSI (s) (74:44) [11:04:43:203]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI243.tmp,
Entrypoint: OutputString
MSI (s) (74:2C) [11:04:43:203]: Generating random cookie.
MSI (s) (74:2C) [11:04:43:219]: Created Custom Action Server with PID 2260 (0x8D4).
MSI (s) (74:64) [11:04:43:250]: Running as a service.
MSI (s) (74:64) [11:04:43:250]: Hello, I'm your 32bit Impersonated custom action server.
MSI (s) (74:14) [11:04:43:250]: Executing op: CustomActionSchedule(Action=CA_OutputString64,

ActionType=1025,Source=BinaryData,Target=OutputString,)
MSI (s) (74:14) [11:04:43:250]: Creating MSIHANDLE (3) of type 790536 for thread 3604
MSI (s) (74:8C) [11:04:43:266]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI244.tmp,
Entrypoint: OutputString
MSI (s) (74:2C) [11:04:43:266]: Generating random cookie.
MSI (s) (74:2C) [11:04:43:266]: Created Custom Action Server with PID 3480 (0xD98).
MSI (s) (74:08) [11:04:43:282]: Running as a service.
MSI (s) (74:64) [11:04:43:282]: Hello, I'm your 64bit Impersonated custom action server.
145
Kapitel 3
Listing 3.29: Kennzeichnung der Custom Action-Server im Installationsprotokoll
Wie bereits weiter oben erlutert, funktioniert die automatische Zuordnung des Custom Action-Servers
nur fr Dateien, die ber ein PE-Header verfgen. Bei Skriptdateien oder der Verwendung von
Skriptcode funktioniert diese Automatik somit nicht, so dass eine manuelle Zuordnung erfolgen muss.
Hierfr steht das Attribut msidbCustomActionType64BitScript zur Verfgung, dass der Spalte Type der
Tabelle CustomAction anzufgen ist. Bei der Verwendung von Windows Installer-XML erfolgt die
Zuordnung ber das Attribut Win64 des Elementes <CustomAction/>, wie auch Listing 3.30 zeigt.
Wie bei den Objektdateien, wird die Verwendung des jeweiligen Custom Action-Servers dem
Installationsprotokoll ebenfalls angefgt.

<Binary Id="VBScript" SourceFile=".\Binaries\GetInfos.vbs" />

<CustomAction Id="CheckEnvironment" BinaryKey="VBScript" VBScriptCall="Main"
Win64="yes" Execute="immediate"/>

<Custom Action="CheckEnvironment" Before="LaunchConditions"/>
Listing 3.30: Definition einer benutzerdefinierten Aktion vom Typ Skript
Ausfhrbare Dateien, die als benutzerdefinierten Aktionen verwendet werden, bentigen keine
besondere Kennzeichnung, denn sie werden im eigenen Prozessraum ausgefhrt und sind somit auf
keinen Host-Prozess angewiesen.
Richtlinien
Es ist erkennbar, dass die Erstellung und Konfiguration von Installationspaketen fr unterschiedlichen
Plattformen und Prozessorarchitekturen als nicht trivial zu bezeichnen ist. Aus diesem Grund sollten
die folgenden Dinge bei der Erstellung eines 64-Bit-Paketes beachtet werden:
Verwenden sie das Windows Installer-Datenbankschema 200oder hher. Legen Sie die Version
2.0 als minimale Windows Installer-Version fest, die bentigt wird, um das Paket zu installieren.
Hierzu ist die Eigenschaft PID_PAGECOUNT im Summary Information Stream auf den Wert
200zu setzen. Frhere Versionen des Windows Installers lassen die Installation von 64-BitPaketen nicht zu.
Legen Sie die erforderliche Prozessorarchitektur fr dieses Paket fest. Verwenden Sie den Wert
Intel64 in der Eigenschaft PID_TEMPLATE des Summary Information Streams, falls das Paket
auf einer IA64-Plattform ausgefhrt werden soll. Verwenden Sie hingegen den Eigenschaftswert
x64 um die Ausfhrung auf einem x64 System, also EM64T und AMD64 zu ermglichen. Ein
Paket kann nicht mehrere Plattformen untersttzen. Daher sind die Eigenschaftswerte
Intel64,x64, Intel,x64 oder Intel,Intel64 ungltig.
Identifizieren sie jede 64-Bit Komponente, indem sie in der Spalte Attributes der Tabelle
Component das Attribut msidbComponentAttributes64bit verwenden.
Verwenden sie Bedingungen um die Version des 64-Bit-Betriebssystems zu prfen, falls dieses
146
Kapitel 3
erforderlich ist. Hierzu ist die Eigenschaft VersionNT64 zu verwenden. Diese Eigenschaft wird nur
unter 64-Bit gesetzt; bei 32-Bit befindet sich diese Eigenschaft in einem nicht definierten Zustand.
Verwenden sie Bedingungen um die Prozessorarchitektur und den numerischen Prozessor-Level zu
bestimmen, falls dieses erforderlich sein sollte. Verwenden sie hierzu die Eigenschaften Intel,
Intel64 oder Msix64.
Verwenden Sie die Tabelle AppSearch und die gleichnamige Aktion, um in der
Systemregistrierung nach existierenden 64-Bit-Elementen zu suchen, falls das erforderlich sein
sollte. Ergnzen Sie hierzu in der Tabelle RegLocator den Inhalt der Spalte Type um das Attribut
msidbLocatorType64bit.
Verwenden sie zum Bestimmen der Pfade zu den 64-Bit-Systemordnern die Eigenschaften
System64Folder, ProgramFiles64Folder und CommonFiles64Folder. Fr die 32-Bit-Systemordner
sind die Eigenschaften SystemFolder, ProgramFilesFolder und CommonFilesFolder zu
verwenden.
Stellen sie sicher, dass die Anwendung die korrekte GUID verwendet, falls sie 64-Bit
Komponenten ber den Mechanismus der qualifizierten Komponenten referenziert. Falls eine
Komponente sowohl in einer 32-Bit und einer 64-Bit Variante vorliegt, verfgen diese ber
unterschiedliche IDs.
Stellen sie sicher, dass die Komponente mit ODBCDriverManager64 bezeichnet wird, fall sie
einen 64-Bit ODBC Driver Manager installieren mchten. Der ODBC Driver Manager ist dieser
Komponente hinzuzufgen. Er wird installiert, falls es erforderlich sein sollte.
Stellen sie sicher, dass die Installation nur 32-Bit-Betriebssystemdienste verwendet, die als
ausfhrbare Datei vorliegen. Ein 64-Bit-Paket kann keine 32-Bit-Dienste aufrufen, die als
Objektbibliothek vorliegen.
Stellen sie sicher, dass die Eintrge in INI-Dateien richtig zugeordnet werden, falls eine
Anwendung koexistierende 32-Bit und 64-Bit-Varianten einer Komponente installiert.
Stellen sie sicher, dass 32-Bit-Patches nur auf 32-Bit-Dateien und 64-Bit-Patches nur auf 64-BitDateien angewendet werden.
32-Bit-Anwendungen die im WOW64-Subsystem ausgefhrt werden, benutzen eine andere Sicht
auf die Systemregistrierung als 64-Bit-Anwendungen. Durch die Spiegelung der Registrierung wird
erreicht, dass Eintrge der Systemregistrierung im 32-Bit-Bereich und 64-Bit-Bereich synchron
gehalten werden. Um diese Funktionalitt zu deaktivieren ist fr die entsprechende Komponente, in
der
Tabelle
Component
der
Spalte
Attribut
das
Attribut
msidbComponentAttributesDisableRegistryReflection anzufgen. Dieses Attribut steht nur mit dem
Windows Installer 4.0 und hher zur Verfgung und wird somit unter Verwendung der 64-BitVersionen von Windows 2000 und Windows XP ignoriert genauso ignoriert wie bei einem 32-BitBetriebssystem.
Nachdem das Installationspaket den Vorgaben entsprechend erstellt wurde, sollte einer fehlerfreien
Ausfhrung nichts mehr im Wege stehen. Falls es dennoch zu Fehlern kommen sollte, geben die
Fehlernummern darber Auskunft, ob es sich um eine 64-Bit-Problematik handelt.
1633: Das Installationspaket ist fr diese Plattform nicht geeignet. Hier wird versucht ein 64-BitPaket auf einer 32-Bit-Plattform oder ein 64-Bit-Paket auf einer inkompatiblen 64-Bit-Plattform zu
installieren.
2401. Es wird versucht eine 64-Bit-Operation in der Systemregistrierung eines 32-Bit-
147
Kapitel 3
Betriebssystems durchzufhren.
2943: Es wird versucht das Advertise-Skript eines 64-Bit-Paketes auf einem inkompatiblen
Betriebssystem auszufhren.
Um im Vorfeld alle Faktoren zu bercksichtigen, die bei der Entwicklung von 64-Bit-Paketen zu
beachten sind, ist bei einer Validierung die berprfungsart ICE80 besonders zu beachten.
Fazit
Auf den aktuellen 64-Bit-Plattformen knnen sowohl 32-Bit-Anwendungen, als auch 64-BitAnwendungen ausgefhrt werden. Die Installation einer 32-Bit-Anwendung und die Entwicklung eines
geeigneten Installationspaketes sind nahezu identisch mit den Vorgaben, die bei Installationen fr die
32-Bit-Plattform gelten. Das bedeutet aber auch, dass einige abweichende Verhaltensmuster existieren,
die besonders zu bercksichtigen sind. Diese Verhaltensmuster sind darauf zurckzufhren, dass 32Bit- und 64-Bit-Anwendungen voneinander isoliert abgelegt werden und somit die Anwendung eine
andere Sicht auf das System erhlt. Die Erstellung eines Installationspaketes zur Installation einer 64Bit-Anwendung weicht nicht wesentlich von den bekannten Vorgehensweisen ab. Wie auch bei der
Anwendungsentwicklung, sind bei der Erstellung solcher Pakete bestimmte Regeln zu beachten und
einige Vorberlegungen anzustellen. Nur wenn die unterschiedlichen Plattformeigenheiten auch
Beachtung finden, kann die Funktionsfhigkeit der zu installierenden Anwendung sichergestellt
werden.
148
Kapitel 4
Fazit
149
151
161
174
Der Windows Installer stellt seit jeher eine Schnittstelle zur Verfgung, mit der programmtechnische
Zugriffe auf interne Strukturen und Funktionen des Windows Installers realisiert werden knnen. Der
Zugriff kann hierbei ber die Funktionen des Windows Installer-API oder durch die Verwendung des
Windows Installer Objektmodells erfolgen. Beide Zugriffsmodelle haben ihre Vor- und Nachteile,
wobei die grten Probleme dadurch entstehen, dass die Modelle auf Technologien abzielen, die in
aktuellen Entwicklungsprojekten kaum noch verwendet werden. Die aktuellen Entwicklungstrends
verwenden eine Programmierlandschaft, die auf Basis einer verwalteten Sprache des Microsoft .NET
Frameworks realisiert wird. Der Windows Installer bietet jedoch keine direkte Zugriffsschicht fr
solche Implementierungen, so dass ein entsprechender Zugriff einige Probleme aufwirft. Die
Deployment Tools Foundation ist eine Sammlung von Klassenbibliotheken, die den Zugriff auf die
Windows Installer-Funktionalitt fr .NET ermglicht.
Um es vorweg zu nehmen, ich bin ein sehr groer Fan der Deployment Tools Foundation, denn ich
nutze diese bereits seit mehr als 5 Jahren sehr intensiv. Die Deployment Tools Foundation wurde
ursprnglich unter der Bezeichnung Managed Libraries for Windows Installer als interne
Toolsammlung bei Microsoft entwickelt und verwendet. Erst vor kurzem wurde die Deployment Tools
Foundation in die Toolsammlung Windows Installer-XML integriert und steht somit der breiten Masse
zur Verfgung.
Funktionalitt
Bei der Deployment Tools Foundation handelt es sich um eine Sammlung von .NETKlassenbibliotheken und sonstigen Ressourcen, mit denen die Bereitstellungs-Technologien der
Windows-Plattform der .NET-Welt zugnglich gemacht werden. Dieses wird realisiert durch die
Bereitstellung eines Basis-Frameworks, dessen Funktionalitt von Tools und Anwendungen genutzt
werden kann, um ein Softwareprodukt im gesamten Lebenszyklus zu verwalten. Diese
Inventarisierungsmglichkeit ist aber noch nicht alles, denn es ist ebenfalls mglich ein
Installationspaket zu entwickeln, zu analysieren, zu testen und auch zu debuggen. Darber hinaus kann
die Funktionalitt auch im Installationsprozess und zur Laufzeit der Anwendung verwendet werden.
149
Kapitel 4
Das bedeutet, dass die Entwicklung von Bootstrapper- oder Chainer-Anwendungen, externen
Benutzeroberflchen und auch benutzerdefinierte Aktionen hiermit hervorragend umgesetzt werden
kann. Es besteht natrlich auch die Mglichkeit funktionsspezifische Implementierungen in
Anwendungen zu integrieren, um somit zur Laufzeit den Zugriff auf die Bereitstellungs-Plattform zu
ermglichen. Unabhngig vom tatschlichen Einsatzzweck sollte der Vorteil der Deployment Tools
Foundation deutlich geworden sein. Hiermit ist es endlich mglich, Installationsspezifische Aufgaben
in einer modernen Programmiersprache zu erstellen und hierbei das gesamte Funktionsspektrum der
darunter liegenden Technologie nutzen zu knnen. Ein Beispiel hierfr knnte LINQ (Language
INtegrated Query) sein. Diese Funktionalitt ist neu im Microsoft .NET Framework 3.5 und ermglicht
den Zugriff auf beliebige Objekte in einer typisierten Abfragesprache. Mit der Deployment Tools
Foundation ist es nun mglich ein Installationspaket zu ffnen und mit Hilfe von LINQ die Inhalte der
Tabellen zu ermitteln und weiter zu verwenden, wie das auch im Listing 4.31 demonstriert wird.
private void ViewFiles(string fileName)
{
// Datenbank ffnen
using (QDatabase db = new QDatabase(fileName))
{
// Dateien der Tabelle File ermitteln, die grer als 1000 Byte sind.
var files = from a in db.Files
where a.FileSize > 1000
select a;
// Ausgabe
foreach (var a in files)
Console.WriteLine(a);
}
}
Listing 4.31: Zugriff auf die Inhalte eines Installationspaketes mit LINQ
Das vorliegende Beispiel ist einfach gehalten und soll lediglich die Mchtigkeit der Deployment Tools
Foundation andeuten. Im Verlauf dieses Kapitels werden noch weitere Beispiele folgen.
Installation und Bestandteile

Wie bereits erwhnt ist die Deployment Tools Foundation nun Bestandteil von Windows InstallerXML und wird auch damit installiert. Bei der Installation ist allerdings darauf zu achten, dass die
Funktionalitt WiX SDK ausgewhlt ist, wie das auch in Abbildung 4.25 dargestellt wird.
150
Kapitel 4
Abbildung 4.25: Auswahl der Deployment Tools Foundation bei der Installation von Windows Installer-XML
Nach der erfolgreichen Installation sind die relevanten Ressourcen standardmig im Ordner
%ProgramFiles%\Windows Installer XML v3\SDK zu finden. In dem Ordner befinden sich einige
Dateien, von denen die in Tabelle 4.36 aufgefhrten Assemblies fr den programmtechnischen Zugriff
am relevantesten sind.
Datei
Beschreibung
Microsoft.Deployment.Compression.dll
Funktionen zum Packen und Entpacken von Archiven.
Microsoft.Deployment.Compression.Cab.dll
Integriert die Verwaltung von CAB-Archiven.
Microsoft.Deployment.Compression.Zip.dll
Integriert die Verwaltung von ZIP-Archiven.
Microsoft.Deployment.Resources.dll
Verwalten von Ressourcen in ausfhrbaren

Anwendungen.
Microsoft.Deployment.WindowsInstaller.dll
Vollstndige Klassenbibliothek fr den Zugriff auf die

Windows Installer-Funktionen.
Microsoft.Deployment.WindowsInstaller.Linq.dll
LINQ-Erweiterung fr den Zugriff auf Windows

Installer-Datenbanken (Experimentell).
Microsoft.Deployment.WindowsInstaller.Package.dll
Erweiterte Klasse fr den Zugriff auf Installation- und

Patch-Pakete.
Tabelle 4.36: Wesentliche Bestandteile der Deployment Tools Foundation

Wie bereits in Tabelle 4.36 aufgefhrt, stellt die Deployment Tools Foundation einige
funktionsspezifische Assemblies zur Verfgung, die den zweckorientierten Zugriff auf bestimmte
Windows
Installer-Implementierungen
ermglichen.
Das
Assembly
151
Kapitel 4
Microsoft.Deployment.WindowsInstaller.dll nimmt die tragende Rolle ein, denn hierbei handelt es sich
vornehmlich um die Umsetzung der standardmigen Programmierschnittstelle des Windows Installers
in Form von verwaltetem Code. Das Hauptobjekt ist hierbei die Klasse Installer des Namensraums
Microsoft.Deployment.WindowsInstaller, die statische Funktionen vornehmlich zur Steuerung der
Installation bereitstellt. Die Methoden und Eigenschaften dieser Klasse sind in Abbildung 4.26
dargestellt.
Abbildung 4.26: Struktur der Klasse Microsoft.Deployment.WindowsInstaller.Installer
Die Installation eines Produktes kann durch die Verwendung der Funktion Installer.InstallProduct()
veranlasst werden. Dem Funktionsaufruf sind der Pfad zum Installationspaket und eine optionale
Befehlszeile zu bergeben. Schlgt die Installation fehl oder wird sie vom Benutzer abgebrochen, wird
eine entsprechende Ausnahme ausgelst, auf die individuell reagiert werden kann. Die Darstellung der
Benutzeroberflche kann durch die Funktion Installer.SetInternalUI() beeinflusst werden, genauso wie
152
Kapitel 4
die Erstellung eines Protokolls durch Installer.EnableLog() ermglicht wird. Letztlich sind die
Funktions- und Eigenschaftsbezeichnungen verstndlich gewhlt, so dass die Verwendung dieser
Klasse sehr einfach mglich ist.
Datenbank und Session

Eines der hufigsten Szenarien, in denen programmtechnische Zugriffe auf die Windows InstallerImplementierungen notwendig sind, betrifft die Betrachtung, die Analyse oder die Modifikation des
Installationspaketes. Die Klassenbibliothek Microsoft.Deployment.WindowsInstaller stellt fr diesen
Zweck mehrere Objekte zur Verfgung, mit denen auf die einzelnen Elemente des Installationspaketes
zugegriffen werden kann. Wie auch in Abbildung 4.27 dargestellt kann die Klasse SummaryInfo fr
den Zugriff auf den Summary Information Stream und die Klasse Database fr den Zugriff auf die
Windows Installer-Datenbank verwendet werden. Der Zugriff auf die Ressourcen ist hingegen nur
indirekt mglich. Die verwendeten Archive mssen zunchst extrahiert werden, knnen aber
anschlieend durch die Funktionen der Bibliotheken Microsoft.Deployment.Compression.dll und
Microsoft.Deployment.Compression.Cab.dll betrachtet und weiter bearbeitet werden.
153
Kapitel 4
Abbildung 4.27: Klassendiagramm fr den Zugriff auf die Inhalte eines Installationspaketes
Ich mchte die Verwendung einiger Objekte anhand eines Beispiels demonstrieren. Die
Aufgabenstellung ist im Prinzip recht einfach. Es sollen alle im Installationspaket enthaltenen
154
Kapitel 4
Kabinettdateien extrahiert und entpackt werden.

Im ersten Schritt muss zunchst geprft werden, ob die Ressourcen im komprimierten oder nicht
komprimierten Zustand vorliegen. Nur wenn sie im komprimierten Zustand vorliegen, sind auch die
entsprechenden Archive vorhanden, die extrahiert werden sollen. Zur Feststellung ist der Summary
Information Stream zu verwenden, denn die Eigenschaft PID_WORDCOUNT gibt hierber Auskunft.
private static bool IsCompressed(SummaryInfo summaryInfo)
{
// Eigenschaft PID_WORDCOUNT auswerten
//bool longfilenames = (!(0 < (summaryInfo.WordCount & 1)));
bool compressed = (0 < (summaryInfo.WordCount & 2));
//bool adminimage = (0 < (summaryInfo.WordCount & 4));
//bool uac = (0 < (summaryInfo.WordCount & 8));
return (compressed);
}
Listing 4.32: Analysieren der Eigenschaft PID_WORDCOUNT
Der in Listing 4.32 dargestellten Funktion IsCompressed() wird ein Objekt vom Typ SummaryInfo
bergeben. Wie in Abbildung 4.27 ersichtlich, kann dieses Objekt ber die gleichnamige Eigenschaft
des Objektes Database angesprochen werden. Die Eigenschaft PID_WORDCOUNT ist ein Bit-Feld,
durch das unterschiedliche Funktionalitten abgedeckt werden. Fr das Beispiel ist nur die Eigenschaft
compressed relevant, die von der Funktion auch zurckgegeben wird.
Die Hauptfunktion zum Extrahieren und entpacken der Archive ist in Listing 4.33 dargestellt. Im
ersten Schritt wird die Datenbank im schreibgeschtzten Modus geffnet und somit ein Objekt vom
Typ Database zurckgeliefert. Danach folgt dann der bereits erluterten Funktionsaufruf zum
Auswerten des Summary Information Streams, dem die Eigenschaft db.SummaryInfo bergeben wird.
internal static void Extract(string packageFileName, string outputFolder)
{
// Datenbank ffnen
using (Database db = new Database(packageFileName, DatabaseOpenMode.ReadOnly))
{
// Prfen ob komprimierten Ressourcen verwendet werden
if (IsCompressed(db.SummaryInfo))
{
// Prfen, ob die Tabelle Media vorhanden ist
if (db.IsTablePersistent("Media"))
{
// Alle Eintrge der Spalte Cabinet der Tabelle Media abrufen
IList<string> cabinetFiles = db.ExecuteStringQuery("SELECT DISTINCT `Cabinet` FROM `Media`");
// Alle Eintrge durchlaufen
foreach (string cabinett in cabinetFiles)
{
// Prfen ob ein Archiv angegeben wurde und ob es ein eingebettetes Archiv ist
if (!string.IsNullOrEmpty(cabinett) && cabinett.StartsWith("#"))
{
// Name des Archivs bestimmen
string cabinetName = cabinett.Substring(1);
// Archiv extrahieren und unter einem temporren Dateinamen speichern
155
Kapitel 4

string cabinetFileName = ExtractArchive(db, cabinetName);
// Archiv entpacken
CabInfo cabInfo = new CabInfo(cabinetFileName);
cabInfo.Unpack(outputFolder);
}
}
}
}
}
}
Listing 4.33: Hauptfunktion zum extrahieren und entpacken der Archive
Im Folgenden wird geprft, ob die Tabelle Media berhaupt vorhanden ist, bevor der Inhalt dieser
Tabelle abgefragt wird. Der Windows Installer stellt fr solche Flle eine Abfragesprache zur
Verfgung, die einen eingeschrnkten SQL-Funktionsvorrat (Structured Query Language) enthlt und
daher auch sinngem zu verwenden ist. Das Ergebnis dieser Abfrage ist eine Zeichenfolgen-Liste, in
der alle Inhalte der Spalte Cabinet abgelegt sind. Anschlieend wird bei jedem Eintrag geprft, ob
dieser mit dem Prfix # versehen ist. Dieses ist insofern relevant, da nur so gekennzeichnete Archive
physisch im Installationspaket enthalten sind und somit extrahiert werden knnen.
Wurde festgestellt, dass es sich um ein eingebettetes Archiv handelt, wird die Funktion
ExtractArchive() aufgerufen, die im Listing 4.34 nachfolgend aufgezeigt wird. Diese Funktion
extrahiert die jeweilige Kabinettdatei und speichert sie unter einem temporren Dateinamen ab. Der
Dateiname wird von der Funktion zurckgegeben, so dass er zum entpacken der enthaltenen
Ressourcen verwendet werden kann.
Das
Entpacken
der
Archive
erfolgt
unter
Verwendung
des
Objektes
Microsoft.Deployment.Compression.Cab.CabInfo, dem beim Erzeugen der Name des Archivs zu
bergeben ist. Schlielich ist nur noch die Methode CabInfo.Unpack() aufzurufen, um die Ressourcen
im Ausgabeordner abzulegen.
private static string ExtractArchive(Database db, string cabinetName)
{
// Dateiname konstruieren
string outputFileName = Path.GetTempFileName();
// Ansicht ffnen
using (View view = db.OpenView("SELECT `Name`, `Data` FROM `_Streams` WHERE `Name` = '{0}'",
cabinetName))
{
// Datensatz abrufen
view.Execute();
Record record = view.Fetch();
if (record == null)
throw new InstallerException();
// Stream extrahieren
record.GetStream("Data", outputFileName);
record.Close();
}
return (outputFileName);
}
156
Kapitel 4
Listing 4.34: Funktion zum extrahieren eines Archivs
Die Funktion ExtractArchive() wurde bereits zuvor im berblick erlutert. Es ist erkennbar, dass
zunchst ein temporrer Dateiname erzeugt wird, unter dem das extrahierte Archiv gespeichert werden
soll. Anschlieend wird ein Objekt vom Typ View erstellt, das letztlich das Ergebnis einer Abfrage
reprsentiert und auf das ber ein Objekt vom Typ Record zugegriffen werden kann. Somit wird das
Archiv durch die Funktion Record.GetStream() extrahiert. Beim ermitteln des Archivs ist noch zu
beachten, dass integrierte Kabinettdateien im Speicherbereich Streams abgelegt werden, auf den ber
die Systemtabelle _Streams zugegriffen werden kann.
Eine alternative Mglichkeit zur Erzielung eines hnlichen Ergebnisses liegt in der Verwendung der
Klasse Microsoft.Deployment.WindowsInstaller.Package.InstallPackage. Hierbei handelt es sich um
ein Objekt, mit dem die zu installierenden Dateien und Verzeichnisse eines Installationspaketes
verwaltet werden knnen. Zum Extrahieren der Dateien stellt dieses Objekt die Funktion ExtractFiles()
zur Verfgung, wie es auch in Listing 4.35 gezeigt wird. Allerdings kann bei Nutzung dieser
Funktionalitt der Ausgabeordner nicht direkt beeinflusst werden, denn er wird hierbei durch die
internen Strukturen des Paketes bestimmt. Zustzlich zu der gerade erluterten Klasse, enthlt das
Assembly Microsoft.Deployment.WindowsInstaller.Package.dll noch weitere interessante Objekte, mit
denen Informationen zu Patches und Transformationen abgerufen werden knnen, wie das auch im
Kapitel 10 dieses Buches noch vertieft wird.
internal static void ExtractPackage(string packageFileName)
{
// Paket ffnen
using (InstallPackage package = new InstallPackage(packageFileName, DatabaseOpenMode.ReadOnly))
{
// Dateien extrahieren
package.ExtractFiles();
}
}
Listing 4.35: Extrahieren der enthaltenen Dateien
Was in der bisherigen Betrachtung noch fehlt ist das Objekt vom Typ Session. Dieses Objekt stellt eine
aktive Installations-Session dar, und kann verwendet werden, um den Installationsprozess zu
kontrollieren. Die Erstellung erfolgt durch die Funktionen Installer.OpenPackage() und
Installer.OpenProduct(), die bei erfolgreichem Aufruf ein solches Objekt zurckliefern. Ein kurzes
Beispiel zeigt Listing 4.36.
internal static void CreateSession(string packageFileName, string targetDirectory)
{
// Session ffnen
using (Session session = Installer.OpenPackage(packageFileName, true))
{
// Aktionen ausfhren
session.DoAction("CostInitialize");
session.DoAction("FileCost");
session.DoAction("CostFinalize");
// Zielverzeichnis ndern und nderung im Protokoll vermerken
session.SetTargetPath("APPLICATIONFOLDER", targetDirectory);
session.Log("Zielverzeichnis gendert in: {0}", targetDirectory);
// Anforderungsstatus der Komponenten prfen und ausgeben
157
Kapitel 4
foreach (ComponentInfo info in session.Components)

{
Console.WriteLine(info.Name + ", " + info.RequestState.ToString());
}
}
}
Listing 4.36: Kontrolle des Installationsprozesses durch das Session-Objekt
In dem vorliegenden Beispiel wird der Installationsprozess gestartet und einige Standardaktionen
aufgerufen. Anschlieend wird das Zielverzeichnis verndert und diese nderung dem
Installationsprotokoll angefgt. Letztlich wird noch der Anforderungsstatus der Komponenten ermittelt
und mit dem Namen der Komponente ausgegeben. Anhand dieser wenigen Programmzeilen sollte die
Mchtigkeit des Session-Objektes deutlich geworden sein, denn die Steuerung des
Installationsprozesses beispielsweise durch einen individuell gestaltetet Debugger ist alles andere als
trivial. Die Relevanz des Objektes bleibt ebenfalls unbestritten, denn gerade bei der Verwendung von
benutzerdefinierten Aktionen kann hierauf nicht verzichtet werden, wie dieses auch an spterer Stelle
noch aufgezeigt wird.
Inventarisierung
Die bisherigen Funktionen bezogen sich im Wesentlichen auf das Installationspaket und die
enthaltenen Bauteile und Ressourcen. Die Deployment Tools Foundation stellt darber hinaus noch
eine Vielzahl von Funktionen zur Verfgung, die im Rahmen der Inventarisierung von Produkten und
Patches verwendet werden knnen. Es ist bekannt, dass whrend der Installationen eine groe Anzahl
von Konfigurationsinformationen, vornehmlich in der Systemregistrierung abgelegt werden. Diese
Informationen beziehen sich nicht nur auf die Eintragungen in der Windows Installer-Datenbank,
sondern auch auf die vom Windows Installer-Service bentigten Einstellungen. Durch diese
Einstellungen wird beispielsweise das vollstndige Deinstallieren der Anwendung oder die
automatische Reparatur einer defekten Installation ermglicht. Darber hinaus sind hier auch
Metainformationen zu finden, die Auskunft ber das installierte Produkt, den Installationszeitpunkt
und die Installationsquellen geben.
Obwohl die bentigten Informationen in der Systemregistrierung zu finden sind, auf die relativ einfach
zugegriffen werden kann, bleibt die Bereitstellung der Inventarisierungsfunktionalitt unbestritten.
Dieses ist darauf zurckzufhren, dass die erforderlichen Informationen an unterschiedlichen
Positionen der Systemregistrierung zu finden sind. So ist beispielsweise der Ablageort von Produkten
vom Installationskontext abhngig:
Per-User-Non-Managed: HKCU\Software\Microsoft\Installer\Products\
Per-User-Managed:
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Managed\<SID>\Products\
Per-Machine: HKLM\Software\Classes\Installer\Products\
Zustzlich kommen noch weitere Ablageorte ins Spiel, denn die gerade geschilderten Informationen
beziehen sich nur auf die Verffentlichung aber nicht auf die tatschlichen Eigenschaften eines
Produktes, die wiederum an anderen Positionen zu finden sind, wie dieses auch Abbildung 4.28 zeigt.
Dieses ist jedoch noch nicht alles, denn wie im Kapitel 3 bereits erlutert wurde, gibt es auf einem 64Bit-System noch eine Bit-Spezifische Unterteilung der Systemregistrierung, so dass diese Ablageorte
ebenfalls zu bercksichtigen sind.
158
Kapitel 4
Abbildung 4.28: Installationseigenschaften von Produkten
Besondere Beachtung mssen auch die vom Windows Installer bentigten Identifikationsmerkmale
erfahren, der zu diesem Zweck die folgenden Darstellungsformen einer GUID verwendet:
Standard-GUID: {012F8BAC-80EA-43fc-BA96-CB6FFBE952A1}
Gepackte GUID: CAB8F210AE08CF34AB69BCF6BF9E251A
Komprimierte GUID: 7HIH!$RBq9`O-xKW14q[
Die Problematik liegt nun darin begrndet, dass diese Darstellungsformen funktionsabhngig
verwendet werden. Hieraus folgt, dass bei einer manuellen Analyse entsprechende Querverknpfungen
bercksichtigt werden mssen, wobei die Darstellungsformen umzurechnen sind. Es sollte deutlich
geworden sein, dass eine detaillierte Inventarisierung des Systems unter Verwendung eines manuellen
Lsungsansatzes uerst komplex ist und potentielle Fehlerquellen birgt. Aus diesem Grund ist es
umso wichtiger, dass geeignete Funktionen zur Verfgung stehen, mit denen eine Analyse auf elegante
Art und Weise durchgefhrt werden kann. Die Deployment Tools Foundation stellt fr diese Zwecke
einige Klassen zur Verfgung, die objektspezifisch zu verwenden sind. Einige dieser Klassen mit den
enthaltene Eigenschaften, Methoden und Beziehungen werden in Abbildung 4.29 dargestellt.
159
Kapitel 4
Abbildung 4.29: Klassendiagramm zur Inventarisierung des Systems
Aus dem Klassendiagramm wird ersichtlich, dass drei unterschiedliche Objekttypen abgefragt werden
knnen. Die Klasse ProductInstallation dient hierbei zur Ermittlung der installierten Produkte und die
Klasse PatchInstallation ermittelt die installierten Patches, wie es auch spter in Kapitel 10 noch
dargestellt wird. Die Klasse ComponentInstallation dient zur Ermittlung der auf dem System
befindlichen Komponenten, wobei zustzliche Statusinformationen und auch die verwendeten Clients
mit ausgegeben werden. Ein Beispiel dazu zeigt Listing 4.37.
internal static void GetComponentInformation(string componentCode)
{
// Instanz des Objektes erstellen
ComponentInstallation component = new ComponentInstallation(componentCode);
if (component != null)
{
// Status und Pfad ausgeben
Console.WriteLine(component.State.ToString());
Console.WriteLine(component.Path);
// Alle Clients ermitteln und einige Daten ausgeben
160
Kapitel 4
foreach (ProductInstallation product in component.ClientProducts)

{
Console.WriteLine(product.ProductCode + ", " + product.ProductName);
}
}
}
Listing 4.37: Ermitteln des Komponenten-Status und der Clients die sie verwenden
Der Klassiker im Rahmen der Inventarisierung ist sicherlich die Ermittlung der installierten Produkte.
Dieses ist jedoch unter Verwendung der Klasse ProductInstallation der Deployment Tools Foundation
relativ unspektakulr und einfach durchfhrbar. Dennoch gibt es hierbei eine Vielzahl von Optionen,
die zustzliche Mglichkeiten bereitstellen. Die Eigenschaft SourceList enthlt eine Liste mit den
verwendeten Installationsquellen, die ber diese Eigenschaft auch nachtrglich verndert werden
knnen. Mit Hilfe der Methode GetRelatedProducts() knnen alle Produkte ermittelt werden, die ber
einen identischen Upgradecode verfgen und unter Verwendung der Eigenschaft ProductCode ist es
wiederum mglich auf andere Windows Installer-Funktionen zuzugreifen. Das folgende Beispiel soll
das Zusammenspiel ein wenig verdeutlichen. Es werden zunchst alle Produkte ermittelt, die am
heutigen Tag installiert wurden. Anschlieend werden sie wieder deinstalliert, indem die Funktion
Installer.ConfigureProduct() aufgerufen wird.
internal static void DeinstallProducts()
{
// Alle Produkte abrufen die heute installiert wurden
var products = from p in ProductInstallation.AllProducts
where p.InstallDate == DateTime.Today
select p;
// Die gefundenen Produkte deinstallieren
foreach (var product in products)
{
Console.WriteLine("Deinstallation von: " + product.ProductName);
// Produkt deinstallieren
Installer.ConfigureProduct(product.ProductCode, 0, InstallState.Absent, string.Empty);
}
}
Listing 4.38: Ermitteln und deinstallieren der Produkte die heute installiert wurden
Im vorangegangenen Listing wird deutlich, dass bei der Ermittlung der installierten Produkte auch
andere Technologien des Microsoft .NET Frameworks verwendet werden, um hierdurch eine
effiziente, moderne und bersichtliche Implementierung zu erhalten.
Wie bereits im ersten Kapitel dieses Buches verdeutlicht, knnen die Standardaktivitten des
Installationsprozesses mit Hilfe von benutzerdefinierten Aktionen um eigene Implementierungen
erweitert werden. Hierbei kann der individuelle Code in unterschiedlichen Formaten vorliegen, wobei
die Verwendung einer Objektbibliothek das Optimum darstellt. Der Hauptgrund erstreckt sich auf die
Fhigkeit des Zugriffs auf die Installations-Session und die Mglichkeit die internen Ablufe zu
verndern. Leider bietet der Windows Installer keinen nativen Support zur Verwendung von .NETPersnliche Ausfertigung fr Martin Martinsson
161
Kapitel 4
Klassen als benutzerdefinierte Aktionen, so dass an dieser Stelle in C++ erstellte Bibliotheken
erforderlich sind. Dieses ist ungemein schade, denn der riesige Funktionsvorrat des Microsoft .NET
Frameworks wrde somit verschlossen bleiben. Um die Funktionalitt dennoch nutzen zu knnen,
stellt das .NET-Framework die Klasse System.Configuration.Install.Installer zur Verfgung.
Allerdings sollte aus den folgenden Grnden von dieser Mglichkeit Abstand genommen werden:
Bei System.Configuration.Install.Installer handelt es sich um eine verwaltete Version der
klassischen SelfReg-Funktionalitt. Dieses begrndet sich darauf, dass die Logik zum Verwenden
der benutzerdefinierten Aktion in der Komponente zu finden ist und nicht im Windows Installer.
Somit ist die Verwendung dieser Basisklasse zu Entwicklungszwecken und im Testbetrieb
durchaus geeignet; ihre Verwendung im produktiven Einsatz hingegen als durchaus kritisch zu
betrachten.
Die Registrierung von Betriebssystemdiensten und COM-Komponenten wird von
System.Configuration.Install.Installer durch eine eigene Logik realisiert, obwohl der Windows
Installer fr solche Einsatzzwecke Standardimplementierungen zur Verfgung stellt.
Eine benutzerdefinierte Aktion sollte datengesteuert ausgefhrt werden, so dass die tatschliche
Implementierungslogik von den zu verwendenden Informationen getrennt wird. Eine solche
Vorgabe kann durch Tabellen realisiert werden, auf die durch benutzerdefinierte Aktionen
zugegriffen wird. Diese Vorgehensweise ermglicht eine effektive Wiederverwendung der
Programmlogik und lsst die gesamte Implementierung transparenter erscheinen. Eine solche
Mglichkeit ist mit System.Configuration.Install.Installer nicht realisierbar, da der Zugriff auf die
Installations-Session und somit auf die Tabellen hiermit nicht mglich ist.
Zur
Ausfhrung
einer
benutzerdefinierten
Aktion,
die
auf
Grundlage
von
System.Configuration.Install.Installer erstellt wurde, muss sich das Assembly bereits auf dem
lokalen System befinden. Aus diesem Grund kann eine solche Implementierung nicht zur
Erstellung von benutzerdefinierten Aktionen mit sofortiger Ausfhrung verwendet werden und zu
Problemen fhren, falls das Assembly versehentlich gelscht wurde.
Es ist dennoch mglich eine .NET-Klasse als Grundlage einer benutzerdefinierten Aktion zu
verwenden. Die hierzu erforderliche Umsetzung wird durch eine Technologie erreicht, die als Inverse
Platform Invocation Service bezeichnet wird und in meinem letzten Buch ausfhrlich beschrieben
wurde.
Interne Ablufe
Die Deployment Tools Foundation enthlt ebenfalls eine Implementierung zur Erstellung von
benutzerdefinierten Aktionen in einer modernen .NET-Sprache. Diese Implementierung ist eine
optimierte Weiterentwicklung des Inverse Platform Invocation Service mit vielen zustzlichen
Funktionalitten.
Die Erweiterungen beziehen sich primr auf die Verwendung eines Proxys. Das bedeutet, dass
automatisch eine C++ Bibliothek erzeugt wird, die letztlich die Schnittstelle zum Windows Installer
darstellt. Die tatschliche Implementierung, also die erstellte .NET-Klasse befindet sich als
eingebettete und komprimierte Ressource innerhalb dieses Proxys. Beim Ausfhren der
benutzerdefinierten Aktion wird der Proxy vom Windows Installer im temporren Verzeichnis
abgelegt und die spezifizierte Funktion aufgerufen. Der Proxy extrahiert zunchst die eingebetteten
Ressourcen und erstellt eine Instanz der .NET-Klasse, wobei die konfigurierte Version der zu
verwendenden Laufzeitumgebung bercksichtigt wird. Letztlich wird der Funktionsaufruf an die
162
Kapitel 4
.NET-Klasse weiter geleitet. Die .NET-Klasse bentigt die Objekte aus dem Assembly
Microsoft.Deployment.WindowsInstaller.dll um auf die Installations-Session zuzugreifen. Aus diesem
Grund werden dieses Assembly und alle weiteren Referenzen ebenfalls in den Proxy integriert, so dass
sie whrend der Installation ebenfalls zur Verfgung stehen.
Die Verwendung einer verwalteten benutzerdefinierten Aktion hat den groen Vorteil, dass whrend
der Installation bereits auf den mchtigen Funktionsvorrat des .NET Frameworks zugegriffen und
dieses verwendet werden kann. Bei der Installation ist somit darauf zu achten, dass das Framework
bereits vorhanden ist und dass die Installation bei fehlenden Voraussetzungen abgebrochen wird.
Hierbei ist natrlich auch besonderes Augenmerk auf die richtige Version des .NET Frameworks zu
legen. Jede verwaltete benutzerdefinierte Aktion sollte mit einer Konfigurationsdatei versehen werden,
in der die erforderliche Version des .NET Frameworks festgelegt wird. Es ist zwar auch mglich, einen
generischen Ansatz zu fahren, aber hiervon wird ausdrcklich abgeraten, da es zu
Kompatibilittsproblemen mit knftigen Framework-Versionen kommen knnte. Was fr die
Installation gilt, ist natrlich auch fr den Deinstallationsprozess mageblich. Wird eine solche
benutzerdefinierte Aktion whrend der Deinstallation ausgefhrt, schlgt sie fehl, falls das .NET
Framework nicht oder in keiner entsprechenden Version vorhanden ist. Das bedeutet, dass es zu
Problemen fhren kann, falls der Benutzer das .NET Framework vor dem eigentlichen Produkt
deinstalliert. Auch fr solche Flle sollte eine Prfung der Systemvoraussetzungen integriert werden.
Werden diese Faktoren beachtet, sollte der Verwendung einer verwalteten benutzerdefinierten Aktion
nichts im Wege stehen.
Erstellen einer benutzerdefinierten Aktion

Das Erstellen einer benutzerdefinierten Aktion in einer .NET-Sprache unterscheidet sich nur
unwesentlich von der Erstellung einer standardmigen Klassenbibliothek. Allerdings ist die
Erstellung wesentlich einfacher und kompakter als bei der Verwendung der Programmiersprache C++.
Die nachfolgenden Faktoren sind jedoch dabei zu beachten:
Die Funktion, die vom Windows Installer aufgerufen werden soll, ist in C# als public static und in
VB.NET als Public Shared zu deklarieren. Sie enthlt einen Parameter, der auf das Session-Objekt
verweist und gibt einen Wert des Enumerations-Typs ActionResult zurck.
Die Funktion ist mit dem Attribut CustomActionAttribute zu kennzeichnen, wodurch die
Verknpfung mit dem Proxy hergestellt wird. Das Attribut kann optional mit einem Namen
versehen werden. Wird der Name angegeben wird anstelle des Funktionsnamens diese
Bezeichnung als Einsprungpunkt verwendet. Das bedeutet, dass diese Bezeichnung in der Spalte
Target der Tabelle CustomAction zu verwenden ist.
Alle noch offenen Handles sollte geschlossen werden, bevor die Funktion beendet wird. Falls das
nicht erfolgt, wird eine entsprechende Warnung dem Installationsprotokoll angefgt. Die
Umsetzung ist relativ einfach, denn alle Klassen der Bibliothek die ein Handle erzeugen (Database,
View, Record und SummaryInfo), implementieren auch das Interface IDisposable. Somit knnen
diese Objekte sehr einfach in einem Using-Block verwendet damit automatisch geschlossen
werden.
Zur Verwendung der richtigen Version des .NET Frameworks ist diese in einer Konfigurationsdatei
zu spezifizieren. Die benutzerdefinierte Aktion wird unter Verwendung dieser Version ausgefhrt.
Wurde keine Version spezifiziert, wird das Framework verwendet, dessen Version am besten zu
der Microsoft.Deployment.WindowsInstaller.dll passt.
163
Kapitel 4
Die Eintrge der Tabelle CustomAction sind wie bei einer nativen Bibliothek, also bei einer
benutzerdefiniertes Aktion des Basistyps 1 zu definieren. Verwaltete benutzerdefinierte
Aktionen knnen auf identische Weise, also als Immediate-, Deferred-, Rollback- oder CommitCustom-Action, verwendet werden.
Wird innerhalb der benutzerdefinierten Aktion eine Ausnahme ausgelst, die intern nicht behandelt
wurde, wird diese durch die Proxy-Funktion abgefangen. Die Fehlermeldung und die
Stapelberwachung (Stack Trace) werden dem Installationsprotokoll angefgt und die Aktion wird
mit einem Fehlercode beendet.
Ich denke, dass die dargestellten Richtlinien und Vorgaben keine weitreichenden Folgen offenbaren
und auch relativ einfach umzusetzen sind. Ein kleines Beispiel soll dieses verdeutlichen. Es soll der
Installationspfad einer Anwendung durch eine benutzerdefinierte Aktion auf das Verzeichnis der
Common Language Runtime festgelegt werden. Hierbei ist zu bercksichtigen, dass das Verzeichnis
von der aktuell installierten Version des Microsoft .NET Frameworks und der verwendeten ProzessorArchitektur abhngig ist. Aus diesem Grund sollte eine spezielle Funktion im Microsoft .NET
Framework verwendet werden, die dieses Verzeichnis ermittelt. Im Weiteren soll diese Festlegung nur
erfolgen, wenn eine spezifische Eigenschaft im Installationspaket festgelegt wurde.
[CustomAction]
public static ActionResult SetTargetPath(Session session)
{
// Prfen ob der Pfad verndert werden soll
bool changePath = session["ChangePath"] == "1";
if (changePath)
{
// Neues Zielverzeichnis abrufen
string targetFolder = RuntimeEnvironment.GetRuntimeDirectory();
// Ausgabe ins Protokoll
session.Log("Change Property 'INSTALLLOCATION' to " + targetFolder);
// Zielverzeichnis setzen
session["INSTALLLOCATION"] = targetFolder;
// Funktion erfolgreich ausgefhrt
return ActionResult.Success;
}
else
{
// Funktion wurde nicht ausgefhrt
return ActionResult.NotExecuted;
}
}
Listing 4.39: Verndern des Installationsverzeichnisses durch eine benutzerdefinierte Aktion
Im nchsten Schritt ist die Konfigurationsdatei zu erstellen, in der die zu verwendende Version des
.NET Frameworks festzulegen ist. Die Struktur der Konfigurationsdatei entspricht dem
Standardschema fr solche Dateien, wie auch Listing 4.40 zeigt. Als Dateiname ist grundstzlich
CustomAction.config zu verwenden.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
164
Kapitel 4
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
Listing 4.40: Konfigurationsdatei zur Spezifizierung einer .NET Framework-Version
Zur Festlegung der Laufzeitumgebung ist dem Element supportedRuntime die entsprechende Version
zuzuordnen. Falls keine Version festgelegt wird, wird die Framework-Version verwendet, die am
besten zu der Variante passt, mit dem das Assembly Microsoft.Deployment.WindowsInstaller.dll
erzeugt wurde. Allerdings sollte hiervon Abstand genommen werden, denn dieses kann zu
Kompatibilittsproblemen mit zuknftigen Versionen des Frameworks fhren. Grundstzlich sollte
immer die Version festgelegt werden, mit der die benutzerdefinierte Aktion auch getestet wurde.
Nachdem alle Dateien erstellt wurden, kann die zu verwendende Objektbibliothek erzeugt werden.
Hierzu ist zunchst der klassische Kompiliervorgang durchzufhren, bei dem die Datei
Microsoft.Deployment.WindowsInstaller.dll ebenfalls zu referenzieren ist.
csc.exe
/target:library
/r:Microsoft.Deployment.WindowsInstaller.dll
/out:CAFilePath.dll
*.cs
Im nchsten Schritt ist der Proxy zu erstellen und die erforderlichen Dateien sind zu integrieren.
Hierbei
ist
zu
beachten,
dass
die
Dateien
CustomAction.config
und
Microsoft.Deployment.WindowsInstaller.dll nicht umbenannt werden, denn der Proxy bentigt die
Dateien mit exakt diesen Namen. Zum Erstellen des Proxys und zum integrieren der Dateien stellt die
Deployment Tools Foundation das Tool MakeSfxCA.exe zur Verfgung. Der Aufruf zum Erstellen des
Proxys gestaltet sich wie nachfolgend aufgefhrt.
MakeSfxCA.exe
ProxyPackage.dll
SfxCA.dll
CAFilePath.dll
CustomAction.config
Natrlich sind die Pfade noch entsprechend anzupassen. Das Tool MakeSfxCA.exe und die Datei
befinden
sich
standardmig
im
Ordner
%ProgramFiles%\Windows Installer XML v3\SDK. Bei der Datei SfxCA.dll handelt es sich um das
Grundgerst zum Erzeugen des Proxys. Diese Datei befindet sich in Abhngigkeit zur bentigten
Prozessorarchitektur im Unterordner x86 oder x64. Die Datei CAFilePath.dll wurde schlielich
im ersten Schritt erzeugt und bei ProxyPackage.dll handelt es sich um die Ausgabedatei, die alle
Dateien enthlt und letztlich in das Installationspaket integriert werden kann.
Tipp Beginn
Es ist mglich die Inhalte des Proxys zu betrachten. Hierzu kann die Proxy-Datei beispielsweise mit
winzip.exe geffnet werden.
165
Kapitel 4
Tipp Ende
Optimierung des Erstellungsvorgangs

Die zuvor erluterten Schritte zum Erzeugen einer verwalteten benutzerdefinierten Aktion sind nicht
sonderlich umfangreich und kompliziert, dennoch kann der Vorgang bei Verwendung von Visual
Studio weiter optimiert werden. Der Vorteil ist offensichtlich, denn zur Erstellung des Programmcodes
und auch des Installationspaketes kann zunchst eine moderne Entwicklungsumgebung verwendet
werden und auch die Referenzierung der erforderlichen Dateien funktioniert automatisch. Ein weiterer
Vorteil liegt in der Kompatibilitt mit der Microsoft Build Engine, so dass automatisierte Builds
ebenfalls mglich sind. Die Verwendung von Visual Studio zur Erzeugung von benutzerdefinierten
Aktionen ist denkbar einfach, denn nach der oben beschriebenen Installation, stehen die erforderlichen
Projektvorlagen zur Verfgung, wie es auch in Abbildung 4.30 gezeigt wird.
Abbildung 4.30: Projektvorlagen zur Erzeugung von benutzerdefinierten Aktionen
Es wird deutlich dass Projektvorlagen fr unterschiedliche Programmiersprachen zur Verfgung

stehen. Das C++ Projekt ist zu verwenden, falls eine native Objekt-Bibliothek erstellt werden soll, die
auf klassische Art und Weise zu verwenden ist. Das C# und das VB-Projekt sind hingegen
auszuwhlen, falls verwaltete benutzerdefinierten Aktionen nach dem zuvor erluterten Schema
erzeugt und verwendet werden sollen. Nachdem eine solche Projektvorlage ausgewhlt wurde, werden
automatisch eine Codedatei und eine Konfigurationsdatei erzeugt und die Codedatei wird im Editor
angezeigt.
Nach dem Erstellen der Programmlogik kann der Kompiliervorgang auf bekannte Weise durchgefhrt
werden. Das Ergebnis dieses Vorgangs ist letztlich der Proxy, der im Ausgabeverzeichnis abgelegt
wird. In diesen Proxy werden die Dateien CustomAction.config, SfxCA.dll und
Microsoft.Deployment.WindowsInstaller.dll, sowie das erzeugte .NET-Assembly integriert. Sind in
166
Kapitel 4
dem Projekt noch weitere Dateien vorhanden, werden diese ebenfalls in den Proxy integriert, wenn die
Eigenschaft Build Action der Datei auf Content festgelegt wurde. Zustzliche Abhngigkeiten
(References) werden ebenfalls in den Proxy integriert, sofern es sich um keine Assemblies des Global
Assembly Cache handelt. Das bedeutet, dass zur Integration dieser Abhngigkeiten die Eigenschaft
Copy Local auf True zu setzen ist, wie auch in Abbildung 4.31 aufgezeigt wird.
Abbildung 4.31: Integration einer zustzlichen Abhngigkeit in den Proxy
Das finale Ergebnis des Kompiliervorgangs ist letztlich der Proxy. Hierzu wird zunchst auf klassische
Weise das .NET-Assembly erzeugt und alle weiteren Schritte werden durch einen Postbuild-Schritt
realisiert. Die hierzu erforderlichen Regeln und Bedingungen sind in der Datei
%ProgramFiles%\MSBuild\Microsoft\WiX\v3.0\wix.ca.targets beschrieben. Beim Erzeugen des
Projektes wird eine zustzliche DLL-Datei im Ausgabeverzeichnis abgelegt, die letztlich den Proxy
darstellt. Die Namensgebung orientiert sich an dem Namen des Assemblies, der jedoch nach dem
Schema $(TargetName).CA.dll angepasst wurde. Das bedeutet, dass fr ein Assembly mit der
Bezeichnung CAFilePath.dll ein Proxy mit der Bezeichnung CAFilePath.CA.dll erzeugt und im
Ausgabeverzeichnis abgelegt wird.
Ein weiterer Pluspunkt der sich bei der Nutzung von Visual Studio zur Erzeugung der
benutzerdefinierten Aktionen ergibt, ist das direkte Zusammenspiel mit Windows Installer-XML.
Nachdem die Objektbibliothek erzeugt wurde, muss diese natrlich noch in das Installationspaket
integriert werden, so dass sie auch im Installationsprozess aufgerufen werden kann. Die
Vorgehensweise hierzu ist denkbar einfach. Zunchst ist eine Projektmappe zu erzeugen der ein WIXProjekt und ein Custom Action-Projekt hinzugefgt wird. Alternativ kann natrlich auch ein WIX
Library-Projekt verwendet werden. Dem WIX-Projekt ist anschlieend eine Referenz auf das Custom
Action-Projekt hinzuzufgen. Hierdurch wurden alle Voraussetzungen geschaffen, um die
benutzerdefinierte Aktion in dem WXS-Dokument referenzieren zu knnen, wie das auch in Listing
4.41 gezeigt wird.

<Binary Id="CADLL" SourceFile="$(var.CAFilePath.TargetDir)$(var.CAFilePath.TargetName).CA.dll"/>
167
Kapitel 4

<CustomAction Id="SetTargetPath" BinaryKey="CADLL" DllEntry="SetTargetPath"
Execute="firstSequence"/>


<InstallUISequence>
<Custom Action="SetTargetPath" Before="CostFinalize"/>
</InstallUISequence>

<Custom Action="SetTargetPath" Before="CostFinalize"/>
Listing 4.41: Definition einer benutzerdefinierten Aktion in einem WXS-Dokument
Der an dieser Stelle relevanteste Punkt, betrifft die Integration des Proxys in den Binr-Stream. Die
Referenzierung erfolgt hierbei nicht ber absolute Pfadangaben sondern variabel unter Verwendung
von Projektreferenzen, wie dieses auch bereits in Kapitel 2 erlutert wurde. In Kapitel 6 wird die
Verwendung der gerade vorgestellten Funktionalitt anhand eines komplexen Beispiels zur Nutzung
des Neustart-Managers weiter vertieft.
Debuggen
Im Falle der fehlerhaften Ausfhrung von benutzerdefinierten Aktionen besteht vielfach die
Notwendigkeit, die Ausfhrung des Codes in einem Debugger zu betrachten. Die Vorgehensweise zur
Realisierung eines solchen Szenarios ist von dem Format abhngig, in dem die benutzerdefinierte
Aktion vorliegt. Der Windows Installer verwendet die Umgebungsvariable MsiBreak, um festzustellen,
ob eine benutzerdefinierte Aktion vom Typ Objektbibliothek im Debugger ausgefhrt werden soll.
Zur Verwendung dieser Umgebungsvariablen ist ihr der Name der jeweiligen benutzerdefinierten
Aktion zuzuweisen. Seit dem Windows Installer 2.0 kann MsiBreak als Benutzerumgebungsvariable
festgelegt werden, wodurch ein Neustart des Computers nicht erforderlich wird. Seit dieser Version
des Windows Installers wird die Umgebungsvariable ausschlielich geprft, wenn der Benutzer zur
Gruppe der Administratoren gehrt.
Zum Debuggen einer Objektbibliothek weisen Sie zunchst der Umgebungsvariablen MsiBreak den
Namen der jeweiligen benutzerdefinierten Aktion zu und starten Sie dann den Installationsprozess.
Beim Aufruf der benutzerdefinierten Aktion durch den Windows Installer erscheint eine Dialogbox in
der die ID des entsprechenden Prozesses angegeben ist. Verbinden Sie den Debugger mit diesem
Prozess, ffnen Sie die jeweiligen Programmquellen, setzen Sie die Haltepunkte und prfen Sie, ob die
Symboldateien der benutzerdefinierten Aktion geladen sind. Nach dem Schlieen der Dialogbox wird
die Ausfhrung der benutzerdefinierten Aktion am ersten Haltepunkt unterbrochen. Nun knnen Sie
schrittweise durch den Programmcode navigieren und die Problemquellen analysieren. Die
Verwendung der Umgebungsvariablen MsiBreak stellt einen einfachen Lsungsansatz dar, eine
benutzerdefinierte Aktion in einem Debugger zu analysieren. Falls Sie Zugriff auf den Quellcode der
benutzerdefinierten Aktion haben, knnen Sie die Aktion auch im Debugger ausfhren ohne die
Umgebungsvariable zu verwenden. Fgen Sie hierzu eine temporre Dialogbox an den Beginn des
Quellcodes. Nach dem Erscheinen dieses Dialoges im Installationsprozess verbinden Sie den Debugger
mit diesem Prozess.
Auch wenn es sich bei einer verwalteten benutzerdefinierten Aktion um eine Objektbibliothek handelt,
muss zum Debuggen eine leicht abgewandelte Vorgehensweise gewhlt werden. Das hat damit zu tun,
168
Kapitel 4
dass der zuvor beschriebene Dialog angezeigt wird, wenn die entsprechende Funktion des Proxys
aufgerufen wird. Um jedoch eine Mglichkeit zu erhalten, die Funktion innerhalb des .NET Assembly
zu debuggen, ist es erforderlich die Umgebungsvariable MMsiBreak anstelle von MsiBreak zu
verwenden. Setzen Sie diese auf den Namen des Einsprungpunktes der Funktion, die im Debugger
ausgefhrt werden soll. Standardmig entspricht der Name des Einsprungpunktes der
Funktionsbezeichnung, allerdings kann dieses durch das Attribut CustomActionAttribute verndert
werden. Falls also durch das CustomActionAttribute ein anderer Name vergeben wurde, ist dieser der
Umgebungsvariablen zuzuweisen. Im Installationsprozess prft der Proxy diese Vorgaben und falls er
eine Entsprechung findet, wird der Just-In-Time Debugger aufgerufen, wie dieses auch in Abbildung
4.32 demonstriert wird.
Abbildung 4.32: Debuggen einer verwalteten benutzerdefinierten Aktion
Die Ausfhrung wird angehalten nachdem das Assembly geladen aber bevor die Funktion aufgerufen
wurde. Nachdem der Debugger angefgt wurde, ist zunchst zu prfen ob die Symbole geladen
wurden. Anschlieend knnen Haltepunkte gesetzt werden und der Code im Debugger ausgefhrt
werden.
Hinweis Beginn
Der Umgebungsvariablen MMsiBreak knnen mehrere Einsprungpunkte zugeordnete werden, die

hierzu durch ein Komma voneinander getrennt werden mssen
Hinweis Ende
Erweiterte Implementierungen
Eine benutzerdefinierte Aktion mit verzgerter Ausfhrung wird innerhalb der Installationstransaktion
verwendet, um Modifikationen am System vorzunehmen. Eine solche Aktion kann jedoch nicht auf die
Elemente der aktuellen Installations-Session zugreifen. Ihr stehen nur Informationen des
Installationsskriptes zur Verfgung, so dass hier noch zustzliche Faktoren bercksichtigt werden
mssen.
169
Kapitel 4
Wie in Kapitel 1 bereits erlutert, mssen die Informationen, die von der Implementierung bentigt
werden, durch eine Eigenschaftszuweisung dem Installationsskript angefgt werden, wobei als
Eigenschaftsname der Name der benutzerdefinierten Aktion zu verwenden ist. Zum besseren
Verstndnis mchte ich das Beispiel zum Hinzufgen eines Benutzerkontos aus Kapitel 1 nochmal
aufgreifen. Die benutzerdefinierte Aktion mit der Bezeichnung CreateUser veranlassen hierbei die
Erstellung des Benutzerkontos. Da diese jedoch innerhalb der Installationstransaktion ausgefhrt
werden soll, mssen die zu bercksichtigenden Informationen ebenfalls in das Installationsskript
bertragen werden. Hierzu kann eine weitere benutzerdefinierte Aktion verwendet werden. Die
Deklarationen werden natrlich in der Tabelle CustomAction vorgenommen, die somit die folgenden
Inhalte aufweist:
Action
Type
Source
Target
ExtendedType
CreateUser.SetProperty
51
CreateUser
Name=[ACCOUNTNAME];
Description=[ACCOUNTDESCRIPTION];
Password=[ACCOUNTPASSWORD]
CreateUser
3073
CADLL
AddAccount
Tabelle 4.37: Deklaration der Aktionen in der Tabelle CustomAction
Die benutzerdefinierte Aktion CreateUser ist fr das Hinzufgen des Benutzerkontos zustndig.
Hierdurch wird die Funktion AddAccount() aufgerufen, die sich in einer Objektbibliothek befindet, die
unter der Bezeichnung CADLL im Binr-Stream des Installationspaketes abgelegt wurde. Weiterhin
ist die Aktion als Typ 3073 (msidbCustomActionTypeDll + msidbCustomActionTypeBinaryData+
msidbCustomActionTypeInScript + nmsidbCustomActionTypeNoImpersonate) definiert, wodurch sie
whrend der Skriptausfhrung im Systemkontext verwendet wird. Die Aktion bentigt zwangslufig
Informationen zu dem anzulegenden Benutzerkonto. Da eine benutzerdefinierte Aktion mit verzgerter
Ausfhrung nicht auf die Informationen der Installations-Session zugreifen kann, mssen die
erforderlichen Daten dem Installationsskript angefgt werden. Dieses wird durch die
benutzerdefinierte Aktion CreateUser.SetProperty realisiert. Es ist zu erkennen dass im Feld Source
eine Referenz auf die Aktion CreateUser zu erkennen ist und dass im Feld Target die zu erforderlichen
Daten angegeben werden. Es besteht jedoch nur die Mglichkeit eine Zeichenfolge zu bergeben,
wodurch ein Algorithmus angewendet werden muss, mehrere Informationen zusammenzufassen.
Dieser Algorithmus ist individuell gestaltbar, da in der benutzerdefinierten Aktion eine Funktionalitt
enthalten sein muss, diese Zeichenfolge wieder in ihre Bestandteile zu berfhren.
Die Deployment Tools Foundation stellt bereits einen entsprechenden Parser zur Verfgung, der die
einzelnen Elemente der Zeichenfolge in eine Auflistung bertrgt, auf die ber den Namen zugegriffen
werden kann. Zur Verwendung dieses Parsers mssen die Informationen als Wertepaare bergeben
werden, wobei mehrere solcher Paare durch Semikolon voneinander getrennt werden mssen.
Name=Wert;[Name=Wert];[]
Nachdem die Aktionen in der Tabelle CustomAction definiert wurden, mssen sie noch aus der
Installationstransaktion aufgerufen werden. Hierzu ist es erforderlich sie der Tabelle
InstallExecuteSequence anzufgen, wobei sie sich zwischen den Aktionen InstallInitialize und
InstallFinalize befinden mssen.
Action
InstallInitialize
170
Condition
Sequence
1500
Kapitel 4
CreateUser.SetProperty
$C__Main.exe>2
4001
CreateUser
$C__Main.exe>2
4002
InstallFinalize
6600
Tabelle 4.38: Darstellung der Informationen in der Tabelle InstallExecuteSequence
Die Ausfhrung der Aktionen wurde von einer Bedingung abhngig gemacht, so dass das
Benutzerkonto nur erzeugt wird, wenn eine bestimmte Komponente installiert wird. Zu erkennen ist
weiterhin, dass die Eigenschaftszuweisung vor der eigentlichen benutzerdefinierten Aktion erfolgt.
Hierdurch werden die erforderlichen Argumente einer aktionsspezifischen Eigenschaft mit der
Bezeichnung CustomActionData zugewiesen, wie auch der nachfolgende Auszug des
Installationsprotokolls zeigt.
MSI (s) (0C:94) [15:24:06:732]: Doing action: CreateUser.SetProperty
MSI (s) (0C:94) [15:24:06:732]: PROPERTY CHANGE: Adding CreateUser property.
Its value is 'Name=MSI;Description=Windows Installer-Testaccount;Password=ABCDE*1'.
MSI (s) (0C:94) [15:24:06:763]: Executing op: ActionStart(Name=CreateUser,,)

MSI (s) (0C:94) [15:24:06:763]: Executing op: CustomActionSchedule(Action=CreateUser,ActionType=3073,
Source=BinaryData,Target=AddAccount,CustomActionData=Name=MSI;
Description=Windows Installer-Testaccount;Password=ABCDE*1)
MSI (s) (0C:04) [15:24:06:779]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI3630.tmp,
Entrypoint: AddAccount
MSI
MSI
MSI
MSI
(s)
(s)
(s)
(s)
(0C:A0)
(0C:A0)
(0C:54)
(0C:54)
[15:24:06:779]:
[15:24:06:779]:
[15:24:06:810]:
[15:24:06:810]:
Generating random cookie.

Created Custom Action Server with PID 3360 (0xD20).
Running as a service.
Hello, I'm your 32bit Impersonated custom action server.
Bei der Betrachtung des Protokollauszugs ist auffallend, dass alle Informationen im Klartext
dargestellt werden, so dass hierdurch das Passwort offen gelegt wird. Um dieses zu vermeiden, sollten
benutzerdefinierte Aktionen, die sicherheitsrelevante Daten bentigen, mit dem Attribut
msidbCustomActionTypeHideTarget gekennzeichnet werden. Zur Realisierung ist in der Tabelle
CustomAction der Wert der Spalte Type fr die benutzerdefinierten Aktion CreateUser von 3073 auf
11265 zu ndern. Nach erfolgter nderung werden die Argumente im Installationsprotokoll durch
Platzhalter ersetzt.
MSI (s) (0C:78) [15:31:25:332]: Executing op: CustomActionSchedule(Action=CreateUser,ActionType=11265,
Source=BinaryData,Target=**********,CustomActionData=**********)
Eine benutzerdefinierte Aktion mit verzgerter Ausfhrung kann nur bestimmte Funktionen des
Windows Installer-API verwenden, da nur ein Zugriff auf das Installationsskript, jedoch nicht auf alle
Informationen der Installations-Session mglich ist. Die Eigenschaft CustomActionData steht hierbei
selbstverstndlich zur Verfgung, da hiermit die erforderlichen Informationen transportiert werden.
Der Zugriff auf die bertragenen Daten innerhalb der programmtechnischen Implementierung ist unter
Verwendung der Deployment Tools Foundation relativ einfach, wenn die Zuweisung der Wertepaare
nach dem obigen Schema erfolgt. Auf diese Informationen kann anschlieend ber das Objekt
Session.CustomActionData zugegriffen werden.
Die bisherigen Ausfhrungen bezogen sich ausnahmslos auf das Hinzufgen eines Benutzerkontos. In
einem Installationspaket fr den produktiven Einsatz wrden sich natrlich auch Implementierungen
zum Entfernen eines solchen Kontos finden. Die im Listing 4.42 dargestellte Implementierung zeigt
171
Kapitel 4
die benutzerdefinierten Aktionen zum Durchfhren dieser Systemvernderungen.

public class CustomActions
{
// Benutzerkonto erstellen
[CustomAction]
public static ActionResult AddAccount(Session session)
{
return (ManageAccounts(session, AccountActionMode.Add ));
}
// Benutzerkonto entfernen
[CustomAction]
public static ActionResult RemoveAccount(Session session)
{
return (ManageAccounts(session, AccountActionMode.Remove));
}
// Benutzerkonto verwalten
private static ActionResult ManageAccounts(Session session, AccountActionMode actionMode)
{
// Prfen auf verzgerte Ausfhrung oder Ausfhrung whrend des Rollback
if (!session.GetMode(InstallRunMode.Scheduled) && !session.GetMode(InstallRunMode.Rollback))
{
// Meldung ins Protokoll schreiben
session.Log(INAVLID_MODE_TEXT);
return (ActionResult.Failure);
}
try
{
if (actionMode == AccountActionMode.Add)
{
AccountHelper.CreateAccount(
session.CustomActionData["Name"],
session.CustomActionData["Description"],
session.CustomActionData["Password"]);
}
else if (actionMode == AccountActionMode.Remove)
{
AccountHelper.RemoveAccount(
session.CustomActionData["Name"]);
}
}
catch (Exception ex)
{
session.Log(ex.Message);
return (ActionResult.Failure);
}
// Rckgabe
}
}
Listing 4.42: Verwalten von Benutzerkonten durch benutzerdefinierte Aktionen
172
Kapitel 4
Die Funktionen AddAccount() und RemoveAccount() stellen hierbei die Einsprungpunkte der
benutzerdefinierten Aktion dar. Die eigentliche Verarbeitung findet in der Funktion ManageAccounts()
statt, die von den zuvor genannten Funktionen aufgerufen wird. Zu Beginn wird durch
Session.GetMode() geprft, ob die Aktion verzgert oder whrend des Rollbacks ausgefhrt wird. Ist
dies nicht der Fall, wird die Installation an dieser Stelle abgebrochen und eine entsprechende
Information dem Installationsprotokoll angefgt. Im Anschluss werden Funktionen einer Hilfsklasse
aufgerufen, mit denen das Benutzerkonto letztlich erstellt oder entfernt wird. Diesen Funktionsaufrufen
werden Informationen zu dem Benutzerkonto bergeben, die ber die Eigenschaft CustomActionData
an die Implementierung bertragen wurden. Hierbei wird deutlich, dass sich diese Informationen in
einer Auflistung befinden, auf die ber den Namen des Eintrags zugegriffen werden kann. Was an
dieser Stelle natrlich noch fehlt ist die Gestaltung des Installationspaketes und die Definition der
benutzerdefinierten Aktionen.

<Property Id="ACCOUNTPASSWORD" Value="ABCDE*1" Secure="yes" Hidden="yes"/>
<Property Id="ACCOUNTNAME" Value="MSI" Secure="yes"/>
<Property Id="ACCOUNTDESCRIPTION" Value="Windows Installer-Testaccount" Secure="yes"/>

<Binary Id="CADLL" SourceFile="$(var.ManageUsers.TargetDir)$(var.ManageUsers.TargetName).CA.dll"/>

<CustomAction Id="DeleteUser.SetProperty" Property="DeleteUser" Value="Name=[ACCOUNTNAME]" />
<CustomAction Id="DeleteUser" BinaryKey="CADLL" DllEntry="RemoveAccount" Execute="deferred"
Impersonate="no" />
<CustomAction Id="CreateUser.SetProperty" Property="CreateUser"
Value="Name=[ACCOUNTNAME];Description=[ACCOUNTDESCRIPTION];Password=[ACCOUNTPASSWORD]" />
<CustomAction Id="CreateUser" BinaryKey="CADLL" DllEntry="AddAccount" Execute="deferred" HideTarget="yes"
Impersonate="no" />
<CustomAction Id="RollbackUser.SetProperty" Property="RollbackUser" Value="Name=[ACCOUNTNAME]" />
<CustomAction Id="RollbackUser" BinaryKey="CADLL" DllEntry="RemoveAccount" Execute="rollback"
Impersonate="no" />

<Custom Action="DeleteUser" Before="RemoveFiles" >$C__Main.exe=2</Custom>
<Custom Action="DeleteUser.SetProperty" Before="DeleteUser" >$C__Main.exe=2</Custom>
<Custom Action="RollbackUser.SetProperty" After="InstallFiles">$C__Main.exe>2</Custom>
<Custom Action="RollbackUser" After="RollbackUser.SetProperty">$C__Main.exe>2</Custom>
<Custom Action="CreateUser.SetProperty" After="RollbackUser">$C__Main.exe>2</Custom>
<Custom Action="CreateUser" After="CreateUser.SetProperty">$C__Main.exe>2</Custom>
Listing 4.43: Verwendung der benutzerdefinierten Aktionen
In dem vorliegenden Listing fllt das paarweise Auftreten der benutzerdefinierten Aktionen besonders
auf. Fr jede verzgert ausgefhrte Aktion existiert eine weitere benutzerdefinierte Aktion, die
relevante Daten dem Installationsskript anfgt. Die Wertepaare entsprechen hierbei der Namensgebung
innerhalb der Implementierung, so dass die bentigten Informationen auch verwendet werden knnen.
Im Weiteren ist in dem Listing die Implementierung fr den Rollback zu erkennen. Hierbei wird
ebenfalls die Funktion zum Entfernen des Benutzerkontos aufgerufen, denn fr die Implementierung
ist es unerheblich, ob dieses whrend der Deinstallation oder whrend des Rollbacks geschieht. Der
173
Kapitel 4
Unterschied liegt lediglich in der Definition der benutzerdefinierten Aktion. Hierdurch wird sie dem
Rollback-Skript angefgt und wird im Fehlerfall ausgefhrt, so dass die Konsistenz des Systems
gewhrleistet werden kann.
Fazit
Durch die Bereitstellung der Deployment Tools Foundation wird der programmtechnische Zugriff auf
die Windows Installer-Funktionalitt nun auch fr .NET-Anwendungen auf elegante Weise ermglicht.
Die Funktionalitten und Implementierungen sind uerst mchtig, so dass nahezu alle Anforderungen
hiermit umgesetzt werden knnen. Die Nutzung der Deployment Tools Foundation ist auch innerhalb
des Installationsprozesses mglich, denn hierdurch wird eine Mglichkeit geschaffen,
benutzerdefinierte Aktionen in einer .NET-Sprache zu erstellen und zu verwenden. Die Deployment
Tools Foundation ist Bestandteil der Toolsammlung Windows Installer-XML und ist daher ebenfalls
frei verfgbar. Die Nutzung im kommerziellen Umfeld ist ebenfalls gestattet, so dass der Nutzung
kaum Grenzen gesetzt werden.
174
Teil B
Installationen
unter Windows
Vista und
Windows Server
2008
175
Kapitel 5
Benutzerkontensteuerung in Windows Vista und Windows Server 2008
Benutzerkontensteuerung in Windows
Vista und Windows Server 2008

Sicherheit
Anwendungen fr Windows Vista und Windows Server 2008
Installationen unter Windows Vista und Windows Server 2008
Fazit
176
178
188
201
208
224
238
241
Dem Installationsprozess wird unter Windows Vista eine sehr hohe Bedeutung beigemessen, denn
durch fehlerhafte Implementierungen kann die Stabilitt des Betriebssystems und anderer
Anwendungen stark beeintrchtigt werden. Aus diesem Grund sehen die Zertifizierungsrichtlinien zur
Erlangung des Logos Certified for Windows Vista nur Click-Once und den Windows Installer als
mgliche Technologien fr die Anwendungsinstallation vor. Click-Once ist eine Technologie, die auf
dem Microsoft .NET Framework 2.0 basiert und die Vorteile einer webbasierten Verteilung auch fr
Windows Anwendungen mglich macht. Allerdings eignet sich Click-Once nicht fr jede Art von
Anwendung, da durch die isolierte Ausfhrung, der Zugriff auf Systemressourcen stark eingeschrnkt
ist.

Windows Vista und Windows Server 2008 enthalten die Version 4.0 des Windows Installers. Diese
Version ist speziell auf die neuen Funktionalitten in Windows Vista und Windows Server 2008
angepasst und kommt ausschlielich mit diesen Betriebssystemen zum Einsatz. Ein
Redistributionspaket fr die Betriebssysteme Windows XP und Windows Server 2003 existiert nicht.
Der Windows Installer 4.0 ist in unterschiedlichen Versionen verfgbar, wie dieses auch in Tabelle
5.39 dargestellt wird.
Release
Version
Anmerkungen
4.0.6000.16386
Enthalten in Windows Vista.
4.0.6001.18000
Enthalten in Windows Server 2008 und Windows Vista SP1.
Tabelle 5.39: Verfgbare Versionen des Windows Installers 4.0
176
Wie jede Version des Windows Installers wurde auch der Windows Installer 4.0 um neue
Funktionalitten ergnzt und bestehende Funktionalitten wurden verndert. Die folgende Auflistung
zeigt diese neu hinzugefgten und genderten Funktionalitten gegenber der Windows Installer
Version 4.0.
Neue Funktionen
MsiGetPatchFileList()
Neue Eigenschaften
MSIARPSETTINGSIDENTIFIER
MsiLogging
MsiLogFileLocation
MsiSystemRebootPending
MsiRunningElevated
MSIRESTARTMANAGERCONTROL
MsiRestartManagerSessionKey
MSIDISABLERMRESTART
MSIRMSHUTDOWN
MSIUSEREALADMINDETECTION
Eigenschaften des Summary Information Streams
Die Eigenschaft Word Count (PID_WORDCOUNT) wurde um ein zustzliches Attribut erweitert,
durch das UAC-Konforme Installationspakete definiert werden knnen.
Genderte Datenbanktabellen
In der Spalte Attributes der Tabelle Component kann nun das Attribut
msidbComponentAttributesDisableRegistryReflection verwendet werden, um die Spiegelung der
Systemregistrierung bei 64-Bit-Betriebssystemen zu verhindern.
Die Tabelle Shortcut wurde um die Spalten DisplayResourceDLL, DisplayResourceId,
DescriptionResourceDLL und DescriptionResourceId erweitert.
Neuer Dialog
MsiRMFilesInUse
Neue Steuerelement-Attribute
ElevationShield
Neue Steuerelement-Ereignisse
RmShutdownAndRestart
Neue Fenster-Meldung
INSTALLLOGMODE_RMFILESINUSE
Neue Systemrichtlinien
DisableLoggingFromPackage
DisableAutomaticApplicationShutdown
Neue Methoden des Automations-Objektes
177
Kapitel 5
Installer.AdvertiseProduct()
Installer.AdvertiseScript()
Installer.CreateAdvertiseScript()
Installer.ProvideAssembly()
Neue Eigenschaften des Automations-Objektes
Installer.PatchFiles
Installer.ProductElevated
Installer.ProductInfoFromScript
Der Windows Installer 4.0 adressiert schwerpunktmig die Themen Sicherheit, Verfgbarkeit
und Komfort. Dem Thema Sicherheit sind hierbei Technologien wie die Benutzerkontensteuerung
und der Windows-Ressourcenschutz zugeordnet. Die Funktionalitt des Neustart-Managers fllt
hingegen in die Kategorie Verfgbarkeit und die Themen Protokollierung und Mehrsprachigkeit
sind eindeutig dem Komfort anzurechnen.
Die Funktionalitt des Windows Installers 4.0 wird in den folgenden drei Kapiteln erlutert. In diesem
Kapitel geht es zunchst allgemein um Sicherheit und darauf aufbauend um die
Benutzerkontensteuerung. Das zweite Kapitel dieses Teils befasst sich dann mit den
Computerneustarts und der neuen Technologie des Neustart-Managers. Im dritten und letzten Kapitel
dieses Teils sind mehrere Themen zusammengefasst. So finden sich dort Erluterungen zum WindowsRessourcenschutz, zur Protokollierung und zu mehrsprachigen Benutzeroberflchen.
Sicherheit
Sicherheit nimmt bei den aktuellen Betriebssystemen einen immer hheren Stellenwert ein. Sicherheit
bedeutet Stabilitt und Stabilitt bedeutet Effizienz. Effizienz fhrt schlielich zur Kostenminimierung
und somit auf Unternehmensseite zu einem positiven Betriebsergebnis. Sicherheit lsst sich nicht nur
mit harter Whrung auf Unternehmenserfolge und Misserfolge abbilden; Sicherheit betrifft alle
Computernutzer, denn nur abgesicherte Betriebssysteme erreichen deutlich geringere Ausfallzeiten und
frdern gleichermaen den Spa bei der Arbeit am Computer.
Bereits bei Windows 2000 wurden sehr viele sicherheitsrelevante Implementierungen im
Betriebssystem vorgenommen, wodurch dem Ziel der Schaffung einer stabilen Umgebung sehr nahe
gekommen wurde. Um dieses zu erreichen enthlt Windows 2000 Funktionalitten und Technologien
zur Einschrnkung der Zugriffsrechte einer Anwendung durch die Verwendung eingeschrnkter Token
(Restricted Token). Windows XP und Windows Server 2003 enthalten weitere Verbesserungen und
Optimierungen auf dieser Grundlage und versprechen somit einen noch hheren Sicherheitsfaktor.
Doch was ntzen die besten Schlsser und Alarmanlagen, wenn die Haustr nicht verschlossen wird was ntzen die besten Funktionalitten und Implementierungen, wenn diese nicht genutzt werden und
somit die heroischen Ziele der Schaffung eines sicheren Betriebssystems zum Scheitern verurteilt
werden.
Der grte Problemfaktor oder besser gesagt das hchste Sicherheitsrisiko ist der Administrator. Er hat
uneingeschrnkten Zugriff auf das System, kann nahezu jede Aktion ausfhren und kritisch betrachtet
natrlich auch die meisten Schden anrichten. Jede Anwendung die von einem Administrator gestartet
wird verwendet die gleichen Privilegien und ist hinsichtlich der Zugriffsmglichkeiten nicht oder nur
178
minimal eingeschrnkt. Das hieraus resultierende Gefahrenpotential ist besonders hoch, denn
bsartiger Software sind hierdurch Tor und Tr geffnet, da sie auf nahezu alle Bereiche des
Betriebssystems schreibend zugreifen kann. Eine einfache Lsungsmglichkeit zur Vermeidung
solcher und hnlich gelagerter Problemfaktoren ist der Verzicht auf administrative Privilegien whrend
der tglichen Arbeit, also das standardmige Arbeiten mit den Rechten eines normalen Benutzers.
Die Privilegien eines solchen Benutzers sind stark eingeschrnkt, wodurch es ihm nicht mglich ist,
auf die sicherheitsrelevanten Bereiche des Betriebssystems schreibend zuzugreifen. Hieraus folgt
zwangslufig, dass die von einem Standardbenutzer aufgerufene Anwendung keine Mglichkeit besitzt
die sicherheitsrelevanten Bereiche des Betriebssystems nachhaltig zu schdigen. Schreibzugriffe sind
nur fr das jeweilige Benutzerprofil mglich, so dass ein potentieller Angriff bsartiger Software
vergleichsweise harmlose Folgen hat.
Nachdem ein einfacher Lsungsansatz zur effizienten Minimierung der Sicherheitsrisiken existiert,
stellt sich die Frage, warum dieser Lsungsansatz nur geringe Akzeptanz fand und auch noch findet.
Die Antworten sind einfach und einleuchtend und zeigen ganz deutlich die Schwachstellen des
Systems auf:
Vielen Benutzern fehlt die Sensibilisierung fr diese Problematik, hufig werden die potentiellen
Gefahrenquellen nicht bedacht oder falsch eingeschtzt.
Bei der Installation wird automatisch ein Administratorenkonto erzeugt, dass auch nach der
Installation weiter verwendet wird. Viele Benutzer lassen das entsprechende Fachwissen
vermissen, dieses Konto zu deaktivieren und ein eingeschrnktes Benutzerkonto einzurichten.
Fr bestimmte Aktionen werden immer administrative Privilegien erforderlich sein, so dass immer
ein Benutzerkonto existieren muss, dass ber diese Rechte verfgt. Werden bei der tglichen Arbeit
nun diese erhhten Rechte bentigt, muss zwangslufig ein Wechsel zu diesem
Administratorenkonto erfolgen. Diese Mglichkeit ist in den aktuellen Betriebssystemen
vorhanden, sie ist allerdings nicht als sonderlich komfortabel anzusehen.
Aus den Ausfhrungen lsst sich jedoch ganz klar erkennen, dass an der standardmigen Verwendung
der eingeschrnkten Rechte im Tagesgeschft nicht vorbeigegangen werden kann. Die Problematik
liegt vielmehr im Zusammenspiel zwischen Sicherheit und Komfort begrndet. Diesem Problempunkt
wurde jedoch bei der Entwicklung von Windows Vista und Windows Server 2008 Rechnung getragen;
es wurde ein Mechanismus integriert, der Sicherheit und Komfort nicht mehr gegenstzlich erscheinen
lsst. Dieser Mechanismus wird als Benutzerkontensteuerung (User Account Control) oder abgekrzt
UAC bezeichnet.
Sicherheitskontext
Sicherheit wird schon seit geraumer Zeit immer grer geschrieben. So verwenden alle aktuellen
Microsoft Betriebssysteme ein ausgeklgeltes Sicherheitssystem um Informationen vor unbefugten
Zugriff zu schtzen. Einfach ausgedrckt muss das Betriebssystem zunchst prfen, ob ein Benutzer
oder eine Benutzergruppe die erforderlichen Berechtigungen aufweist um auf eine spezifische
Ressource zugreifen zu knnen. Die erforderlichen Berechtigungen fr den Zugriff sind Bestandteil
der Ressource und sind gemeinsam mit ihr gespeichert. Die erteilten Berechtigungen lassen sich ber
den Eigenschaftendialog der Ressource anzeigen, wie dieses in Abbildung 5.33 fr die Datei
notepad.exe dargestellt wird, die sich im Windows-Ordner befindet.
179
Kapitel 5
Abbildung 5.33: Zugriffsberechtigungen einer Ressource
Der grundstzliche Aufbau dieses Dialoges oder besser gesagt der Registerkarte Sicherheit ist fr alle
Arten von Ressourcen identisch, allerdings sind die mglichen Berechtigungen von der Art der
Ressource abhngig. So finden sich bei einer Datei Berechtigungen zum Lesen oder Schreiben, bei
einem Drucker hingegen sind es Optionen zum Drucken oder Verwalten des Druckers. Kommen wir
aber zurck zu den Sicherheitseinstellungen von notepad.exe. Die obere Liste enthlt die Benutzer und
Benutzergruppen, die auf die Ressource zugreifen drfen oder denen der Zugriff entzogen wurde. Die
untere Liste enthlt schlielich die mglichen Zugriffsberechtigungen fr jeden Benutzer oder
Benutzergruppe der oberen Liste. Es wird deutlich, dass die Mitglieder der Gruppe Administratoren
ber Lesezugriffe fr die Datei verfgen und diese auch ausfhren also starten drfen. Modifikationen
an der Datei, also das Ersetzen oder Entfernen sind den Mitgliedern der Administratorengruppe nicht
gestattet, sondern sind einem speziellen Benutzerkonto, dem TrustedInstaller vorbehalten. Wie bereits
angedeutet, sind diese Einstellungen und Vorgaben Bestandteil der Datei, wie dieses schematisch auch
in Abbildung 5.34 dargestellt wird.
180
Abbildung 5.34: Schematischer Aufbau der Sicherheitsoptionen einer Datei
Jede Ressource verfgt neben ihrem eigentlichen Inhalt noch ber eine Sicherheitsbeschreibung
(Security Descriptor), die letztlich die Zugriffsmglichkeiten regelt. Die Sicherheitsbeschreibung
selbst enthlt die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List) oder kurz
DACL. Hierbei handelt es sich um eine Liste, in der die einzelnen Berechtigungen aufgefhrt sind.
Jeder einzelne Eintrag dieser Liste ist eine Struktur vom Typ Zugriffssteuerungseintrag (Access
Control Entry) oder ACE. Ein solcher Zugriffssteuerungseintrag enthlt immer eine
Sicherheitskennung (SID) mit deren Hilfe der Benutzer oder die Benutzergruppe identifiziert wird.
Weiterhin verfgt dieser ACE ber eine Liste mit Berechtigungen und Verboten, anhand der
entschieden wird, ob der Zugriff durch diesen Benutzer erlaubt oder abgewiesen wird. In einem
Zugriffssteuerungseintrag drfen keine Verbote (Access Denied ACE) und Genehmigungen (Access
Allowed ACE) gemischt werden, so dass fr eine Sicherheitskennung unter Umstnden mehrere
Zugriffssteuerungseintrge vorhanden sind.
Es wird deutlich, dass es zu Konflikten kommen kann. Dem Benutzer XYZ kann es untersagt
werden, auf eine Datei zuzugreifen. Gleichzeitig kann er aber Mitglied einer Benutzergruppe sein, die
wiederum auf die Datei zugreifen darf. Bei der berprfung werden die Zugriffssteuerungseintrge
sequentiell abgearbeitet. Wird hierbei auf einen Eintrag getroffen, der eine der angeforderten
Berechtigungen verbietet, so wird der Vergleich an dieser Stelle abgebrochen und der Zugriff wird
verweigert. Wird hingegen ein Zugriffssteuerungseintrag angetroffen, der die angeforderte Rechte
gestattet, wird der Zugriff logischerweise erlaubt. Es wird deutlich, dass die Reihenfolge, in der die
181
Kapitel 5
Zugriffssteuerungseintrge in der freigegebenen Zugriffsteuerungsliste abgelegt werden nicht

unerheblich ist. Aus diesem Grund stellt das Betriebssystem alle Steuerungseintrge an den Beginn der
Liste, die einen Zugriff verbieten. Zustzlich gibt es noch einige Sonderformen zu bercksichtigen.
Enthlt eine Sicherheitsbeschreibung keine freigegebene Zugriffssteuerungsliste (NULL DACL), so ist
der Zugriff nicht eingeschrnkt und jeder kann auf diese Ressource zugreifen. Existiert hingegen eine
freigegebene
Zugriffssteuerungsliste,
verfgt
diese
aber
wiederum
ber
keine
Zugriffssteuerungseintrge, so darf niemand auf die Ressource zugreifen.
Sicherheit hat natrlich auch sehr hufig mit berwachungsmechanismen zu tun. So enthlt die
Sicherheitsbeschreibung noch eine Systemzugriffssteuerungsliste (System Access Control List) oder
kurz SACL. Diese Systemzugriffssteuerungsliste ist erforderlich, um alle erfolgreichen oder
gescheiterten Zugriffsversuche auf eine Ressource in ein spezielles Ereignisprotokoll zu schreiben.
So viel hierzu, aber dieses ist natrlich zunchst nur die halbe Wahrheit, denn bisher wurde lediglich
dargestellt, wie die einzelnen Ressourcen abgesichert werden und wer mit welchen Rechten darauf
zugreifen darf. Es stellt sich aber noch die Frage, ber welche Berechtigungen der aktuellen Benutzer
verfgt und welchen Benutzergruppen er angehrt. Um dieses zu klren muss zunchst der
Anmeldevorgang errtert werden, denn dessen Ergebnis ist der sogenannte Sicherheitskontext
(Security Context). Hierbei handelt es sich um eine Eigenschaft die festlegt in wessen Namen und mit
welchen Rechten Programmcode ausgefhrt wird, also letztlich welche Privilegien und
Genehmigungen einem Prozess erteilt oder entzogen wurden. Im Rahmen des Anmeldevorgangs
werden die folgenden Schritte durchlaufen:
Der Benutzer meldet sich am Anmeldebildschirm an. Er gibt seinen Benutzernamen und sein
Kennwort ein. Diese Informationen werden an das Sicherheitssubsystem weiter geleitet.
Das Sicherheitssubsystem ruft ein Authentifizierungspaket auf, das letztlich bei erfolgreicher
Authentifizierung die Anfrage an die Sicherheitskontenverwaltung (Security Account Manager)
weiter leitet. Ein Authentifizierungspaket ist eine Objektbibliothek (Dynamic Link Library), die
Anmeldedaten analysiert und feststellt, ob ein Konto authentifiziert werden soll. Beispiele fr
hufig verwendete Authentifizierungspakete sind Kerberos und NTLM.
Die Sicherheitskontenverwaltung (SAM) verwaltet eine Datenbank mit Benutzerkennungen. Von
der Sicherheitskontenverwaltung wird die Sicherheitskennung (SID) des Benutzers und die SIDs
aller Benutzergruppen, denen er angehrt zurckgegeben.
Es wird nun eine Anmeldesitzung (Logon Session) angelegt und zurckgegeben. Im Weiteren wird
ein Zugriffstoken erstellt. Dieser enthlt die Sicherheitsinformationen ber den Benutzter.
Die Windows Oberflche mit dem Explorer wird unter dem Sicherheitskontext des soeben
authentifizierten Benutzers gestartet. Hieraus folgt, dass alle Anwendungen, die beispielsweise
durch Doppelklick aus dem Explorer-Fenster gestartet werden, ebenfalls ber diesen
Sicherheitskontext verfgen.
Fr alle weiteren sicherheitsrelevanten Betrachtungen einschlielich der Erluterung der
Benutzerkontensteuerung ist der vorletzte Schritt im Anmeldevorgang, die Erzeugung des
Zugriffstokens zu beachten. Ein solcher Zugriffstoken enthlt alle sicherheitsrelevanten Informationen
des Benutzers kann somit als Ausweis fr Systemoperationen bezeichnet werden, wie dieses auch in
Abbildung 5.35 aufgezeigt wird.
182
Abbildung 5.35: Schematische Darstellung eines Zugriffstokens
Ein Bestandteil der Informationen des Benutzerkontos ist die Sicherheitskennung (SID). Hierbei
handelt es sich um einen numerischen Wert variabler Lnge, der weltweit eindeutig ist und somit einen
Benutzer eindeutig ausweisen kann.
S-1-5-21-2215374185-4733489-3158440935-500
Die SID beginnt mit dem Prfix S. Danach folgt die sogenannte Revisionsnummer, in diesem Fall
die 1 und die Autorittsnummer, in diesem Fall die 5, die fr SECURITY_NT_AUTHORITY steht.
Dahinter folgt die individuelle Subautoritt, die den Rechner oder die Domne kennzeichnet, auf der
diese SID erstellt wurde. Dieser Zifferncode wird aus verschiedenen Faktoren berechnet, so dass
hiermit eine Eindeutigkeit erreicht werden kann. Die 21 der Subautoritt kennzeichnet in dem
Beispiel ein Benutzerkonto, dass nachtrglich angelegt wurde. Eine 32 wrde hingegen eine von
Windows automatisch erzeugte Benutzergruppe kennzeichnen. Der letzte Teil der SID, nmlich die
500, ist die Relative ID (RID). Nachtrglich erstellte Benutzerkonten beginnen mit der Zahl 1000
und werden fortlaufend vergeben. RIDs zwischen 500 und 999 sind systemeigene RIDs, die fest
zugeordnet sind. Das Administratorkonto hat beispielsweise die 500. Darber hinaus existieren noch
weitere vordefinierte RIDs fr bestimmte Benutzergruppen.
Zustzlich zum Identifizierungsmerkmal des Benutzers enthlt der Zugriffstoken eine Auflistung aller
Gruppen denen der Benutzer angehrt. Blicken wir an diese Stelle zurck zu unserem Zugriff auf die
Ressource. Der bei der Anmeldung erzeugte Zugriffstoken wird im Verlauf der Windows-Sitzung
jedem Prozess bergeben, den der Benutzer startet, wie die nachfolgende Deklaration der Funktion
CreateProcessAsUser() auch zeigt.
[DllImport("kernel32.dll")]
private static extern bool CreateProcessAsUser (
183
Kapitel 5
int hToken,
string lpApplicationName,
string lpCommandLine,
ref SECURITY_ATTRIBUTES lpProcessAttributes,
ref SECURITY_ATTRIBUTES lpThreadAttributes,
int bInheritHandles,
int dwCreationFlags,
string lpEnvironment,
string lpCurrentDirectory,
ref STARTUPINFO lpStartupInfo,
ref PROCESS_INFORMATION lpProcessInformation
);
Hieraus folgt, dass jeder Prozess, der auf dem Betriebssystem ausgefhrt wird, immer ber ein Token
verfgt, welches abgefragt werden kann, und welches Informationen ber den Erzeuger des Prozesses
besitzt. Wird also versucht die Datei notepad.exe zu starten, werden die Informationen des Tokens des
aufrufenden Prozesses mit den erforderlichen Sicherheitseinstellungen der Ressource verglichen und in
Abhngigkeit zum Ergebnis die Aktion ausgefhrt oder abgebrochen, wie dieses in Abbildung 5.36
gezeigt wird.
Abbildung 5.36: Schema der Absicherung von Objekten
Der Zugriffstoken enthlt zustzlich zu den gerade erluterten Daten noch eine Liste der Privilegien
des Benutzers. Hierunter versteht man Rechte die sich nicht auf einzelne Objekte abbilden lassen,
sondern Berechtigungen zum Durchfhren bestimmter Aktionen, wie zum Beispiel das Recht zum
Herunterfahren des Systems, dass durch das Privileg SeShutdownPrivilege gekennzeichnet ist. Alle
diese Informationen sind in ihrer Gesamtheit relevant fr die Ausfhrung von Benutzeraktivitten. So
wird beispielsweise anhand der SID geprft, ob auf bestimmte Bereiche des Dateisystems oder die
Systemregistrierung zugegriffen werden darf. Die Privilegien finden hingegen beim Ausfhren
systemrelevanter Aktivitten ihre Anwendung.
Zugriffstoken unter Windows Vista

Alle bisherigen Windows-Betriebssysteme erstellen whrend des Anmeldevorgangs einen
Zugriffstoken, der fr alle weiteren Benutzeraktivitten, wie das Starten von Anwendungen, das
Anlegen von Dateien oder den Zugriff auf Verzeichnisse verwendet wird. Die Problematik ist
184
offensichtlich; handelt es sich bei dem Benutzer um ein Mitglied der Administratorengruppe sind die
Benutzerrechte kaum eingeschrnkt, so dass gestartete Software auf alle systemrelevanten Bereiche
des Betriebssystems zugreifen und dieses modifizieren kann. Handelt es sich hingegen um einen
normalen Benutzer, reichen diese Berechtigungen zur Durchfhrung bestimmter Aktivitten hufig
nicht aus, so dass diese Aktionen von einem anderen Benutzerkonto aus gesteuert werden mssen.
Windows Vista und Windows Server 2008 enthalten hier einen abweichenden Lsungsansatz, der das
bisher bekannte Standardbenutzermodell wesentlich flexibler und sicherer gestaltet. Einfach
ausgedrckt werden fr einen Administrator zwei Zugriffstoken erstellt, ein gefilterter Token fr den
Standardzugriff und ein weiterer Token fr den vollen Administratorzugriff. Anstatt die WindowsOberflche mit dem Token des Administrators zu starten, wird hierfr der gefilterte Zugriffstoken des
Standardbenutzers verwendet. Alle untergeordneten Prozesse erben diesen Zugriffstoken, was somit
zur Verringerung der Angriffsflche von Windows Vista und Windows Server 2008 beitrgt.
Hierdurch wurde weiterhin auch die Problematik des erforderlichen technischen Wissens adressiert,
die zum Anlegen eines neuen Benutzerkontos vorhanden sein muss. Bei der Installation des
Betriebssystems wird der Benutzer aufgefordert eine Bezeichnung fr das zu erzeugende
Benutzerkonto anzulegen. Dieses Konto wird automatisch der Administratorengruppe hinzugefgt und
im Rahmen der Installation verwendet. Nach Abschluss der Installation ist dann die
Benutzerkontensteuerung aktiv, so dass durch die Verwendung des gefilterten Tokens die
ursprngliche Problematik beseitigt wurde. Ergnzend sei anzumerken, dass es nach wie vor das
vordefinierte Administratorenkonto (Built-In Administrator) existiert, dieses aber standardmig
deaktiviert ist.
Es ist erkennbar, dass zunchst nur die Rechte des Standardbenutzers zur Verfgung stehen, wodurch
zwangslufig gewisse Aktivitten nicht durchgefhrt werden knnen. Hier hat es jedoch bei Windows
Vista und Windows Server 2008 eine Anpassung gegeben, so dass ein Standardbenutzer unter diesen
Betriebssystemen zustzliche Privilegien besitzt. Zu diesen neuen Berechtigungen fr
Standardbenutzer gehren:
Anzeigen der Systemuhr und des Kalenders.
ndern der Zeitzone.
Installation von WEP (Wired Equivalent Privacy), um eine Verbindung zu einem WLAN
aufzubauen.
ndern der Anzeigeeinstellungen.
ndern der Energiesparoptionen.
Installation von Schriftarten.
Hinzufgen von Druckern und anderen Gerten, fr die die Installation von Treibern erforderlich
ist.
Erstellen und Konfigurieren von VPN-Verbindungen.
Herunterladen und Installieren von Updates mit einem UAC-kompatiblen Installer.
An vorheriger Stelle habe ich bereits erwhnt, dass bei einem Administrator zwei Zugriffstoken erstellt
werden. Dieses ist zwar nicht falsch, doch technisch gesehen nicht ganz korrekt. Przise ausgedrckt
werden zunchst die Privilegien des Benutzers betrachtet. Verfgt der Benutzer im Gegensatz zu
einem Standardbenutzer ber zustzliche Privilegien werden zwei Zugriffstoken erstellt, wobei ein
Standardbenutzerkonto ausschlielich ber die folgenden Privilegien verfgt:
SeChangeNotifyPrivilege
185
Kapitel 5
SeShutdownPrivilege
SeUndockPrivilege
SeReserveProcessorPrivilege
Besitzt ein Benutzer beispielsweise das Privileg SeDebugPrivilege, werden zwei Zugriffstoken erstellt,
da SeDebugPrivilege nicht zu den Privilegien eines Standardbenutzers gehrt.
Darber hinaus existiert noch ein anderes Szenario, in dem zwei Zugriffstoken erstellt werden. Hierbei
wird die Gruppenzugehrigkeit des Benutzers betrachtet. Meldet sich beispielsweise ein Benutzer am
System an, der zur Administratorengruppe gehrt, werden natrlich zwei Zugriffstoken erstellt. Der zu
Grunde liegende Algorithmus verwendet hierbei die Sicherheitskennung (SID) der jeweiligen
Benutzergruppe, wie S-1-5-32-544 fr die Administratoren. Relevant ist hierbei ausschlielich die
Relative ID (RID), also der letzte Teil der SID. Dieses Identifizierungsmerkmal wird mit einer
Auflistung verglichen, wie sie auch in Tabelle 5.40 dargestellt ist. Fr das Beispiel ist erkennbar, dass
sich die 544 in der Tabelle wieder findet (DOMAIN_ALIAS_RID_ADMIN), wodurch zwei
Zugriffstoken erstellt werden.
RID
Wert
DOMAIN_GROUP_RID_ADMINS
0x200 (512)
DOMAIN_GROUP_RID_CONTROLLERS
0x204 (516)
DOMAIN_GROUP_RID_CERT_ADMINS
0x205 (517)
DOMAIN_GROUP_RID_SCHEMA_ADMINS
0x206 (518)
DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
0x207 (519)
DOMAIN_GROUP_RID_POLICY_ADMINS
0x208 (520)
DOMAIN_ALIAS_RID_ADMINS
0x220 (544)
DOMAIN_ALIAS_RID_POWER_USERS
0x223 (547)
DOMAIN_ALIAS_RID_ACCOUNT_OPS
0x224 (548)
DOMAIN_ALIAS_RID_SYSTEM_OPS
0x225 (549)
DOMAIN_ALIAS_RID_PRINT_OPS
0x226 (550)
DOMAIN_ALIAS_RID_BACKUP_OPS
0x227 (551)
DOMAIN_ALIAS_RID_RAS_SERVERS
0x229 (553)
DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
0x22A (554)
DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
0x22C (556)
Tabelle 5.40: Relative IDs (RID) zur Bestimmung der Zugriffstoken
In dem konstruierten Beispiel existieren fr ein Mitglied der Administratorengruppe nun zwei
Zugriffstoken. Unter Verwendung des ersten Tokens, der auch als gefilterter Token, eingeschrnkter
Token oder auch UAC-Token bezeichnet wird, werden standardmig alle Benutzeraktivitten
durchgefhrt. So wird zum Starten der Windows-Oberflche dieser Token verwendet, wodurch alle
von der Oberflche ausgefhrten Aktionen ebenfalls diesen Token verwenden.
Wie bereits angedeutet, sollen diese Aktivitten mit geringeren Privilegien ausgefhrt werden, wozu
186
ein geeigneter Token zunchst erzeugt werden muss. Zu diesem Zweck wird die Funktion
CreateRestrictedToken() auf eine Kopie des unvernderten Zugriffstokens verwendet:
[DllImport("advapi32.dll")]
private static extern bool CreateRestrictedToken (
int ExistingTokenHandle,
int Flags,
int DisableSidCount,
ref SID_AND_ATTRIBUTES SidsToDisable,
int DeletePrivilegeCount,
ref LUID_AND_ATTRIBUTES PrivilegesToDelete,
int RestrictedSidCount,
ref SID_AND_ATTRIBUTES SidsToRestrict,
int NewTokenHandle
);
Dem Parameter PrivilegesToDelete wird hierbei eine Auflistung von Privilegien bergeben, die aus
dem Token entfernt werden sollen. Zwangslufig mssen hier allen Privilegien angegeben werden, die
einem Standardbenutzer nicht zur Verfgung stehen. Der Benutzer wird hierdurch in der Ausfhrung
systemrelevanter Operationen eingeschrnkt. Es fehlen schlielich noch die Einschrnkungen beim
Zugriff auf Objekte. Wie bereits verdeutlicht, wird dieser Zugriff durch die Gruppenzugehrigkeit
ermglicht. Es ist somit erforderlich, diese Zuordnungen zu modifizieren, wozu der Parameter
SidsToDisable dient. Diesem ist eine Auflistung der Benutzergruppen zu bergeben, deren
Zugehrigkeit dem Benutzer aberkannt werden soll. Das Betriebssystem enthlt die Anwendung
whoami.exe die dieses unter Verwendung des Parameters /groups veranschaulicht. So wird deutlich,
dass der Benutzer nach wie vor zur Gruppe der Administratoren gehrt, allerdings ist erkennbar, dass
es sich nun um eine geschtzte Gruppe handelt:
Gruppe: BUILTIN\Administrators, Alias: S-1-5-32-544, Gruppe, die nur zum
Ablehnen verwendet wird (Group used for deny only)
Bei dem zweiten Token handelt es sich um den vollstndigen, unvernderten Token, der auch als FullAdmin-Token bezeichnet wird. Dieser Token wird nur verwendet, falls vollstndige Privilegien
erforderlich werden. Wird beispielsweise die Eingabeaufforderung im Startmen markiert und im
Kontextmen der Befehl Als Administrator ausfhren ausgewhlt, erscheint zunchst ein Dialog um
die Verwendung des vollstndigen Tokens zu besttigen. Wird nun der Befehl whoami.exe /groups in
das Befehlsfenster eingegeben, wird die Verwendung des vollstndigen Tokens deutlich, denn hierbei
wird nun die uneingeschrnkte Administratorengruppe ausgegeben:
Gruppe: BUILTIN\Administrators, Alias: S-1-5-32-544, Verbindliche Gruppe,
Standardmig aktiviert, Aktivierte Gruppe, Gruppenbesitzer (Mandatory
Group, Enabled by default, Enabled Group)
Deutlich wird in diesem Beispiel auch die Verbindung von Sicherheit und Komfort, die sich ja bei
frheren Betriebssystemen gegenseitig ausgeschlossen haben. Der angemeldete Benutzer arbeitet mit
den normalen Standardberechtigungen. Durch eine Manahme wird das Betriebssystem informiert,
dass fr die folgende Aktivitt diese Rechte nicht ausreichend sind und der Benutzer vollstndige
Privilegien bentigt. Das Betriebssystem holt sich daraufhin nochmal die Besttigung vom Benutzer
187
Kapitel 5
zum Starten des Prozesses unter Verwendung des vollstndigen Zugriffstokens. Dieses Szenario wird
als Administratorbesttigungsmodus (Admin Approval Mode) bezeichnet.
Anwendungen fr Windows Vista und Windows

Server 2008
In dem kurzen Szenario des vorherigen Absatzes wurde die Verwendung der vollstndigen Privilegien
vom Anwender veranlasst, indem er einen speziellen Befehl verwendet hat. Dieses ist zwar mglich,
allerdings ist es nicht sehr komfortabel und teilweise auch fehleranfllig, denn hufig sind dem
Benutzer die erforderlichen Rechte gar nicht bekannt. Windows Vista und Windows Server 2008
gehen an dieser Stelle noch einen Schritt weiter und entscheiden individuell, wobei bestimmte
Faktoren im Anwendungsdesign zu bercksichtigen sind.
Zunchst interpretiert das Betriebssystem jede Anwendung als UAC-Kompatibel. Das bedeutet, dass
aus dessen Sicht, zunchst jede Anwendung mit eingeschrnkten Privilegien lauffhig ist. Windows
Vista und Windows Server 2008 verwenden jedoch einen Algorithmus, der anhand der Metadaten
einer Anwendung erkennt, ob vollstndige Privilegien fr die Ausfhrung erforderlich sein mssen.
Der Algorithmus dient im Wesentlichen als Kompatibilittsmittel, da folgende Faktoren zutreffen
mssen:
Es muss sich um eine 32-Bit Anwendung handeln.
Die Anwendungen drfen ber kein Manifest verfgen, in dem die Ausfhrungsebene
(requestedExecutionLevel) festgelegt wurde.
Es muss sich um interaktive Prozesse handeln, die im Kontext eines Standardbenutzers bei
aktivierter Benutzerkontensteuerung ausgefhrt werden.
Der Algorithmus ist sehr einfach gehalten und dient im Wesentlichen dazu ein Installationsprogramm
(nicht Windows Installer) von einer klassischen Anwendung zu unterscheiden. Es werden folgende
Metainformationen geprft:
Enthlt der Dateiname die Zeichenfolgen setup, update oder install.
Enthalten die Eigenschaftsfelder Firma, Produktname,
Dateiname, Interner Name der Datei eine dieser Zeichenfolgen.
Beschreibung,
Original
Sind diese Zeichenfolgen im eingebetteten SxS-Manifest der Anwendung zu finden.

Verfgt die ausfhrbare Datei ber Bytesequenzen oder Zeichenfolgen, die auf ein
Installationsprogramm schlieen lassen. Hierzu werden Charakteristiken von verschiedenen
Installationstechnologien herangezogen.
Wird eine Datei anhand dieser Kriterien identifiziert, werden vom Betriebssystem vollstndige
Privilegien fr die Ausfhrung verlangt. Die Verwendung dieses Algorithmus kann durch die
Systemrichtlinie Benutzerkontensteuerung: Anwendungsinstallationen erkennen und erhhte Rechte
anfordern (EnableInstallerDetection) beeinflusst werden. Der dargestellte Algorithmus stellt eine
sehr grob gefasste und zum Teil auch problematische Mglichkeit dar, die erforderlichen
Ausfhrungsprivilegien seitens des Systems automatisch zu bestimmen. Darber hinaus existieren
noch weitere Mglichkeiten, eine Anwendung zur Ausfhrung mit vollstndigen Privilegien zu
veranlassen:
188
Der erforderliche Ausfhrungslevel einer Anwendung wurde im Anwendungsmanifest definiert.

Der erforderliche Ausfhrungslevel eines Windows Installer-Paketes wurde ber eine spezielle
Eigenschaft festgelegt.
In der Kompatibilittsdatenbank (APPCOMPAT) wurde der Ausfhrungslevel der Anwendung
definiert.
Im Register Kompatibilitt des Dialogs Eigenschaften der Anwendung,
Kontrollkstchen Programm als ein Administrator ausfhren aktiviert.
wurde
das
Die Anwendung wurde ber den Menpunkt Als Administrator ausfhren des Kontextmens
gestartet.
Die letzten Optionen dieser Liste verndern die Datei nicht, sondern bieten die Mglichkeit der
nachtrglichen Konfiguration einer Anwendung. Dieses ist natrlich erforderlich, da viele
Anwendungen existieren, die vor dem Erscheinen von Windows Vista entwickelt wurden und somit
ber keine spezielle Anpassung verfgen. Bei Neuentwicklungen oder speziell fr Windows Vista und
Windows Server 2008 angepasste Dateiversionen sollte immer die erste Option verwendet werden,
denn hierdurch sind die Ausfhrungsprivilegien untrennbar mit der Datei verbunden und gelten auf
jeder untersttzten Plattform. Das heit natrlich auch, dass bei der Anwendungsentwicklung geprft
werden muss, welche Privilegien tatschlich erforderlich sind. Hilfestellung hierbei bietet der Standard
User Analyzer, der Bestandteil des Microsoft Application Compatibility Toolkit ist. Das Ergebnis
dieser Prfung muss sich letztlich in einer Ausfhrungsebene niederschlagen und im
Anwendungsmanifest abgelegt werden. Die folgenden Ausfhrungsebenen stehen hierfr zur
Verfgung:
asInvoker: Die Anwendung wird mit dem identischen Token ausgefhrt, wie der aufrufende
Prozess.
highestAvailable: Die Anwendung wird mit den hchsten Privilegien ausgefhrt, die dem
jeweiligen Benutzer zur Verfgung stehen. Bei einem Standardbenutzer, wird nicht nach hheren
Privilegien verlangt, sondern die Anwendung wird mit Standardberechtigungen ausgefhrt. Bei
einem Administrator hingegen, wird die Verwendung vollstndiger Privilegien veranlasst.
requireAdministrator: Die Anwendung erfordert administrative Privilegien und verlangt dazu den
vollstndigen Zugriffstoken.
Das zu erstellende Anwendungsmanifest kann sich hierbei als externe Datei (application.exe.manifest)
im Anwendungsordner befinden oder als Ressource RT_MANIFEST in die ausfhrbare Datei integriert
werden, wobei die letzte Mglichkeit zu bevorzugen ist. Listing 5.44 zeigt ein Manifest, das fr die
Anwendung vollstndige Privilegien erfordert. Mit Hilfe des Attributs uiAccess wird es mglich
Sicherheitsebenen fr Benutzeroberflchen zu umgehen, so dass quasi eine Fernsteuerung der
Fensterinhalte erfolgen kann. Dieses Szenario ist hufig im Rahmen der Testautomatisierung und bei
der Verwendung von Eingabehilfen wie beispielsweise eine Bildschirmtastatur anzutreffen. Um
hierbei auch einen mglichst hohen Sicherheitsanspruch zu gewhrleisten, muss die so
gekennzeichnete Anwendung digital signiert werden. Im Weiteren ist es erforderlich, dass eine solche
Anwendung aus einem vertrauenswrdigen Verzeichnis gestartet wird, wie das bei %SystemRoot%
oder %ProgramFiles% der Fall ist. Dieses kann jedoch mit Hilfe der Richtlinie
Benutzerkontensteuerung: Nur erhhte Rechte fr UIAccess-Anwendungen, die an sicheren Orten
installiert sind unterbunden werden.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
189
Kapitel 5
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="UACSample"
type="win32"/>
<description>Beschreibung der Anwendung</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Listing 5.44: Anwendungsmanifest zur Untersttzung der Benutzerkontensteuerung.
Bei der Verwendung von Visual Studio 2005 ist zu beachten, dass nur bei C++ Anwendungen, die
direkte Integration des Manifests seitens der Entwicklungsumgebung bereitgestellt wird. Bei der
Erstellung von VB.NET und C# Anwendungen mssen die Manifest-Dateien nachtrglich in die
Anwendung integriert werden. Das Windows SDK stellt fr solche Zwecke das Befehlszeilentool
mt.exe zur Verfgung. Der erforderliche Aufruf kann als Postbuildereignis (Post-Build Event) in den
Projekteigenschaften hinzugefgt werden, so dass die Integration des Manifestes bei jedem
Erstellungsvorgang automatisch erfolgt.
mt.exe
-manifest
outputresource:"$(TargetPath)";#1
"$(ProjectDir)Admin.manifest"
Mit Visual Studio 2008 ist dieses nicht mehr erforderlich. Diese Version der Entwicklungsumgebung
bietet umfangreiche Einstellungsmglichkeiten zur Verwendung von Manifest-Dateien ber die
Einstellungsdialoge der Projekteigenschaften. Standardmig wird jeder Anwendung ein Manifest
hinzugefgt, bei dem die Ausfhrungsebene auf asInvoker festgelegt wurde. Bitte beachten Sie, dass
dieses auch die grundstzliche Zielsetzung der Benutzerkontensteuerung darstellt. Bei der
Softwareentwicklung sind immer Anwendungen anzustreben, die unter Verwendung von
Standardbenutzerrechten ausgefhrt werden knnen. Natrlich mssen auch Anwendungen geschaffen
werden, die administrative Privilegien erfordern, so dass ein Manifest mit festgelegter
Ausfhrungsebene auf requireAdministrator verwendet werden muss. Dieses Manifest kann dem
Visual Studio-Projekt als Ressource hinzugefgt werden und die Verwendung kann ber die
Projekteigenschaften vorgenommen werden. Bei Starten eines Prozesses wird der festgelegte
Ausfhrungslevel ausgewertet und in den weiteren Workflow einbezogen, wie dieses auch Abbildung
5.37 darstellt.
190
Abbildung 5.37: Schematischer Ablauf beim Starten eines Prozesses
Wie bereits angedeutet, sollte die Zielsetzung bei der Softwareentwicklung jedoch immer auf die
Verwendung von Standardbenutzerrechten abzielen. Hierdurch ist gewhrleistet, dass keine bsartigen
Zugriffe auf das System erfolgen und dass die Mechanismen der Benutzerkontensteuerung nicht als
strend empfunden werden.
Hinweis Beginn
Ein einfacher Weg zur berprfung, ob die Anwendung ber ein Manifest verfgt und welche Werte
dieses Manifest aufweist ermglicht das Tool sigcheck.exe von Windows Sysinternals. Ein Aufruf
unter Verwendung des Parameters m zeigt die relevanten Einstellungen an.
Hinweis Ende
Absicherung des Systems

Wird die Ausfhrungsebene einer Anwendung so festgelegt, dass vollstndige Privilegien fr die
Ausfhrung erforderlich werden, wird dieses unter Windows Vista und Windows Server 2008 auch
grafisch gekennzeichnet. Hierzu wird das Symbol der Anwendung mit einer zustzlichen Markierung,
dem Schild versehen. Diese Kennzeichnung wird vom Betriebssystem dynamisch generiert. Wird eine
Anwendung beispielsweise der Ausfhrungsebene highestAvailable zugeordnet, wird das
Anwendungssymbol zustzlich durch den Schild markiert, wenn ein Benutzer mit vollstndigen
Privilegien am System angemeldet ist. Eine Kennzeichnung erfolgt hingegen nicht, falls ein
Standardbenutzer am System angemeldet ist. Diese Kennzeichnung erstreckt sich nicht nur auf
191
Kapitel 5
vollstndige Anwendungen und deren Verknpfungen, sondern kann auch einzelne Anwendungsteile
betreffen. Betrachten Sie hierzu den Dialog Datum und Uhrzeit, der auch in Abbildung 5.38
dargestellt ist. Dieser Dialog lsst sich von jedem Benutzer ohne Besttigung weiterer Privilegien
ffnen. Sollen jedoch das Datum oder die Uhrzeit gendert werden, sind vollstndige Privilegien
erforderlich, worauf das Schild-Symbol auf der entsprechenden Schaltflche hinweist.
Abbildung 5.38: Anwendungsteil erfordert vollstndige Privilegien
Wird eine Anwendung gestartet, wird vom Betriebssystem die erforderliche Ausfhrungsebene
ausgewertet. Wird hierbei festgestellt, dass vollstndige Privilegien erforderlich sind, erscheint ein
Dialog, in dem der Anwender die Verwendung dieser Privilegien explizit besttigen muss. Sind
hingegen nur die Rechte eines Standardbenutzers erforderlich, erscheint kein zustzlicher Dialog,
wodurch der gefhlte Arbeitskomfort des Benutzers erhht wird. Die interne Implementierung
verschiedener Win32-Funktionen wurde in Windows Vista und Windows Server 2008 angepasst um
Sicherheit und Komfort zu vereinbaren. Das zentrale Element innerhalb der UAC-Infrastruktur ist der
Anwendungsinformationsdienst (Application Information Service) oder kurz AIS, wie dieses auch der
nachfolgend skizzierte Workflow zeigt, der beim Starten einer Anwendung durchlaufen wird:
Der Benutzer startet das Defragmentierungsprogramm defrag.exe.
ShellExecute() erstellt einen neuen Prozess indem CreateProcess() aufgerufen wird.
CreateProcess() prft nun ob erhhte Privilegien fr die Prozessausfhrung bentigt werden.
Hierzu werden zunchst Informationen der Kompatibilittsdatenbank ausgewertet. Anschlieend
wird in der ausfhrbaren Datei nach einer festgelegten Ausfhrungsebene im Manifest gesucht.
Verfgt die ausfhrbare Datei ber kein Anwendungsmanifest mit festgelegter Ausfhrungsebene
wird schlielich noch anhand der Installer-Erkennung geprft.
Wurde festgestellt, dass erhhte Privilegien erforderlich sind, gibt CreateProcess() den neuen
Win32-Fehler ERROR_ELEVATION_REQUIRED zurck.
ShellExecute() reagiert auf diesen neuen Fehler und informiert den Anwendungsinformationsdienst
192
um die Verwendung erhhter Privilegien anzufordern.

AIS empfngt die Anforderung von ShellExecute() und prft erneut die angeforderte
Ausfhrungsebene. AIS wertet an dieser Stelle die Systemrichtlinien aus und stellt auf Basis dieses
Ergebnis fest, ob die Verwendung erhhter Privilegien gestattet wird und welche Darstellungsform
der Benutzeroberflche zu verwenden ist.
Falls
die
Verwendung
erhhter
Privilegien
erforderlich
ist,
zeigt
der
Anwendungsinformationsdienst den Besttigungsdialog an. Dieser wird je nach Festlegung in den
Systemrichtlinien auf dem Interaktiven Desktop des Benutzers oder dem Sicheren Desktop
dargestellt.
Der Anwendungsinformationsdienst ruft CreateProcessAsUser() auf, wobei der vollstndige
Zugriffstoken und der Interaktive Desktop des Aufrufers verwendet werden.
Aus dem skizzierten Ablauf wird deutlich, dass die Verwendung vollstndiger Privilegien vom
Anwender zu besttigen ist, wozu ein speziell geschaffener Dialog verwendet wird. Die Anzeige des
Dialogs selbst ist natrlich auch durch unterschiedliche Mechanismen abgesichert. Hierdurch wird
sichergestellt, dass die Besttigung normalerweise nicht automatisiert werden kann. Der Dialog wird
hierzu standardmig auf dem sicheren Desktop ausgefhrt. Hierbei handelt es sich um einen
speziellen Desktop, auf den nur vertrauenswrdige Systemprozesse zugreifen knnen. Dieses
Verhalten kann durch die Systemrichtline Benutzerkontensteuerung: Bei Benutzeraufforderung nach
erhhten Rechten zum sicheren Desktop wechseln (PromptOnSecureDesktop) verndert werden, was
gerade in Testszenarien im Rahme der Softwareentwicklung notwendig ist. Unabhngig davon auf
welchem Desktop der Besttigungsdialog tatschlich angezeigt wird, hat die aufgerufene Anwendung
noch Einfluss auf das Erscheinungsbild des Dialogs. An dieser Stelle kommen Signalfarben zum
Einsatz, die den Benutzer bezglich der Vertrauensstellung der Software sensibilisieren sollen, wie
Tabelle 5.41 zeigt.
Merkmal des Dialogs
Bedeutung
Blauer oder grner Hintergrund
Es handelt sich um eine administrative Anwendung von

Windows Vista und Windows Server 2008, wie bestimmte
Elemente der Systemsteuerung.
Grauer Hintergrund und goldener Schild
Es handelt sich um eine Authenticode signierte und daher

vertrauenswrdige Anwendung.
Gelber Hintergrund und goldener Schild
Die Anwendung ist nicht signiert oder sie ist signiert aber nicht
vertrauenswrdig.
Roter Hintergrund und roter Schild
Die Ausfhrung der Anwendung wird blockiert, da dieses ber

Systemrichtlinien festgelegt wurde oder der Publisher geblockt
ist.
Tabelle 5.41: Farbliche Kennzeichnung des UAC-Besttigungsdialogs
Darber hinaus wird die Darstellungsform des UAC-Besttigungsdialogs noch durch die Anzahl der
Zugriffstoken des Benutzers beeinflusst. Bei einem Benutzer der ber den eingeschrnkten und den
vollstndigen Zugriffstoken verfgt, also beispielsweise bei einem Mitglied der
Administratorengruppe, findet sich der Dialog in einer sehr einfachen Ausprgung. Er enthlt im
Wesentlichen lediglich eine Besttigungsfunktion fr die Verwendung erweiterten Privilegien. Dieser
Dialog wird als Aufforderung zur Eingabe der Zustimmung (Prompt for Consent) oder Einfacher
Besttigungsdialog bezeichnet. Handelt es sich bei dem Anwender um einen Standardbenutzer,
193
Kapitel 5
verfgt er zwangslufig nur ber einen eingeschrnkten Zugriffstoken, wodurch die erforderlichen
Rechte zum Ausfhren der Anwendung nicht gegeben sind. In diesem Fall wird der erweiterte
Besttigungsdialog oder die Aufforderung zur Eingabe der Anmeldeinformationen (Prompt for
Credentials) angezeigt. Mit Hilfe dieses Dialogs ist es nun mglich einen Benutzer auszuwhlen oder
anzugeben mit dessen Privilegien die Anwendung ausgefhrt werden soll. An dieser Stelle muss noch
zustzlich zwischen der Verwendung in einer Domne und einer Arbeitsgruppe unterschieden werden.
Bei der Verwendung in einer Arbeitsgruppe werden alle lokalen Benutzerkonten zur Auswahl
angeboten, die ber vollstndige Privilegien verfgen. In einer Domne ist dieses nicht der Fall; hier
muss der Benutzername manuell eingegeben werden. Die unterschiedlichen Ausprgungen des UACBesttigungsdialoges sind in Abbildung 5.39 aufgefhrt.
Abbildung 5.39: Unterschiedliche Ausprgungen des UAC-Besttigungsdialoges
Die gerade geschilderten Darstellungs- und Anwendungsformen des Besttigungsdialogs entsprechen

den Standardeinstellungen, die jedoch durch Sicherheitsrichtlinien beeinflusst werden knnen. Die
Darstellungsform fr Benutzer, die auch ber den vollstndigen Zugriffstoken verfgen, kann durch
die Richtlinie Benutzerkontensteuerung: Verhalten der Benutzeraufforderung mit erhhten Rechten
fr Administratoren im Administratorbesttigungsmodus (ConsentPromptBehaviorAdmin) beeinflusst
werden. Die Auswirkungen der Einstellungsoptionen sind in Tabelle 5.42 zusammengefasst. Fr
Benutzer die lediglich ber den eingeschrnkten Token verfgen ist die Richtlinie
Benutzerkontensteuerung: Verhalten der Benutzeraufforderung mit erhhten Rechten fr
Standardbenutzer (ConsentPromptBehaviorUser) zu verwenden. Die Einstellungsoptionen fr diese
Richtlinie werden hingegen in Tabelle 5.43 dargestellt.
194
bergeordneter
Prozesstoken
Einstellungen
asInvoker oder kein

Manifest
highestAvailable oder
requireAdministrator
Eingeschrnkter Token
Erhhte Rechte ohne

Eingabeaufforderung
(Elevate without
prompting).
Anwendung wird mit

Standardprivilegien
ausgefhrt.
Anwendung wird mit

vollstndigen Privilegien
ausgefhrt. Es wird kein
Dialog angezeigt.
Aufforderung zur Eingabe

der Zustimmung (Prompt
for Consent). Dieses ist
die Standardeinstellung.
Anwendung wird mit

Standardprivilegien
ausgefhrt.
Anwendung wird mit

ausgefhrt. Einfacher
Besttigungsdialog wird
angezeigt.

der
Anmeldeinformationen
(Prompt for Credentials).
Anwendung wird mit

Standardprivilegien
ausgefhrt.
Anwendung wird mit

ausgefhrt. Erweiterter
angezeigt.
Vollstndiger Token
(Nicht relevant)
Anwendung wird mit

Dialog angezeigt.
Anwendung wird mit

Dialog angezeigt.
Tabelle 5.42: Richtlinie fr den Besttigungsdialog bei Aktionen durch Administratoren

bergeordneter
Prozesstoken
Einstellungen
asInvoker,
highestAvailable oder
kein Manifest
requireAdministrator
Anhebungsaufforderung
automatisch abweisen
(Automatically deny
elevation requests).
Anwendung wird mit

Standardprivilegien
ausgefhrt.
Start der Anwendung

schlgt fehl.
Fehlermeldung Zugriff
verweigert wird
angezeigt.

der
Anmeldeinformationen
(Prompt for Credentials).
Dieses ist die
Standardeinstellung.
Anwendung wird mit

Standardprivilegien
ausgefhrt.
Anwendung wird mit

ausgefhrt. Erweiterter
angezeigt.
Tabelle 5.43: Richtlinie fr den Besttigungsdialog bei Aktionen durch Standardbenutzer
Eine Besonderheit bei der Benutzerkontensteuerung betrifft noch das vordefinierte

Administratorenkonto (built-in Administrator). Dieser Benutzer ist standardmig vom Zugriffsschutz
ausgenommen. Das bedeutet, dass er lediglich ber einen vollstndigen Zugriffstoken verfgt und
somit die Anzeige eines Besttigungsdialogs nicht erforderlich ist. Dieses Verhalten kann durch die
Sicherheitsrichtlinie Benutzerkontensteuerung: Administratorbesttigungsmodus fr das integrierte
Administratorkonto (FilterAdministratorToken) verndert werden.
Mitunter existiert die Anforderung der programmtechnischen Ermittlung, mit welchen Rechten ein
Prozess ausgefhrt wird und ob der Benutzer ber mehrere Zugriffstoken verfgt. Zu diesem Zweck
195
Kapitel 5
kann die Win32-Funktion GetTokenInformation() verwendet werden, wie dieses auch in Listing 5.45
demonstriert wird.
internal static void CheckElevationType(Process process)
{
// Deklarationen
int tokenInfoLen = sizeof(int);
int tokenInfo = 0;
IntPtr hToken;
// Prozess-Token ffnen
if (OpenProcessToken(process.Handle, TOKEN_QUERY, out hToken))
{
// Token-Informationen abrufen
if (GetTokenInformation(hToken, TOKEN_INFORMATION_CLASS.TokenElevationType, ref tokenInfo,
tokenInfoLen, out tokenInfoLen))
{
// Elevation-Typ auswerten
switch ((TOKEN_ELEVATION_TYPE)tokenInfo)
{
case TOKEN_ELEVATION_TYPE.TokenElevationTypeDefault:
Console.WriteLine("TokenElevationTypeDefault - Ein Token vorhanden (Standardbenutzer oder
vordefinierter Administrator).");
break;
case TOKEN_ELEVATION_TYPE.TokenElevationTypeFull:
Console.WriteLine("TokenElevationTypeFull - Zwei Token vorhanden. Prozess wird mit
erhhten Rechten ausgefhrt.");
break;
case TOKEN_ELEVATION_TYPE.TokenElevationTypeLimited:
Console.WriteLine("TokenElevationTypeLimited - Zwei Token vorhanden. Prozess wird mit
Standardbenutzerrechten ausgefhrt.");
break;
}
}
}
}
Listing 5.45: Prfen ob ein Prozess ber erhhte Rechte verfgt
Zusammenfassend lsst sich feststellen, dass die Benutzerkontensteuerung nicht nur zur Absicherung
des Systems dient, sondern auch dem Komfort des Benutzers zu Gute kommt. So ist die
Benutzerkontensteuerung auch als Erweiterung und Verbesserung der RunAs-Funktionalitt von
Windows XP zu verstehen. Das begrndet sich darauf, dass jede Anwendung die zur Ausfhrung
erforderlichen Privilegien offen legt und das System die bentigten Rechte automatisch anfordern
kann. Weiterhin kann jede Anwendung zur Ausfhrung in einem anderen Kontext veranlasst werden,
wozu geeignete Optionen im Kontextmen vorhanden sind. Die gravierende Zielsetzung der
Benutzerkontensteuerung basiert jedoch auf der Ausfhrung von Anwendungen im Kontext des
Standardbenutzers, wodurch Sicherheitsrisiken stark minimiert werden. Hierzu ist es allerdings
zwingend erforderlich das Design der Anwendung zu prfen und zu korrigieren.
196
Virtualisierung
Viele Anwendungen legen Informationen in Speicherbereichen des Systems ab, auf die ein
Standardbenutzer nur ber lesenden Zugriff verfgt. Dieses ist sehr hufig historisch bedingt, denn die
programmtechnische Ermittlung der Systemverzeichnisse wurde seit jeher hervorragend untersttzt.
Das Auffinden der benutzerspezifischen Verzeichnisse war hufig nur rudimentr implementiert, so
dass der Weg des geringsten Widerstandes genommen wurde und die Systemverzeichnisse hierfr
verwendet wurden. Wird nun eine solche Anwendung unter Windows Vista oder Windows Server
2008 ausgefhrt, msste die Verwendung erhhter Privilegien sichergestellt werden. Dieses Vorhaben
ist zwar relativ einfach umsetzbar, allerdings verstt es gegen den Grundgedanken der
Benutzerkontensteuerung, da die Rechte des Standardbenutzers zur Ausfhrung einer normalen
Anwendung nicht mehr ausreichend wren. Folglich msste die Anwendung umprogrammiert werden,
was jedoch in vielen Fllen sehr aufwendig und somit sehr kostenintensiv ist, so dass hufig davon
Abstand genommen wird.
Windows Vista und Windows Server 2008 enthalten eine Migrationslsung fr solche Szenarien, die
als Virtualisierung bezeichnet wird. Hierdurch wird es fr einen Standardbenutzer mglich, auch eine
solche Anwendung unter diesen Betriebssystemen auszufhren. Ermglicht wird dieses durch eine
Umleitung der Zugriffe auf das Dateisystem und auf die Systemregistrierung. Soll beispielsweise eine
INI-Datei im Windows-Ordner angelegt werden, wird dieser Zielordner auf einen virtuellen Ordner im
Benutzerprofil umgelenkt. Beim Lesezugriff geschieht dieses in umgekehrter Reihenfolge. Das
Betriebssystem schaut zunchst im virtuellen Verzeichnis nach. Wird dort keine entsprechende Datei
gefunden, wird im Windows-Ordner nachgesehen. Virtualisierung funktioniert fr die folgenden
Ordner:
%ProgramFiles%
%ProgramData%
%SystemRoot%
Soll durch einen Standardbenutzer eine Datei in einem der vorher genannten Ordner angelegt werden,
wird diese Datei physisch unter %LocalAppData%\VirtualStore\<Ordner> gespeichert. Was sich
zunchst sehr interessant anhrt, offenbart bei nherer Betrachtung einige Schwachstellen. Zum
besseren Verstndnis soll hier ein einfaches Szenario dienen, bei dem ein Spiel die Bestenliste (High
Score) in einer Datei ablegt. Diese Anwendung wurde so konstruiert, dass diese Datei im Verzeichnis
%ProgramFiles%\Games gespeichert wird. Hieraus folgt, dass bei einem Standardbenutzer der
Virtualisierungs-Mechanismus des Betriebssystems greift und die Datei physisch unter
%LocalAppData %\VirtualStore\ProgramFile\Games abgelegt wird. Hierbei gilt es zu beachten, dass
sich dieser Ordner im Benutzerprofil befindet, wodurch ein solcher Ordner fr jeden Benutzer angelegt
wird, der das Spiel spielt. Hieraus folgt auch, dass jeder Benutzer eine eigene Bestenliste verwendet.
Dieses ist zwar aus Motivationsgrnden eine hervorragende Umsetzung, allerdings ist dieses nicht im
Sinne des Entwicklers.
Ein sehr hufig anzutreffendes und auch problematisches Szenario liegt in der Verwendung von INIDateien. Vielfach sind diese Dateiarten nur mit einer speziellen Version einer Anwendung kompatibel,
so dass es durch die Virtualisierung hier zu einigen Problemen kommen kann. Auch hier zum besseren
Verstndnis ein Beispiel. Eine Anwendung wird unter Verwendung des Windows Installers installiert,
wobei eine INI-Datei im Windows-Verzeichnis abgelegt wird. Die INI-Datei enthlt allgemeine
Konfigurationseinstellungen, die auch vom Benutzer verndert werden knnen. Bitte beachten Sie,
dass dieses kein Anwendungsfall ist, der den Richtlinien entspricht. Dennoch existieren viele solcher
197
Kapitel 5
Anwendungen, die Konfigurationen auf Maschinen- und Benutzerebene nicht trennen. Der Benutzer
fhrt nun seine Einstellungen aus, die in der INI-Datei abgelegt werden sollen. Da er ber keine
ausreichenden Privilegien verfgt, schlgt die Virtualisierung zu und die Einstellungen werden in einer
INI-Datei im Virtualisierungs-Verzeichnis gespeichert. Existiert diese INI-Datei bereits im
Virtualisierungs-Verzeichnis, werden die entsprechenden Eintrge lediglich modifiziert oder ergnzt.
Falls die Datei noch nicht vorhanden ist, wird zunchst die INI-Datei aus dem Windows-Verzeichnis
kopiert und anschlieend werden die nderungen vorgenommen. Wird nun zu einem spteren
Zeitpunkt eine Aktualisierung der Anwendung ausgefhrt und werden hierbei auch Modifikationen an
der INI-Datei ausgefhrt oder wird diese gegen eine neue Version ausgetauscht, wirkt sich dieses nur
auf die INI-Datei des Windows-Verzeichnisses aus; die virtualisierten Kopien sind hiervon nicht
betroffen. Werden im Rahmen dieser Produktaktualisierung funktionsrelevante nderungen an der
INI-Datei ausgefhrt, werden diese nicht beachtet, da die private Kopie verwendet wird, die ber diese
Einstellungen nicht verfgt. Dieses kann dazu fhren, dass die Anwendung nicht mehr funktionsfhig
ist.
Es sollte erkennbar sein, dass durch die Virtualisierung einige Probleme auftreten knnen, die vielfach
auf ein unglckliches und nicht den Richtlinien entsprechendes Anwendungsdesign zurckzufhren
sind. Eine mgliche Abhilfe knnte in der Synchronisierung der unterschiedlichen
Konfigurationseinstellungen liegen, wobei das Microsoft Active Setup (Siehe Anhang G) mitunter
helfen kann. Die Grundvoraussetzung fr alle Lsungsszenarien liegt natrlich zunchst darin,
herauszufinden, wo die Dateien physisch abgelegt wurden. Der Windows-Explorer enthlt zum
besseren Auffinden dieser virtuell abgelegten Dateien eine Erweiterung. Wird einer der oben
erwhnten Ordner im Windows-Explorer ausgewhlt und enthlt dieser Ordner virtuelle Dateien,
erscheint in der Symbolleiste die Schaltflche Kompatibilittsdateien. Eine Aktivierung dieser
Schaltflche wechselt zu dem entsprechenden virtuellen Verzeichnis.
Virtualisierung funktioniert nicht fr alle Dateitypen. So sind ausfhrbare Dateien, die u.a. durch die
Dateiendungen .exe, .bat, .cmd, .scr und .vbs charakterisiert sind, von der Virtualisierung
ausgeschlossen. Wre das nicht der Fall, knnte jedes selbstaktualisierende Programm eine private
Version anlegen, die fr das eigentliche Installationsprogramm nicht sichtbar wre. Hierdurch wre
eine geordnete Verwaltung der einzelnen Produktversionen nicht mehr gewhrleistet.
Ein hnliches Verhalten wird im Rahmen der Virtualisierung fr Teile der Systemregistrierung
untersttzt. Soll durch einen Standardbenutzer ein Wert unter HKEY_LOCAL_MACHINE\Software
angelegt
werden,
wird
dieser
Wert
tatschlich
unter
HKEY_CURRENT_USER\Classes\VirtualStore\Machine\Software angelegt. Ausgenommen hiervon
sind die folgenden fest definierten Registrierungsschlssel:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT
HKEY_LOCAL_MACHINE\Software\Classes
Im Weiteren knnen Registrierungsschlssel so markiert werden, dass sie von der Virtualisierung
ausgenommen werden. Zur berprfung, ob ein Registrierungsschlssel so gekennzeichnet ist, eignet
sich das Betriebssystem-Tool reg.exe. Durch den folgenden Aufruf werden Attribute fr einen
spezifischen Schlssel ausgegeben.
reg.exe flags hklm\software\demo
198
Es ist natrlich auch mglich entsprechende Attribute einem Schlssel zuzuweisen. Um

HKEY_LOCAL_MACHINE\Software\Demo von der Virtualisierung auszuschlieen, ist der folgende
Befehl zu verwenden:
reg.exe flags hklm\software\demo set dont_virtualize
Bei der Virtualisierung ist darauf zu achten, dass sie nicht fr jede Anwendung oder Ttigkeit
untersttzt wird. Die nachfolgenden Merkmale verhindern die Virtualisierung:
Die Anwendung wird mit vollstndigen Privilegien ausgefhrt.
Es handelt sich um eine 64-Bit Anwendung.
Fr die Anwendung wurde eine Ausfhrungsebene festgelegt.
Die zu modifizierende Ressource unterliegt dem Windows-Ressourcenschutz (Windows Resource
Protection).
Beim Schreiben von Eintrgen der Systemregistrierung ist der Schlssel als Do Not Virtualize
gekennzeichnet werden, wie es bei HKLM\Software\Classes der Fall ist.
Um festzustellen, ob die Zugriffe einer Anwendung virtualisiert werden, gengt eine Betrachtung im
Windows Task-Manager. Hierzu ist die Spalte Virtualisierung der Prozessdarstellung hinzuzufgen. In
dieser Spalte werden letztlich alle Anwendungen gekennzeichnet, die Virtualisierung untersttzen, wie
auch Abbildung 5.40 zeigt. Es besteht die Mglichkeit die Virtualisierung fr einen bereits gestarteten
Prozess nachtrglich zu aktivieren oder auch zu deaktivieren. Diese Funktionalitt kann ber den
Menpunkt Virtualisierung des Kontextmens jedes Prozesses umgesetzt werden.
Abbildung 5.40: Windows Task Manager zeigt die virtualisierten Prozesse an
199
Kapitel 5
Vielfach ist es wnschenswert programmtechnisch zu ermitteln, ob ein Prozess virtualisiert ausgefhrt

wird oder nicht. Auch zu diesem Zweck kann die Windows-Funktion GetTokenInformation()
verwendet werden wie Listing 5.46 zeigt.
internal static void CheckVirtualization(Process process)
{
// Deklarationen
int tokenInfoLen = sizeof(int);
int tokenInfo = 0;
bool virtualized = false;
IntPtr hToken;
// Prozess-Token ffnen
if (OpenProcessToken(process.Handle, TOKEN_QUERY, out hToken))
{
if (GetTokenInformation(hToken, TOKEN_INFORMATION_CLASS.TokenVirtualizationEnabled,
ref tokenInfo,
tokenInfoLen,
out tokenInfoLen))
{
virtualized = (tokenInfo != 0);
}
}
// Ausgabe
Console.WriteLine("Prozess ist virtualisiert: " + virtualized.ToString());
}
Listing 5.46: Prfung ob ein Prozess virtualisiert ausgefhrt wird
Es ist erkennbar, dass Virtualisierung viele Vorteile bietet aber auch einige Problempunkte offenbart.
An dieser Stelle kann nur individuell entschieden werden, ob Virtualisierung in der jeweiligen
Umgebung geeignet erscheint oder nicht. Virtualisierung kann systemweit durch die Richtlinie
Benutzerkontensteuerung: Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte
virtualisieren (EnableVirtualization) deaktiviert werden. Wer jedoch auf die VirtualisierungsFunktionalitt setzt, sollte immer bercksichtigen, dass Virtualisierung ausschlielich als
Migrationsmittel zu verstehen ist. Dieses wird deutlich, da Virtualisierung fr 64-Bit Anwendungen
nicht funktioniert und auch fr Anwendungen nicht, die ber eine definierte Ausfhrungsebene
verfgen. Hier wird davon ausgegangen, dass es im 64-Bit Bereich nur sehr wenige Altlasten gibt, so
dass Migrationsoptionen nur sehr selten bentigt werden. Verfgt eine Anwendung bereits ber eine
konfigurierte Ausfhrungsebene wird davon ausgegangen, dass diese Anwendung schon auf die
Betriebssysteme Windows Vista und Windows Server 2008 abgestimmt wurde. Dieses wird durch das
Schema der Abbildung 5.41 besonders deutlich.
200
Abbildung 5.41: Virtualisierung beim Zugriff auf das Dateisystem und die Systemregistrierung

Die Verwendung niedrig privilegierter Prozesse fr alle Standardaufgaben ist nicht neu in Windows
Vista und Windows Server 2008, sondern war bereits in frheren Windows-Betriebssystemen in
unterschiedlichen Ausprgungen zu finden. Diese Mglichkeit der Systemabsicherung wird hufig
auch als Limited User Account, Least-privileged User Account oder Least User Access bezeichnet; als
Abkrzung ist meistens LUA zu finden. Die bereits dargestellte Benutzerkontensteuerung ist ein
Mechanismus zur Steigerung der Effizienz und des Benutzerkomforts in LUA-Umgebungen. Die
Zielsetzung wurde bereits angesprochen. Anwendungen werden mit den Rechten eines
Standardbenutzers ausgefhrt; auf die Verwendung administrativer Privilegien wird weitgehend
verzichtet wodurch die Systemzugriffe durch nicht autorisierte Software stark reduziert werden. Das
Resultat ist ein abgesichertes und stabiles System. Was fr die Anwendungsebene gilt, kann natrlich
auch auf die Installations-Ebene abgeleitet werden. Auch hierbei sollten Systemzugriffe reduziert
werden, wodurch Installationsprogramme zwangslufig mit der Benutzerkontensteuerung interagieren
mssen. Bevor diese Szenarien erlutert werden, ist es angebracht zunchst eine Ebene tiefer zu
beginnen und die Installationen in LUA-Umgebungen zu skizzieren.
In den meisten Fllen knnen Installationen durch einen Standardbenutzer nicht ausgefhrt werden, da
berwiegend auf das Verzeichnis %ProgramFiles% und den Registrierungsschlssel
HKEY_LOCAL_MACHINE schreibend zugegriffen werden muss. Dem Standardbenutzer fehlen
201
Kapitel 5
allerdings diese Privilegien, wodurch eine eventuell gestartet Installation fehlschlgt. Dennoch ist ein
solches Modell umsetzbar, denn der Windows Installer untersttzt seit jeher die Installation in
geschtzten Umgebungen. Hierunter sind Szenarien zu verstehen, in denen Installationen von einem
Standardbenutzer ausgefhrt werden, obwohl administrative Privilegien erforderlich wren. Dieses
wird mglich, da der Server-Prozess des Windows Installers mit den Rechten des lokalen
Systemkontos ausgefhrt wird und somit auf nahezu alle Bereiche des Systems schreibend zugreifen
kann. Im Normalfall werden die erforderlichen Aktionen jedoch nicht mit den Privilegien des
Systemkontos ausgefhrt, vielmehr findet stattdessen ein Identittswechsel auf den aktuellen Benutzer
statt, dessen Privilegien dann fr die Installationsaufgaben verwendet werden. Hierdurch wird zunchst
sichergestellt, dass ein Benutzer nur die Aktionen ausfhren kann, fr die er auch ermchtigt wurde. Es
wird jedoch auch deutlich, dass die Mglichkeit der Verwendung der hheren Rechte grundstzlich
existiert. Eine solche Verwendung ist nicht so einfach mglich, sondern setzt entsprechende
Autorisierungen voraus, damit die Einordnung in die Sicherheits-Infrastruktur des Betriebssystems
gewhrleistet werden kann. Einfach ausgedrckt muss ein Administrator einen Benutzer autorisieren
bei der Installation hhere Privilegien zu verwenden. Entscheidend ist hierbei, dass die Autorisierung
von einem privilegierten Benutzer durchgefhrt wird und nicht durch das Installationspaket selbst
erfolgen kann.
Wichtig Beginn
Ein Installationspaket kann sich nicht selbst fr die Verwendung erhhter Rechte autorisieren.
Wichtig Ende
Erfolgt eine Autorisierung, so dass die Installation von einem Standardbenutzer ausgefhrt werden
kann, werden die folgenden Privilegien im Rahmen des Installationsprozesses verwendet:
Alle Aktionen der Tabelle InstallUISequence werden mit den Privilegien des Benutzers ausgefhrt,
der die Installation startet.
Alle
benutzerdefinierten
Aktionen
der
Tabelle
InstallExecuteSequence
die
als
msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate (3072) gekennzeichnet
sind, werden mit den Privilegien des lokalen Systemkontos ausgefhrt.
Alle anderen benutzerdefinierten Aktionen der Tabelle InstallExecuteSequence werden im Kontext
des Benutzers ausgefhrt.
Alle lokalen Zugriffe auf das Dateisystem und die Systemregistrierung werden mit den Rechten des
lokalen Systemkontos ausgefhrt.
Alle Netzwerkzugriffe erfolgen mit den Privilegien des Benutzers.
Die technische Umsetzung der Autorisierung ist recht einfach. Ein Administrator registriert das zu
installierende Produkt ohne es physisch zu installieren. Hierdurch werden nur rudimentre Elemente
des Produktes auf das System gebracht; wesentlicher ist hierbei jedoch die Autorisierung zur
Verwendung erhhter Privilegien, die im Repository des Windows Installers abgelegt wird. Wird die
Installation fortan von einem Standardbenutzer durchgefhrt, werden fr die Installationsaktionen
erhhte Rechte verwendet, falls dieses erforderlich ist. Hierzu werden fr die lokalen Aktivitten die
Privilegien des lokalen Systemkontos verwendet; Netzwerkzugriffe werden hingegen im Kontext des
aktuellen Benutzers ausgefhrt. Es stellt sich noch die Frage, wie die Autorisierung durch einen
Administrator praktisch erfolgen kann. Hierzu muss zunchst zwischen dem Privatanwender und dem
Firmenbenutzer (Corporate User) unterschieden werden, oder technisch ausgedrckt muss zwischen
der Verwendung in einer Domne und in einer Arbeitsgruppe unterschieden werden. Im DomnenUmfeld kann die Autorisierung durch jeden Domnen-Administrator erfolgen. Der manuelle Ansatz
202
fr solche Szenarien erfordert die Remote-Ausfhrung des Windows Installers unter Verwendung
geeigneter Tools auf dem jeweiligen Rechner, wodurch das Produkt angekndigt werden muss, wie es
mit der folgenden Befehlszeile mglich ist:
msiexec.exe /jm <Pfad zum Installationspaket>
Ein hervorragendes Tool, mit dem die Produktankndigung remote durchgefhrt werden kann ist
psexec.exe, das ber die Seite von Windows Sysinternals bereitgestellt wird. Eine entsprechende
Verwendung des Tools knnte wie folgt erfolgen:
psexec.exe \\Eagle -s -i -d msiexec.exe /jm "\\Eagle\Files\demo.msi"
Ein anderer Lsungsansatz verwendet Windows Management Instrumentation (WMI) wie das
folgende Code-Fragment darstellt. Es gilt es zu beachten, dass die Windows-Firewall standardmig
WMI blockiert, so dass hierfr eine Ausnahme erstellt werden muss.
public static void AdvertisePackage(string domainName,
string computerName,
string userName,
string loginPassword,
string msiFilePath,
string installOptions,
bool allUsers)
{
ManagementScope managementScope = null;
// Optionen fr den Verbindung
ConnectionOptions connectionOption = new ConnectionOptions();
connectionOption.Impersonation = ImpersonationLevel.Impersonate;
connectionOption.Authentication = AuthenticationLevel.PacketPrivacy;
connectionOption.Authority = "ntlmdomain:" + domainName;
// Prfen ob die Installation lokal oder Remote erfolgen soll
if (computerName.Equals(Environment.MachineName, StringComparison.InvariantCultureIgnoreCase))
{
managementScope = new ManagementScope(@"\ROOT\CIMV2", connectionOption);
}
else
{
connectionOption.Username = userName;
connectionOption.Password = loginPassword;
// Scope definieren
managementScope = new ManagementScope(string.Format(@"\\{0}\root\cimv2",
computerName), connectionOption);
managementScope.Options.Impersonation = ImpersonationLevel.Impersonate;
}
// Verbinden
managementScope.Connect();
203
Kapitel 5
// Installatonen werden ber Win32_Product gesteuert

ManagementPath managementPath = new ManagementPath("Win32_Product");
ManagementClass managementClass = new ManagementClass(managementScope, managementPath, null);
// Parameter verwenden
object[] parameters = { msiFilePath, installOptions, allUsers };
// Funktion aufrufen
UInt32 returnValue = (UInt32)managementClass.InvokeMethod("Advertise", parameters);
if (returnValue > 0)
throw new InstallerException(returnValue);
}
Listing 5.47: Produktankndigung auf einem anderen Computer mit WMI
Die gerade skizzierten Vorgehensweisen zeigen einfache Mglichkeiten zur Lsung der Anforderung.
Allerdings sind diese Lsungsanstze in greren Netzwerkumgebungen nicht praktikabel, da der
Komfort und die Verwaltung nur uerst gering zu bezeichnen sind. Wesentlich komfortabler und
einfacher gestaltet sich Softwareverteilung ber die Gruppenrichtlinien des Active Directories. Im
Rahmen dieser Softwareverteilungs-Methode wird zwischen dem Zuweisen und dem Verffentlichen
von Installationspaketen unterschieden. Das Zuweisen von Software entspricht hierbei der klassischen
Produktankndigung des Windows Installers, also die Registrierung von Schnittstellen ohne dabei das
Produkt physisch zu installieren. Die Zuweisung kann sowohl fr den Computer als auch fr den
Benutzer erfolgen. Wird die Software einem Benutzer zugewiesen, wird sie auf jedem Computer
installiert, an dem sich der Benutzer anmeldet. Die physische Installation erfolgt nicht automatisch,
sondern erst wenn der Benutzer die Software startet. Wird die Software einem Computer zugewiesen,
wird diese beim nchsten Start des Computers automatisch installiert. Die Verffentlichung erfolgt
immer benutzerbezogen. Hierbei wird die Software nach der nchsten Anmeldung des Benutzers in der
Systemsteuerung zur Installation angeboten. Hieraus wird deutlich, dass spezielle Implementierungen
im Active Directory vorhanden sind, die auf die Softwareverteilung abzielen.
Wesentlich komplizierter und unkomfortabler sind solche Szenarien in Arbeitsgruppen und auf
Einzelplatzrechnern umzusetzen. Problematisch ist hierbei, dass es keine bergeordneten
Administratoren gibt, die auf alle Computer zugreifen knnen. Es ist somit der lokale Administrator
gefordert, die Registrierung der Produkte nach den oben skizzierten Vorgehensweisen ber die
Befehlszeile, Windows Management Instrumentation oder sonstige Programmiertechniken
durchzufhren. Hufig stellt sich hier natrlich die Frage, warum der Administrator nicht gleich die
Installation ausfhrt, wenn er sich eh auf dem System lokal anmelden muss. Die Frage ist legitim und
in vielen Fllen auch der praktikabelste Ansatz. Soll eine Anwendung allen Benutzern zugnglich
gemacht werden, warum denn nicht diesen Weg beschreiten. Aber soll die Anwendung nur bestimmten
Benutzern zugnglich gemacht werden, also eine Benutzerinstallation durchgefhrt werden, ist die
Vorabregistrierung oder Produktankndigung der geeignete Weg. An dieser Stelle kommt natrlich
auch die Benutzerkontensteuerung von Windows Vista und Windows Server 2008 als komfortable
Umsetzung des RunAs-Befehls zur Verwendung, aber dazu spter mehr.
Verwaltete und privilegierte Installationen

Ich mchte an dieser Stelle noch auf die Installation mit erhhten Rechten eingehen oder besser gesagt
auf die Anforderung erhhter Rechte in unterschiedlichen Installationsszenarien. Unter Windows Vista
und Windows Server 2008 wird die Anforderung der Rechte bei aktivierter Benutzerkontensteuerung
204
besonders deutlich. Bei der Installation einer Anwendung erscheint der Dialog mit dem die
Verwendung erhhter Privilegien besttigt werden muss; identisches gilt fr die Deinstallation. Aber
was ist bei der Reparatur oder der Nachinstallation von Features, warum erscheint der
Besttigungsdialog hier nicht, oder erscheint er doch? Ich denke diese Frage ist uerst wichtig wenn
es um das Design von Installationspaketen fr Windows Vista und Windows Server 2008 geht. Aber
auch hierbei zunchst zurck zum Anfang und einigen grundlegenden Aspekten.
Der Lsungsansatz fr die Frage ist einfach und auch nicht verwunderlich. Anwendungen die fr den
Computer (per-machine) oder als verwaltete Benutzerinstallation (per-user managed) auf das System
gebracht werden, verwenden automatisch erhhte Privilegien bei nachgeordneten Installationen. Dieser
Mechanismus, der als Sticky Elevation bezeichnet wird, sorgt dafr, dass bei der Reparatur oder
Nachinstallation von Features die Verwendung erhhter Rechte unter Windows Vista und Windows
Server 2008 nicht explizit besttigt werden muss. Oder einfach ausgedrckt werden alle
untergeordneten Installationen automatisch mit erhhten Privilegien ausgefhrt. Wird also ein Produkt
in diesem Kontext registriert, verwendet es immer erhhte Privilegien. Problematisch ist hierbei die
Deinstallationsoption. Wie bereits erlutert, muss die Deinstallation des Produktes durch den UACDialog explizit besttigt werden. Wird jedoch der Wartungsmodus ausgefhrt, erfolgt die Sticky
Elevation. Wird nun im Wartungsmodus die Option zur Deinstallation des Produktes gewhlt, fhrt
dieses zum Fehler, da die erforderlichen Rechte nicht gegeben sind. Es ist somit im Rahmen der
Wartung nur mglich, einige Features zu entfernen, das Entfernen aller Features (REMOVE=ALL),
also die Produktdeinstallation, schlgt fehl.
Es existiert noch eine weitere Mglichkeit die Installation mit erhhten Rechten durch einen
Standardbenutzer durchfhren zu lassen, wozu die Systemrichtlinie Immer mit erhhten Rechten
installieren (AlwaysInstallElevated) verwendet werden kann. Wird diese Richtline in der
Benutzerkonfiguration und der Computerkonfiguration auf True gesetzt, werden alle Installationen
unter Verwendung erhhter Rechte ausgefhrt.
Achtung Beginn
Die Verwendung der Systemrichtlinie AlwaysInstallElevated stellt ein enormes Sicherheitsrisiko dar,
da alle Installationen schreibend auf das System zugreifen und es somit potentiell gefhrden knnen.
Bei gesetzter Systemrichtlinie wird unter Windows Vista und Windows Server 2008 kein
Besttigungsdialog angezeigt.
Achtung Ende
In der Praxis wird diese Richtlinie dennoch hufig verwendet, jedoch nicht permanent. Soll heien, die
Richtlinie wird aktiviert, das Produkt wird installiert oder angekndigt und anschlieend wird die
Richtlinie wieder deaktiviert. In diesem Szenario gilt besonders zu beachten, dass keine Sticky
Elevation durchgefhrt wird, wie vorhergehend beschrieben. Die Richtlinie AlwaysInstallElevated
wirkt sich nur auf die aktuelle Installationstransaktion aus. Das bedeutet, dass das Installationsszenario
umsetzbar wre, aber untergeordnete Installationen wie beispielsweise die Reparatur wahrscheinlich
nicht. Dieses begrndet sich darauf, dass zum Zeitpunkt der Reparatur die Richtlinie nicht aktiv ist,
wodurch keine erhhten Rechte angefordert werden. Somit erfolgt die Reparatur im Kontext des
aktuellen Benutzers. Sind dessen Rechte fr die jeweilige Aktion nicht ausreichend kommt es
zwangslufig zum Installationsfehler.
Es ist erkennbar, dass die mglichen Szenarien oder Verhaltensmuster durchaus zu abweichenden
Ergebnissen fhren knnen. Dennoch ist der unterliegende Algorithmus sehr einfach und konkret
gehalten. Nur verwaltete Anwendungen (managed applications) verwenden Sticky Elevation.
Verwaltete Anwendungen sind Installationen die unter der Kontrolle des Systemadministrators
205
Kapitel 5
durchgefhrt wurden; dieses sind:

Alle Maschineninstallationen (per-machine): Dies sind alle Installationen bei denen die
Eigenschaft ALLUSERS final auf den Wert 1 gesetzt wurde.
Bestimmte
Benutzerinstallationen
(per-user
managed):
Hierunter
fallen
alle
Benutzerinstallationen, die durch einen speziellen Installationsdienst wie ber das Active Directory
installiert wurden. Technisch gesehen muss es sich beim dem Installationsdienst um einen lokalen
Systemprozess handeln, der MsiAdvertiseScript() aufruft, nachdem ein Identittswechsel auf den
entsprechenden Benutzer stattgefunden hat.
Im Gegensatz zu der verwalteten Anwendung wird eine nicht verwaltete Anwendung unter der
Kontrolle des Standardbenutzers installiert. Eine nicht verwaltete Installation ist auch dadurch
gekennzeichnet, dass smtliche Informationen im Benutzerprofil abgelegt werden, welches natrlich
auch serverseitig (Roaming Profile) gespeichert werden kann. Die Installation von nicht verwalteten
Anwendungen kann durch die Systemrichtlinie Windows Installer deaktivieren (DisableMSI)
verhindert werden. Hierzu ist diese Richtlinie auf den Wert 1 zu setzen. Mitunter kann es sein, dass
die Installation von nicht verwalteten Anwendungen bereits standardmig deaktiviert wurde, da diese
Standardeinstellung vom Betriebssystem abhngig ist:
Windows XP und Windows Vista: Die Installation von verwalteten und nicht verwalteten
Anwendungen ist standardmig mglich.
Windows Server 2003 und Windows Server 2008: Die Installation von nicht verwalteten
Anwendungen ist standardmig nicht mglich. Es ist nur mglich verwaltete Anwendungen zu
installieren.
Hufig wird im Zusammenhang mit verwalteten Installationen auch von privilegierten (elevated)
Installationen gesprochen, wobei dieser Begriff synonym verwendet wird. Dieses ist jedoch nicht
richtig, denn es handelt sich hierbei um unterschiedliche Konzepte im Umfeld des Windows Installers.
Der Begriff der verwalteten Installation wurde ja bereits erlutert; dieser Begriff bezieht sich immer
auf den finalen Status des Produktes. Dem entgegen stehen die Operationen oder Aktionen, die im
Rahmen der Installation ausgefhrt werden. Diese Aktionen knnen entweder privilegiert oder nicht
privilegiert ausgefhrt werden. Eine privilegierte Aktion wird vom Windows Installer durchgefhrt um
nderungen am System vorzunehmen, wozu der Standardbenutzer normalerweise nicht berechtigt
wre.
Hieraus kann abgeleitet werden, dass die Installationsoperationen einer verwalteten Installation immer
privilegiert ausgefhrt werden. Aber die gegenstzliche Folgerung kann natrlich nicht angestellt
werden. Denn privilegiert ausgefhrte Installationsoperationen resultieren nicht immer in einer
verwalteten Installation. Eine Benutzerinstallation die durch einen Administrator ausgefhrt wird
resultiert in einer nicht verwalteten Anwendung, obwohl die Installationsoperationen privilegiert
ausgefhrt werden. Zusammenfassend lassen sich privilegierte Installationen (per-machine und peruser managed) wie folgt skizzieren:
Der Dienst verwendet die Privilegien des lokalen Systemkontos fr alle Installationsoperationen
wie dem Kopieren der Dateien und dem schreiben in die Systemregistrierung.
Der Dienst fhrt einen Identittswechsel auf den Benutzer aus um mit dessen Privilegien auf
Netzwerk-Ressourcen zuzugreifen.
Benutzerdefinierte Aktionen werden im Kontext des Benutzers ausgefhrt, wenn sie nicht durch
das Attribut msidbCustomActionTypeNoImpersonate gekennzeichnet sind.
Benutzerdefinierte Aktionen werden im Kontext des lokalen Systemkontos ausgefhrt, wenn sie
206
mit dem Attribut msidbCustomActionTypeNoImpersonate versehen sind.

Dem gegenber stehen die nicht privilegierten Installationen (per-user unmanaged), die wie folgt
klassifiziert werden knnen:
Der Dienst fhrt einen Identittswechsel auf den Benutzer aus um mit dessen Privilegien alle
Installationsoperationen durchzufhren.
Der Dienst verwendet die Privilegien des lokalen Systemkontos um die Installationsspezifischen
Konfigurationsdaten im Windows Installer-Repository anzulegen.
Benutzerdefinierte Aktionen werden unabhngig von der Kennzeichnung immer im Kontext des
Benutzers ausgefhrt.
Es ist erkennbar, dass sich die gerade dargestellten Verhaltensmuster durchaus auf den
Installationserfolg auswirken knnen. Wird die Eigenschaft ALLUSERS beispielsweise auf den Wert
1 gesetzt und wird die Installation durch einen Standardbenutzer ausgefhrt, kommt es zwangslufig
zum Installationsfehler, da die erforderlichen Privilegien nicht gegeben sind. Vielfach sind solche
Probleme im produktiven Umfeld anzutreffen, wodurch die Fehlersuche erschwert wird. Hilfe
verspricht hier das Installationsprotokoll, denn es gibt Auskunft darber was bei der Installation
tatschlich passiert und wie Dinge ausgefhrt werden. Das bedeutet auch, dass anhand des
Installationsprotokolls festgestellt werden kann, ob es sich um eine verwaltete Installation handelt und
ob die Aktionen privilegiert ausgefhrt werden.
Erstinstallation fr den Computer:
MSI (s) (4C:68) [17:30:56:187]: Product installation will be elevated because user is admin and product
is being installed per-machine.
MSI (s) (4C:68) [17:30:56:187]: Running product '{7BF40BDA-E554-4949-8A6E-10297BD30BB6}' with elevated
privileges: Product is assigned.
Reparatur einer Maschineninstallation:

MSI (s) (4C:1C) [17:31:47:515]:
LocalSystem owns the publish
MSI (s) (4C:1C) [17:31:47:515]:
MSI (s) (4C:1C) [17:31:47:515]:
elevated privileges: Product
Product {7BF40BDA-E554-4949-8A6E-10297BD30BB6} is admin assigned:

key.
Product {7BF40BDA-E554-4949-8A6E-10297BD30BB6} is managed.
Running product '{7BF40BDA-E554-4949-8A6E-10297BD30BB6}' with
is assigned.
Erstinstallation fr den aktuellen Benutzer:

MSI (s) (4C:90) [17:27:00:058]: Running product '{7BF40BDA-E554-4949-8A6E-10297BD30BB6}' with
user privileges: It's not assigned.
Reparatur einer Benutzerinstallation:

MSI (s) (4C:60) [17:27:50:608]: Product {7BF40BDA-E554-4949-8A6E-10297BD30BB6} is not managed.
MSI (s) (4C:60) [17:27:50:608]: Running product '{7BF40BDA-E554-4949-8A6E-10297BD30BB6}' with
user privileges:It's not assigned.
207
Kapitel 5
Installationen unter Windows Vista und

Windows Server 2008
Windows Vista und Windows Server 2008 enthalten standardmig den Windows Installer in der
Version 4.0. Hierbei handelt es sich um eine speziell fr diese Betriebssysteme optimierte und
erweiterte Variante des Windows Installers. Die neuen Funktionalitten dieser Version sind nur unter
Windows Vista und Windows Server 2008 nutzbar, wodurch der Windows Installer 4.0 fr andere
Plattformen nicht zur Verfgung steht. Mit dem Erscheinen des Windows Installers 4.5 wurde die
Diskrepanz der unterschiedlichen Installer-Versionen fr unterschiedliche Plattformen beseitigt. Die
Version 4.5 des Windows Installers ist sowohl fr Windows Vista und Windows Server 2008 als auch
fr Windows XP und Windows Server 2003 verfgbar. Es ist allerdings weiterhin zu differenzieren,
denn nur die Windows Vista-Variante enthlt die Spezialimplementierungen fr diese
Betriebssystemgeneration, wie in einem spteren Kapitel des Buches noch erlutert wird. An dieser
Stelle, nmlich bei Installationsprozessen unter Verwendung der Benutzerkontensteuerung ist es
unerheblich ob der Windows Installer 4.0 oder 4.5 verwendet wird.
Zunchst sei anzumerken, dass ltere Installationspakete, also Pakete die fr eine ltere Version des
Windows Installers gebaut wurden, kompatibel mit der aktuellen Windows Installer-Version sind.
Weiterhin ist die Wahrscheinlichkeit sehr hoch, dass diese auch unter Windows Vista und Windows
Server 2008 fehlerfrei ausgefhrt werden. Das hat in erster Linie damit zu tun, dass bei solchen
Paketen administrative Privilegien fr die Installation standardmig vorausgesetzt werden.
Hinweis Beginn
Anwendungen werden standardmig als UAC-Kompatibel interpretiert, wodurch keine

administrativen Privilegien angefordert werden. Bei Windows Installer-Paketen ist dieses umgekehrt;
hierbei wird standardmig davon ausgegangen, dass administrative Privilegien erforderlich sind.
Hinweis Ende
Interaktion mit der Benutzerkontensteuerung

Eine Windows Installer basierte Installation wird durch den Client- und den Server-Prozess realisiert.
Einfach ausgedrckt ist der Client-Prozess fr die Interaktion mit dem Benutzer zustndig, whrend
der Server-Prozess die eigentlichen Installationsttigkeiten ausfhrt. Die Aktionen des ClientProzesses werden immer mit den Privilegien des Standardbenutzers ausgefhrt. Wird die Installation
durch eine setup.exe gestartet, findet die Freigabe der erhhten Privilegien bereits vor der eigentlichen
Installation statt, so dass der Client-Prozess bereits den vollstndigen Zugriffstoken verwendet. Dieses
hat jedoch streng genommen nichts mit dem Windows Installer zu tun und soll an dieser Stelle
zunchst nicht weiter betrachtet werden. Beim Wechsel vom Client- zum Server-Prozess findet nun die
Interaktion mit der UAC-Infrastruktur statt. Das bedeutet, dass an dieser Stelle unter Verwendung des
Application Information Service (AIS) zur Besttigung der vollstndigen Privilegien aufgefordert wird,
falls es sich nicht um ein Standardbenutzer-Paket handelt. Bei einem Standardbenutzer-Paket handelt
es sich um ein Installationspaket, das mit den Rechten eines Standardbenutzers installiert werden kann.
Visuell betrachtet findet der Wechsel zum Serverprozess nach Besttigung der Schaltflche
Fertigstellen des letzten Dialogs der Dialogsequenz statt. An dieser Stelle stellt sich nun die Frage, bei
welcher Installationsform der UAC-Besttigungsdialog denn tatschlich angezeigt wird und welches
Erscheinungsbild er aufweist.
208
Kommen wir zunchst zur Anzeige des Dialogs. Die Frage die hierzu gestellt wurde, ist nicht so
einfach zu beantworten. Das liegt darin begrndet, dass eine Vielzahl von Rahmenparametern zu
bercksichtigen sind. Die genaue Ablaufsteuerung fr die Installation eines Produktes ist in
Abbildung 5.42: Anzeige des UAC-Dialogs bei der Installation eines Produktes
Es ist ersichtlich, dass zunchst geprft wird, ob es sich um eine Erst- oder eine Folgeinstallation
handelt. Handelt es sich um eine Erstinstallation, prft der Windows Installer ob das Produkt bereits
zur Verwendung mit erhhten Rechten angekndigt wurde. Falls dieses zutrifft wird kein Dialog
angezeigt und die physische Installation des Produktes erfolgt. Im anderen Fall wird geprft ob die
Installation bereits mit vollstndigen Privilegien gestartet wurde, wie das beispielsweise beim Aufruf
durch eine setup.exe der Fall wre. Ist dieses zutreffend wird kein Dialog angezeigt und die Installation
wird ausgefhrt. Falls keine vollstndigen Privilegien vorhanden sind, wird nun geprft, ob es sich um
ein Standardbenutzer-Paket handelt, also ob es sich um ein Paket handelt, dass nur das aktuelle
Benutzerprofil beeinflusst. In diesem Fall ist eine Anzeige des Dialogs nicht erforderlich, da
Standardbenutzerrechte fr die Installation ausreichend sind. Im nchsten Schritt wird geprft ob die
Benutzerkontensteuerung oder die relevanten Teile davon aktiviert sind. Falls nicht, ist die Anzeige
des Dialogs natrlich nicht erforderlich. Als letztes wird die Anzeigestufe der Benutzeroberflche
(UILevel) geprft. Falls die Installation nicht unbeaufsichtigt (silent) ausgefhrt wird, wird der
Besttigungsdialog angezeigt, ansonsten erscheint der Dialog nicht. Hieraus folgt dass bei einer
unbeaufsichtigten Ausfhrung die Besttigung der erhhten Privilegien vor dem Aufruf des Installers
erfolgen muss. Eine einfache programmtechnische Umsetzung zeigt Listing 5.48.
public void InstallPrivileged()
{
// Argumente konstruieren
string installPackage = System.IO.Path.Combine(Application.StartupPath, "demo.msi");
string arguments = string.Format("/i \"{0}\" /qn+", installPackage);
209
Kapitel 5
// Startinformationen fr den Prozess konstruieren

ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "msiexec.exe";
startInfo.Arguments = arguments;
// Das Verb 'runas' zuweisen. Hierdurch werden fr den Prozess
// vollstndige Privilegien angefordert
startInfo.Verb = "runas";
// Prozess starten
Process.Start(startInfo);
}
Listing 5.48: Anforderung vollstndiger Privilegien durch die Klasse Process
Handelt es sich um keine Erstinstallation, also um eine Folge- oder Wartungsinstallation wird bei einer
verwalteten Installation (per-machine und per-user managed) die Anzeige des Besttigungsdialogs
unterdrckt. Ansonsten wird mit der Prfung der administrativen Privilegien fortgefahren. Die
Deinstallation des Produktes wurde in dem Schema nicht bercksichtigt. Hierbei wird zunchst vom
Windows Installer geprft ob vollstndige Privilegien fr die Deinstallation erforderlich sind, wie das
beim Entfernen einer Maschineninstallation der Fall wre. Im nchsten Schritt wird geprft, ob bereits
administrative Berechtigungen vorhanden sind. In diesem Fall wird die Deinstallation ohne erneute
Anzeige des Dialogs ausgefhrt. Im anderen Fall erscheint natrlich der Dialog, damit die
Verwendung der vollstndigen Privilegien besttigt werden kann.
Was an dieser Stelle noch fehlt ist die Frage nach der Darstellung und der Farbgebung des UACBesttigungsdialogs. Wie bereits zu Beginn dieses Kapitels erlutert, hngt die Illustration von
diversen Faktoren ab. Relevant fr die Installation ist zunchst, ob das Installationspaket digital
signiert wurde. Falls das nicht der Fall ist, erscheint der Dialog mit einem orangenen Farbbalken, der
den Hinweis Ein nicht identifiziertes Programm mchte auf den Computer zugreifen trgt. Wurde
das
Installationspaket
hingegen
mit
dem
Zertifikat
einer
vertrauenswrdigen
Stammzertifizierungsstelle (trusted root authority) digital signiert, wird der Dialog durch einen grauen
Balken mit dem Hinweis Zur Fortsetzung des Programms ist Ihre Zustimmung erforderlich
gekennzeichnet. In diesem Fall werden noch zustzliche Metainformationen des Paketes, wie die
Eigenschaften Manufacturer, ProductVersion und ProductLanguage, angezeigt.
Eine etwas unglckliche Implementierung zeigt sich hingegen bei der Deinstallation. Auch hier wird
der Besttigungsdialog angezeigt, allerdings erscheint er immer in der Darstellung nicht signierter
Installationspakete. Das hat damit zu tun, dass bei der Deinstallation das im Cache befindliche
Installationspaket verwendet wird. Dieses Paket wurde allerdings im Rahmen der Installation in der
Form modifiziert, dass interne Kabinett-Dateien entfernt wurden. Vom Sicherheitsaspekt hat hier also
eine physische Modifikation des Paketes stattgefunden, wodurch die digitale Signatur durchbrochen
wurde. Somit wird es als nicht signiertes, also als nicht identifiziertes Programm angesehen, dass auf
den Computer zugreifen mchte. Dieses Szenario ist im Artikel Q929467 erlutert; eine Lsung ist erst
bei Windows 7 zu erwarten.
Verwenden eines Bootstrappers

In den dargestellten Ablufen wurden immer wieder zwei Szenarien betrachtet. Im ersten Fall wurde
eine setup.exe gestartet, die dann wiederum die eigentliche Installation initiiert hat. Im anderen Fall
wurde die Installation direkt gestartet, indem die MSI-Datei angeklickt wurde, oder die Installation
210
ber die Befehlszeile veranlasst wurde. Diese Unterscheidung ist uerst relevant fr die Speicherung
der Benutzerdaten und die zur Verfgung stehenden Privilegien, wie die folgenden Szenarien
verdeutlichen.
Eine Windows Installer basierte Installation wird durch Benutzer A unter Verwendung einer
setup.exe (Bootstrapper) gestartet. Wie zu Beginn des Kapitels beschrieben, kommt hier nun die
Installer-Erkennung der Benutzerkontensteuerung ins Spiel, da die Datei setup.exe heit. Hieraus wird
abgeleitet, dass es sich um ein Installationsprogramm handelt und dass solche Programme
normalerweise administrative Privilegien bentigen, weshalb der UAC-Besttigungsdialog angezeigt
wird. Da es sich bei Benutzer A um einen Standardbenutzer handelt wird der erweiterte
Besttigungsdialog (prompt for credentials) angezeigt. Benutzer A whlt hier nun einen Benutzer
aus, der ber ausreichende Privilegien verfgt; in diesem Fall Benutzer B. Die Installation wird nun
privilegiert ausgefhrt, wobei die folgenden Rahmenparameter verwendet werden:
Alle Aktionen und benutzerdefinierten Aktionen der Tabelle InstallUISequence werden mit den
Privilegien von Benutzer B ausgefhrt.
Der Client-Prozess wird ebenfalls mit den Rechten von Benutzer B ausgefhrt.
Alle Zugriffe auf das gemeinsam genutzte Dateisystem und den maschinenbasierten Teil der
Systemregistrierung (HKEY_LOCAL_MACHINE) werden mit den Rechten des lokalen
Systemkontos ausgefhrt. Alle Zugriffe auf den benutzerspezifischen Teil des Dateisystems werden
mit den Privilegien von Benutzer B ausgefhrt.
Benutzerdefinierte
Aktionen
der
Tabelle
die
als
des Benutzers B ausgefhrt.
Alle Netzwerkzugriffe erfolgen mit den Privilegien des Benutzers B.
Alle
Zugriffe
auf
den
benutzerbezogenen
Teil
der
(HKEY_CURRENT_USER) werden durch Benutzer B durchgefhrt.
Systemregistrierung
Gleiches gilt fr die Umgebungsvariablen, auf die wiederum im Kontext von Benutzer B
zugegriffen wird.
Aus diesem Schema lsst sich sehr gut erkennen, dass die Ablagestruktur nicht sehr einfach
nachvollziehbar ist. Das liegt daran, dass benutzerspezifische Informationen im Benutzerprofil von
B abgeleitet werden. Hieraus folgt auch, dass beispielsweise solche Dateiverknpfungen fr
Benutzer A gar nicht sichtbar sind. Problematisch ist hierbei, dass Benutzer A die Installation
startet aber dass fr ihn keine Elemente auf dem Desktop und im Startmen des Betriebssystems
angezeigt werden. Das Installationsergebnis ist so nicht direkt nachvollziehbar.
Ein anderes Bild ergibt sich beim Starten der Installation durch einen Doppelklick auf die Windows
Installer-Datei oder unter Verwendung der Befehlszeile. Hierdurch erfolgt die Anforderung der
erhhten Privilegien durch den Windows Installer selbst. Auch hier wird wiederum Benutzer B
ausgewhlt, damit eine privilegierte Installation erfolgen kann. Allerdings sind die Rahmenparameter
abweichend gestaltet.
Alle Aktionen und benutzerdefinierten Aktionen der Tabelle InstallUISequence werden in diesem
Szenario mit den Privilegien von Benutzer A ausgefhrt.
Der Client-Prozess wird auch mit den Rechten von Benutzer A ausgefhrt.
211
Kapitel 5
Alle Zugriffe auf das Dateisystem und den maschinenbasierten Teil der Systemregistrierung
(HKEY_LOCAL_MACHINE) werden mit den Rechten des lokalen Systemkontos ausgefhrt.
Benutzerdefinierte
Aktionen
der
Tabelle
die
als
des Benutzers A ausgefhrt.
Alle Netzwerkzugriffe erfolgen mit den Privilegien des Benutzers A.
Die Zugriffe auf den benutzerbezogenen Teil der Systemregistrierung (HKEY_CURRENT_USER)
werden auch hier durch Benutzer A durchgefhrt.
Gleiches gilt fr die Umgebungsvariablen, auf die wiederum im Kontext von Benutzer A
zugegriffen wird.
Hierbei lsst sich gut erkennen, dass die benutzerspezifischen Informationen wie erwartet im
Benutzerprofil von A abgelegt werden, also im Profil des Benutzers, der auch die Installation
ausfhrt und nicht im Profil des Benutzers, dessen Privilegien verwendet werden. Hieraus wird
deutlich, dass mehrere Mglichkeiten existieren, zu einem Installationserfolg zu gelangen. Beachtet
werden mssen jedoch die Rahmenparameter im Installationsszenario. Erkennbar ist auch, dass das
letzte Szenario dem erwarteten Ergebnis entspricht, womit diese Vorgehensweise favorisiert werden
sollte. Ist es zwingend erforderlich einen Bootstrapper zu verwenden, sollte die abweichenden
Verhaltensmuster und Installationsbilder immer Bercksichtigung finden.
Standardbenutzerinstallationen
Analog zu dem Festlegen eines Ausfhrungslevels auf Anwendungsebene existiert ein hnlicher
Mechanismus auch fr Installationspakete. Hierdurch wird es mglich, Installationspakete zu
kennzeichnen, die lediglich die Rechte eines Standardbenutzers bei der Installation bentigen. Diese
Installationspakete werden als Standardbenutzer-Pakete oder UAC-Konforme Installationspakete
bezeichnet.
Bevor ein Installationspaket fr die ausschlieliche Verwendung der Standardbenutzerrechte
gekennzeichnet werden kann, ist natrlich zu prfen, ob diese Rechte fr den Installationserfolg
tatschlich ausreichend sind. Wird ein Paket als UAC-Konform gekennzeichnet, wird logischerweise
kein UAC-Besttigungsdialog angezeigt. Enthlt das Installationspaket nun Elemente oder Aktionen
die vollstndige Privilegien erwarten kommt es zwangslufig zum Installationsfehler. Um im Vorfeld
diesbezgliche Fehlerquellen auszuschlieen sollten die folgenden Vorgaben bercksichtigt werden.
In der Tabelle InstallUISequence sollte eine benutzerdefinierte Aktion vom Typ 51 verwendet
werden, mit der die Eigenschaft ALLUSERS zurckgesetzt wird.
Dateien mssen in einem Ordner abgelegt werden, auf den ein Standardbenutzer schreibend
zugreifen kann. Es knnen natrlich die variablen Ordnerbezeichner wie beispielsweise
DesktopFolder, ProgramMenuFolder oder StartMenuFolder verwendet werden, die in
Abhngigkeit zur Eigenschaft ALLUSERS auf ein Computer- oder Benutzerverzeichnis verweisen.
Es ist jedoch zu beachten, dass ProgramFilesFolder hiervon nicht abhngig ist.
Die Anwendung sollte unter LocalAppDataFolder installiert werden.
Alle Registrierungseintrge sind unter HKEY_CURRENT_USER zu schreiben, was durch die 1
in der Spalte Root der Tabelle Registry festzulegen ist.
212
Das Paket ist als UAC-Konform zu kennzeichnen.

Falls die Installationen ber einen Bootstrapper (setup.exe) veranlasst wird, ist dieser mit der
Ausfhrungsebene asInvoker zu manifestieren.
Benutzerdefinierte Aktionen drfen nicht mit dem Attribut msidbCustomActionTypeNoImpersonate
(2048) gekennzeichnet werden.
Alle Fehler bei der ICE-Validierung sind zu beseitigen. Besonderes Augenmerk sollte hierbei auf
ICE57, also die gemeinsame Verwendung von Computer- und Benutzerdaten in einer Komponente.
Der Test des Installationspaketes sollte sowohl die Installation mit Standardbenutzerrechten als
auch die Installation mit vollstndigen Privilegien einschlieen.
Die Kennzeichnung eines Paketes als UAC-Konform erfolgt im Windows Installer-Umfeld nicht ber
ein Manifest, sondern durch die Eigenschaft PID_WORDCOUNT des Summary Information Streams.
Die mglichen Werte dieser Eigenschaft sind in Tabelle 5.44 zusammengefasst.
Bit
Wert
Beschreibung
Lange Dateinamen
Kurze Dateinamen
Quelldateien sind unkomprimiert
Quelldateien sind komprimiert
Bei der Quelle handelt es sich um das Originalmedium.
Bei der Quelle handelt es sich um das Abbild einer administrativen Installation
Vollstndige Privilegien sind fr die Installation erforderlich
Fr die Installation sind keine vollstndigen Privilegien erforderlich
Tabelle 5.44: Mgliche Werte fr die Eigenschaft PID_WORDCOUNT.
Da es sich bei dieser Eigenschaft um ein Bit-Feld handelt, sind die einzelnen Werte zu kombinieren.
Soll also ein Paket gekennzeichnet werden, das mit Standardbenutzer-Privilegien bei der Installation
auskommt, das lange Dateinamen verwendet und bei dem die zu installierenden Ressourcen in
komprimierter Form vorliegen, ist dieser Eigenschaft der Wert 10 zuzuordnen. Zum Festlegen der
Eigenschaft eignet sich das Tool msiinfo.exe, das sich im Windows Installer-SDK befindet und wie
folgt aufzurufen ist:
msiinfo.exe <Pfad zum Installationspaket> /W 10
Alternativ bietet auch Orca in der aktuellen Version die Mglichkeit diese Eigenschaft zu
modifizieren. Hierzu ist das Feld UAC Compliant im Dialog Edit Summary Information zu aktivieren,
wie auch Abbildung 5.43 verdeutlicht.
213
Kapitel 5
Abbildung 5.43: Kennzeichnung eines UAC-Konformen Installationspaketes mit Orca.
Bei der Verwendung von Windows Installer-XML kann die entsprechende Information direkt im WIXDokument angegeben werden. Hierzu ist das Attribut InstallPrivileges des Elementes <Package/> auf
den Wert limited zu setzen. Ein WIX-Dokument zur Definition eines UAC-Konformen
Installationspaketes zeigt Listing 5.49.
<Product UpgradeCode="2501DE56-6CC9-4078-B87E-F6664896125F" Manufacturer="Microsoft Deutschland GmbH"
Language="1031" Version="1.00.0000" Name="Vista UAC Non-Admin"
Id="7BF40BDA-E554-4949-8A6E-10297BD30BB6" Codepage="1252">
<Package Keywords="Microsoft Windows Installer, MSI"
Description="UAC-Konformes Installationspaket" Manufacturer="Andreas Kerl" InstallerVersion="400"
Platform="x86" Languages="1031" Compressed="yes" SummaryCodepage="1252"
InstallPrivileges="limited" />
<Condition Message='Bentigt Microsoft Windows Vista oder ein neueres
Betriebssystem'>VersionNT >= 600</Condition>
<Condition Message ='Die Verwendung dieses Installationspaketes als Nested Installation
wird nicht untersttzt.'>Not ParentProductCode</Condition>
<Property Id="INSTALLLEVEL" Value="3" />
<Property Id="MsiLogging" Value="icewarmupvxo" />
<Icon Id="AdminIcon.exe" SourceFile="$(var.SourceFolder)Admin.ico.exe" />
214
<Icon Id="NonAdminIcon.exe" SourceFile="$(var.SourceFolder)NonAdmin.ico.exe" />

<Directory Id="AppDataFolder">
<Directory Id="INSTALLLOCATION" Name="Vista UAC Non-Admin">

<Component Id="Admin.exe" Guid="3E935EC1-F26F-432B-B198-3E648371B6EC">
<File Id="Admin.exe" Source="$(var.SourceFolder)" Name="Admin.exe"
AssemblyManifest="Admin.exe" AssemblyApplication="Admin.exe"
Assembly=".net" DiskId="1" KeyPath="yes" />
<Shortcut Id="Admin.exe" Directory="DesktopFolder" Name="UAC-Demo (Administrator)"
Target="Application" Hotkey="0" Icon="AdminIcon.exe" IconIndex="0" Show="normal" />
</Component>

<Component Id="NonAdmin.exe" Guid="09482FE2-88D2-4862-AE9F-BE00918380E8">
<File Id="NonAdmin.exe" Source="$(var.SourceFolder)" Name="NonAdmin.exe"
AssemblyManifest="NonAdmin.exe" AssemblyApplication="NonAdmin.exe"
Assembly=".net" DiskId="1" KeyPath="yes" />
<Shortcut Id="NonAdmin.exe" Directory="DesktopFolder" Name="UAC-Demo (Benutzer)"
Target="Application" Hotkey="0" Icon="NonAdminIcon.exe" IconIndex="0" Show="normal" />
</Component>

<Component Id="System.Windows.Forms.Vista.dll" Guid="4FF6CAE1-DE0B-4232-8B90-F8B08747DEB7">
<File Id="System.Windows.Forms.Vista.dll" Source="$(var.SourceFolder)"
Name="System.Windows.Forms.Vista.dll" KeyPath="yes"
AssemblyManifest="System.Windows.Forms.Vista.dll"
AssemblyApplication="System.Windows.Forms.Vista.dll"
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="Application" Title="Anwendung" Description="Installiert die Anwendung"
Display="expand" Level="3">
<ComponentRef Id="NonAdmin.exe" />
<ComponentRef Id="Admin.exe" />
<ComponentRef Id="System.Windows.Forms.Vista.dll" />
</Feature>

<PatchCertificates>
<DigitalCertificate Id ="PatchCertificate" SourceFile ="$(var.CertificateFolder)Certificate.cer"/>
</PatchCertificates>
215
Kapitel 5

</Product>
</Wix>
Listing 5.49: UAC-Konformes Installationspaket mit Windows Installer-XML.
Wird hingegen das Attribut InstallPrivileges auf elevated gesetzt oder wird keine Kennzeichnung im
Summary Information Stream vorgenommen, geht der Windows Installer davon aus, dass vollstndige
Privilegien fr die Installation erforderlich sind und dass der Besttigungsdialog angezeigt wird. Hier
sei anzumerken, dass das dargestellte Verhalten unabhngig von den tatschlich erforderlichen
Rechten fr die Installationsttigkeit ist, sondern ausschlielich von der definierten Eigenschaft
abhngig ist. Wird ein Installationspaket erstellt, das Dateien lediglich im Benutzerprofil speichert,
sind folglich keine vollstndigen Berechtigungen erforderlich, so dass unbedingt ein StandardbenutzerPaket erstellt werden sollte. Existiert hingegen ein UAC-Konformes Installationspaket und sollen
hiermit Eintrge in der Systemregistrierung unter HKEY_LOCAL_MACHINE angelegt werden, kommt
es zum Fehler im Installationsprozess, da die Benutzerrechte nicht ausreichend sind. Es gilt somit das
Gleiche wie bei der Entwicklung einer Anwendung. Es muss genau geprft werden, an welchen Stellen
des Systems Modifikationen vorgenommen werden und anhand dieser Ergebnisse ist der
Ausfhrungslevel zu setzen
Anwenden von Windows Installer-Patches

Eine weitere Relevanz beim Windows Installer in Verbindung mit der Benutzerkontensteuerung
erfahren die Windows Installer-Patches. Wird ein Patch auf ein installiertes Produkt angewendet, ist es
mglich, dass die Verwendung vollstndiger Privilegien erneut besttigt werden muss. Allerdings
bietet der Windows Installer hier die Mglichkeit, die Anzeige des Dialogs zu unterbinden, indem
sogenannte UAC-Patches verwendet werden. Bevor ich auf die UAC-Patches, die vielfach auch unter
der Bezeichnung LUA-Patches bekannt sind, mchte ich zunchst auf die Anzeige des
Besttigungsdialogs beim Anwenden von Patches eingehen. Wie bereits bei der Installation wird auch
hier der schematische Ablauf in Abbildung 5.44 dargestellt.
216
Abbildung 5.44: Anzeige des UAC-Dialogs bei der Anwendung eines Patches
Im ersten Schritt wird geprft, ob bereits vollstndige Privilegien fr die Anwendung des Patches
vorliegen. In diesem Fall ist eine weitere Besttigung des Benutzers nicht erforderlich und der Patch
wird auf das installierte Produkt angewendet. Im nchsten Schritt wird zunchst geprft, ob das
Produkt fr alle Benutzer (per-machine) oder nur fr den aktuellen Benutzer (per-user) installiert
wurde. Nehmen wir zunchst die Benutzerinstallation. Hier wird geprft, ob es sich bei zu
aktualisierenden Produkt um ein UAC-Konformes Installationspaket handelt. In diesem Fall sind fr
die Aktualisierung logischerweise auch nur Standardbenutzerrechte erforderlich, wodurch keine
Besttigung erfolgen muss. Handelt es sich um kein Standardbenutzer-Paket werden zur Installation
des Patches wiederum vollstndige Privilegien bentigt, so dass die Verwendung explizit besttigt
werden muss. Im Rahmen der Computerinstallation kommen nun die LUA-Patches oder auch UACPatches ins Spiel. Zunchst wird geprft ob die Verwendung von LUA-Patches berhaupt mglich ist
und nicht durch Systemrichtlinien oder anderen Vorkehrungen auer Kraft gesetzt wurde. Im nchsten
Schritt wird festgestellt, ob es sich um einen LUA-Patch handelt. Ist dieses der Fall wird der Patch auf
das Produkt angewendet, ohne dass der Besttigungsdialog erscheint.
LUA-Patching
Die Untersttzung und Verwendung von LUA-Patches ist nicht neu in Windows Vista, sondern wurde
auf Initiative der Spielhersteller fr die Windows-Plattform bereits in den Windows Installer 3.0
integriert. Eine Vielzahl dieser Hersteller verfolgte das Ziel, fr ihre Spiele den Windows XP Logo
Status zu erlangen. Hierzu ist es jedoch erforderlich, dass sich das Standardinstallationsverzeichnis
unterhalb des Ordners %ProgramFiles% befindet und dass die Spiele auch von Benutzern ohne
administrative Berechtigungen ausgefhrt werden knnen. Im Normalfall ist dieses problemlos
mglich, da jeder Benutzer standardmig auf die Dateien und Ordner unterhalb von
%ProgramFiles% schreibgeschtzt zugreifen kann. Problematische Aspekte ergeben sich hingegen bei
Anwendungen, die relativ hufig aktualisiert werden mssen, wie es bei MMOGS (massive multi user
online games) der Fall ist. Zur Ausfhrung dieser Spiele ist die Anwendung eines Patches vielfach
erforderlich, um die clientseitige Version des Spiels auf den Versionsstand des Servers anzupassen.
217
Kapitel 5
Die Aktualisierung erstreckt sich hierbei zwangslufig auch auf Bereiche, auf die ein Standardbenutzer
nur ber einen schreibgeschtzten Zugriff verfgt, so dass die Aktualisierung nicht durchgefhrt
werden kann.
Zur Verwendung von LUA-Patches sind Richtlinien sowohl bei der Erstellung des Installationspaketes
als auch bei der Erstellung der jeweiligen Patches zu beachten. Der gesamte Algorithmus zur
Anwendung von LUA-Patches beruht auf der Prfung eines Zertifikates mit dem die jeweiligen
Patches digital signiert werden mssen. Bevor der Patch auf das Produkt angewendet wird, wird die
digitale Signatur des Patches extrahiert und mit dem Zertifikat verglichen, das im
Originalinstallationspaket gespeichert ist. Fllt dieser Vergleich positiv aus, kann der Patch auf das
jeweilige Produkt angewendet werden. Erkennbar ist hierbei, dass das Installationspaket ber
Mglichkeiten verfgen muss, das Zertifikat aufzunehmen. Hierzu sind die beiden Tabellen
MsiDigitalCertificate und MsiPatchCertificate erforderlich.
MsiDigitalCertificate: Windows Installer verwendet digitale Signaturen, um fehlerhafte
Ressourcen festzustellen. Die Tabelle MsiDigitalCertificate speichert Zertifikate als binren
Datenstrom und verknpft jedes Zertifikat mit einem Primrschlssel. Der Primrschlssel wird
bentigt, um die Zertifikate von mehreren digital signierten Objekten gemeinsam zu verwenden.
Windows Installer Version 2.0 kann ausschlielich die digitalen Signaturen von externen
Kabinettdateien
durch
die
Verwendung der
Tabellen MsiDigitalSignature
und
MsiDigitalCertificate verifizieren. Mit den neueren Versionen des Windows Installers wird diese
Tabelle auch verwendet, um Zertifikate zu speichern, mit denen Windows Installer-Patches digital
signiert wurden.
MsiPatchCertificate: Die Tabelle MsiPatchCertificate enthlt Referenzen auf die mglichen
Zertifikate, mit denen ein Patch digital signiert werden kann. Die Informationen dieser Tabelle sind
erforderlich, um das LUA-Patching zu ermglichen.
Die einzige Vorgabe, die bei der Erstellung des Patches zu bercksichtigen ist, betrifft die digitale
Signatur des Patches selbst. Es ist erforderlich, die MSP-Datei mit einem Zertifikat digital zu
signieren, das im Originalinstallationspaket gespeichert ist. Das Aufbringen der digitalen Signatur
kann mit dem Tool signcode.exe oder signtool.exe vorgenommen werden.
Im Normalfall werden Softwareprodukte ber eine sehr lange Zeitdauer verwendet, die hufig die
Gltigkeitsdauer der Zertifikate bersteigt. Aus diesem Grund wird bei der Anwendung des Patches
lediglich die bereinstimmung der Zertifikate geprft, wobei die Gltigkeitsdauer der Zertifikate nicht
bercksichtigt wird. Hieraus ergibt sich, dass ein Patch angewendet werden kann, obwohl die
Gltigkeitsdauer des Zertifikats verstrichen ist. Ein potentielles Sicherheitsproblem hingegen sind
gesperrte Zertifikate, da die Ursache hierfr hufig in der Offenlegung des privaten Schlssels zu
finden ist. Falls ein Zertifikat gesperrt wird, nachdem der Patch auf das Produkt angewendet wurde,
tritt kein Fehler bei zuknftigen Installationsttigkeiten auf, solange sich die Kopie des Patch-Paketes
im Ordner %windir%\installer befindet. In bestimmten Situationen und Umgebungen kann es jedoch
erforderlich werden, ein neues Zertifikat fr die Signatur der Patches zu verwenden. Hierzu kann ein
weiterer Patch verwendet werden, der der Tabelle MsiPatchCertificate einen neuen Eintrag hinzufgt
oder einen existierenden Eintrag aktualisiert. Hierdurch kann es geschehen, dass mehrere Zertifikate in
der jeweiligen Tabelle des Installationspaketes vorhanden sind. Zur Anwendung eines Patches muss
jedoch nur eine bereinstimmung vorliegen.
Gltigkeit der Zertifikate

Die berprfung der digitalen Signatur des Patches wird durch die Funktion WinVerifyTrust()
218
ausgefhrt. Gibt diese Funktionen einen der folgenden Werte zurck, wird das Zertifikat als nicht
vertrauenswrdig eingestuft und der Patch kann nicht angewendet werden:
TRUST_E_NOSIGNATURE (0x800B0100): Es war keine Signatur vorhanden.
TRUST_E_BAD_DIGEST (0x80096010): Die digitale Signatur des Objekts konnte nicht
besttigt werden.
TRUST_E_NO_SIGNER_CERT (0x80096002): Das Zertifikat fr den Signaturgeber fr diese
Nachricht ist ungltig oder wurde nicht gefunden.
TRUST_E_SUBJECT_NOT_TRUSTED (0x800B0004): Der Antragsteller gilt fr den
angegebenen Vorgang nicht als vertrauenswrdig.
CERT_E_MALFORMED (0x800B0108): Es fehlt ein Zertifikat, oder es hat keinen Wert fr ein
wichtiges Feld, z. B. ein Antragsteller- oder Ausstellername.
CERT_E_REVOKED (0x800B010C): Ein Zertifikat wurde explizit durch den Aussteller gesperrt.
TRUST_E_PROVIDER_UNKNOWN (0x800B0001): Unbekannter Vertrauensanbieter.
TRUST_E_SUBJECT_FORM_UNKNOWN (0x800B0003): Das fr den Antragsteller
angegebene Formular wird vom angegebenen Vertrauensanbieter nicht untersttzt oder ist ihm
nicht bekannt.
TRUST_E_ACTION_UNKNOWN
(0x800B0002):
Die
angegebene
Vorgang
der
Vertrauensberprfung wird von dem angegebenen Vertrauensanbieter nicht untersttzt.
Bei den folgenden Rckgabewerten handelt es sich um einige Sonderflle, die hingegen die
Anwendung des Patches zulassen.
CERT_E_EXPIRED (0x800B0101): Ein erforderliches Zertifikat befindet sich nicht im
Gltigkeitszeitraum gemessen an der aktuellen Systemzeit oder dem Zeitstempel in der signierten
Datei.
CERT_E_UNTRUSTED_ROOT (0x800B0109): Eine Zertifikatkette wurde zwar verarbeitet,
endete jedoch mit einem Stammzertifikat, das beim Vertrauensanbieter nicht als vertrauenswrdig
gilt.
CERT_E_UNTRUSTEDTESTROOT (0x800B010D): Der Zertifizierungspfad endet mit dem
Teststamm, der mit den aktuellen Richtlinieneinstellungen nicht vertrauenswrdig ist.
CERT_E_UNTRUSTEDCA (0x800B0112): Die Zertifizierungskette wurde richtig verarbeitet,
doch wird eines der Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht fr
vertrauenswrdig gehalten.
Zwei Formen dieser berprfungsergebnisse erfordern eine besondere Betrachtung, da diese durch den
Windows Installer abweichend interpretiert und verwendet werden.
Abgelaufene Zertifikate
Die Lebensdauer von Produkten ist im Normalfall wesentlich hher als die Gltigkeitsdauer von
Zertifikaten. Aus diesem Grund wird bei der Anwendung von LUA-Patches die Gltigkeitsdauer des
Zertifikates nicht berprft. Das Zertifikat wird lediglich mit der digitalen Signatur des Patches
verglichen. Ein problematischer Aspekt ergibt sich hierbei lediglich bei der Erstellung eines LUAPatches, da dieser mit einem abgelaufenen Zertifikat nicht signiert werden kann.
Um eine solche Problemsituation zu vermeiden ist es vor dem Ablauf des Zertifikates erforderlich,
dem Installationspaket ein neues Zertifikat hinzuzufgen. Solange das Zertifikat gltig ist, kann fr die
219
Kapitel 5
erforderliche Aktualisierung des Installationspaketes auch ein LUA-Patch verwendet werden.

Problematische Aspekte ergeben sich lediglich, falls der Gltigkeitsraum des Zertifikates bereits
berschritten ist, so dass kein geeigneter LUA-Patch mehr erstellt werden kann. In einem solchen Fall
besteht nur die Mglichkeit, einen normalen Patch zu erstellen und diesen durch einen Administrator
anwenden zu lassen.
Gesperrte Zertifikate
Etwas anders verhlt es sich bei Zertifikaten dessen privater Schlssel offen gelegt wurde, wodurch ein
solches Zertifikat als nicht vertrauenswrdig eingestuft werden sollte. Um hieraus resultierende
Sicherheitsprobleme zu vermeiden, werden die entsprechenden Zertifikate normalerweise in eine
Zertifikatssperrliste aufgenommen. Falls beim Anwenden eines LUA-Patches das verwendete
Zertifikat auf der Sperrliste zu finden ist, wird der Patch als nicht vertrauenswrdig eingestuft und die
Anwendung des Patches wird untersagt.
Zur Aufrechterhaltung des Servicemodells fr ein entsprechendes Produkt, muss dem
Originalinstallationspaket ein neues Zertifikat zugefgt werden. Diese Vorgehensweise ist durch einen
Patch mglich, allerdings muss dieser Patch durch einen Administrator angewendet werden. Falls
dieses erfolgt ist, knnen neue LUA-Patches mit diesem Zertifikat signiert werden und fortan
problemlos auf das Produkt angewendet werden. Eine besondere Beachtung erfahren allerdings
Patches, die bereits angewendet wurden, bevor das Zertifikat der Sperrliste hinzugefgt wurde. Falls
das Patch-Paket im Ordner %windir%\installer noch vorhanden ist, behlt der Patch nach wie vor
seine Gltigkeit, da eine bereinstimmung des Zertifikats nicht erneut geprft wird. Ist das Patchpaket
im Cache hingegen nicht mehr vorhanden, wird der Patch als nicht vertrauenswrdig erachtet und
gesperrt.
Anwendungsvoraussetzungen
Der Verwendung von LUA-Patches setzt Windows XP oder Windows Vista als Betriebssystem und
mindestens die Version 3.0 des Windows Installer voraus. Falls die Forderung besteht, LUA-Patching
auf den untersttzten Betriebssystemen generell zu deaktivieren, kann hierfr die Systemrichtlinie
Installation von Updates, die durch Hersteller signiert wurden, fr Nichtadministratoren nicht
zulassen (DisableLUAPatching) verwendet werden. Diese Richtlinie wirkt sich auf alle Patches aus,
die zuknftig auf Produkte angewendet werden sollen. Wie bereits bei den bisherigen Richtlinien, gilt
auch diese global, so dass alle Patches davon betroffen sind. Um das LUA-Patching in Abhngigkeit
zu
bestimmten
Produkten
zu
verhindern,
kann
die
ffentliche
Eigenschaft
MSIDISABLELUAPATCHING verwendet werden. Auf den Server-Betriebssystemen Windows Server
2003 und Windows Server 2008 steht LUA-Patching nicht zur Verfgung.
Wie bereits dargestellt sind einige Voraussetzungen erforderlich, um LUA-Patches verwenden zu
knnen. So darf beispielsweise die Systemrichtlinie DisableLUAPatching nicht deaktiviert sein und die
richtige Version des Betriebssystems muss vorliegen. Diese und weitere Kriterien mssen bei der
Installation des Produktes erfllt sein, damit dieses Produkt durch LUA-Patches aktualisiert werden
kann. Die Erfllung dieser Kriterien wird in der Eigenschaft AuthorizedLUAApp in den
Konfigurationsdaten des Produktes abgelegt. Ein Wert von 1 fr diese Eigenschaft besagt, dass
LUA-Patches auf dieses Produkt angewendet werden knnen. Ein Wert von 0 oder ein fehlender
Wert kennzeichnet ein Produkt, auf das LUA-Patches nicht angewendet werden knnen.
Bei der Verwendung der Deployment Tools Foundation kann mit Hilfe der Eigenschaft
PrivilegedPatchingAuthorized des Objektes ProductInstallation ermittelt werden, ob LUA-Patches fr
220
die Anwendung untersttzt werden. Im nachfolgenden Codefragment wird dieses fr Visual Studio
2008 durchgefhrt, das Ergebnis ist positiv.
// Produkt: Visual Studio Team System 2008 - Team Suite
string productCode = "{80C06CCD-7D07-3DB6-86CD-B57B3F0614D8}";
// Objekt mit Installationseigenschaften abrufen
ProductInstallation product = new ProductInstallation(productCode);
// Entsprechende Eigenschaft verwenden
bool isAuthorizedLUAApp = product.PrivilegedPatchingAuthorized;
Der Wert der gerade dargestellten Eigenschaft kann whrend der Gltigkeitsdauer eines Produktes
nicht mehr verndert werden; sie wird bei der Basisinstallation des Produkts durch den Windows
Installer automatisch gesetzt. Bei der Entscheidung ob ein Produkt die Verwendung von LUA-Patches
untersttzt, wendet der Windows Installer den in Abbildung 5.45 dargestellten Algorithmus an:
Abbildung 5.45: Algorithmus zur Feststellung ob LUA-Patches fr das Produkt untersttzt werden
Hieraus ergeben sich die folgenden Kriterien, die bei der Installation des Produktes erfllt sein mssen,
damit der Windows Installer das Produkt zur Verwendung von LUA-Patches autorisiert.
Die Eigenschaft MSIDISABLELUAPATCHING darf nicht festgelegt sein.
Die Tabelle MsiPatchCertificate muss im Installationspaket vorhanden sein und gltige Daten
enthalten.
221
Kapitel 5
Die Installation erfolgt auf dem Betriebssystem Windows XP oder hher.

Es darf sich um kein Server-Betriebssystem handeln.
Die Systemrichtlinie DisableLUAPatching darf nicht auf den Wert 0 gesetzt sein.
Die Installation darf nicht von einem administrativen Abbild erfolgen.
Es muss sich um eine Maschineninstallation handeln.
Die Installation des Produktes muss von einem Wechseldatentrger erfolgen. Diese Vorgabe wurde
unter Windows Vista gendert, so dass sie nur bei Windows XP zutreffend ist. Unter Windows
Vista kann die Produktinstallation von jeder Installationsquelle ausgefhrt werden.
Aus diesen Richtlinien ergeben sich einige Anwendungsszenarien, die sich auf die Eigenschaft
AuthorizedLUAApp auswirken. Bei den Tabelle 5.45 dargestellten Beispielen wird die Verwendung
eines gltigen Betriebssystems vorausgesetzt.
Situation
AuthorizedLUAApp
Begrndung
Die Tabelle MsiPatchCertificate

ist nicht vorhanden
LUA-Patching ist deaktiviert.
Die Tabelle MsiPatchCertificate

enthlt keine Eintragungen
LUA-Patching ist deaktiviert.
Es handelt sich um die Installation

eines Standardbenutzerpaketes.
LUA-Patching ist irrelevant, da der

Patch auf eine solche Installation
von jedem Benutzer angewendet
werden kann.
Die Installation erfolgt von einem

administrativen Abbild mit
gefllter Tabelle
MsiPatchCertificate.
LUA-Patching wird fr
Installationen von einem
administrativen Abbild nicht
untersttzt.
Die Installation unter Windows

Vista erfolgt von einem
Netzlaufwerk mit gefllter Tabelle
MsiPatchCertificate.
Falls die Richtlinie

DisableLUAPatching oder die
Eigenschaft
MSIDISABLELUAPATCHING
gesetzt wurde 0, ansonsten 1
LUA-Patching wird bei Windows

XP nur fr Installationen vom
Wechseldatentrger untersttzt. Bei
Windows Vista kann die
Installation von jeder Quelle
erfolgen. Natrlich muss die
Tabelle MsiPatchCertificate gefllt
sein und der Mechanismus darf
nicht durch die Richtlinie oder die
Eigenschaft auer Kraft gesetzt
werden.
Die Installation erfolgt von einem

Wechseldatentrger mit gefllter
Tabelle MsiPatchCertificate.
Falls die Richtlinie

DisableLUAPatching oder die
Eigenschaft
gesetzt wurde 0, ansonsten 1
LUA-Patching wird fr
Installationen vom
Wechseldatentrger generell
untersttzt, wenn die Tabelle
MsiPatchCertificate gefllt ist und
der Mechanismus nicht durch die
Richtlinie oder die Eigenschaft
auer Kraft gesetzt wird.
Tabelle 5.45: Szenarien zur Kennzeichnung eines Produktes das LUA-Patches untersttzt
222
Bei der Erstellung von Installationspaketen fr Windows Vista sollte die perspektivische Verwendung
von LUA-Patches immer bercksichtigt werden. Wie bereits erlutert ist es erforderlich die Tabelle
MsiPatchCertificate in das Installationspaket zu integrieren und mit einem geeigneten Zertifikat zu
versehen. Entsprechende Szenarien sind natrlich auch mit Windows Installer-XML umsetzbar wie das
bereits bekannte Listing 5.49 zeigt. Bei der Betrachtung des Listings stellt sich die Frage, warum muss
das Zertifikat in das Paket integriert werden, wenn es sich doch um ein Standardbenutzerpaket handelt
und somit keine erhhten Privilegien fr die Installation von Patches erforderlich sind. Das ist
natrlich richtig, aber zunchst ist der Aufwand zum Integrieren eines Zertifikates sehr gering und man
ist hierdurch fr alle Eventualitten gerstet. Die Kennzeichnung als UAC-Konformes Paket besagt ja
zunchst nur, dass keine administrativen Privilegien fr die Installation erforderlich sind und das kein
UAC-Besttigungsdialog angezeigt wird. Es ist ja dennoch mglich die Installation privilegiert
auszufhren. Wenn dieses dann als Maschineninstallation erfolgt sind zwangslufig beim Anwenden
von Patches wiederum vollstndige Privilegien erforderlich.
Was fr die Installation gilt, ist natrlich auch fr die Deinstallation von Patches zutreffend. Seit dem
Windows Installer 3.0 knnen Patches deinstalliert werden, falls bestimmte Voraussetzungen
vorliegen. Hierbei ist es einem Benutzer ohne administrative Berechtigungen jedoch nicht mglich,
Patches von privilegierten Produkten zu deinstallieren. Falls es sich um einen LUA-Patch handelt,
kann dieser jedoch auch von einem Benutzer deinstalliert werden, der ber keine administrativen
Berechtigungen verfgt. Bei der Verwendung von Windows Vista ist dieses natrlich analog
anzuwenden; hier erscheint bei der Deinstallation des Patches kein UAC-Besttigungsdialog.
Hilfestellung durch das Installationsprotokoll

Die Informationen zu LUA-Patches und zu Anwendungen die LUA-Patches untersttzen, werden im
Installationsprotokoll detailliert aufgefhrt, so dass sie im Fehlerfall eine groe Hilfestellung bieten.
Bei der Installation des Originalpaketes lassen die folgenden Eintragungen auf ein Produkt schlieen,
dass durch LUA-Patches aktualisiert werden kann. Die relevanten Informationen finden sich hierbei in
der Operationsanweisung ProductInfo. Diese Operationsanweisung verfgt ber das Argument
LUASetting, welches den Wert 1 enthlt, falls das Produkt die Anwendung von LUA-Patches
untersttzt.
MSI (s) (B4:98) [10:04:09:420]: Product installation will be elevated because user provided
elevated credentials and product is being installed per-machine.
MSI (s) (B4:98) [10:04:09:420]: Running product '{F757EB1A-EF82-47A3-9D64-E11EED95D206}' with elevated
privileges: Product is assigned.
MSI (s) (B4:98) [10:04:09:561]: Executing op: Header(Signature=1397708873,Version=405,

Timestamp=954290309,LangId=1031,Platform=0,ScriptType=1,ScriptMajorVersion=21,
ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (B4:98) [10:04:09:561]: Executing op: ProductInfo(
ProductKey={F757EB1A-EF82-47A3-9D64-E11EED95D206},
ProductName=Vista Restart Manager Sample,PackageName=Restart.msi,Language=1031,Version=16777216,
Assignment=1,ObsoleteArg=0,ProductIcon=AppIcon.exe,0,,
PackageCode={71A011AC-476C-4CE7-B7FE-31B58561E23B},,,InstanceType=0,LUASetting=1,
RemoteURTInstalls=0,ProductDeploymentFlags=2)
Bei der Anwendung eines LUA-Patches auf ein entsprechendes Produkt, werden Informationen zu der
Gltigkeit des Zertifikates ausgegeben. Im Weiteren wird ausgegeben ob der Patch den erforderlichen
Kriterien entspricht, was sich letztlich in der Operationsanweisung zur Registrierung des Patches
wieder findet.
223
Kapitel 5
MSI (s) (B4:AC) [10:06:47:326]: Machine policy value 'DisableLUAPatching' is 0

MSI (s) (B4:AC) [10:06:47:326]: Validating digital signature of file 'C:\Windows\Installer\5df423.msp'
MSI (s) (B4:AC) [10:06:47:326]: File 'C:\Windows\Installer\5df423.msp' is a validly signed file and
validates according to authoring of MSI package
MSI (s) (B4:AC) [10:06:47:326]: Patch =\\eagle\setup\update.msp will be applied because it meets
the LUA patch criteria
MSI (s) (B4:AC) [10:06:47:591]: Executing op: PatchRegister(

PatchId={1C60721E-88A8-4F84-B0FB-3D8BB7F408DC},NewState=2,OldState=1,TransformList=:T1ToU1;:#T1ToU1,
Uninstallable=1,LUAEnabled=1,PatchType=1,DisplayName=SP1,
MoreInfoURL=http://www.microsoft.com/germany)
Falls das Zertifikat gesperrt wurde, werden diesbezgliche Informationen ebenfalls dem
Installationsprotokoll angefgt.
MSI (c) (8C:80) [10:20:53:708]: SOFTWARE RESTRICTION POLICY: Verifying patch --> '\\eagle\setup\update.msp'
against software restriction policy
MSI (c) (8C:80) [10:20:53:708]: SOFTWARE RESTRICTION POLICY: \\eagle\setup\update.msp has a digital signature
MSI (c) (8C:80) [10:20:53:708]: SOFTWARE RESTRICTION POLICY: \\eagle\setup\update.msp is not permitted
to run at the 'unrestricted' authorization level.
MSI (c) (8C:80) [10:20:53:708]: SOFTWARE RESTRICTION POLICY: \\eagle\setup\update.msp was disallowed
because a required certificate in its digital signature has been revoked by its issuer
(status = 0x800B010C). The returned execution level was 0
MSI (c) (8C:80) [10:20:53:708]: Die Installation von \\eagle\setup\update.msp wurde durch die
Richtlinie fr Softwareeinschrnkungen nicht zugelassen. Der Windows Installer lsst nur
die Installation von Elementen zu, die ber keine Einschrnkungen verfgen. Die von der
Richtlinie fr Softwareeinschrnkungen zurckgelieferte Autorisierungsstufe war 0x0
(Statusrckgabewert 0x800b010c).
Wird ein Zertifikat verwendet, bei dem die Gltigkeitsdauer erloschen ist, sind keine diesbezglichen
Informationen im Protokoll zu finden. Der Patch wird fehlerfrei angewendet.

Eine Zielsetzung bei der Entwicklung neuer Windows Installer-Versionen war und ist die
Kompatibilitt mit lteren Versionen. Hiermit soll erreicht werden, dass Installationspakete, die fr
eine ltere Version des Windows Installers konzipiert wurden unter der neuen Version zu einem
identischen Installationsergebnis fhren. Allerdings ist dieses ist jedoch die Theorie, denn es hat sich
unter Windows Vista und Windows Server 2008 sehr viel im sicherheitsrelevanten Bereich getan, so
dass hierbei Auswirkungen auf den Installationsprozess nicht ausgeschlossen werden knnen.
Installation fr den Benutzer oder fr den Computer

Eine erste Abweichung gibt es bei der Verwendung der Eigenschaft ALLUSERS. Durch diese
Eigenschaft kann festgelegt werden ob eine Maschinen- oder einer Benutzerinstallation durchgefhrt
werden soll. Es kann also bestimmt werden, ob eine verwaltete oder eine nicht verwaltete Installation
erfolgen soll. Im Weiteren wird hierdurch festgelegt, ob Informationen im aktuellen Benutzerprofil
oder im Profil aller Benutzer abgelegt werden. Wird beispielsweise die Ordnerkennzeichnung
ProgramMenuFolder im Installationspaket verwendet, erfolgt die Installation bei einer
224
Maschineninstallation unterhalb von %ALLUSERSPROFILE%, bei einer Benutzerinstallation unter

%USERPROFILE%. Wird diese Eigenschaft nicht definiert oder auf eine leere Zeichenfolge gesetzt,
wird eine Benutzerinstallation durchgefhrt. Wird die Eigenschaft ALLUSERS auf den Wert 1
festgelegt, fhrt der Windows Installer eine Maschineninstallation durch. Hierzu sind jedoch
administrative Rechte erforderlich. Wird die Eigenschaft ALLUSERS auf den Wert 2 festgelegt,
beginnt der Windows Installer auch mit einer Computerinstallation. Wird hierbei festgestellt, dass der
Benutzer nicht ber die bentigten Administratorenrechte verfgt, wird die Eigenschaft ALLUSERS
automatisch auf den Standardwert zurckgesetzt und eine Benutzerinstallation durchgefhrt. Das
bedeutet, dass diese nur fr den aktuellen Benutzer verfgbar ist. Die Installation und Konfiguration
wird wie folgt vorgenommen:
Dateiverknpfungen werden im Benutzerprofil angelegt.
Anwendungen erscheinen in der Systemsteuerung unter Software ausschlielich unter dem
Benutzer, der die Installation durchgefhrt hat.
Die Registrierung von COM-Komponenten wird unter HKEY_CURRENT_USER\Software\Classes
durchgefhrt.
Die Installation kann mit den Rechten des Standardbenutzers durchgefhrt werden.
Symbole
und
normale
Transformationen
werden
unter
%APPDATA%\Microsoft\Installer\{ProductCode} abgelegt. Abgesicherte Transformationen
werden hingegen im identischen Verzeichnis abgelegt wie bei einer Maschineninstallation.
Die nachfolgende Tabelle 5.46 zeigt, auf welche Werte der Windows Installer die dargestellten
Eigenschaftswerte setzt:
Eigenschaft
Beschreibung
DesktopFolder
Vollstndiger Pfad zum Ordner Desktop des aktuellen Benutzers.
ProgramMenuFolder
Vollstndiger Pfad zum Ordner Startmen\Programme des aktuellen

Benutzers.
StartMenuFolder
Vollstndiger Pfad zum Ordner Startmen des aktuellen Benutzers.
StartUpFolder
Vollstndiger Pfad zum Ordner Autostart des aktuellen Benutzers.
TemplateFolder
Vollstndiger Pfad zum Ordner Vorlagen des aktuellen Benutzers.
AdminToolsFolder
Vollstndiger Pfad zum Ordner Startmen\Programme\Verwaltung des

aktuellen Benutzers.
AppDataFolder
Vollstndiger Pfad zum Ordner Anwendungsdaten des aktuellen Benutzers.
CommonAppDataFolder
Vollstndiger Pfad zum Ordner Anwendungsdaten fr alle Benutzer.
FavoritesFolder
Vollstndiger Pfad zum Ordner Favoriten des aktuellen Benutzers.
PersonalFolder
Vollstndiger Pfad zum Ordner Eigene Dateien des aktuellen Benutzers.
SendToFolder
Vollstndiger Pfad zum Ordner SendTo des aktuellen Benutzers.
FontsFolder
Vollstndiger Pfad zum Ordner Schriftarten.
ProgramFilesFolder
Vollstndiger Pfad zum Ordner Programme des aktuellen Benutzers.
CommonFilesFolder
Vollstndiger Pfad zum Ordner Gemeinsame Dateien des aktuellen
225
Kapitel 5

Benutzers.
WindowsFolder
Vollstndiger Pfad zum Ordner Windows.
SystemFolder
Vollstndiger Pfad zum Ordner System des aktuellen Benutzers.
LocalAppDataFolder
Vollstndiger Pfad zum Ordner Anwendungsdaten des aktuellen Benutzers.
MyPicturesFolder
Vollstndiger Pfad zum Ordner Eigene Bilder des aktuellen Benutzers.
Tabelle 5.46: Eigenschaftswerte bei einer Benutzerinstallation
Computerinstallation bedeutet hingegen, dass diese fr alle Benutzer verfgbar ist. Die Installation und
Konfiguration wird wie folgt vorgenommen:
Dateiverknpfungen werden im Profil aller Benutzer angelegt.
COM-Komponenten werden immer unter HKEY_LOCAL_MACHINE\Software\Classes registriert.
Die Installation muss immer mit erhhten Rechten durchgefhrt werden.
Symbole und Transformationen werden unter %Windows%\Installer\{ProductCode} abgelegt.
Die nachfolgende Tabelle zeigt, auf welche Werte der Windows Installer die dargestellten
Eigenschaften setzt:
Eigenschaft
Beschreibung
DesktopFolder
Vollstndiger Pfad zum Ordner Desktop fr alle Benutzer.
ProgramMenuFolder
Vollstndiger Pfad zum Ordner Startmen\Programme fr alle Benutzer.
StartMenuFolder
Vollstndiger Pfad zum Ordner Startmen fr alle Benutzer.
StartUpFolder
Vollstndiger Pfad zum Ordner Autostart fr alle Benutzer.
TemplateFolder
Vollstndiger Pfad zum Ordner Vorlagen fr alle Benutzer.
AdminToolsFolder
Vollstndiger Pfad zum Ordner Startmen\Programme\Verwaltung fr alle

Benutzer.
AppDataFolder
Vollstndiger Pfad zum Ordner Anwendungsdaten fr den aktuellen Benutzer.
CommonAppDataFolder
FavoritesFolder
Vollstndiger Pfad zum Ordner Favoriten fr den aktuellen Benutzer.
PersonalFolder
Vollstndiger Pfad zum Ordner Eigene Dateien fr den aktuellen Benutzer.
SendToFolder
Vollstndiger Pfad zum Ordner SendTo fr den aktuellen Benutzer.
FontsFolder
Vollstndiger Pfad zum Ordner Schriftarten.
ProgramFilesFolder
Vollstndiger Pfad zum Ordner Programme fr den aktuellen Benutzer.
CommonFilesFolder
Vollstndiger Pfad zum Ordner Gemeinsame Dateien fr den aktuellen Benutzer.
WindowsFolder
Vollstndiger Pfad zum Ordner Windows fr den aktuellen Benutzer.
SystemFolder
Vollstndiger Pfad zum Ordner System fr den aktuellen Benutzer.
LocalAppDataFolder
MyPicturesFolder
Vollstndiger Pfad zum Ordner Eigene Bilder fr den aktuellen Benutzer.
226
Tabelle 5.47: Eigenschaftswerte bei einer Computerinstallation
Bei der Verwendung von Windows XP und Windows Server 2003 spielt die Eigenschaft ALLUSERS
eine gravierende Rolle hinsichtlich der erforderlichen Berechtigungen, wie dieses auch in Tabelle 5.48
gezeigt wird. Hier wird die verwendete Installationsart in Abhngigkeit zu der Eigenschaft ALLUSERS
und den zugewiesenen Privilegien aufgefhrt.
Berechtigungen
ALLUSERS nicht
definiert (Standard)
ALLUSERS = 1
ALLUSERS = 2
Benutzerrechte
Benutzerinstallation.
Verwendet Ordner im
Profil des Anwenders.
Nicht mglich. Gibt einen

Fehler zurck, der darauf
hinweist, dass der
Anwender nicht die
bentigten Rechte besitzt.
Verwendet Ordner im
Administrative Rechte
Verwendet Ordner im
Computerinstallation.
Verwendet Ordner im
Profil aller Benutzer.
Verwendet Ordner im
Tabelle 5.48: Auswirkungen der Eigenschaft ALLUSERS unter Windows XP und Windows Server 2003
Unter Windows Vista und Windows Server 2008 wurde die Bedeutung dieser Eigenschaft in der Form
gendert, dass sie nicht mehr fr die Festlegung der erforderlichen Privilegien verantwortlich ist. Die
bentigten Privilegien werden nun durch eine zustzliche Kennzeichnung des Installationspaketes
spezifiziert, wie dieses an spterer Stelle noch erlutert wird. Hierdurch ergeben sich natrlich
abweichende Verhaltensmuster wie dieses auch Tabelle 5.49 zeigt. Wesentlich gendert wurde das
Verhalten, wenn ALLUSERS auf 2 festgelegt wurde. Hierbei wird nun in allen Fllen eine
Maschineninstallation veranlasst; stehen jedoch keine ausreichenden Rechte zur Verfgung kommt es
zum Installationsfehler.
UAC-Konformitt
ALLUSERS nicht
definiert (Standard)
ALLUSERS = 1
ALLUSERS = 2
Standardbenutzer-Paket
Verwendet Ordner im

hinweist, dass der
Anwender nicht die

hinweist, dass der
Anwender nicht die
Kein StandardbenutzerPaket
Verwendet Ordner im
Verwendet Ordner im
Verwendet Ordner im
Tabelle 5.49: Auswirkungen der Eigenschaft ALLUSERS unter Windows Vista und Windows Server 2008
Voraussetzungen fr die Installation

Die Eigenschaften AdminUser und Privileged werden in vielen Installationspaketen fr
unterschiedliche Zwecke, aber hauptschlich im Rahmen von Bedingungen verwendet. Vielfach sind
diese in den Ausfhrungsbedingungen (LaunchConditons) zu finden, wodurch eine Installation nur fr
Benutzer mit administrativen Privilegien ermglicht wird. Weitere Einsatzmglichkeiten ergeben sich
hufig in der Gestaltung der Benutzeroberflche. So kann vielfach festgelegt werden, ob die
Installation fr die Maschine oder den Benutzer erfolgen soll, wozu letztlich die Eigenschaft
227
Kapitel 5
ALLUSERS herangezogen wird. Fr eine Maschineninstallation sind jedoch erhhte Privilegien

erforderlich, so dass eine entsprechende Auswahloption nur sinnvoll ist, wenn diese Rechte auch
vorhanden sind. Mitunter werden die Eigenschaften AdminUser und Privileged synonym betrachtet
und verwendet, was jedoch nicht richtig ist.
Die Eigenschaft AdminUser wird auf den Wert 1 gesetzt, wenn es sich bei dem Benutzer um
einen Administrator handelt.
Die Eigenschaft Privileged wird hingegen auf den Wert 1 gesetzt, falls die Installation mit
erhhten Rechten ausgefhrt wird. Dieses ist natrlich der Fall, falls ein Administrator die
Installation ausfhrt. Szenarien in denen ein Standardbenutzer die Installation privilegiert ausfhrt,
werden hierbei auch bercksichtigt, wie das bei der Produktankndigung oder unter Verwendung
der Richtline AlwaysInstallElevated der Fall ist.
Hieraus resultiert die vornehmlich Verwendung der Eigenschaft Privileged fr die oben skizzierten
Anwendungsbeispiele, zumal im Rahmen der Validierung durch ICE86 explizit auf dessen bevorzugte
Verwendung hingewiesen wird.
Die sich hierunter verbergende Problematik unter Windows Vista und Windows Server 2008 sollte
offensichtlich sein. Die Eigenschaft AdminUser ist unter diesen Betriebssystemen niemals True, denn
der Benutzer ist kein Administrator, da eine eventuelle Zugehrigkeit zu dieser Benutzergruppe durch
die Benutzerkontensteuerung aberkannt wurde. Anders ist es bei der Eigenschaft Privileged; diese ist
whrend der UI-Sequenz, also im Client-Prozess ebenfalls nicht vorhanden, wird aber im Gegensatz zu
AdminUser im Server-Prozess auf True gesetzt, wenn die Installation mit erhhten Rechten ausgefhrt
wird. Dieser Algorithmus ist jedoch aus Grnden der Anwendungskompatibilitt nicht optimal
geeignet, wie das folgende Beispiel zeigt:
Sie prfen in einem Installationspaket in der Tabelle LaunchCondition die Eigenschaft Privileged ab,
um hiermit sicherzustellen, dass bei der Installation erhhte Rechte zur Verfgung stehen. Nun wird
diese berprfung durch die gleichnamige Standardaktion sowohl im Client- als auch im ServerProzess veranlasst. Es ist ja bekannt, dass erst whrend des Server-Prozesses die Eigenschaft
Privileged auf den realen Wert gesetzt wird, nachdem der Benutzer den UAC-Dialog erfolgreich
besttigt hat. Das bedeutet, dass die Ausfhrungsberechtigungen in der UI-Sequenz, also im ClientProzess niemals zutreffen knnen, wodurch die Installation an dieser Stelle beendet wird und der
Server-Prozess niemals erreicht wird.
Um dennoch eine relativ problemlose Ausfhrung nicht speziell angepasster Installationspakete zu
gewhrleiten wurde der Algorithmus zum Ermitteln der Eigenschaften Privileged und AdminUser
grundlegend gendert. Die Eigenschaft Privileged ist whrend der UI-Sequenz nun immer True.
Hierbei ist es unerheblich ob die Installation von einem echten Standardbenutzer ausgefhrt wird,
oder ob lediglich der gefilterte Token zur Verwendung kommt. Erst in der Ausfhrungssequenz wird
Privileged auf den realen Wert gesetzt. Werden fr die Installation erhhte Rechte bentigt muss deren
Verwendung durch den UAC-Dialog besttigt werden, so dass Privileged dann auch in der
Ausfhrungssequenz auf True gesetzt wird. Ein Standardbenutzer-Paket wird hingegen nicht
privilegiert ausgefhrt, so dass die Eigenschaft Privileged auf Null gesetzt wird. Der Algorithmus zum
Ermitteln der Eigenschaft AdminUser wurde in der Form angepasst, dass AdminUser immer einen
identischen Wert aufweist wie Privileged. Eine gute Hilfestellung bietet hier auch das
Installationsprotokoll, da entsprechende Hinweise darin zu finden sind:
MSI (c) (9C:84) [12:54:24:701]: MSI_LUA: Setting AdminUser property to 1 because this is the client
or the user has already permitted elevation
MSI (c) (9C:84) [12:54:24:701]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'.
228
MSI (c) (9C:84) [12:54:24:701]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'.
Aus dieser nderung des Algorithmus ergibt sich fr das oben skizzierte Beispiel nun ein genderter
Ablauf. Die UI-Sequenz wird immer durchlaufen; die relevante berprfung der Berechtigungen
erfolgt erst in der Ausfhrungssequenz, da hier reale Vergleichswerte vorliegen. Hieraus folgt, dass
nicht speziell auf die Benutzerkontensteuerung optimierte Installationspakete dennoch ausgefhrt
werden knnen. Abweichend ist der Zeitpunkt, an dem eine Installation auf Grund fehlender
Berechtigungen abgebrochen wird, da dieses nun erst nach der UI-Sequenz erfolgt.
Aus Grnden der Kompatibilitt wurde die neue Eigenschaft MSIUSEREALADMINDETECTION
eingefhrt. Wird diese Eigenschaft auf den Wert 1 gesetzt, wird der bisherige Algorithmus zur
Ermittlung der Eigenschaften AdminUser und Privileged verwendet.
Beim Erstellen von Installationspaketen fr Windows Vista und Windows Server 2008 sollten einige
Dinge hinsichtlich der Ausfhrungsbedingungen beachtet werden. Sollte es erforderlich sein, dass der
Client-Prozess bereits mit administrativen Privilegien ausgefhrt wird, sollten folgende Vorkehrungen
getroffen werden:
Die Verwendung erhhter Rechte ist durch die Eigenschaft Privileged in der Tabelle
LaunchCondition zu prfen.
Es ist ein Bootstrapper (setup.exe) zum Starten der Installation zu verwenden. Der Bootstrapper ist
mit einem Manifest zu versehen, mit dem die Ausfhrungsebene auf requireAdministrator
festgelegt wird.
Ist es hingegen ausreichend, dass erst whrend der Ausfhrungssequenz mit erhhten Privilegien
gearbeitet wird, so sind zunchst alle Referenzen auf die Eigenschaften AdminUser und Privileged zu
entfernen, die whrend der UI-Sequenz ausgewertet werden. Hierzu gehren auch entsprechende
Eintragungen in der Tabelle LaunchCondition. Die Prfung auf ausreichende Berechtigungen ist durch
eine Benutzerdefinierte Aktion vom Typ 19 zu veranlassen. Diese benutzerdefinierte Aktion ist aus
der Tabelle InstallExecuteSequence zu referenzieren, wenn die Installation nicht privilegiert ausgefhrt
wird, wie das auch in Listing 5.50 dargestellt wird.

<CustomAction Id="CheckPrivilges" Error ="Zur Installation sind erhhte Privilegien erforderlich."/>

<Custom Action="CheckPrivilges" Before ="LaunchConditions">NOT Privileged</Custom>
Listing 5.50: Darstellung der Prfung auf ausreichende Privilegien im WiX-Format
Die Verwendung einer benutzerdefinierten Aktion fr diese Zwecke ist erforderlich, da eine Nutzung
der Tabelle LaunchCondition fr diese Zwecke nicht immer zu einem aussagekrftigen Ergebnis fhrt.
Wird in einem solchen Szenario die bereits bekannte Eigenschaft MSIUSEREALADMINDETECTION
genutzt, fhrt dieses unweigerlich zum Installationsabbruch. Solche Szenarien und potentielle
Problemquellen sind gerade bei Installationspaketen zu vermeiden, die spezielle fr diese Plattformen
angepasst wurden.
Hinweis Beginn
Die neue Eigenschaft MsiRunningElevated wird vom Windows Installer automatisch gesetzt, wenn die
Installation
privilegiert
durchgefhrt
wird.
Diese
Eigenschaft
wird
nicht
durch
MSIUSEREALADMINDETECTION beeinflusst.
229
Kapitel 5
Hinweis Ende
Absicherung der Installationsquellen

Im privaten Umfeld ist es keine Besonderheit, dass Installationsprogramme von Wechselmedien
ausgefhrt werden. In Firmenumgebungen ist ein solches Vorgehen vielfach nicht gewnscht da
hierdurch der Benutzer ungewollten Zugang zu dem Computer erhlt. Aus diesem Grund war es bisher
nur Systemadministratoren mglich eine privilegierte Installation von einem Wechselmedium
auszufhren. Einem Standardbenutzer war es hingegen nur mglich, eine nicht privilegierte
Installation von einer solchen Installationsquelle auszufhren. Dieses Standardverhalten konnte durch
die Systemrichtlinie Verwendung von Medienquellen fr Benutzer mit erhhten Rechten aktivieren
(AllowLockdownMedia) verndert werden. Mit dem Windows Installer 4.0 wurde das
Standardverhalten verndert, da bei aktivierter Benutzerkontensteuerung das Wechselmedium im
privaten Umfeld nicht mehr verwendet werden konnte wie bisher.
Der Standardwert der Richtlinie ist nun von mehreren Faktoren abhngig. Handelt es sich um ein
Client-Betriebssystem und befindet sich der Computer in keiner Domne wird 1 als Standardwert
verwendet. Handelt es sich hingegen um ein Server-Betriebssystem oder befindet sich der Computer in
einer Domne ist der Standardwert hingegen 0. Der Wert 1 besagt hierbei, das es allen Benutzern
gestattet ist, Programme von Wechselmedien zu installieren, auch wenn das Installationsprogramm mit
erhhten Systemberechtigungen ausgefhrt wird. Wurde hingegen die Richtlinie gesetzt, wird natrlich
dieser Wert verwendet und der gerade dargestellte Algorithmus ignoriert, wie auch Abbildung 5.46
zeigt.
Abbildung 5.46: Bestimmen des Standardwertes der Richtlinie AllowLockDownMedia
Die Ausfhrung von benutzerdefinierten Aktionen zhlt unbestreitbar zu den komplexesten und
kritischsten Vorgngen im gesamten Installationsprozess. Dieses resultiert zum einen aus der
Forderung individuellen Programmcode in unterschiedlichen Formaten zu untersttzen und zum
anderen die Stabilitt des Installationsprozesses nicht zu beeintrchtigen. Zur Realisierung dieser
Anforderung wurden speziellen Objekte in den Windows Installer-Service integriert, die es
ermglichen, individuellen Programmcode in einer geschtzten Umgebung unter Verwendung
unterschiedlicher Sicherheitsmodelle isoliert auszufhren. Diese speziellen Objekte werden als Custom
Action-Server bezeichnet. Custom Action-Server knnen nach dem verwendeten Sicherheitsmodell
wie folgt kategorisiert werden:
230
Impersoniert: Der individuelle Programmcode wird in einem solchen Custom Action-Server

immer im Kontext des Benutzers ausgefhrt, auch wenn die Installation mit erhhten Rechten
erfolgt.
Elevated: Falls die Installation im privilegierten Kontext ausgefhrt wird, wird der Programmcode
in diesem Custom Action-Server ebenfalls privilegiert ausgefhrt. Wird die Installation in einem
nicht privilegierten Kontext ausgefhrt, erfolgt die Ausfhrung der benutzerdefinierten Aktionen
im impersonierten Server.
Wie bereits dargestellt, versteht man unter einem Custom Action-Server einen eigenen Prozess, in dem
benutzerdefinierter Code im Rahmen des Installationsvorgangs ausgefhrt wird. Verfgte unter den
bisherigen Betriebssystemen ein Benutzer ber administrative Privilegien, war es relativ unerheblich,
in welchem Custom Action-Server die benutzerdefinierte Aktion ausgefhrt wurde, da die Rechte in
allen Fllen ausreichend waren. Bei der Verwendung von Windows Vista und Windows Server 2008
ist dieses durch die Benutzerkontensteuerung nicht mehr der Fall. Der Impersonierte Custom ActionServer verwendet immer die Privilegien des Standardbenutzers; er nutzt also immer den
eingeschrnkten Token und hat somit nur eingeschrnkte Zugriffsrechte. Der Elevated Custom ActionServer verwendet wie gehabt die Privilegien des lokalen Systemkontos, wie dieses auch in Abbildung
5.47 dargestellt wird.
Abbildung 5.47: Privilegien der Custom Action-Server.
Sollen durch eine benutzerdefinierte Aktion nun Modifikationen am System vorgenommen werden, die
administrative Privilegien erfordern, mssen die zwei folgenden Kriterien zutreffen:
Die Installation muss privilegiert ausgefhrt werden.
Die benutzerdefinierte Aktion muss den Elevated Custom Action-Server verwenden.
Zum ersten Kriterium ist an dieser Stelle keine weitere Erluterung erforderlich. Das zweite Kriterium
ist umso relevanter, zumal es eine potentielle Problemquelle fr den Installationsprozess darstellen
kann. Es ist erforderlich die benutzerdefinierte Aktion fr die privilegierte Ausfhrung zu
231
Kapitel 5
kennzeichnen wozu das Attribut msidbCustomActionTypeNoImpersonate in der Spalte Type der

Tabelle CustomAction zu verwenden ist. Da solche Aktionen nur whrend der Skriptausfhrung
verwendet werden knnen, ist das Attribut msidbCustomActionTypeInScript ebenfalls der Spalte Type
hinzuzufgen. Im Weiteren ist natrlich sicherzustellen, dass die Aktion von der Tabelle
InstallExecuteSequence aufgerufen wird und hierin zwischen den Aktionen InstallInitialize und
InstallFinalize referenziert wird. Eine entsprechende Definition mit Windows Installer-XML ist in
Listing 5.51 dargestellt:
<CustomAction Id="ElevatedAction" DllEntry ="CreateDatabase" Impersonate ="no"
Execute="deferred" BinaryKey ="CADLL" />

<Custom Action="ElevatedAction" Before ="InstallFinalize" />
Listing 5.51: Definition einer Benutzerdefinierten Aktion mit Windows Installer-XML
Es sollte erkennbar sein, dass die Verwendung des privilegierten Custom Action-Servers unter
Windows Vista und Windows Server 2008 in den meisten Fllen erforderlich ist, so dass die
ordnungsgeme Verwendung der Attribute sicherzustellen ist. Leider stellt das Windows InstallerSDK keine Prfroutinen zur Verfgung, mit denen entsprechende Validierungen durchgefhrt werden
knnen.An dieser Stelle hilft jedoch ein kleines Codefragment weiter, welches die Prfung des richtig
gewhlten Custom Action-Servers vornimmt. Die Ermittlung der kritischen Aktionen wird unter
Verwendung der Deployment Tools Foundation durchgefhrt wie Listing 5.52 zeigt. Hierbei sei
anzumerken, dass Funktionen aus dem Namensraums Microsoft.Deployment.WindowsInstaller.Linq
verwendet werden, wodurch das Microsoft .NET Framework 3.5 erforderlich ist.
private void CheckCustomAction(string fileName)
{
// Datenbank ffnen
using (QDatabase database = new QDatabase(fileName, DatabaseOpenMode.ReadOnly))
{
// Alle Datenstze durchlaufen
foreach (CustomAction_ ca in database.CustomActions)
{
// Prfen ob die CA innerhalb des Skriptes ausgefhrt wird
if ((ca.Type & CustomActionTypes.InScript) == CustomActionTypes.InScript)
{
// Prfen ob das NoImpersonate-Flag gesetzt wurde
if ((ca.Type & CustomActionTypes.NoImpersonate) != CustomActionTypes.NoImpersonate )
{
// Flag wurde nicht gesetzt. Daher kann es bei UAC zu Problemen fhren
Console.WriteLine(ca.Action + ": " + ca.Type.ToString());
}
}
}
}
}
Listing 5.52: Ermitteln problematischer benutzerdefinierte Aktionen
232
Was auf den ersten Blick einfach aussieht und hinsichtlich der Migration einen nur geringen Aufwand
bedeutet, kann jedoch noch kritische Probleme nach sich ziehen. Grundstzlich sollte ja zunchst
davon ausgegangen werden, dass der Entwickler des Installationspaketes bestimmte
Grundberlegungen getroffen hatte, wenn er das Attribut msidbCustomActionTypeNoImpersonate
bisher nicht verwendet hat. In den wenigsten Fllen ist dieses auf fehlende Fachkenntnis oder einen
Fehler zurckzufhren. In den meisten Fllen wurde der personifizierte Custom Action-Server
verwendet, wenn mittels individueller Implementierung auf das Netzwerk zugegriffen werden musste.
In einem solchen Fall ist es natrlich nicht damit getan, das Attribut zu verndern, denn das fhrt mit
hoher Wahrscheinlichkeit zu einem Fehler, da dem lokalen Systemkonto diese Berechtigungen fehlen.
Hieraus folgt zwangslufig, dass tiefergehende nderungen im Design des Installationspaketes
vorzunehmen sind. Um hier einen entsprechenden Lsungsansatz implementieren zu knnen, ist
zunchst der Grund des Netzwerkzugriffs zu ermitteln. Falls der Netzwerkzugriff bentigt wird um auf
Dateien zuzugreifen, die fr die Installation bentigt werden, sollte an dieser Stelle geprft werden, ob
das einbetten der Dateien in den binren Datenspeicher des Installationspaketes an dieser Stelle
weiterhilft. Wird der Netzwerkzugriff hingegen bentigt um Informationen fr die Installation zu
ermitteln, sollte berlegt werden, ob diese Informationen nicht auch durch eine personifizierte Aktion
ermittelt werden knnen, die mit Standardbenutzerrechten ausgefhrt wird. Falls das mglich ist,
knnen die Informationen mit Hilfe der Eigenschaft CustomActionData an die privilegierte Aktion
bergeben werden.
Eine andere potentielle Problemquelle betrifft den Zugriff auf das Benutzerprofil. Hierunter ist
zunchst kein Berechtigungsproblem zu verstehen, denn solche Aktionen brauchen ja nicht privilegiert
ausgefhrt, da der Vollzugriff auf das Benutzerprofil gewhrleistet ist. Dieses Problem ist vielmehr in
der Verwendung eines privilegierten Bootstrappers zu sehen. Wird der Installationsprozess aus einem
privilegierten Prozess gestartet, steht das Profil des Benutzers, der die Installation startet nicht zur
Verfgung. Modifikationen werden zwangslufig im Profil des Benutzers vorgenommen, mit dessen
Privilegien die Installation ausgefhrt wird. Wird hingegen von einem privilegierten Custom ActionServer versucht, etwas in das Benutzerprofil zu schreiben, wird auch hier ein abweichendes, nmlich
das Systemprofil verwendet. Eine effektive und perspektivische Abhilfe ist nur durch ein Re-Design
des Installationspaketes mglich, wie dieses auch in entsprechenden Richtlinien vorgeschlagen wird.
Grundstzlich wird hier vorgeschlagen, alle benutzerspezifischen Konfigurationen beim ersten Starten
der Anwendung ausfhren zu lassen, so dass auf Informationen die das Benutzerprofil betreffen, im
Installationspaket verzichtet werden kann. Es mag sein, dass dieser Vorschlag widersprchlich zu den
Standardbenutzer-Paketen erscheint, das ist jedoch nicht beabsichtigt, denn bei diesen Paketen sind die
skizzierten Probleme nicht anzutreffen. Dieser Vorschlag und die Problemflle beziehen sich
ausnahmslos auf Installationspakete die vollstndige Privilegien bentigen.
Windows Installer und der Schild

Eine Designrichtlinie von Windows Vista und Windows Server 2008 besagt, dass der Benutzer durch
grafische Elemente darauf hingewiesen werden soll, falls zur Ausfhrung administrative Privilegien
erforderlich sind. Zu diesem Zweck mssen Symbole und Schaltflchen zustzlich mit dem
Sicherheitsschildsymbol gekennzeichnet werden, falls die damit ausgefhrte Aktion entsprechende
Privilegien erfordert. Im Umfeld des Windows Installers sind zwei hierauf abzielende Szenarien zu
betrachten.
Im ersten Fall geht es um die Kennzeichnung des Installationsdialogs. Wie bereits vorhergehend
erlutert, wird der UAC-Besttigungsdialog beim Wechsel vom Client- zum Server-Prozess angezeigt.
Hieraus folgt, dass die entsprechende Schaltflche des finalen Dialogs mit dem Symbol zu
233
Kapitel 5
kennzeichnen ist, wie Abbildung 5.48 zeigt.
Abbildung 5.48: Kennzeichnung der Schaltflche mit dem Sicherheitsschildsymbol
Die Kennzeichnung wird hierzu in der Tabelle Control vorgenommen. Einem Steuerelement vom Typ
PushButton ist das neue Attribut msidbControlAttributesElevationShield (8388608) zuzuordnen. Das
Sicherheitsschildsymbol wird angezeigt wenn das Attribut gesetzt wurde und die Installation mit den
Rechten des Standardbenutzers ausgefhrt wird. Es wird nicht angezeigt, wenn die Installation bereits
mit erhhten Rechten ausgefhrt wird, wie das bei der Verwendung einer setup.exe der Fall wre. Die
Verwendung des Installationspaketes unter einer lteren Version des Windows Installers ist problemlos
mglich; ltere Installer-Versionen ignorieren das Attribut.
Bei der Verwendung von Windows Installer-XML ist das Attribut ElevationShield fr diesen
Steuerelementtyp zu verwenden.
<Control Id="NextButton" Type="PushButton" X="230" Y="243" Width="66" Height="17"
Default="yes" Text="Installieren" ElevationShield="yes">
<Publish Event="EndDialog" Value="Return"><![CDATA[OutOfDiskSpace <> 1]]></Publish>
</Control>
Werden hingegen die in Windows Installer-XML enthaltenen Standarddialoge verwendet, sind keine
spezifischen Vorkehrungen zu treffen. Die Verwendung des Symbols ist jedoch hierbei mit der
Eigenschaft ALLUSERS verknpft, so dass diese ebenfalls zu setzen ist.
Der zweite Fall betrifft die Dateiverknpfungen, oder besser gesagt die Symbole dieser
Verknpfungen. Gem den Richtlinien fr Windows Vista und Windows Server 2008 sind auch
Dateiverknpfungen mit dem Sicherheitsschildsymbol zu kennzeichnen, wenn die zu startende
Anwendung administrative Privilegien bentigt. Normalerweise wird dieses automatisch vom
Betriebssystem oder detaillierter betrachtet durch die Windows-Shell umgesetzt. Die Windows-Shell
prft ob die referenzierte Anwendung fr die Verwendung administrativer Privilegien gekennzeichnet
wurde. Ist dieses der Fall und wird die Windows-Shell mit eingeschrnkten Privilegien ausgefhrt,
wird die Dateiverknpfung mit dem Sicherheitsschildsymbol gekennzeichnet. Dieses Verhalten ist
ganz einfach zu testen. Stellen Sie sicher, dass auf dem Desktop einige Dateiverknpfungen vorhanden
234
sind, die vom Betriebssystem automatisch mit dem Sicherheitsschildsymbol gekennzeichnet sind.
Schlieen Sie zunchst alle geffneten Instanzen des Windows-Explorers und starten Sie dann den
Windows-Explorer mit vollstndigen Privilegien, beispielsweise ber das Kontextmen Als
Administrator ausfhren. Navigieren Sie nun in diesem Explorer-Fenster zum Desktop. Sie werden
feststellen, dass die betreffenden Symbole keine Kennzeichnung mehr aufweisen. Das Starten dieser
Anwendungen funktioniert dann auch ohne erneute Darstellung des Besttigungsdialogs.
Diese Funktionalitt ist jedoch nur fr Standard-Dateiverknpfungen vorhanden, also bei
Verknpfungen die eine Datei direkt referenzieren. Windows Installer untersttzt jedoch auch die
sogenannten Angekndigten Verknpfungen (Advertised Shortcuts) und die sorgen in diesem Kontext
fr Probleme. Zur Identifizierung der Dateiverknpfung gengt ein Blick in den Eigenschaftendialog.
Bei einer Standardverknpfung befindet sich im Feld Ziel ein Verweis auf das jeweilige
Verknpfungsziel. Bei einem Advertised Shortcut ist das Feld Ziel deaktiviert und es findet sich dort
lediglich eine Bezeichnung fr die zu startende Anwendung. Der einfachste Lsungsansatz lge nun im
vollstndigen Verzicht auf angekndigte Verknpfungen, wie das unter Zuhilfenahme der Eigenschaft
DISABLEADVTSHORTCUTS mglich ist. Aber diese Vorgehensweise sollte natrlich nicht der
Normalfall sein, denn durch den Verzicht auf diese Verknpfungsarten werden einige
Grundfunktionalitten des Windows Installers auer Kraft gesetzt. Besser wre es an dieser Stelle
qualifiziertere Mittel zu verwenden um somit alle denkbaren Szenarien abzudecken.
Mit einem Advertised Shortcut wird keine Datei oder ein anderes Ziel direkt referenziert; eine solche
Verknpfung referenziert immer eine Windows Installer-Komponente oder detaillierter ausgedrckt
die Schlsselressource (KeyPath) einer solchen Komponente. Somit kann eine solche Verknpfung
auch gut mit dem Begriff der logischen Verknpfung umschrieben werden. Die Definition der
Dateiverknpfung wird in der Tabelle Shortcut vorgenommen. Im einfachen Fall, also fr eine
Standard-Dateiverknpfung wird die zu referenzierende Datei in dem Feld Target angegeben. Bei der
Gestaltung einer angekndigten Verknpfung ist diesem Feld die Referenz auf das Feature
hinzuzufgen, das hiermit verknpft wird. Da ein Feature die kleinste installierbare Einheit aus Sicht
des Anwenders darstellt, wird eine solche Dateiverknpfung auf dem Zielsystem angelegt, wenn das
entsprechende Feature zur Installation ausgewhlt wurde. Hierbei ist es unerheblich ob das Feature fr
die physische Installation, fr die Ausfhrung vom Quellmedium oder fr die Installation bei der
ersten Verwendung markiert wurde. Ein Advertised Shortcut wird auch erstellt, wenn die indirekt
referenzierte Datei nicht physisch dem System hinzugefgt wurde. Hier ist es ausreichend dass das
zugehrende Feature fr eine Installationsart bestimmt wurde.
Bei der Aktivierung einer Dateiverknpfung wird seitens der Windows-Shell geprft, ob es sich um
eine physische Dateiverknpfung handelt, also einfach ausgedrckt, ob die referenzierte Datei existiert
und gestartet werden kann. Ist dieses nicht der Fall, findet eine Interaktion mit dem Windows InstallerService statt. Hierbei wird dem Windows Installer-Service der Pfad zu der Verknpfung bergeben, so
dass geprft werden kann, ob es sich um einen gltigen Advertised Shortcut handelt. Falls dieses
zutreffend ist, werden Informationen zum Produkt, zum Feature und letztlich zur Komponente
ermittelt. Anschlieend wird seitens des Windows Installers geprft, ob diese Komponente bereits
vorhanden ist und ob die Schlsselressourcen aller Komponenten des referenzierten Features ebenfalls
vorhanden sind. Ist dieses nicht der Fall, findet eine Reparatur auf Ebene des Features statt.
Anschlieend wird der absolute Pfad zu der Schlsselressource der referenzierten Komponente
ermittelt und wieder an die Windows-Shell zurck gegeben. Die entsprechende Datei wird nun
gestartet. Das nachfolgende Listing 5.53 zeigt die erforderlichen programmtechnischen
Implementierungen auf Basis der Deployment Tools Foundation.
private void GetShortCutInfo(string shortcutFileName)
235
Kapitel 5
{
// Ermitteln der relevanten Informationen des Shortcuts
ShortcutTarget target = Installer.GetShortcutTarget(shortcutFileName);
// Pfad zu der Schlsselressource der Komponente bestimmen,
// hierbei eine Reparatur des Features ausfhren (falls erforderlich)
string componentPath = Installer.ProvideComponent(target.ProductCode,
target.Feature, target.ComponentCode, InstallMode.Default);
// Datei starten (normalerweise durch die Windows-Shell)
Process.Start(componentPath);
}
Listing 5.53: Ermitteln der Eigenschaften und Verwenden einer angekndigten Dateiverknpfung
Die indirekte Referenzierung einer Datei durch einen Advertised Shortcut hat natrlich auch Einfluss
auf das zu verwendende Symbol. Bei einer regulren Verknpfung wird eine Datei referenziert die
Ressourcen in Form von Symbolen enthlt und von denen ein Symbol zur Darstellung ausgewhlt
wurde. Beim Advertised Shortcut ist das nicht mglich, denn eine solche Verknpfung kann bereits auf
dem System vorhanden sein, ohne dass die zu startende Datei physisch existiert. Dennoch wird in
einem solchen Fall bereits das regulre Symbol fr die Verknpfung angezeigt. Dieses wird mglich,
da sich smtliche Symbole in einer separaten Symboldatei befinden, die sich im binren Datenspeicher
des Installations-Paketes befindet. Bei der Installation oder bei der Ankndigung werden diese
Symboldateien im produktspezifischen Windows Installer-Repository abgelegt und von den
Verknpfungen verwendet.
Die Problematik mit dem Sicherheitsschildsymbol sollte nun deutlich werden. Die Windows-Shell
kann keinen direkten Bezug zur referenzierten Datei herstellen, wodurch die konfigurierte
Ausfhrungsebene ebenfalls nicht festgestellt werden kann. Somit kann das Sicherheitsschildsymbol
nicht angezeigt werden. Um die Anzeige des Schilds dennoch zu ermglichen ist es erforderlich, ein
Manifest in die separate Symboldatei zu integrieren, mit dem die Ausfhrungsebene entsprechend
festgelegt wird. Enthlt ein Produkt mehrere Anwendungen, die unterschiedliche Ausfhrungsebenen
bentigen, sind ebenfalls unterschiedliche Symboldateien zu verwenden.
Im ersten Schritt wird ein Manifest bentigt, in dem die entsprechende Ausfhrungsebene, in der Regel
requireAdministrator festgelegt wird.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="AdminIcon"
type="win32"/>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
236
Als nchstes wird die Ressource Skriptdatei (.rc) bentigt, in der die zu verwendenden Symbole
referenziert werden.
// base resource script.
//
#include "afxres.h"
#define IDI_ICON1
#define MANIFEST_RESOURCE_ID
101
1
/////////////////////////////////////////////////////////////////////////////
//
// Icon
//
// Icon with lowest ID value placed first to ensure application icon
// remains consistent on all systems.
IDI_ICON1
ICON
"icon.ico"
/////////////////////////////////////////////////////////////////////////////
//
// RT_MANIFEST
//
MANIFEST_RESOURCE_ID
RT_MANIFEST
"admin.manifest"
/////////////////////////////////////////////////////////////////////////////
Hierbei ist icon.ico die Bezeichnung der Symboldatei, die in die Ressource integriert werden soll und
admin.manifest die Manifest-Datei. Diese Ressource-Skriptdatei muss im nchsten Schritt kompiliert
werden, wozu der Windows Resource Compiler zu verwenden ist.
rc adminicon.rc
Das Ergebnis dieser Aktion ist die Datei adminicon.res, aus der zum Schluss eine RessourcenBibliothek zu erstellen ist. Windows Installer erwartet, dass diese Bibliotheken die identische
Dateiendung aufweisen, wie die Dateien, die diese verwenden. Zur Erzeugung der Bibliothek wird der
Microsoft Incremental Linker verwendet.
link adminicon.res /noentry /machine:x86 /dll /out:adminicon.exe
Das Ergebnis ist die Ressourcen-Bibliothek icon.exe, die nun in einem Windows Installer-Paket
verwendet werden kann. Im bereits bekannten Listing 5.49 wird dieses unter Verwendung von
Windows Installer-XML demonstriert.
237
Kapitel 5

Die Benutzerkontensteuerung von Windows Vista und Windows Server 2008 nimmt tiefgreifende und
sicherheitsrelevante nderungen am System vor. Aus den bisherigen Erluterungen sollte ersichtlich
geworden sein, dass es gilt, einige Besonderheiten und Fallstricke zu beachten und wenn mglich zu
vermeiden. Vielfach sind entsprechende Lsungsszenarien nicht einfach umsetzbar, da Problemflle
hufig erst auf den Live-Systemen, also im produktiven Umfeld auftreten. An dieser Stelle leistet die
Windows Installer-Protokollierung gute Hilfe, denn viele Informationen die die
Benutzerkontensteuerung betreffen, werden dem Protokoll angefgt, wenn es im Ausfhrlichen Modus
(Verbose Logging) erstellt wurde.
Eine der wesentlichsten Problemflle betrifft die Verwendung von benutzerdefinierten Aktionen und
schwerpunktmig der Frage, wie festgestellt werden kann, dass der Zugriff verweigert wurde. Durch
die Vielzahl der mglichen benutzerdefinierten Aktionen sind zwangslufig unterschiedliche
Behandlungen im Fehlerfall vorhanden. Einer benutzerdefinierten Aktion wird durch das WindowsAPI zwar der Fehler 0x80070005 (Zugriff verweigert) mitgeteilt, aber inwieweit darauf reagiert wird,
liegt an der individuellen Implementierung. Normalerweise sollte eine benutzerdefinierte Aktion so
geschrieben sein, dass Fehler immer dem Installationsprotokoll angefgt werden. Leider ist dieses die
Theorie, die Praxis sieht (noch) anders aus. Aus diesem Grund sollte bei der Fehleranalyse wie folgt
vorgegangen werden:
Zunchst ist nach dem Rckgabewert (Return Value) 3 zu suchen. Die im Installationsprotokoll
davor aufgefhrte Aktion ist die Fehlerquelle. Handelt es sich hierbei um eine benutzerdefinierte
Aktion, sind sie fndig geworden.
Sie sollten dann die Installation erneut ausfhren, wobei sie fr die komplette Installation
vollstndige Privilegien verwenden. Prfen sie, ob die gleiche benutzerdefinierte Aktion nun
ausgefhrt wird oder ebenfalls fehlschlgt.
Hiermit wurde zumindest die Problemquelle identifiziert, zur Frage nach dem Warum wurden einige
Antworten bereits in diesem Kapitel gegeben. Vielfach handelt es sich jedoch um Probleme, die durch
das Fehlen des Attributs msidbCustomActionTypeNoImpersonate verursacht werden. Zur Fehlersuche
sollte hierbei das Installationsprotokoll verwendet werden, denn die Attribute einer benutzerdefinierten
Aktion werden dem Protokoll angefgt wie, der folgende Auszug demonstriert.
MSI (s) (FC:88) [10:35:50:086]: Executing op: CustomActionSchedule(Action=AddAccount,ActionType=1025,
Source=BinaryData,Target=CreateAccount,CustomActionData=MSI)
Die relevanten Informationen befinden sich hierbei hinter dem Parameter ActionType. Der Wert
1025 bedeutet zunchst dass die benutzerdefinierte Aktion in Form einer Objektbibliothek
verwendet wird, die sich als binre Quelle im Installationspaket befindet (msidbCustomActionTypeDll
+ msidbCustomActionTypeBinaryData). Weiterhin besagt dieser Wert dass die benutzerdefinierte
Aktion
whrend
der
Ausfhrung
des
Installationsskriptes
mit
ausgefhrt
wird
(msidbCustomActionTypeInScript). Das Attribut msidbCustomActionTypeNoImpersonate wurde somit
nicht gesetzt, wodurch dieses durchaus die Problemquelle sein knnte. Der verwendete Aktionstyp war
in diesem Beispiel sehr einfach, doch Werte wie 11649 sind da schon schwieriger zu entschlsseln.
Mit Hilfe der Deployment Tools Foundation lsst sich dieses jedoch durch ein sehr kurzes
Codefragment realisieren.
// Aktionstyp bestimmen
CustomActionTypes actionType = (CustomActionTypes)11649;
238
Console.WriteLine(actionType.ToString());
// Ausgabe: Dll, Async, FirstSequence, InScript, NoImpersonate, HideTarget
Es ist somit erkennbar, dass die Probleme vielfach in Verbindung mit der Benutzerkontensteuerung
stehen, so dass es hilfreich ist die spezifischen Eintragungen zu kennen und zu analysieren. Wie spter
noch erlutert wird, ist der Windows Installer 4.5 auch fr die Betriebssysteme Windows XP und
Windows Server 2003 verfgbar. Diese Betriebssysteme verfgen jedoch ber keine
Benutzerkontensteuerung, so dass die folgende Eintragung hierbei im Installationsprotokoll zu finden
ist:
MSI (s) (28:B8) [11:27:55:099]: MSI_LUA: Credential prompt functionality not
available on this operating system
Falls jedoch ein Betriebssystem verwendet wird, dass die Benutzerkontensteuerung untersttzt, wird
die nachfolgende Meldung ausgegeben, falls die Installation bereits privilegiert ausgefhrt wird:
MSI (s) (FC:88) [10:35:49:453]: MSI_LUA: Credential prompt not required, user is an admin
Falls das Produkt zur Verwendung mit erhhten Privilegien bereits angekndigt wurde, oder fr eine
verwaltete Anwendung der Wartungsmodus gestartet wird, erscheint ebenfalls kein UACBesttigungsdialog:
MSI (s) (38:20) [12:31:36:766]: MSI_LUA: Credential prompt is not required at this point, product is managed
Auch bei der Verwendung von Standardbenutzer-Paketen ist die Anzeige des Dialogs nicht
erforderlich, da die Privilegien des Benutzers ausreichend sind. Hierauf weist der folgende Eintrag hin:
MSI (s) (38:EC) [12:25:03:339]: MSI_LUA: Package is marked as LUA installation
capable with no elevation required
Im einem weiteren Fall wird der Dialog ebenfalls nicht angezeigt, nmlich falls die Systemrichtlinie
AlwaysInstallElevated sowohl fr die Computer- als auch die Benutzerkonfiguration festgelegt wurde:
MSI (s) (38:A0) [12:37:25:862]: MSI_LUA: No credentials required as all installs will
run elevated due to AlwaysInstallElevated policy setting
Selbstverstndlich wird der UAC-Besttigungsdialog auch nicht angezeigt, wenn die Installation im
unbeaufsichtigten Modus (silent Installation) ausgefhrt wird.
MSI (s) (38:60) [12:19:16:145]: MSI_LUA: Installation UI level is silent, no credential elevation is possible
Die bisherigen Grnde, die zur Nicht-Anzeige des Dialogs fhrten, ermglichten dennoch eine
privilegierte Installation. Im Gegensatz dazu kann eine unbeaufsichtigte Installation auf einen Fehler
laufen, wenn die erforderlichen Rechte nicht vorhanden sind. Hierbei ist sicherzustellen, dass die
erforderlichen Privilegien bereits vor dem Aufruf der Installation vorhanden sind, oder dass die
Ausfhrung mit den Privilegien des Standardbenutzers ausreichend ist. Ansonsten wird kein Dialog
angezeigt und es wird somit keine Mglichkeit gegeben, die Verwendung erhhter Privilegien zu
besttigen. Abweichungen in diesem Standardverhalten knnen sich natrlich ergeben, wenn die
Sicherheitsrichtlinien fr die Benutzerkontensteuerung modifiziert werden, so dass automatisch mit
erhhten Privilegien installiert wird, was durch die Richtlinie Benutzerkontensteuerung: Verhalten
der
Benutzeraufforderung
mit
erhhten
Rechten
fr
Administratoren
im
Administratorbesttigungsmodus mglich wre.
239
Kapitel 5
Sollten alle diese Eventualitten nicht gegeben sein und wird die Installation gestartet, wird der
Besttigungsdialag angezeigt, falls das Installationspaket erhhte Privilegien erfordert.
MSI (s) (38:54) [16:18:54:217]: MSI_LUA: Elevation required to install product, will prompt for credentials
Die darauf folgenden Zeilen im Installationsprotokoll enthalten das Ergebnis der Aktion und geben
Auskunft ber die Privilegien, die anschlieend verwendet werden.
MSI (s) (30:B4) [12:54:29:842]: MSI_LUA: Credential Request return = 0x0
MSI (s) (30:B4) [12:54:29:842]: MSI_LUA: Elevated credential consent provided. Install will run elevated
Falls die Aktion nicht fehlerfrei ausgefhrt wird, enthlt der Rckgabewert die entsprechende
Fehlernummer. In dem folgenden Beispiel ist es 0x800704C7, da die Aktion vom Benutzer
abgebrochen wurde.
MSI (s) (38:D8) [16:33:30:861]: MSI_LUA: Credential Request return = 0x800704C7
Falls der Application Information Service oder andere Bestandteile der UAC-Infrastruktur einen Fehler
verursachen, findet sich der folgenden Eintrag:
MSI (s) (38:D8) [16:33:30:861]: MSI_LUA: Failed to obtain credentials. Error = 0x??????
Vielfach stellt sich die Frage, ob das zu installierende Paket auch die Verwendung von LUA-Patches
untersttzt. Wie bereits angedeutet, finden sich entsprechende Informationen in der
Operationsanweisung ProductInfo. Der relevante Parameter hierbei ist LUASetting. Ist dieser
Parameter auf den Wert 1 gesetzt, handelt es sich um eine autorisierte Anwendung, die LUAPatches untersttzt.
MSI (s) (38:D0) [16:31:52:124]: Executing op: ProductInfo(
ProductKey={5FC3B67B-D782-491C-AFE8-08A5F19647ED},
ProductName=Vista UAC Admin,PackageName=UACAdmin.msi,Language=1031,Version=16777216,
Assignment=1,ObsoleteArg=0,ProductIcon=NonAdminIcon.exe,0,,
PackageCode={7CEF4C66-D23D-40EA-8822-78A664E3EFAE},,,InstanceType=0,LUASetting=1,
Ist diesem Parameter hingegen der Wert 0 zugewiesen, wird LUA-Patching fr diese Anwendung
nicht untersttzt. Das Installationsprotokoll enthlt in diesem Fall zustzliche Informationen ber die
entsprechende Begrndung. Mgliche Eintragungen wren:
MSI (s) (38:AC) [16:44:28:270]: LUA patching is disabled: missing MsiPatchCertificate table
oder
MSI (s) (AC:00) [16:16:43:148]: LUA patching is disabled: not available on server SKUs
oder
MSI (s) (38:30) [16:53:19:288]: LUA patching is disabled: LUA patching is completely disabled
on the machine (by machine policy)
oder
MSI (s) (38:0C) [16:54:50:776]: LUA patching is disabled: DISABLELUAPATCHING property was set
240
oder
MSI (s) (38:9C) [16:55:42:973]: LUA patching is disabled: not run for non-admins
oder
MSI (s) (38:1C) [16:57:34:626]: LUA patching is disabled: not available for per-user installs
Hilfreich sind auch noch die Eintragungen, die auf die privilegierte Ausfhrung der Installation
hinweisen.
MSI (s) (38:1C) [16:57:34:595]: MSI_LUA: Setting MsiRunningElevated property to 1 because the
install is already running elevated.
Eine potentielle Fehlerquelle ist und bleibt die Verwendung der Eigenschaft AdminUser. Im
Normalfall findet sich die folgende Eintragung:
MSI (c) (D8:DC) [16:54:47:527]: MSI_LUA: Setting AdminUser property to 1 because this is the
client or the user has already permitted elevation
Falls jedoch der ursprngliche Algorithmus zum ermitteln dieser Eigenschaft verwendet wurde, ist die
Eigenschaft MSIREALADMINDETECTION, in der Eigenschaftenauflistung am Ende des Protokolls zu
finden.
Es wird deutlich, dass eine Vielzahl von Informationen im Installationsprotokoll auf die Verwendung
der Benutzerkontensteuerung hinweisen. Wichtig ist hierbei die Kennzeichnung der Eintragungen,
denn alle verfgen ber den Prfix MSI_LUA, so dass die Identifikation entsprechend ausgerichteter
Fehlerbilder, durch eine Suche nach der Zeichenfolge vereinfacht wird.
Fazit
Die Benutzerkontensteuerung ist eine der wichtigsten Pfeiler im Sicherheitskonzept von Windows
Vista und Windows Server 2008. Die Relevanz liegt darin begrndet, dass alle normalen Aktivitten
mit den Privilegien eines Standardbenutzers ausgefhrt werden. Das Sicherheitsschildsymbol wird zur
Kennzeichnung von Operationen verwendet, die hhere Privilegien erfordern, als die eines
Standardbenutzers. Fhrt der Benutzer eine solche Aktion aus, wird ein Dialog angezeigt, in dem der
Benutzer die Verwendung erhhter explizit Privilegien besttigen muss. Im Folgenden wird ein neuer
Prozess gestartet, der ber die vollstndigen Privilegien des entsprechenden Tokens verfgt und somit
nahezu alle Aktivitten vornehmen kann. Die meisten Installationen fhren systemweite
Modifikationen durch, so dass fast immer administrative Privilegien bentigt werden. Aus diesem
Grund ist festzustellen, dass der Einfluss der Benutzerkontensteuerung auf den Installationsprozess
recht gro ist. Umso wichtiger ist es bereits frhzeitig darauf zu reagieren, indem bei der Erstellung
von Installationspaketen die folgenden Vorgaben beachtet werden:
Falls in der Tabelle InstallUISequence die Aktionsausfhrung vom Installationskontext abhngig
gemacht werden muss, ist hierzu eine Bedingung zu verwenden, die auf der Eigenschaft Privileged
basiert. Verwenden Sie keine Bedingung die auf der Eigenschaft AdminUser basiert.
Falls in der Tabelle InstallExecuteSequence die Installationsausfhrung vom Installationskontext
abhngig gemacht werden muss, verwenden Sie eine Benutzerdefinierte Aktion vom Typ 19,
deren Ausfhrung mit einer Bedingung versehen ist, die auf der Eigenschaft Privileged basiert.
241
Kapitel 5
Verwenden Sie hierfr nicht die Tabelle LaunchCondition.

Verwenden Sie immer Benutzerdefinierte Aktionen mit verzgerter Ausfhrung um nderungen
am System durchzufhren, die durch Windows Installer Funktionalitten nicht abgedeckt werden.
Markieren
Sie
diese
fr
die
Ausfhrung
im
Systemkontext
(msidbCustomActionTypeNoImpersonate), falls die Modifikationen sich auf Systemteile beziehen,
die nicht benutzerspezifisch sind.
Entfernen Sie das Attribut msidbSumInfoSourceTypeLUAPackage vom Wert der Eigenschaft
PID_WORDCOUNT des Summary Information Streams, falls die Installation vollstndige
Privilegien erfordert. Fgen Sie dieses Bit hinzu, falls fr die Installation Standardprivilegien
ausreichend sind. Setzen Sie in diesem Fall zustzlich die Eigenschaft ALLUSERS auf eine leere
Zeichenfolge.
Fgen Sie der Tabelle MsiPatchCertificate des Originalinstallationspaketes ein Zertifikat hinzu und
signieren Sie alle spteren Patches fr dieses Produkt mit dem Zertifikat.
Falls vollstndige Privilegien fr die Installation erforderlich sind, ist dieses auch visuell
hervorzuheben. Kennzeichnen Sie hierzu die Steuerelemente vom Typ PushButton mit Attribut
msidbControlAttributesElevationShield, die den Wechsel zum Server-Prozess ermglichen.
Diese Modifikationen sollten bereits bei allen aktuellen Installationspaketen vorgenommen werden,
um somit bereits heute, die Weichen fr eine erfolgreiche Installation unter Windows Vista und
Windows Server 2008 zu stellen. Zu beachten ist hierbei, dass diese Vorkehrungen keinen Einfluss auf
den Installationsprozess bei Verwendung einer lteren Version des Windows Installers haben und
somit zu keinen Inkompatibilitten fhren knnen.
242
Computerneustarts im
Installationsprozess

Verwendung des Neustart-Managers durch den Windows Installer
Fazit
243
245
260
272
291
Fr einige Entwickler von Installationspaketen sind Computerneustarts ein notwendiges bel, fr

andere Entwickler wiederum geht kein Weg an einem Neustart vorbei. Die letzte Kategorie der
Entwickler hat die aus grauen Vorzeiten der Informationstechnologie stammenden
Standardvorgehensweise Ein Reboot tut immer gut immer noch verinnerlicht. Mit Sicherheit ist
dieser Ansatz nicht mehr zeitgem und sollte berdacht werden. In der heutigen Zeit sind effiziente
und verfgbare Computersysteme gefragt, wodurch die Notwendigkeit bestehen sollte,
Computerneustarts zu reduzieren. Die andere Kategorie der Entwickler mchte nach Mglichkeit ohne
Neustarts auskommen, akzeptiert aber mitunter auch maximal einen Computerneustart, der nach der
Installation einer Vielzahl von Anwendungen ausgefhrt wird. Zur Erreichung dieses Ziels wird
analysiert, verglichen und diskutiert um letztlich einen eigenen Algorithmus zur Verwaltung der
Neustarts zu entwickeln. Beide Lsungsanstze haben natrlich ihre Berechtigung und auch ihre
Vorteile, wenngleich keiner dieser Anstze zielfhrend zu sein scheint, da entweder die Verfgbarkeit
oder die Stabilitt des Computersystems nicht gegeben sind.

Die gerade dargestellten Paradigmen sind natrlich nur eine kleine Anzahl der mglichen Szenarien,
die zu einem Neustart fhren oder auch einen Computerneustart vermeiden knnen. Das Ziel sollte
natrlich immer in der Reduzierung der Computerneustarts im Rahmen der Anwendungsinstallation
sein, wobei die Stabilitt der Anwendungen im Mittelpunkt stehen sollte. Zur Reduzierung der
Neustarts ist es natrlich erst mal wichtig, die mglichen Ursachen zu hierfr zu kennen, die sich in
vier Kategorien unterteilen lassen, wie dieses auch Abbildung 6.49 darstellt.
243
Kapitel 6
Computerneustarts im Installationsprozess
Abbildung 6.49: Ursachen fr einen Computerneustart whrend der Installation
Wie bereits im oberen Beispiel angesprochen liegt ein wesentlicher Grund fr einen Computerneustart
in einem Kommunikationsproblem. Hiermit ist gemeint, dass dem Benutzer suggeriert wird, dass er
den Computer nach der Installation neu starten muss, obwohl vielfach keine technischen Grnde
vorliegen. Diese Aufforderung kann hierbei auf klassische Weise ber die Dokumentation oder
technisch ber einen Dialog im Installationsprogramm erfolgen. Eine solche Vorgehensweise ist hufig
historisch begrndet, da frher auf einen Computerneustart nach der Installation nicht verzichtet
werden konnte. Von dieser Vorgehensweise sollte unbedingt Abstand genommen werden, denn die
heutigen technischen Mglichkeiten zur Erkennung eines Neustarts sind mit denen frherer Systeme
nicht mehr vergleichbar.
Ein anderer Problembereich ist im Konfigurationssektor zu finden. Hierunter sind Szenarien zu
verstehen, in denen das Installationsprogramm selbst konfiguriert oder aktualisiert wird, wie auch der
Windows Installer. Dieser wurde bis zur Version 2.0 als Windows Installer-Paket ausgeliefert,
wodurch er sich nicht selbst aktualisieren konnte. Es gab zwar die Option des verzgerten Neustarts,
aber sptestens nach Abschluss der Installation musste ein Computerneustart erfolgen. Solche
Szenarien sind mitunter noch zu beobachten; eine effektive Abhilfe gibt es aus technischen Grnden
jedoch nicht.
Eine ganz andere Ursache ist bei den Prozessablufen zu finden. Hiermit sind Problemquellen gemeint,
die durch Umgestaltung der Installation oder Bercksichtigung von Richtlinien beseitigt werden
knnen. Unter diesem Gesichtspunkt wurde beispielsweise die Aktualisierung der Windows-Plattform
optimiert. Es enthlt nun jeder Patch eine Kennung, ob er als kritisch eingestuft wurde oder nicht. Falls
es sich um einen unkritischen Patch handelt, wird er zwar installiert, aber auf einen eventuell
notwendigen Computerneustart wird zu diesem Zeitpunkt verzichtet. Dieser wird durch den Benutzer
beim nchsten Starten des Computers unbewusst selbst veranlasst. Weiterhin sind in dieser Kategorie
244
Lsungsanstze zu finden, die sich an Richtlinien orientieren. So wird in vielen Richtlinien von der
Selbstregistrierung von COM-Komponenten abgeraten. Die Selbstregistrierung des Windows Installers
kann mit einem Aufruf von regsvr32.exe verglichen werden. Es wird die interne Funktion
DLLRegisterServer() der jeweiligen COM-Komponente aufgerufen. Fr einen ordnungsgemen
Aufruf der Funktion ist es jedoch erforderlich, dass sich die Komponente im jeweiligen
Installationsverzeichnis auf dem Zielsystem befindet. Ist eine vorherige Version der Komponente in
Verwendung muss das System im Rahmen der Installation zunchst neu gestartet werden, bevor die
eigentliche Registrierung erfolgen kann.
Wichtig Beginn
Soll die Anwendung fr Windows Vista zertifiziert werden, ist ein Neustart whrend der Installation
zu vermeiden. Im Weiteren fordern diese Richtlinien den Verzicht der Selbstregistrierung im
Installationsprozess. Entsprechende Vorgaben sind in den Best Practices des Windows Installer-Teams
zu finden.
Wichtig Ende
Der letzte Grund fr einen Computerneustart kommt in der Praxis sehr hufig vor. Hierbei kann eine
Datei nicht ersetzt oder gelscht werden, da sie derzeitig verwendet wird. Dieses relativ einfach
aussehende Szenario bildet jedoch die Grundlage fr den Rest des Kapitels. Aus diesem Grund folgt
zunchst eine Betrachtung der Ablufe des Installationsprozesses, die zur Ermittlung der verwendeten
Dateien und der darauf basierenden Vorgehensweise des Windows Installer relevant sind.
Der Windows Installer enthlt seit jeher viele Funktionalitten, mit denen der Neustart des Computers
und alle damit verbundenen Darstellungsformen beeinflusst werden knnen. So kann festgelegt
werden, ob dem Benutzer ein Dialog angezeigt wird, in dem er den Neustart explizit besttigen muss
oder ob der Neustart automatisch ausgefhrt wird. Im Weiteren stehen natrlichen Mechanismen zur
Verfgung um einen Neustart direkt oder indirekt zu veranlassen:
Durch die Aktionen ForceReboot und ScheduleReboot und auch durch die Eigenschaft REBOOT
wenn diese auf Force gesetzt wird.
Indem das Reboot-Flag (iefReboot) durch die Funktion MsiSetMode() in einer benutzerdefinierten
Aktion
auf
die
mglichen
Werte
MSIRUNMODE_REBOOTATEND
oder
MSIRUNMODE_REBOOTNOW gesetzt wird.
Falls bei der Installation Dateien berschrieben werden mssen, die derzeitig verwendet werden.
Hierbei wird die Eigenschaft ReplacedInUseFiles gesetzt, so dass hierdurch ein solcher Fall
jederzeit identifiziert werden kann.
In allen dieser Szenarien wird die Durchfhrung eines Computerneustarts veranlasst, wobei eine groe
Relevanz auf der im letzten Fall skizzierten Vorgehensweise liegt. Zunchst mchte ich jedoch auf die
Kontrollfunktionen eingehen, die der Windows Installer hierfr bereit stellt.
Kontrollieren und berwachen des Neustartverhaltens

Unabhngig davon, ob und auf welche Weise ein Neustart veranlasst wurde kann das tatschliche
Verhalten des Windows Installers weiter spezifiziert und beeinflusst werden. Hierzu sind die
245
Kapitel 6
Eigenschaften REBOOT und REBOOTPROMPT zu verwenden.

REBOOT Wert
Erluterung
Force
Veranlasst einen Neustart nach dem Abschluss der Installation. In der Benutzeroberflche
wird ein Dialog mit der Aufforderung angezeigt, den Computer neu zu starten. Wird die
Installation ohne Anzeige einer Benutzeroberflche durchgefhrt, wird das System
automatisch nach Abschluss der Installation neu gestartet.
Suppress
Die Aufforderung zum Neustart nach Beendigung der Installation wird unterdrckt. Der
Installer fordert hingegen den Anwender auf, einen Neustart whrend der Installation
durchzufhren, wenn die Aktion ForceReboot whrend des Setups aufgerufen wird. Wird
die Installation ohne Anzeige einer Benutzeroberflche durchgefhrt, wird bei jeder
ForceReboot-Aktion ein Neustart ausgefhrt. Vom Windows Installer veranlasste Neustarts
(z.B. durch verwendete Dateien) am Ende der Installation werden unterdrckt.
ReallySuppress
Unterdrckt alle Aufforderungen zum Neustart, die durch die Aktion ForceReboot whrend
der Installation ausgelst werden. Ein erforderlicher Neustart am Ende der Installation wird
ebenfalls unterdrckt.
Tabelle 6.50: Mgliche Werte der Eigenschaft REBOOT
Der Eigenschaft REBOOT ist der jeweilige Wert zuzuweisen, wobei nur der erste Buchstabe
bercksichtigt wird. Somit ist die Zuweisung REBOOT=S vollkommen ausreichend. Wird die
Installation unter Verwendung einer Benutzeroberflche durchgefhrt, erscheint ein Dialog in dem der
Benutzer einen eventuellen Neustart besttigen muss. In vielen Fllen ist es notwendig einen
Computerneustart automatisch auszufhren, ohne dem Anwender eine diesbezgliche
Auswahlmglichkeit zu bieten. Setzen Sie hierzu die Eigenschaft REBOOTPROMPT auf den Wert
Suppress (oder S), um einen notwendigen Neustart durchzufhren, ohne dem Anwender eine
Mglichkeit zur Vermeidung des Neustarts zu geben. Die Mglichkeiten zur Steuerung eines
Computerneustarts sind von der Version des Windows Installers abhngig, wie dieses auch Tabelle
6.51 zeigt. So enthalten die Betriebssysteme Windows Vista und Windows Server 2008 eine
Funktionalitt, die als Neustart-Manager (Restart-Manager) bezeichnet wird und die ab der Version 4.0
des Installers auch untersttzt wird, aber dazu spter mehr.
Aktion, Dialog oder Eigenschaft
Beschreibung
Aktion: ForceReboot
Die Aktion ForceReboot veranlasst einen umgehenden Neustart des

Systems. Dem Anwender wird hierzu eine Dialogbox angezeigt, falls
die Darstellungsform der Benutzeroberflche dieses erlaubt. Beim
Ausfhren von ForceReboot werden alle vorherigen im InstallationsSkript befindlichen Aktionen abgeschlossen. Der Installer erstellt den
Schlssel
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce in der
Systemregistrierung und fgt den Productcode oder den Namen des
Installationspaketes als Wert hinzu. Der Installer erstellt ebenfalls
eine Befehlszeile, die diesem Schlssel als Wert hinzugefgt wird.
Diese Befehlszeile verfgt ber den folgenden Aufbau:
AFTERREBOOT=1 RUNONCEENTRY=[Name des Eintrages].
Der Eintrag RUNONCEENTRY enthlt einen Verweis auf einen
speziellen RunOnce-Schlssel fr den Windows Installer, der unter
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\RunO
nceEntries angelegt wird. Diese Informationen werden bentigt, um
die Installation auf Basis der IPI-Datei nach dem Neustart
246
fortzusetzen.
Aktion: ScheduleReboot
Die Aktion ScheduleReboot veranlasst den Neustart des Systems

nach dem Abschluss der Installation.
Eigenschaft: REBOOT
Forciert oder unterdrckt den Computerneustart.
Eigenschaft: REBOOTPROMPT
Verhindert die Anzeige eines Dialoges zum Computerneustart. Der

Neustart des Systems wird immer automatisch durchgefhrt.
Eigenschaft: AFTERREBOOT
Diese Eigenschaft wird auf den Wert 1 nach dem

Computerneustart gesetzt, falls dieser durch ForceReboot veranlasst
wurde.
Aktion: InstallValidate
Zeigt den Dialog FilesInUse an und ermglicht es dem Benutzer,

Prozesse zu beenden um somit unntige Computerneustarts zu
vermeiden.
Dialog: FilesInUse
Dieses Dialogfeld informiert den Benutzer whrend des

Installationsprozesses ber verwendete Dateien, die im Laufe der
Installation ersetzt oder entfernt werden mssen. Hierdurch besitzt
der Benutzer die Mglichkeit, die entsprechenden Prozesse zu
beenden um einen unntigen Computerneustart zum Ersetzen der
Dateien zu vermeiden. Dieses Dialogfeld wird automatisch durch die
Aktion InstallValidate erzeugt, falls es erforderlich ist.
Dialog: MsiRMFilesInUse
Gibt den Anwender die Option, den Neustart-Manager zum Beenden

und Starten der Anwendungen zu verwenden. Verfgbar mit
Windows Installer 4.0 und hher unter Windows Vista und Windows
Server 2008.
Eigenschaft: ReplacedInUseFiles
Wird gesetzt, falls der Installer eine Datei berschreibt, die

momentan in Verwendung ist. Diese Eigenschaft kann von
benutzerdefinierten Aktionen verwendet werden, um festzustellen, ob
ein Computerneustart erforderlich ist.
Eigenschaft:
Hiermit kann die Interaktion mit dem Neustart-Manager deaktiviert

werden. Verfgbar mit Windows Installer 4.0 und hher unter
Windows Vista und Windows Server 2008.
Eigenschaft:
MSIDISABLERMRESTART und
MSIRMSHUTDOWN
Legt fest, in welcher Form der Neustart-Manager Anwendungen

schliet und wieder startet. Verfgbar mit Windows Installer 4.0 und
hher unter Windows Vista und Windows Server 2008.
Eigenschaft: MsiSystemRebootPending
Diese Eigenschaft wird vom Installer auf den Wert 1 gesetzt, falls
ein Computerneustart noch aussteht. Verfgbar mit Windows
Installer 4.0 und hher unter Windows Vista und Windows Server
2008.
Richtlinie:
Systemrichtlinie, mit der die Interaktion mit dem Neustart-Manager

deaktiviert werden kann. Verfgbar mit Windows Installer 4.0 und
hher unter Windows Vista und Windows Server 2008.
Tabelle 6.51: Optionen zur Steuerung des Computerneustarts
Die vielfltigen Manipulationsmechanismen hinsichtlich des Neustartverhaltens knnen dazu fhren,

dass ein Neustart erforderlich ist aber niemand davon Kenntnis erlangt. Gerade in Szenarien, in denen
247
Kapitel 6
mehrere Installationen nacheinander ausgefhrt werden, kann dieses zu gravierenden Problemen

fhren, wie an spterer Stelle noch erlutert wird. Somit besteht hufig die Notwendigkeit, eine
Prfung auf einen ausstehenden oder einen veranlassten Computerneustart vorzunehmen. Hierbei ist es
natrlich wesentlich, ob auf die Neustartanforderung reagiert werden muss oder ob sie lediglich einen
informellen Nutzen bieten soll, wobei dieser Punkt vornehmlich in Troubleshooting-Szenarien
anzutreffen ist.
Das Installationsprotokoll und auch das Windows-Ereignisprotokoll enthalten Hinweise auf einen
erforderlichen oder auch veranlassten Neustart. Das Installationsprotokoll gibt entsprechende
Informationen im Klartext aus und weist durch entsprechende Rckgabewerte zustzlich darauf hin.
Der folgende Auszug zeigt eine erfolgreich abgeschlossene Installation und informiert gleichzeitig
darber, dass der Windows Installer einen Neustart veranlasst hat. Dieses wird durch den
Rckgabewert
1641
des
MainEngineThread
deutlich,
wobei
1641
fr
ERROR_SUCCESS_REBOOT_INITIATED steht.
MSI (s) (E0:68) [14:32:57:516]: Product: Installer-Demo -- Installation completed successfully.
MSI (s) (E0:68) [14:32:57:516]: Windows Installer installed the product. Product Name: Installer-Demo.
Product Version: 1.00.0000. Product Language: 1033. Installation success or error status: 0.
MSI (s) (E0:68) [14:32:57:516]: Windows Installer requires a system restart. Product Name: Installer-Demo.
Product Version: 1.00.0000. Product Language: 1033. Type of System Restart: 1. Reason for Restart: 1.
MSI (s) (E0:68) [14:32:57:516]: MainEngineThread is returning 1641
Wurde hingegen ein notwendiger Computerneustart unterdrckt, wird dieses durch den Rckgabewert
3010 verdeutlicht, wobei dieser Wert fr ERROR_SUCCESS_REBOOT_REQUIRED steht. Zustzlich
finden sich ebenfalls Hinweise im Klartext.
MSI (s) (FC:C0) [09:36:16:162]: Product: Installer-Demo -- Installation completed successfully.
MSI (s) (FC:C0) [09:36:16:162]: Windows Installer installed the product. Product Name: Installer-Demo.
Product Version: 1.00.0000. Product Language: 1033. Installation success or error status: 0.
MSI (s) (FC:C0) [09:36:16:163]: Windows Installer requires a system restart. Product Name: Installer-Demo.
Product Version: 1.00.0000. Product Language: 1033. Type of System Restart: 2. Reason for Restart: 1.
MSI (s) (FC:C0) [09:36:16:163]: Product: Installer-Demo. Restart required. The installation or update for
the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (FC:C0) [09:36:16:164]: MainEngineThread is returning 3010
Wird eine Installation unter Verwendung der Funktion MsiInstallProduct() des Windows Installer-API
oder durch direkten Aufruf der msiexec.exe ausgefhrt, knnen die gerade dargestellten
Rckgabewerte im weiteren Programmablauf verwendet werden. Listing 6.54 zeigt eine Batch-Datei,
die entsprechende Implementierungen enthlt. Die Rckgabewerte werden hierbei ber den
ERRORLEVEL abgefragt, wodurch die eigentmliche Darstellung der Sprunganweisungen begrndet
ist. Das hat damit zu tun, dass eine IF-Abfrage fr einen ERRORLEVEL immer auf grere und gleiche
Werte abprft. Der Befehl If ERRORLEVEL 1615 wird somit als If ERRORLEVEL >= 1615
interpretiert.
@ECHO OFF
REM Starten der Installation
start /wait msiexec.exe /i setup.msi /qb /l*v setup.log
248
If
If
If
If
If
ERRORLEVEL
ERRORLEVEL
ERRORLEVEL
ERRORLEVEL
ERRORLEVEL
3010 GoTo REQUIRED

1615 GoTo ERROR
1614 GoTo INITIATED
1 GoTo ERROR
0 GoTo SUCCESS
:REQUIRED
ECHO Neustart ist erforderlich
GoTo END
:INITIATED
ECHO Neustart wurde veranlasst
GoTO END
:SUCCESS
ECHO Installation erfolgreich. Neustart ist nicht erforderlich
GoTo END
:ERROR
ECHO Installation mit Rckgabewert %ERRORLEVEL% beendet
:END
Listing 6.54: Batch-Datei zum Starten der Installation und Auswerten der Rckgabewerte
Auf programmtechnischen Wege unter Verwendung der Deployment Tools Foundation steht fr diese
Zwecke die Funktion InstallProduct() des Objektes Installer zur Verfgung. Dieses Objekt enthlt
weiterhin die Eigenschaften RebootRequired und RebootInitiated, die Auskunft ber das
Neustartverhalten geben, wie auch in Listing 6.55 verdeutlicht wird.
Try
{
// Installation ohne Benutzeroberflche ausfhren
Installer.SetInternalUI(InstallUIOptions.Silent);
Installer.InstallProduct(fileName, string.Empty);
// Prfen ob ein Reboot erforderlich ist
if (Installer.RebootRequired)
EventLog.WriteEntry(Application.ProductName, "RebootRequired");
// Prfen ob ein Reboot veranlasst wurde
if (Installer.RebootInitiated)
EventLog.WriteEntry(Application.ProductName, "RebootInitiated");
}
{
// Fehler ins Ereignisprotokoll schreiben
EventLog.WriteEntry(Application.ProductName, ex.Message);
}
Listing 6.55: Starten einer Installation und Reaktionen auf das Neustartverhalten
Es ist erkennbar, dass viele Mglichkeiten bestehen, Auskunft ber das Neustartverhalten im Rahmen
der Installation zu erhalten. Nachteilig ist bei den vorgestellten Methoden, dass diese Szenarien
249
Kapitel 6
zunchst initiiert werden mssen, indem ein Protokoll erstellt oder entsprechende programmtechnische
Anstze gewhlt werden. Vielfach werden Probleme ja erst im Nachhinein festgestellt, wobei sich
dann die Frage nach der mglichen Fehlerquelle stellt. An dieser Stelle hilft das WindowsEreignisprotokoll weiter, denn alle Informationen die einen Computerneustart betreffen, werden
diesem angefgt, wie auch Tabelle 6.52 zeigt.
Ereignis-ID
Quelle
Meldung
1005
MsiInstaller
Der Windows Installer hat einen Neustart des Systems initiiert, um die
Konfiguration von "%1" fortzusetzen bzw. abzuschlieen.
1029
MsiInstaller
Produkt: %1. Ein Neustart ist erforderlich. Die Installation oder

Aktualisierung des Produkts erfordert einen Neustart, damit alle
nderungen in Kraft treten. Der Neustart wurde auf einen spteren
Zeitpunkt verschoben.
1038
MsiInstaller
Windows Installer erfordert einen Neustart des Systems. Produktname:

%1. Produktversion: %2. Produktsprache: %3. Typ des Systemneustarts:
%4. Ursache des Neustarts: %5.
Tabelle 6.52: Eintrge im Ereignisprotokoll die auf Computerneustarts hinweisen
Die Verwendung des Ereignisprotokolls kann noch weiter optimiert werden, denn bei den
Betriebssystemen Windows Vista und Windows Server 2008 ist es nun mglich, entsprechende
Ereignisse weiter zu verarbeiten. So kann das Auftreten bestimmter Ereignisse mit individuellen
Aktionen, wie dem Senden einer Mail, der Anzeige einer Meldung oder dem Starten eines Programms
verknpft werden. Zur manuellen Erstellung ist die Ereignisanzeige zu ffnen, das entsprechende
Ereignis auszuwhlen und der Kontextmeneintrag Aufgabe an dieses Ereignis anfgen auszuwhlen.
Daraufhin ffnet sich der Assistent zum Erstellen einfacher Aufgaben und fhrt sie durch die weiteren
Schritte. Eine so erstellte Aufgabe wird letztlich der neu gestalteten Aufgabenplanung (Task
Scheduler) von Windows Vista und Windows Server 2008 hinzugefgt. Somit sind die Erstellung und
die nachtrgliche Modifikation auch hierber mglich. Ebenso steht eine Schnittstelle fr den
programmtechnischen Zugriff zur Verfgung.
Besonders interessant ist hierbei, dass alle Aufgaben ins XML-Format exportiert und importiert
werden knnen. Demzufolge ist es mglich, eine entsprechende XML-Datei zu erstellen und diese zu
importieren, wozu neben den Mglichkeiten ber die Benutzeroberflche auch eine
Befehlszeilensteuerung zur Verfgung steht. Bei Verwendung der in Listing 6.56 dargestellten XMLDatei, wird beim Auftreten des Ereignisses mit der ID 1038 der Quelle MsiInstaller eine Meldung mit
dem Titel Windows Installer und dem Text Ein Neustart des Computers ist erforderlich
ausgegeben.
<?xml version="1.0" encoding="UTF-16" ?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<Triggers>
<EventTrigger>
<Enabled>true</Enabled>
<Subscription>
<QueryList>
<Query Id="0" Path="Application">
<Select Path="Application">*[System[Provider[@Name='MsiInstaller'] and EventID=1038]]</Select>
</Query>
</QueryList>
</Subscription>
250
</EventTrigger>
</Triggers>
<Actions Context="Author">
<ShowMessage>
<Title>Windows Installer</Title>
<Body> Ein Neustart des Computers ist erforderlich</Body>
</ShowMessage>
</Actions>
</Task>
Listing 6.56: XML-Datei zum Erstellen einer Aufgabe
Die gerade dargestellte XML-Datei kann nun der Aufgabenplanung hinzugefgt werden. Dieses kann
ber den Befehl Aufgabe importieren innerhalb der Benutzeroberflche oder auch ber eine
Befehlszeile erfolgen. Der folgende Befehlt fgt die Aufgabe unter der Bezeichnung MSI1038Event
der Aufgabenplanung hinzu:
Schtasks.exe /Create /TN MSI1038Event /XML d:\Event1038.xml
Es ist noch wichtig zu wissen, dass die Aufgabenplanung nun ein integraler Bestandteil von Windows
geworden ist, auf dem sehr viele Windowsfunktionen basieren. Deshalb kann dieser auch nicht einfach
abgeschaltet werden. Fr Sie bedeutet das: Sie knnen sich darauf verlassen, dass er luft.
Neustart durch Dateien in Verwendung

Wie in einem vorherigen Kapitel bereits erlutert wird die Installation durch den Client- und den
Server-Prozess realisiert, wobei vom Server-Prozess die physische Vernderung des Systems
vorgenommen wird. Der Client-Prozess wird lediglich zur Interaktion mit dem Benutzer bentigt. An
dieser Stelle geht es um Dateien, die derzeitig in Verwendung sind und die darauf abzielenden und
aufbauenden Manahmen des Windows Installers, wodurch die Relevanz ganz klar beim ServerProzess zu suchen ist.
In diesem serverseitigen Installationsprozess werden zunchst die Aktionen zur Bestimmung der
Installationsinformationen (Acquisition-Phase) ausgefhrt. Im ersten Teil werden die
Systemvoraussetzungen geprft und nach abhngigen Ressourcen gesucht (AppSearch). Im weiteren
Verlauf werden die Aktionen zur Berechnung des Speicherbedarfs (CostInitialize, FileCost und
CostFinalize) ausgefhrt. Bei der Berechnung des Speicherbedarfs wird sichergestellt, dass das
Zielsystem ber ausreichend Speicherplatz auf den Datentrgern verfgt. Hierbei werden Szenarien fr
die lokale Installation von Komponenten, die Ausfhrung von Komponenten vom Quellmedium und
fr Komponenten, die nicht installiert werden sollen, getrennt bercksichtigt. Die Werte werden
jeweils fr Rollback-Szenarien und fr Szenarien in denen kein Rollback ausgefhrt wird, berechnet.
Zur Ermittlung des tatschlichen Installationsumfangs und somit der Bestimmung des bentigten
Festplattenspeichers, werden die folgenden Informationen zu den betreffenden Komponenten bentigt:
Installationsstatus (InstallState): Der bisherige Status der Komponente auf dem Zielsystem.
Anforderungsstatus (RequestState): Der Status der Komponente, der nach der Installation
hergestellt sein soll.
Aktionsstatus (ActionState): Die Aktion, die ausgefhrt werden muss, um die Komponente vom
Installationsstatus in den Anforderungsstatus zu berfhren.
251
Kapitel 6
Nachdem der bentigte Speicherbedarf ermittelt wurde, wird whrend der Aktion InstallValidate
geprft, ob ausreichend Festplattenspeicher zur Verfgung steht, wozu die symbolisch benannte
Verzeichnisstruktur aufgelst wird und anschlieend Berechnungen durchgefhrt werden. Falls nicht
gengend Speicher zur Verfgung steht, wird der Client-Prozess angewiesen, dem Benutzer einen
entsprechenden Dialog anzuzeigen. Falls der Speicher ausreichend ist wird whrend der Aktion
InstallValidate weiterhin geprft, ob zu ersetzende oder zu modifizierende Dateien in Verwendung
sind. In einem solchen Fall wird der Benutzer aufgefordert die jeweilige Anwendung zu schlieen, um
somit einen Computerneustart zu vermeiden. Hierzu findet natrlich wieder eine Kommunikation mit
dem Client-Prozess statt, der letztlich den in Abbildung 6.50 dargestellte Dialog FilesInUse fr diese
Zwecke anzeigt.
Abbildung 6.50: Dialog FilesInUse zeigt Prozesse an die Dateien derzeitig verwenden
Lassen Sie und das ganze noch etwas detaillierter betrachten und auf den Algorithmus eingehen, der
zum Ermitteln der Dateien angewendet wird. Zunchst einmal hat der Windows Installer zum
Zeitpunkt der Aktion InstallValidate festgestellt welche Dateien physisch installiert werden mssen
und welches Zielverzeichnis hierfr verwendet wird. Im nchsten Schritt muss nun geprft werden, ob
diese Dateien bereits verwendet werden. Die bisherige Implementierung zum Ermitteln dieser Dateien
bedient sich dem Registrierungshauptschlssel HKEY_PERFORMANCE_DATA. Hierbei handelt es
sich um einen virtuellen Schlssel der nicht physisch in der Registrierungsdatenbank vorhanden ist und
somit auch von den verfgbaren Editoren nicht angezeigt werden kann. Dieser Schlssel bietet den
Zugriff auf diverse Performance-Daten des Systems unter Verwendung des Registrierungs-API. Er
wird auch von dem in Windows Vista und Windows Server 2008 enthaltenen Tool Zuverlssigkeitsund Leistungsberwachung (Reliability and Performance Monitor) verwendet. Jeder der mit diesem
oder hnlichen Tools bereits gearbeitet hat, wird festgestellt haben, dass viele Informationen
prozessbezogen dargestellt werden knnen. Anhand dieser Prozessauflistung und der Liste der zu
installierenden Dateien kann nun ermittelt werden, welche Dateien derzeitig in Verwendung sind und
von welchen Prozessen sie verwendet werden. Somit ist es nun relativ einfach dem Benutzer eine Liste
mit Prozessen anzuzeigen, die beendet werden mssen um hierdurch einen Computerneustart zu
vermeiden. Dieses ist jedoch nur die Theorie; in der Praxis sind noch einige Besonderheiten zu
beachten.
252
Die Ermittlung der derzeitig verwendeten Dateien bercksichtigt nur PE-Dateien. Das PE steht
hierbei fr Portable Executable und kennzeichnet eine ausfhrbare Datei fr die Microsoft
Windows-Plattform. Es ist zu beachten, dass nicht alle PE-Dateien ber die Dateierweiterung .exe
verfgen. Bei Dateien vom Typ .dll, .scr, .sys, .cpl, .ocx und .msstyles handelt es sich ebenfalls um
PE-Dateien, auch wenn diese alleine nicht lauffhig sind. Das bedeutet, dass der aktuelle Files-InUse-Algorithmus nicht erkennt, wenn beispielsweise eine Textdatei verwendet wird.
Bei dem Prozess der die Datei verwendet, handelt es sich um den Prozess der die Installation
startet. Wird die Installation beispielsweise durch die Funktion MsiInstallProduct() einer eigenen
Anwendung gestartet, wird diese Anwendung nicht bercksichtigt, auch wenn sie derzeitig Dateien
verwendet.
Es werden nur Prozesse bercksichtigt, die ber ein sichtbares Fenster verfgen und die vom
Benutzer tatschlich beendet werden knnen. Hiermit ist jedoch ein sauberes Beenden gemeint und
kein Abschieen der Prozesse. Genau an dieser Stelle liegt jedoch das Problem. Vielfach hat der
Benutzer keine Mglichkeit einen solchen Prozess zu beenden. Aus diesem Grund erscheint er gar
nicht in der Liste.
Es wird deutlich, dass der skizzierte Mechanismus zum Ermitteln der in Verwendung befindlichen
Dateien durchaus einige Schwachpunkte aufweist. So werden nicht alle Dateiformate bercksichtigt
und nicht alle Prozesse dem Benutzer angezeigt. Die Grnde hierfr sind nachvollziehbar und
verstndlich. An dieser Stelle hat sich auch etwas getan, aber dazu spter mehr.
Zunchst nochmal zur Aktion InstallValidate und den relevanten Informationen im
Installationsprotokoll. Zunchst ist erkennbar, dass die Aktion aufgerufen wurde. Anschlieend finden
sich die Informationen zum Installationsumfang, also der Festlegung des relevanten Aktionsstatus der
Features und der Komponenten.
MSI (s) (20:48) [12:05:49:437]: Doing action: InstallValidate
MSI (s) (20:48) [12:05:49:437]: Feature: Application; Installed: Absent; Request: Local; Action: Local
MSI (s) (20:48) [12:05:49:437]: Component: C__RMEditor.exe; Installed: Absent; Request: Local; Action: Local
Falls Dateien in Verwendung sind, wird dieses im Klartext dem Installationsprotokoll mit Hinweis auf
den Prozess, die Prozess-Id und weiteren Informationen angefgt.
MSI (s) (20:48) [12:05:49:968]: 1 application(s) had been reported to have files in use.
Info 1603. The file C:\Program Files (x86)\Tools\RMEditor.exe is being held in use by the following process:
Name: RMEditor, Id: 3752, Window Title: '(not determined yet)'. Close that application and retry.
An dieser Stelle wird nun der Dialog FilesInUse angezeigt, wodurch dem Benutzer mehrere
Mglichkeiten fr den weiteren Ablauf des Installationsprozesses angeboten werden. Falls die
Schaltflche Beenden aktiviert wird, wird der Installationsprozess auch an dieser Stelle abgebrochen.
Im Installationsprotokoll wird dieses durch den Rckgabewert 2 dargestellt, wobei dieser Wert
ERROR_INSTALL_USEREXIT bedeutet.
Action ended 12:27:23: InstallValidate. Return value 2.
Action ended 12:27:23: INSTALL. Return value 2.
Wird hingegen die Schaltflche Wiederholen aktiviert, prft der Windows Installer nochmals, ob
Dateien in Verwendung sind. Falls das der Fall ist wird der Dialog erneut angezeigt. Aktiviert der
Anwender hingegen die Schaltflche Ignorieren, so kann dieses zwangslufig zu dem Szenario fhren,
das es zu vermeiden gilt dem Computerneustart. Das bisher dargestellte Verhaltensmuster des
Windows Installers hat keinen Einfluss auf das physische Kopieren der Datei, sondern lediglich
253
Kapitel 6
informellen Charakter. Hierdurch soll der Anwender frhzeitig auf einen mglichen Computerneustart
hingewiesen werden, weiterhin soll ihm die Mglichkeit gegeben werden, diesen durch geeignete
Manahmen zu vermeiden.
Bei der physischen Modifikation des Zielsystems werden nun diverse Schritte durchlaufen, die
letztlich das Kopieren der Datei sicherstellen sollen. Im Ersten Schritt wird geprft ob die zu
kopierende Datei bereits auf dem Zielsystem existiert. Ist dies der Fall und werden dieser Datei keine
besonderen Zugriffssteuerlisten zugewiesen, werden die Zugriffsteuerlisten der existierenden Datei
gesichert, damit sie spter auf die neue Datei angewendet werden knnen. Ist die Datei auf dem
Zielsystem noch nicht vorhanden, wird lediglich die Operationsanweisung zum Entfernen der Datei in
das Rollback-Skript bertragen. Existiert die Datei bereits, wird sie vor dem Entfernen fr einen
eventuellen Rollback gesichert. Hierzu wird zunchst der Ort bestimmt, an dem die gesicherte Datei
abgelegt werden soll. Als Erstes wird geprft ob der Ordner config.msi im Stammverzeichnis des
Laufwerks erstellt werden kann, auf dem sich die Datei befindet und ob in diesen Ordner geschrieben
werden kann. Ist dieses nicht der Fall wird die Datei unter einem abweichenden Namen im
Originalverzeichnis gesichert. Lsst sich der Ordner config.msi hingegen erstellen, wird die zu
sichernde Datei in diesen Ordner verschoben, wobei die Datei umbenannt wird. Falls beim
Verschieben Probleme auftreten, wird zunchst die Datei kopiert und anschlieend die existierende
gelscht. Schlgt der Lschvorgang fehl wird das Attribut Neustart ist erforderlich gesetzt und die
Datei zum Lschen nach dem Systemneustart markiert, wie dieses auch das Installationsprotokoll
zeigt.
MSI (s) (F0:60) [16:55:14:728]: Executing op: FileCopy(SourceName=RMEditor.exe,SourceCabKey=F__RMEditor.exe,
DestName=RMEditor.exe,Attributes=512,FileSize=76800,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,
Version=2.0.0.0,Language=0,InstallMode=58982400,,,,,,,)
MSI (s) (F0:60) [16:55:14:729]: File: C:\Program Files (x86)\Tools\RMEditor.exe; Overwrite;
Won't patch; Existing file is a lower version
MSI (s) (F0:60) [16:55:14:729]: Re-applying security from existing file.
MSI (s) (F0:60) [16:55:14:730]: Product: Installer-Demo. The file C:\Program Files (x86)\Tools\RMEditor.exe
is being used by the following process: Name: RMEditor , Id 7288.
MSI (s) (F0:60) [16:55:14:731]: Verifying accessibility of file: RMEditor.exe
Info 2318. File does not exist: C:\Config.Msi\1d44c31.rbf
MSI (s) (F0:60) [16:55:14:731]: Using source file security for destination.
Info 2329. Error deleting file: C:\Program Files (x86)\Tools\RMEditor.exe. GetLastError: 32.
MSI (s) (F0:60) [16:55:14:750]: Verifying accessibility of file: RMEditor.exe

Info 1603. The file C:\Program Files (x86)\Tools\RMEditor.exe is being held in use.
Close that application and retry.
Info 1903. Scheduling reboot operation: Deleting file C:\Program Files (x86)\Tools\RMEditor.exe.
Must reboot to complete operation.
Info 1902. Scheduling reboot operation: Renaming file C:\Program Files (x86)\Tools\TBM2FBA.tmp to
C:\Program Files (x86)\Tools\RMEditor.exe. Must reboot to complete operation.
Listing 6.57: Kennzeichnung von verwendeten Dateien im Installationsprotokoll
Falls Dateien berschrieben werden, die derzeitig in Verwendung sind, wird vom Windows Installer
die Eigenschaft ReplacedInUseFiles auf 1 gesetzt, die sich auch in der Eigenschaftenauflistung des
Protokolls wieder findet.
Property(S): ReplacedInUseFiles = 1
Wie
254
bereits zu Beginn
dieses
Abschnittes erwhnt,
finden sich auch am
Ende
des
Installationsprotokolls, weitere Informationen die auf einen erforderlichen Computerneustart

hinweisen.
Ersetzen von verwendeten Dateien

Im vorherigen Abschnitt wurde der Algorithmus erlutert, der zum Erkennen von verwendeten Dateien
benutzt wird. Letztlich ist dieser Algorithmus aber nur ein Mechanismus um die Wahrscheinlichkeit
eines Neustarts zu minimieren. Dieses resultiert daraus, dass zwischen dem Ermitteln der
problematischen Dateien und dem physischen Ersetzen durchaus einige Zeit vergehen kann. Wer
jemals Visual Studio 2005 installiert hat, wei was ich hiermit meine und dass ist nicht negativ
gemeint. Aber Visual Studio 2005 ist eines der komplexesten Installationspakete die ich kenne. Bei der
vollstndigen Installation werden mehr als 23.000 Dateien auf das System gebracht, was
logischerweise einige Zeit dauert. Fr die gerade geschilderte Problematik bedeutet dies, dass die
Zeitspanne zwischen InstallValidate und der physischen Installation der letzten Datei recht gro sein
kann. In diesem Zeitraum kann es nun geschehen, dass auf eine Datei zugegriffen wird, wodurch das
bisherige Ergebnis der verwendeten Dateien verflscht wird. Natrlich ist auch der umgekehrte Fall
mglich.
Wie zuvor dargestellt benutzt der Windows Installer unterschiedliche Strategien und FallbackMechanismen um eine Datei physisch zu installieren. Die letzte Mglichkeit hierbei resultiert in dem
Ersetzen der verwendeten Datei nach einem Computerneustart. Zur Realisierung wird die Funktion
MoveFileEx() verwendet, der als Parameter MOVEFILE_DELAY_UNTIL_REBOOT bergeben wurde,
wie dieses sinngem auch in Listing 6.58 dargestellt ist.
[DllImport("kernel32.dll", EntryPoint = "MoveFileExA")]
private static extern bool MoveFileEx(string lpExistingFileName,
string lpNewFileName, int dwFlags);
public static bool MoveFileAfterReboot(string existingFileName, string newFileName)
{
// Konstanten
const int MOVEFILE_REPLACE_EXISTING = 0x1;
const int MOVEFILE_DELAY_UNTIL_REBOOT = 0x4;
// Aufruf der Win32-Funktion
return (MoveFileEx(existingFileName,
newFileName,
MOVEFILE_REPLACE_EXISTING |
MOVEFILE_DELAY_UNTIL_REBOOT));
}
Listing 6.58: Verwendung der Win32-Funktion MoveFileEx()
Zum besseren Verstndnis mchte ich die Darstellung dieser Funktion mit den regulren
Dateibezeichnungen aus dem in Listing 6.57 dargestellten Protokollauszug verwenden. Hierbei soll
die Datei C:\Program Files (x86)\Tools\RMEditor.exe ersetzt werden, was jedoch nicht mglich ist, da
sie bereits verwendet wird. Aus diesem Grund wird die neue Datei unter der Bezeichnung
TBM2FBA.tmp ebenfalls im Ordner C:\Program Files (x86)\Tools gespeichert. Zustzlich wird das
Betriebssystem informiert, dass das Umbenennen der Datei nach einem Computerneustart erfolgen
soll. Wird dieses nun auf die Funktion MoveFileAfterReboot() in Listing 6.58 projiziert, wrde sich
folgender Funktionsaufruf ergeben:
255
Kapitel 6
MoveFileAfterReboot(C:\\Program
Files
(x86)\\Tools\\TBM2FBA.tmp,
C:\\Program Files (x86)\\Tools\\RMEditor.exe);
Letztlich wird hierdurch die bereits bekannte Win32-Funktion MoveFileEx() mit dem Parameter
MOVEFILE_DELAY_UNTIL_REBOOT aufgerufen. Dieser Parameter bewirkt, dass die ursprngliche
Datei RMEditor.exe nach dem Neustart gelscht und die neue Datei TBM2FBA.tmp in RMEditor.exe
umbenannt wird. Hierfr verantwortlich ist das Betriebssystem selbst, denn dieses stellt fr solche
Szenarien einen entsprechenden Mechanismus mit der Bezeichnung PendingFileRenameOperations
zur Verfgung. In Wirklichkeit handelt es sich hierbei lediglich um einen Eintrag in der
Systemregistrierung, dem die jeweiligen Dateien angefgt werden und der beim Neustart des
Computers abgearbeitet wird. Der Eintrag PendingFileRenameOperations ist vom Typ
REG_MULTI_SZ
und
wird
in
der
Systemregistrierung
unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager angelegt. Dieser
Eintrag enthlt einen oder mehrere Dateinamenpaare, wobei der erste Name die neue Datei
reprsentiert, die letztlich nach dem Neustart in die zweite Datei umbenannt wird. Die nachfolgenden
Eintragungen finden sich nach dem zuvor beschriebenen Aufruf von MoveFileAfterReboot() in der
Systemregistrierung. Es ist erkennbar, dass den Dateinamen zustzliche Zeichen vorangestellt sind.
Hierbei handelt es sich um ein spezielles Kennzeichnungsformat, das jedoch bei der spteren
Umbenennung nicht bercksichtigt wird.
\??\C:\Program Files (x86)\Tools\TBM2FBA.tmp
!\??\C:\Program Files (x86)\Tools\RMEditor.exe
Mitunter kann es vorkommen, dass im Rahmen der Installation eine Datei gelscht werden soll, die
bereits verwendet wird. Auch dieses Szenario wird unter Verwendung der Funktion MoveFileEx() und
dem bekannten Parameter MOVEFILE_DELAY_UNTIL_REBOOT realisiert. Beim Aufruf der
Funktion ist hier jedoch der zweite Parameter auf Null zu setzen.
Tipp Beginn
Mit Hilfe des Tools pendmoves.exe von Windows Sysinternals kann geprft werden, ob Lsch- oder
Umbenennungsaktionen noch ausstehen und ob die entsprechenden Dateien physisch vorhanden sind.
Ein weiteres Tool von Windows Sysinternals ist movefile.exe. Hiermit ist es mglich, auf einfache
Weise die Funktionalitt der PendingFileRenameOperations zu nutzen.
Tipp Ende
Startvorgang des Systems

Die Funktionalitt der PendingFileRenameOperations ist ohne Frage eine sehr interessante und
unverzichtbare Technik zum Ersetzen oder Umbenennen von bereits verwendeten Dateien, die auch
recht einfach umsetzbar ist. Im Prinzip gibt es dazu nicht mehr viel zu sagen, aber auf zwei
interessante Aspekte mchte ich noch hinweisen. Im ersten Fall geht es um mehrere
Benutzersitzungen, wie das beispielsweise bei der schnellen Benutzerumschaltung (Fast User
Switching) mglich ist. Die Funktionalitt der PendingFileRenameOperations arbeitet
sitzungsbergreifend, so dass in dem skizzierten Registrierungseintrag alle systemweit ausstehenden
Operationen vermerkt sind. Dieser Punkt ist relevant fr einige Szenarien, auf die ich an spterer Stelle
dieses Kapitels noch eingehen werde. Der zweite Punkt betrifft den Zeitpunkt an dem diese
256
Operationen ausgefhrt werden. Diese Fragestellung ist natrlich uerst wichtig, wenn es darum geht,
bereits frhzeitig auf diese neuen Dateien zuzugreifen. Die Erluterung ist etwas komplexer, da hierzu
ein Abriss des Startvorgangs unverzichtbar ist.
Whrend des Computerneustarts werden mehrere Phasen durchlaufen, wobei der Beginn des
Bootvorgangs von der verwendeten Plattform abhngig ist. Zu Beginn kommt hierbei der Boot-Loader
ins Spiel. Hierbei handelt es sich um eine spezielle Software, die sich bereits auf dem bootfhigen
Medium befindet und von einer speziellen Firmware wie dem BIOS geladen und ausgefhrt wird. Fr
die Windows-Plattform sind standardmig zwei dieser Boot-Loader verfgbar:
NT-Loader (NTLDR): Hierbei handelt es sich um den Bootmanager fr die Betriebssysteme
Windows NT, Windows 2000, Windows XP und Windows Server 2003.
Windows Boot Manager (Bootmgr): Hierbei handelt es sich um den Bootmanager von Windows
Vista und Windows Server 2008.
Whrend dieser ersten Phase kann der Benutzer beispielsweise das zu verwendende Betriebssystem
auswhlen, falls Mehrere vorhanden sind. Im Anschluss erfolgt der Wechsel in die Kernel-LoadingPhase. Beim Kernel handelt es sich um den zentralen Bestandteil des Betriebssystems, der an dieser
Stelle vom Boot-Loader geladen. Im Betriebssystemkern ist die Prozess- und Datenorganisation
festgelegt, auf der alle weiteren Softwarebestandteile des Betriebssystems aufbauen. Hierbei handelt es
sich auch um die unterste Softwareschicht, so dass hiermit auf die Hardware zugegriffen werden kann.
Nachdem der Betriebssystemkern geladen wurde kommen wir nun zu dem fr dieses Thema
relevanten Teil des Bootvorgangs; der Kernel ldt den Sitzungs-Manager (Session Manager). Hierbei
handelt es sich um das Subsystem, das fr das Starten von Benutzersitzungen zustndig ist. Im Detail
werden hier die folgenden Aktionen ausgefhrt:
Die
System-Umgebungsvariablen
werden
erstellt.
Diese
sind
unter
HKEYLOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment definiert.
Der Kernelmodus des Win32-Subsystems (win23k.sys) wird gestartet. Hierdurch ist der Wechsel in
den graphischen Darstellungsmodus mglich.
Der Benutzermodus des Win32-Subsystems, also das Client/Server Runtime Server Subsystem
(csrss.exe) wird gestartet. Hierdurch ist es mglich, Anwendungen im Benutzermodus (user-mode
applications) auszufhren.
Die Auslagerungsdatei fr den virtuellen Speicher wird erstellt.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session
Management definiert.
Diese ist unter

Manager\Memory
Die Umbenennungsoperationen werden ausgefhrt. An dieser Stelle werden somit die Elemente
des Registrierungseintrags PendingFileRenameOperations abgearbeitet.
Danach wird der Windows-Anmeldevorgang (winlogon.exe) gestartet, der durch die folgenden
Aktionen charakterisiert ist:
Ermitteln der Anmeldeinformationen. An dieser Stelle gibt es gravierende Unterschiede zwischen
den Betriebssystemgenerationen. Bei Windows Vista und Windows Server 2008 werden hierzu so
genannte Anmeldeinformationsanbieter (Credential Providers) verwendet. Bei den
Betriebssystemen der frheren Generation erfolgte die Authentifizierung ber die Graphical
identification and authentication library, die auch besser unter der Bezeichnung GINA bekannt ist.
berprfen der Anmeldeinformationen durch das Local Security Authority Subsystem, wobei durch
dieses auch ermittelt wird welche Sicherheitskontenverwaltung (SAM) verwendet wird. Zur
257
Kapitel 6
Auswahl stehen hier die lokale SAM, die Domnen SAM oder das Active Directory.
Der Service Control Manager wird gestartet, so dass alle Betriebssystemdienste ebenfalls
ausgefhrt werden, die fr den automatischen Start konfiguriert wurden.
Nachdem der Benutzer sich erfolgreich am System angemeldet hat, werden durch winlogon.exe noch
die Konfigurationseinstellungen aktualisiert. Hierbei wird die Einstellung LastKnownGood so
angepasst, dass die aktuelle Konfiguration (HKEY_LOCAL_MACHINE\System\CurrentControlSet)
hier abgebildet wird. Nachdem die Benutzer- und maschinenspezifischen Gruppenrichtlinien
angewendet wurden, erfolgt noch der Start vorkonfigurierter Anwendungen. Hierbei werden die
folgenden Orte in der angegebenen Reihenfolge durchlaufen.
7. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
8. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
9. HKEY_LOCAL_MACHINE\Software \Microsoft\Windows\CurrentVersion\Run
10. HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
11. HKEY_CURRENT_USER \Software\Microsoft\Windows\CurrentVersion\Run
12. HKEY_CURRENT_USER \Software\Microsoft\Windows\CurrentVersion\RunOnce
13. % ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Startup
14. %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup
Durch die Darstellung des Startvorgangs kann nun auch die noch offene Frage beantwortet werden.
Das Umbenennen der Dateien erfolgt bereits recht frh, so dass hierdurch sichergestellt ist, dass
beispielsweise Betriebssysteme oder automatisch startende Anwendungen bereits eine neue Version
der Datei verwenden.
Unterdrcken des Computerneustarts

In den vorangehenden Abschnitten wurden die technischen Mglichkeiten aufgezeigt, durch die ein
vom System veranlasster Computerneustart unterdrckt werden kann. Hier stellt sich hufig die Frage,
ob so etwas tatschlich getan werden sollte oder ob nicht lieber der sichere Weg zu gehen ist, nmlich
den Neustart auszufhren. Vielfach lsst sich diese Frage nicht pauschal beantworten, denn hierbei
sind auch Unternehmenspolitische Faktoren zu bercksichtigen. Hufig werden an dieser Stelle
mehrere Neustarts pro Installation seitens der Unternehmensleitung nicht akzeptiert, so dass an dieser
Stelle der Komfort, der Stabilitt vorangestellt wird. Leider sind die Lsungsmglichkeiten, die einen
guten Kompromiss zwischen Komfort und Stabilitt darstellen, nur begrenzt anzutreffen.
Auf technischer Ebene mssen an dieser Stelle zwei unterschiedliche Szenarien betrachtet werden. Im
ersten Fall ist die einzelne Installation zu sehen, also die Ausfhrung eines Installationspaketes. Dieser
Fall ist sehr einfach, denn hierfr gibt es ganz klare Richtlinien, die sich auch in den Bestimmungen
zur Erlangung eines Windows-Logos wiederfinden. Hierbei gilt, dass Neustarts whrend der
Installation zu vermeiden sind. Das bedeutet nicht, dass nach Abschluss der Installation kein Neustart
auszufhren ist. Hiermit ist gemeint, dass der Installationsprozess durch einen Neustart unterbrochen
und danach wieder aufgenommen wird. Um solche Flle zu vermeiden, ist das Design des
Installationspaketes zu prfen und die problematischen Umsetzungen sind zu korrigieren. Im
Wesentlichen gib es an dieser Stelle zwei Problemfaktoren, die zu vermeiden sind.
Aktion ForceReboot: Diese Aktion veranlasst einen Neustart an der aktuellen Position des
Installationsprozesses. Wird die Installation ohne Benutzeroberflche durchgefhrt, erfolgt der
Computerneustart automatisch.
258
Selbstregistrierung: Bei der Registrierung von COM-Komponenten unter Verwendung der Tabelle
SelfReg, kann es zum Neustart kommen, falls die Komponente bereits verwendet wird.
Das zweite Szenario ist wesentlich komplexer und die Umsetzung ist nicht ganz trivial. Hierbei handelt
es sich nicht um ein einzelnes Installationspaket, sondern um mehrere Pakete, die nacheinander
ausgefhrt werden. Die effektive Realisierung eines solchen Szenarios, ist eines der wesentlichen
neuen Features im Windows Installer 4.5, so dass ich spter nochmal hierauf zurck kommen werde.
An dieser Stelle mchte einen allgemeinen oder generischen Ansatz vorstellen, der derzeitig vielfach
verwendet wird. Einfach ausgedrckt werden hierbei nacheinander die Installationen unter
Verwendung der Programmierschnittstelle oder von msiexec.exe ausgefhrt, wobei ein vom System
veranlasster Neustart unterdrckt wird. Wie gesagt diese Vorgehensweise ist derzeitig allgegenwrtig,
obwohl die Installationsergebnisse durchaus problematisch sein knnen, wie die folgenden Szenarien
zeigen:
In diesem Beispiel wird vom ersten Installationspaket eine Datei installiert, die vom zweiten
Installationspaket als benutzerdefinierte Aktion verwendet wird. Sicherlich weisen die Richtlinien
zur Gestaltung von benutzerdefinierten Aktionen auf diese Problematik hin und fordern dazu auf,
den binren Datenspeicher hierfr zu nutzen, aber die Praxis sieht leider anders aus. Kann jetzt
diese Datei dem System nicht hinzugefgt werden, da bereits eine ltere und vielleicht auch
inkompatible Version der Datei in Verwendung ist, kommt es zwangslufig zum Fehler bei
Ausfhren der benutzerdefinierten Aktion. Solange dieser Fehler auch transparent ist, kann auch
entsprechend reagiert werden. Mitunter sind benutzerdefinierte Aktionen so definiert, dass der
Rckgabewert ignoriert wird. Hierdurch kann das Fehlverhalten nicht sofort bemerkt werden, so
dass zwangslufig eine sptere Fehlersuche wesentlich erschwert wird. Hierbei sollte auch immer
bercksichtigt werden, dass vielfach Installationspakete verwendet werden, auf deren Gestaltung
kein Einfluss genommen werden kann und somit bestimmte Verhaltensmuster nicht offengelegt
sind.
Das zweite Beispiel ist etwas anderer Natur, da es sich direkt auf das Erscheinungsbild des finalen
Produktes auswirkt. Hierbei ist eine ausfhrbare Datei der Version 1.0 bereits in Verwendung und
kann somit ohne Computerneustart nicht ersetzt werden. Mit dem ersten Installationspaket soll
diese Datei durch die Version 1.5 ersetzt werden. Das ist zunchst nicht mglich, da die Datei in
Verwendung
ist.
Also
werden
die
entsprechenden
Eintragungen
unter
PendingFileRenameOperations vorgenommen, so dass die Datei nach dem nchsten Neustart
aktualisiert wird. Der Neustart wird unterdrckt und die nchste Installation ausgefhrt. Hierbei
wird die Datei in der Version 1.2 installiert. Windows Installer wendet natrlich die StandardVersionierungsregel an um zu berprfen, ob die bisherige Datei berschrieben werden soll.
Physisch befindet sich die Version 1.0 auf dem Computer, so dass die Versionsnummer 1.2 hher
ist und die Datei aktualisiert werden muss. Die Problematik ist bereits hier erkennbar; die Datei in
der Version 1.5 ist physisch noch nicht in der relevanten Form vorhanden, so dass sie an dieser
Stelle nicht bercksichtigt wird. Es kommt was kommen muss; auch die Version 1.2 der Datei wird
den PendingFileRenameOperations zugefgt. Im Rahmen des Neustarts werden die Eintragungen
dann sequentiell verarbeitet, wodurch zunchst die Version 1.0 gegen die Version 1.5
ausgewechselt wird und diese dann wiederum durch Version 1.2 berschrieben wird.
Sicherlich ist es elegant und mitunter auch notwendig einen Computerneustart zu unterdrcken, alle
Installationen sequentiell durchzufhren und erst im Anschluss das System neu zu starten. Das spart
Zeit ist komfortabel, kann aber auch einige Probleme verursachen, wie dieses auch gerade dargestellt
wurde. Hier muss nun die Frage nach den Lsungsmglichkeiten gestellt werden, falls denn solche
vorhanden sind.
259
Kapitel 6
Die Ursache fr das Verhalten und die daraus resultierende Probleme sind die verwendeten Dateien.
Falls diese frhzeitig freigegeben werden und somit whrend der Installation auch physisch ersetzt
werden knnten, wre ein Computerneustart nicht erforderlich. Hier kann optimiert werden und hier
wurde optimiert. Windows Vista und Windows Server 2008 enthalten eine Technologie, die als
Neustart-Manager bezeichnet wird und durch die diese Probleme adressiert werden. Der nchste groe
Block dieses Kapitels befasst sich intensiv mit dieser Technologie. Falls trotz Neustart-Manager und
anderer Technologien ein Computerneustart unumgnglich ist, sollte der Algorithmus seitens des
Windows Installers zur Nutzung der PendingFileRenameOperations optimiert werden. Auch dieses
Thema wurde adressiert; eine entsprechende Lsung wurde in den Windows Installer 4.5 integriert,
wie spter noch dargestellt wird. Falls aber kein Neustart-Manager vorhanden ist und auch der
Windows Installer 4.5 nicht genutzt wird, sind die Lsungsanstze sehr eingeschrnkt und die
Kreativitt des Entwicklers ist gefragt.
Ein denkbarer Ausweg aus dem Dilemma wre die berwachung der Eigenschaft ReplacedInUseFiles,
die vom Windows Installer automatisch gesetzt wird, falls bereits verwendete Dateien berschrieben
werden mssen. Dieses ist jedoch keine Lsung, denn einen Neustart wrde der Windows Installer
automatisch vornehmen, falls dieser nicht unterdrckt worden wre. Ein anderer Ansatz betrifft die
Eigenschaft MsiSystemRebootPending. Diese Eigenschaft wurde mit dem Windows Installer 4.0 neu
eingefhrt und wird vom Windows Installer automatisch gesetzt, falls ein Computerneustart noch
aussteht. Folgt man der Windows Installer-Dokumentation, sollte diese Eigenschaft von jedem Paket
ber die Tabelle LaunchCondition geprft werden um somit die Installation abzubrechen, falls ein
Neustart noch aussteht. Die Problematik liegt nun darin, dass die Eigenschaft
lediglich
die
Existenz
des
Registrierungseintrages
PendingFileRenameOperations prft. Es wird keine Verbindung zwischen den darin enthaltenen
Werten und den Dateien des Installationspaketes hergestellt. Dominik Oberlin hat in seinem Blog einen
interessanten Lsungsansatz vorgestellt, der diese Funktionalitt ergnzt. Hier wird eine
benutzerdefinierte Aktion vorgestellt, die die Eintrge aus PendingFileRenameOperations mit den
Dateien des Paketes vergleicht und das Ergebnis einer individuellen Eigenschaft zuweist. Hiermit wre
es mglich zu prfen, ob die in PendingFileRenameOperations registrierten Dateien einen
tatschlichen Einfluss auf den Installationsablauf haben. Der Nachteil liegt auch auf der Hand. Die
benutzerdefinierte Aktion muss in jedes Installationspaket integriert werden, was nicht immer mglich
ist. Sicherlich wre es auch denkbar einen hnlichen Mechanismus zwischen die einzelnen
Installationsaufrufe zu integrieren, um hier einen intelligenten Abbruchmechanismus zu schaffen.
Allerdings ist dieses auch keine saubere Lsung, denn vor der Installation kann nur der
Standardumfang der zu installierenden Dateien geprft werden, wodurch es zu Abweichungen
whrend der eigentlichen Installation kommen kann. Es ist erkennbar, dass scheinbar keine wirkliche
Lsungsmglichkeit existiert, dennoch ist dieser Ansatz recht interessant, wie auch die anderen
Eintrge des Blogs, die unter http://windowsinstaller.wordpress.com zu finden sind.

Wie in den vorangegangenen Erluterungen dieses Kapitels bereits angedeutet, wurde in Windows
Vista und Windows Server 2008 eine Technologie integriert, die als Neustart-Manager bezeichnet
wird. Die Zielsetzung dieser Technologie liegt in der Reduzierung der Computerneustarts im Rahmen
der Anwendungsinstallation und der Aktualisierung des Betriebssystems. Dieses ist zwingend
erforderlich, denn diese beiden Szenarien stellen die Hauptursachen fr Computerneustarts dar, wie
260
Abbildung 6.51 zeigt.
Abbildung 6.51: Technische Grnde fr einen Computerneustart
In Abbildung 6.51 ist weiterhin erkennbar, dass sich die Ursachen in einen geplanten und einen nicht
geplanten Bereich unterteilen lassen. Bei den nichtplanbaren Ursachen handelt es sich im
Wesentlichen um Fehler im Betriebssystem, der Anwendung oder der Hardware, die zum Neustart
fhren. Der grere und auch fr dieses Kapitel wichtigere Bereich betrifft die geplanten Aktionen,
also alles was im Zusammenhang mit der Installation steht. Hier wird deutlich dass sich fast 70% der
Neustarts dieser Kategorie zuordnen lassen. An dieser Stelle kommt nun der Neustart-Manager ins
Spiel, mit dem die Neustarts im Rahmen der Anwendungsinstallation um 70% und bei der
Aktualisierung des Betriebssystems um mindestens 50% reduziert werden sollen. Diese Werte sollen
erreicht werden, indem alle gngigen Installationsmechanismen wie Windows Installer, Windows
Update, Microsoft System Management Server und Microsoft System Center Configuration Manager
diese Technologie untersttzen. Hierbei ist zu bercksichtigen, dass nicht alle Ursachen fr einen
Computerneustart im Rahmen des Installationsprozesses hiermit optimiert werden knnen. So sind die
in Abbildung 6.49 skizzierten Prozess-, Kommunikations- und Konfigurationsprobleme aus
nachvollziehbaren Grnden hiervon ausgenommen. Der Neustart-Manager zielt somit auf die bereits
ausgiebig erluterte Hauptursache fr die Durchfhrung eines Computerneustarts hin, die darin
begrndet liegt, dass zum Installationszeitpunkt zu ersetzende Dateien bereits in Verwendung sind.
Das hieraus abzuleitende Ziel ist es, diese Dateien frhzeitig freizugeben, so dass sie problemlos
ersetzt werden knnen. Abbildung 6.52 zeigt die Grnde fr die Durchfhrung eines
Computerneustarts, sowie die darauf basierenden Lsungen. In der Abbildung sind ebenfalls die
Problempunkte erkennbar, die durch den Neustart-Manager adressiert werden:
Anwendungen speichern ihren Status automatisch und werden ohne Interaktion mit dem Benutzer
261
Kapitel 6
beendet und wieder neu gestartet.

Betriebssystemdienste werden gestoppt und die erforderlichen Dienstbibliotheken werden vom
Prozess svchost.exe entladen.
Einfach ausgedrckt fordert der Neustart-Manager die Anwendung auf ihren Status zu speichern,
beendet sie und startet sie nach dem Abschluss der Installation automatisch. Hierbei wird ebenfalls
sichergestellt, dass geladene Bibliotheken und Ressourcen ebenfalls entladen werden, so dass die
Dateien whrend der Installation problemlos ersetzt werden knnen.
Windows Installer 4.0 und Windows Installer 4.5 verwenden bei der Installation und der
Aktualisierung unter den Betriebssystemen Windows Vista und Windows Server 2008 automatisch
den Neustart-Manager, um hierdurch die Anzahl der erforderlichen Computerneustarts zu reduzieren.
Abbildung 6.52: Lsungsanstze durch den Neustart-Manager
Bevor die entsprechenden Anwendungen durch den Neustart-Manager beendet und wieder gestartet
werden knnen, sind natrlich zunchst die betroffenen Anwendungen zu ermitteln. Blicken wir an
dieser Stelle kurz zurck zum bereits erluterten Files-In-Use-Algorithmus. Bei der Ermittlung der
bereits verwendeten Dateien wurden hierbei nur PE-Dateien bercksichtigt. Im Weiteren wurden nur
Prozesse bercksichtigt, die ber ein sichtbares Fenster verfgen und die vom Benutzer tatschlich
beendet werden konnten. Hieraus lie sich ableiten, dass der Algorithmus fr normale
Anwendungen gut funktioniert, aber in vielen Szenarien doch einige Schwachpunkte aufweist.
Der Neustart-Manager arbeitet hier wesentlich effektiver, da der Algorithmus zum Erkennen der
bereits verwendeten Dateien nicht auf PE-Dateien beschrnkt ist. Dieser neue Mechanismus basiert
somit nicht mehr auf den Informationen des Schlssels HKEY_PERFORMANCE_DATA sondern
262
verwendet die existierenden Datenstrukturen des Speicher-Managers (Memory Manager) vom

Betriebssystem. Der Zugriff hierauf erfolgt ber die Windows-Funktion NtQueryInformationFile(), der
das Datei-Handle der zu berprfenden Datei bergeben wird. Das Ergebnis ist ein Array der Prozesse,
die diese Datei verwenden. Die Abfrage ist uerst effektiv, da alle ausfhrbaren Prozess-Abbilder
(Executable Images), alle im Speicher abgebildeten Dateien (Memory Mapped Files), sowie alle
geffneten Datendateien bercksichtigt werden. Darber hinaus werden auch Dateien bercksichtigt,
die ber das Netzwerk geffnet wurden. In diesem Fall ist es natrlich nicht mglich, den RemoteProzess zu ermitteln, der diese Dateien verwendet, so dass diese dem Systemprozess zugeordnet
werden. Dieser Prozess ist immer durch PID 4 gekennzeichnet und ist einfach ausgedrckt eine
Zusammenfassung des eigentlichen Betriebssystems und aller Treiber des Systems.
Der Neustart-Manager stellt eine Programmierschnittstelle zur Verfgung, ber die auf komfortable
Weise auf die gerade geschilderte Funktion und weitere Funktionen zugegriffen werden kann. Die
hierdurch zur Verfgung stehenden Funktionen sind in Tabelle 6.53 zusammengefasst.
Funktion
Beschreibung
RmAddFilter()
Entfernt eine Anwendung oder einen Dienst aus der Liste der zu
beendenden und / oder zu startenden Prozesse.
RmCancelCurrentTask()
Bricht die Ausfhrung der aktuellen Operation RmGetList(),

RmShutdown() oder RmRestart() ab.
RmEndSession()
Beendet eine Neustart-Manager Sitzung.
RmGetFilterList()
Gibt die mit RmAddFilter() erzeugte Liste der Prozesse zurck, die vom
Herunterfahren und / oder Neustarten ausgeschlossen wurden.
RmGetList()
Gibt eine Auflistung aller Anwendungen und Dienste zurck, die eine
Ressource verwenden, die in der Neustart-Manager-Sitzung registriert
wurden.
RmJoinSession()
Ermglicht es einem neuen Prozess sich mit einer bestehenden NeustartManager-Sitzung zu verbinden.
RmRegisterResources()
Ermglicht die Registrierung von Ressourcen in einen Neustart-Manager

Sitzung. Der Neustart-Manager bentigt diese Informationen zur
Ermittlung der Anwendungen und Dienste, die diese Ressource
verwenden.
RmRemoveFilter()
Entfernt einen Prozess aus der mit RmAddFilter() erzeugten AusschlussListe.
RmRestart()
Veranlasst das Starten der Anwendungen und Dienste. Ausgenommen

sind hierbei die mit der Funktion RmAddFilter() heraus gefilterten
Prozesse.
RmShutdown()
Veranlasst das Herunterfahren und Beenden der Anwendungen und

Dienste. Ausgenommen sind hierbei die mit der Funktion RmAddFilter()
heraus gefilterten Prozesse.
RmStartSession()
Erzeugt eine Neustart-Manager Sitzung. Es knnen maximal 64 NeustartManager-Sitzungen pro Benutzer-Sitzung zur gleichen Zeit gestartet
werden.
Tabelle 6.53: Funktionen der Programmierschnittstelle des Neustart-Managers
263
Kapitel 6
Die erste Aufgabe des Neustart-Managers besteht in der Ermittlung der derzeitig verwendeten
Ressourcen und die Identifizierung der Prozesse, die diese Ressourcen verwenden. Ich habe hier
bewusst den Begriff der Ressource verwendet, denn der Neustart-Manager ist nicht auf die Erkennung
von Dateien beschrnkt. So ist es auch mglich, den oder die Prozesse herauszufinden, die einen
Dienst, einen anderen Prozess oder lediglich eine Datei verwenden. Nachdem die betroffenen Prozesse
ermittelt wurden, werden diese durch den Neustart-Manager automatisch beendet und anschlieend
wieder neu gestartet, wie dieses auch in Abbildung 6.53 zu sehen ist. Durch die Verwendung einiger
Hilfsfunktionen ist es mglich die Auflistung der betroffenen Prozesse nachtrglich zu korrigieren.
Abbildung 6.53: Schematischer Ablauf innerhalb des Neustart-Managers
Nachdem der grob gefasste Ablauf innerhalb des Neustart-Managers bekannt ist, folgt eine detaillierte
Betrachtung der beiden relevanten Phasen.
Identifikation der verwendeten Ressourcen

Die Funktion RmStartSession() dient zum Erzeugen einer neuen Neustart-Manager-Sitzung und die
Funktion RmEndSession() zum Schlieen einer vorher gestarteten Sitzung. Die Funktion
RmStartSession() gibt bei erfolgreicher Ausfhrung ein Handle zurck, dass bei allen weiteren
diesbezglichen Funktionen zu verwenden ist, um die Neustart-Manager-Sitzung zu definieren.
Darber hinaus sind zunchst noch die Funktionen RmRegisterResources() und RmGetList() relevant.
Mit der Funktion RmRegisterResources() werden die Ressourcen registriert, die auf Verwendung
geprft werden sollen. Die Funktion RmGetList() gibt schlielich Informationen zu den Prozessen
zurck, die diese Ressourcen verwenden.
Zur Erlangung des Certified for Windows Vista Logos ist die Verwendung des Neustart-Managers im
Anwendungsdesign gefordert. Zur berprfung dieser Logo-Voraussetzungen wird eine
Toolsammlung mit der Bezeichnung Microsoft Logo Testing Tools for Windows bereitgestellt. Diese
Sammlung enthlt das fr dieses Thema relevante Tool rmtool.exe. Hiermit ist es unter anderem
mglich die verwendeten Ressourcen zu prfen. Im folgenden Beispiel wird geprft ob die Datei
hilfe.docx und der Betriebssystemdienst msiserver verwendet werden. Hierzu ist wird der folgende
Befehlszeilenaufruf ausgefhrt:
264
rmtool.exe -f c:\hilfe.docx -s msiserver

Das Ergebnis dieses Aufrufs ist in Listing 6.59 dargestellt. Es sind sehr gut die einzelnen Schritte vom
starten der Sitzung ber die Ergebnisliste bis zum Beenden der Sitzung zu erkennen. Falls betroffenen
Anwendungen existieren, die nicht beendet werden knnen, so dass ein Neustart erforderlich wre, ist
dieses unter reboot reasons vermerkt.
Starting Session
StartSession() returned 0
SUCCESS: StartSession()
Session Key: 00bfccac040fcd4cb508ada5d4d26656
Registering file
RegisterResources() returned 0
SUCCESS: RegisterResources()
Getting affected apps.
RmGetList() needs 2 structs, reboot reasons 0, returned 0xea
SUCCESS: Allocating RM_PROCESS_INFO array
SUCCESS: GetAffectedApps()
My PID: 5084, Affected Apps: 2, needed 2, reboot reasons 0
PID(1:3088, type 1, stat 1) - Microsoft Office Word ()
PID(0:1336, type 3, stat 1) - Windows Installer (msiserver)
Ending Session
EndSession() returned 0
SUCCESS: EndSession()
Listing 6.59: Ermitteln der verwendeten Dateien mit den Microsoft Logo Testing Tools for Windows
Die programmtechnische Umsetzung der gerade vorgestellten Funktionalitt stellt auch keine groe
Herausforderung dar, wie Listing 6.60 zeigt. Die relevante Funktion fr die Umsetzung ist
RmRegisterResources(), die wie folgt definiert ist:
[DllImport("rstrtmgr.dll", CharSet = CharSet.Unicode)]
internal static extern int RmRegisterResources(uint dwSessionHandle,
uint nFiles, string[] rgsFilenames,
uint nApplications, RM_UNIQUE_PROCESS[] rgApplications,
uint nServices, string[] rgsServiceNames);
Hierbei ist erkennbar, dass dem ersten Parameter das Handle der Neustart-Manager-Sitzung bergeben
wird. Die folgenden Parameter definieren die zu prfenden Ressourcen, wobei es sich immer um
Parameterpaare handelt. Der erste Parameter jeden Paares enthlt die Anzahl der Elemente des Arrays
das im zweiten Parameter bergeben wird. Die Parameterpaare sind wie folgt zu verwenden:
rgsFilenames: Hiermit werden zu berprfende Dateien festgelegt. Diese sind mit vollstndiger
Pfadangabe dem Array anzufgen. Falls keine Dateien zu berprfen sind, ist dieser Parameter auf
Null und der Parameter nFiles auf 0 zu setzen. Das gleiche gilt sinngem fr die weiteren
Parameterpaare.
rgApplications: Hiermit werden zu berprfende Anwendungen festgelegt, die hierzu einem Array
von Strukturen des Typs RM_UNIQUE_PROCESS angefgt werden. Die Struktur
RM_UNIQUE_PROCESS definiert einen eindeutigen Prozess und bentigt somit die Prozess-ID
(PID) und die Startzeit des Prozesses.
rgsServiceNames: Dieser Parameter wird bentigt um Betriebssystemdienste auf Verwendung zu
prfen.
Hierzu
sind
die
kurzen
Namen
des
Dienstes
wie
sie
unter
265
Kapitel 6
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services angeben sind, dem Array

anzufgen.
Das Beispiel in Listing 6.60 berprft lediglich auf verwendete Dateien, so dass die anderen
Parameterpaare auf 0 und Null gesetzt wurden. Die Funktion RmGetList() gibt letztlich die betroffenen
Prozesse als Array von Strukturen des Typs RM_PROCESS_INFO zurck. Es ist erkennbar, dass diese
Funktion zweimal aufgerufen wird. Der erste Aufruf, ermittelt lediglich die Anzahl der betroffenen
Prozesse, so dass hiermit das aufnehmende Array dimensioniert werden kann. Der zweite Aufruf fllt
letztlich das Array.
public void GetProcessesUsingFiles(IList<string> filePaths)
{
this.Processes.Clear();
uint sessionHandle;
// Erstellen der Neustart-Manager Sitzung
int rv = NativeMethods.RmStartSession(out sessionHandle, 0, Guid.NewGuid().ToString("N"));
if (rv == 0)
{
try
{
// Die zu prfenden Dateien dem Neustart-Manager bergeben
string[] pathStrings = new string[filePaths.Count];
filePaths.CopyTo(pathStrings, 0);
rv = NativeMethods.RmRegisterResources(sessionHandle,
(uint)pathStrings.Length, pathStrings, 0, null, 0, null);
if (rv != 0) throw new Win32Exception();
// Vom Neustart-Manager prfen lassen, welche anderen Anwendungen die Dateien verwenden
const int ERROR_MORE_DATA = 234;
uint pnProcInfoNeeded = 0, pnProcInfo = 0, lpdwRebootReasons = (uint)this.RebootReason;
rv = NativeMethods.RmGetList(sessionHandle, out pnProcInfoNeeded,
ref pnProcInfo, null, ref lpdwRebootReasons);
if (rv == ERROR_MORE_DATA)
{
// Array zum Aufnehmen der Resultate erstellen
NativeMethods.RM_PROCESS_INFO[] processInfo = new
NativeMethods.RM_PROCESS_INFO[pnProcInfoNeeded];
pnProcInfo = (uint)processInfo.Length;
// Liste abrufen
rv = NativeMethods.RmGetList(sessionHandle, out pnProcInfoNeeded,
ref pnProcInfo, processInfo, ref lpdwRebootReasons);
if (rv == 0)
{
// Grund fr einen eventuellen Neustart
this.RebootReason = (NativeMethods.RmRebootReason)lpdwRebootReasons;
// Enmeration der Resultate und hinzufgen zu der Prozessliste
for (int i = 0; i < pnProcInfo; i++)
{
try
{
266
this.Processes.Add(Process.GetProcessById(processInfo[i].Process.dwProcessId));
}
catch (ArgumentException) { } // Falls der Prozess gerade beendet wurde
}
}
else throw new Win32Exception(rv);
}
else if (rv != 0) throw new Win32Exception(rv);
}
finally
{
// Neutart-Manager Session schlieen
NativeMethods.RmEndSession(sessionHandle);
}
}
else
{
// Exception
throw new Win32Exception(rv);
}
}
Listing 6.60: Programmtechnisches Ermitteln der Prozesse die Dateien verwenden
Die Funktion RmGetList() erfllt hierbei mehrere Aufgaben. Im ersten Schritt wird eine Auflistung der
Prozesse erstellt, die eine durch RmRegisterResources() registrierte Ressource in Verwendung halten.
Im zweiten Schritt wird ermittelt ob die Prozesse beendet werden knnen und somit auf einen
notwendigen Computerneustart verzichtet werden kann. Zur Erstellung der Prozessauflistung werden
die folgenden Aktivitten durchgefhrt:
1. Ermitteln der Prozesse die Ressourcen verwenden: Es werden alle Prozesse identifiziert und der
Auflistung hinzugefgt, die derzeitig registrierte Ressourcen verwenden. Hierzu erfolgt ein Aufruf
der Funktion NTQueryInformationFile(). Es werden alle ausfhrbaren Prozess-Abbilder
(Executable Images), alle im Speicher abgebildeten Dateien (Memory Mapped Files), sowie alle
geffneten Datendateien bercksichtigt.
2. Hinzufgen der registrierten Prozesse: Es werden alle Prozesse der Auflistung angefgt, die dem
Parameter rgApplications der Funktion RmRegisterResources() bergeben wurden.
3. Hinzufgen der registrierten Dienste: Es werden alle Dienste der Auflistung angefgt, die dem
Parameter rgsServiceNames der Funktion RmRegisterResources() bergeben wurden.
4. Ermitteln abhngiger Dienste: Fr jeden Dienst der Auflistung werden die davon abhngigen
Dienste ermittelt und diese werden ebenfalls der Auflistung hinzugefgt.
5. Klassifizieren der Prozesse: Als letztes werden alle Prozesse der Auflistung klassifiziert. Die
mglichen Klassifizierungen sind in Tabelle 6.54 zusammengefasst. Die entsprechenden Werte
werden in die Eigenschaft ApplicationType der Struktur RM_PROCESS_INFO bertragen.
Hiermit ist die erste Aufgabe der Funktion RmGetList() abgeschlossen. Es wurde eine Liste von den
Prozessen erstellt, die Ressourcen in Verwendung halten und somit zu beenden sind, falls auf einen
Computerneustart verzichtet werden soll.
Wert
Beschreibung
267
Kapitel 6
RmUnknownApp (0)
Der Typ der Anwendung kann nicht bestimmt werden. Eine Anwendung dieses
Typs kann nur durch einen Computerneustart beendet werden.
RmMainWindow (1)
Eine Windows-Anwendung die ber ein sichtbares Fenster verfgt.
RmOtherWindow (2)
Eine Windows-Anwendung die ber sichtbares Fenster verfgt.
RmService (3)
Bei der Anwendung handelt es sich um einen Betriebssystemdienst.
RmExplorer (4)
Bei der Anwendung handelt es sich um den Windows-Explorer.
RmConsole (5)
Es handelt sich um eine Konsolenanwendung.
RmCritical (1000)
Ein Systemneustart ist zum Beenden dieses Prozesses erforderlich. Dieses ist
mglich, wenn es sich um einen kritischen Prozess oder Dienst handelt, der
Benutzer keine ausreichenden Privilegien besitzt, den Prozess zu beenden oder es
sich um den Prozess handelt, der die Neustart-Manager-Sitzung erzeugt hat.
Tabelle 6.54: Klassifizierung der ermittelten Prozesse
Zustzlich zum Erzeugen der Prozessliste wird noch geprft, ob die Prozesse auch beendet werden
knnen. Hierzu wird bei allen Prozessen der Liste u.a. die Eigenschaft ApplicationType ausgewertet.
Das Ergebnis dieser Prfung wird dem Parameter lpdwRebootReasons zugewiesen. Falls mindestens
ein Prozess nicht beendet werden kann, ist ein Neustart des Systems unumgnglich. Die mglichen
Grnde dafr sind in Tabelle 6.55 zusammengefasst.
Wert
Beschreibung
None (0x0)
Es ist kein Neustart erforderlich.
PermissionDenied (0x1)
Der Benutzer verfgt ber unzureichende Rechte mindestens einen Prozess

herunterzufahren.
SessionMismatch (0x2)
Prozesse werden in einer anderen Terminal-Server Sitzung oder einer

anderen Sitzung unter Verwendung der schnellen Benutzerumschaltung
ausgefhrt.
CriticalProcess (0x4)
Einige Prozesse sind systemkritisch und knnen daher nicht

heruntergefahren werden.
CriticalService (0x8)
Einige Dienste sind systemkritisch und knnen daher nicht

heruntergefahren werden. Beispiele dafr sind smss.exe, csrss.exe,
winit.exe, logonui.exe, lsass.exe, services.exe, winlogon.exe, System,
svchost.exe mit RPCSS und svchost.exe mit Dcom/PnP.
DetectedSelf (0x10)
Der aktuelle Prozess muss beendet werden.
Tabelle 6.55: Grnde in denen ein Computerneustart trotz Neustart-Managers erforderlich ist.
Beenden und Starten der Prozesse

Kommen wir nun zur zweiten Phase innerhalb der Neustart-Manager Sitzung, also die Phase, in der die
Prozesse beendet und somit die Ressourcen frei gegeben werden. An dieser Stelle knnen nun die
Ressourcen gegen andere Versionen ausgetauscht und anschlieend die Prozesse neu gestartet werden.
Die Basis fr diese Aktionen ist die ermittelte Prozessliste, die noch mit Hilfe der Funktionen
RmAddFilter() und RmRemoveFilter() verndert werden kann. Zunchst wird geprft ob alle Prozesse
beendet werden knnen, wozu der Parameter lpdwRebootReasons der Funktion RmGetList() geprft
268
wird. In das Beenden der Prozesse mglich werden alle Prozesse der Auflistung durch den NeustartManager aufgefordert ihren Status zu speichern und anschlieend werden sie beendet. Nach
Aktualisierung der Ressourcen, werden die Prozesse in umgekehrter Reihenfolge wieder gestartet.
Der wahrscheinlich komplizierteste und undurchsichtigste Aspekt in diesem Szenario ist das Speichern
des aktuellen Status der Anwendung. Der Neustart-Manager enthlt keine Mechanismen zum
Persistieren des Status. Er teilt lediglich der Anwendung mit das diese beendet werden muss. Dieses
setzt zwangslufig eine Implementierung zum Speichern und zum Wiederherstellen des Status in der
Anwendung voraus, wodurch spezielle Anforderungen an das Anwendungsdesign gestellt werden, die
natrlich von der Art der Anwendung abhngig sind. Der schematische Ablauf zum Speichern des
Status und dem Beenden einer Windows-Anwendung wird in Abbildung 6.54 dargestellt.
Abbildung 6.54: Ablauf beim Beenden einer Windows-Anwendung durch den Neustart-Manager
Im ersten Schritt informiert der Neustart-Manager alle Anwendungen, dass diese demnchst beendet
werden. Hierzu sendet er die Fenstermeldung WM_QUERYENDSESSION an die entsprechenden
Anwendungen, wobei der Parameter lParam auf ENDSESSION_CLOSEAPP gesetzt wurde. Die
jeweilige Anwendung gibt True zurck und signalisiert hierdurch dem Neustart-Manager, dass die
Vorbereitungen fr das Beenden und den Neustart abgeschlossen sind. Diese Meldung hat wie gesagt
nur informativen Charakter und verlangt zunchst noch keine besonderen Aktivitten seitens der
Anwendung. Es ist natrlich mglich, an dieser Stelle bereits den Status der Anwendung zu speichern.
Die Problematik liegt jedoch darin, dass der Neustart-Manager die Fenstermeldung an alle betroffenen
Anwendungen sendet. Gibt eine der Anwendungen False zurck oder reagiert innerhalb der
Zeitspanne von 5 Sekunden nicht auf die Meldung, wird der Vorgang zum Beenden der Anwendungen
abgebrochen, so dass ein entsprechender Speichervorgang umsonst ausgefhrt wurde. Gibt jedoch
keine der betroffenen Anwendungen False zurck, setzt der Neustart-Manager den Prozess fort, indem
die Fenstermeldung WM_ENDSESSION wiederum an alle Fenster gesendet wird. Auch bei dieser
Meldung wird Parameter lParam auf ENDSESSION_CLOSEAPP gesetzt. Dieses ist jetzt der Indikator
zum Herunterfahren der Anwendungen. Es ist somit an dieser Stelle zwingend erforderlich den
aktuellen Status der Anwendung zu speichern. Problematisch ist hierbei, dass ebenfalls nur ein
269
Kapitel 6
begrenzter Zeitraum von 5 Sekunden zur Verfgung steht, in dem der Status gespeichert werden muss.
Nach Ablauf dieser Zeitspanne wird die Anwendung beendet. Hierbei ist es unerheblich, ob die
Speicherung des Status abgeschlossen wurde oder nicht. Es kann somit mitunter effektiver sein eine
automatische Speicherung des Status periodisch durchzufhren. Nach dem Speichern der
Statusinformationen muss die Anwendung noch fr den automatischen Neustart registriert werden.
Hierzu ist die Funktion RegisterApplicationRestart() zu verwenden. Dieser Funktion kann eine
Befehlszeile bergeben werden, die wiederum beim Starten der Anwendung durch den NeustartManager verwendet wird. Schlielich sendet der Neustart-Manager noch die Fenstermeldung
WM_CLOSE, um auch Anwendungen zu beenden, die bisher nicht beendet wurden (LegacyApplikationen).
Listing 6.61 zeigt eine einfache Windows-Anwendung, die Implementierungen fr die Verwendung
des Neustart-Managers enthlt. Hierbei wird die Methode wndProc() berschrieben, so dass auf die
einzelnen
Nachrichten
reagiert
werden
kann.
Beim
Empfangen
der
Meldung
WM_QUERYENDSESSION wird als Ergebnis ein von IntPtr.Zero abweichender Wert zurckgeben,
um dem Neustart-Manager zu signalisieren, dass diese Anwendung fr den Neustart vorbereitet ist.
Beim
Empfangen
der
Fenstermeldung
WM_ENDSESSION
und
dem
Parameter
ENDSESSION_CLOSEAPP werden die Daten der verwendeten RichTextBox in einer temporren Datei
gespeichert. Anschlieend wird die Anwendung fr den automatischen Neustart registriert, wobei die
beim Neustart zu verwendenden Befehlszeilenparameter angegeben werden.
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
case Win32.WM_QUERYENDSESSION:
if (m.LParam.ToInt32() == Win32.ENDSESSION_CLOSEAPP)
{
// Falls Neustart untersttzt werden soll
m.Result = new IntPtr(1);
}
break;
case Win32.WM_ENDSESSION:
if (m.LParam.ToInt32() == Win32.ENDSESSION_CLOSEAPP)
{
// Prfen ob Daten vorhanden sind und ggf. speichern
if (this.richTextBox1.Text.Length > 0)
this.SaveData();
// Registrieren fr den Neustart
Win32.RegisterApplicationRestart(this.commandLineParameter, 0);
}
break;
default:
base.WndProc(ref m);
break;
}
}
Listing 6.61: Implementierung in einer Windows-Anwendung zur Untersttzung des Neustart-Managers
270
Die Windows-Funktion RegisterApplicationRestart() ist Bestandteil der neuen Funktionalitt zur

Anwendungswiederherstellung (Application Recovery) in Windows Vista und Windows Server 2008.
Weitere
interessante
und
in
diesem
Kontext
zu
sehende
Funktionen
sind
UnregisterApplicationRestart()
und
GetApplicationRestartSettings().
Die
Funktion
GetApplicationRestartSettings() ermglicht den Abruf der vorgenommen Einstellungen fr den
Neustart und UnregisterApplicationRestart() hebt letztlich die wieder Registrierung auf. In einem
speziellen Anwendungsfall wird die Funktion GetApplicationRestartSettings() sehr intensiv verwendet.
So kann es mitunter geschehen, dass ein Computerneustart nicht vermieden werden kann,
beispielsweise wenn der aufrufende Prozess oder ein anderer kritischer Prozess betroffen ist. In diesem
Fall hilft der Neustart-Manager weiter, denn der Status der registrierten Anwendungen wird nach dem
Neustart des Computers wieder hergestellt. Dieses wird durch eine Erweiterung der WindowsFunktionalitt erreicht. So wurde die Funktion ExitWindowsEx() um den Parameter
EWX_RESTARTAPPS und InitiateShutdown() um den Parameter SHUTDOWN_RESTARTAPP
erweitert. Wird also ein Computerneustart unter Verwendung der beiden Funktionen und Nutzung der
neuen Parameter durchgefhrt, werden die folgenden Aktionen fr die registrierten WindowsAnwendungen ausgefhrt:
Die Nachricht WM_QUERYENDSESSION wird gesendet. Der Parameter lParam ist auf
ENDSESSION_CLOSEAPP gesetzt.
Falls keine Anwendung ein Veto einlegt, wird die Befehlszeile zum Neustarten der Anwendung mit
GetApplicationRestartSettings() abgerufen.
Die Fenstermeldung WM_ENDSESSION wird gesendet. Der Parameter lParam ist auf
ENDSESSION_CLOSEAPP gesetzt.
Die
abgerufene
Befehlszeile
wird
unter
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce gespeichert, so
dass diese nach dem Neustart des Systems ausgefhrt wird.
Hierbei ist natrlich zu bercksichtigen, dass sich diese Funktionalitt nur auf Anwendungen bezieht,
die sich mit RegisterApplicationRestart() fr einen Neustart registriert haben.
Vielfach ist es erforderlich und gewnscht eine Anwendung auf Untersttzung der Neustart-Manager
Funktionalitt zu testen. Zu diesem Zweck kann wiederum das bereits erwhnte Tool rmtool.exe
verwendet werden. Soll beispielsweise getestet werden, ob Microsoft Word 2007 eine entsprechende
Implementierung enthlt, starten sie Word und ermitteln Sie im Taskmanager die entsprechende
Prozess-ID. Rufen Sie nun rmtool.exe auf und bergeben sie diese ID. Fgen Sie die Parameter zum
Beenden -S und zum Neustarten -R an. Alternativ kann die Angabe des Prozesses auch unter
Verwendung des Dateinamens erfolgen. Soll mit Hilfe dieses Tools die automatische
Wiederherstellung nach einem Computerneustart getestet werden, ist der Parameter -lr anzufgen.
Hierbei wird standardmig die Funktion InitiateShutdown() verwendet. Soll jedoch die Funktion
ExitWindowsEx() hierbei verwendet werden, ist der Parameter -lrw zu verwenden.
rmtool.exe p <PID> S R [-lr[w]]
Die Anwendung wird beendet und wieder neu gestartet. Die geffneten Dokumente werden
gespeichert und anschlieend wieder hergestellt. Alle Aktivitten innerhalb dieser Neustart-ManagerSitzung werden in der Konsole ausgegeben, wie dieses auch in Listing 6.62 erkennbar ist.
Starting Session
271
Kapitel 6
StartSession() returned 0
SUCCESS: StartSession()
Session Key: e5979c37583dd44096891a574cee9164
Registering file
RegisterResources() returned 0
SUCCESS: RegisterResources()
Shuting down applications
SUCCESS: RmShutdown()
Restarting Applications
SUCCESS: RmRestart()
Ending Session
EndSession() returned 0
SUCCESS: EndSession()
Listing 6.62: Neustarten einer Anwendung mit den Microsoft Logo Testing Tools for Windows
Die bisherigen Erluterungen und Beispiele bezogen sich ausschlielich auf Windows-Anwendungen.
Das Zusammenspiel zwischen dem Neustart-Manager und den Betriebssystemdiensten, sowie den
Konsolenanwendungen funktioniert leicht abweichend, so dass andere Implementierungen im
Anwendungsdesign zu bercksichtigen sind. Zum Beenden von Konsolenanwendungen sendet der
Neustart-Manger das CTRL_SHUTDOWN_EVENT Signal, so dass die mit SetConsoleCtrlHandler()
definierte Handler-Routine die Statusspeicherung veranlassen sollte. Das Beenden und Starten der
Betriebssystemdienste wird durch den Dienststeuerungs-Manager (Service Control Manager) oder kurz
SCM veranlasst. Dieser sendet nach Veranlassung durch den Neustart-Manger die jeweiligen Stoppund Start-Befehle an den entsprechenden Dienst. Falls der Dienst im Host Prozess fr Windows
Dienste (svchost.exe) ausgefhrt wird, muss er so registriert werden, dass die Objektbibliotheken
automatisch beim Beenden entladen werden. Hierzu ist der Registrierungseintrag
des
Schlssel
ServiceDllUnloadOnStop
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<Dienst>\Parameters auf den Wert
1 zu setzen.
Verwendung des Neustart-Managers durch den

272
Windows Installer
In den bisherigen Ausfhrungen dieses Kapitels wurden die beiden Mechanismen vorgestellt, mit
deren Hilfe die Probleme mit bereits verwendeten Dateien verringert werden sollen. Die als Files-InUse-, oder auch Legacy-Mechanismus bezeichnete Vorgehensweise ist hierbei das ltere Modell, dass
hervorragend bei Prozessen funktioniert, die ein sichtbares Fenster besitzen und vom Benutzer beendet
werden knnen. Der modernere Mechanismus, der als Neustart-Manager bezeichnet wird, geht einen
Schritt weiter, denn dieser bercksichtigt auch die folgenden Anwendungsarten:
Betriebssystemdienste
Anwendungen fr den Systeminfobereich (System Tray Applications)
Anwendungen, die ber kein sichtbares Fenster verfgen
Dieser Algorithmus ist jedoch nicht nur auf die Erkennung verwendeter Dateien beschrnkt, sondern
stellt noch eine Vielzahl von Funktionen zur Verfgung, mit denen die Notwendigkeit eines
Computerneustarts reduziert werden kann. Das wird ermglicht, durch die folgenden Aktivitten:
Herunterfahren aller ausgewhlten Anwendungen, Dienste und Prozesse.
Automatischer Neustart dieser Anwendungen, Dienste und Prozesse. Hierbei wird der Status
hergestellt, der vor dem Herunterfahren existierte.
Die Mglichkeit mehrere Neustart-Manger Sitzungen zu verknpfen und somit das Herunterfahren
der Anwendungen oder einen Computerneustart ber mehrere Installationen zusammenzufassen.
Es wird deutlich, dass der Neustart-Manager die effizientere Methode zur Adressierung des Problems
darstellt. Es stellt sich nun die Frage, welcher Algorithmus wird in welchem Fall verwendet.
Voraussetzungen fr die Verwendung des Neustart-Managers

Die einfache Frage nach dem jeweiligen Algorithmus ist nicht ganz so einfach zu beantworten, wie es
normalerweise zu erwarten wre. Eine einfache Antwort kann es nur fr die Betriebssysteme Windows
XP und Windows Server 2003 geben, denn hier wird immer der Files-In-Use-Mechanismus verwendet,
da der Neustart-Manager nur in Windows Vista und Windows Server 2008 zur Verfgung steht. Die
Komplexitt der Frage bezieht sich somit auf diese Betriebssysteme, da hier beide Algorithmen zur
Anwendung kommen knnen. Natrlich versucht der Windows Installer standardmig den
moderneren und effektiveren Mechanismus, also den Neustart-Manager zu verwenden. Standardmig
bedeutet jedoch dass es auch Ausnahmen gibt. Die folgenden Faktoren mssen somit zutreffen, damit
der Neustart-Manager verwendet wird.
Als Betriebssystem wird Windows Vista oder Windows Server 2008 verwendet.
Der Windows Installer wird in der Version 4.0 oder hher verwendet.
Die Interaktion mit dem Neustart-Manager wurde
oder
DisableAutomaticApplicationShutdown unterbunden.
nicht
die
durch
die Eigenschaft
Systemrichtlinie
Der Dialog MsiRMFilesInUse ist im Installationspaket vorhanden, falls die Installation unter
Verwendung der vollstndigen oder reduzierten Benutzeroberflche ausgefhrt wird.
Alle Aufrufe vom Windows Installer zum Neustart-Manager waren erfolgreich.
Eine ganz entscheidende Rolle im Interaktionsmechanismus zwischen dem Windows Installer und dem
273
Kapitel 6
Neustart-Manager spielt der neu geschaffene Dialog MsiRMFilesInUse. Hierbei handelt es sich um
eine fr den Neustart-Manager optimierte Fassung des alt bekannten Dialoges FilesInUse, wie dieses
auch Abbildung 6.55 zeigt.
Abbildung 6.55: Darstellung der Dialoge FilesInUse und MsiRmFilesInUse unter Verwendung der
vollstndigen Oberflche.
In diesem Dialog werden alle Prozesse angezeigt werden, die derzeitig Dateien verwenden, die
whrend des Installationsprozesses berschrieben oder gelscht werden mssen. Hierbei ist es
unerheblich, ob es sich bei den Prozessen um klassische Windows-Anwendungen,
Betriebssystemdienste oder andere Anwendungen handelt. Der Benutzer kann in diesem Dialog nun
auswhlen ob die Anwendungen automatisch geschlossen und wieder gestartet werden sollen, oder ob
die Anwendungen geffnet bleiben sollen, wodurch zwangslufig ein Computerneustart erforderlich
wird. Wird vom Anwender die Option zum automatischen beenden und starten der Anwendungen
gewhlt, muss dieses dem Windows Installer-Service mitgeteilt werden. Zu diesem Zweck steht das
neue Ereignis RMShutdownAndRestart zur Verfgung, dass durch die Besttigungsschaltflche des
Dialoges ausgelst wird. Listing 6.63 zeigt die Definition dieses Dialogs im Windows Installer-XML
Format. Es ist erkennbar, dass dieses Ereignis mit einer Bedingung verknpft ist. Die Bedingung
wiederum ist das Ergebnis der RadioButtonGroup, mit deren Hilfe der Benutzer bestimmen kann ob
die Anwendungen beendet werden sollen oder nicht. Bei der Bedingung ist weiterhin zu erkennen, dass
die Tilde dort dem Vergleichsoperator vorangestellt wird. Hierdurch wird ein Zeichenfolgenvergleich
durchgefhrt, bei dem die Gro- und Kleinschreibung nicht bercksichtigt wird.
<Dialog Id="MsiRMFilesInUse" X="50" Y="50" Width="370" Height="270" Title="Setup" KeepModeless="yes">
<Control Id="OK" Type="PushButton" X="240" Y="243" Width="56" Height="17" Text="OK" Default="yes">
<Publish Event="EndDialog" Value="Return">1</Publish>
<Publish Event="RMShutdownAndRestart" Value="0">WixUIRMOption~="UseRM"</Publish>
</Control>
<Control Id="Cancel" Type="PushButton" X="304" Y="243" Width="56" Height="17" Text="Abbrechen"
Cancel="yes">
274
<Publish Event="EndDialog" Value="Exit">1</Publish>

</Control>
<Control Id="ShutdownOption" Type="RadioButtonGroup" X="26" Y="190" Width="305" Height="45"
Property="WixUIRMOption"/>
<Control Id="BannerBitmap" Type="Bitmap" X="0" Y="0" Width="370" Height="44" Text="WixUI_Bmp_Banner"
Disabled="yes"/>
<Control Id="Description" Type="Text" X="20" Y="23" Width="280" Height="20" Text="Einige der zu
aktualisierenden Dateien werden gerade verwendet." TabSkip="yes" Transparent="yes" NoPrefix="yes" />
<Control Id="Text" Type="Text" X="20" Y="55" Width="330" Height="45" Text="Die folgenden Programme
verwenden Dateien, die bei der Installation aktualisiert werden mssen. Das Setup kann die Programme
schlieen und versuchen, sie neu zu starten, oder Sie lassen die Programme geffnet." TabSkip="yes"
/>
<Control Id="Title" Type="Text" X="15" Y="6" Width="200" Height="15" Text="Verwendete Dateien"
Transparent="yes" NoPrefix="yes"/>
<Control Id="BannerLine" Type="Line" X="0" Y="44" Width="370" Height="0" />
<Control Id="BottomLine" Type="Line" X="0" Y="234" Width="370" Height="0" />
<Control Id="List" Type="ListBox" X="20" Y="100" Width="330" Height="100" Property="FileInUseProcess"
Sunken="yes" />
</Dialog>
Listing 6.63: Definition des Dialogs MsiRmFilesInUse.

Hinweis Beginn
Die Integration des Dialogs MsiRMFilesInUse in Installationspakete hat keinen Einfluss auf die
Installation bei der Verwendung lterer Versionen des Windows Installer hat. Die Anzeige und die
Verwendung des Dialogs werden hierbei ignoriert.
Hinweis Ende
Die Existenz des Dialogs MsiRMFilesInUse im Installationspaket hat aber noch weiter gehenden
Einfluss. So wirkt sich die Existenz in einigen Fllen auf die Systemrichtlinie
DisableAutomaticApplicationShutdown und die Eigenschaft MSIRESTARTMANAGERCONTROL aus.
Beide Funktionen wurden geschaffen um manuell festzulegen, welcher Algorithmus zu verwenden ist.
Hierbei ist jedoch noch weiter zu differenzieren. Es wird unterschieden, ob der Neustart-Manager zur
Identifizierung der verwendeten Dateien benutzt werden soll und welcher Dialog zur Darstellung zu
verwenden ist. Die Richtlinie legt hierbei die Einstellung systemweit fest, die Eigenschaft fokussiert
hingegen lediglich die einzelne Installation. Das Installationsprotokoll gibt Auskunft ber die
jeweiligen Einstellungen. Wird die Nutzung des Neustart-Managers durch die Eigenschaft
verhindert,
findet
sich
folgender
Eintrag
im
Installationsprotokoll.
MSI (s) (D0:04) [14:38:01:261]: RESTART MANAGER: Disabled by MSIRESTARTMANAGERCONTROL property; Windows
Installer will use the built-in FilesInUse functionality.
Wurde hingegen die Systemrichtlinie DisableAutomaticApplicationShutdown zur nderung des

Verhaltens vom Neustart-Manager benutzt, finden sich folgende Eintragungen.
MSI (s) (D0:3C) [14:48:01:649]: Machine policy value 'DisableAutomaticApplicationShutdown' is 1
MSI (s) (D0:3C) [14:48:01:649]: RESTART MANAGER: Disabled by DisableAutomaticApplicationShutdown
system policy; Windows Installer will use the built-in FilesInUse functionality.
In beiden Fllen ist hervorragend zu erkennen, dass der Legacy-Mechanismus als Fallback verwendet
wird. Die mglichen Einstelloptionen der Eigenschaft und der Richtlinien sowie die Auswirkungen
sind in Tabelle 6.56 zusammengefasst.
275
Kapitel 6
Eigenschaftswert
Einstellung der
Richtlinie
Beschreibung
0 oder Null
0 oder nicht gesetzt
Dieses ist die Standardeinstellung. Windows Installer

verwendet den Neustart-Manager zur Identifizierung der
verwendeten Dateien und um die Anzahl notwendiger
Systemneustarts falls mglich zu reduzieren.
Disable
Die Interaktion mit dem Neustart-Manager wird

vollstndig deaktiviert. Die Erkennung der verwendeten
Dateien erfolgt ber den Legacy-Mechanismus. Die
betroffenen Prozesse werden im Dialog FilesInUse
angezeigt.
DisableShutDown
Zur Erkennung der verwendeten Dateien wird der

Neustart-Manager verwendet. Befindet sich der Dialog
MsiRMFilesInUse nicht im Installationspaket, werden
auch keine Prozesse automatisch beendet und neu
gestartet. Die betroffenen Prozesse werden im Dialog
FilesInUse angezeigt. Existiert der Dialog
MsiRMFilesInUse hingegen, wird der Neustart-Manager
vollstndig genutzt.
Tabelle 6.56: Optionen der Eigenschaft MSIRESTARTMANAGERCONTROL und der Richtlinie

Wird die Installation unter Windows Vista oder Windows Server 2008 ausgefhrt und wurde der
Neustart-Manager nicht deaktiviert, verwendet der Windows Installer den Neustart-Manager zur
Ermittlung der Prozesse, die derzeitig Dateien in Benutzung halten. Kommt es hierbei zu Problemen,
in dem die Funktionsaufrufe des Windows Installer zum Neustart-Manager fehlschlagen, wird eine
aussagekrftige Meldung dem Installationsprotokoll hinzugefgt. Weiterhin kommt nun der FallbackMechanismus ins Spiel; der Windows Installer verwendet den Legacy-Mechanismus zur
Identifizierung der entsprechenden Prozesse.
Wird die Installation unter Verwendung der vollstndigen oder reduzierten Benutzeroberflche
ausgefhrt und befindet sich der Dialog MsiRMFilesInUse im Installationspaket, so wird dieser zur
Darstellung der Prozesse verwendet. Ist dieser Dialog jedoch im Paket nicht vorhanden, so wird
geprft ob der Dialog FilesInUse vorhanden ist. Im positiven Fall wird dieser Dialog zur Darstellung
der Prozesse verwendet. Ist der Dialog nicht vorhanden, wird ein Computerneustart nach der
Installation ausgefhrt. Bei Verwendung der Basis-Oberflche, werden generell nur Dialoge angezeigt,
die durch die Windows Installer-Technologie bereitgestellt werden, also nur Dialoge die sich als
Ressource in der Datei msi.dll befinden. Die Ressourcen dieser Objektbibliothek wurden mit dem
Windows Installer 4.x um den Dialog IDD_RMFILESINUSE zur Bereitstellung der Neustart-Manager
Funktionalitt ergnzt, wie er auch in Abbildung 6.56 dargestellt wird. Somit wird bei Verwendung
der Basis-Oberflche der integrierte Dialog MsiRMFilesInUse zur Darstellung der Prozesse angezeigt.
276
Abbildung 6.56: Integrierter Dialog MsiRMFilesInUse bei Verwendung der Basis-Oberflche
Bei der gerade dargestellten Verwendung der Basis-Oberflche gibt es allerdings eine Ausnahme.
Wurde diese so konfiguriert dass keine modalen Dialoge angezeigt werden, beispielsweise durch das
Befehlszeilenargument qb-, gilt das gleiche wie bei einer Installation ohne Benutzeroberflche. Es
werden keine Dialoge angezeigt, so dass die Prozesse automatisch heruntergefahren und neu gestartet
werden. Dieses Verhalten des Windows Installers lsst sich auch sehr im Installationsprotokoll
nachvollziehen, das in einem solchen Fall die folgenden Zeilen enthlt:
MSI (s) (FC:20) [12:21:19:130]: RESTART MANAGER: Will attempt to shut down and restart applications
because the UI does not display any modal dialogs.
oder
MSI (s) (DC:C8) [11:42:52:664]: RESTART MANAGER: Will attempt to shut down and restart applications
in no UI modes.
Es sei anzumerken, dass dieses Standardverhalten noch durch Eigenschaften verndert werden kann,
die an sptere Stelle erlutert werden. Es wurde aber deutlich, dass die Existenz des Dialogs
MsiRMFilesInUse und der gewhlte Darstellungsmodus einen extremen Einfluss auf die Verwendung
des Neustart-Managers ausben, wie auch Tabelle 6.57 zeigt.
Dialog MsiRMFilesInUse
vorhanden
Dialog MsiRMFilesInUse nicht

vorhanden
Vollstndiges UI oder reduziertes

UI
Der Neustart-Manager wird zum

Herunterfahren und Starten der
Prozesse verwendet.
Zur Darstellung der Prozesse wird

der Dialog FilesInUse verwendet.
Falls dieser Dialog nicht im Paket
vorhanden ist, wird die Installation
fortgesetzt und ein
Computerneustart erfolgt nach
Abschluss der Installation.
Basis UI

Prozesse verwendet.

Prozesse verwendet.
277
Kapitel 6
Ohne UI

Prozesse verwendet.

Prozesse verwendet.
Tabelle 6.57: Interaktion zwischen dem Windows Installer und den Neustart-Manager in Abhngigkeit zur
Benutzeroberflche
Unabhngig von der Existenz des Dialogs MsiRMFilesInUse und dem gewhlten Darstellungsmodus,
lsst sich das Verhalten des Neustart-Managers noch weiter steuern. Die Eigenschaft
MSIRMSHUTDOWN ermglicht hierbei eine exaktere Steuerung des Verhaltens beim beenden oder
herunterfahren eines Prozesses, der Dateien verwendet. Die mglichen Einstellungen zeigt Tabelle
6.58. Fr die Eigenschaft MSIDISABLERMRESTART gilt nahezu das gleiche, hiermit kann hingegen
das Verhalten fr den Neustart beeinflusst werden, wie Tabelle 6.59 zeigt.
Eigenschaftswert
Beschreibung
0 oder Null
Prozesse oder Dienste, die Dateien verwenden, die vom Update betroffen sind, werden
beendet oder heruntergefahren. Dieses ist die Standardeinstellung.
Prozesse oder Dienste, die Dateien verwenden, die vom Update betroffen sind, werden
beendet, auch wenn diese nicht auf die Aufforderung des Neustart-Managers reagieren.
Prozesse oder Dienste die Dateien verwenden, die vom Update betroffen sind, werden
nur beendet oder heruntergefahren, wenn sie sich fr den Neustart registriert haben.
Falls mindestens ein Dienst oder Prozess sich hierfr nicht registriert, wird kein Dienst
oder Prozess beendet.
Tabelle 6.58: Einstelloptionen durch die Eigenschaft MSIRMSHUTDOWN
Das Verhalten durch die Option bedarf noch einiger Erluterungen. Grundlage sind Anwendungen, die
Dateien verwenden, die vom Update betroffen sind. Die Relevanz liegt im Anwendungsdesign bei der
Nachricht WM_QUERYENDSESSION. In der Standardeinstellung werden natrlich die Anwendungen
beendet, die diese Meldung mit True beantworten. Es werden aber auch Anwendungen beendet, die
auf diese Meldung gar nicht reagieren; also Legacy-Anwendungen. Lediglich wenn eine Anwendung
die Meldung mit False beantwortet, werden die betroffenen Anwendungen nicht beendet. Wird
allerdings die Eigenschaft MSIRMSHUTDOWN auf den Wert 1 gesetzt, werden alle Anwendungen
und Dienste beendet. Hierbei ist es unerheblich, ob es sich um Legacy-Anwendungen handelt oder um
Anwendungen fr den Neustart-Manager. Weiterhin ist es unerheblich ob diese Anwendungen die
Fenstermeldung mit True oder False beantworten. Alle Anwendungen werden hierbei beendet. Wird
die Eigenschaft hingegen auf 2 gesetzt, ist die Funktion RegisterApplicationRestart() uerst
interessant, denn nur wenn eine Anwendung sich hiermit fr den Neustart registriert hat, wird sie auch
beendet. Das Verhalten kann ber die Meldung WM_QUERYENDSESSION noch weiter verfeinert
werden. Wird diese Meldung mit False beantwortet, wird die Anwendung nicht beendet, auch wenn
sie fr den Neustart registriert wurde. Wird die Meldung hingegen mit True beantwortet oder wird
darauf gar nicht reagiert, wie es bei einer Legacy-Anwendung der Fall ist, ist nur die Registrierung
ausschlaggebend. Es sei noch anzumerken, dass hierbei das alles oder nichts Prinzip gilt. Existiert
mindestens eine Anwendung die das Beenden verhindert, wird keine betroffene Anwendung beendet
oder heruntergefahren.
Eigenschaftswert
Beschreibung
0 oder Null
Alle Betriebssystemdienste, die zur Installation des Updates heruntergefahren

wurden, werden neu gestartet. Alle Anwendungen, die sich fr den Neustart
278
registriert haben werden auch neu gestartet. Dieses ist die Standardeinstellung.
1
Die Prozesse, die zur Installation des Updates durch den Neustart-Manager
heruntergefahren oder beendet wurden, werden nicht neu gestartet.
Tabelle 6.59: Einstelloptionen durch die Eigenschaft MSIDISABLERMRESTART

Hinweis Beginn
Die Eigenschaften MSIRMSHUTDOWN und MSIDISABLERMRESTART werden ignoriert, falls der

Neustart-Manager nicht verfgbar ist oder deaktiviert wurde.
Hinweis Ende
Ein weiterer wichtiger Punkt bei der Interaktion zwischen dem Windows Installer und dem NeustartManager betrifft die Verwendung einer externen Benutzeroberflche. Da die Thematik der externen
Benutzeroberflche durchaus als komplex bezeichnet werden kann, ist dieser das Kapitel 9 gewidmet
in dem auch der Neustart-Manager nochmal aufgegriffen wird.
Interaktion mit dem Windows Installer

Im vorherigen Abschnitt wurden die Voraussetzungen zur Verwendung des Neustart-Managers im
Installationsprozess beschrieben. An der einen oder anderen Stelle wurde bereits auf die Interaktion
mit dem Windows Installer eingegangen, ohne hierbei nher ins Detail zu gehen. Das soll an dieser
Stelle nachgeholt werden, wobei sich die vornehmliche Betrachtung auf den Server-Prozess bezieht.
Die primre Komponente dieses Prozesses ist der Konfigurationsmanager, der im Rahmen der
Initialisierung die Installationsaufforderung vom Client empfngt, wozu ihm der ProductCode, die
Top-Level-Aktion, die Befehlszeile, Informationen zur Protokollierung und eine Referenz auf den UIHandler bergeben werden. Im Rahmen dieser Initialisierung werden alle der eigentlichen Installation
vorgelagerten Aktivitten ausgefhrt. Hierbei handelt es sich somit um Ttigkeiten, die vor der ersten
Aktion der entsprechenden Ausfhrungssequenz-Tabelle abgearbeitet werden. Beispiele hierfr sind
sicherheitsrelevante Prfungen, Kompatibilittsmanahmen und Analysen der derzeitigen
Systemkonfiguration. Whrend dieser Initialisierungsphase wird auch eine Neustart-Manager-Sitzung
erstellt und die Eigenschaft MsiRestartManagerSessionKey gesetzt, falls die Interaktion mit dem
Neustart-Manager nicht deaktiviert wurde, wie dieses im vorherigen Abschnitt erlutert wurde. Im
Installationsprotokoll sind die diesbezgliche Informationen zu finden.
MSI (s) (40:84)
MSI (s) (40:84)
Its value is
MSI (s) (40:84)
[16:16:29:341]: Machine policy value 'DisableAutomaticApplicationShutdown' is 0

[16:16:29:341]: PROPERTY CHANGE: Adding MsiRestartManagerSessionKey property.
'0fb4397a83ec0040be8ba7c57d4da084'.
[16:16:29:341]: RESTART MANAGER: Session opened.
Der relevante Teil der Initialisierungsphase ist danach abgeschlossen, so dass mit der Abarbeitung der
Aktionen der Ausfhrungssequenz-Tabelle begonnen wird. Die ersten bedeutsamen Aktionen dienen
der Berechnung des Speicherbedarfs (CostInitialize, FileCost und CostFinalize). Die Bezeichnung
Costing-Actions fr diese Aktionen ist jedoch nicht sehr glcklich gewhlt, denn die Ausfhrung der
Aktionen ermittelt nicht nur den Speicherbedarf, sondern dient auch dazu, die
Installationsverzeichnisse zu bestimmen. Am Ende dieser Phase stehen somit die finalen
Installationsverzeichnisse und die zu installierenden Komponenten fest. Somit werden nun die zu
berwachenden Datei-Ressourcen an den Neustart-Manager bergeben.
Whrend der Aktion InstallValidate fordert der Windows Installer den Neustart-Manager schlielich
auf, alle Prozesse zu ermitteln die heruntergefahren werden mssen, damit die Installation ohne
279
Kapitel 6
Neustart durchgefhrt werden kann. Stellt der Neustart-Manager fest, dass eine Datei durch einen
kritischen Prozess, durch den aufrufenden Prozess (Windows Installer-Client) oder durch den
Windows Installer-Dienst verwendet wird, kann der Neustart nicht verhindert werden. Dieses wird
auch im Installationsprotokoll entsprechend vermerkt.
MSI (s) (40:84) [16:16:29:541]: RESTART MANAGER: Did detect that the client process of this installation
holds file[s] in use, so a reboot will be necessary.
oder
MSI (s) (DC:9C) [13:34:18:060]: RESTART MANAGER: Did detect that a critical application holds file[s]
in use, so a reboot will be necessary.
In Abhngigkeit zur Existenz des Dialogs MsiRMFilesInUse im Installationspaket, stehen nun die
folgenden Vorgehensweisen zur Auswahl:
Die Installation wird bei Legacy-Installationspaketen, also bei Paketen ohne den Dialog
MsiRMFilesInUse, fortgesetzt.
Der Windows Installer sendet bei Installationspaketen, die den Dialog MsiRMFilesInUse enthalten,
die Meldung Setup muss Dateien oder Dienste aktualisieren, die nicht whrend der Ausfhrung
des Systems aktualisiert werden knnen. Wenn Sie den Vorgang fortsetzen, ist ein Neustart
erforderlich, um das Setup abzuschlieen mit der Fehlernummer 1610.
Im nchsten Schritt wird durch den Neustart-Manager geprft, ob auch Betriebssystemdienste
betroffen sind und somit heruntergefahren werden mssen. Hierbei ist zu beachten, dass Dienste, die
mit Hilfe der Tabellen ServiceInstall und ServiceControl verwaltet und konfiguriert werden, nicht
durch den Neustart-Manager, sondern durch den Windows Installer unter Verwendung der Aktionen
StartServices und StopServices selbst beendet und neu gestartet werden. Lediglich Dienste, die keinen
direkten Bezug zum eigentlichen Installationspaket aufweisen, werden vom Neustart-Manger gestoppt
und gestartet.
Bis zu diesem Zeitpunkt wurden vom Neustart-Manager die Betriebssystemdienste und die sonstigen
Prozesse ermittelt, die von der Installation betroffen sind und somit beendet oder heruntergefahren
werden sollten. Die Verwaltung der betroffenen Betriebssystemdienste stellt keine groe Schwierigkeit
dar, da diese in der gleichen Windows-Sitzung (Session 0) ausgefhrt werden, wie der Windows
Installer selbst. Schwieriger wird es bei den anderen Prozessen, die beispielsweise vom Benutzer direkt
gestartet wurden. Der Neustart-Manager kann den Typ der Anwendung nicht erkennen und er kann die
Anwendung nicht beenden und neu starten, da diese in einer anderen Windows-Sitzung ausgefhrt
wird. Dieses wird auch im nachfolgenden Auszug aus Installationsprotokoll sehr gut verdeutlicht. Der
Betriebssystemdienst wird eindeutig identifiziert, so dass auch der Anwendungstyp bestimmt werden
kann. Die anderen Prozesse knnen vom Server-Prozess nicht weiter analysiert werden; der
Anwendungstyp wird auf RmUnknownApp gesetzt.
MSI (s) (30:10) [12:50:39:208]: RESTART MANAGER: Detected that application with id 3200,
friendly name 'NonAdmin', of type RmUnknownApp and status 1 holds file[s] in use.
friendly name 'RMEditor', of type RmUnknownApp and status 1 holds file[s] in use.
friendly name 'Restart Service', service short name 'Service1', of type RmService and
status 1 holds file[s] in use.
An dieser Stelle wird nun der Client-Prozess involviert. Der Server-Prozess sendet eine Meldung zum
280
Client-Prozess und fragt nach, ob er die betroffenen Prozesse beenden oder herunterfahren kann.
Zustzlich werden auch die Informationen zu den Betriebssystemdiensten bertragen, so dass diese
vom Client im entsprechenden Dialog angezeigt werden knnen. Zur Realsierung muss der ClientProzess ebenfalls eine Neustart-Manager-Sitzung erzeugen, wie dieses auch im Installationsprotokoll
dargestellt wird. Zu beachten ist hierbei der Prfix MSI (c), der auf die Eintragungen des ClientProzesses hinweist. Es ist ebenfalls gut zu erkennen, dass der Client-Prozess nun auch den Typ der
Anwendungen bestimmen kann.
MSI (c) (3C:8C) [12:50:39:229]: RESTART MANAGER: Session opened.
MSI (c) (3C:8C) [12:50:39:235]: RESTART MANAGER: Detected that application with id 3200,
friendly name 'NonAdmin', of type RmMainWindow and status 1 holds file[s] in use.
friendly name 'RMEditor', of type RmMainWindow and status 1 holds file[s] in use.
friendly name 'Restart Service', service short name 'Service1', of type RmService and
Als nchstes wird vom Client-Prozess geprft, ob alle betroffenen Prozesse vom Neustart-Manager
beendet werden knnen. Hierzu wird der Parameter lpdwRebootReasons der Funktion RmGetList()
ausgewertet, wie das bereits an einer vorherigen Stelle beschrieben wurde. Die beiden folgenden
Szenarien werden hierbei betrachtet:
Es wurde ein Prozess ermittelt, der in einer anderen Benutzer-Sitzung ausgefhrt wird.
Es wurde festgestellt, dass unzureichende Privilegien vorhanden sind um den Prozess zu beenden.
In keinem dieser Flle kann der jeweilige Prozess beendet werden. Der Benutzer wird davon in
Kenntnis gesetzt und ebenfalls darber informiert, dass ein Neustart des Computers erforderlich ist.
Weist der Parameter lpdwRebootReasons hingegen darauf hin, dass kein Computerneustart erforderlich
ist, werden letztlich die zu beendenden Prozesse dem Benutzer angezeigt. Hierzu wird die Meldung
INSTALLMESSAGE_RMFILESINUSE an alle externen UI-Handler gesendet, soweit diese existieren
und auch die Meldung durch das Attribut INSTALLLOGMODE_RMFILESINUSE abonniert haben.
Falls das nicht der Fall ist, wird die Meldung an den internen UI-Handler weitergeleitet.
Letztlich entscheidet der Benutzer an dieser Stelle, was mit den entsprechenden Prozessen geschehen
soll. Wird hier nun der Windows Installer angewiesen, die betroffenen Prozesse zu beenden, kommt
zunchst der Server-Prozess ins Spiel. Dieser veranlasst nun den serverseitigen Neustart-Manager alle
Betriebssystemdienste zu beenden, die heruntergefahren werden mssen. Anschlieend findet wieder
ein Wechsel zum Client-Prozess statt. Hier wird nun der clientseitige Neustart-Manager angewiesen,
die von ihm zu verwaltenden Prozesse zu beenden, wie dieses auch an den beiden folgenden Zeilen des
Protokolls ersichtlich wird.
MSI (s) (30:10) [12:50:46:304]: RESTART MANAGER: Successfully shut down all applications in
the service's session that held files in use.
MSI (c) (3C:8C) [12:50:46:304]: RESTART MANAGER: Successfully shut down all applications that
held files in use.
Es bleibt noch anzumerken, dass diese standardmige Vorgehensweise zum Herunterfahren der
Prozesse durch die Eigenschaft MSIRMSHUTDOWN beeinflusst werden kann.
Der Neustart-Manager kann Prozesse nicht beenden, wenn diese nicht auf die Fenstermeldungen
WM_ENDSESSION oder WM_CLOSE reagieren oder falls es sich um einen Betriebssystemdienst
handelt und dieser nicht auf die Aufforderungen des Dienststeuerungs-Manager (SCM) reagiert. Falls
281
Kapitel 6
der Neustart-Manager mindestens einen Prozess nicht herunterfahren kann, zeigt der Windows
Installer die Meldung Setup konnte nicht alle angeforderten Anwendungen automatisch schlieen.
Stellen Sie sicher, dass die Anwendungen, in denen verwendete Dateien geffnet sind, vor dem
Fortsetzen der Installation geschlossen werden mit der Nummer 1611 an, falls das Installationspaket
den Dialog MsiRMFilesInUse enthlt. Falls kein Dialog enthalten ist, wird die Installation fortgesetzt,
wobei ein Neustart jedoch erforderlich wird.
Was jetzt noch fehlt ist der Neustart der Anwendungen. Nach Abschluss der Installation, fordert der
Server-Prozess den Neustart-Manager auf alle Betriebssystemdienste neu zu starten, die
heruntergefahren wurden. Der Client-Prozess fordert hingegen den clientseitigen Neustart-Manager auf
alle Anwendungen zu starten, die durch die Funktion RegisterApplicationRestart() fr den Neustart
registriert wurden. Anschlieend werden die Neustart-Manager-Sitzungen geschlossen.
MSI
MSI
MSI
MSI
(s) (30:20) [12:50:49:265]: RESTART MANAGER: Previously shut down applications have been restarted.
(s) (30:20) [12:50:49:265]: RESTART MANAGER: Session closed.
(c) (3C:8C) [12:50:50:753]: RESTART MANAGER: Previously shut down applications have been restarted.
(c) (3C:8C) [12:50:50:753]: RESTART MANAGER: Session closed.
Zu Beginn dieses Kapitels wurde auf die Problematik des Unterdrckens eines Computerneustarts
hingewiesen. Diese Problematik bleibt natrlich trotz Neustart-Manager bestehen; die Notwendigkeit
eines Neustarts wird hingegen hierdurch reduziert. Die Zielsetzung sollte immer in der Stabilitt der
Installation und der spteren Anwendung liegen, so dass Neustarts entsprechend zu bercksichtigen
sind. Die Eigenschaft MsiSystemRebootPending kann hier eine Hilfestellung geben, denn sie
signalisiert einen ausstehenden Neustart.
Hinweis Beginn
Die Aktionen des Neustart-Managers werden auch dem Windows-Ereignisprotokoll angefgt, so dass
dieses auch eine wertvolle Informationsquelle darstellt.
Hinweis Ende
Wie im vorherigen Abschnitt verdeutlicht, findet whrend der Costing-Phase nicht nur die finale
Bestimmung der Zielverzeichnisse statt, sondern die primre Zielsetzung dieser Phase ist die
Bestimmung des Installationsumfangs, wozu die Installationsverzeichnisse zwangslufig bentigt
werden. Zunchst wird hierbei ermittelt, welche Windows Installer-Features fr die Installation
vorgesehen wurden. Durch die Verknpfung der Windows Installer-Komponenten zu den Features
kann nun ermittelt werden, welche Komponenten letztlich von der Installation betroffen sind. Da es
sich bei den Komponenten um eine logische Gruppierung unterschiedlicher Ressourcen handelt,
knnen die einzelnen Ressourcen auch individuell betrachtet werden. An dieser Stelle sind nur DateiRessourcen von Bedeutung, die sich in Komponenten befinden, die fr die Installation vorgesehen
wurden. Die so ermittelten Datei-Ressourcen werden whrend der Costing-Phase nun zur
berwachung an den Neustart-Manager bergeben.
Aus diesem kurz gefassten Ablauf wird deutlich, dass sich die Aktivitten des Neustart-Managers
ausschlielich auf Dateien beziehen, die im Installationspaket oder detaillierter betrachtet in der
Tabelle File definiert wurden. Mitunter existieren jedoch Szenarien, in denen diese Vorgehensweise
nicht ausreichend ist. So knnen Szenarien vorhanden sein, in denen Dateien von entsprechenden
Anwendungen dynamisch erzeugt werden, wie es beispielsweise bei Konfigurationsdateien der Fall
282
sein kann. Dennoch kann es erforderlich werden, dass eine solche Datei whrend der Installation eines
Updates modifiziert werden muss, wozu eine benutzerdefinierte Aktion zu verwenden ist. Eine solche
Vorgehensweise ist zwangslufig problematisch, falls die Datei verwendet wird, so dass die
Modifikation nicht erfolgen kann. Um solche Szenarien effektiv zu lsen, kann ebenfalls der NeustartManager verwendet werden. Es ist lediglich erforderlich, die entsprechende Datei vom NeustartManager berwachen zu lassen. In diesem Fall wrde der Neustart-Manager whrend der Installation
feststellen, dass die Datei verwendet wird. Er wrde den betroffenen Prozess beenden, so dass die
Modifikationen im Rahmen der Installation erfolgen knnen. Nach dem Abschluss der Installation
wrde er den Prozess erneut starten.
Der Windows Installer enthlt in der aktuellen Version leider keine entsprechende Implementierung,
um solche Szenarien direkt umsetzen zu knnen. Es besteht allerdings die Mglichkeit, ein solches
Szenario im Rahmen einer benutzerdefinierten Aktion umzusetzen. Das entscheidende Element hierzu
ist die Eigenschaft MsiRestartManangerSessionKey. Diese Eigenschaft wird whrend der
Initialisierungsphase des Installationsprozesses erzeugt, falls die Nutzung des Neustart-Managers nicht
deaktiviert wurde. Mit Hilfe der Funktion RMJoinSession() ist es mglich, die Verbindung mit einer
existierenden Neustart-Manager-Sitzung herzustellen. In einigen Dokumentationen zum NeustartManager finden sich hierfr auch Bezeichnungen wie Primrer- und Sekundrer-Installer. Als
sekundrer Installer wird die Implementierung bezeichnet, die sich unter Verwendung der Funktion
RMJoinSession() mit einem primren Installer verbindet. Der Windows Installer ist in diesem
Zusammenhang natrlich der primre Installer, wogegen die benutzerdefinierte Aktion letztlich der
sekundre Installer ist.
Der Funktion RMJoinSession() wird einfach ausgedrckt, der Sitzungs-Schlssel des primren
Installers bergeben, der im Zusammenhang mit dem Windows Installer der Eigenschaft
MsiRestartManangerSessionKey entspricht. Wurde die Funktion erfolgreich ausgefhrt ist das
Ergebnis ein Handle fr eine Neustart-Manager-Sitzung, dass fr alle weiteren diesbezglichen
Funktionen zu verwenden ist. So kann nun die Funktion RmRegisterResources() verwendet werden,
um zustzliche Ressourcen zu registrieren. Es ist unbedingt zu beachten, dass im Rahmen der
benutzerdefinierten Aktion lediglich Einfluss auf die Registrierung der Ressourcen genommen werden
kann. So knnen ausschlielich neue Dateien registriert werden, es ist hingegen nicht mglich,
prozessbezogene Aktionen direkt zu veranlassen. Die Funktionen RmShutdownApplications(),
RmRestartApplications() und RmGetAffectedApplications() und auch RmAddFilter() und
RmRemoveFilter() drfen somit nur durch einen primren Installer verwendet werden. Nachdem alle
Aktivitten im Rahmen der benutzerdefinierten Aktion vorgenommen wurden, muss die Verbindung
zur Neustart-Manager-Sitzung auch wieder beendet werden, indem die Funktion RMEndSession()
aufgerufen wird.
Hinweis Beginn
Wird innerhalb einer benutzerdefinierten Aktion die Funktion RmJoinSession() aufgerufen, so muss
auch RmEndSession() aufgerufen werden, nachdem die Registrierung der Ressourcen abgeschlossen
wurde.
Hinweis Ende
Eine besondere Relevanz erfhrt noch die Eigenschaft MsiRestartManangerSessionKey. Wie bereits
dargestellt wird diese Eigenschaft whrend der Initialisierungsphase erzeugt. Falls der NeustartManager nicht verwendet wird und somit der Fallback-Mechanismus zum Tragen kommt, wird diese
Eigenschaft wieder gelscht. Dieses Verhalten ist unbedingt innerhalb der benutzerdefinierten Aktion
zu bercksichtigen.
283
Kapitel 6
Wird der Neustart-Manager verwendet, bleibt jedoch die Eigenschaft MsiRestartManangerSessionKey

nicht unbegrenzt bestehen. Diese Eigenschaft wird whrend der Eigenschaft InstallValidate gelscht,
wie dieses auch im Installationsprotokoll ersichtlich ist.
Action start 13:34:18: InstallValidate.
MSI (s) (DC:9C) [13:34:18:027]: PROPERTY CHANGE: Deleting MsiRestartManagerSessionKey property.
Its current value is 'cb63209c2e99e14e8953fa4aabb568a0'.
Dieses Verhalten ist uerst sinnvoll, denn whrend der Aktion InstallValidate wird der NeustartManager vom Windows Installer bereits aufgefordert, die betroffenen Prozesse zu ermitteln. Aus
diesem Grund wrde es keinen Sinn machen, nach der Aktion InstallValidate noch zustzliche
Ressourcen zu registrieren, wozu dieser Schlssel bentigt wird. Um eine potentielle Fehlerquelle zu
vermeiden, steht die Eigenschaft nach InstallValidate nicht mehr zur Verfgung, so dass auch keine
entsprechenden Funktionen mehr ausgefhrt werden knnen. Fr eine benutzerdefinierte Aktion, die
den Neustart-Manager verwenden mchte, ergibt sich somit die Einschrnkung, dass sie vor der
Aktion InstallValidate ausgefhrt werden muss.
Nun aber genug mit der Theorie, lassen sie uns ein kurzes Beispiel konstruieren und beginnen wir
zunchst mit dem Installationspaket. Eine benutzerdefinierte Aktion sollte immer datengesteuert
ausgefhrt werden, so dass die tatschliche Implementierungslogik von den zu verwendenden
Informationen getrennt wird. Eine solche Vorgabe kann durch Tabellen realisiert werden, auf die durch
benutzerdefinierte Aktionen zugegriffen wird. Diese Vorgehensweise ermglicht eine effektive
Wiederverwendung der Programmlogik und lsst die gesamte Implementierung transparenter
erscheinen. Zur Realisierung einer solchen Vorgehensweise und somit der Trennung zwischen
Implementierung und Daten wurde dem Installationspaket die Tabelle RestartManagerFiles
hinzugefgt. Diese Tabelle enthlt die Spalten File und Path, wobei es sich bei File lediglich um die
Schlsselspalte handelt. Die Spalte Path ist hier wesentlich interessanter, denn hier werden die
vollstndigen Pfade zu den zustzlich zu registrierenden Ressourcen angegeben, wie dieses auch
Listing 6.64 zeigt:

<CustomTable Id="RestartManagerFiles">
<Column Id ="File" Nullable="no" Category="Identifier" PrimaryKey="yes" Type="string" Width="72"/>
<Column Id ="Path" Nullable="yes" Category="Formatted" Type ="string" Width ="0" />

<Row>
<Data Column="File">F__Data</Data>
<Data Column="Path">[INSTALLLOCATION]RMData.xml</Data>
</Row>
</CustomTable>
Listing 6.64: Benutzerdefinierte Tabelle zum registrieren zustzlicher Datei-Ressourcen
Nachdem die Datenbasis definiert wurde, kommen wir zur Implementierung. Diese wurde in der
Programmiersprache C# unter Verwendung der Deployment Tools Foundation erzeugt. Der Name und
somit die exportierte Funktion der benutzerdefinierten Aktion ist RegisterRestartFiles(). Nach dem
Festlegen
einiger
Konstanten
wird
zunchst
geprft,
ob
die
Eigenschaft
MsiRestartManagerSessionKey festgelegt wurde. Falls das nicht der Fall ist, werden keine weiteren
Aktivitten ausgefhrt, da der Neustart-Manager deaktiviert wurde oder nicht verfgbar ist. Wurde
hingegen diese Eigenschaft gesetzt, wird im nchsten Schritt geprft, ob die Tabelle
RestartManagerFiles im Installationspaket existiert und ob diese ber die Spalte Path verfgt. Ist das
284
der Fall wird auf die Tabelle zugegriffen und alle Eintrge werden innerhalb einer Schleife verarbeitet.
Dieses ist erforderlich, um eventuell verwendete Platzhalter oder Variablen innerhalb der Pfadangabe
durch absolute Werte zu ersetzen. Dieses erfolgt innerhalb des Programmcodes durch den Befehl
Format() des Session-Objektes. Letztlich werden alle so transformierten Dateipfade in ein Array
umgewandelt und an die Funktion RegisterFiles() ebenso bergeben wie der Inhalt der Eigenschaft
MsiRestartManagerSessionKey.
Diese Funktion ist letztlich das Herzstck der benutzerdefinierten Aktion, denn hier findet die
eigentliche Kommunikation mit dem Neustart-Manager statt. Zu Beginn wird die Funktion
RmJoinSession() aufgerufen, der der Schlssel der Neustart-Manager-Session bergeben wurde. Die
Funktion gibt ein Handle zurck, dass beim Aufruf der Funktion RmRegisterResources() verwendet
wird. Dieser Funktion wird nun das Array der Datei-Ressourcen bergeben; auf die Registrierung von
zustzlichen Prozessen und Diensten wurde hier verzichtet, so dass die betroffenen Parameter auf Null
gesetzt wurden. Als letztes wird schlielich noch RmEndSession() aufgerufen, um hiermit die
Registrierung zustzlicher Ressourcen abzuschlieen, wie dieses auch Listing 6.65 dargestellt wird.
public class CustomActions
{
// Deklarationen
static extern int RmJoinSession(out uint pSessionHandle, string strSessionKey);
[DllImport("rstrtmgr.dll")]
static extern int RmEndSession(uint pSessionHandle);
static extern int RmRegisterResources(uint pSessionHandle, UInt32 nFiles, string[] rgsFilenames,
UInt32 nApplications, object[] rgApplications, UInt32 nServices, string[] rgsServiceNames);
/// <summary>
/// Registrieren der zustzlichen Dateien fr den Neustart-Manager
/// </summary>
/// <param name="session">Referenz auf die Installations-Sitzung</param>
[CustomAction]
public static ActionResult RegisterRestartFiles(Session session)
{
// Konstante
const string tableName = "RestartManagerFiles";
const string columnName = "Path";
const string query = "SELECT Path FROM RestartManagerFiles";
try
{
// SessionKey des Neustart-Managers abrufen
string sessionKey = session["MsiRestartManagerSessionKey"];
if (!string.IsNullOrEmpty(sessionKey))
{
// Prfen ob die Tabelle vorhanden ist und ob die Spalte existiert
if (session.Database.IsColumnPersistent(tableName, columnName))
{
List<string> filePaths = new List<string>();
285
Kapitel 6
// Iteration durch alle Elemente. Hinzufgen der Dateipfade zu der Liste.
// Hierbei jedoch den Inhalt formatieren, falls Variablen in der Zeichenfolge
// verwendet wurden
foreach (string item in session.Database.ExecuteStringQuery(query))
{
string formattedPath = session.Format(item);
filePaths.Add(session.Format(item));
// Zum Protokoll hinzufgen
session.Log("File '{0}' registred for using with Restart Manager", formattedPath);
}
// Die Liste in ein Array umwandeln
string[] pathStrings = new string[filePaths.Count];
filePaths.CopyTo(pathStrings, 0);
// Dateien registrieren
CustomActions.RegisterFiles(sessionKey, pathStrings);
}
else
{
// Tabelle oder Spalte ist nicht vorhanden
session.Log("Table '{0}' or Column '{1}' is missing", tableName, columnName);
}
}
else
{
// Neustart-Manager ist nicht vorhanden
session.Log("Restart Manager is not available or disabled");
}
}
catch (Win32Exception ex)
{
session.Log("Win32Exception No: {0}, Description '{1}'", ex.ErrorCode, ex.Message);
}
{
session.Log("Exception '{1}'", ex.Message);
}
}
/// <summary>
/// Registrieren der Dateien
/// </summary>
/// <param name="sessionKey">Schlssel der Neustart-Manager Sitzung</param>
/// <param name="pathStrings">Array mit den Pfaden</param>
private static void RegisterFiles(string sessionKey, string[] pathStrings)
{
uint sessionHandle;
// Mit Session verbinden
286
int ret = CustomActions.RmJoinSession(out sessionHandle, sessionKey);

if (ret != 0)
throw new System.ComponentModel.Win32Exception(ret);
// Ressourcen registrieren
ret = CustomActions.RmRegisterResources(sessionHandle,
(uint)pathStrings.Length, pathStrings,
0, null, 0, null);
if (ret != 0)
throw new System.ComponentModel.Win32Exception(ret);
// Session beenden
CustomActions.RmEndSession(sessionHandle);
}
}
Listing 6.65: Benutzerdefinierte Aktion zum Registrieren zustzlicher Datei-Ressourcen
Was noch fehlt ist die Integration der benutzerdefinierten Aktion in das Installationspaket. Hierzu wird
zunchst die erzeugte physische Datei dem binren Datenspeicher des Paketes hinzugefgt.
Anschlieend wird die benutzerdefinierte Aktion in der Tabelle CustomAction definiert. Die
Ausfhrung erfolgt innerhalb der Tabelle InstallExecuteSeuquence, jedoch bevor die Aktion
InstallValidate ausgefhrt wird, wie auch Listing 6.66 zeigt.
<Binary Id="MyCustomAction.dll" SourceFile="$(var.RestartCA.TargetDir)$(var.RestartCA.TargetName).CA.dll" />
<CustomAction Id="RegisterRestartFiles" DllEntry="RegisterRestartFiles"
BinaryKey="MyCustomAction.dll" Execute="immediate" />

<Custom Action="RegisterRestartFiles" Before ="InstallValidate"></Custom>
Listing 6.66: Verwendenden der benutzerdefinierten Aktion zum Registrieren zustzlicher Ressourcen
In dem vorherigen Listing ist erkennbar, dass beim Hinzufgen der Datei zu dem binren
Datenspeicher keine absoluten Werte verwendet werden, sondern dass hier mit Variablen gearbeitet
wurde. Dieses ist mglich, da sowohl das Visual Studio-Projekt fr die benutzerdefinierte Aktion als
auch das Projekt zur Erzeugung des Installationspaketes einer Projektmappe (Solution) angehren und
die entsprechenden Referenzen definiert wurden. Den genauen Aufbau und die Verknpfungen zeigt
Abbildung 6.57.
287
Kapitel 6
Abbildung 6.57: Erstellen eines Installationspaketes mit Visual Studio
Die so erzeugte benutzerdefinierte Aktion stellt einen generischen Lsungsansatz dar, zustzliche
Datei-Ressourcen vom Neustart-Manager verwalten zulassen. Dieses ist wie gesagt nur ein sehr
einfacher Lsungsansatz, aber der Fantasie sind hierbei keine Grenzen gesetzt. Diese Mglichkeit ist
nicht nur auf Datei-Ressourcen beschrnkt, auch Anforderungen zum Beenden von Prozessen und
Diensten im Installationsprozess sind hiermit einfach umsetzbar.
Problemfall Benutzerkontensteuerung
Die Benutzerkontensteuerung wurde bereits in Kapitel 5 dieses Buches detailliert erlutert. Dennoch
darf bei einer Betrachtung des Neustart-Managers diese Funktionalitt nicht auer Acht gelassen
werden, denn mitunter kann das skizzierte Neustartverhalten hierdurch beeintrchtigt werden. Der
wesentliche Problemfaktor bei dieser Betrachtung betrifft die Trennung zwischen der Benutzer- und
der Service-Sitzung.
Bei einer normalen Installation wird der Benutzer beim Wechsel zum Server-Prozess aufgefordert,
die Verwendung erhhter Privilegien zu besttigen. Ist dieses erfolgt, wird die eigentliche Installation,
also die physische Vernderung des Systems, mit den Privilegien des lokalen Systemkontos
ausgefhrt. Nun kommt an dieser Stelle der Neustart-Manager ins Spiel. Er identifiziert zunchst die
Prozesse, die derzeitig Dateien verwenden, die im Rahmen der Installation modifiziert oder entfernt
werden mssen. An spterer Stelle versucht er zustzlich, die betroffenen Prozesse zu beenden und
nach der Installation neu zu starten. Werden hierbei privilegierte Prozesse identifiziert, die in der
gleichen Windows-Sitzung ausgefhrt werden, wie der Windows Installer-Service selbst, so knnen
288
diese problemlos beendet werden. Wird hingegen ein privilegierter Prozess in der Windows-Sitzung
des Benutzers ausgefhrt, so kann dieser Prozess nicht beendet werden. Die Begrndung wurde bereits
in diesem Kapitel geliefert. Zur Identifizierung von Prozessen die in der Benutzer-Sitzung ausgefhrt
werden, wird vom Client-Prozess eine eigene Neustart-Manger-Sitzung erzeugt. Da der Client-Prozess
lediglich mit Standardbenutzer-Privilegien ausgefhrt wird, kann der Neustart-Manager ebenfalls nur
diese Privilegien fr die weiteren Aktivitten verwenden. Ist nun ein Prozess der Benutzer-Sitzung
betroffen, der privilegiert ausgefhrt wird, so kann dieser durch den nicht privilegierten NeustartManager auch nicht beendet werden. Whrend der Installation wird dem Benutzer die Meldung 1611
angezeigt, womit er auf einen erforderlichen Neustart des Computers hingewiesen wird. Diese
Informationen befinden sich natrlich auch im Installationsprotokoll.
MSI (s) (EC:14) [17:00:15:878]: RESTART MANAGER: Detected that application with id 2932,
friendly name 'NonAdmin', of type RmUnknownApp and status 1 holds file[s] in use.
MSI (c) (64:88) [17:00:15:941]: RESTART MANAGER: Session opened.

MSI (c) (64:88) [17:00:15:941]: RESTART MANAGER: Detected that application with id 2932,
friendly name 'NonAdmin.exe', of type RmCritical and status 1 holds file[s] in use.
Action 17:00:22: ShutdownApplications. Shutting down applications
MSI (s) (EC:14) [17:00:22:602]: Note: 1: 1611 2: The setup was unable to automatically close all
requested applications. Please ensure that the applications holding files in use are closed before
continuing with the installation.
MSI (s) (EC:14) [17:00:30:244]: RESTART MANAGER: The user chose to go on with the installation,
although a reboot will be required.
Die Ursache fr dieses Verhalten liegt im Sicherheitskonzept von Windows Vista und Windows Server
2008, da es nicht gestattet ist, Anmeldeinformationen (Credentials) eines privilegierten Prozesses an
einen nicht vertrauenswrdigen Client zu bermitteln. An diesem Thema wird weiterhin gearbeitet. So
ist die Bestrebung in einer zuknftigen Windows-Version, das beenden oder herunterfahren von
Prozessen ber Sitzungen hinweg zu ermglichen.
Ein etwas abweichenderes Thema in Verbindung mit der Benutzerkontensteuerung bezieht sich auf die
Anwendung von Windows Installer-Patches, die digital signiert wurden, also um die sogenannten
LUA-Patches. Der Vorteil dieser Patches liegt darin begrndet, dass bei der Anwendung auf ein
installiertes Produkt, die Verwendung erhhter Privilegien nicht explizit besttigt werden muss. Ein
problematischer Nebeneffekt, ergibt sich nun in Kombination mit den Betriebssystemdiensten und dem
Neustart-Manager. Der Server-Prozess kann in einem solchen Fall nur Betriebssystemdienste beenden
und neu starten die unter Verwendung der Tabellen ServiceInstall und ServiceControl konfiguriert
wurden. Ist es erforderlich einen Betriebssystemdienst zu beenden, der nicht Bestandteil des
Installationspaketes ist, so fehlen die erforderlichen Rechte und der Vorgang wrde fehlschlagen. In
einem solchen Fall wird dies vom Neustart-Manager festgestellt und der Benutzer ber diesen
Sachverhalt informiert. Weiterhin wird dem Benutzer mitgeteilt, dass ein Neustart des Computers
erforderlich ist, wie auch das Protokoll zeigt.
MSI (s) (70:4C) [18:26:21:148]: RESTART MANAGER: Detected that application with id 1304,
friendly name 'Restart Service', service short name 'Service1', of type RmCritical and
MSI (s) (70:4C) [18:26:21:148]: RESTART MANAGER: Did detect that a critical application holds
file[s] in use, so a reboot will be necessary.
Es ist erkennbar, dass die Kombination mit der Benutzerkontensteuerung durchaus zu Problemen
289
Kapitel 6
fhren kann, so dass hier auf Computerneustarts nicht verzichtet werden kann. Es sei jedoch
anzumerken, dass sowohl der Neustart-Manager als auch die Benutzerkontensteuerung sehr neue
Technologien sind, und das jede Technologie auch ber Kinderkrankheiten verfgt. Es bleibt zu
hoffen, dass diese Probleme in zuknftigen Versionen adressiert werden.
Bootstrapper
Wie bereits angedeutet, enthlt erst der Windows Installer 4.5 eine Implementierung durch die es
mglich wird, mehrere Installationspakete zusammenhngend zu installieren. Die frheren Versionen
des Installers verfgten ber einen solchen Mechanismus nicht. Zur Umsetzung solcher oder hnlich
gelagerter Szenarien wurde ein sogenannter Bootstrapper verwendet. Hierunter ist eine externe
Anwendung zu verstehen, die die Steuerung des Installationsprozesses vornimmt. Ein wesentlicher
Punkt, den diese Anwendung abdecken muss, ist die Prfung auf noch ausstehende Computerneustarts.
Zu Beginn dieses Kapitels wurde die Gefahrenquelle der nicht durchgefhrten Neustarts erlutert, so
dass die Notwendigkeit durchaus bewusst sein sollte. Im Rahmen der Neustart-Prfung und der
effektiven Vermeidung ist es mitunter auch gefordert, eine frhzeitige oder dynamische Prfung auf
verwendete Dateien zu integrieren. Bei einer solchen Umsetzung helfen der Neustart-Manager und
natrlich auch der Windows Installer weiter. Der Bootstrapper fungiert hierbei als primrer Installer.
Zur Vermeidung doppelter Aktivitten, sollte in einem solchen Szenario der Neustart-Manger fr den
Windows Installer deaktiviert werden, indem die Eigenschaft MSIRESTARTMANAGERCONTROL
entsprechend zu verwenden ist. Die Implementierung innerhalb des Bootstrappers zur Verwendung des
Neustart-Managers gestaltet sich durch die folgenden Aktivitten und Vorgehensweisen:
Der Bootstrapper erzeugt eine Neustart-Manager-Sitzung, indem RMStartSession() aufgerufen
wird. Er erhlt daraufhin das Sitzungs-Handle und einen Sitzungs-Schlssel.
Im nchsten Schritt werde die zu berwachenden Ressourcen mit RmRegisterResources()
registriert. Der Neustart-Manager kann nur fr die registrierten Ressourcen ermitteln, welche
Prozesse diese derzeitig verwenden und heruntergefahren werden mssen.
Durch den Aufruf von RMGetList() werden letztlich die Prozesse ermittelt, die Dateien in
Verwendung halten. Zustzlich wird durch den Parameter pbRebootNeeded ber einen mglichen
Neustart informiert. Wird hier True zurckgegeben, so knnen nicht alle Prozesse beendet werden,
so dass ein Computerneustart erforderlich ist. Falls hier jedoch False zurckgegeben wird, kann
nun durch den Bootstrapper das Herunterfahren und Neustarten der Prozesse veranlasst werden,
indem RmShutDown() und RmRestart() aufgerufen werden.
Der Bootstrapper kann weiterhin die Liste der Prozesse, die heruntergefahren und neu gestartet
werden sollen modifizieren. Durch die Funktion RmAddFilter() knnen Prozesse von diesen
Aktivitten ausgeschlossen werden. Die Funktion RmGetFilterList() gibt die Liste der Filter zurck
und durch die Funktion RmRemoveFilter() knnen letztlich definierte Filter wieder von der Liste
entfernt werden.
Der Bootstrapper ruft schlielich RmEndSession() auf um somit die Neustart-Manager-Sitzung zu
beenden.
Der wahrscheinlich komplizierteste Punkt in diesem Szenario liegt in der Ermittlung der zu
installierenden Dateien durch den Bootstrapper. Werden durch den Bootstrapper nur Windows
Installer-Pakete installiert, ist dieses nicht ganz so schwierig. Durch den Einsatz eines Bootstrappers
wird ja die Auswahl der Installationsoptionen vorgegeben, so dass der Benutzer wenig oder gar keinen
Einfluss auf den Umfang der Installation hat. Somit knnte an dieser Stelle eine statische Liste
290
verwendet werden, in der die von der Installation betroffenen Dateien aufgefhrt werde. Es ist
natrlich auch mglich, ber die Windows Installer-Programmierschnittstelle auf die Datenbank der
Installationspakete zuzugreifen und die zu installierenden Dateien anhand der Tabellen File,
Component und Directory zu ermitteln. Wie gesagt, diese Vorgehensweisen sind nicht sonderlich
kompliziert.
Bei der Installation eines oder mehrerer Patches gestaltet sich dieses ungleich schwieriger. Denn zum
Einen ist hier die Anwendungsreihenfolge der Patches zu beachten und zum anderen muss auch der
Status und die Gltigkeit der Patches mit einbezogen werden. Der Windows Installer enthlt seit der
Version 4.0 eine neue Funktion, mit der die betroffenen Dateien beim Einspielen von Patches ermittelt
werden knnen. Der Funktion MsiGetPatchFileList() werden hierzu eine Liste von Patches und die
Referenz auf das Zielprodukt bergeben. Das Ergebnis ist die Liste der betroffenen Dateien. Unter
Verwendung der Deployment Tools Foundation existiert die Funktion GetPatchFileList() in der Klasse
Installer des Namensraums Microsoft.Deployment.WindowsInstaller. Dieser Funktion ist der
ProductCode des Produktes zu bergeben, auf das der oder die Patches angewendet werden sollen. Im
Weiteren sind der Funktion die zu berprfenden Patches zu bergeben. Das Ergebnis ist eine Liste
vom Typ IList<string>, der die absoluten Pfade zu den Dateien angefgt wurden, die von den Patches
betroffen sind. Durch Verwendung dieser Funktion wird es relativ einfach einen generischen
Bootstrapper zu entwickeln, der nicht nur Installationspakete, sondern auch Patches bercksichtigt. Die
Notwendigkeit eines solchen Bootstrappers gilt es natrlich zu prfen, da der Windows Installer 4.5
diesbezgliche Funktionalitt bereitstellt, wie spter noch zu sehen ist.
Fazit
Die Ausfhrungen dieses Kapitels sollten zu einer Sensibilisierung fr das Thema der
Computerneustarts fhren. Ein Computerneustart ist immer strend und eine Vermeidung ist immer
anzustreben. Dennoch sollte die Stabilitt des Systems und der Anwendung im Mittelpunkt stehen, so
dass eine Vermeidung von Neustarts nicht auf deren Unterdrckung abzielen sollte. Effektiver ist es
die potentiellen Ursachen fr einen Neustart frhzeitig zu erkennen und diese Klippen zu umschiffen.
Ein wirkungsvolles Hilfsmittel hierfr ist der Neustart-Manager, der mit Windows Vista und Windows
Server 2008 bereitgestellt wird. Wird der Windows Installer in der Version 4.0 und hher unter diesen
Betriebssystemen ausgefhrt, wird der Neustart-Manager zur Identifizierung bereits verwendeter
Dateien und zustzlicher Aktivitten verwendet. Hierbei werden auch unterschiedliche
Anwendungsszenarien und Benutzerprofile bercksichtigt. Ein Endbenutzer fhrt die Installation
berwiegend unter Verwendung der vollstndigen Benutzeroberflche durch. In einem solchen Fall
steht dem Benutzer nur die vollstndige Funktionalitt des Neustart-Managers zur Verfgung, wenn
der Dialog MsiRMFilesInUse im Installationspaket vorhanden ist. Dieses gilt natrlich auch, wenn der
Dialog in einer Windows Installer-Transformation bereitgestellt wird, die auf die Datenbank des
entsprechenden Paketes angewendet wird. Ist dieser Dialog nicht vorhanden, wird der Standarddialog
FilesInUse zur Prsentation der Prozesse verwenden. Der Neustart-Manager wird hierbei zur
Identifizierung der jeweiligen Prozesse, jedoch nicht zum beenden dieser Prozesse verwendet. Im
Unternehmensumfeld sieht dieses jedoch etwas anders aus, denn hier werden unterschiedliche
Darstellungsformen angewendet. Wird eine Installation unter Verwendung der Basis-Oberflche
durchgefhrt, so erhlt der Benutzer auch die Option zur Vermeidung eines Computerneustarts wenn
der Dialog MsiRMFilesInUse nicht im Paket vorhanden ist. In diesem Szenario wird der als Ressource
integrierte Dialog IDD_RMFILESINUSE verwendet. Wird die Installation im unbeaufsichtigten Modus
291
Kapitel 6
durchgefhrt, wird der Neustart-Manger verwendet um einen Computerneustart zu vermeiden. Das

bedeutet, dass in einem solchen Fall die betroffenen Prozesse automatisch beendet und wenn mglich
wieder neu gestartet werden. Auch im Rahmen der Deinstallation eines Produktes wird der NeustartManager verwendet, wobei die gleichen Kriterien gelten, wie bei der Installation. Wird die
Deinstallation ber den Dialog Software der Systemsteuerung durchgefhrt, wird immer die BasisOberflche verwendet, wodurch der Benutzer die Option zur Vermeidung eines Computerneustarts
erhlt.
292
Sicherheit, Sprachen und

Troubleshooting
Fazit
293
298
307
318
Die Benutzerkontensteuerung und der Neustart-Manager sind nur einige der vielen Neuerungen in
Windows Vista und Windows Server 2008. Der Neustart-Manager ermglicht ein effektiveres
Arbeiten, da hierdurch die Ausfallzeiten reduziert werden knnen, die durch Computerneustarts
verursacht werden. Im Weiteren trgt der Neustart-Manager auch zur Anwendungsstabilitt bei, da
problematischen Verhaltensweisen im Rahmen der Computerneustarts verringert oder sogar vermieden
werden knnen. Die Benutzerkontensteuerung ist im sicherheitsrelevanten Bereich anzusiedeln und
trgt somit auch zur Effizienzsteigerung bei. Hierdurch werden die Schdigungen durch bsartige
Software reduziert, wodurch zwangslufig die Systemausfallzeiten reduziert werden. Wie bereits in
den vorherigen Kapiteln erlutert, wirken sich diese Technologien direkt auf den Installationsprozess
aus, so dass beim Design des Installationspakets entsprechende Faktoren zu bercksichtigen sind.
Windows Vista und Windows Server 2008 enthalten eine weitere sicherheitsrelevante
Implementierung, die im Rahmen der Installation zu beachten ist und als Windows-Ressourcenschutz
bezeichnet wird.
In den Betriebssystemen Windows 2000, Windows XP und Windows Server 2003 ist ein
Mechanismus enthalten, der als Windows-Dateischutz (Windows File Protection) bezeichnet wird.
Hierdurch wird sichergestellt, dass fr das Betriebssystem relevante Dateien nicht ersetzt oder entfernt
werden knnen. Zur Realisierung wird ein Betriebssystemdienst verwendet, der entsprechende Lschoder Kopiervorgnge berwacht und bei Bedarf die Datei wieder herstellt. Problempunkte ergeben sich
bei einer Mengenoperation, also dem Lschen einer Vielzahl von Dateien. Hierbei stt der Dienst an
seine Grenzen und die Dateien knnen nicht wieder hergestellt werden. Weiterhin ist das entfernen
oder austauschen von geschtzten Dateien problemlos mglich, wenn der berwachungsmechanismus
nicht aktiv ist. Dieses ist beispielsweise der Fall, wenn das System im abgesicherten Modus gestartet
wurde.
293
Kapitel 7
Sicherheit, Sprachen und Troubleshooting
Funktionsweise
Windows Vista und Windows Server 2008 enthalten einen neuen Schutzmechanismus, der als
Windows-Ressourcenschutz (Windows Ressource Protection) bezeichnet wird. Hierbei handelt es sich
um die konsequente Weiterentwicklung des Windows-Dateischutzes. Wie die Bezeichnung bereits
vermuten lsst, erstreckt sich dieser Schutzmechanismus nicht mehr nur auf Dateien, sondern schliet
auch andere Ressourcentypen mit ein. Darber hinaus wurde die Implementierung in der Form
gendert, dass auf den berwachungs-Dienst gnzlich verzichtet wurde. Die neue Implementierung
lsst ein austauschen oder entfernen der geschtzten Ressource erst gar nicht zu, was natrlich den
wesentlich sichereren und effektiveren Ansatz darstellt. Der Versuch eine Datei oder einen Schlssel
der Registrierung zu lschen wird mit den in Abbildung 7.58 dargestellten Fehlermeldungen
abgebrochen.
Abbildung 7.58: Windows-Ressourcenschutz verhindert das Lschen einer Ressource
Die Realsierung dieser Absicherung erfolgt unter Verwendung spezieller Zugriffskontrolllisten, wie
dieses auch Abbildung 7.59 gezeigt wird. Es wird deutlich, dass nur die als TrustedInstaller
bezeichnete Benutzergruppe ber den Vollzugriff verfgt und die Datei somit ersetzen oder entfernen
knnte. Alle anderen Konten verfgen nur ber eingeschrnkte Rechte, so dass es auch dem
Systemadministrator nicht gestattet ist, die Datei zu modifizieren. Eine identische Form der
Absicherung gilt ebenfalls fr bestimmte Teile der Systemregistrierung. Dieser Schutzmechanismus
hat natrlich nicht nur die Aufgabe, das versehentliche Entfernen oder Modifizieren einer Ressource zu
verhindern. Hierdurch werden natrlich auch Viren oder andere bsartige Implementierungen daran
gehindert, sich durch das berschreiben von Systemdateien im System einzunisten.
294
Abbildung 7.59: Absicherung einer Datei durch den Windows-Ressourcenschutz
Es ist natrlich weiterhin erforderlich, geschtzte Systemressourcen gegen neuere Versionen

auszutauschen. Wie bereits angedeutet, verfgt lediglich die Benutzergruppe des TrustedInstallers
ber den erforderlichen Vollzugriff, so dass eine solche Aktion mit deren Privilegien ausgefhrt
werden muss. Technisch betrachtet wird hierzu ein Betriebssystemdienst verwendet, der als WindowsModulinstallation bezeichnet ist. Die Aufgabe dieses Dienstes liegt in der berprfung des zu
verwendenden Installationspaketes. Wird festgestellt, dass es sich um ein autorisiertes
Installationspaket handelt, wird die Installation durchgefhrt, falls sie durch folgende Mechanismen
veranlasst wurde:
Windows Service Packs
Hotfixes
Betriebssystemupdates
Windows Update
An dieser Stelle wird der Unterschied zum Windows-Dateischutz besonders deutlich. Wird hierbei der
berwachungsmechanismus deaktiviert, lassen sich Dateien problemlos manipulieren. Wird im neuen
Modell hingegen der Betriebssystemdienst Windows-Modulinstallation deaktiviert, lassen sich keine
Aktualisierungen mehr durchfhren. Somit kann auch in einem solchen Szenario die Sicherheit und
Stabilitt des Betriebssystems nicht negativ beeinflusst werden.
Programmtechnischer Zugriff
Trotz der massiven nderungen in dem Schutzmechanismus sind existierende Anwendungen und
295
Kapitel 7
Installationsprogramme weitestgehend kompatibel mit der neuen Implementierung. Das ist darauf
zurck zu fhren, dass die Programmierschnittstelle weiterhin die erforderlichen Funktionen zum
Prfen auf eine geschtzte Ressource zur Verfgung stellt und diese lediglich ergnzt. Allerdings
verhalten sich die Funktionen SfcGetFiles() und SfcGetNextProtectedFile() unter Windows Vista und
Windows Server 2008 abweichend. Das ist darauf zurckzufhren, dass der bisherige WindowsDateischutz einen Katalog verwendete, in dem alle geschtzten Dateien enthalten waren. Durch diese
Funktionen wurde auf den Katalog zugegriffen und die entsprechenden Informationen wurden ermittelt
und zurck geliefert. Beim Windows-Ressourcenschutz wird hingegen kein diesbezglicher Katalog
mehr verwendet, so dass eine entsprechende Prfung nicht mglich ist. Die erforderlichen
Informationen sind Bestandteil der Ressourcen, so dass eine berprfung immer auf Ebene der
Ressource erfolgen muss. Die dazu erforderlichen Funktionen sind in Tabelle 7.60 aufgefhrt.
Funktion
Beschreibung
Betriebssystem
SfcGetNextProtectedFile() und
SfcGetFiles()
Ermittelt
alle
geschtzten
Dateien auf dem System.
Windows XP, Windows Server

2003, Windows Vista und
Windows Server 2008.
Unter Windows Vista und
Windows Server 2008 werden
diese
Funktionen
nicht
untersttzt und geben immer
False zurck.
SfcIsFileProtected()
Prft ob eine bestimmte Datei

geschtzt ist.
Windows XP, Windows Server

2003, Windows Vista und
SfcIsKeyProtected()
Prft ob ein bestimmter

Schlssel
der
Systemregistrierung geschtzt
ist.
Windows Vista und Windows

Server 2008.
Tabelle 7.60: Funktionen des Windows-Ressourcenschutzes
Mit Hilfe der Funktion SfcIsFileProtected() kann geprft werden, ob eine Datei unter dem WindowsRessourcenschutz steht. Dem Funktionsaufruf ist der vollstndige Pfad zu der Datei zu bergeben, wie
dieses auch Listing 7.67 zeigt. Durch die Funktion kann relativ einfach ermittelt werden, welche
Dateien dem Windows-Ressourcenschutz unterliegen, indem rekursiv alle Dateien des Systems geprft
werden.
[DllImport("sfc.dll", CharSet=CharSet.Auto )]
private static extern bool SfcIsFileProtected(
int RpcHandle,
[MarshalAs(UnmanagedType.LPWStr)]string ProtFileName);
// Prfen, ob die Datei dem Windows-Ressourcenschutz unterliegt
internal static bool IsFileProtected(string fileName)
{
return (SfcIsFileProtected(0, fileName));
}
Listing 7.67: Ermitteln ob eine Datei dem Windows-Ressourcenschutz unterliegt
296
Eine nahezu identische Implementierung ist fr die Ermittlung der geschtzten Registrierungsschlssel
erforderlich. Hierfr steht die Funktion SfcIsKeyProtected() zur Verfgung, der letztlich der zu
prfende Schlssel zu bergeben ist. Wie in Listing 7.68 zu erkennen ist, kann der Bit-SpezifischeBereich der Registrierung explizit festgelegt werden. Standardmig wird von 32-Bit-Anwendungen
auf den 32-Bit-Bereich der Systemregistrierung zugegriffen und von 64-Bit-Anwendungen natrlich
auf den 64-Bit-Bereich. Allerdings kann der Funktionsaufruf so gestaltet werden, dass eine 64-BitAnwendung auch den 32-Bit-Bereich der Registrierung verwendet und umgekehrt.
[DllImport("sfc.dll", CharSet = CharSet.Auto)]
private static extern bool SfcIsKeyProtected(
int hKey, [MarshalAs(UnmanagedType.LPWStr)]
string lpSubKey,
int samDesired);
// Zugriffsoptionen
internal enum RegistryPart
{
Default = 0x0,
// Verwendet den 32-Bit-Bereich bei 32-Bit-Anwendungen
und den 64-Bit-Bereich bei 64-Bit-Anwendungen
Key64Bit = 0x100, // Verwendet den 64-Bit-Schlssel von einer 32- oder 64-Bit-Anwendung
Key32Bit = 0x200 // Verwendet den 32-Bit-Schlssel von einer 32- oder 64-Bit-Anwendung
}
// Prfen, ob der Registrierungsschlssel dem Windows-Ressourcenschutz unterliegt
internal static bool IsKeyProtected(RegistryHive rootKey, string subKey, RegistryPart part)
{
return (SfcIsKeyProtected((int)rootKey, subKey, (int)part));
}
Listing 7.68: Ermitteln ob ein Registrierungsschlssel dem Windows-Ressourcenschutz unterliegt
Die Ermittlung der geschtzten Ressourcen kann im Rahmen einer eventuell beabsichtigten LogoZertifizierung uerst relevant werden. Eine diesbezgliche Richtlinie besagt, dass ein
Installationspaket nicht versuchen darf eine Ressource zu ersetzen, die durch den WindowsRessourcenschutz abgesichert ist.
Installation
Fr die Anwendungsinstallation mit dem Windows Installer bedeutet dies, dass keine Ressourcen
installiert werden knnen, die dem Windows-Ressourcenschutz unterliegen. Sollte whrend des
Installationsprozesses trotzdem versucht werden, eine so geschtzte Ressource zu berschreiben, wird
diese Aktion bersprungen und der Installationsprozess fortgesetzt. Dem Installationsprotokoll wird
eine Warnung angefgt.
MSI (s) (34:60) [17:21:21:077]: Product: Notepad. The application tried to install a more recent version of
the protected Windows file C:\Windows\system32\Notepad.exe. You may need to update your operating system
for this application to work correctly. (Package Version: 7.0.7001.18000,
Operating System Protected Version: 6.0.6001.18000).
Dieses Verhalten weicht sehr stark von dem bisherigen Verhaltensmuster beim Windows-Dateischutz
ab. Wurde hierbei versucht, eine geschtzte Datei zu berschreiben, wurde die Installation mit dem
Fehler 1931 beendet, wie auch der nachfolgende Auszug des Installationsprotokolls zeigt.
MSI (s) (30:34) [10:39:43:207]: Product: Notepad -- Error 1931. The Windows Installer service cannot update
the system file C:\WINDOWS\system32\Notepad.exe because the file is protected by Windows. You may need to
297
Kapitel 7
update your operating system for this program to work correctly. Package version: 7.0.7001.18000,
OS Protected version: 5.1.2600.2180
Auch wenn der Windows Installer nicht in der Lage ist, geschtzte Systemdateien zu ersetzen, sollten
die Installationspakete diesbezglich analysiert und korrigiert werden. Wie bereits zuvor angedeutet,
wird ein Installationspaket die Zertifizierungsrichtlinien nicht bestehen, falls es versucht, geschtzte
Systemressourcen zu ersetzen.
An vielen Stellen dieses Buches wurde bereits das Installationsprotokoll erwhnt und auf spezifische
Eintragungen hingewiesen. Allerdings erfolgte noch keine ausfhrliche Betrachtung des
Protokollierungsmechanismus im Rahmen der Installation. Der Windows Installer 4.0 stellt hierfr
einige neue Funktionalitten bereit, so dass die Gesamtbetrachtung an dieser Stelle folgt. Das
Windows Installer-Protokoll dient der Aufzeichnung der Ablufe im Installationsprozess und hilft
somit bei der Erstellung einer exakten Fehleranalyse. Der Inhalt des Installationsprotokolls kann durch
den Protokollierungsmodus individuell festgelegt werden. Nachdem die Protokolldatei erstellt wurde,
kann sie mit relativ einfachen Mitteln ausgewertet werden. Die Protokollierung und den Umfang der
Informationen kann auf mehrere Arten bestimmt werden:
Durch Verwenden der Befehlszeilenoptionen /log oder /l von msiexec.exe.
Durch Systemrichtlinie Logging.
Durch die Funktion MsiEnableLog() oder die Methode Installer.EnableLog().
Durch die neue Eigenschaft MsiLogging des Windows Installer 4.x.
Zur Erstellung eines Protokolls ist der Umfang der zu protokollierenden Aktivitten anzugeben, indem
entsprechende Protokollargumente zu verwenden sind. Bei diesen Protokollargumenten handelt es sich
um eine Verkettung von einzelnen Zeichen, die letztlich den Umfang des Installationsprotokolls
definieren. Tabelle 7.61 stellt die einzelnen Elemente dar, die zur Definition der Protokollargumente
verwendet werden knnen. Um smtliche Aktivitten im Installationsprozess zu protokollieren, sollte
als Wert icewarmupvxo verwendet werden.
Argument
Beschreibung
Statusmeldungen (Informational status messages)
Warnungen (Nonfatal warnings)
Alle Fehlermeldungen (All error messages)
Beginn von Aktionen (Action activity)
Aktionsspezifische Daten (Record data for active action)
Anfragen an den Benutzer (User requests)
Initialisierungswerte der UI-Argumente (Initial client UI parameters)
Meldungen wegen unzureichendem Speicher und fatale Fehlermeldungen (Out-of-memory or

fatal exit information)
Meldungen wegen unzureichender Datentrgerkapazitt (Out-of-disk-space messages)
298
Eigenschaften (Properties)
Detaillierte Informationen (Additional verbose output)
Zustzliche Debugging-Informationen (Extra debugging information)
Direktes Schreiben jeder Protokollzeile
Tabelle 7.61: Argumente zum Festlegen der Protokollierung
Bei der Erstellung des Protokolls unter Verwendung der Befehlszeilenoptionen oder durch die
programmtechnischen Implementierungen muss der Zielort der Protokolldatei angegeben werden. Bei
den anderen Mglichkeiten wird eine Protokolldatei mit der Bezeichnung msi?????.log im Ordner
fr temporre Daten erzeugt, wobei die Fragezeichen durch einen Zufallszahl ersetzt werden.
Protokollierung aus dem Paket

Durch die neue Eigenschaft MsiLogging wird es mglich, die Erstellung eines Installationsprotokolls
bereits beim Design des Installationspaketes zu veranlassen. Hierzu ist es erforderlich diese
Eigenschaft der Tabelle Property hinzuzufgen und den entsprechenden Protokollierungsmodus zu
definieren. Es ist ebenfalls mglich, die Eigenschaft in einer Windows Installer-Transformation
festzulegen. Dieses ist mglich, da die Transformation vor der erforderlichen Initialisierung
angewendet wird. Es ist jedoch nicht mglich, die Eigenschaft in einem Windows Installer-Patch zu
definieren, da zum Zeitpunkt der Anwendung des Patches, die Protokollierung bereits gestartet wurde.
Unabhngig von der Art der Aktivierung wird bei der spteren Installation ein Installationsprotokoll
mit den definierten Inhalten erstellt und im Ordner %temp% unter einem zufllig generierten
Dateienamen abgelegt. Der vollstndige Pfad zu dieser Datei wird der weiteren neuen Eigenschaft
MsiLogFileLocation angefgt, so hierdurch viele Anwendungsszenarien mglich werden. Der Inhalt
der Eigenschaft MsiLogFileLocation kann beispielsweise im Rahmen des Installationsprozesses in der
Systemregistrierung abgelegt werden. Hierdurch kann zu einem spteren Zeitpunkt das
Installationsprotokoll jederzeit identifiziert und darauf zugegriffen werden. Alternativ besteht natrlich
auch die Mglichkeit, das Protokoll nach Abschluss der Installation anzeigen zu lassen. Hierbei kann
die Anzeige von einer Bedingung abhngig gemacht werden, so dass der Benutzer in einem Dialog
diesem erst zustimmen muss, wie es auch Abbildung 7.60 aufzeigt.
299
Kapitel 7
Abbildung 7.60: Protokoll nach Abschluss der Installation anzeigen
Die skizzierte Mglichkeit lsst sich auch mit den vorgefertigten Dialogen von Windows InstallerXML sehr einfach umsetzen. Es ist zunchst erforderlich, das auf dem letzten Dialog bereits
vorhandene
Kontrollkstchen
zu
aktivieren.
Hierzu
ist
der
Eigenschaft
WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT die Beschreibung zuzuweisen, die auf dem
Dialog erscheinen soll. Weiterhin muss natrlich noch eine benutzerdefinierte Aktion erzeugt werden,
die letztlich fr die Anzeige des Protokolls sorgt. Die benutzerdefinierte Aktion wird durch Aktivieren
einer Schaltflche ausgefhrt, falls das Kontrollkstchen aktiviert wurde und die Eigenschaft
MsiLogFileLocation ber einen Wert verfgt. Die relevanten Codezeilen sind in Listing 7.69
aufgefhrt.

<Property Id="MsiLogging" Value="icewarmupvxo" />
<Property Id="WIXUI_INSTALLDIR" Value="APPLICATIONFOLDER" />
<Property Id="WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT" Value="Installationsprotokoll anzeigen" />

<UI>
<Publish Dialog="ExitDialog" Control="Finish" Event="DoAction"
Value="ShowTheLog">WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 AND MsiLogFileLocation</Publish>
</UI>

<Property Id="Notepad" Value="notepad.exe"/>
<CustomAction Id="ShowTheLog" Return="asyncNoWait" Property="Notepad" ExeCommand="[MsiLogFileLocation]" />
Listing 7.69: Definition eines Dialogs zur Anzeige des Installationsprotokolls
Wie gerade dargestellt wird der Eigenschaft MsiLogFileLocation der vollstndige Pfad zu dem
erzeugten Installationsprotokoll vom Windows Installer automatisch angefgt. Hierbei ist es
unerheblich auf welche Weise die Erstellung des Protokolls veranlasst wurde. Hieraus folgt, dass
300
immer wenn ein Protokoll erzeugt wird, die Eigenschaft MsiLogFileLocation eine Referenz darauf
enthlt.
Es besteht natrlich die Mglichkeit, mehrere Optionen zur Erzeugung eines Installationsprotokolls
gleichzeitig zu verwenden. Hierbei ist zu beachten, dass immer nur ein Protokoll erzeugt wird. Die
Optionen zur Protokollerstellung werden in der nachfolgend aufgefhrten Reihenfolge geprft. Die
erste zutreffende Option gewinnt und die nachfolgenden Optionen werden ignoriert. Ist keine Option
zutreffenden, wird auch kein Protokoll erzeugt.
6. Verwenden der Befehlszeilenoptionen /log oder /l zur Definition des Protokollumfangs, oder
verwenden der programmtechnischen Mglichkeiten.
7. Definition des Protokollumfangs durch die Eigenschaft MsiLogging.
8. Definition des Protokollumfangs durch die Systemrichtlinie.
Die Erstellung eines Protokolls durch die Verwendung der Eigenschaft MsiLogging kann systemweit
deaktiviert werden. Hierzu ist die Systemrichtlinie DisableLoggingFromPackage auf 1 zu setzen,
Informationen im Protokoll
Der Umfang des Installationsprotokolls ist natrlich vom gewhlten Protokollierungsmodus abhngig.
Zur detaillierten Fehleranalyse ist in den meisten Fllen ein vollstndiges Protokoll erforderlich. Unter
Verwendung der Systemrichtlinie oder der Eigenschaft MsiLogging kann ein solches Protokoll durch
Zuordnung der Zeichenfolge icewarmupvo erstellt werden. Erfolgt die Aktivierung ber die
Befehlszeile, so kann diese Zeichenfolge dem Argument /l angefgt werden. Alternativ kann auch
der Platzhalter verwendet werden, so dass das Argument /l*v synonym zu verwenden ist. Bei dem
gerade dargestellten Protokollmodus wurde auf die Ausgabe zustzlicher Debugging-Informationen
verzichtet, da die Vielzahl dieser Informationen nicht gerade zur bersichtlichkeit beitrgt. Allerdings
existieren durchaus Anwendungsflle in denen diese Informationen sehr hilfreich sind, wie
beispielsweise bei der Verwendung von Windows Installer-Patches. Unabhngig ob die zustzlichen
Debugging-Informationen ausgegeben werden oder nicht, die nachfolgenden Angaben sind in einem
vollstndigen Protokoll enthalten.
Fehler die whrend der Installation auftreten, einschlielich aller Windows Installer-Meldungen die
einen Benutzerdialog erzeugen.
Standardaktionen und benutzerdefinierte Aktionen.
Ist ein Neustart des Systems erforderlich oder wurde er bereits durchgefhrt.
Abschlieende Werte der Windows Installer-Eigenschaften.
Die Position der Installationsquellen.
Wurde die Installation durch den Benutzer abgebrochen.
An welcher Stelle eine Installation fehlgeschlagen ist.
Ob eine fehlerhafte Installation zurckgesetzt (Rollback) wurde.
Wie bereits in Kapitel 1 verdeutlicht, wird die Installation durch zwei Prozesse realisiert. Das
Installationsprotokoll stellt die Informationen beider Prozesse dar. Eine Aktion, die innerhalb des
Client-Prozesses ausgefhrt wird, ist im Installationsprotokoll durch (c) gekennzeichnet.
MSI (c) (E0:2C) [17:26:22:777]: Machine policy value 'DisableUserInstalls' is 0
Eine Aktion des Server-Prozesses ist durch (s) gekennzeichnet.

301
Kapitel 7
MSI (s) (70:74) [17:26:25:701]: Machine policy value 'LimitSystemRestoreCheckpointing' is 1
Der generelle Aufbau einer Eintragung im Installationsprotokoll beginnt immer mit dem Prfix MSI,
der gefolgt wird von der Kennzeichnung des Prozesses (c) oder (s). Im Anschluss werden die
Identifikationsmerkmale des Prozesses und des Threads angefgt, von dem diese Eintragung erzeugt
wurde. Bei der Eintragung des Client-Prozesses aus dem Beispiel, reprsentiert E0 den Prozess und
2C den Thread. Hierbei ist allerdings zu beachten, dass nur die letzten beiden Stellen der IDs (Hex)
dargestellt werden. Im Folgenden wird fr jede Aktion ein Zeitstempel (TimeStamp) angefgt, der aus
den Elementen [Stunde:Minute:Sekunde:Ticks] zusammengesetzt ist. Der Doppelpunkt (:) trennt die
Metadaten von der eigentlichen Beschreibung der Aktion. Alle Werte die dem Doppelpunkt folgen,
beschreiben die durchgefhrte Aktion. Der Aufbau ist immer von der jeweiligen Aktion abhngig.
Die Protokollierung beginnt zunchst mit allgemeinen Informationen ber das Datum der Installation,
der Version des Windows Installers, eine Referenz auf das zu installierende Produkt und zustzliche
Argumente, die der Befehlszeile bergeben wurden.
=== Verbose logging started: 08.09.2008 17:26:22 Build type: SHIP UNICODE 4.05.6001.00
C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (E0:2C) [17:26:22:771]: Resetting cached policy values
MSI (c) (E0:2C) [17:26:22:771]: Machine policy value 'Debug' is 0
MSI (c) (E0:2C) [17:26:22:771]: ******* RunEngine:
******* Product: D:\Setup\Football.msi
******* Action:
******* CommandLine: TRANSFORMS="Goal01.mst" MSINEWINSTANCE=1
Calling process:
Dem Installationsprotokoll werden anschlieend die Aktionen des Client-Prozesses angefgt. Hierbei
handelt es sich hauptschlich um Informationen, die die Interaktion des Benutzers mit dem Windows
Installer beschreiben.
MSI (c) (E0:2C) [17:26:22:859]: PROPERTY CHANGE: Adding MsiLogFileLocation property.
Its value is 'D:\Setup\Football.msi.install.log'.
Nachdem die Benutzerinformationen gesammelt wurden, wird die Ausfhrung an den Server-Prozess
bergeben. Dieses wird durch folgende Zeile dargestellt:
MSI (c) (E0:2C) [17:26:25:664]: Switching to server: INSTALLLOCATION="C:\Program Files (x86)\Football 2008\"
TARGETDIR="F:\" CURRENTDIRECTORY="D:\Setup" CLIENTUILEVEL="0" CLIENTPROCESSID="480" USERNAME="Andreas
Kerl"
COMPANYNAME="Microsoft Deutschland GmbH" SOURCEDIR="D:\Setup\" ACTION="INSTALL" EXECUTEACTION="INSTALL"
ROOTDRIVE="F:\" INSTALLLEVEL="1" SECONDSEQUENCE="1" ADDLOCAL=Application
Der Wechsel zum Server-Prozess wird durch die Zeichenfolge Switching to server markiert. Dieser
Zeichenfolge werden alle ffentlichen Eigenschaften angefgt, die durch die Aktionen des ClientProzesses verndert wurden. Wird eine Installation mit erhhten Rechten durchgefhrt, werden nur die
als sicher erachteten ffentlichen Eigenschaften (SecureCustomProperties) bergeben. In dem ServerProzess werden die eigentlichen Installationsprozeduren, wie das Kopieren von Dateien und das
Schreiben von Eintrgen in die Systemregistrierung durchgefhrt. Als nchstes werden die
serverseitigen Initialisierungen angezeigt, bevor die eigentlichen Installationsaktionen ausgefhrt
werden. Der Aktion InstallValidate folgt ein Dump, in dem die bentigten Statusinformationen der
Features und Komponenten zusammengefasst werden.
MSI (s) (70:74) [17:26:25:782]: Doing action: InstallValidate.
302
MSI (s)
MSI (s)
MSI (s)
MSI (s)
MSI (s)
Local
(70:74)
(70:74)
(70:74)
(70:74)
(70:74)
[17:26:25:783]:
[17:26:25:783]:
[17:26:25:783]:
[17:26:25:783]:
[17:26:25:783]:
Feature: Application; Installed: Absent; Request: Local; Action: Local

Component: C__Football.exe; Installed: Absent; Request: Local; Action: Local
Component: C__English; Installed: Absent; Request: Local; Action: Local
Component: C__German; Installed: Absent; Request: Local; Action: Local
Component: __C__Football.exe65; Installed: Null; Request: Local; Action:
Hinweis Beginn
Bei der Komponente __C__Football.exe65 handelt es sich um ein temporres Element, dass zur
Berechnung des Speicherplatzes dient, wie dieses bereits in Kapitel 1 erlutert wurde.
Hinweis Ende
Die eigentlichen Installationsaktionen, wie das Kopieren von Dateien, werden immer durch mehrere
Eintrge dargestellt. Der Beginn der Skripterstellung ist durch die folgende Zeile dargestellt:
Action 17:26:25: GenerateScript. Generating script operations for action:
Im Anschluss werden fr jede Aktion, die im Rahmen der Skriptausfhrung verwendet werden soll,
entsprechende Eintragungen angefgt.
MSI (s) (70:74) [17:26:25:834]: Doing action: InstallFiles
Action start 17:26:25: InstallFiles.
Action ended 17:26:25: InstallFiles. Return value 1.
Wenn Aktionen ordnungsgem beendet wurden, wird fr diese Aktion der Wert 1 zurckgegeben.
In der folgenden Tabelle 7.62 sind die mglichen Rckgabewerte von Aktionen aufgefhrt.
Wert
Error Code
Beschreibung
Aktion kann nicht ausgefhrt werden.
ERROR_SUCCESS
Aktion wurde ordnungsgem ausgefhrt.
Benutzer hat die Installation abgebrochen.
Nicht reproduzierbarer Fehler.
ERROR_INSTALL_SUSPEND
Installation wurde vorbergehend angehalten und wird

spter fortgesetzt.
Tabelle 7.62: Rckgabewerte von Aktionen
Nachdem die Erstellung des Installationsskriptes abgeschlossen ist, wird das Ausfhrungsmodul
erzeugt und die Skriptausfhrung gestartet.
MSI (s) (70:74) [17:26:25:865]: Running Script: C:\Windows\Installer\MSIDBB2.tmp
Es werden nun die Aktionen des Installationsskriptes ausgefhrt. Das Ausfhren dieser
Operationsanweisungen ist im Installationsprotokoll durch die Zeichenfolge Executing op: markiert.
MSI (s) (70:74) [17:26:25:869]: Executing op: Header(Signature=1397708873,Version=405,Timestamp=958958413,
LangId=1033,Platform=0,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (70:74) [17:26:25:870]: Executing op: ProductInfo(
ProductKey={B97086E8-06AB-4A78-8069-5BB33E1564C3},ProductName=Football 2008,PackageName=Football.msi,
Language=1033,Version=16777216,Assignment=1,ObsoleteArg=0,ProductIcon=I__Football.exe,,
PackageCode={CF130E25-5FED-4143-9B70-AAA03811E73C},,,InstanceType=0,LUASetting=0,
303
Kapitel 7
Nachdem zunchst diese Informationen ausgewertet wurden, werden die Modifikationen am

Zielsystem durchgefhrt.
MSI (s) (70:74) [17:26:25:902]: Executing op: SetTargetFolder(Folder=C:\Program Files (x86)\Football 2008\)
MSI (s) (70:74) [17:26:25:902]: Executing op: SetSourceFolder(Folder=1\tx5eoa5j\|Football 2008\)
MSI (s) (70:74) [17:26:25:902]: Executing op: FileCopy(SourceName=Football.exe,SourceCabKey=F__Football.exe,
DestName=Football.exe,Attributes=512,FileSize=43520,PerTick=32768,,VerifyMedia=1,,,,,
CheckCRC=0,Version=1.0.0.0,Language=0,InstallMode=58982400,,,,,,,)
MSI (s) (70:74) [17:26:25:902]: File: C:\Program Files (x86)\Football 2008\Football.exe;
To be installed; Won't patch; No existing file
MSI (s) (70:74) [17:26:25:902]: Source for file 'F__Football.exe' is compressed
Die Skriptausfhrung wird mit der Operationsanweisung

Installationsprotokoll wie folgt dargestellt wird:
End abgeschlossen,
die
im
MSI (s) (70:74) [17:26:26:081]: Executing op:

End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=136512)
Dem Installationsprotokoll wird ein Dump aller Eigenschaften des Installationsprozesses angefgt.
Hierbei sind zunchst die Eigenschaften des Server-Prozesses und im Anschluss die Eigenschaften des
Client-Prozesses aufgefhrt. Die beschriebenen Darstellungsformen im Installationsprotokoll werden
in dieser Vollstndigkeit nur angezeigt, wenn die detaillierte Ausgabeform (Verbose) gewhlt wurde.
In Abbildung 7.61 werden der Aufbau und die Gliederung eines solchen Protokolls grafisch
dargestellt.
304
Abbildung 7.61: Schematischer Aufbau des Installationsprotokolls.
Strategien fr die Fehlersuche

Die Fehlersuche ist ein uerst komplexer Prozess, der eine groe Erfahrung und die hierfr
notwendigen Detailkenntnisse voraussetzt. Der Windows Installer informiert durch geeignete
Manahmen ber das Auftreten eines Fehlers. Wird eine Installation mit einer Benutzeroberflche
ausgefhrt und tritt whrend des Installationsprozesses ein Fehler auf, wird eine Fehlermeldung
angezeigt. Wurde die Protokollierung aktiviert, werden solche Informationen dem
Installationsprotokoll angefgt. Das Windows Installer-Protokoll ist das wichtigste Instrument, um
auftretende Probleme wirkungsvoll zu beseitigen.
Beim Auftreten von Fehlern im Installationsprozess sollte der erste Schritt darin bestehen, das
Installationsprotokoll mit einem Texteditor zu ffnen und nach der Zeichenfolge Error zu suchen.
Wird eine solche Zeichenfolge gefunden und folgt darauf eine Nummer, kann eine Erluterung zu dem
aufgetretenen Fehler anhand der Fehlernummer im Windows Installer-SDK nachgeschlagen werden.
MSI (c) (E0:2C) [17:26:22:921]: Doing action: WelcomeDlg
Action 17:26:22: WelcomeDlg.
Action start 17:26:22: WelcomeDlg.
Action 17:26:22: WelcomeDlg. Dialog created
305
Kapitel 7
Error 2803: Dialog View did not find a record for the dialog LicenseAgreementDlg
Action ended 17:26:23: WelcomeDlg. Return value 3.
Wurde ein entsprechender Fehler identifiziert, sollten die Vorgnge vor dem Fehler betrachtet und
analysiert werden, da sich hier hufig die Fehlerursache befindet. Wenn mglich sollte immer ein
detailliertes Installationsprotokoll erstellt werden, da dieses viele zustzliche Informationen enthlt, die
hufig als Erklrung fr das Verhalten ausreichend sind.
MSI (s) (70:74) [17:26:25:722]: File: C:\Windows\inf\football.inf; Overwrite;
existing file is unversioned and unmodified
Es ist zu beachten, dass der Windows Installer mitunter nicht alle Fehlermeldungen protokolliert, so
dass unter Umstnden eine andere Taktik verwendet werden sollte. Die Suche nach ungewhnlichen
Unterbrechungen in der zeitlichen Abfolge der Aktionen kann hierbei weiter helfen. Mit Verwendung
des Windows Installers 3.0 und hher wird zu diesem Zweck ein Zeitstempel jeder Eintragung
vorangestellt.
In einigen Anwendungsfllen ist es erforderlich, dass der Windows Installer auf die
Originalinstallationsquellen zugreifen muss, um bestimmte Ressourcen zu extrahieren. Wird die
Installation ohne Anzeige einer Benutzeroberflche durchgefhrt und kann auf die Installationsquelle
nicht zugegriffen werden, wird die Installation beendet. Das Installationsprotokoll enthlt jedoch
Hinweise fr den Zugriff auf die Installationsquellen nach dem folgenden Schema.
MSI
MSI
MSI
MSI
MSI
MSI
(s)
(s)
(s)
(s)
(s)
(s)
(70:74)
(70:74)
(70:74)
(70:74)
(70:74)
(70:74)
[17:26:25:171]:
[17:26:25:171]:
[17:26:25:187]:
[17:26:25:187]:
[17:26:25:187]:
[17:26:25:203]:
SOURCEMGMT:
SOURCEMGMT:
SOURCEMGMT:
SOURCEMGMT:
SOURCEMGMT:
SOURCEMGMT:
Attempting to use LastUsedSource from source list.

Trying source \\eagle\setup\.
Source is invalid due to missing/inaccessible package.
Processing net source list.
Trying source \\eagle\setup\1.0.0.
Source is invalid due to missing/inaccessible package.
Alle Informationen, die auf die Installationsquellen abzielen, sind durch die Zeichenfolge
SOURCEMGMT im Installationsprotokoll gekennzeichnet.
Vielfach stellt sich die Frage warum eine bestimmte Ressource nicht installiert wurde. Auch hierfr ist
die Analyse nicht sonderlich schwierig, da das Installationsprotokoll die erforderlichen Informationen
bereitstellt. Der erste Schritt besteht darin, den Installationserfolg der Komponente zu prfen, die die
jeweilige Ressource beinhaltet.
MSI (s) (70:74) [17:26:25:546]: Disallowing installation of component: {10048711-2C96-11D2-9A97-006097C4E452}
since the same component with higher versioned keyfile exists
Ist ein solcher Eintrag im Installationsprotokoll vorhanden, kann die Begrndung fr das Verhalten
sehr einfach abgelesen werden. Findet sich im Installationsprotokoll kein Hinweis auf die jeweilige
Komponente, muss zunchst geprft werden, ob die Komponente im Installationspaket mit einer
Bedingung versehen ist, die gegen False ausgewertet wurde. Ist dieses nicht der Fall, sollte eine
Analyse auf Ebene der Datei erfolgen, da entsprechende Dateiaktionen dem Protokoll ebenfalls
angefgt werden.
MSI (s) (70:74) [17:26:25:897]: Executing op: FileCopy(SourceName=e_5ltnaj.dll|Football.resources.dll,
SourceCabKey=F__en_Football.resources.dll,DestName=Football.resources.dll,Attributes=512,FileSize=7168,
PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=1.0.0.0,Language=0,InstallMode=58982400,,,,,,,)
MSI (s) (70:74) [17:26:25:897]: File: C:\Program Files (x86)\Football 2008\en-US\Football.resources.dll;
Won't Overwrite; Won't patch; Existing file is of an equal version
306
Wird die Installation nicht fehlerfrei beendet, so stellt sich immer die Frage nach dem Grund fr dieses
Verhalten. In den meisten Fllen findet sich der Fehler im transaktionalen Teil der Installation, also in
dem Teil, in dem das Zielsystem physisch modifiziert wird. Da die hierfr erforderlichen Aktionen im
Rahmen der Skriptverarbeitung ausgefhrt werden, ist dieses ein guter Aufhnger fr eine Analyse.
Das Installationsprotokoll sollte demzufolge nach den folgenden Informationen durchsucht werden:
InstallFinalize: Return: Kennzeichnet das Ende des Installation. Der letzte Fehler ist der Grund fr
den Abbruch (Return Code 3 bedeutet einen Fehler).
Executing op: Header (Letzte Instanz): Dieser Eintrag wird zu Beginn der Skriptausfhrung
erstellt. Die letzte Instanz dieser Eintragung kennzeichnet das Rollback-Skript. Die Aktion die zum
Rollback fhrte, befindet sich kurz vor diesem Eintrag.
Es sollte ersichtlich sein, dass die Analyse eines Fehlerprotokolls sehr aufwendig ist und ein hohes
Ma an Sachverstndnis erfordert. Bei komplexen Installationsszenarien kommt ein betrchtlicher
Umfang des Installationsprotokolls hinzu. Eine Analyse mit Notepad oder einem anderen Texteditor
erscheint ausgesprochen schwierig und resultiert in vielen Fllen in zustzlichen Fehlerquellen. Das
Windows Installer-SDK enthlt fr solche Flle ein hervorragendes Tool mit der Bezeichnung
Windows Installer Verbose Log Analyzer (wilogutl.exe). Diese Anwendung ist unentbehrlich bei der
Analyse von Protokolldateien einer Windows Installer-Installation. Es werden ausschlielich kritische
Fehler angezeigt und vielfach eine Lsung zur Abhilfe des Problems angeboten. Zustzlich existieren
weitere Tools dieser Kategorie, von denen einige in Anhang B aufgefhrt sind.
Mehrsprachige Benutzeroberflchen (Multi-Lingual User Interface, MUI) sind in unterschiedlichen
Ausprgungen zu finden. So existieren Installationsprogramme, Anwendungen und schlielich auch
Betriebssysteme in sprachspezifischen Varianten. Bei Windows XP musste zunchst das
Betriebssystem auf die Verwendung unterschiedlicher Sprachen vorbereitet werden, indem das
Multilingual User Interface Pack installiert wurde. Anschlieend konnten die erforderlichen
Sprachpakete verwendet werden, um eine lokalisierte Benutzeroberflche zu gestalten. Die Ergebnisse
waren hierbei von der Wahl der Sprache abhngig. Bei einigen Sprachen war die Untersttzung
vollstndiger als bei anderen Sprachen. Ein sehr groer Nachteil ergab sich jedoch aus dem Umstand,
dass als Grundlage immer eine englische Version von Windows XP verwendet werden musste. Das
bedeutet auch, dass keine Mglichkeit bestand, ein deutsches Windows nachtrglich um die englische
Darstellung zu erweitern.
Die mehrsprachige Benutzeroberflche in den Betriebssystemen Windows Vista und Windows Server
2008 stellt einen neuen Ansatz fr Mehrsprachigkeit dar. Hierbei werden die Sprachressourcen fr die
Benutzeroberflche vom Binrcode des Betriebssystems getrennt. Diese Trennung ermglicht eine
vollstndige nderung der Sprache, ohne die Kernbinrdateien des Betriebssystems ndern oder
mehrere Sprachen auf dem gleichen Computer installieren zu mssen. Sprachen werden als
Sprachpakete angewendet, die die Ressourcen enthalten, die fr die Lokalisierung eines Teils oder der
gesamten Benutzeroberflche des Betriebssystems erforderlich sind. Alle Installationen von Windows
Vista und Windows Server 2008 enthalten mindestens ein Sprachpaket sowie die sprachneutralen
Binrdateien, aus denen das Betriebssystem besteht. Die Sprachpakete werden ber Windows-Update
angeboten und lassen sich nach der Installation ber die Regions- und Spracheinstellungen aktivieren,
307
Kapitel 7
wie auch die nachfolgende Abbildung 7.62 zeigt.
Abbildung 7.62: Aktivieren einer Anzeigesprache
Im Rahmen der Anwendungsentwicklung kann sich dieser Mechanismus ebenfalls zu Nutze gemacht
werden. Bei der Verwendung von Visual Studio ist die Realsierung einer mehrsprachigen Anwendung
auf sehr einfache Weise mglich. Starten Sie hierzu Visual Studio und whlen Sie als neuen Projekttyp
die Windows Forms-Anwendung. Vergeben Sie einen Namen fr das Projekt wie beispielsweise
Football. ffnen sie die automatische generierte Datei Form1.cs im Entwurfsmodus und wechseln
Sie zum Eigenschaftenfenster. Markieren Sie die Eigenschaft Language und whlen in der Liste die
Sprache English (United States) aus. Verndern Sie nun den Titel des Dialogs Form1in Football
2008. Wechseln Sie wieder zum Eigenschaftenfenster, whlen die Sprache German (Germany) aus
und verndern sie den Titel nun in Fuball 2008. Wenn Sie nun das Projekt im ProjektmappenExplorer betrachten, erkennen Sie zustzlich generierte Ressourcen-Dateien, die letztlich die
sprachspezifischen Informationen enthalten, wie dieses auch in Abbildung 7.63 dargestellt wird.
308
Abbildung 7.63: Mehrsprachige Anwendung im Projektmappen-Explorer
Beim Kompilieren werden die sprachspezifischen Informationen in eigene Ressource-Bibliotheken

bertragen und in speziell benannten Unterverzeichnissen abgelegt. Die Namensgebung dieser
Unterverzeichnisse richtet sich nach den verwendeten Sprachen und reprsentiert den Namen der
verwendeten Kultur wie beispielsweise de-DE fr German (Germany) oder en-US fr English
(United States). Die generierte Verzeichnisstruktur wird im folgende Listing 7.70 aufgezeigt.
D:\Football\Release>dir *.* /s
Volume in Laufwerk D: hat keine Bezeichnung.
Verzeichnis von D:\Football\Release
09.09.2008
09.09.2008
09.09.2008
09.09.2008
09.09.2008
11:05
<DIR>
11:05
<DIR>
11:04
<DIR>
11:04
<DIR>
11:02
1 Datei(en),
.
..
de-DE
en-US
43.520 Football.exe
43.520 Bytes
Verzeichnis von D:\Football\Release\de-DE

09.09.2008
09.09.2008
09.09.2008
11:04
<DIR>
11:04
<DIR>
11:02
1 Datei(en),
.
..
7.680 Football.resources.dll
7.680 Bytes
Verzeichnis von D:\Football\Release\en-US

09.09.2008
09.09.2008
09.09.2008
11:04
<DIR>
11:04
<DIR>
11:02
1 Datei(en),
.
..
7.168 Football.resources.dll
7.168 Bytes
Listing 7.70: Verzeichnisstruktur einer mehrsprachigen Anwendung
309
Kapitel 7
Die erzeugte Verzeichnisstruktur ist kompatibel mit den Vorgaben der mehrsprachigen
Benutzeroberflche von Windows Vista und Windows Server 2008, worauf ich an spterer Stelle noch
zurckkommen werde. Zu diesem Zeitpunkt ist bereits ein sehr schnes Ergebnis zu beobachten, denn
in Abhngigkeit zur verwendeten Anzeigesprache des Betriebssystems wird auch die Sprache der
Anwendung automatisch verndert.
Die Erstellung eines geeigneten Installationspaketes fr die zuvor erstellte Anwendung stellt keine
besondere Herausforderung dar, da nur das Design der Ordnerstruktur beachtet werden muss. Alle
weiteren Informationen sind zunchst identisch mit einem Installationspaket einsprachiger
Anwendungen. Ich habe im letzten Satz bewusst das Wort zunchst gewhlt, denn das erzeugte
Installationspaket ist in mehrsprachigen Systemen nicht ganz perfekt. Den Problempunkt stellt die
Dateiverknpfung dar, da diese nicht sprachspezifisch erzeugt werden kann. Das bedeutet, dass
unabhngig von der verwendeten Anzeigesprache, die Bezeichnung der Dateiverknpfung identisch
bleibt. Bei einigen Anwendungen mag das kein groes Problem darstellen, da die Bezeichnung
sowieso sprachneutral gewhlt wurde. Allerdings existieren Anwendungen, bei denen das nicht
mglich ist. Darber hinaus kann eine Dateiverknpfung mit einer Beschreibung versehen werden, die
ebenfalls nicht lokalisierbar ist und somit nicht zur gewnschten Darstellung innerhalb einer
mehrsprachigen Umgebung fhrt.
Windows Vista, Windows Server 2008 und der Windows Installer 4.0 und hher enthalten neue
Implementierungen, mit denen die Verwendung lokalisierter Dateiverknpfungen ermglicht wird.
Technisch gesehen, werden die Bezeichnungen und Beschreibungen in eine Ressourcen-Bibliothek
ausgelagert und der Dateiverknpfung wird eine Referenz hierauf zugewiesen. Die RessourceBibliothek unterteilt sich wiederum in einen sprachneutralen und einen sprachspezifischen Bereich, so
dass hiermit eine lokalisierte Darstellung realisiert werden kann. Die Zuordnung zu der
Dateiverknpfung erfolgt ber die spezielle Initialisierungsdatei desktop.ini, die sich im gleichen
Verzeichnis wie die Verknpfung befindet. Im Programm-Ordner findet sich beispielsweise eine
solche Datei mit dem nachfolgenden Inhalt.
[LocalizedFileNames]
Windows Contacts.lnk=@%SystemRoot%\system32\shell32.dll,-22017
Windows Fax and Scan.lnk=@%SystemRoot%\system32\FXSRESM.dll,-114
Windows Mail.lnk=@%ProgramFiles%\Windows Mail\WinMail.exe,-225
Windows Movie Maker.lnk=@%ProgramFiles%\Movie Maker\MovieMk.dll,-61403
Windows Collaboration.lnk=@%programfiles%\Windows Collaboration\WinCollabRes.dll,-2530
Windows Live.lnk=@%SystemRoot%\explorer.exe,-6006
Windows DVD Maker.lnk=@%ProgramFiles%\Movie Maker\DVDMaker.exe,-61403
Windows Calendar.lnk=@%ProgramFiles%\Windows Calendar\wincal.exe,-200
Windows Media Player.lnk=@%systemroot%\syswow64\wmploc.dll,-102
Windows Defender.lnk=@%ProgramFiles%\Windows Defender\MsMpRes.dll,-104
Der Umfang der Datei ist natrlich von den installierten Betriebssystemkomponenten abhngig.
Erkennbar ist jedoch, dass den Dateiverknpfungen eine Binrdatei zugeordnet ist, die letztlich die
lokalisierte Bezeichnung enthlt, die durch die Ressource-ID angegeben wird. Mit dem Windows
Installer 4.0 und hher ist es fr die Betriebssysteme Windows Vista und Windows Server 2008 nun
ebenfalls mglich, lokalisierte Dateiverknpfungen zu erstellen. Zu diesem Zweck wurde die Tabelle
Shortcut um einige Spalten erweitert. Bevor ich jedoch auf das Design des Paketes eingehen werde,
gilt es zunchst die erforderliche Ressource-Bibliothek zu erstellen, in der die lokalisierten
310
Zeichenfolgen abgelegt werden.
Ressourcenskript und Ressourcendateien

Der erste Schritt besteht darin ein Ressourcenskript zu erzeugen, das als Basis zur Erzeugung der
bentigten Bibliotheken verwendet wird. Starten Sie hierzu Visual Studio und erstellen Sie eine neue
Datei. In dem sich ffnenden Dialogfeld whlen sie die Systemeigene Ressourcenvorlage (Native
Resource Template), wie dieses auch in Abbildung 7.64 gezeigt wird.
Abbildung 7.64: Auswahl einer Vorlage zur Erzeugung eines Ressourcenskriptes
Nachdem diese Vorlage im Designer in Visual Studio geffnet wurde, fgen sie eine Ressource vom
Typ Zeichenfolgentabelle (String Table) hinzu, indem sie den Menpunkt Ressource hinzufgen des
Mens Bearbeiten aktivieren. In der sich ffnenden Zeichenfolgentabelle fgen Sie einen Eintrag mit
dem Wert 101 und der Bezeichnung fr die Dateiverknpfung wie beispielsweise Fuball 2008
hinzu. Erstellen Sie einen weiteren Eintrag mit dem Wert 102 und einer Beschreibung fr die
Verknpfung. Die Darstellung der Zeichenfolgentabelle kann nun geschlossen werden. Anschlieend
ist noch eine Ressource vom Typ Version zu erstellen und diese ggf. anzupassen. Wichtig ist an dieser
Stelle, dass fr die Zeichenfolgentabelle noch die richtige Sprache gewhlt wird. Diese kann ber das
Eigenschaftsfenster erfolgen, nachdem die Ressource markiert wurde. Legen Sie als Sprache Deutsch
(Deutschland) fest und speichern Sie die Datei anschlieend. Whlen Sie hierbei den Dateityp 32Bit Ressourcendatei und verwenden sie 1031.res als Dateinamen. Wiederholen Sie die gerade
aufgefhrten Aktionen um eine weitere Ressourcendatei zu erstellen, in der die englischen Texte
enthalten sind. Die Vorgehensweise ist identisch. Es sind natrlich die entsprechend lokalisierten Texte
zu verwenden und die Sprache der Zeichenfolgentabelle ist auf Englisch (USA) festzulegen.
Speichern Sie die Datei letztlich unter der Bezeichnung 1033.res.
Im nchsten Schritt mssen aus den erzeugten Ressourcendateien, die erforderlichen
Objektbibliotheken erzeugt werden. Verwenden Sie hierzu den Microsoft Incremental Linker, der ber
die folgenden Befehlszeilen aufgerufen wird. Beachten Sie, dass sich der Linker nicht im Suchpfad
311
Kapitel 7
befindet und somit die Befehle am einfachsten innerhalb der Visual Studio 2008 Eingabeaufforderung
auszufhren sind.
link.exe 1031.res /noentry /machine:x86 /dll /out:1031.dll
link.exe 1033.res /noentry /machine:x86 /dll /out:1033.dll
Das Ergebnis sind nun zwei Ressource-Bibliotheken, die jeweils sprachspezifische Informationen
enthalten. Allerdings knnen sie fr das beabsichtigte Szenario noch nicht verwendet werden. Es ist
erforderlich sie in mehrere Dateien aufzuteilen, so dass eine sprachneutrale Datei und zwei
sprachspezifische Dateien erzeugt werden mssen. Zu diesem Zweck existiert das Tool muirct.exe,
dass Bestandteil des Windows SDKs 6.0 und hher ist.
Sprachneutrale und Sprachspezifische Dateien

Die Verwendung des Tools muirct.exe ist nicht ganz trivial, da einige Vorberlegungen und
Vorbereitungen getroffen werden mssen. Zunchst wird eine Art Steuerdatei bentigt, die zur
Definition der Ressourcen dient, die sprachspezifisch zu verwenden sind. Im Normalfall sind
sprachabhngige Informationen in Zeichenfolgentabellen zu finden, so dass diese Ressource in die
sprachspezifische Datei bertragen wird. Im Gegensatz dazu sind Versionsinformationen
sprachneutral, so dass diese auch in der neutralen Datei verbleiben. Um hier flexibel auf
unterschiedlichste Anforderungen reagieren zu knnen, kann die Zuordnung individuell festgelegt
werden. Im nachfolgenden Listing 7.71 ist eine generische Vorlage fr eine solche Steuerdatei zu
finden, die auch als Resource Configuration Data bezeichnet wird.
<localization>
<resources>
<win32Resources fileType="Application" >
<neutralResources>
<resourceType typeNameId="#16"/>
</neutralResources>
<localizedResources>
<resourceType typeNameId="#2" itemId="5 6 7 8 9 10 11 12" itemName="HTML PRI" />
<resourceType typeNameId="#4" />
<resourceType typeNameId="HTML" />
<resourceType typeNameId="MY_TYPE" />
</localizedResources>
</win32Resources>
</resources>
</localization>
Listing 7.71: Generische Vorlage zur Erzeugung von sprachspezifischen Dateien
312
In der Vorlage ist erkennbar, dass nur die Ressource #16 sprachneutral verwendet wird und das alle
anderen Ressourcen hingegen sprachspezifisch verwendet werden. Bei der Ressource #16 handelt es
sich um die Versionsinformationen, wie auch in der nachfolgenden Auflistung dargestellt wird.
CURSOR(1)
BITMAP(2)
ICON(3)
MENU(4)
DIALOG(5)
STRING(6)
FONTDIR(7)
FONT(8)
ACCELERATORS(9)
RCDATA(10)
MESSAGETABLE(11)
GROUP_CURSOR(12)
GROUP_ICON(14)
VERSION(16)
HTML(23)
Nun sind vorerst alle Informationen und Ressourcen vorhanden um eine sprachneutrale und eine
sprachspezifische Objektbibliothek zu erzeugen. Hierzu ist die folgende Befehlszeile zu verwenden, in
der die Datei mui.rcconfig die gerade erluterte Steuerdatei bezeichnet. Bei der Datei 1031.dll handelt
es sich um die bereits erzeugte Eingabedatei, die letztlich in die Dateien strings.dll und strings.dll.mui
aufgeteilt wird, wobei die letztere die sprachspezifischen Informationen enthlt.
muirct.exe -q mui.rcconfig -f 1031.dll strings.dll .\de-DE\strings.dll.mui
Es ist natrlich weiterhin erforderlich die Dateien fr die englische Sprachfassung zu erzeugen, indem
die Befehlszeile entsprechend aufgerufen wird. Die sich hieraus ergebende Problematik liegt nun im
fehlerhaften Zusammenspiel der sprachneutralen mit der sprachspezifischen Datei, da beide ber eine
Checksumme verfgen. Es ist erforderlich, dass beide Dateien ber die identische Checksumme
verfgen, was im oberen Konstrukt aus dem folgenden Grund nicht zwangslufig gegeben ist.
Im ersten Schritt werden die beiden Dateien fr die deutsche Sprachfassung generiert. Beide Dateien
verfgen ber eine identische Checksumme und knnen somit gemeinsam verwendet werden. Im
zweiten Schritt werden die Dateien fr die englische Sprachfassung generiert, wobei nur die
sprachspezifische Datei bentigt wird. Die hierbei erzeugte sprachneutrale Datei wird nicht weiter
bentigt, da die Inhalte der sprachneutralen Dateien identisch sind und nur eine Datei verwendet
werden kann. Allerdings enthalten die Dateien, die auf Basis der englischen Fassung generiert wurden
eine Checksumme, die von den anderen Checksummen abweicht und somit nicht zu dem gewnschten
Verhalten in der mehrsprachigen Oberflche fhrt.
Die Umsetzung einer funktionsfhigen Lsung ist allerdings nicht sonderlich kompliziert. Nachdem
313
Kapitel 7
die Dateien auf Basis der deutschen Sprachfassung generiert wurden, kann die generierte Checksumme
betrachtet werden, indem die folgende Befehlszeile aufgerufen wird.
muirct.exe -d strings.dll
Das Ergebnis dieses Befehlszeilenaufrufs ist eine Auflistung aller fr die Mehrsprachigkeit relevanten
Informationen der Datei strings.dll, die im nachfolgenden Listing 7.72 auch dargestellt werden.
D:\ResLibs>muirct.exe -d strings.dll
Signature
Length
RC Config Version
FileType
SystemAttributes
Service Checksum
Checksum
MainNameTypes
MainIDTypes
MuiNameTypes
MuiIDTypes
fecdfecd
c8
10000
21
0
2a078537f90dd2e4442a688fe8a56e9b
55613533024690a5e0f74b7dd5abfedb
MUI
16
MUI
6 16
Listing 7.72: Sprachspezifische Metainformationen einer Datei
Der fr die weiteren Schritte erforderliche Wert verbirgt sich hinter der Eigenschaft Checksum.
Fgen Sie diese Zeichenfolge dem Element <win32Resources/> der Steuerdatei mui.rcconfig an,
wobei als Attribut checksum zu verwenden ist. Somit muss der in Listing 7.71 dargestellte Eintrag
<win32Resources/> korrigiert werden, so dass sich die nachfolgende Darstellung ergibt.
<win32Resources fileType="Application" checksum="55613533024690a5e0f74b7dd5abfedb" >
Hiernach sind alle Vorbereitungen abgeschlossen und die Ressource-Bibliotheken knnen final durch
die folgenden Befehlszeilen erzeugt werden.
muirct.exe -q mui.rcconfig -f 1031.dll strings.dll .\de-DE\strings.dll.mui
muirct.exe -q mui.rcconfig -f 1033.dll strings.dll .\en-US\strings.dll.mui
Hierdurch wird die sprachneutrale Datei strings.dll erzeugt und in den entsprechenden
Unterverzeichnissen die sprachspezifischen Fassungen. Zu beachten ist hierbei, dass die
Unterverzeichnisse fr die Befehlszeilenaufrufe existieren mssen.
Erstellen des Installationspaketes

Die mehrsprachige Anwendung und die Ressourcen-Bibliotheken zur Verwendung lokalisierter
Dateiverknpfungen wurden erzeugt. An dieser Stelle sind nun die einzelnen Teile zusammenzufhren
und das Installationspaket ist zu erzeugen. Wie bereits zu Beginn des Abschnitts angemerkt wurde,
unterscheidet sich die Vorgehensweise nicht von den bereits bekannten Ablufen. Lediglich die
Integration der sprachspezifischen Dateien und die Verwendung der Tabelle Shortcut sind abweichend
durchzufhren.
314
In der Tabelle Shortcut sind Informationen zu finden, die der Windows Installer bentigt, um
Verknpfungen auf dem Zielcomputer anzulegen. Die Struktur der Tabelle wurde mit dem Windows
Installer 4.0 um einige Spalten ergnzt, so dass sich nun der folgende Aufbau ergibt.
Spalte
Typ
Gre
Schlssel
Null
Beschreibung
Shortcut
Identifier
s72
Directory_
Identifier
s72
Verweist auf das Verzeichnis in dem

die Verknpfung erzeugt werden
soll.
Name
Filename
s128
Name der Verknpfung.
Component_
Identifier
s72
Verweist auf eine Komponente.
Target
Shortcut
s72
Ziel der Verknpfung.
Arguments
Formatted
s255
Enthlt zustzliche
Befehlszeilenargumente.
Description
Text
s255
Enthlt eine Beschreibung.
Hotkey
Integer
i2
Tastenkombination zur Aktivierung

der Verknpfung.
Icon
Identifier
s72
Verweist auf eine Symboldatei.
IconIndex
Integer
i2
Legt den Index des Symbols der

Symboldatei fest.
ShowCmd
Integer
i2
Darstellungsform des Fensters.
WkDir
Integer
s72
Legt das Arbeitsverzeichnis fest.
DisplayResourceDLL
Formatted
s100
Definition einer Ressourcendatei zur

Festlegung der Bezeichnung 3.
DisplayResourceId
DoubleInteger
i4
Festlegen der zu verwendenden

Ressource3.
DescriptionResourceDLL
Formatted
s100
Definition einer Ressourcendatei zur

Festlegung der Beschreibung3.
DescriptionResourceId
DoubleInteger
i4
Festlegen der zu verwendenden

Ressource3.
Eindeutige Identifizierung des

Datensatzes.
Tabelle 7.63: Struktur der Tabelle Shortcut
Wie in der Tabelle ersichtlich, wurden die Spalten DisplayResourceDLL, DisplayResourceId,

DescriptionResourceDLL und DescriptionResourceId der Tabelle Shortcut angefgt um mehrsprachige
Implementierungen zu ermglichen. Die Spalten werden jedoch nur verwendet, wenn die Installation
unter Verwendung des Windows Installers 4.0 und hher auf den Plattformen Windows Vista und
Windows Server 2008 erfolgt. In allen anderen Konstellationen werden sie ignoriert.
Verfgbar mit Windows Installer 4.0 und hher unter Windows Vista unter Windows Server 2008.
315
Kapitel 7
Zur Verwendung einer lokalisierten Bezeichnung muss der Spalte DisplayResourceDLL der
vollstndige Pfad zu der sprachneutralen Datei zugewiesen werden. Die Pfadangabe kann auch durch
das Konstrukt [#Dateischlssel] realisiert werden. Falls dieser Spalte ein gltiger Wert zugewiesen
wurde, wird der Inhalt der Spalte Name ignoriert. In diesem Fall muss der Spalte DisplayResourceId
die Kennzeichnung der zu verwendenden Ressource zugeordnet werden. Wurde der Spalte
DisplayResourceDLL hingegen kein Wert zugewiesen, wird die Spalte Name zur Bezeichnung der
Dateiverknpfung benutzt. Ein identisches Bild ergibt sich bei der Verwendung der Spalte
DescriptionResourceDLL. Die hierdurch involvierten Spalten sind DescriptionResourceId und
Description.
Hinweis Beginn
Es ist wichtig, dass die Referenz immer auf die sprachneutrale Datei gelegt wird. Diese ist virtuell mit
der sprachspezifischen Datei verknpft, so dass sie von auen betrachtet als Einheit angesehen werden.
Falls die Referenz auf eine der sprachspezifischen Dateien gesetzt wird, wird immer ein konstanter
Text verwendet, wodurch die Mehrsprachigkeit nicht umgesetzt werden kann.
Hinweis Ende
Das nachfolgende Listing 7.73 zeigt das vollstndige WXS-Dokument zur Erstellung eines
Installationspaketes, mit dem eine mehrsprachige Anwendung installiert werden kann. Weiterhin
werden in dem Listing die neuen Funktionalitten der Tabelle Shortcut dargestellt.
<Product UpgradeCode="{6C4FA1DC-0AEF-47d7-974D-409DF1EB44F5}" Manufacturer="Microsoft Deutschland GmbH"
Language="1033" Version="1.00.0000" Name="Football 2008 (MUI)"
Id="{B97086E8-06AB-4a78-8069-5BB33E1564C3}" Codepage="1252">
<Package Description="Football 2008 (MUI)" Manufacturer="Andreas Kerl" InstallerVersion="400"
Platform="x86" Languages="1033" Compressed="yes" InstallPrivileges="elevated" />
<Condition Message="This setup requires the .NET Framework. Please install the .NET Framework
and run this setup again..">MsiNetAssemblySupport</Condition>
<Condition Message="Concurrent installations are not supportet with this package.">
Not ParentProductCode</Condition>

<Property Id="ARPPRODUCTICON" Value="I__Football.exe"/>
<Property Id="ALLUSERS" Value="1" />
<Icon Id="I__Football.exe" SourceFile="..\Bin\App.ico" />
<Directory Id="INSTALLLOCATION" Name="Football 2008 (MUI)">

<Component Id="C__Football.exe" Guid="{B7D00D86-78E5-48e4-94AC-7D92D6502008}">
<File Id="F__Football.exe" Source="..\Bin\" Name="Football.exe" KeyPath="yes" DiskId="1"
316
AssemblyManifest="F__Football.exe" AssemblyApplication="F__Football.exe" Assembly=".net" />


<File Id="F__Strings.dll" Source="..\Bin\" Name="Strings.dll" DiskId="1"/>
<Shortcut Id="S__Football.exe" Directory="DesktopFolder" Name="Foot2008" Target="Application"
Hotkey="0" Icon="I__Football.exe" IconIndex="0" Show="normal"
DisplayResourceDll="[#F__Strings.dll]" DisplayResourceId="101"
DescriptionResourceDll="[#F__Strings.dll]" DescriptionResourceId="102" />
</Component>

<Directory Id="EnglishFilesFolder" Name="en-US">
<Component Id="C__English" Guid="{669B10F3-3B4A-4b28-A3F9-A1E27D054886}">
<File Id="F__en_Football.resources.dll" Source="..\Bin\en-US\" Name="Football.resources.dll"
KeyPath="yes" DiskId="1" />
<File Id="F__en_Strings.dll" Source="..\Bin\en-US\" Name="Strings.dll.mui" DiskId="1"/>
</Component>
</Directory>

<Directory Id="GermanFilesFolder" Name="de-DE">
<Component Id="C__German" Guid="{0BE8A52D-0E92-4bdd-8985-A1271BE0915B}">
<File Id="F__de_Football.resources.dll" Source="..\Bin\de-DE\" Name="Football.resources.dll"
KeyPath="yes" DiskId="1" />
<File Id="F__de_Strings.dll" Source="..\Bin\de-DE\" Name="Strings.dll.mui" DiskId="1"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id="Application" Title="Application"
<ComponentRef Id="C__Football.exe" />
<ComponentRef Id="C__English" />
<ComponentRef Id="C__German" />
</Feature>
Level="1">


<WixVariable Id="WixUIBannerBmp" Value="..\Bin\WixUI_Bmp_Banner.jpg" />
<WixVariable Id="WixUIDialogBmp" Value="..\Bin\WixUI_Bmp_Dialog.jpg" />
</Product>
</Wix>
Listing 7.73: Installationspaket einer mehrsprachigen Anwendung
317
Kapitel 7
Die fr diesen Abschnitt relevanten Elemente sind in der Komponente mit der Bezeichnung
C__Football.exe zu finden. Diese Komponente enthlt die Anwendung, die sprachneutrale Datei und
die Dateiverknpfung. Interessant sind hierbei die Definitionen der Tabelle ShortCut, die zur
Festlegung der Ressource-Dateien dienen. Hier ist erkennbar, dass die sprachneutrale Datei
F__Strings.dll sowohl fr den Namen als auch fr die Beschreibung verwendet wird. Der Name
wird letztlich durch die Ressource mit der Nummer 101 und die Beschreibung durch die 102
dargestellt. Die weiteren relevanten Elemente beziehen sich auf die sprachspezifischen Dateien, die in
den speziell bezeichneten Unterordnern abgelegt werden.
Fazit
In den vorangegangenen Kapiteln wurden die neuen Funktionalitten des Windows Installer 4.0
aufgezeigt, wobei Technologien wie die Benutzerkontensteuerung und der Neustart-Manager einen
sehr hohen Stellenwert eingenommen haben. In diesem Kapitel wurde nun die Betrachtung der neuen
Funktionalitten im Windows Installer 4.0 abgeschlossen. Die Inhalte bezogen sich hierbei nicht nur
auf ein spezifisches Thema, sondern adressierten drei vllig unterschiedliche Erweiterungen, die
weniger komplex sind, aber dennoch uerst interessante Mglichkeiten bieten.
Der Windows-Ressourcenschutz und die Verwendung der mehrsprachigen Benutzeroberflche sind
spezielle Funktionalitten, die nur unter den Betriebssystemen Windows Vista und Windows Server
2008 zur Verfgung stehen. Anders verhlt es sich mit den neuen Mglichkeiten zur Erstellung eines
Installationsprotokolls. Diese sind auch im Windows Installer 4.5 zu finden, so dass diese
Funktionalitt hierdurch auch unter Windows XP und Windows Server 2003 zur Verfgung steht.
Dieses ist absolut notwendig, denn die Erstellung von Installationsprotokollen ist eines der wichtigsten
Werkzeuge zur Analyse und Beseitigung von potentiellen Fehlerquellen und somit die Grundlage fr
optimal konzipierte Installationsprozesse. Trotz guter Analysemglichkeiten darf aber auch das Design
eines Installationspaketes nicht auer Acht gelassen werden. Gerade im Rahmen einer LogoZertifizierung mssen sehr viele Richtlinien und Vorgehensweisen beachtet werden, die letztlich das
Ziel verfolgen, ein stabiles Installationspaket zu erhalten. Auch wenn die Anforderung zur Erlangung
eines solchen Logos nicht besteht, sollte sich dennoch an den Richtlinien orientiert werden.
318
Teil C
Neue Funktionen
des Windows
Installers 4.5
319
Kapitel 8
Paketbergreifende Transaktionen

Transaktionen
Fazit
320
323
334
338
345
357
366
367
Windows Installer 4.0 enthlt viele neue Erweiterungen die fast ausschlielich auf die neuen
Funktionen der Betriebssysteme Windows Vista und Windows Server 2008 abzielen. Aus diesem
Grund existiert der Windows Installer 4.0 nur fr diese Betriebssysteme; ein Redistributionspaket fr
die Betriebssysteme Windows XP und Windows Server 2003 wird es nicht geben. Das hieraus
entstandene Konstrukt ist problematisch, da eine vollstndige Migration auf dies Betriebssysteme
Windows Vista und Windows Server 2008 noch einige Jahre dauern wird. Bis zu diesem Zeitpunkt
wrden somit zwei Versionen des Windows Installers existieren, die einen abweichenden
Funktionsvorrat aufweisen. Hieraus ergeben sich zwangslufig zustzliche Aufwnde im Rahmen der
Softwareentwicklung und -Bereitstellung, da ja immer unterschiedliche Versionen zu bercksichtigen
sind. Gerade in groen IT-Umgebungen ist dieser Aufwand nicht zu unterschtzen.
Dieses ist nur ein Grund, der zur Entwicklung des Windows Installers 4.5 gefhrt hat. Der Windows
Installer 4.5 wird fr alle aktuell untersttzten Plattformen, also Windows XP, Windows Server 2003,
Windows Vista und Windows Server 2008 zur Verfgung gestellt, wodurch nur gegen eine spezifische
Version entwickelt und getestet werden muss. Die Unterschiede und fehlenden Funktionalitten in den
Betriebssystemgenerationen werden vom Windows Installer selbst behandelt. Zustzlich verfgt der
Windows Installer 4.5 noch ber neue Funktionalitten und natrlich ber fehlerbereinigte
Implementierungen.

Windows Installer 4.5 ist als Redistributionspaket fr die Betriebssysteme Windows Server 2008,
Windows Vista, Windows Server 2003 und Windows XP verfgbar. Hierbei gibt es einige
Versionsunterschiede, die in Tabelle 8.64 zusammengefasst wurden.
Release
320
Version
Anmerkungen
Kapitel 8
4.5.6000.20817
Redistributionspaket fr Windows Vista (RTM).
4.5.6001.22159
Redistributionspaket fr Windows XP SP2, Windows

XP SP3, Windows Server 2003 SP1 und Windows
Server 2003 SP2.
4.5.6001.22162
Redistributionspaket fr Windows Vista SP1 und

Tabelle 8.64: Verfgbare Versionen des Windows Installers 4.5
Die
aktuelle
Versionsbezeichnung
des
Windows
Installers
liegt
im
Format
Major.Minor.Build.Update vor. Bei der Betrachtung der vorliegenden Versionsangaben wird
deutlich, dass es Unterschiede in den Build- und Update-Nummern gibt. Die Build-Nummer von
Windows Vista (RTM) ist 6000 und von Windows Server 2008 und Windows Vista SP1 ist es 6001.
Die Build-Nummer des Windows Installers 4.5 wurde dieser Vorgabe entsprechend bernommen. Das
Update-Feld basiert auf der Revision-Nummer des Betriebssystems. Das Redistributionspaket des
Windows Installers 4.5 kann auf unterschiedlichen Betriebssystemen installiert werden, so dass diese
Pakete auch von unterschiedlichen Softwarezweigen (Windows Servicing Branches) erzeugt werden,
die letztlich unterschiedliche Revisionsnummern aufweisen. Wichtig ist hierbei jedoch, dass die
unterschiedlichen Versionsbezeichnungen keinen Einfluss auf die Funktionalitt des Windows
Installers 4.5 haben.
Wie jede Version des Windows Installers wurde auch der Windows Installer 4.5 um neue
Funktionalitten ergnzt, bestehende Funktionalitten wurden verndert oder optimiert und
problematische Implementierungen wurden berarbeitet. Hier sei zu erwhnen, dass der Windows
Installer 4.5 auf der Version 4.0 (4.0.6001.18000) aufbaut, die mit Windows Server 2008 und
Windows Vista SP1 ausgeliefert wurde. Die in dieser Version beseitigten Probleme sind somit im
Windows Installer 4.5 ebenfalls nicht anzutreffen. Zustzlich wurden noch die folgenden Szenarien
adressiert:
Der Windows Installer-Service verfgte nicht ber das Privileg SeBackupPrivilege, so dass
Problem in benutzerdefinierten Aktionen auftraten, die dieses Privileg bentigten.
Die fehlerhafte Identifikation von Betriebssystemdiensten whrend der Aktion InstallValidate
fhrte zu unntigen Meldungen vom Typ Dateien in Verwendung in Windows Vista. Die
Ursache hierfr waren Zeichenfolgenvergleiche, bei denen die Gro- und Kleinschreibung nicht
oder nicht vollstndig bercksichtigt wurde.
Wurde ein Update deinstalliert, dass ursprnglich eine neue Komponente hinzugefgt hat, wird
diese Komponente ebenfalls deinstalliert. Dieses Verhalten tritt auch auf, wenn die Komponente
von mehreren Produkten gemeinsam verwendet wird.
Die Windows Installer-Version 4.5 wurde nicht nur zur Behebung von Bugs entwickelt, sondern
natrlich auch um neue Funktionalitten und Methoden bereit zustellen. Die folgende Auflistung zeigt
diese neu hinzugefgten oder optimierten Funktionalitten gegenber der Windows Installer Version
4.0.
Neue Funktionen
MsiBeginTransaction()
MsiEndTransaction()
MsiJoinTransaction()
321
Kapitel 8
Neue Callback-Funktionen
EmbeddedUIHandler
InitializeEmbeddedUI
ShutdownEmbeddedUI
Neue Eigenschaften
MSIDISABLEEEUI
MSIUNINSTALLSUPERSEDEDCOMPONENTS
Neue Datenbanktabellen
MsiEmbeddedChainer
MsiEmbeddedUI
MsiPackageCertificate
Genderte Datenbanktabellen
In der Spalte Attributes der Tabelle Component knnen nun die Attribute
msidbComponentAttributesUninstallOnSupersedence
oder
msidbComponentAttributesShared
verwendet werden.
Die Tabelle CustomAction wurde um die Spalte ExtendedType erweitert.
Neue Benutzerdefinierte Aktionen
Die benutzerdefinierten Aktionen wurden um eine Aktion ergnzt, die bei der Deinstallation eines
Patches ausgefhrt wird (msidbCustomActionTypePatchUninstall).
Neue Systemrichtlinien
DisableSharedComponent
MsiDisableEmbeddedUI
Neue oder erweiterte berprfungsmethoden (ICE - Internal Consistency Evaluators)
ICE39 gibt eine Warnung aus, falls die Tabelle MsiPackageCertificate ber Eintrge verfgt und
das Paket als UAC-Konform eingestuft wurde.
ICE92
stellt
sicher,
dass
fr
eine
Komponente
nicht
die
Attribute
msidbComponentAttributesPermanent und msidbComponentAttributesUninstallOnSupersedence
gemeinsam verwendet werden.
ICE100 prft die ordnungsgeme Verwendung der Tabellen MsiEmbeddedUI und
MsiEmbeddedChainer.
Die dargestellten neuen Funktionalitten lassen sich thematisch gruppieren, so dass sie in den nchsten
drei Kapiteln dieses Buches betrachtet werden. Begonnen wird hierbei mit der Thematik der
paketbergreifenden Transaktionen. Im folgenden Kapitel geht es dann um externe
Benutzeroberflchen und die hierauf basierenden Neuerungen im Installer 4.5. Das abschlieende
Kapitel befasst sich allgemein ausgedrckt mit Windows Installer-Patches und hierbei mit den
Verbesserungen im Servicemodell.
322
Kapitel 8

Die Softwareinstallation hat sich seit Erscheinen des Windows Installers im Jahre 1999 gravierend
gendert. Zum damaligen Zeitpunkt waren monolithische Anwendungen stark verbreitet, so dass zur
Installation groe komplexe Installationspakete verwendet wurden. Hieraus ergab sich die bis heute
gltige Anwendungsstrategie des Windows Installers, die mit One-Package-One-Product
umschrieben wird. Diese Strategie besagt, dass ein Produkt durch ein Windows Installer-Paket
dargestellt wurde, also zur Installation eines Produktes wurde ein Paket verwendet.
Schon seit einiger Zeit sind neue Trends in der Softwareinstallation zu verzeichnen. Ein Produkt
besteht nicht mehr nur aus einem Paket, sondern aus einer Vielzahl von Paketen, die auch als MikroPakete (Micro-Packages) bezeichnet werden. Mikro-Pakete sind an dieser Stelle sehr vielschichtig
darzustellen. Microsoft Office 2007 ist unterteilt in mehr als 30 einzelne Windows Installer-Pakete, die
funktional, technisch und sprachspezifisch aufgeteilt wurden. Eine andere Art von Mikro-Pakete findet
sich bei der Installation von erforderlichen Komponenten (Prerequisites), also bei unbedingt bentigten
Technologien oder Produkten. So muss beispielsweise das Microsoft .NET Framework auf dem
System vorhanden sein, falls eine .NET-Anwendung ausgefhrt werden soll oder ein DatenbankServer muss vorhanden sein, falls im Rahmen der Installation entsprechende Datenbanken anzulegen
sind. Die Problematik ergibt sich nun daraus, dass fr diese erforderlichen Komponenten
Installationspakete angeboten werden, die auf der Windows Installer-Technologie basieren. Dieser an
und fr sich sehr positive Aspekt erfhrt einen negativen Beigeschmack aus der Einschrnkung der
Windows Installer-Technologie, dass nur eine Installations-Sitzung gleichzeitig ausgefhrt werden
kann. Das bedeutet, dass von dem Server-Prozess nur eine Instanz gestartet werden kann. Bei dem
Server-Prozess handelt es sich jedoch um die eigentliche Arbeitsinstanz in der Windows InstallerTechnologie, die also fr die Installation zwingend erforderlich ist. Dadurch dass nur eine Instanz
gleichzeitig ausgefhrt werden kann, ist es natrlich auch nicht mglich aus einer Installation eine
andere Installation zu starten.
Die bisherigen technischen Anstze zur Realsierung solcher Szenarien waren und sind Konkurrierende
Installationen, Mergemodule, Bootstrapp-Anwendungen und Chainer.
Als konkurrierende oder eingebettete Installation (Nested Installations) wird eine benutzerdefinierte
Aktion bezeichnet, die die Installation eines weiteren Windows Installer-Paketes innerhalb der
aktuellen Installationssession ausfhrt. Das Installationspaket kann hierzu als separate Datei vorliegen
oder in den Speicherbereich des primren Paket integriert werden. Es ist ebenfalls mglich, ein bereits
angekndigtes Produkt ber diesen Mechanismus zu installieren.
Eine konkurrierende Installation verwendet die identischen Einstellungen zur Darstellung der
Benutzeroberflche und fr die Protokollierung wie die Hauptinstallation. Die automatische Ermittlung
des Speicherbedarfs fr diese Installationsart ist jedoch nicht mglich. Um den Speicherbedarf
trotzdem zu bercksichtigen, ist der Bedarf der eingebetteten Installation in die Tabelle ReserveCost
der Hauptinstallation aufzunehmen. Um die eingebettete Installation auszufhren, ist eine
benutzerdefinierte
Aktion
vom
Typ
7
(msidbCustomActionTypeInstall
+
msidbCustomActionTypeBinaryData),
23
+
msidbCustomActionTypeSourceFile)
oder
39
+
msidbCustomActionTypeDirectory) zu verwenden. Diese Aktion muss zwischen den Standardaktionen
InstallInitialize und InstallFinalize der Ausfhrungssequenz aufgerufen werden. Im Rahmen der
323
Kapitel 8
Skripterstellung werden die Rollback-Informationen beider Installationen kombiniert, und im

Fehlerfall zusammenhngend ausgefhrt. Bei der Ausfhrung der eingebetteten Installation werden
vom Windows Installer alle Installationsaufgaben der Hauptinstallation unterbrochen bis die
eingebettete Installation abgeschlossen ist. In einem Beispiel wird eine konkurrierende Installation
durch eine benutzerdefinierte Aktion mit der Bezeichnung InstallNested ausgefhrt, wodurch die
folgenden Protokolleintrge erzeugt werden.
MSI (s) (FC:24) [17:46:27:389]: Doing action: InstallNested
Property(N): ParentProductCode = {51788867-B808-4A0E-8C7A-06FB2109FACA}

Property(N): ParentOriginalDatabase = \\eagle\setups\master.msi
Action ended 17:46:27: InstallNested. Return value 1.
ber die Rckgabewerte der benutzerdefinierten Aktion, kann der Installationserfolg ermittelt werden.
Wird eine benutzerdefinierte Aktion erfolgreich ausgefhrt, so wir sie im Protokoll mit dem
Rckgabewert 1 gekennzeichnet, wie dies auch im vorherigen Protokoll dargestellt wird. Weitere
interessante Eintragungen, die auf eine konkurrierende Installation hinweisen, finden sich in der
Eigenschaftsauflistung. Markant ist hierbei der verwendete Prfix Property(N), denn das N steht
fr Nested, so dass hiermit Eigenschaften der eingebetteten Installation gekennzeichnet werden. Im
Weiteren finden sich dort auch die Eigenschaften ParentProductCode und ParentOriginalDatabase,
die Informationen zu dem aufrufenden Installationspaket enthalten.
Die Verwendung von eingebetteten Installationen wird erst seit der Version 1.1 des Windows Installers
untersttzt. Der Grund hierfr liegt in der Untersttzung von Major-Upgrades seit dieser Version. Die
Deinstallation eines Produktes im Rahmen eines Major-Upgrades wird durch eine eingebettete
Installation realisiert. In einem solchen Anwendungsszenario knnen eingebettete Installationen
ausgesprochen zuverlssig verwendet werden. Von der Verwendung in anderen Szenarien muss
ausdrcklich abgeraten werden, da die folgenden Probleme einem effektiven Einsatz im produktiven
Umfeld entgegenstehen.
Die Aktualisierung von Produkten die durch konkurrierende Installationen dem System
hinzugefgt wurden, ist nicht mglich. Eine Aktualisierung ist nur durch ein Update des
Basisproduktes mglich. Windows Installer-Patches knnen ebenfalls nicht auf diese Installationen
angewendet werden.
Konkurrierende Installationen werden in den Konfigurationsdaten des Basisproduktes gespeichert.
Die Deinstallation eines Produktes, das im Rahmen einer solchen Installation dem System
hinzugefgt wurde, ist nur durch die Deinstallation des Basisproduktes mglich.
Die bedarfsgesteuerte Installation von Ressourcen des eingebetteten Paketes funktioniert nicht
zuverlssig.
Die Anzeige zur Kennzeichnung des Installationsfortschritts funktioniert nicht mit konkurrierenden
Installationen. Das bedeutet, dass die Fortschrittsanzeige whrend der eingebetteten Installation
sich nicht verndert. Erst wenn die Hauptinstallation weiter ausgefhrt wird, wird die
Fortschrittsanzeige wieder aktualisiert.
Eine konkurrierende Installation funktioniert innerhalb einer administrativen Installation nicht wie
erwartet und kann zu ernsthaften Problemen fhren. Normalerweise wird erwartet, dass in einem
solchen Szenario von der eingebetteten Installation ebenfalls ein administratives Image erzeugt
wird. Das ist nicht der Fall. Wird die benutzerdefinierte Aktion allerdings in der Tabelle
324
Kapitel 8
AdminExecuteSequence aufgerufen, wird das eingebettete Produkt physisch installiert. Die

Problematik liegt nun begrndet, dass die konkurrierenden Installationen in den
Konfigurationsdaten des Basisproduktes gespeichert werden. Bei einer administrativen Installation
erfolgt jedoch keine Registrierung des Produktes. Das eingebettete Produkt wird somit einem
Basisprodukt zugeordnet, das gar nicht installiert wurde. Ein nicht installiertes Produkt kann auch
nicht deinstalliert werden, so dass die eingebettete Installation nur durch manuelle Eingriffe
entfernt werden kann.
Es ist erkennbar, dass die Verwendung von konkurrierenden Installationen zur Umsetzung des
Anwendungsszenarios fr Mikro-Pakete nicht wirklich geeignet ist. Vielmehr ist es sogar ein Versto
gegen die Richtlinie 2.10, die bei der Erlangung des Logos Certified for Windows Vista eingehalten
werden muss. Die gravierendsten Probleme liegen jedoch in den dargestellten Einschrnkungen im
produktiven Umfeld. Aus diesem Grund sollte jedes Installationspaket so gekennzeichnet werden, dass
die Verwendung innerhalb einer konkurrierenden Installation verhindert wird. Dieses wird erreicht,
indem die Eigenschaft ParentProductCode oder ParentOriginalDatabase in der Tabelle
LaunchCondition geprft wird, wie das im folgenden Auszug aus einem Windows Installer-XMLDokument verdeutlicht wird:
<Condition Message ='Die Verwendung dieses Installationspaketes als Konkurrierende Installation wird
nicht untersttzt.'>Not ParentProductCode</Condition>
Die Probleme und Einschrnkungen mit und durch konkurrierende Installationen berwiegen und
stehen somit im Widerspruch zu dem erwarteten Erfolg. Darber hinaus verstoen diese
Installationsarten auch gegen Best Practices und Richtlinien zur Zertifizierung der Software. Auch
wenn die Erlangung einer entsprechenden Zertifizierung nicht angestrebt wird, sollte die Qualitt des
Installationspaketes immer die hchste Prioritt aufweisen. Durch Verwendung von Szenarien und
Methoden von denen in entsprechenden Richtlinien abgeraten wird, lsst sich dieses Ziel nicht
erreichen.
Wichtig Beginn
Bei den konkurrierenden Installationen handelt es sich um eine veraltete Funktionalitt, deren
Verwendung nicht mehr empfohlen wird.
Wichtig Ende
Mergemodule
Mergemodule stellen dem Entwickler die bentigte Funktionalitt bereit, um gemeinsam verwendete
Ressourcen und Installationsprozesse zu kapseln und diese whrend des Entwicklungsprozesses in die
entsprechenden Windows Installer-Pakete zu integrieren. Zu diesem Zweck knnen individuelle
Mergemodule entwickelt oder auf bestehende Module anderer Hersteller zurckgegriffen werden. Bei
einem Mergemodul handelt es sich im Wesentlichen um eine Windows Installer-Datei, die jedoch
hinsichtlich der Implementierung eingeschrnkt ist. Mergemodule sind Hilfsmittel fr den Entwickler
und knnen somit nicht separat installiert werden, sondern stellen Informationen bereit, die zum
Zeitpunkt der Entwicklung in das Basispaket bernommen werden. Nachdem diese Informationen in
das Basispaket integriert wurden, wird das Mergemodul nicht weiter bentigt und braucht somit auch
nicht mit dem Installationspaket ausgeliefert werden. Einen schematischen Ablauf der Integration des
Mergemoduls zeigt Abbildung 8.65.
325
Kapitel 8
Abbildung 8.65: Integration eines Mergemoduls in ein Windows Installer-Paket
Aus dieser grob gefassten Erluterung zu den Mergemodulen wird deutlich, dass die Umsetzung des
geforderten Szenarios auf einem vllig anderen Ansatz basiert. Bisher wurde von Mikro-Paketen
gesprochen, also um eigenstndige Installationspakete, die sequentiell dem System hinzugefgt
wurden. Auch wenn dieses im Rahmen einer konkurrierenden Installation erfolgte, handelte es sich
immer um unterschiedliche Produkte. Mit Mergemodulen ndert sich diese Vorgehensweise, denn es
handelt sich hierbei primr um Hilfsmittel fr den Entwickler von Installationspaketen, mit denen die
Implementierung von mehrfach verwendeten Komponenten vereinfacht wird. Ein Mergemodul kann
nicht direkt installiert werden, sondern muss bereits whrend des Erstellungsprozesses in die Windows
Installer-Datenbank integriert werden. Hieraus ergibt sich auch das finale Bild. Alle Komponenten
befinden sich physisch in einem Installationspaket. Es wird auch nur ein Produkt letztlich installiert
und Aktualisierungen betreffen immer dieses eine Produkt. Die Aktualisierung ist hierbei ein ganz
entscheidender Punkt, falls Mergemodule von anderen Softwareherstellern verwendet werden. Die
gravierende Problematik ergibt sich hierbei aus der Verfgbarkeit und der Aktualisierungsmglichkeit
der enthaltenen Ressourcen.
Microsoft hat frher eine Vielzahl von Technologien in Form von Mergemodulen zur Verfgung
gestellt, so auch die Microsoft SQL Server 2000 Desktop Engine (MSDE). Diese Mergemodule wurden
von vielen Softwareherstellern in das eigene Setup integriert, so dass bei der Installation der eigenen
Anwendung auch der Datenbankserver mit installiert wurde. Es ist bekannt, dass damals der SQLSlammer-Virus bestimmte Teile der MSDE angegriffen hat. Microsoft hat an dieser Stelle sehr schnell
reagiert und entsprechende Updates in Form von Windows Installer-Patches fr dieses Produkt
herausgegeben. Doch hier kam es zum gravierenden Problem. Die Patches knnen nur auf die von
Microsoft gelieferte Installation der MSDE angewendet werden die Patches konnten logischerweise
nicht auf die Produkte angewendet werden, die die MSDE mit installiert haben (integrierte
Mergemodule). Das heit der Softwarehersteller musste zunchst ein eigenes Aktualisierungspaket
326
Kapitel 8
erstellen und dieses an seine Kunden verteilen. Hieraus ergaben sich die folgenden Problemfaktoren:
Es handelte sich um einen Security-Fix, der sehr schnell verteilt werden musste. Dadurch dass
der/die Softwarehersteller erst eigene Aktualisierungspakete erstellen mussten, wurde sehr viel Zeit
verloren.
Einige Softwarehersteller existierten nicht mehr, so dass keine Aktualisierungspakete erstellt und
verteilt wurden. Eine Aktualisierung der MSDE war somit nicht oder nur mit groen
Anstrengungen mglich.
Microsoft hat sich daher entschlossen keine komplexen Anwendungen mehr in Form von
Mergemodulen zur Verfgung zu stellen, sondern diese als vollstndige Installationspakete bereit zu
stellen, wie das derzeitig beispielsweise beim SQL Server 2005 Express Edition oder dem Microsoft
.NET Framework praktiziert wird.
Es sollte erkennbar sein, dass die Verwendung von Mergemodulen problematisch sein kann aber nicht
zwangslufig sein muss. Werden eigene Mergemodule entwickelt und verwendet, so ist diese
Vorgehensweise beizubehalten, da die aufgezeigten Problemflle nicht zutreffen.
Wichtig Beginn
Anwendungen sollten nicht auf Mergemodule zur Installation von Komponenten basieren, wenn der
Hersteller des verwendeten Mergemoduls und der Anwendung unterschiedlich sind.
Wichtig Ende
Bootstrapper
In den vorherigen Abschnitten wurden die konkurrierenden Installationen und die Mergemodule
hinsichtlich der Verwendung in Installationsszenarien mit Mikro-Paketen betrachtet. Die Ergebnisse
waren ernchternd, eine zufriedenstellende Lsung mit diesen Technologien ist nicht erreichbar. Die
Problematik beider Lsungsanstze lag darin, dass die installierten Produkte nicht getrennt betrachtet,
deinstalliert und aktualisiert werden knnen. Die Voraussetzung hierfr wre eine sequentielle und
unabhngige Installation der betroffenen Produkte, was allerdings mit den Bordmitteln des Windows
Installers nicht umsetzbar ist. Der Lsungsansatz muss somit auerhalb des Windows Installers
gesucht werden. An dieser Stelle gibt es eine Vielzahl von Mglichkeiten, die immer im
Zusammenhang mit der Komplexitt und dem Umfang der zu installierenden Produkte und dem
Anforderungsprofil stehen mssen. Im einfachsten Fall reicht hier eine Batch-Datei aus, die
nacheinander die einzelnen Installationen aufruft. Die Frage nach dem Erreichen des
Anforderungsprofil und letztlich der einzusetzenden Technik kann nur individuell beantwortet werden,
wobei die folgenden Fragestellungen weiterhelfen knnten:
Fr welche Technologien ist das entsprechende Know-How vorhanden oder kann sich angeeignet
werden?
Was soll mit den bereits installierten Produkten geschehen, wenn die Installation eines spteren
Produktes fehlschlgt?
Wie ist mit Computerneustarts zu verfahren?
Ist eine Logik erforderlich, die berprft, ob das jeweilige Produkt schon vorhanden ist und falls
das der Fall ist, wie damit umzugehen ist?
Unabhngig von der letztlich zu verwendenden Technologie und der tatschlichen Implementierung ist
das Ergebnis immer eine externe Anwendung, die als Bootstrapper bezeichnet wird. Die Erstellung
einer solchen Anwendung kann natrlich individuell durchgefhrt werden, was jedoch hufig sehr
327
Kapitel 8
aufwendig und unter Umstnden auch fehleranfllig ist. Einfacher und eleganter ist es auf bereits
bestehende Funktionalitten zurckzugreifen, wie sie von Visual Studio 2005 und 2008 zur Verfgung
gestellt werden. Hiermit ist es im Rahmen der Setup- und Bereitstellungsprojekte mglich, whrend
des Buildprozesses einen entsprechenden Bootstrapper erstellen zu lassen, wie dieses auch in
Abbildung 8.66 gezeigt wird.
Abbildung 8.66: Manuelles Erstellen eines Bootstrappers mit Visual Studio 2008
Bei der Erzeugung eines solchen Bootstrappers ber die Benutzeroberflche von Visual Studio muss
zunchst ein Setup- oder Bereitstellungsprojekt angelegt oder geffnet werden. Bei der Erstellung des
Bootstrappers wird letztlich die durch das Setup-Projekt erzeugte Windows Installer-Datei als
Anwendungsdatei verwendet. Das bedeutet, dass diese Datei gestartet wird, wenn die erforderlichen
Systemvoraussetzungen geschaffen wurden. Diese Vorgehensweise ist einfach aber mitunter nicht
zielfhrend, da vielfach bereits Installationspakete existieren, die als Anwendungsdatei zu
referenzieren sind.
Die dargestellte Implementierung lsst sich dennoch fr eigene Projekte nutzen, da die Erstellung der
Bootstrapper-Datei auch ber die Microsoft Build Engine (msbuild.exe) durchgefhrt werden kann. Ein
sehr schner Nebeneffekt wird hiermit auch noch erreicht, da die Erstellung des Bootstrappers nun im
Rahmen eines automatisierten Buildprozesses erfolgen kann. Grundlage hierfr ist eine Projektdatei, in
der die Installations- und Ausfhrungsoptionen definiert werden. Listing 8.74 zeigt eine Projektdatei,
durch die ein Bootstrapper erzeugt wird, der die Existenz des Microsoft .NET Frameworks 3.5
voraussetzt und das Windows Installer-Paket setup.msi aufruft.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<ItemGroup>
<BootstrapperFile Include="Microsoft.Net.Framework.3.5">
<ProductName>.NET Framework 3.5</ProductName>
</BootstrapperFile>
</ItemGroup>
328
Kapitel 8
<Target Name="Bootstrapper">
<GenerateBootstrapper
ApplicationFile="Setup.msi"
ApplicationName="Colors 1.0"
BootstrapperItems="@(BootstrapperFile)"
OutputPath=".\"
ComponentsLocation="HomeSite"
Culture="de"
/>
</Target>
</Project>
Listing 8.74: Projektdatei zur Erzeugung eines Bootstrappers mit MSBuild.
In dem Listing ist sehr gut zu erkennen, dass als Installationsvoraussetzung das Microsoft .NET
Framework
3.5
festgelegt
wurde.
Interessant
ist
hierbei
die
Zeichenfolge
Microsoft.Net.Framework.3.5, die durch das Attribut Include definiert wurde. Hierbei handelt es
sich um den Produktschlssel des zu installierenden Produktes. Zum besseren Verstndnis betrachten
Sie das folgende Verzeichnis:
Visual Studio 2008: %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\Bootstrapper
Visual Studio 2005: %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper
Im Verzeichnis Packages finden Sie Unterverzeichnisse in denen sich die Installationspakete befinden,
die als Systemvoraussetzungen installiert werden knnen. In jedem dieser Unterverzeichnisse befindet
sich eine Datei mit der Bezeichnung product.xml. Diese Datei spezifiziert letztlich das zu installierende
Produkt. Enthalten sind allgemeine Informationen, Identifizierungsangaben, abhngige Produkte und
Prfroutinen zur Ermittlung ob das Produkt bereits vorhanden ist. Relevant ist zunchst das Attribut
ProductCode des Elementes Product. Hierbei handelt es sich um den Produktschlssel, der auch in der
Projektdatei zur Erzeugung des Bootstrappers zu verwenden ist. Weiterhin relevant ist das Attribut
ApplicationFile. Hiermit wird das Installationspaket oder die Anwendung definiert, die gestartet
werden soll, wenn alle erforderlichen Komponenten installiert wurden. Diese Angabe ist jedoch
optional. Es ist somit auch mglich einen Bootstrapper zu erstellen, der ausschlielich die
Systemvoraussetzungen installiert. Die Liste der mglichen Attribute der Projektdatei ist in Tabelle
8.65 zusammengefasst.
Parameter
Beschreibung
ApplicationFile
Gibt die Datei an, die der Bootstrapper aufruft, nachdem die Installation aller
Vorbedingungen abgeschlossen wurde. Ein Fehler im Buildprozess ergibt sich, wenn
weder der Parameter BootstrapperItems noch ApplicationFile angegeben wurde.
ApplicationName
Gibt den Namen der Anwendung an, die der Bootstrapper installiert. Dieser Name wird
in der Benutzeroberflche angezeigt, die der Bootstrapper whrend der Installation
verwendet.
ApplicationUrl
Gibt den Webspeicherort an, an dem sich der Installer der Anwendung befindet.
BootstrapperItems
Gibt die Produkte an, die in den Bootstrapper integriert werden sollen. Die an diesen
Parameter bergebenen Elemente sollten die folgende Syntax haben:
<BootstrapperItem
Include=ProductCode>
<ProductName>
329
Kapitel 8
ProductName
</ProductName>
</BootstrapperItem>
Das Attribut Include wird verwendet, um den Namen einer Vorbedingung darzustellen,
die installiert werden sollte. Die Metadaten des Elements ProductName sind optional
und werden als benutzerfreundlicher Name fr den Fall verwendet, dass das Paket nicht
gefunden werden kann. Diese Elemente sind keine erforderlichen Eingabeparameter,
sofern ein ApplicationFile angegeben wird. Ein Fehler im Buildprozess ergibt sich,
wenn weder der Parameter BootstrapperItems noch ApplicationFile angegeben wurde.
ComponentsLocation
Gibt einen Speicherort an, an dem der Bootstrapper nach zu installierenden

Installationsvorbedingungen sucht. Dieser Parameter kann die folgenden Werte
aufweisen:
HomeSite: Gibt an, dass die Vorbedingung vom Komponentenanbieter gehostet wird.
Relative: Gibt an, dass die Vorbedingung sich am Speicherort der Anwendung befindet.
Absolute: Gibt an, dass sich alle Komponenten bei einem zentralisierten URL befinden.
Dieser Wert ist in Verbindung mit dem Parameter ComponentsUrl zu verwenden.
Wenn ComponentsLocation nicht angegeben ist, wird standardmig HomeSite
verwendet.
ComponentsUrl
Gibt die URL an, an der sich die Installationspakete der erforderlichen Komponenten
befinden.
Culture
Gibt die Kultur an, die fr die Bootstrapper-Benutzeroberflche und die

Installationsvorbedingungen verwendet werden soll. Wenn die angegebene Kultur nicht
verfgbar ist, wird der Wert des Parameters FallbackCulture verwendet.
FallbackCulture
Gibt die sekundre Kultur an, die fr die Bootstrapper-Benutzeroberflche und die
Installationsvorbedingungen verwendet werden soll.
OutputPath
Gibt den Speicherort an, an den die setup.exe und alle Paketdateien kopiert werden
sollen.
Path
Gibt den Speicherort fr alle verfgbaren Vorbedingungspakete an.
SupportUrl
Gibt die URL an, die ausgegeben werden soll, wenn die Installation des Bootstrappers
fehlschlgt.
Validate
Bei True fhrt der Bootstrapper XSD-Validierung fr die angegebenen EingabeBootstrapperelemente aus. Der Standardwert dieses Parameters ist False.
Tabelle 8.65: Mgliche Parameter zur Erzeugung eines Bootstrappers
In Visual Studio 2008 sind bereits einige Installationsoptionen enthalten, die mit Hilfe der
beschriebenen Vorgehensweisen als Systemvoraussetzungen verwendet werden knnen. Hierbei ist
natrlich zu beachten, dass der Umfang der Installationsoptionen von der verwendeten Edition von
Visual Studio und der Plattformarchitektur abhngig ist. Wurde Visual Studio Team System 2008 auf
einer x64 Plattform installiert sind die folgenden Installationsoptionen verfgbar.
Microsoft .NET Framework 2.0 (x86)
Microsoft .Net Framework 3.0 (x86)
Microsoft .Net Framework 3.5
330
Kapitel 8
Microsoft Visual Studio 2008 Report Viewer

SQL Server 2005 Express Edition SP2 (x86)
Visual C++ Runtime Libraries (x86)
Visual C++ Runtime Libraries (x64)
Visual Studio Tools for the Office system 3.0 Runtime
Es ist natrlich mglich eigene Installationspakete zu erstellen, die als Systemvoraussetzungen
verwendet und installiert werden knnen. Um ein solches Komponentenpaket zu erstellen, mssen
folgende Dateien verfgbar sein:
Die verteilbare Komponente in Form einer EXE- oder MSI-Datei.
Das Produktmanifest (product.xml), in dem alle sprachneutralen Metadaten fr das Paket definiert
wurden. Es enthlt somit Metadaten, die fr alle lokalisierten Versionen der verteilbaren
Komponente identisch sind.
Das Paketmanifest (package.xml), das sprachspezifische Metadaten und in der Regel auch
lokalisierte Fehlermeldungen enthlt. Eine Komponente bentigt fr jede lokalisierte Version
dieser Komponente mindestens ein Paketmanifest.
Die Manifestdateien mssen manuell erstellt werden, und die darin enthaltenen Metadaten mssen dem
Schema der Paketschemaelemente des .NET Framework SDK entsprechen. Abhngigkeiten zwischen
Paketen in diesen Manifesten werden mit dem Element DependsOnProduct festgelegt. Sie mssen die
Produkt- und Paketmanifestdateien zusammen mit den verteilbaren Dateien in den bereits oben
aufgefhrten Ordner kopieren, den Visual Studio fr verteilbare Pakete reserviert hat. Jede verteilbare
Komponente wird unter dem Paketverzeichnis in einem eigenen Unterordner abgelegt. Das
Produktmanifest und die verteilbare Dateien werden dann in diesen Unterordner eingefgt. Lokalisierte
Versionen der Komponente werden zusammen mit den Paketmanifesten in Unterordnern eingefgt und
entsprechend dem Kulturnamen benannt. Sobald diese Dateien in den Bootstrapper-Ordner kopiert
wurden, werden sie automatisch im Visual Studio-Dialog angezeigt und knnen auch ber die
Microsoft Build Engine verwendet werden.
Zum besseren Verstndnis soll ein kleines Beispiel dienen. In Listing 8.74 wurde fr die Anwendung
Colors 1.0 das Microsoft .NET Framework 3.5 als Systemvoraussetzung definiert. Dieses soll nun in
der Form abgewandelt werde, dass ein individuelles Installationspaket als Voraussetzung definiert
werden soll. Zunchst ist hierzu das Produktmanifest zu erstellen. Hierbei handelt es sich um eine
XML-Datei, die in Listing 8.75 dargestellt wird.
<Product ProductCode="Custom.Redist.2.0" xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper">
<PackageFiles CopyAllPackageFiles="false">
<PackageFile Name="custom.msi" />
</PackageFiles>
<RelatedProducts>
<DependsOnProduct Code="Microsoft.Net.Framework.3.5" />
<DependsOnProduct Code="Microsoft.Windows.Installer.3.1" />
</RelatedProducts>
<InstallChecks>
<MsiProductCheck Property="CustomRedistInstalled" Product="{C317348F-7F33-4C08-BD8C-3C9250BA658F}" />
331
Kapitel 8
</InstallChecks>
<Commands Reboot="Defer">
<Command PackageFile="custom.msi" EstimatedInstallSeconds="10" >
<InstallConditions>
<BypassIf Property="CustomRedistInstalled" Compare="ValueGreaterThanOrEqualTo" Value="3" />
<FailIf Property="AdminUser" Compare="ValueEqualTo" Value="False" String="AdminRequired" />
</InstallConditions>
<ExitCodes>
<ExitCode Value="0" Result="Success" />
<ExitCode Value="3010" Result="SuccessReboot" />
<DefaultExitCode Result="Fail" String="GeneralFailure" FormatMessageFromSystem="true" />
</ExitCodes>
</Command>
</Commands>
</Product>
Listing 8.75: Produktmanifest zur Verwendung eines individuellen Komponenten-Setups
Zunchst ist hierbei der Productcode Custom.Redist.2.0 relevant, denn dieser muss durch das
Attribut Include in der Bootstrapper-Projektdatei referenziert werden. Weiterhin ist erkennbar, dass
diese Komponente wiederum von den Komponenten Microsoft.Net.Framework.3.5 und
Microsoft.Windows.Installer.3.1 abhngig ist. Werden also in der Bootstrapper-Projektdatei diese
Abhngigkeiten nicht definiert, werden entsprechende Warnungen im Buildprozess angezeigt. uerst
interessant sind die Prfroutinen mit denen die Existenz der jeweiligen Systemvoraussetzung ermittelt
werden kann. Die berprfung kann hierzu auf Dateien, Eintrge der Systemregistrierung, installierte
Windows Installer-Produkte und Assemblies des Global Assembly Cache abzielen. Es ist ebenfalls
mglich, einen individuellen Prfalgorithmus zu verwenden, der sich dazu in einer externen Datei
befinden muss. In dem Beispiel handelt es sich um ein Windows Installer-Paket, wodurch eine
diesbezgliche berprfung am effektivsten ist. Hierzu sind der ProductCode des zu berprfenden
Produktes und eine individuelle Eigenschaft festzulegen. Durch den Bootstrapper wird letztlich die
Funktion MsiQueryProductState() fr dieses Produkt aufgerufen und das Ergebnis der definierten
Eigenschaft zugewiesen. Alle Wert <= 2 weisen hier auf einen Fehler bei der Ermittlung oder auf ein
nicht installiertes Produkt hin. In dem Manifest wurde deshalb eine berprfung auf einen Wert >= 3
durchgefhrt, so dass im positiven Fall, das Komponentenpaket vorhanden ist und nicht nochmals
installiert werden muss. Im negativen Fall ist dieses der Indikator fr den Bootstrapper, die
erforderliche Komponente zunchst zu installieren. Weiter Eintragungen im dem Produktmanifest
beziehen sich auf zustzliche Systemvoraussetzungen und auf Fehlermeldungen.
Bei der Verwendung von Visual Studio 2008 ist in das Verzeichnis %ProgramFiles%\Microsoft
SDKs\Windows\v6.0A\Bootstrapper\Packages zu wechseln und ein Unterordner beispielsweise mit der
Bezeichnung CustRedist_20 anzulegen. Bei Visual Studio 2005 ist der Ordner
%ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages\CustRedist_20
entsprechend zu verwenden. In diesen Ordner sind nun das Projektmanifest und das Installationspaket
abzulegen. Im Weiteren ist ein sprachspezifischer Unterordner anzulegen, in den das Paketmanifest
gespeichert wird. Diese Manifestdatei enthlt die lokalisierten Meldungstexte. Nun kann diese
Systemvoraussetzung in der Projektdatei des Bootstrappers referenziert und der Buildprozess gestartet
werden. Nach dem Aufruf der erzeugten setup.exe werden zunchst die Systemvoraussetzungen
geprft. Wird hier festgestellt, dass diese nicht erfllt sind, mssen sie zunchst installiert werden,
worauf der Dialog in Abbildung 8.67 hinweist.
332
Kapitel 8
Abbildung 8.67: Eine erforderliche Komponente muss zunchst installiert werden
Der so erzeugte Bootstrapper kann in vielen, aber nicht in allen Szenarien eingesetzt werden. Zur
Installation von erforderlichen Komponenten im Rahmen des Installationsprozesses leistet er sehr gute
Dienste. Allerdings sind komplexe Installationsszenarien hiermit nicht realisierbar, da kein
transaktionales Modell mit dem Bootstrapper erreicht wird.
Tipp Beginn
Die manuelle Erzeugung einer Projektdatei fr den Bootstrapper oder die Erzeugung der Projekt- und
Paketmanifestdatei knnen mitunter sehr komplexe Formen annehmen, so dass hierzu auf verfgbare
Tools wie den Bootstrapper Manifest-Generator ausgewichen werden kann.
Tipp Ende
Vom Bootstrapper zum Chainer

Wie im vorherigen Abschnitt beschrieben, handelt es sich bei einem Bootstrapper um eine externe
Anwendung zur sequentiellen Installation mehrerer Produkte. In diesem Zusammenhang wird auch
hufig der Begriff des Chainers als Synonym fr den Bootstrapper verwendet. Dieses ist jedoch
nicht richtig, denn zwischen den hiermit bezeichneten Technologien existieren garvierende
Unterschiede aber auch einige Gemeinsamkeiten.
Sowohl beim Bootstrapper als auch beim Chainer handelt es sich um eine externe Client-Anwendung,
die in Beziehung stehende Anwendungen nacheinander installiert. Ein Bootstrapper wird jedoch nur
zum Installationszeitpunkt bentigt und steht whrend der Lebensdauer des installierten Produktes
nicht mehr zur Verfgung. Betrachten Sie zum besseren Verstndnis den im vorherigen Abschnitt
(Listing 8.74) erzeugten Bootstrapper. Die primre Zielsetzung dieses Bootstrappers liegt in der
Installation der Anwendung Colors 1.0, die jedoch das Microsoft .NET Framework 3.5 bentigt.
Durch den Bootstrapper wird zunchst geprft, ob die bentigten Komponenten oder Technologien auf
dem System vorhanden sind. Falls das nicht der Fall ist, werden vor der Installation der Anwendung
Colors 1.0 zunchst die erforderlichen Komponenten installiert. Der Bootstrapper arbeitet hierbei
jedoch nicht transaktional, denn schlgt die Installation der Anwendung fehl, bleiben die bereits
installierten Komponenten auf dem System. Fr dieses Szenario sind das Verhalten und die damit
verbundene Einschrnkung durchaus akzeptabel, denn das Microsoft .NET Framework 3.5 wird von
einer Vielzahl anderer Anwendungen auch verwendet. Anders wre es, wenn die beiden
Installationspakete in direkten Zusammenhang stehen wrden wie das beispielsweise bei einer
Anwendung und dem zugehrigen Sprachpaket der Fall ist. Schlgt die Installation des Sprachpaketes
fehl, wrde trotzdem die Anwendung auf dem System verbleiben, was hierbei nicht gewollt sein kann.
Es wird deutlich, dass ein Bootstrapper durchaus seine Berechtigung hat, aber sehr hufig
333
Kapitel 8
transaktionale Installationsmodelle bevorzugt werden.

Eine weitere Einschrnkung des Bootstrappers liegt in der Verfgbarkeit, denn dieser wird nach
Abschluss der Installation nicht mehr bentigt und steht auch nicht mehr zur Verfgung. Nach der
Installation existieren in dem skizzierten Beispiel die Anwendung Colors 1.0 und das .NET
Framework 3.5 auf dem System. Zu diesem Zeitpunkt sind die im Bootstrapper definierten
Beziehungen nicht mehr verfgbar, wodurch das Produkt individuell konfiguriert werden kann. So
wre es mglich, das .NET Framework 3.5 zu deinstallieren, wodurch die Anwendung nicht mehr
funktionsfhig wre. Wird nun die Reparatur der Anwendung Colors 1.0 ausgefhrt, kann hiermit
das Problem nicht beseitigt werden, denn es wird das Anwendungsspezifische Installationsprogramm
aufgerufen und nicht der Bootstrapper.
Die Problematik ist erkennbar. Ein Bootstrapper wird bentigt um die Anwendung in einen lauffhigen
Zustand zu versetzen, er stellt jedoch die Lauffhigkeit nicht whrend der gesamten Lebensdauer der
Anwendung sicher. Anders ist es beim Chainer. Auch hierbei handelt es sich um eine separate
Anwendung, die mehrere miteinander in Beziehung stehende Anwendungen sequentiell installiert. Der
Chainer steht jedoch whrend der gesamten Lebensdauer des Produktes zur Verfgung, so dass die
definierten Beziehungen und Abhngigkeiten auch im Wartungsmodus, bei der Aktualisierung und der
Deinstallation bercksichtigt werden, wobei auch die Transaktionalitt eine entscheidende Rolle spielt.

Der gravierende architektonische Ansatz der Windows Installer-Technologie liegt in der Verwendung
unterschiedlicher Prozesse fr spezifische Aufgaben. Der Server-Prozess ist der Baustein, der die
eigentlichen Installationsaufgaben ausfhrt. Hierzu verwendet er die Informationen des Windows
Installer-Paketes. Zustzlich findet im Rahmen des Installationsprozesses eine intensive
Kommunikation mit dem Benutzer statt, um weitere Daten dynamisch zu ermitteln. Das Starten einer
Installation ist gleich bedeutend mit dem Starten des Server-Prozesses, wozu der Client-Prozess den
Startschuss gibt. Ein wesentlicher Vorteil dieser Unterteilung liegt in der Austauschbarkeit des ClientProzesses. Wird beispielsweise ein Windows Installer-Paket doppelt angeklickt, so handelt es sich bei
der im Kontext des Benutzers ausgefhrten Instanz des Windows Installer-Prozesses (msiexec.exe) um
den verwendeten Client-Prozess. Dieser fungiert quasi als Schnittstelle zwischen Benutzer und ServerProzess, da er die Installationsoptionen an den Server-Prozess bermittelt und das Feedback des
Servers dem Benutzer prsentiert. Wird hingegen eine individuelle Anwendung verwendet, die den
Installationsprozess durch die Funktionen der Windows Installer-Programmierschnittstelle startet, so
wird diese Anwendung Client-Prozess bezeichnet. Wird eine bereits installierte Anwendung gestartet
und wird festgestellt, dass bestimmte Komponenten nicht vorhanden sind, wird eine automatische
Reparatur veranlasst. In diesem Fall fungiert die Windows-Shell als Windows Installer-Client, da sie
den Server-Prozess auffordert, die Reparatur durchzufhren. Zur Ermittlung des verwendeten Client ist
das Installationsprotokoll eine gute Hilfe, denn der Client-Prozess wird immer in der ersten Zeile
dargestellt.
=== Verbose logging started: 04.08.2008 17:00:53 Build type: SHIP UNICODE 4.05.6001.00
Calling process: C:\Windows\System32\msiexec.exe ===
Oder
=== Verbose logging started: 04.08.2008 17:01:14
Calling process: C:\Windows\Explorer.EXE ===
334
Build type: SHIP UNICODE 4.05.6001.00
Kapitel 8
Diese Austauschbarkeit des Clients ermglicht somit die Einbindung zweckgerichteter Anwendungen
und Technologien zur Durchfhrung von Installationen und Aktualisierungen auf Basis der Windows
Installer-Technologie. Prominente Beispiele fr diese Technologien sind die Software Verteilung ber
das Active Directory, Windows Update und der System Center Configuration Manager 2007.
Bei einem Chainer handelt es sich ebenfalls um eine zweckgerichtete Anwendung zur Steuerung einer
oder mehrerer Installationen. Im Vergleich zu den gerade aufgefhrten Technologien fehlt dem
Chainer der generische Ansatz, denn Chainer sind in der Regel hchst individuell aufgebaut. Das hat
damit zu tun, dass die primre Aufgabe des Chainer in der Verwaltung und Durchsetzung der
Beziehungen zwischen den einzelnen Elementen des Installationsproduktes liegt. Bildlich dargestellt
verwaltet der Chainer die Beziehungen zwischen Neutralen- und sprachspezifischen Paketen,
einzelnen Anwendungen innerhalb einer Produktsuite oder abhngigen Schichten im
Anwendungsmodell. Praktisch dargestellt wrde ein Chainer sicherstellen, dass sowohl der
sprachunabhngige Teil der Anwendung als auch der lokalisierte Teil auf dem System vorhanden sind.
Eine andere Aufgabe des Chainers knnte in der Verwaltung der Produktsuite liegen. Mgliche
Szenarien sind hierbei die Auswertung der Seriennummern und die darauf basierende
Zusammenstellung der Einzelanwendungen oder die Installation einer Trial-Version der Anwendung.
Die Zielsetzung muss jedoch nicht immer eine vollstndige Anwendung sein, sondern auch abhngige
Schichten wie beispielsweise Add-Ins knnen durch einen Chainer verwaltet werden. Durch die
Vielzahl der mglichen Installationsszenarien und der unterschiedlichen Zielsetzungen eines Chainers
knnen durchaus komplexe Implementierungsmodelle entstehen, wie auch Abbildung 8.68 zeigt.
Abbildung 8.68: Modell zur effizienten und zukunftsorientierten Aufteilung eines Produktes
Zur Darstellung der Komplexitt moderner und flexibler Anwendungsmodelle soll das in Abbildung
8.68 skizzierte Produkt dienen. Das Produkt besteht zunchst aus den beiden Anwendungen TextClient und Mail-Client. Jede dieser Anwendungen besteht aus einem sprachunabhngigen Paket
und einem lokalisierten Paket. Wie bei modernen Anwendungen blich, basieren die Anwendungen
auf einem oder mehreren Frameworks. Hierunter sind Komponenten zu verstehen, die
Basisfunktionalitten bereitstellen, die von mehreren Anwendungen verwendet werden. Auch hier gibt
es wieder sprachunabhngige und sprachspezifische Implementierungen, so dass sich die Anzahl der
erforderlichen Installationspakete vervielfacht.
Es wird aber deutlich, dass das bestehende Anwendungsmodell sehr einfach erweitert werden kann,
wobei die Ausdehnung dreidimensional erfolgt. Auf der vertikalen Ebene werden die einzelnen
335
Kapitel 8
Elemente hinsichtlich der Architektur unterteilt. Mgliche Erweiterungen knnten sich im

Datenbankumfeld, durch eine Datenschicht und eine Datenzugriffsschicht ergeben, aber auch
Anwendungserweiterungen durch Add-Ins lassen sich hiermit abbilden. Die horizontale Achse enthlt
die einzelnen Bestandteile der jeweiligen Produkt- oder Technologieebene. Auf Hhe der
Anwendungsschicht sind Erweiterungen durch neue Anwendungen mglich. Auf Ebene des
Frameworks oder der Laufzeitumgebung knnen Erweiterungen fr unterschiedliche System- oder
Prozessorarchitekturen angefgt werden. Die diagonale Achse kennzeichnet letztlich die
Sprachunterteilung. Begonnen mit einem sprachneutralen Paket, sind hier Erweiterungen fr jede
erdenkliche Sprache mglich.
Dieses einfache Schema soll verdeutlichen, dass heutige Installationsszenarien sehr komplex und
umfangreich sein knnen. Es soll aber auch zeigen, dass durch die Wahl eines geeigneten
Anwendungs- oder Architekturmodells sehr flexibel auf neue Anforderungen reagiert werden kann.
Das Wesentliche Element zur Realisierung solcher Installationsszenarien ist der Chainer, dem
zwangslufig ein schlssiges und durchdachtes Konzept zu Grunde liegen muss. Das bedeutet, dass bei
der Entwicklung ein mglichst generischer Ansatz verfolgt werden sollte, um hiermit die Flexibilitt
und Komplexitt des Produktes abzubilden. Wird dieser Ansatz nicht beachtetet, msste fr jede
Produktkombination ein eigener Chainer entwickelt werden. Hierdurch wrde der Vorteil durch die
Verwendung von Mikro-Paketen auf Anwendungsebene ad-absurdum gefhrt, denn die
Ressourceneinsparung msste in den Bau des Chainers investiert werden. Das bedeutet jedoch nicht,
dass mit aller Macht versucht werden sollte, einen generischen Chainer fr alle Produkte zu
verwenden. Dieses ist vermutlich auch gar nicht mglich, denn jedes Produkt verfgt ber hchst
individuelle Besonderheiten, die im Chainer abgebildet werden mssen. So ist es hchst
unwahrscheinlich, dass der Chainer vom Microsoft Office 2007 auch fr Microsoft Visual Studio 2008
oder Microsoft SQL Server 2008 verwendet werden kann. Zusammenfassend lsst sich hieraus
ableiten, dass der Chainer einen generischen Ansatz auf Ebene des Produktes, also beispielsweise
Microsoft Office 2007, verfolgen sollte. Hierunter ist zu verstehen, dass der Chainer alle mglichen
Kombinationen zur Installation des Produktes abdecken sollte, so dass keine Neuprogrammierung oder
Neukompilierung des Chainers erforderlich ist. Der Chainer sollte also beispielsweise in der Lage sein,
alle verfgbaren Editionen von Office 2007 in allen verfgbaren Sprachen zu installieren, ohne dass er
modifiziert oder neu kompiliert werden muss.
Es wird deutlich, dass ein Chainer mit diesen Merkmalen nicht mehr so nebenbei erstellt werden kann,
sondern dass hier ein schlssiges Konzept vorliegen muss und entsprechende Architekturberlegungen
angestellt werden mssen. Wichtig ist dieses auch in Bezug auf die Zukunftssicherheit des Produktes
und des Chainers. Vielfach sind zum Zeitpunkt der Entwicklung des Chainers noch nicht alle
mglichen Produkt- oder Technologiekombinationen verfgbar oder vorstellbar, so dass hier eine
variable Komponente zu integrieren ist.
In der Praxis haben sich Chainer bewhrt, die auf Grundlage eines Schichtenmodells entwickelt
wurden, wie dieses auch in Abbildung 8.69 gezeigt wird.
336
Kapitel 8
Abbildung 8.69: Schematischer Aufbau eines Chainers
Zur Benutzeroberflche sei anzumerken, dass hierunter eine paketbergreifende Implementierung zu

verstehen ist, mit der die Festlegung von Installationsoptionen und die Darstellung des
Installationsfortschritts zentral fr alle involvierten Pakete ermglicht wird. Die Funktionalitt und die
Gestaltung solcher Benutzeroberflchen sind komplex und setzen ein tiefes Verstndnis der
Darstellungsfunktionalitt des Windows Installers voraus. Aus diesem Grund werde ich an dieser
Stelle nicht nher darauf eingehen, sondern eine detaillierte Betrachtung im nchsten Kapitel dieses
Buches anstellen.
Zu den Beziehungen und Abhngigkeiten knnen keine generischen Aussagen getroffen werden, da
diese sehr stark von der verwendeten Technologie und der Gestaltung des Produktes abhngig sind.
Grundstzlich sind hiermit die Abhngigkeiten zwischen den Paketen gemeint, wie das auch in
Abbildung 8.68 ersichtlich wird. Es wird deutlich, dass die Anwendungen auf den jeweiligen
Frameworks oder Laufzeitumgebungen aufsetzen, so dass zur Ausfhrung der Anwendungen die
Frameworks erforderlich sind. Diese Schicht des Chainers muss somit sicherstellen, dass bei der
Auswahl einer der Anwendungen, auch die erforderlichen Komponenten, also die Frameworks mit
installiert werden. Letztlich ist es entscheidend eine geeignete Form zur Beschreibung der
Abhngigkeiten zu finden, die einfach konfiguriert werden kann. Betrachten wir an dieser Stelle
Microsoft Office 2007. Derzeitig existieren sieben Editionen dieses Produktes, die natrlich ber einen
unterschiedlichen Funktionsvorrat verfgen. Aus Sicht des Windows Installers bedeutet dieses, dass
unterschiedliche Kombinationen der zu installierenden Pakete zusammengestellt werden mssen.
Dieses ist natrlich die Aufgabe des Chainers, wobei dieser fr alle Editionen identisch ist. Die
Festlegung der Kombinationen fr die jeweilige Edition erfolgt idealerweise ber eine externe
Konfigurationsdatei oder eine sonstige Logik.
Die noch fehlende Schicht befasst sich mit der Interaktion und der Kommunikation mit dem ServerProzess. Die Windows Installer-Technologie stellt hierzu eine Vielzahl von Funktionen zur Verfgung,
die von existierenden Chainern bereits intensiv zur Realisierung der Anforderungen genutzt werden.
Fr die Erstellung und Konfiguration der Benutzeroberflche sind dieses Funktionen wie
MsiSetExternalUI(), MsiSetExternalUIRecord() oder MsiSetInternalUI(). Hierdurch wird es mglich,
dass alle Nachrichten des Server-Prozesses an den Chainer geleitet werden, der diese dann grafisch
aufbereitet und darstellt. Zum jetzigen Zeitpunkt wesentlich interessanter sind die Funktionen zur
Durchfhrung der Installationsaufgaben. Hierzu sind die Funktion MsiInstallProduct(),
MsiConfigureProductEx(), MsiApplyPatch() und MsiApplyMultiplePatches() vorgesehen. In
Abbildung 8.70 ist ein sehr einfaches Schema fr den Aufruf der Funktionen eines Chainers zur
Installation zweier Produkte und dem Anwenden eines Patches zu finden.
337
Kapitel 8
Abbildung 8.70: Windows Installer-Funktionen zur Realisierung eines Chainers
Das skizzierte Schema stellt eine Implementierung unter Verwendung des Windows Installers 4.0 oder
einer lteren Version dar. Dieses ist daran erkennbar, dass keine paketbergreifende Transaktion
vorhanden ist und dass somit entsprechende Implementierungen manuell zu erstellen und zu
berwachen sind. Mit dem Windows Installer 4.5 ist eine solche manuelle Implementierung nicht mehr
erforderlich, da Funktionen fr paketbergreifende Transaktionen zur Verfgung gestellt werden.
Relevant ist hierbei jedoch, dass diese nicht Out-Of-The-Box funktionieren, sondern innerhalb eines
individuellen Chainers zu verwenden sind.
Transaktionen
Als Transaktion bezeichnet man in der Informatik eine feste Folge von Operationen, die als logische
Einheit betrachtet werden. Transaktionen kommen berwiegend bei Datenbanken zum Einsatz. Bei
einer Transaktion mssen entweder alle Schritte ausgefhrt werden oder keiner, da es sonst zu
Inkonsistenzen in der Datenbank kommt. Daher muss ein Datenbanksystem in der Lage sein, eventuell
Schritte rckgngig zu machen, wenn es whrend der Transaktion zu Strungen kam und nicht alle
Operationen ausgefhrt werden konnten. In Verbindung mit Transaktionen wird hufig das Akronym
ACID verwendet, wobei dieses die Eigenschaften von Transformationen beschreibt. Es steht fr
Atomaritt (atomicity), Konsistenz (consistency), Isoliertheit (isolation) und Dauerhaftigkeit
(durability). Man spricht daher im Deutschen auch von den AKID-Eigenschaften.
Atomaritt (Atomicity): Eine Transaktion wird entweder ganz oder gar nicht ausgefhrt.
Transaktionen sind also unteilbar. Wenn eine atomare Transaktion abgebrochen wird, ist das
System unverndert.
Konsistenz (Consistency): Nach Ausfhrung der Transaktion muss der Datenbestand in einer
konsistenten Form sein, wenn er es bereits zu Beginn der Transaktion war.
Isolation (Isolation): Bei gleichzeitiger Ausfhrung mehrerer Transaktionen drfen sich diese
nicht gegenseitig beeinflussen.
Dauerhaftigkeit (Durability): Das Ergebnis einer Transaktion ist dauerhaft: Die Wirkung einer
erfolgreich abgeschlossenen Transaktion bleibt dauerhaft in der Datenbank erhalten, insbesondere
338
Kapitel 8
auch nach Systemabstrzen.

Transaktionen werden durch einen Beginn und ein Ende gekennzeichnet. Zwischen diesen
Begrenzungen befinden sich die Aktionen, die innerhalb der Transaktion ausgefhrt werden sollen.
Beginn der Transaktion
Lesen x
Schreiben y
Ende der Transaktion
Beim Beenden der Transaktion muss letztlich festgelegt werden, ob die Transaktion erfolgreich war
oder nicht. Hierdurch ergeben sich zwei Mglichkeiten, eine Transaktion zu beenden. Im positiven Fall
wird die Transaktion erfolgreich und ohne Probleme beendet, so dass die Auswirkungen der
Transaktion auf den Datenbestand dauerhaft gespeichert werden. Das Beenden der Transaktion in
dieser Form wird auch als Commit bezeichnet. Im negativen Fall ist es beim Ausfhren einer Aktion
innerhalb der Transaktion zu Problemen gekommen, so dass die weitere Ausfhrung an dieser Stelle
beendet werden muss. Die Bedingung der Atomaritt fordert zustzlich, dass smtliche Auswirkungen
der Transaktion auf den Datenbestand rckgngig gemacht werden mssen. Das Rckgngigmachen
der Effekte einer Transaktion wird als Rollback (Zurcksetzen) bezeichnet.
Transaktionalitt des Windows Installers

Als eine der wesentlichen Funktionalitten des Windows Installers wird die Verwendung
transaktionaler Installationsprozesse bezeichnet. Einfach ausgedrckt bedeutet dieses, dass das System
immer in einem konsistenten Status verbleibt, egal wie der Installationserfolg auch ausfllt. Ein
transaktionales System ist immer dadurch gekennzeichnet, dass die AKID-Eigenschaften eingehalten
werden.
Die Atomaritt des Installationsprozesses wird durch die Rollback-Funktionalitt des Windows
Installers erreicht. Identisches gilt auch fr die Konsistenz des Systems. Allerdings knnen diese
Eigenschaften nicht garantiert werden, wenn nicht regelkonforme benutzerdefinierte Aktionen
eingesetzt werden. Wird beispielsweise eine benutzerdefinierte Aktion mit sofortiger Ausfhrung zur
Vernderung des Systemstatus verwendet, so kann diese nderung whrend eines Rollbacks nicht
zurckgenommen werden. Ein identisches Bild ergibt sich, falls fr verzgert ausgefhrte
benutzerdefinierte Aktionen, keine gegenstzlichen Aktionen fr den Rollback-Fall definiert wurden.
Etwas anders verhlt es sich bei der Isolierung von Transaktionen. Der Windows Installer lsst keine
parallelen Installationen zu, also auch keine weiteren Transaktionen, wodurch alle Vorkehrungen
getroffen wurden, diese Eigenschaft umzusetzen. Eine strikte Isolierung kann jedoch aus den
folgenden Grnden nicht garantiert werden:
Bevor die Installation abgeschlossen wurde, kann ein Benutzer bereits auf die vom Windows
Installer installierten Dateien und Schlssel der Systemregistrierung zugreifen.
Parallel zu einer Installation durch den Windows Installer, kann ein Benutzer Modifikationen am
System vornehmen, indem er beispielsweise eine nicht Windows Installer-basierte Installation
ausfhrt.
Die Umsetzung der Dauerhaftigkeit kann wiederum vollstndig garantiert werden. Denn nach
Abschluss der Installation kann das System nicht mehr in einen anderen Status versetzt werden, ohne
eine neue Transaktion, also eine neue Installation, zu starten.
Zusammenfassend lsst sich feststellen, dass der Installationsprozess des Windows Installers sich an
den AKID-Eigenschaften orientiert und diese bercksichtigt. Die Tcke steckt allerdings im Detail.
339
Kapitel 8
Der Windows Installer ist uerst flexibel was die Erweiterbarkeit betrifft. Diesen Erweiterungen
liegen zwangslufig bestimmte Regeln zu Grunde, die unbedingt zu beachten sind. Wird hiergegen
verstoen, kann sich dieses zwangslufig auf die Transaktionalitt auswirken.
Phasen der Installation

Wie bereits zuvor dargestellt, bercksichtigt der Windows Installer die AKID-Eigenschaften und legt
daher dem Installationsprozess ein transaktionales Verhaltensmuster zu Grunde. Whrend der
Installation werden vom Windows Installer alle durchgefhrten nderungen am System protokolliert
und die zu ersetzenden Ressourcen gesichert. Schlgt die Installation fehl oder bricht der Anwender
diese ab, wird das System in den Zustand gesetzt, der vor der Installation bestand. Die Umsetzung der
Transaktionalitt wird durch vier Phasen realisiert.
Acquisition-Phase
Die Acquisition-Phase dient im Wesentlichen dazu, Informationen fr den Installationsprozess zu
beschaffen. Hierzu findet eine Interaktion mit der Installer-Datenbank, der Systemumgebung und dem
Benutzer statt. Diese Phase wird sowohl im Client-Prozess, als auch im Server-Prozess ausgefhrt. Das
Ergebnis der serverseitigen Acquisition-Phase ist das Installationsskript, das whrend der ExecutionPhase ausgefhrt wird. Das Ergebnis der clientseitigen Acquisition-Phase ist eine Befehlszeile, die an
den Server-Prozess bergeben wird. Wird an dieser Stelle eine MSI-Datei doppelt angeklickt, wird der
Client-Prozess gestartet und die Benutzeroberflche angezeigt. Der Benutzer kann nun innerhalb der
Benutzeroberflche die Installationsoptionen verndern. Nach Fertigstellung wird aus diesen
Einstellungen eine Befehlszeile konstruiert, die an den Server-Prozess bergeben wird. Wird hingegen
eine Installation im unbeaufsichtigten Modus gestartet, wird der Client-Prozess umgangen und es
erfolgt keine direkte Interaktion mit dem Benutzer. In diesem Fall mssen die Installationsoptionen
beim Aufruf des Installationsprozesses direkt der Befehlszeile angefgt werden.
Execution-Phase
Whrend dieser Phase wird das System physisch verndert, indem die im Installationsskript
enthaltenen Operationsanweisungen ausgefhrt werden. Bei der Ausfhrung jeder dieser
Operationsanweisungen, wird eine gegenstzliche Operation erzeugt und in das Rollbackskript
geschrieben. Alle Operationen, die nicht zurckgenommen werden knnen, werden bei der
Abarbeitung des Installationsskriptes bersprungen und dem Rollbackskript angefgt. Beispiele fr
solche
Operationen
sind
benutzerdefinierte
Aktionen
vom
Typ
Commit
(msidbCustomActionTypeInScript + msidbCustomActionTypeCommit) und auch die finalen
Operationen zur Installation von Assemblies in den Global Assembly Cache.
Die hierdurch realisierte Transaktion wird durch die Aktionen InstallInitialize und InstallFinalize
gekennzeichnet. Beim Erreichen der Aktion InstallInitialize wird zunchst mit der Erstellung eines
Installationsskriptes begonnen. Fr alle Standardaktionen, die sich zwischen InstallInitialize und
InstallFinalize befinden, werden Operationsanweisungen generiert, die in das Installationsskript
bertragen werden. Beim Erreichen der Aktion InstallFinalize wird das Installationsskript abgearbeitet.
Bei der Ausfhrung der einzelnen Operationsanweisungen werden gegenstzliche Anweisungen in das
Rollbackskript geschrieben, welches im Falle eines Installationsabbruchs, zur Rekonstruktion des
Ursprungszustandes des Systems verwendet wird. Das Verhalten einer benutzerdefinierten Aktion ist
an dieser Stelle abweichend von der Standardaktion. Befindet sich eine relevante Standardaktion
zwischen InstallInitalize und InstallFinalize wird diese nicht direkt ausgefhrt, sondern eine
340
Kapitel 8
resultierende Operationsanweisung in das Installationsskript eingetragen. Befindet sich hingegen eine

nicht besonders gekennzeichnete, benutzerdefinierte Aktion zwischen den entsprechenden Aktionen,
wird sie sofort ausgefhrt und nicht ins Installationsskript eingetragen. Sie wird demzufolge als
Benutzerdefinierte Aktion mit sofortiger Ausfhrung (Immediate Execution) bezeichnet. Es ist
natrlich auch mglich eine benutzerdefinierte Aktion zu erstellen, die in das Installationsskript
eingetragen und erst im Rahmen der Skriptausfhrung verwendet wird. Diese wird hingegen als
Benutzerdefinierte Aktion mit verzgerter Ausfhrung (Deferred Execution) bezeichnet. Der
gravierende Unterschied zu Standardaktionen ergibt sich daraus, dass eine Standardaktion immer in
das Skript eingetragen wird, wenn sie in der Sequenztabelle zwischen den Aktionen InstallInitialize
und InstallFinalize definiert ist. Eine benutzerdefinierte Aktion muss ebenfalls zwischen diesen
Aktionen in die Sequenztabelle eingefgt werden, allerdings muss sie darber hinaus explizit fr die
Skriptausfhrung in der Tabelle CustomAction gekennzeichnet werden.
Commit-Phase
Wie bereits zu Beginn dieses Buches erlutert, erfolgt die Installation von Assemblies in den Global
Assembly Cache immer in Verbindung mit der Common Language Runtime. Das bedeutet, dass der
Windows Installer die Installation initiiert, aber die physische Installation ausschlielich durch die
Common Language Runtime erfolgt, die hierfr ein transaktionales Modell verwendet. Im ersten
Schritt wird ein Objekt vom Typ IAssemblyCacheItem erstellt und im zweiten Schritt wird die
Methode Commit dieses Objektes ausgefhrt. Die Erstellung des IAssemblyCacheItem-Objektes erfolgt
whrend der Execution-Phase, aber der zweite Schritt dieses Prozesses erfolgt erst whrend der
Commit-Phase des Windows Installers. Erst danach steht das Assembly zur Verfgung und kann
verwendet werden. Dieses ist eine der wesentlichen Aufgaben innerhalb der Commit-Phase. Die zweite
wesentliche Aufgabe betrifft die benutzerdefinierten Aktionen vom Typ Commit. Wie der Name
bereits vermuten lsst, werden diese Aktionen auch whrend der Commit-Phase ausgefhrt und zwar
nach der Finalisierung der Assemblies. Hierdurch ist es mglich, benutzerdefinierte Aktionen zu
verwenden, die auf Assemblies des Global Assembly Cache zugreifen. Die Abarbeitung der
benutzerdefinierten Aktionen erfolgt nach dem FIFO-Prinzip (first in - first out). Das bedeutet, dass
die Aktion die dem Rollbackskript zuerst angefgt wurde, auch zuerst ausgefhrt wird.
Diese Commit-Phase wird allerdings nur ausgefhrt, wenn das Installations-Skript erfolgreich
verarbeitet wurde. Kommt es whrend dieser Phase zu einem Fehler, wird versucht, die bisher
durchgefhrten Modifikationen zurckzunehmen. Fr die Modifikationen, die whrend der ExecutionPhase durchgefhrt wurden, kann die Rcknahme garantiert werden. Werden hingegen nderungen
am System whrend der Commit-Phase vorgenommen, kann die Rcknahme nicht in allen Fllen
garantiert werden. Diese Einschrnkung zielt auf benutzerdefinierten Aktionen vom Typ Commit ab,
da hierfr keine gegenstzliche Aktion zur Zurcknahme der Modifikationen existiert und auch nicht
definiert werden kann.
Rollback-Phase
Kommt es whrend de Skriptausfhrung zu einem Fehler oder zu einem Benutzerabbruch, muss das
System in den Zustand versetzt werden, der vor der Installation vorhanden war. Hierzu werden die
Operationsanweisungen des Rollbackskriptes in der LIFO-Reihenfolge (last in first out) ausgefhrt.
Wichtig Beginn
Benutzerdefinierte Aktionen vom Typ Commit und die Rollback-Phase werden nicht ausgefhrt, wenn
auf dem Zielsystem die Funktionalitt des Rollbacks durch die Systemrichtlinie DisableRollback oder
341
Kapitel 8
die Eigenschaft DISABLEROLLBACK deaktiviert wurde. Da dieses einen nicht unerheblichen Einfluss
auf den gesamten Installationsprozess ausben kann, sollte eine Installation unter diesen
Voraussetzungen nicht durchgefhrt werden. Hierzu kann die Eigenschaft RollbackDisabled in der
Tabelle LaunchCondition geprft werden.
Wichtig Ende
Der Wesentliche Punkt in einem transaktionalen Szenario ist natrlich die Execution-Phase. Hier wird
fr jede Operation eine gegenstzliche Operation erzeugt, mit der die nderungen zurckgenommen
werden knnen. Hieraus ergibt sich, dass diese Phase sowohl vorwrts als auch rckwrts durchlaufen
werden kann, was bei den anderen Phasen nicht der Fall ist. Bei der Acquisition-Phase ist dieses auch
gar nicht erforderlich, da hierbei keine Modifikationen am System vorgenommen werden. Die
Commit-Phase wird rein vorwrts durchlaufen, wodurch eine transaktionale Verhaltensweise nicht
gegeben ist. Das bedeutet, dass bei Fehlern, die in den ersten beiden Phasen auftreten, das System in
den Ursprungszustand zurck versetzt wird. Tritt jedoch ein Fehler in der dritten also der CommitPhase auf, werden bestmgliche Anstrengungen unternommen, dass System in den Ursprungszustand
zu versetzen. Allerdings kann eine vollstndige Restauration nicht gewhrleistet werden, wie dieses
auch in Abbildung 8.71 dargestellt ist
Abbildung 8.71: Transaktionalitt bei der Installation eines Produktes
Die Betrachtung muss an dieser Stelle noch erweitert werden, um letztlich zu einer
paketbergreifenden Transaktion zu gelangen. Die bisherigen Versionen des Windows Installers
enthalten keine Implementierung um eine Transaktion auf mehrere Pakete auszudehnen. Zur
Realisierung ist eine eigene Logik erforderlich, die letztlich eine Art Rollback manuell veranlasst. Der
Rollback ist in einem solchen Fall jedoch nichts anderes als eine Deinstallation, da ja das
Rollbackskript nur whrend der Installation des jeweiligen Produktes zur Verfgung steht und die
Commit-Phase bereits abgeschlossen ist. Die zuverlssige Zurcknahme der durchgefhrten CommitAktionen liegt in der Deinstallation des Produktes. Abbildung 8.72 zeigt den schematischen Ablauf
einer manuell konstruierten paketbergreifenden Transaktion, bei der sich die Logik im Chainer
befindet. Kommt es bei der Installation von Paket 3 whrend der Execution-Phase zu einem Fehler,
342
Kapitel 8
findet automatisch ein Rollback fr dieses Paket statt. Die Zielsetzung des Chainers ist es jedoch, dass
System in den Status zu versetzen, der vor der Installation bestand, falls whrend der Installation ein
Fehler auftritt. Aus diesem Grund muss der Chainer die Zurcknahme der Modifikationen von Paket
1 und Paket 2 veranlassen, wozu er eine Deinstallation startet.
Abbildung 8.72: Schema einer paketbergreifenden Installation mit Windows Installer 4.0
Anders verhlt es sich bei der Verwendung des Windows Installers 4.5. Hier stehen zustzliche
Funktionalitten bereit, eine echte paketbergreifende Transaktion durchzufhren. In Abbildung
8.73 ist erkennbar, dass zunchst die Execution-Phasen aller involvierten Pakete ausgefhrt werden.
Danach wird entschieden ob die Commit-Phase eingeleitet, oder ob ein Rollback durchgefhrt werden
soll.
Abbildung 8.73: Schema einer paketbergreifenden Transaktion mit dem Windows Installer 4.5
Transaktionen mit dem Installer 4.5

Die wahrscheinlich wichtigste Neuerung im Windows Installer 4.5 ist die Untersttzung von
paketbergreifenden Transaktionen (Multi-Package-Transaktion). Hierunter ist ein Mechanismus der
343
Kapitel 8
Windows Installer-Technologie zu verstehen, mit dem er mglich wird, mehrere Installationen

innerhalb einer Transaktion auszufhren, wobei ein integriertes Rollback- und Neustart-Verhalten
vorhanden ist. Bei den bisherigen Versionen des Windows Installers ist keine direkte Untersttzung fr
solche Anforderungen vorhanden, so dass eine Umsetzung mehr oder weniger manuell erfolgen
musste. Die erforderliche Logik zum Steuern der Installation und zur Auswertung der Rckgabewerte
und Fehlercodes musste direkt in den Chainer integriert werden. Das bedeutet auch, dass der Chainer
den Erfolg oder den Misserfolg der Installation sicherstellen musste. Hiermit ist gemeint, dass der
Chainer die Installation der einzelnen Pakete berwacht und beim Auftreten eines Fehlers, die
Deinstallation aller vorherigen Pakete veranlasst.
Mit dem Windows Installer 4.5 wurde diese Vorgehensweise wesentlich optimiert, denn die
Rcknahme der bereits zuvor installierten Produkte erfolgt nicht mehr durch eine manuelle
Implementierung innerhalb des Chainers, sondern wird direkt vom Windows Installer veranlasst.
Hierzu wird letztlich der Rollback-Mechanismus verwendet, der seit dem Windows Installer 4.5 ber
Paketgrenzen hinweg funktioniert. Diese Mglichkeit des Paketbergreifenden Rollbacks wird durch
Persistenz des Rollback-Skriptes erreicht. Hiermit ist gemeint, dass der Rollback-Skript nicht nach
Abschluss der Installation eines Paketes gelscht wird, sondern bis zum Abschluss der Transaktion auf
dem System verbleibt und somit auch verwendet werden kann. Identisches gilt fr die Commit-Phase,
die im Rahmen einer paketbergreifenden Transaktion nicht paketorientiert ausgefhrt wird, sondern
erst nach der Installation aller Pakete, wie Abbildung 8.74 zeigt. Hierdurch werden alle Aktionen, die
nicht mehr zuverlssig zurckgenommen werden, erst ausgefhrt, wenn alle involvierten Pakete
fehlerfrei installiert wurden.
Abbildung 8.74: Phasen einer Multi-Package-Transaktion
Wir bereits in einem vorherigen Abschnitt beschrieben, werden im Chainer die Abhngigkeiten der zu
installierenden Pakete verwaltet. Das Ergebnis dieser Phase ist einfach ausgedrckt eine Liste mit
Paketen und Patches, die im Rahmen einer Transaktion zu installieren sind. Wenn diese Liste vorliegt,
gibt der Chainer letztlich den Startschuss fr die Installation der einzelnen Pakete. Wesentlich ist
hierbei auch, dass der Chainer letztlich darber entscheidet, ob die gesamte Transaktion abgeschlossen
oder zurckgenommen werden soll. Zusammenfassend lassen sich die Aktivitten im Rahmen einer
Multi-Package-Transaktion wie folgt skizzieren:
9. Der Chainer startet die Transaktion durch den Aufruf der Funktion MsiBeginTransaction().
10. Der Chainer veranlasst den Windows Installer ein entsprechendes Produkt zu installieren oder
einen Patch anzuwenden.
11. Die Installation wird ausgefhrt, der Windows Installer beginnt mit der Acquisition-Phase. Die
Acquisition-Phase einer Multi-Package-Transaktion unterscheidet sich nicht von der einer
344
Kapitel 8
einzelnen Installation.
12. Der Installer wechselt nun in die Execution-Phase. Die Execution-Phase einer Multi-PackageTransaktion unterscheidet sich nicht von der einer einzelnen Installation.
13. Der Installer gibt die Ausfhrungskontrolle zurck an den Chainer.
14. Die Schritte 2 bis 5 werden nun fr jedes Produkt ausgefhrt, das installiert werden soll.
15. Der
Chainer
schliet
die
Transaktion
durch
Aufruf
der
Funktion
MsiEndTransaction(msiCommitTransaction) ab.
16. Der Installer fhrt nun die Commit-Phase fr alle Produkte aus, die im Rahmen der Transaktion
installiert wurden und beendet danach die Transaktion.
In Abbildung 8.75 sind diese einzelnen Schritte in einer schematischen Ablaufdarstellung dargestellt.
Abbildung 8.75: Schematische Darstellung der Multi-Package-Transaktion
In der vorliegenden Auflistung der Aktivitten, wurden bereits die neuen Funktionen verwendet, die es
nun zu erlutern gilt.
Wie bereits zuvor erwhnt, ist eine Transaktion immer durch einen Beginn und ein Ende
gekennzeichnet. Die hierfr erforderlichen Funktionen oder Schlsselwrter sind natrlich von der
verwendeten Technologie abhngig. Das Starten einer Transaktion erfolgt in ADO (ActiveX Data
Objects) beispielsweise ber die Funktion BeginTrans(), in T-SQL des Microsoft SQL-Servers durch
BEGIN TRANSACTION und beim Windows Installer 4.5 durch die Funktion MsiBeginTransaction().
Durch die Verwendung dieser Funktion wird ein Transaktions-Objekt erstellt, in dem ein
Identifizierungsmerkmal, das Handle des Client-Prozesses, der Name der Transaktion und weitere
Attribute enthalten sind. Diese Informationen werden von anderen Funktionen bentigt, um weitere
Installationsaktivitten innerhalb dieser Transaktion auszufhren. Die Zerstrung des TransaktionsObjektes und damit verbunden das Beenden der Transaktion erfolgt durch die Funktion
MsiEndTransaction().
345
Kapitel 8

Die Realsierung von paketbergreifenden Transaktionen erfordert den Zugriff und die Verwendung
des Windows Installer-API. Das bedeutet, dass zur Entwicklung eines entsprechenden Chainers nur
Programmiersprachen oder Technologien verwendet werden knnen, die Win32-Funktion aufrufen
knnen. Eine Automatisierungsschnittstelle steht nicht zur Verfgung, so dass die geforderte
Funktionalitt durch eine Skriptsprache wie VBScript nur ber Umwege umsetzbar wre.
Starten der Transaktion

Durch die Funktion MsiBeginTransaction() wird eine Transaktion zur Durchfhrung einer MehrpaketInstallation gestartet. Die Funktion gibt ein Identifizierungsmerkmal zurck, dass von anderen
Transaktionsspezifischen Funktionen bentigt wird. Die Definition der Funktion sieht folgendermaen
aus:
[DllImport("msi.dll", CharSet=CharSet.Unicode)]
internal static extern uint MsiBeginTransaction(
string szTransactionName,
int dwTransactionAttributes,
out int hTransaction,
out IntPtr phChangeOfOwnerEvent
);
Zur Vermeidung sicherheitsrelevanter Probleme drfen Aktionen innerhalb der Transaktion nur von
dem Prozess veranlasst werden, der auch der Eigentmer der Transaktion ist. Hierzu speichert der
Windows Installer einige identifizierende Merkmale des Prozesses, der MsiBeginTransaction() aufruft
und gleicht diese bei den Funktionsaufrufen ab. Die folgenden Parameter sind beim Aufrufen der
Funktion zu verwenden:
szTransactionName: Name der paketbergreifenden Transaktion.
dwTransactionAttributes: Ein numerischer Wert zur Definition von bestimmten Verhaltensweisen
der Transaktion hinsichtlich der Verwendung der Benutzeroberflche. Wird dieses Attribut nicht
oder auf den Wert 0x0 gesetzt, wird die Benutzeroberflche einer vorherigen Installation
geschlossen.
Wird
das
Attribut
hingegen
auf
den
Wert
0x1
(MSITRANSACTION_CHAIN_EMBEDDEDUI) festgelegt, wird der Windows Installer
angewiesen, eine eingebettete Benutzeroberflche (Embedded UI) whrend der Transaktion nicht
zu schlieen. Die Funktionalitt der eingebetteten Benutzeroberflchen wird in einem gesonderten
Kapitel erlutert.
hTransaction: Diesem Parameter wird vom Windows Installer ein Identifizierungsmerkmal
zugewiesen. Diese Transaktions-ID kann zum Wechsel des Eigentmers einer Transaktion
verwendet werden.
phChangeOfOwnerEvent: Diesem Parameter wir vom Installer ein Handle auf eine
Ereignisroutine zugewiesen. Das so referenzierte Ereignis wird ausgelst, wenn sich Eigentmer
(Client-Prozess) der Transformation gendert hat. Eine nderung des Eigentmers kann durch die
Funktion MsiJoinTransaction() veranlasst werden. Hierdurch kann der aktuelle Eigentmer der
Transformation feststellen, wenn sich das Eigentumsverhltnis ndert. Wird eine Transaktion in
einen Zustand versetzt, in dem kein Eigentmer existiert, wird ein Rollback durchgefhrt und die
Transaktion beendet. Wird beispielsweise der Chainer beendet, obwohl noch eine Transaktion aktiv
ist, verfgt die Transaktion zwangslufig ber keinen Eigentmer mehr, und die nderungen
346
Kapitel 8
werden zurckgenommen.
War der Aufruf der Funktion MsiBeginTransaction() erfolgreich, wird ERROR_SUCCESS als
Rckgabewert geliefert. Abweichende Rckgabewerte deuten auf einen Fehler hin, wie dieses auch in
Tabelle 8.66 dargestellt ist.
Fehlercode
Wert
Beschreibung
ERROR_INVALID_PARAMETER
87
Falscher oder ungltiger Parameter.
ERROR_INSTALL_SERVICE_FAILURE
1601
Auf den Windows-Installationsdienst konnte nicht

zugegriffen werden. Die kann vorkommen, wenn der
Windows-Installer nicht richtig installiert ist.
ERROR_INSTALL_ALREADY_RUNNING
1618
Zur Vermeidung von konkurrierenden Transaktionen

kann systemweit nur eine Transaktion geffnet werden.
Falls versucht wird, eine weitere Transaktion zu ffnen,
wird die Funktion mit diesem Fehlercode beendet.
Zustzlich werden dem Ereignisprotokoll Informationen
zu der bereits existierenden Transaktion angefgt.
ERROR_ROLLBACK_DISABLED
1653
Eine paketbergreifende Transaktion kann nicht

ausgefhrt werden, wenn die Verwendung von
Rollback-Installationen deaktiviert wurde. Falls die
Systemrichtlinie DisableRollback oder die Eigenschaft
DISABLEROLLBACK gesetzt wurde, wird die Funktion
mit diesem Fehlercode beendet.
Tabelle 8.66: Mgliche Fehlercodes der Funktion MsiBeginTransaction()
Beenden der Transaktion

Die Funktion MsiEndTransaction() beendet eine durch MsiBeginTransaction() geffnete Transaktion.
Diese Funktion kann nur von dem Eigentmer der Funktion aufgerufen werden. Die Definition dieser
Funktion ist nicht sehr komplex, wie nachfolgend dargestellt wird:
internal static extern uint MsiEndTransaction(
int dwTransactionState
);
Beim Beenden der Transaktion muss festgelegt werden, ob die Ausfhrung erfolgreich war oder ob die
nderungen am Zielsystem zurckgenommen werden mssen. Dieses Verhalten kann durch den
Parameter dwTransactionState beeinflusst werden, indem die folgenden Werte verwendet werden.
MSITRANSACTIONSTATE_ROLLBACK (0x0): Es wird ein Rollback durchgefhrt um die
nderungen der Transaktion zurckzunehmen, die seit dem Aufruf von MsiBeginTransaction()
durchgefhrt wurden.
MSITRANSACTIONSTATE_COMMIT (0x1): Es werden alle noch ausstehenden und nicht mehr
zurckzunehmenden Modifikationen am System durchgefhrt. Hierbei wird die Installation der
Win32- und der .NET Assemblies abgeschlossen und die benutzerdefinierten Aktionen vom Typ
Commit werden ausgefhrt. Im Weiteren wird das Rollback-Skript gelscht, so dass danach keine
nderungen mehr zurckgenommen werden knnen.
Wird die Funktion erfolgreich ausgefhrt, wird ERROR_SUCCESS zurckgegeben. Die weiteren
347
Kapitel 8
mglichen Rckgabewerte und die Begrndung fr das entsprechende Verhalten sind in Tabelle 8.67
aufgefhrt.
Fehlercode
Wert
Beschreibung
ERROR_ACCESS_DENIED
Beim Versuch eine Transaktion durch einen anderen

Eigentmer zu beenden, als dem Aktuellen, wird
der Zugriff verweigert.
1603
Schwerwiegender Fehler bei der Installation.
1618
Die Transaktion kann nicht beendet werden, da eine

Installation derzeit noch ausgefhrt wird.
1653
Eine Installation innerhalb dieser Transaktion kann

nicht fertiggestellt werden. Wird whrend der
Transaktion die Verwendung von RollbackInstallationen durch die Richtlinie DisableRollback
unterbunden, wird die Installation bis zu dem
Zeitpunkt zurckgenommen, an dem die nderung
der Richtlinie erfolgte.
Tabelle 8.67: Mgliche Fehlercodes der Funktion MsiEndTransaction()
Wird die Transaktion erfolgreich beendet werden die im Rollback-Skript befindlichen

benutzerdefinierten Aktionen vom Typ Commit in der FIFO-Reihenfolge ausgefhrt. War die
Transaktion hingegen nicht erfolgreich, wird eine Rollback-Installation gestartet wozu die
gespeicherten Rollback-Skripte in LIFO-Reihenfolge verwendet werden.
bernahme einer Transaktion

Eine Transaktion kann nur ber einen Eigentmer verfgen. Die Funktion MsiJoinTransaction()
ermglicht die bernahme einer Transaktion durch einen anderen Chainer, also durch einen anderen
Prozess. Jeder Chainer, der eine Installations- oder Konfigurationsaufgabe durchfhrt, sollte auch der
Eigentmer der Transaktion sein. Diese Funktion ist folgendermaen definiert:
internal static extern uint MsiJoinTransaction(
int hTransaction,
int dwTransactionAttributes,
out IntPtr phChangeOfOwnerEvent
);
Bei dem letzten Parameter handelt es sich wie bei der Funktion MsiBeginTransaction() um das Handle
auf eine Ereignisroutine, so dass hier auf eine weitere Erluterung verzichtet werden kann. Die
weiteren Parameter sind wie folgt definiert:
hTransactionID: Hierbei handelt es sich um das Identifizierungsmerkmal der Transaktion, das
durch die Funktion MsiBeginTransaction() zurckgegeben wurde.
dwTransactionAttributes: Ein numerischer Wert zur Definition von bestimmten Verhaltensweisen
der Transaktion hinsichtlich der Benutzeroberflche. Wird dieses Attribut nicht oder auf den Wert
0x0 gesetzt, wird die Benutzeroberflche einer vorherigen Installation geschlossen. Wird das
Attribut hingegen auf den Wert 0x1 (MSITRANSACTION_CHAIN_EMBEDDEDUI) festgelegt,
wird der Windows Installer angewiesen, eine integrierte Benutzeroberflche (Embedded UI)
348
Kapitel 8
whrend der Transaktion nicht zu schlieen. Das Festlegen des Attributs auf 0x2
(MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI) veranlasst den Windows Installer die
integrierte Benutzeroberflche der Originalinstallation zu verwenden. Verfgt diese Installation
ber keine integrierte Benutzeroberflche, wird dieses Attribut ignoriert.
Der erfolgreiche Aufruf dieser Funktion resultiert wiederum im Rckgabewert ERROR_SUCCESS
zurckgegeben. Die weiteren mglichen Rckgabewerte sind in Tabelle 8.68 aufgefhrt.
Fehlercode
Wert
Beschreibung
ERROR_ACCESS_DENIED
Der Benutzer der die Transaktion besitzt und der

Benutzer der die Transaktion bernehmen mchte sind
unterschiedlich, so dass der Zugriff verweigert wird.
ERROR_INVALID_HANDLE
Die verwendete Transaktions-ID ist ungltig.
ERROR_INVALID_PARAMETER
87
Falscher oder ungltiger Parameter.
1618
Der Eigentmer kann nicht gewechselt werden, da eine

Installation derzeit noch ausgefhrt wird.
Tabelle 8.68: Mgliche Fehlercodes der Funktion MsiJoinTransaction()
Wird diese Funktion durch den Chainer aufgerufen wird zunchst geprft, ob der Benutzertoken des
aufrufenden Prozesses mit dem Token des Eigentmers der Transaktion identisch ist. Ist das nicht der
Fall wird die Funktion mit einem Fehler beendet. Im Weiteren wird auch geprft, ob sich der neue
Eigentmer in der gleichen Prozessstruktur befindet, wie der aktuelle Eigentmer. Die Prozessstruktur
wird hierbei von dem Prozess gebildet, der die Transaktion erzeugt hat. Hieraus folgt, dass eine
bernahme der Transaktion nur durch einen Kind-Prozess des Erzeugers erfolgen kann. Die Funktion
kann auch nur ausgefhrt werden, wenn keine Installation aktiv ist.
Installationen und Konfigurationen

Die gerade vorgestellten Funktionen kennzeichnen den Beginn und das Ende der Transaktion und
ermglichen die bernahme der Transaktion durch einem anderen Prozess. Zwischen diese
Markierungen sind natrlich noch die Anweisungen zur Installation und zur Konfiguration der Pakete
einzufgen, wie dieses in Abbildung 8.76 dargestellt wird.
349
Kapitel 8
Abbildung 8.76: Windows Installer-Funktionen zur Realisierung eines transaktionalen Chainers
Beginnend mit dem Windows Installer 4.5 knnen die von den folgenden Funktionen durchgefhrten
nderungen am System, im Rahmen einer paketbergreifenden Transaktion zurckgenommen werden:
MsiAdvertiseProduct()
MsiAdvertiseProductEx()
MsiApplyMultiplePatches()
MsiApplyPatch()
MsiConfigureFeature()
MsiConfigureProduct()
MsiConfigureProductEx()
MsiInstallMissingComponent()
MsiInstallMissingFile()
MsiInstallProduct()
MsiProvideAssembly()
MsiProvideComponent()
MsiProvideQualifiedComponent()
MsiProvideQualifiedComponentEx()
MsiReinstallFeature()
MsiReinstallProduct()
MsiRemovePatches()
Es ist nicht verwunderlich, dass bestimmte Verhaltensmuster dieser Installations- und
Konfigurationsfunktionen einen abweichenden Algorithmus verwenden, wenn sie innerhalb einer
350
Kapitel 8
paketbergreifenden Transaktion ausgefhrt werden. Innerhalb einer Transaktion wird zunchst

geprft, ob der Client, der die Windows Installer-Funktion zur Installation oder Konfiguration aufruft,
identisch ist mit dem Eigentmer der Transaktion. Ist dieses nicht der Fall wird die entsprechende
Funktion mit dem Fehlercode ERROR_INSTALL_ALREADY_RUNNING beendet. Durch diese
Implementierung wird der AKID-Eigenschaft der Isolation entsprochen. Diese besagt, dass sich
mehrere Transaktionen nicht gegenseitig beeinflussen drfen. Eine gegenseitige Beeinflussung kann
ausgeschlossen, da keine parallelen Installationen und Transaktionen mglich sind.
Zu einer ganz wesentlichen nderung im Verhalten der Funktionen haben die Optionen zur
Deaktivierung oder Einschrnkung des Rollbacks gefhrt. Standardmig kann eine RollbackInstallation durch die Systemrichtlinie DisableRollback, die Eigenschaften DISABLEROLLBACK und
PROMPTROLLBACKCOST und die Aktion DisableRollback deaktiviert werden. Eine solche
Vorgehensweise ist innerhalb einer Transaktion nicht erlaubt, so dass die entsprechenden
Funktionsaufrufe mit dem Rckgabewert ERROR_ROLLBACK_DISABLED beendet werden. Alle
Funktionen zur Installation und Konfigurationen wurden aus diesem Grund um den in Tabelle 8.69
dargestellten Fehlercode erweitert.
Fehlercode
Wert
Beschreibung
1653
Pakete bei denen die Rollback-Funktionalitt

deaktiviert wurde, knnen nicht innerhalb der
Transaktion installiert oder konfiguriert werden.
Tabelle 8.69: Neue Fehlercodes zur Vermeidung deaktivierter Rollback-Funktionalitt
Transaktionsklasse
Die Erstellung eines Chainers unter Verwendung der neuen Funktionen des Windows Installers 4.5 ist
relativ einfach. Die Funktion MsiBeginTransaction() erzeugt eine Transaktion und gibt ein
Identifizierungsmerkmal fr die Transaktion zurck. Mit MsiJoinTransaction() ist es fr einen anderen
Prozess mglich, das Eigentumsverhltnis der Transaktion zu bernehmen, wozu die Transaktions-ID
bentigt wird. Durch MsiEndTransaction() wird die letztlich Transaktion abgeschlossen. Diese
Funktion erwartet einen booleschen Wert, der das Ergebnis der Transaktion bestimmt.
Im objektorientierte Programmierparadigma bietet sich jedoch die Verwendung eines
funktionsspezifischen Objektes an. Die Deployment Tools Foundation stellen hierfr die Klasse
Transaction des Namensraums Microsoft.Deployment.WindowsInstaller zur Verfgung. Die einzelnen
Elemente der Klasse sind in Tabelle 8.70 aufgefhrt.
Member
Typ
Beschreibung
Transaction(String,
TransactionAttributes)
Konstruktor
Erstellt eine Transaktion zur Realisierung einer

Mehrpaket-Installation.
Commit()
Methode
Beendet die Transaktion und schliet alle noch

ausstehenden und nicht mehr zurckzunehmenden
Modifikationen am System ab.
FromHandle(IntPtr, Boolean)
Methode (Statisch)
Erstellt aus einem Handle ein neues Objekt vom Typ

Transaction.
Join(TransactionAttributes)
Methode
Macht den aktuellen Prozess zum neuen Eigentmer der

Transaktion.
351
Kapitel 8
Name
Eigenschaft
Gibt den Namen der Transaktion zurck. Der Name

wird beim Erzeugen der Transaktion definiert.
OwnerChanged
Ereignis
Ereignis wird ausgelst, wenn der Eigentmer der

Transaktion gewechselt wird.
Rollback()
Methode
Beendet die Transaktion und nimmt die bereits

durchgefhrten nderungen zurck.
Tabelle 8.70: Mitglieder der Klasse Microsoft.Deployment.WindowsInstaller.Transaction
Der programmtechnischen Umsetzung liegt natrlich die bereits angesprochene schichtweise

Unterteilung der Chainer-Architektur zu Grunde. Die Interaktionsschicht enthlt die
Implementierungen zur Realsierung der Transaktion. Dieser Schicht muss logischerweise eine Liste
der zu installierenden Pakete bergeben werden. Die Ermittlung dieser Pakete wird zwangslufig auf
einer hheren Ebene ausgefhrt. Die zu installierenden Pakete werden der Funktion als Parameter vom
Typ List bergeben. Innerhalb der Funktion wird zunchst das Transaktions-Objekt erzeugt und
anschlieend wird die Installation der einzelnen Produkte durchgefhrt. Letztlich wird die Transaktion
geschlossen und die noch ausstehenden Aktivitten beendet. Sollte die Installation eines Produktes
fehlschlagen, wird zwangslufig eine Ausnahme (Exception) ausgelst so dass im Exception-Handler
die Transaktion beendet wird und die durchgefhrten nderungen zurckgenommen werden.
In Listing 8.76 ist auch erkennbar, dass bei der Installation der Produkte die Eigenschaft
ARPSYSTEMCOMPONENT auf den Wert 1 gesetzt wird. Hierdurch wird die Anzeige der
installierten Produkte in der Systemsteuerung unterbunden. In einem realen Szenario wrde sich der
Chainer dort selbst registrieren, so dass die Deinstallation oder die Reparatur auch innerhalb einer
paketbergreifenden Transaktion erfolgt.
internal static void Install(List<string> fileList)
{
// Transaktions-Objekt erzeugen
using (Transaction transaction = new Transaction("Install", TransactionAttributes.None))
{
try
{
foreach (string fileName in fileList)
{
// Installation der Produkte. Anzeige in der Systemsteuerung
// durch verwenden von ARPSYSTEMCOMPONENT verhindern.
Installer.InstallProduct(fileName, "ARPSYSTEMCOMPONENT =1");
}
// Transaktion abschlieen
transaction.Commit();
}
catch
{
// nderungen zurcknehmen
transaction.Rollback();
}
}
}
Listing 8.76: Verwenden der Klasse Transaction zur Durchfhrung einer paketbergreifenden Transaktion
352
Kapitel 8
Das vorstehende Listing sollte die Verwendung der Transaktionsklasse verdeutlichen. Die
tatschlichen Installationsttigkeiten werden hier nur rudimentr betrachtet. In dem Beispiel werden
nur Produkte installiert; Konfigurationsttigkeiten, Deinstallationen oder die Installation von Patches
wurden hierbei nicht bercksichtigt, sind aber in diesem Zusammenhang nicht zu vernachlssigen.
Eingebetteter Chainer
Zur Realisierung einer paketbergreifenden Transaktion ist immer eine Chainer-Anwendung
erforderlich. Diese kann als externe Anwendung vorliegen, sie kann aber auch direkt in die Pakete
integriert werden. Die Integration wird durch die neue Tabelle MsiEmbeddedChainer ermglicht.
Durch die Verwendung dieser Tabelle ergibt sich die Mglichkeit ein Windows Installer-Paket
beispielsweise durch Doppelklick zu starten und dennoch einer Chainer-Anwendung zur
paketbergreifenden Steuerung zu verwenden. Interessent ist diese Verwendungsmglichkeit bei der
Verteilung ber das Active Directory, da hierbei nur MSI-Pakete verwendet werden knnen und keine
EXE-Dateien. Durch diese verschiedenen Integrationsformen des Chainers ergeben sich auch
zwangslufig abweichende Anwendungsszenarien des Installers.
Windows Installer 4.5 versucht Installationen immer innerhalb einer Transaktion auszufhren, auch
wenn es sich nur um ein Paket handelt und auch wenn eine Transaktion nicht explizit erstellt wurde.
Entsprechende Hinweise darauf finden sich im Ereignisprotokoll von Windows. Zum Beginn der
serverseitigen Installation wird geprft ob bereits eine Transaktion vorhanden ist. Ist dieses nicht der
Fall wird MsiBeginTransaction() vom Server-Prozess aufgerufen, wodurch der Server-Prozess
gleichzeitig als Eigentmer der Transaktion festgelegt wird. Wurde jedoch die Rollback-Funktionalitt
auf dem System oder fr das Installationspaket deaktiviert, wird keine Transaktion erzeugt und die
Installation erfolgt wie bei den vorherigen Versionen des Windows Installers. Wir befassen uns aber an
dieser Stelle mit Transaktionen und betrachten somit das Szenario in dem der Server-Prozess eine
Transaktion erzeugt hat und somit deren Eigentmer ist.
Beim Erreichen der Aktion InstallFinalize wird die Tabelle MsiEmbeddedChainer auf die Existenz
eines Chainers geprft. Falls kein Chainer vorhanden ist, wird MsiEndTransaction() aufgerufen
und die Installation wie seit jeher abgeschlossen. Falls jedoch ein Chainer vorhanden ist, der auch
ausgefhrt werden kann und darf, wird dieser gestartet. Der Chainer wird hierbei als
benutzerdefinierte Aktion vom Typ Ausfhrbare Datei im Kontext des Benutzers ausgefhrt.
Innerhalb des Chainers knnen wiederum MsiInstallProduct() oder artverwandte Funktionen
verwendet werden, um Pakete oder Patches innerhalb der Transaktion zu installieren, nachdem die
Transaktion mit MsiJoinTransaction() bernommen wurde. Im Weiteren muss der Chainer die
Transaktion durch MsiEndTransaction() abschlieen. Schlgt die Ausfhrung des Chainers fehl
oder wird MsiEndTransaction() nicht ausgefhrt, wird diese Funktion mit dem Parameter
MSITRANSACTIONSTATE_ROLLBACK vom Server-Prozess automatisch aufgerufen um die
durchgefhrten nderungen zurckzunehmen. Schlgt der Aufruf von MsiEndTransaction() fehl,
da noch eine Installation ausgefhrt wird, wird die Transaktion bis zum frhestmglichen Zeitpunkt
zurckgerollt.
Beim Ausfhren einer Produktankndigung (Advertised Installation) wrde der Chainer nach dem
gleichen Muster aufgerufen werden, da der Windows Installer keine Unterscheidung zwischen den
Installationsarten vornimmt. Allerdings untersagen die Regeln fr benutzerdefinierte Aktionen deren
Verwendung im Rahmen einer Produktankndigung, wie das auch durch ICE72 geprft wird. Da der
Chainer nichts anderes als eine benutzerdefinierte Aktion ist, sollte die Verwendung whrend der
Produktankndigung durch eine entsprechend definierte Bedingung unterbunden werden.
353
Kapitel 8
Bei der Programmierung eines eingebetteten Chainers ist eine Besonderheit zu beachten. Der Chainer
muss die Transaktion bernehmen, wozu er zwangslufig die ID der aktiven Transaktion bentigt. Die
ID wird der Befehlszeile zum Starten des Chainers vom Server-Prozess automatisch als Argument
angefgt. Es ist nicht sehr effektiv, unterschiedliche Chainer fr unterschiedliche Einsatzmglichkeiten
zu erstellen. Aus diesem Grund empfiehlt sich beim Bau des Chainers, die Befehlszeilenargumente zu
prfen und auszuwerten. Wird hierbei ein numerischer Wert bergeben, handelt es sich um
Transaktions-ID. Hieraus kann nun abgeleitet werden, dass bereits eine Transaktion existiert und diese
Transaktion bernommen werden muss, wie dieses auch in Listing 8.77 demonstriert wird. Mit dieser
einfachen Fallunterscheidung kann ein so definierter Chainer sowohl extern als auch eingebettet
verwendet werden. Auch Szenarien in denen mehrere Chainer verwendet werden, sind hiermit mglich
wie spter noch erlutert wird.
static void Main(string[] args)
{
// Transaktions-Id
uint transactionID = 0;
// berprfen ob Argument bergeben wurden
if (args.Length > 0)
{
// Argument 1 ist das Handle
if (!uint.TryParse(args[0], out transactionID))
throw new ArgumentOutOfRangeException("Invalid Handle");
}
// Neue Transaktion erzeugen und installieren
Program.Install(transactionID, Files);
}
private static void Install(uint transactionId, List<string> fileList)
{
// Transaktion bernehmen oder erstellen
if (transactionId == 0)
Installer.BeginTransaction();
else
Installer.JoinTransaction(transactionId);
try
{
foreach (string fileName in fileList)
{
// Installation der Pakete
Installer.InstallProduct(fileName, "ARPSYSTEMCOMPONENT =1");
}
// Transaktion abschlieen (Commit)
Installer.EndTransaction(true);
}
catch
{
// nderungen zurcknehmen
Installer.EndTransaction(false);
}
354
Kapitel 8
Listing 8.77: Prototyp eines extern und eingebettet zu verwendenden Chainers
Tabelle MsiEmbeddedChainer
Die Tabelle MsiEmbeddedChainer ermglicht die Speicherung und Referenzierung von einem oder
mehrere Chainern in einem Installationspaket. Hierdurch wird es mglich mehrere Pakete innerhalb
einer Transaktion zu installieren, ohne den Installationsprozess durch eine externe EXE-Datei
anzustoen. Die Tabelle MsiEmbeddedChainer ist wie folgt aufgebaut:
Spalte
Typ
Gre
Schlssel
Null
Beschreibung
MsiEmbeddedChainer
Identifier
s72
Condition
Condition
s255
Bedingung zur Ausfhrung des

Chainers
CommandLine
Formatted
s255
Eigenschaften, die der

Befehlszeile angefgt werden
knnen.
Source
CustomSource
s72
Quelle des Chainers.
Type
Integer
i2
Definition der Art der Quelle.
Eindeutige Identifizierung fr
den Datensatz
Tabelle 8.71: Struktur der Tabelle MsiEmbeddedChainer
MsiEmbeddedChainer: Enthlt eine eindeutige Bezeichnung fr den Chainer.

Condition: Zum Ausfhren des Chainers muss die Bedingung dieses Feldes erfllt sein. Gerade bei der
Verteilung von Softwarepaketen in Unternehmenslandschaften besteht mitunter die Notwendigkeit die
Verwendung eines Chainers zu deaktivieren, da hufig ein eigener Mechanismus fr die
Softwareverteilung eingesetzt wird. Die Deaktivierung ist durch eine Transformation mglich, die auf
diese Spalte abzielt. Weiterhin ist es durch diese Spalte auch mglich, die Verwendung des Chainers
bei einer Produktankndigung zu unterbinden.
CommandLine: Der Spalte CommandLine kann eine formatierte Zeichenfolge zugewiesen werden, die
beim Starten des Chainers an diesen bergeben werden soll. Das Handle der Transaktion wird der
Befehlszeile automatisch als erstes Argument angefgt. Wird diese Spalte auf Null gesetzt, wird nur
das Handle der Transaktion an den Chainer bertragen. Diese Spalte ist vergleichbar mit der Spalte
Target der Tabelle CustomAction bei der Verwendung von ausfhrbaren Dateien als benutzerdefinierte
Aktionen.
Source: Diese Spalte enthlt einen Verweis auf die ausfhrbare Chainer-Datei. Die Referenzierung
erfolgt durch den Schlssel zur Tabelle File, Binary oder Property.
Type: Hiermit kann der Typ der Chainer-Datei festgelegt werden. Diese Spalte ist identisch mit der
Spalte Type der Tabelle CustomAction, wobei die mglichen Typen beschrnkt sind. Die folgenden
Typen sind in der Chainer-Tabelle erlaubt, wobei alle anderen Kombinationen ignoriert werden. Bei
Typ 2 wird der im Binr-Stream befindliche Chainer temporr im Windows Installer-Ordner
gespeichert und von dort ausgefhrt. Bei den anderen Typen wird der Chainer aus dem angegebenen
Verzeichnis geladen.
Beschreibung
Typ
Spalte Source
Flags
355
Kapitel 8
Ausfhrbare Datei,
die in der Tabelle
Binary gespeichert
ist.
2 (0x2)
Referenz auf die

Tabelle Binary.
msidbCustomActionTypeExe +
msidbCustomActionTypeBinaryData
Ausfhrbare Datei,
die mit dem Produkt
installiert wird.
18 (0x12)
Referenz auf die

Tabelle File.
msidbCustomActionTypeSourceFile
Ausfhrbare Datei,
die durch einen
Eigenschaftswert
festgelegt ist.
50 (0x32)
Enthlt den
vollstndigen Pfad zu
der ausfhrbaren
Datei, der durch eine
Eigenschaft oder
durch eine Referenz
auf die Tabelle
Property angegeben
wird.
msidbCustomActionTypeProperty
Tabelle 8.72: Mglichen Typen zur Definition eines integrierten Chainers
Die Definition der Tabelle MsiEmbeddedChainer ist bei Windows Installer-XML durch das Element
<EmbeddedChainer/> mglich, wie dieses in Listing 8.78 gezeigt wird. Hierbei werden alle drei
Chainer-Arten definiert, wobei die Auswahl des zu verwendenden ber die Eigenschaft
RUNCHAINER gesteuert wird. Der Chainer, der ber eine Eigenschaft definiert wird (Typ: 50)
befindet sich im gleichen Verzeichnis wie das Installationspaket. Der vollstndige Pfad wird daher
durch die benutzerdefinierte Aktion SetChainer zugewiesen.
<Directory Id="INSTALLLOCATION" Name="$(var.ApplicationName)">
<Component Id="C__Chainer.exe" Guid="{07848269-6ECD-48d8-92DE-DDFB233215CE}">

<File Id="FileChainer" Source=".\Files\ " Name="EmbeddedChainer.exe" KeyPath="yes" DiskId="1" />
</Component>
</Directory>
</Directory>
</Directory>
<Property Id="RUNCHAINER" Value="1" />
<Property Id="PropertyChainer" Value ="EmbeddedChainer.exe"/>

<Binary Id="BinaryChainer" SourceFile=".\Files\EmbeddedChainer.exe" />

<EmbeddedChainer Id="Chainer1" CommandLine =""[CURRENTDIRECTORY]""
BinarySource="BinaryChainer">RUNCHAINER=1</EmbeddedChainer>
PropertySource="PropertyChainer">RUNCHAINER=2</EmbeddedChainer>
FileSource ="FileChainer">RUNCHAINER=3</EmbeddedChainer>
356
Kapitel 8

<CustomAction Id="SetChainer" Property="PropertyChainer" Value="[CURRENTDIRECTORY]EmbeddedChainer.exe" />
<InstallExecuteSequence >
<Custom Action="SetChainer" After="CostFinalize"/>
Listing 8.78: Festlegen eines Chainers in einem Windows Installer-XML-Dokument
Identifikation des integrierten Chainers

Der Windows Installer enthlt eine Logik, anhand dessen er die Verwendung eines integrierten
Chainers prft und steuert. Im Normalfall wird nach Beendigung der Aktion InstallFinalize geprft, ob
eine Transaktion aktiv ist und ob diese vom Server-Prozess bernommen wurde. Falls das zutreffend
ist, handelt es sich hierbei um die Transaktion, die bei der Installation eines einzelnen Paketes
automatisch erzeugt wurde. Somit kann problemlos MsiEndTransaction() aufgerufen werden, um die
Transaktion abzuschlieen. An dieser Stelle wird nun der angedeutete Algorithmus angewendet und
die Tabelle MsiEmbeddedChainer berprft. Das bedeutet, dass nur in dem Fall, in dem der ServerProzess der Eigentmer der Transaktion ist, diese Tabelle geprft wird. Wird die Installation
beispielsweise ber eine externe Chainer-Anwendung gestartet, ist der Chainer der Eigentmer der
Transaktion. In diesem Fall sind die Existenz und der Inhalt der Tabelle MsiEmbeddedChainer nicht
relevant.
Wie gesagt, die Existenz der Tabelle MsiEmbeddedChainer wird geprft, wenn der Server-Prozess der
Eigentmer der Transaktion ist. Dieses ist nur mglich, wenn ein Installationspaket direkt gestartet
wird, also entweder durch Doppelklick, durch Funktionen des Windows Installer-API oder durch
msiexec.exe. Darauf aufbauend wird nun geprft, ob in der Tabelle ein Chainer vorhanden ist, der auch
ausgefhrt werden kann. Das bedeutet, dass hierzu die Bedingungen ausgewertet werden. Wird ein
Chainer gefunden, ruft der Windows Installer nicht MsiEndTransaction() auf, sondern initiiert eine
paketbergreifende Transaktion, indem er den Chainer startet. Der Chainer muss die Transaktion durch
MsiJoinTransaction() bernehmen, um anschlieend weitere Installationen auszufhren und er muss
die Transaktion noch durch MsiEndTransaction() abschlieen. Falls nach Beendigung des ChainerProzesses noch eine Transaktion aktiv ist, interpretiert der Windows Installer dieses als
Installationsfehler und fhrt daher einen Rollback aus.
Es besteht natrlich die Mglichkeit, der Tabelle MsiEmbeddedChainer mehrere Chainer
hinzuzufgen. In diesem Fall sind die Bedingungen so zu definieren, dass maximal nur ein Chainer
aktiviert werden kann. Kommt es dennoch vor, dass bei mehreren Chainern die Bedingung zutrifft,
wird einer der Chainer verwendet, wobei nicht festgelegt ist, welcher das tatschlich sein wird. Dieses
ist eine sehr groe Fehlerquelle, so dass auf die Definition der Bedingung besonderer Wert gelegt
werden sollte.

In den ersten Ausfhrungen zu der neuen Funktionalitt der paketbergreifenden Transaktionen habe
ich bereits darauf hingewiesen, dass diese Transaktionen ber ein integriertes Rollback- und NeustartVerhalten verfgen. Das bedeutet, dass sowohl fr den Rollback als auch fr einen Neustart die
Transaktion als Einheit betrachtet wird oder zumindest betrachtet werden kann.
357
Kapitel 8
Szenarien fr einen Rollback

Eine der wesentlichen Aufgaben des Chainers ist die Modellierung und berwachung der transaktional
ausgefhrten Installationsprozesse. Hierbei ist es die Aufgabe des Chainers den Installationserfolg oder
Installationsmisserfolg festzustellen und angemessen darauf zu reagieren. Ein generischer Ansatz
wrde an dieser Stelle immer einen Rollback ausfhren, wenn die Installation mindestens eines
Paketes fehlschlgt. Die Flexibilitt des Chainers ermglicht jedoch an dieser Stelle abweichende
Verhaltensweisen zu integrieren um unterschiedlichen Anwendungsszenarien gerecht zu werden.
Zunchst muss jedoch zwischen den verschiedenen Rollback-Funktionalitten unterschieden werden.
Hier ist auf der einen Seite der paketbergreifende Rollback zu sehen, der im Rahmen einer
Transaktion zur Verfgung steht. Diese Rollback-Funktionalitt hat eher manuellen Charakter, da sie
normalerweise manuell ausgelst werden muss. Eine andere Form der Rollback-Funktionalitt ist aus
der Vergangenheit bereits bekannt. Hierbei handelt es sich um den Rollback unter Verwendung des
Rollback-Skriptes, der vom Windows Installer automatischen veranlasst wird, wenn die Installation
eines Paketes fehlschlgt. Diese Funktionalitt ist integraler Bestandteil der Windows InstallerTechnologie und kann durch die neuen Transaktionsoptionen nicht beeinflusst werden. Hieraus lsst
sich ableiten, dass es unerheblich ist, ob die Installation im Rahmen einer Transaktion oder
einzelstehend ausgefhrt wird. Kommt es zum Fehler werden die nderungen dieses Paketes
zurckgenommen. Allerdings kann diese automatische Rollback-Funktionalitt deaktiviert werden,
was in diesem Fall extreme Auswirkungen auf eine paketbergreifende Transaktion nehmen kann.
Deaktivieren der Rollback-Funktionalitt

Bei der Installation eines Paketes wird ein Rollback-Skript erzeugt, dass im Fehlerfall verwendet wird
um das System wieder in den ursprnglichen Zustand zu versetzen. Das Rollback-Skript wird im
Ordner config.msi des Systemlaufwerks gespeichert und von dem folgenden Eintrag in der
Systemregistrierung referenziert:
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts
Diesem Schlssel werden alle aktuellen Rollback-Skripte angefgt, wie dieses auch Abbildung 8.77
zeigt. Die Skripte und die Eintragungen in der Systemregistrierung sind nur fr die Installationsdauer
verfgbar. Nach Abschluss der Installation werden diese entfernt.
Abbildung 8.77: Schlssel Rollback in der Systemregistrierung
An dieser Stelle ist zu bercksichtigen, dass zum Wiederherstellen des Systemzustandes auch die
berschriebenen und gelschten Ressourcen bentigt werden. Aus diesem Grund werden diese in
einem speziellen Verzeichnis gesichert und erst nach Abschluss der Installation gelscht. Es wird
deutlich, dass diese Vorgehensweise sehr speicherintensiv sein kann und das gerade dieses Verhalten
mitunter problematisch zu sehen ist. Der Windows Installer wurde zu Zeiten entwickelt, in denen die
Kapazitten der Datentrger noch nicht die heutigen Dimensionen aufwiesen. Das sichern der
Ressourcen berstieg zum damaligen Zeitpunkt mitunter die Kapazitten der Datentrger, so dass eine
358
Kapitel 8
Installation theoretisch nicht durchgefhrt werden konnte. Um dennoch solche Problemfelder zu

adressieren, besteht die Mglichkeit die Rollback-Funktionalitt des Windows Installers zu
deaktivieren. Tabelle 8.73 zeigt die Mglichkeiten, mit denen die Rollback-Funktionalitt deaktiviert
oder geprft werden kann.
Aktion, Richtline, Eigenschaft
Beschreibung
Richtlinie: DisableRollback
Diese Einstellung verhindert, dass der Windows Installer den

ursprnglichen Systemzustand oder die Sequenz der nderungen
whrend einer Installation aufzeichnet. Zustzlich wird verhindert, dass
Windows Installer Dateien beibehlt, die spter gelscht werden sollen.
Somit kann der Windows Installer den Computer nicht in den
ursprnglichen Zustand zurcksetzen, falls die Installation nicht fertig
gestellt wird. Diese Richtlinie muss sowohl fr den Computer, als auch
fr den Benutzer festgelegt werden.
Aktion: DisableRollback
Diese Aktion deaktiviert die Rollback-Funktionalitt fr die

Installation. Ein Rollback wird nur fr die Aktionen deaktiviert, die in
der Sequenztabelle nach der Aktion DisableRollback ausgefhrt
werden. Die Rollback-Funktionalitt wird fr die gesamte Installation
deaktiviert, falls diese Aktion vor der Aktion InstallInitialize ausgefhrt
wird
Eigenschaft: DISABLEROLLBACK
Deaktiviert die Rollback-Funktionalitt fr die aktuelle Installation.
Eigenschaft:
PROMPTROLLBACKCOST
Durch diese Eigenschaft kann festgelegt, wie sich der Windows

Installer bei unzureichendem Speicherplatz verhalten soll. Es kann
festgelegt, dass die Installation fortgesetzt wird, aber die RollbackFunktionalitt deaktiviert wird.
Eigenschaft: RollbackDisabled
Durch diese Eigenschaft kann geprft werden, ob die RollbackFunktionalitt deaktiviert wurde.
Tabelle 8.73: Methoden zur Deaktivierung der Rollback-Funktionalitt des Windows Installers
Bei der Verwendung von paketbergreifenden Transaktionen fhren diese Einstellungen nicht mehr
zum erwarteten Ergebnis. Wurde die Rollback-Funktionalitt des Windows Installers durch die
Systemrichtlinie DisableRollback deaktiviert, schlgt der Aufruf der Funktion MsiBeginTransaction()
fehl und es wird ERROR_ROLLBACK_DISABLED zurckgeliefert. Dieses Verhalten liegt darin
begrndet, dass die Rollback-Fhigkeit des Windows Installers absolut notwendig ist, um
paketbergreifende Transaktionen durchzufhren. Dieses wird besonders deutlich, da die RollbackFunktionalitt nicht nur zu Beginn der Transaktion, sondern auch whrend der Transaktion geprft
wird.
Wird innerhalb einer aktiven Transaktion die Rollback-Funktionalitt durch die Richtlinie
DisableRollback oder die gleichnamige Standardaktion deaktiviert, schlgt die Installation des aktiven
Produktes mit ERROR_ROLLBACK_DISABLED fehl. Wird die Installation eines Produktes innerhalb
einer Transaktion ausgefhrt, wird vor dem Aufruf der Standardaktionen InstallExecute,
InstallExecuteAgain und InstallFinalize die Eigenschaft RollbackDisabled geprft. Wird an diesen
Prfpunkten festgestellt, dass der Rollback deaktiviert wurde, werden die bisherigen nderungen
zurckgenommen. Diese Rcknahme der nderungen ist natrlich nur mglich, falls nderungen
vorgenommen wurden und falls ein Rollback-Skript vorhanden ist. Wird beispielsweise bei der Aktion
InstallExecute festgestellt, dass der Rollback deaktiviert wurde, sind keine Aktionen erforderlich, da zu
359
Kapitel 8
diesem Zeitpunkt noch keine nderungen stattgefunden haben.
Fehler im Installationsprozess
Die gerade skizzierten Einstellungen knnen nicht in Verbindung mit paketbergreifenden
Transaktionen verwendet werden, so dass der Windows Installer automatisch in die Rollback-Phase
wechselt und die nderungen zurcknimmt, falls welche stattgefunden haben. Ein anderes Bild ergibt
sich bei den normalen Fehlern, die whrend der Acquisition- oder der Execution-Phase auftreten
knnen. Die Acquisition-Phase wird hier nur der Vollstndigkeit halber erwhnt. Sie kann
vernachlssigt werden, da hierbei keine nderungen am System vorgenommen werden und somit eine
Rcknahme der nderungen nicht erforderlich machen. Anders ist es whrend der Execution-Phase, da
hierbei das System modifiziert wird. Kommt es zum Fehler werden die durchgefhrten nderungen
vom Windows Installer automatisch zurckgenommen und der Fehlercode wird an den aufrufenden
Prozess zurckgegeben. Wurde die Installation im Rahmen einer Transaktion veranlasst, wird der
Fehlercode somit zum Chainer zurckgegeben. Der Chainer kann nun entscheiden, in welcher Form
ein Rollback durchgefhrt werden soll, wie das folgende Beispiel darstellt.
Der Chainer startet eine Transaktion indem MsiBeginTransaction() aufgerufen wird.
Der Chainer installiert nun Produkt A innerhalb der Transaktion, indem er MsiInstallProduct()
aufruft. Der Windows Installer prft zunchst, ob der Installationsaufruf gltig ist. Hierzu wird
geprft ob der Eigentmer der Transaktion und der aufrufende Prozess identisch sind.
Anschlieend ruft der Chainer MsiInstallProduct() fr Produkt B auf. Diese Installation ist
fehlerhaft und der Windows Installer fhrt einen Rollback fr Produkt B aus. Weiterhin gibt er
ERROR_INSTALL_FAILURE an den Chainer zurck.
Der Chainer stellt fest, dass es sich bei Produkt B um ein optionales Paket handelt. Er fhrt daher
mit der Installation von Produkt C fort.
Nach der erfolgreichen Installation von Produkt C fhrt der Chainer den Commit fr die
Produkte A und C durch indem er MsiEndTransaction() aufruft und
MSITRANSACTIONSTATE_COMMIT bergibt.
In dem Szenario wurde deutlich, dass durchaus unterschiedliche Prioritten fr die Installationspakete
vergeben werden knnen. Dieses wurde anhand einer optionalen Komponente verdeutlicht. Handelt es
sich bei Produkt B jedoch um eine erforderliche Komponente, mssen die nderungen der
Transaktion zurckgenommen werden. Hierzu beendet der Chainer die Transaktion mit
MSITRANSACTIONSTATE_ROLLBACK nachdem die Installation von Produkt B fehlgeschlagen ist.
Eine etwas andere Situation fr einen Rollback ergibt sich nach der Veranlassung durch den Benutzer.
Bei vielen Installationsformen findet sich eine Benutzeroberflche, in der unter anderem der Fortschritt
der Installation dargestellt wird. Vielfach befindet sich auf dieser Oberflche eine Option, die aktuelle
Installation abzubrechen. Einfach ausgedrckt sendet der Windows Installer eine Vielzahl von
Nachrichten an die Benutzeroberflche. Abhngig von der Art der Nachricht reagiert die Oberflche
hierauf in unterschiedlicher Weise. Die Benutzeroberflche muss jedoch die Nachricht beantworten
und kann somit die weitere Installation beeinflussen. Wird an dieser Stelle die Meldung mit
IDCANCEL beantwortet, wird die Installation mit der Fehlernummer 1602 (A user canceled
installation) beendet. Das bedeutet natrlich auch, dass automatisch ein Rollback auf Ebene des
Paketes durchgefhrt wird, um den Ursprungszustand des Systems wieder herzustellen. Auch hier kann
die Flexibilitt des Chainers ausgenutzt werden um individuelle Verhaltensmuster zu erreichen.
360
Kapitel 8
Fehler whrend der Commit-Phase

Die gerade dargestellten Ablufe bezogen sich auf Fehler oder Abbrche whrend der Acquisitionund der Execution-Phase. Ein leicht abweichendes Bild ergibt sich innerhalb der Commit-Phase, wie
das folgende Szenario demonstrieren soll:
Nach dem Starten einer Transaktion veranlasst der Chainer die Installation der Produkte A, B
und C.
Nach Fertigstellung ruft der Chainer MsiEndTransaction() mit
MSITRANSACTIONSTATE_COMMIT auf um die nderungen abzuschlieen.
dem
Argument
Whrend der Commit-Phase von Produkt B schlgt eine benutzerdefinierte Aktion fehl.
In diesem Szenario wird auch ein Rollback ausgefhrt und die nderungen werden zurckgenommen.
Problematisch sind hierbei jedoch benutzerdefinierte Aktionen die whrend der Commit-Phase
ausgefhrt wurden. Wurde hierdurch das System verndert, knnen diese Modifikationen nicht
zurckgenommen werden. Dieses ist nicht nur auf Produkt B bezogen, sondern auf alle Produkte,
bei denen die Commit-Phase bereits abgeschlossen wurde.
Mehrere Chainer
Die bisherigen Szenarien bezogen sich immer auf die Verwendung eines Chainers. Mitunter besteht
jedoch die Notwendigkeit mehrere Chainer zu verwenden. Diese Vorgehensweise birgt einige
Gefahrenpunkte, so dass das Design exakt durchdacht werden sollte. Zum besseren Verstndnis soll
zunchst ein kurzes Beispiel dienen.
Der Chainer fr Visual Studio startet eine Transaktion indem MsiBeginTransaction() aufgerufen
wird und installiert mehrere Produkte innerhalb dieser Transaktion durch den mehrfachen Aufruf
von MsiInstallProduct().
Visual Studio mchte einige Installationen durch den Chainer vom SQL Server ausfhren lassen.
Der Chainer des SQL Servers wird hierzu gestartet, indem CreateProcess() aufgerufen wird.
Wichtig ist hierbei die Transaktions-ID, die dem SQL-Chainer bergeben werden muss. Hierzu
wird diese in eine Zeichenfolge konvertiert, und der Befehlszeile zum Starten des SQL-Chainers
angefgt.
Der Chainer des SQL Servers veranlasst nun die Eigentumsbernahme der Transaktion, indem er
MsiJoinTransaction() aufruft. Der Windows Installer prft die Rechtmigkeit des
Eigentmerwechsels indem er den Token des aktuellen und des neuen Eigentmers vergleicht. Im
Weiteren stellt der Installer sicher, dass derzeitig keine Installation ausgefhrt wird.
Nachdem diese berprfungen erfolgreich abgeschlossen wurden, fhrt der Installer den Wechsel
des Eigentmers durch. Der Chainer des SQL Servers ist nun der Eigentmer der Transaktion.
Der SQL-Chainer installiert nun einige Produkte indem er MsiInstallProduct() ausfhrt. Nach der
Fertigstellung informiert er den Chainer von Visual Studio.
Der Chainer von Visual Studio bernimmt nun wieder die Transaktion durch den Aufruf von
MsiJoinTransaction().
Nach der Installation weiterer Pakete wird die Transaktion durch den Chainer von Visual Studio
abgeschlossen,
indem
MsiEndTransaction()
mit
dem
Argument
MSITRANSACTIONSTATE_COMMIT aufgerufen wird.
Bei der Umsetzung des Szenarios muss besonderes Augenmerk auf den Chainer des SQL Servers
361
Kapitel 8
gelegt werden. Kommt es bei der Installation eines Paketes zum Fehler, gilt es natrlich wieder, die
Prioritt des Paketes auszuwerten. Handelt es sich um ein optionales Paket, kann die Installation der
weiteren Pakete fortgesetzt werden. Im anderen Fall muss der Chainer die nderungen durch die
Transaktion auf alt bekannte Weise zurcknehmen. Hierbei ist zu bercksichtigen, dass es nur einen
Eigentmer fr die Transaktion gibt. Dieses ist derzeitig der SQL-Chainer, so dass sich ein Rollback
natrlich auch auf die Modifikationen des Chainers von Visual Studio beziehen. Dieses ist wichtig,
denn nachdem der SQL-Chainer seine Aufgaben durchgefhrt hat, findet ja wieder der Wechsel zum
Chainer von Visual Studio statt. Diesem Chainer muss nun das Ergebnis des bisherigen
Installationsverlaufs mitgeteilt werden, wozu der Exitcode verwendet werden kann. Im positiven Fall
bernimmt der Chainer die Transaktion, installiert weitere Pakete und schliet die Transaktion ab. Im
negativen Fall wurde die Transaktion bereits durch den SQL-Chainer beendet, so dass die bernahme
der bereits geschlossenen Transaktion zum Fehler fhrt.
Neustarts und Transaktionen

In einem eigenstndigen Kapitel dieses Buches wurde bereits detailliert auf Computerneustarts
eingegangen. Ein wesentlicher Abschnitt dieses Kapitels befasste sich mit dem Neustart-Manager von
Windows Vista und Windows Server 2008. Ziel dieses Neustart-Managers ist die Reduzierung der
Computerneustarts im Rahmen des Installationsprozesses. Die Notwendigkeit von Computerneustarts
bleibt natrlich trotz Neustart-Manager bestehen. Aus diesem Grund muss das Neustart-Verhalten im
Rahmen einer paketbergreifenden Installation mit dem Windows Installer 4.5 weitergehender
betrachtet werden, da hier die gesamte Transaktion zu bercksichtigen ist.
Kommt es whrend der Installation zu einem Computerneustart, muss der aktuelle Status des
Installationsfortschrittes gespeichert werden. Hierdurch wird es mglich, die Installation nach einem
Computerneustart an dieser Stelle fortzusetzen. Zu diesem Zweck wird vom Windows Installer zu
Beginn der Transaktion eine Binrdatei erzeugt, die als In-Progress-Datenbank oder kurz IPI-Datei
bezeichnet wird. Dieser Datei werden Informationen zum Produkt, zum Benutzer und zur aktuellen
Installationssequenz angefgt, so dass nach dem Neustart die Installation an dieser Stelle fortgesetzt
werden kann. Die IPI-Datei wird im Ordner %windir%\installer gespeichert und von dem Schlssel
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress der Systemregistrierung
referenziert, wie dieses auch Abbildung 8.78 zeigt.
Abbildung 8.78: Schlssel InProgress in der Systemregistrierung
Bei einer paketbergreifenden Transaktion wird die In-Progress-Datenbank nicht bentigt, da der
Windows Installer keinen Computerneustart innerhalb der Transaktion veranlasst.
Dateien in Verwendung
Die Aktion InstallValidate ist fr die Identifizierung von Dateien zustndig, die im Rahmen der
Installation ersetzt oder modifiziert werden mssen. Wird whrend dieser Aktion festgestellt, dass eine
zu aktualisierende Datei von einer anderen Anwendung verwendet wird, fhrt der Windows Installer
362
Kapitel 8
die folgenden Aktionen aus:

Der
Installer
sendet
die
Fenstermeldung
INSTALLMESSAGE_FILESINUSE
oder
INSTALLMESSAGE_RMFILESINUSE an den Client-Prozess. Hierbei bergibt er die Liste der
Prozesse, die beendet werden mssen. Wird auf die Fenstermeldung reagiert und werden die
jeweiligen Prozesse beendet, fhrt der Windows Installer mit der Kopieraktion fort und beendet die
Aktionen erfolgreich.
Werden
hingegen
die
Fenstermeldungen
oder
INSTALLMESSAGE_RMFILESINUSE ignoriert, wird die Funktion MoveFileEx() mit dem
Parameter MOVEFILE_DELAY_UNTIL_REBOOT verwendet, um die erforderliche Kopieraktion
nach dem Computerneustart zu beenden. Zustzlich wird das Reboot-Flag auf True gesetzt und die
Aktion wird beendet.
Das Installationsmodul fhrt anschlieend alle weiteren Aktionen der Sequenztabelle aus. Nach
Abschluss dieser Aktivitten wird das Reboot-Flag ausgewertet. Enthlt dieses den Wert False, wird
der Rckgabewert der Installationsprozedur auf ERROR_SUCCESS festgelegt, Wurde das Reboot-Flag
hingegen auf True gesetzt, wird fr die Rckgabe ERROR_SUCCESS_REBOOT_REQUIRED
verwendet. Dieser Rckgabewert wird schlielich an den Chainer bergeben, so dass dieser nach
Abschluss der Transaktion einen Computerneustart veranlassen kann.
Wie bereits angedeutet fhrt der Windows Installer keinen Computerneustart aus, wenn die Installation
innerhalb einer Transaktion erfolgt. In diesem Szenario ist es die Aufgabe des Chainers den Neustart
zu veranlassen. Die Eigenschaft REBOOT wird bei paketbergreifenden Transaktionen ignoriert, wie
dieses auch im Installationsprotokoll angezeigt wird.
MSI (s) (38:E4) [18:09:42:483]: Reboots are not supported from a multi-package transaction.
A reboot request was suppressed automatically.
Der schematische Ablauf zur Anforderung eines Neustarts innerhalb einer Transaktion wird in
363
Kapitel 8
Abbildung 8.79:
Dateioperationen
Schematischer
Ablauf
der
Neustartanforderung
hervorgerufen
durch
ausstehende
ScheduleReboot und ForceReboot

Die Aktionen ScheduleReboot und ForceReboot werden innerhalb von paketbergreifenden
Transaktionen nicht untersttzt. Werden diese Aktionen ausgefhrt wird die Installation mit dem
Fehlercode 1603 abgebrochen und die bereits durchgefhrten nderungen innerhalb der Transaktion
zurckgenommen. Im Installationsprotokoll finden sich die folgenden Hinweise:
MSI (s) (00:6C) [17:14:05:200]: Doing action: ForceReboot
DEBUG: Error 2622: Calling ForceReboot from a multi-package transaction is not supported.
oder
MSI (s) (00:18) [17:15:49:322]: Doing action: ScheduleReboot
DEBUG: Error 2623: Calling ScheduleReboot from a multi-package transaction is not supported.
364
Kapitel 8
Es wird deutlich, dass die Verwendung der Aktionen ScheduleReboot und ForceReboot nicht mehr
zukunftsorientiert ist, da moderne Technologien diese nicht mehr untersttzen. Unter diesem
Gesichtspunkt sollte die Verwendung dieser Aktionen in eigenen Installationspaketen kritisch
hinterfragt werden.
Ausstehende Dateioperationen
Befindet sich eine Datei zum Zeitpunkt der Aktion InstallFiles bereits im Zugriff, kann sie nicht ersetzt
werden. In diesem Fall lsst der Windows Installer die Datei whrend des nchsten Computerneustarts
ersetzen. Hierzu wird sie dem Registrierungsschlssel PendingFileRenameOperations angefgt, wie es
bereits im Kapitel 6 erlutert wurde. Hier wurde auch verdeutlicht, dass es zu Problemen fhren kann,
wenn die Datei durch mehrere Installationspakete aktualisiert wird. Der Algorithmus des
Betriebssystems zur Verarbeitung der ausstehenden Dateioperationen verwendet die FIFOReihenfolge, so dass die Datei des zuletzt installierten Paketes gewinnt und das Ergebnis markiert.
Falls alle Installationspakete ber die identische Dateiversion verfgen, kann dieses Problem
vernachlssigt werden. Werden hingegen unterschiedliche Dateiversionen durch die einzelnen Pakete
installiert, kann dieses zu einem Funktionsverlust bei dem installierten Produkt fhren.
Mit dem Windows Installer 4.5 wurde der Problempunkt adressiert. Im Rahmen der
paketbergreifenden Transaktion wird nun eine Tabelle verwendet, der alle Dateien angefgt werden,
bei denen noch Dateioperationen ausstehen. Die Tabelle enthlt zustzlich zu dem Dateinamen auch
die Versionsnummer, die Sprache und das Zielverzeichnis der Datei. Die Verwendung der Tabelle
wird nachfolgend skizziert. Der Algorithmus bercksichtigt den Modus der Installation, wobei die
Modi A, E und O relevant sind. Hiermit sind die Optionen gemeint, mit denen im Rahmen
einer Reparatur die Kriterien fr das berschreiben einer Datei festgelegt werden knnen. Im O-Modus
werden Dateien nur berschrieben, wenn eine ltere Version vorhanden ist. Ergnzend dazu werden im
E-Modus auch Dateien berschrieben, bei denen die Versionsnummer identisch ist. Im A-Modus
werden die Dateien letztlich immer berschrieben, so dass die Version unerheblich ist.
17. Whrend der Kopieraktion wird geprft ob die Tabelle bereits Eintragungen enthlt. Enthlt die
Tabelle keine Eintragungen, wird mit der Kopieraktion fortgefahren.
18. Sind hingegen Eintragungen vorhanden, wird zunchst geprft, ob die zu kopierende Datei bereits
in der Tabelle vorhanden ist. Falls die Datei in der Tabelle noch nicht vorhanden ist, wird sie in das
Zielverzeichnis kopiert. Allerdings wird hierbei die Standardversionierungsregel des Windows
Installers verwendet. Das bedeutet, dass die existierende Datei nur berschrieben wird, wenn die
neue Datei eine hhere Dateiversion aufweist oder wenn die Installation im A-Modus ausgefhrt
wird.
19. Ist die Datei in der Tabelle hingegen vorhanden, wird die Dateiversion mit dem Eintrag in der
Tabelle verglichen. Ist die Dateiversion kleiner oder gleich dem Eintrag in der Tabelle und wird die
Installation im O-Modus ausgefhrt, wird die Kopieraktion bersprungen.
20. Ist die Dateiversion hingegen grer als der Eintrag in der Tabelle oder wird die Installation im Aoder E-Modus ausgefhrt, wird zunchst die Versionsnummer der Tabelle aktualisiert. Weiterhin
wird das Ersetzen der Datei nach dem Computerneustart veranlasst indem MoveFileEx() ausgefhrt
wird.
Es sei noch anzumerken, dass nach den Kopieraktionen der Schritte 1 und 2, die Datei mit den
zugehrenden Metainformationen natrlich der Tabelle angefgt wird.
365
Kapitel 8

Der Benutzerkontensteuerung ist ein eigenes Kapitel dieses Buches gewidmet, so dass an dieser Stelle
nur noch zustzliche Erluterungen erfolgen, die sich auf paketbergreifende Transaktionen beziehen.
Hierbei gilt im Prinzip das gleiche, wie bei der Installation einzelner Pakete. Werden fr die
Installation erhhte Privilegien bentigt, muss die Verwendung explizit besttigt werden, wozu der
entsprechende UAC-Dialog dient. Das bedeutet auch, dass normalerweise die Besttigung fr jedes
Paket erfolgen muss, dass innerhalb der Transaktion installiert wird. Es besteht natrlich auch die
Mglichkeit, die Ausfhrungsprivilegien direkt im Chainer zu definieren. Verlangt der Chainer bereits
administrative Privilegien, erscheint der UAC-Besttigungsdialog bereits beim Starten des Chainers.
Der Installationsaufruf erfolgt dann mit den erhhten Privilegien, so dass keine weiteren Besttigungen
erforderlich sind. Zu beachten ist hierbei jedoch die bereits beschriebene Problematik bei der
Verwendung unterschiedlicher Benutzerprofile.
Es sollte deutlich werden, dass die Festlegung von Anwendungsprivilegien auf Ebene des Chainers
nicht unbedingt das Optimum bietet, da mitunter Anwendungseinstellungen in anderen
Benutzerprofilen vorgenommen werden. Effektiver und eleganter hingegen ist die Verwendung von
Zertifikaten, wobei die Vorgehensweise eine gewisse hnlichkeit zu den LUA-Patches aufweist. Das
Prinzip ist einfach. Das erste Paket der Transaktion muss ein Zertifikat enthalten und alle weiteren
Pakete mssen mit diesem Zertifikat digital signiert werden. In diesem Fall erscheint bei der
Installation des ersten Paketes der UAC-Dialog. Wird der Dialog besttigt, werden die
Anmeldeinformationen im Transaktionsobjekt zwischengespeichert und fr alle weiteren Pakete der
Transaktion verwendet, wenn diese digital signiert wurde.
Es wird deutlich, dass der wesentliche Punkt hierbei die Verwendung der Zertifikate betrifft. Hieraus
folgt, dass Installationspakete eine Mglichkeit aufweisen mssen, solche Zertifikate zu speichern. Die
bereits bekannte Tabelle MsiDigitalCertificate ermglicht die physische Speicherung der Zertifikate
im Binrformat innerhalb des Paketes. Mit Hilfe der neuen Tabelle MsiPackageCertificate werden
diese Zertifikate letztlich zweckorientiert zugeordnet. Es ist noch erforderlich, die Pakete digital zu
signieren, die innerhalb der Transaktion installiert werden sollen. Hierzu ist ein Zertifikat zu
verwenden, dass innerhalb der Tabelle MsiPackageCertificate referenziert wurde, wie auch das
folgende Windows Installer-XML-Beispiel zeigt:

<PackageCertificates>
<DigitalCertificate Id ="PackageCertificate" SourceFile ="$(var.CertificateFolder)Certificate.cer"/>
</PackageCertificates>
Letztlich ist es unerheblich ob zur Installation ein externer oder eingebetteter Chainer verwendet wird.
Entscheidend ist das erste Paket innerhalb der Transaktion. Verfgt dieses ber die Tabelle
MsiDigitalCertificate und enthlt diese ein gltiges Zertifikat, wird die Anzeige des UAC-Dialogs bei
den Paketen unterdrckt, die mit diesem Zertifikat digital signiert wurden. Das Installationsprotokoll
hebt dieses auch hervor.
MSI (s) (1C:34) [16:11:06:152]: Validating digital signature of file 'C:\Windows\Installer\20d60.msi'
MSI (s) (1C:34) [16:11:06:152]: File 'C:\Windows\Installer\20d60.msi' is a validly signed file and
validates according to authoring of MSI package
MSI (s) (1C:34) [16:11:06:152]: Package meets the LUA multi-package criteria
MSI (s) (1C:34) [16:11:06:152]: MSI_LUA: Credential prompt is not required at this point,
credentials for transaction already provided
366
Kapitel 8
Fr alle Pakete, die keine Signatur aufweisen, erscheint zwangslufig der UAC-Dialog. Wird dieser
nicht besttigt, wird die Installation beendet und die nderungen der Transaktion werden
zurckgenommen. Ein identischer Ablauf gilt bei Patches. Soll ein Patch innerhalb dieser Transaktion
angewendet werden, ohne dass ein UAC-Dialog erscheint, muss dieser Patch ebenfalls signiert werden.
Allerdings muss dieses mit einem Zertifikat geschehen, dass sich in der Tabelle MsiPatchCertificate
befindet.
Hinweis Beginn
Allgemeine Informationen zu den Zertifikaten, wie die Gltigkeitsdauer und die Mglichkeit der
digitalen Signatur wurden bereits im Kapitel 5 fr Windows Installer-Patches erlutert. Diese
Erluterungen sind sinngem auch auf Windows Installer-Pakete bertragbar.
Hinweis Ende
Fazit
Die Installationslandschaft im Rahmen der Anwendungsinstallation hat sich in den letzten Jahren
wesentlich verndert. Frher waren monolithische Anwendungen und auch Installationspakete
vorherrschend, die natrlich sehr einfach zu verteilen waren. Der Trend geht schon seit einiger Zeit in
eine komponentenorientierte Verteilungsform. Das bedeutet, dass mehrere kleinere Installationspakete
zusammengefasst das finale Produkt ergeben. Zur Realsierung solcher Installationsszenarien gab es in
der Vergangenheit mehrere Lsungsanstze, die aber alle irgendwelche Schachstellen aufwiesen. Erst
mit dem Windows Installer 4.5 wurde eine Technologie geschaffen, die es ermglicht, mehrere Pakete
innerhalb einer Transaktion zu installieren.
367
Kapitel 9
Externe Benutzeroberflchen

Fazit
369
371
377
392
415
Aktuell sind in der Softwareentwicklung neue Trends und Technologien zu verzeichnen, die dabei
helfen eine ansprechende Benutzeroberflche zu gestalten. Hierbei steht zum einen die technische
Realisierung im Fokus aber auch die Integration in das Gesamtbild moderner Betriebssysteme und die
Nutzung moderner Hardwarefunktionalitten. Windows Presentation Foundation (WPF) ist eine solche
Technologie. Hierbei handelt es sich um ein Grafik-Framework, das Bestandteil des Microsoft .NET
Frameworks 3.0 ist und erstmalig mit Windows Vista ausgeliefert wurde. Durch WPF wird ein sehr
modernes Programmiermodell zur Verfgung gestellt, in dem die Prsentations- von der
Geschftslogik getrennt wird. Die Benutzeroberflche wird hierbei in einer eigens entwickelten
Sprache definiert, die als XAML (eXtensible Application Markup Language) bezeichnet wird und auf
XML aufbaut. Mit WPF knnen sowohl Windows-Anwendungen als auch Web-Anwendungen erzeugt
werden, die wenn mglich, auch die Hardwarebeschleunigung der Grafikkarte verwenden. Eine
weitere Zielsetzung dieser Technologie liegt in der Vereinigung aller Bereiche, die fr eine
Prsentation relevant sind.
Benutzerschnittstelle
Zeichnen und Grafiken
Audio und Video
Dokumente
Typographie
Eine weitere neue Technologie zur Darstellung der Prsentationsebene ist Microsoft Silverlight.
Hierbei handelt es sich um eine reduzierte Version der Windows Presentation Foundation. Die
Zielsetzung dient der Darstellung und Animation von Oberflchen aus grafischen Elementen und
Media-Daten in Browsern. Microsoft Silverlight spricht ebenfalls XAML, verwendet aber nicht das
Microsoft .NET Framework 3.0, sondern benutzt eine reduzierte Variante davon.
Es wird deutlich, dass neue Mglichkeiten zur Verfgung stehen, ergonomische und ansprechende
Benutzeroberflchen zu gestalten, die sich mit bisherigen Darstellungsmglichkeiten nicht mehr
vergleichen lassen, wie Abbildung 9.80 zeigt.
368
Kapitel 9
Abbildung 9.80: Benutzeroberflche erstellt mit Windows Presentation Foundation
Es wird deutlich, dass die hierdurch bereitgestellten Mglichkeiten nahezu grenzenlos sind. Weiterhin
findet sich natrliche auch eine Anwendungs-Palette, die bei der Gestaltung solcher Oberflchen
erstklassige Arbeit leistet. Hier stellt sich natrlich die Frage nach der Nutzbarkeit in
Installationsprogrammen, die ich in diesem Kapitel beantworten mchte.

Benutzeroberflchen spiegeln sich nicht nur in Installationsprogrammen, sondern schwerpunktmig
natrlich auch in Anwendungsprogrammen wieder. Bei lteren Anwendungsprogrammen wirken die
Benutzeroberflchen hufig berladen oder unstrukturiert und sind fr den Benutzer nicht oder nur
teilweise intuitiv zu bedienen. Moderne Benutzeroberflchen sind in den meisten Fllen sehr gut
strukturiert und auch identisch aufgebaut, so dass der Benutzer diese neuen Anwendungen relativ
schnell einsetzen kann. Das beobachtete Verhalten bei den Anwendungsprogrammen ist nicht
vollstndig auf Installationsprogramme bertragbar. ltere wie Neue Installationsprogramme haben
keinen identischen Aufbau. Einige Programme zeigen vollkommen berladene Dialogfelder mit
Installationsoptionen an, andere hingegen fhren den Benutzer programmtechnisch durch diese
Einstellungen. In vielen Fllen sind die berlegungen des Entwicklers bei der Gestaltung der
Oberflche nicht mit denen des Benutzers zu vereinbaren, so dass dieser extreme Probleme bei der
Bedienung des Programms erfhrt. Zur Gestaltung eines ordentlich konzipierten
Installationsprogrammes sollten daher die folgenden Aspekte unbedingt bercksichtigt werden:
369
Kapitel 9
Bei der Ausfhrung der Installationsroutine erhlt der Benutzer erstmals Einblick in die
Anwendung. Jede noch so gute Anwendung wird zwangslufig durch die Verwendung eines
schlecht konzipierten Installationsprogrammes in einem negativen Licht dargestellt.
Das Erscheinungsbild des Installationsprogrammes ist einer der bedeutendsten Aspekte, sich von
einem Mitbewerber abgrenzen zu knnen.
Der Power-User sollte nicht als Mastab gesehen werden. In vielen Fllen wird die Installation von
Benutzern ausgefhrt, die eher als Laien bezeichnet werden knnen.
Die Interaktion mit dem Benutzer sollte sich ausschlielich auf die notwendigen Informationen
beziehen.
Es sollte nicht fr alles und jedes eine Besttigung vom Benutzer gefordert werden. Es ist
effektiver eine Programmlogik zu implementieren, die dem Benutzer einige Entscheidungen
abnimmt.
Der Windows Installer stellt Funktionen bereit, um funktionale und intuitive Benutzeroberflchen zu
gestalten, die den gerade dargestellten Richtlinien entsprechen. Whrend des Installationsprozesses
wird der Benutzer vor schwer verstndlichen Fragen geschtzt, wodurch sich die Installation auch fr
Laien einfacher gestaltet. Die hierzu bereitgestellte interne Benutzeroberflche wird vom Windows
Installer selbst dargestellt und verwaltet und ist sehr hufig anzutreffen. Sie basiert auf den
Eintragungen in den entsprechenden Tabellen der Windows Installer-Datenbank. Die Definition der
Benutzeroberflche erfolgt somit analog zum Design eines Installationspaketes. Die Vorgehensweise
zum Gestalten der Oberflche ist einfach, die sptere Darstellung ist zweckorientiert und allgemein
betrachtet entspricht eine solche Oberflche den meisten Anforderungen.
Hinweis Beginn
Bei der Erluterung der Toolsammlung Windows Installer-XML in Kapitel 2 wurden Mglichkeiten
vorgestellt, die Entwicklung von internen Benutzeroberflchen zu optimieren und zu vereinfachen.
Hinweis Ende
Gerade in der heutigen Zeit gibt es aber immer hufiger Szenarien, in denen die hiermit zu
realisierenden Mglichkeiten nicht mehr ausreichen. Die Problematik begrndet sich in der fehlenden
Flexibilitt und Erweiterbarkeit der Oberflche. Die hufigsten Kritikpunkte und Anforderungen sind
nachfolgend aufgefhrt:
Es wird kein HyperLink-Steuerelement zur Verfgung gestellt, so dass der gewohnte Zugriff auf
externe Ressourcen nicht erfolgen kann.
Die Anwenderfunktionen des RichEdit-Steuerelementes, in dem beispielsweise die
Lizenzbestimmung dargestellt wird, sind nicht ausreichend. Vielfach soll eine Mglichkeit
existieren, die Lizenzbestimmungen zu drucken oder zu speichern.
Die Verwendung von individuellen Steuerelementen wre wnschenswert, da hierdurch
Anwendungen und Installationsprogramm ber einen identischen Aufbau verfgen knnten.
Die Optionen zur Verwendung der Eingabehilfen (Accessibility options) sind vielfach nicht
ausreichend.
Das Steuerelement zur Auswahl der Features ist zu unflexibel und kann nicht erweitert werden. Es
besteht auch keine Mglichkeit die Features aller Pakete darzustellen, die im Rahmen einer
paketbergreifenden Transaktion installiert werden.
Es
370
besteht
keine
Mglichkeit
eine
gemeinsame
Oberflche
fr
alle
Pakete
einer
Kapitel 9
paketbergreifenden Transaktion zu definieren.

Ein Ausweg aus der Problematik besteht darin, die Benutzeroberflche auszulagern und in einer echten
Programmiersprache zu entwickeln. Hierbei steht natrlich der vollstndige Funktionsvorrat der
verwendeten Programmiersprache zur Verfgung, so dass die gestalterischen Mglichkeiten um
einiges effektiver sind. Natrlich knnen zur Gestaltung und Modellierung auch modernen
Technologien wie Windows Presentation Foundation verwendet werden. Relevant ist hierbei, dass die
Steuerung der Oberflche durch den Windows Installer erfolgt, die Darstellung jedoch durch die
eigene Implementierung.

Die Entwicklung einer individuellen Benutzeroberflche zur Verwendung mit dem Windows Installer
ist nicht trivial. Das hat vornehmlich damit zu tun, dass die Oberflche letztlich mit dem Windows
Installer-Dienst interagieren muss, was durchaus eine gewisse Komplexitt aufwirft. Zunchst muss
die Oberflche ber eine Mglichkeit verfgen, die Installation zu starten. Identisches gilt fr
eventuelle Abbruchbedingungen. Hier sollte es ber die Oberflche mglich sein, eine entsprechende
Abbruchmeldung an den Windows Installer zu senden. Zu beachten ist auch die gegenstzliche
Kommunikationsrichtung. Bisher wurden alle Aktivtten von der Benutzeroberflche gesendet, aber
auch der Empfang von Nachrichten muss sichergestellt werden. Hierdurch wird es mglich, den
Installationsfortschritt darzustellen oder auf entsprechende Zustnde und Zustandsmeldungen zu
reagieren. Stellt der Windows Installer beispielsweise fest, dass eine Datei verwendet wird oder dass
der verfgbare Speicherplatz nicht ausreicht, sollte dieses natrlich auch in der Benutzeroberflche
bercksichtigt werden. Zur Realisierung eines solchen Szenarios sind einige Aktionen erforderlich, die
im Folgenden sehr abstrakt skizziert werden:
Zunchst ist die externe Anwendung zu starten.
Diese Anwendung informiert den Windows Installer, dass alle oder nur bestimmte Meldungen an
diese Anwendung gesendet werden sollen.
Die Darstellung der internen Benutzeroberflche wird eingeschrnkt oder deaktiviert.
Die Installation des Produktes wird veranlasst.
Es wird deutlich, dass viele Faktoren in das Design einflieen und zustzliche Aktionen erfolgen
mssen, bevor eine externe Benutzeroberflche einen wirklichen Optimierungsfaktor darstellt.
Registrieren der externen Oberflche

Wie zuvor bereits dargestellt, findet eine intensive Kommunikation zwischen dem Windows InstallerDienst und der Benutzeroberflche statt. Um die erforderliche Verbindung auch zu einer externen
Benutzeroberflche herzustellen, muss eine Behandlungsroutine fr Nachrichten in die Anwendung
integriert werden. Das Windows Installer-API stellt zu diesem Zweck die beiden Funktionen
MsiSetExternalUI() und MsiSetExternalUIRecord() zur Verfgung. Die Zielsetzung beider Funktionen
ist identisch und die Verwendung im Wesentlichen auch. Einfach ausgedrckt werden dem
Funktionsaufruf ein Meldungsfilter, sowie eine Rckruffunktion (Callback) bergeben. Die
Rckruffunktion wird bentigt um die Nachrichten des Windows Installers zu empfangen und
entsprechend darauf zu reagieren. Hierbei handelt es sich somit um den Nachrichten-Handler. Durch
den Filter kann der Umfang der Nachrichten beeinflusst werden, so dass nur die tatschlich bentigten
371
Kapitel 9
Meldungen am Handler ankommen. Die Unterscheidung zwischen den Funktionen MsiSetExternalUI()

und MsiSetExternalUIRecord() liegt in dem Format, in dem die Meldungen zur Rckruffunktion
bertragen werden. Bei MsiSetExternalUI() wird der Nachrichteneinhalt als einzelne Zeichenfolge
bertragen. Hierdurch wird eine Logik erforderlich, mit der diese Zeichenkette in die einzelnen
Bestandteile zerlegt werden kann. Die Definition der Funktionen MsiSetExternalUI() ist nachfolgend
dargestellt. Hierbei ist zu erkennen, dass die Rckruffunktionen durch einen Delegaten vom Typ
ExternalUIHandler() abgebildet wird, der ebenfalls aufgezeigt wird.
internal static extern ExternalUIHandler MsiSetExternalUI(
[MarshalAs(UnmanagedType.FunctionPtr)] ExternalUIHandler puiHandler,
uint dwMessageFilter,
IntPtr pvContext);
internal delegate int ExternalUIHandler(
IntPtr context,
int messageType,
[MarshalAs(UnmanagedType.LPWStr)] string message);
Anders verhlt es sich bei der Funktion MsiSetExternalUIRecord(), die durchaus als effizienter
bezeichnet werden kann. Bei dieser Funktion wird der Nachrichteninhalt einem Objekt vom Typ
Windows Installer-Record zugewiesen, wodurch die einzelnen Bestandteile direkt vorliegen und somit
direkt angesprochen werden knnen. Die Verwendung eines Parsers zum Aufteilen der einzelnen
Meldungsparameter ist nicht erforderlich. Auch hier ist ersichtlich, dass wiederum ein Delegate fr die
Rckruffunktion erforderlich, der hierbei allerdings durch den Typ ExternalUIRecordHandler()
dargestellt wird.
DllImport("msi.dll", CharSet=CharSet.Unicode)]
internal static extern uint MsiSetExternalUIRecord(
[MarshalAs(UnmanagedType.FunctionPtr)] ExternalUIRecordHandler puiHandler,
uint dwMessageFilter,
IntPtr pvContext,
out ExternalUIRecordHandler ppuiPrevHandler);
internal delegate int ExternalUIRecordHandler(
IntPtr context,
int messageType,
int recordHandle);
Es wir deutlich, dass die Signaturen der beiden Funktionen ber gewisse hnlichkeiten verfgen, so
dass eine diesbezgliche Erluterung gemeinsam erfolgen kann. Die folgenden Parameter sind beim
Aufrufen der Funktionen zu verwenden:
puiHandler: Hiermit wird die Rckruffunktion festgelegt, die je nach Funktion eine bestimmte
Spezifikationen aufweisen muss. Wie bereits dargestellt ist bei der Funktion MsiSetExternalUI()
ein Delegate vom Typ ExternalUIHandler() zu verwenden. Bei MsiSetExternalUIRecord()
hingegen wird ein Delegate vom Typ ExternalUIRecordHandler() verwendet. Soll die
Registrierung eines existierenden Meldungs-Handlers aufgehoben werden, ist dieser Parameter auf
Null zu setzen. Ist es hingegen erforderlich, den aktuellen Nachrichten-Handler mit dem vorherigen
Handler zu berschreiben, ist die Funktion erneut aufzurufen, und der ursprngliche Handler ist
diesem Parameter anzufgen. Weiterhin ist dem Parameter dwMessageFilter der Wert 0
zuzuweisen.
372
Kapitel 9
dwMessageFilter: Legt fest welche Nachrichten an den externen Nachrichten-Handler gesendet

und von dort verarbeitet werden sollen. Die mglichen Nachrichtenarten sind in Tabelle
9.74dargestellt.
pvContext: Hiermit kann ein Zeiger auf einen Anwendungskontext definiert werden, der an die
Rckruffunktion bergeben wird. Dieser Parameter eignet sich auch fr Fehlerprfungen.
ppuiPrevHandler: Hierbei handelt es sich um einen Ausgabeparameter, der jedoch nur bei der
Funktion MsiSetExternalUIRecord() vorhanden ist. Es wird hierdurch der vorherige MeldungsHandler zurckgegeben. Falls noch keine Handler definiert wurde, wird Null zurckgegeben. Bei
der Funktion MsiSetExternalUI() wird ein vorheriger Handler als Rckgabewert der Funktion
geliefert.
Zusammenfassend lsst sich festhalten, dass zwei unterschiedliche Methoden existieren, eine externe
Benutzeroberflche zu registrieren und zu verwenden. Ein hierzu erforderlicher Nachrichten-Handler,
der durch die Funktion MsiSetExternalUIRecord() aktiviert wurde, empfngt Nachrichten im Format
eines Objektes vom Typ Windows Installer-Record. Ein Handler, der durch die Funktion
MsiSetExternalUI() festgelegt wurde, empfngt somit Nachrichten in Form einer Zeichenfolge. Es
wurde bereits darauf hingewiesen, dass ein vorheriger Handler durch den Aufruf der Funktion
berschrieben wird. Somit ist es nicht mglich, mehrere identische Handler zu verwenden. Allerdings
knnen Handler unterschiedlichen Typs verwendet werden. Das resultiert daraus, dass ein
Zeichenfolgenbasierter Handler, nicht durch eine Datensatzbasierten Handler berschrieben werden
kann. Gleiches gilt natrlich fr die umgekehrte Richtung. Zu beachten ist auch der Handler der
internen Benutzeroberflche, der ebenfalls noch aktiv sein kann. Der in solchen Szenarien
angewendete Algorithmus prft zunchst die Existenz eines datensatzbasierenden Handlers. Ist dieser
vorhanden, wird er auch zuerst verwendet. Betrachten Sie nochmal den fr diese externen Handler
relevanten Delegaten. Hier wird deutlich, dass es sich um Funktions-Delegaten handelt, denen ein
Rckgabewert als Ganzzahl zugewiesen werden muss. Liefert der datensatzbasierte NachrichtenHandler den Wert 0 zurck, so wird die Nachricht an einen eventuell vorhandenen
zeichenfolgenbasierten Handler weiter geleitet. Ist kein zeichenfolgenbasierter Handler registriert, wird
die Nachricht an den internen Handler weiter geleitet. Identisches gilt hierbei auch fr den
zeichenfolgenbasierten Handler. Wird allerdings vom externen Handler ein von 0 abweichender
Wert zurckgegeben, wird die Meldung als behandelt betrachtet. Das bedeutet, dass diese Nachricht an
keine nachfolgenden, externen Nachrichten-Handler weiter geleitet wird. Auch der interne Handler
wird hierdurch angewiesen, diese Informationen nicht mehr zur Darstellung der internen
Benutzeroberflche zu verwenden. Sie wird allerdings ins Installationsprotokoll bertragen, falls ein
solches erstellt wurde, und die Nachricht entsprechend geeignet ist. Tabelle 9.74 enthlt eine
Auflistung aller Nachrichten. Die mittlere Spalte gibt Auskunft darber, ab die Nachricht auch an ein
eventuelles Protokoll angefgt wird.
Hinweis Beginn
Eine externe Benutzeroberflche wird immer vor einer internen Benutzeroberflche aufgerufen.
Hinweis Ende
Bei der Verwendung einer externen Benutzeroberflche, wir der Darstellungsmodus fr die interne
Benutzeroberflche automatisch auf INSTALLUILEVEL_BASIC gesetzt. Das bedeutet, dass der externe
Nachrichten-Handler keine vollstndige Kontrolle ber die Benutzeroberflche erhlt, solange die
interne Benutzeroberflche aktiv ist, was hierdurch erreicht wird. Wie bereits angedeutet, werden alle
Nachrichten durch die interne Benutzeroberflche dargestellt, solange diese nicht vom externen
Handler als behandelt gekennzeichnet wurden. Hierbei wird die Basisoberflche angezeigt, die einen
373
Kapitel 9
statischen Text enthlt, wie dieses auch Abbildung 9.81 zeigt. Die Fortschrittsanzeige oder Hinweise
zum Installationsverlauf werden nicht ausgegeben.
Abbildung 9.81: Basisoberflche mit statischen Informationen
Das geschilderte Verhalten kann durchaus erwnscht sein, aber mitunter auch als strend empfunden
werden. Um solche Darstellungsformen der internen Benutzeroberflche zu vermeiden, ist sie zu
deaktivieren. Hierzu ist die Funktion MsiSetInternalUI() aufzurufen, wobei der Parameter dwUILevel
auf INSTALLUILEVEL_NONE gesetzt wird.
Wert
Protokoll
Bedeutung
INSTALLLOGMODE_
FILESINUSE
Ja
Dateien sind in Verwendung. Bein Empfang dieser Nachricht sollte ein

Dialog vom Typ FilesInUse angezeigt werden.
INSTALLLOGMODE_
FATALEXIT
Ja
Vorzeitige Beendigung der Installation.
INSTALLLOGMODE_
ERROR
Ja
Nachricht vom Typ Fehler.
INSTALLLOGMODE_
WARNING
Ja
Nachricht vom Typ Warnung.
INSTALLLOGMODE_
USER
Ja
Anfragen des Benutzers.
INSTALLLOGMODE_
INFO
Ja
Statusinformationen, die nicht angezeigt werden.
INSTALLLOGMODE_
RESOLVESOURCE
Ja
Festlegen einer gltigen Installationsquelle.
INSTALLLOGMODE_
RMFILESINUSE
Ja
Dateien sind in Verwendung. Bein Empfang dieser Nachricht sollte ein

Dialog vom Typ MsiRMFilesInUse angezeigt werden.
INSTALLLOGMODE_
OUTOFDISKSPACE
Ja
Der verfgbare Speicherplatz ist nicht ausreichend.
INSTALLLOGMODE_
ACTIONSTART
Ja
Beginn der durchzufhrenden Aktion.
INSTALLLOGMODE_
ACTIONDATA
Ja
Informationen zu den durchzufhrenden Aktionen.
INSTALLLOGMODE_
COMMONDATA
Ja
Parameter zur Initialisierung der Benutzeroberflche.
INSTALLLOGMODE_
PROGRESS
Nein
Informationen zum Fortschritt der Installation.
374
Kapitel 9
INSTALLLOGMODE_
INITIALIZE
Nein
Initialisieren der Benutzeroberflche. Eine vollstndige

Benutzeroberflche existiert zu diesem Zeitpunkt noch nicht. Wird die
Installation nicht unbeaufsichtigt durchgefhrt, wird die
Basisoberflche verwendet, die hier schon existiert.
INSTALLLOGMODE_
TERMINATE
Nein
Terminieren der Benutzeroberflche. Bei vollstndiger Oberflche

wurde diese bereits terminiert. Wird die Installation nicht im
unbeaufsichtigten Modus ausgefhrt, existiert die Basisoberflche noch
zu diesem Zeitpunkt.
INSTALLLOGMODE_
SHOWDIALOG
Nein
Wird ausgelst bevor ein Dialog bei vollstndiger Benutzeroberflche

angezeigt wird.
INSTALLLOGMODE_
INSTALLSTART
Ja
Installation des Produktes beginnt. Die Meldung enthlt die

Eigenschaften ProductName und ProductCode (Nur verfgbar mit
Windows Installer 4.5).
INSTALLLOGMODE_
INSTALLEND
Ja
Installation des Produktes ist abgeschlossen. Die Meldung enthlt die

Eigenschaften ProductName und ProductCode sowie einen
Rckgabewert (Nur verfgbar mit Windows Installer 4.5).
Tabelle 9.74: Mgliche Nachrichten zur Verwaltung durch einen externen Nachrichten-Handler
Wichtig Beginn
Es ist zu beachten, dass die Funktionen MsiSetExternalUI() und MsiSetExternalUIRecord() nur von
einer externen Anwendung aufgerufen werden knnen. Ein Aufruf aus einer benutzerdefinierten
Aktion ist nicht mglich. Weiterhin ist anzumerken, dass die Funktion MsiSetExternalUIRecord() erst
mit dem Windows Installer 3.1 zur Verfgung gestellt wurde.
Wichtig Ende
Darstellung der internen Oberflche

Wie vorhergehend beschrieben, wird die interne Benutzeroberflche auch dann verwendet, wenn eine
externe Benutzeroberflche registriert wurde. Um dieses zu vermeiden oder zu korrigieren, kann die
Darstellungsform der internen Oberflche unter Verwendung der Funktion MsiSetInternalUI()
verndert werden. In den meisten Fllen wird es darauf hinauslaufen, die interne Oberflche zu
deaktivieren oder nur eingeschrnkt zu verwenden, falls eine externe Oberflche verwendet wird.
Dieses ist aber nicht grundstzlich zu sehen, denn es existieren Anwendungsszenarien, in denen auch
die vollstndige interne Benutzeroberflche in Kombination mit einem externen Nachrichten-Handler
zu verwenden ist. Ich denke da an einen Debugger fr Installationspakete. Der externe Handler wird
bentigt um die Nachrichten des Installationsprozesses zu empfangen, aufzubereiten und in geeigneten
Formen darzustellen. Die interne Benutzeroberflche wird bentigt um den Installationsprozess zu
simulieren, wobei die Interaktion mit dem Benutzer einflieen muss. Unabhngig vom tatschlichen
Verwendungszweck, kann die Darstellung der internen Benutzeroberflche mit Hilfe der folgenden
Funktion beeinflusst werden.
internal static extern uint MsiSetInternalUI(
uint dwUILevel,
ref IntPtr phWnd);
375
Kapitel 9
Beim Verwenden der Funktionen sind die Argumente wie folgt zu verwenden:
dwUILevel: Durch diesen Parameter kann die Darstellungsform der Benutzeroberflche festgelegt
werden. Die mglichen Werte sind in Tabelle 9.75 zusammengefasst.
phWnd: Hierbei handelt es sich um einen Ein- und Ausgabeparameter. Dem Parameter kann ein
Fensterhandle zugewiesen werden. Das hiermit referenzierte Fenster wird als Eigentmer der
erzeugten Benutzeroberflche registriert. Nach erfolgreichem Aufruf der Funktion, wird diesem
Parameter der vorherige Besitzer der Benutzeroberflche zugewiesen. Wurde der Eigentmer nicht
verndert, wird Null zurckgegeben.
Wird die Funktion erfolgreich ausgefhrt, wird der Wert der vorherigen Darstellungsform
zurckgeliefert. Wird jedoch eine ungltige Darstellungsform als Parameter bergeben, wird
INSTALLUILEVEL_NOCHANGE zurckgegeben. Die Standarddarstellungsform die beim laden der
msi.dll festgelegt wird ist INSTALLUILEVEL_DEFAULT. Als Fenster-Handle wird die 0 bergeben,
so dass der Windows-Desktop als Eigentmer fungiert.
Wert
Beschreibung
INSTALLUILEVEL_
FULL
Verwendet die im Paket definierte Benutzeroberflche. Hierzu werden die WizardSequenz, die Fortschrittsanzeige und die Fehlerdialoge benutzt.
INSTALLUILEVEL_
REDUCED
Verwendet die im Paket definierte Benutzeroberflche. Hierbei wird die WizardSequenz nicht bercksichtigt.
INSTALLUILEVEL_
BASIC
Es wird die vom Windows Installer bereitgestellte Benutzeroberflche verwendet,

die aus der Fortschrittsanzeige, den Fehlerdialogen und einigen modalen Dialogen
(Dateien in Verwendung, Unzureichender Speicherplatz) besteht.
INSTALLUILEVEL_
DEFAULT
Der Windows Installer whlt eine angemessene Darstellungsform.
INSTALLUILEVEL_
NONE
Die Installation erfolgt im unbeaufsichtigten Modus, also ohne Darstellung einer

Benutzeroberflche.
INSTALLUILEVEL_
ENDDIALOG
Am Ende der erfolgreichen und auch fehlerhaften Installation wird ein modaler
Dialog angezeigt. Er wird jedoch nicht angezeigt, wenn die Installation vom
Benutzer abgebrochen wurde. Diese Option kann in Verbindung mit
INSTALLUILEVEL_BASIC, INSTALLUILEVEL_NONE und
INSTALLUILEVEL_DEFAULT verwendet werden.
INSTALLUILEVEL_
PROGRESSONLY
Der Installer zeigt eine einfache Fortschrittsanzeige. Er zeigt aber keine modalen
Dialogfelder und Fehlermeldungen an. Diese Option kann nur in Verbindung mit
INSTALLUILEVEL_BASIC verwendet werden.
INSTALLUILEVEL_
NOCHANGE
Die Darstellungsform der Benutzeroberflche wird nicht verndert. Wird phWnd

ein von Null abweichender Wert bergeben, wird das bergeordnete Fenster
gewechselt.
INSTALLUILEVEL_
HIDECANCEL
Der Installer zeigt eine einfache Fortschrittsanzeige, aber keine Schaltflche zum
Abbrechen der Installation. Hierdurch ist es dem Benutzer nicht mglich, die
Installation vorzeitig zu beenden. Diese Option kann nur in Verbindung mit
INSTALLUILEVEL_BASIC verwendet werden.
INSTALLUILEVEL_
SOURCERESONLY
In Kombination mit INSTALLUILEVEL_NONE werden bei der unbeaufsichtigten

Installation nur Dialoge angezeigt, um die Installationsquellen auszuwhlen. Bei
allen anderen Darstellungsformen, erzielt diese Option keine Wirkung. In
376
Kapitel 9
Verbindung mit einer externen Benutzeroberflche, wird die interne Darstellung

des Windows Installers zur Auswahl von Installationsquellen verwendet.
Tabelle 9.75: Festlegen der Darstellungsform einer internen Benutzeroberflche
Tipp Beginn
Bei Verwendung einer externen Benutzeroberflche in standardmigen Installationsszenerien

empfiehlt es sich, die interne Benutzeroberflche auf INSTALLUILEVEL_NONE in Kombination mit
INSTALLUILEVEL_SOURCERESONLY festzulegen.
Tipp Ende
Unter Verwendung der Deployment Tools Foundation ist die Realisierung einer externen
Benutzeroberflche wesentlich einfacher mglich, als sich nach der Betrachtung der zuvor genannten
Funktionen
vermuten
lsst.
Die
Klasse
Installer
des
Namensraums
Microsoft.Deployment.WindowsInstaller enthlt die fr diese Zwecke relevanten Funktionen
SetExternalUI() und SetInternalUI(). Zur Registrierung einer externen Benutzeroberflche ist
SetExternalUI() zu verwenden. Die erforderlichen Rckruffunktionen werden durch die Delegaten
ExternalUIHandler() und ExternalUIRecordHandler() modelliert. Die Referenz auf die Instanz der
Rckruffunktionen ist dem Funktionsaufruf SetExternalUI() anzufgen. Diese Funktion arbeitet mit
einer Parameterberlagerung, so dass beide Formen der Delegaten verwendet werden knnen, wie
Listing 9.79 zeigt.
/// <summary>
/// Installation starten
/// </summary>
private void Install(string fileName)
{
// Interne Benutzeroberflche konfigurieren
Installer.SetInternalUI(InstallUIOptions.Silent | InstallUIOptions.SourceResolutionOnly);
// Festlegen der Meldungen, die abonniert werden sollen
InstallLogModes logMode = InstallLogModes.ActionData |
InstallLogModes.ActionStart |
InstallLogModes.Progress;
// Festlegen des Textbasierten Nachrichten-Handlers
ExternalUIHandler textbasedHandler = new ExternalUIHandler(this.UIHandler);
Installer.SetExternalUI(textbasedHandler, logMode);
// Festlegen des Datensatzbsierten Nachrichten-Handlers
ExternalUIRecordHandler recordbasedHandler = new ExternalUIRecordHandler(this.UIRecordHandler);
Installer.SetExternalUI(recordbasedHandler, logMode);
// Produkt installieren
Installer.InstallProduct(fileName, string.Empty);
}
/// <summary>
377
Kapitel 9
/// Textbasierter Nachrichten-Handler

/// </summary>
private MessageResult UIHandler(InstallMessage messageType, string message,
MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton)
{
return MessageResult.None;
}
/// <summary>
/// Datensatzbasierter Nachrichten-Handler
/// </summary>
private MessageResult UIRecordHandler(InstallMessage messageType, Record messageRecord,
{
}
Listing 9.79: Basisimplementierungen zur Realisierung einer externen Benutzeroberflche
Dieses Beispiel soll nur die Basisimplementierung zeigen. Es ist erkennbar, dass zunchst die
Darstellungsform der internen Benutzeroberflche verndert wird, wobei diese nur verwendet wird,
falls eine Installationsquelle ausgewhlt werden muss. Diese Voreinstellung sollte immer
vorgenommen werden, da eine externe Benutzeroberflche diesbezgliche Meldungen zwar
empfangen aber keine Aktionen daraus ableiten kann. Im Weiteren werden die Instanzen der
jeweiligen Rckruffunktionen erstellt, die dann dem Funktionsaufruf SetExternalUI() angefgt
werden. Dieser Funktion werden ebenfalls die Nachrichtenarten bergeben, die vom externen Handler
behandelt werden sollen. Weiterhin sind die beiden Nachrichten-Handler erkennbar, die durch die
Funktionen UIRecordHandler() und UIHandler() reprsentiert werden. Es ist erkennbar, dass diese
den Wert None zurckliefern. Hierbei handelt es sich um einen Aufzhlungstypen der dem Wert 0
entspricht. Das bedeutet in diesem Szenario, dass zunchst die Rckruffunktion UIRecordHandler()
aufgerufen wird. Da diese den Wert 0 zurckliefert, wird auch die Funktion UIHandler() aufgeufen.
Da auch diese 0 liefert, wird die Nachricht auch an die interne Oberflche weiter geleitet. Die
Darstellung der internen Benutzeroberflche ist deaktiviert, so dass hier zunchst keine visuellen
Ausgaben erfolgen. Betrachten wir nochmal den Filter fr die Nachrichten. Es werden nur die
Nachrichten ActionData, ActionStart und Progress an den externen Handler bermittelt. Alle anderen
Nachrichtentypen werden in diesem Fall nicht weiter behandelt, da die interne Benutzeroberflche
deaktiviert wurde. Die Ausnahme davon betrifft das Szenario, in dem eine neue Installationsquelle
angegeben werden muss. Dieser wird durch die interne Oberflche behandelt, da die Darstellungsform
entsprechend gewhlt wurde.
Beeinflussung des Installationsprozesses

Wie bereits zuvor erlutert, muss dem Nachrichten-Handler ein Rckgabewert zugewiesen werden.
Dieser Rckgabewert entscheidet zunchst darber, ob die Nachricht auch an weitere Handler geleitet
werden soll. Darber hinaus wird dieser Rckgabewert auch zur Steuerung des Installationsprozesses
bentigt. Wird beispielsweise Cancel oder Abort zurckgegeben, wird die Installation mit dem
Fehlercode ERROR_INSTALL_USEREXIT (1602) beendet. Die mglichen Rckgabewerte unter
Verwendung der Deployment Tools Foundation werden durch den folgenden Aufzhlungstypen
definiert:
public enum MessageResult
{
378
Error
None
OK
Cancel
Abort
Retry
Ignore
Yes
No
Kapitel 9
= -1,
= 0,
= 1,
= 2,
= 2,
= 3,
= 4,
= 5,
= 6,
Hierbei ist zu bercksichtigen, dass die mglichen Werte von der Art der empfangenen Meldung
abhngig sind. Wird beispielsweise die Meldung InstallLogModes.ActionData empfangen, macht es
keinen Sinn diese mit MessageResult.Retry zu beantworten. Betrachten wir an dieser Stelle nochmal
die Signatur des Delegaten zur Definition eines datensatzbasierten Nachrichten-Handlers.
internal delegate int ExternalUIRecordHandler(
IntPtr context,
int messageType,
int recordHandle);
Betrachten Sie den fr die Erluterung relevanten Parameter messageType. Hierbei handelt es sich um
eine Ganzzahl, die zunchst Auskunft ber die empfangene Nachrichtenart gibt. Dieses ist aber nicht
alles, denn der Informationsgehalt kann weitaus hher sein. So kann dieser Parameter auch
Gestaltungsmerkmale eines Meldungsfelds (MessageBox) enthalten. Betrachten Sie zum besseren
Verstndnis das folgende Beispiel.
Es wird eine Installation unter Verwendung der Basisoberflche durchgefhrt. Das Kopieren einer
Datei kann nicht erfolgreich durchgefhrt werden, da diese Datei nicht vorhanden ist oder auf die Datei
nicht zugegriffen werden kann. In einem solchen Fall wird das in Abbildung 9.82 dargestellte
Meldungsfeld angezeigt.
Abbildung 9.82: Zugriffsfehler, da die Datei nicht gefunden wurde
Es ist erkennbar, dass dieses Meldungsfeld ber einen Hinweistext, ein Symbol und die Schaltflchen
Wiederholen und Abbrechen verfgt. Bei der Verwendung eines externen Nachrichten-Handlers ist die
Anzeige eines entsprechenden Hinweises ebenfalls erforderlich. Hierbei muss der Dialog natrlich
individuell kreiert werden, wozu die Gestaltungsinformationen bereitgestellt werden mssen. Es ist
nicht ausreichend, den Dialog alleine von der Nachrichtenart abhngig zu machen. So kann es sein,
dass fr eine Aktivitt unterschiedliche Reprsentationen eingesetzt werden. Wie in Abbildung 9.82
ersichtlich, wird bei einem Zugriffsfehler das dargestellte Meldungsfeld angezeigt. Allerdings ist das
nur die halbe Wahrheit. Die Datei, die nicht vorhanden ist, wurde in der Tabelle File mit dem Attribut
msidbFileAttributesVital gekennzeichnet. Das bedeutet, die Datei ist fr die zu installierende
Anwendung zwingend erforderlich. Aus diesem Grund stehen im Meldungsfeld auch nur die
Schaltflchen Abbrechen und Wiederholen zur Verfgung. Wrde es sich jedoch um keine durch
379
Kapitel 9
msidbFileAttributesVital gekennzeichnete Datei handeln, so enthlt das Meldungsfeld zustzlich die

Schaltflche Ignorieren, da die Kopieraktion rein formal bersprungen werden kann. Es wird deutlich,
dass die Darstellung der Dialoge von diversen Faktoren abhngig ist, so dass der genaue Aufbau und
Inhalt Bestandteil der jeweiligen Nachricht sein muss. Hieraus folgt, dass die als Ganzzahl dargestellte
Nachrichtenart in einzelne Bestandteile zu zerlegen ist, die letztlich den einzelnen
Gestaltungsmerkmalen zuzuordnen sind
private const
private const
private const
int msgType
int buttons
int icon
int defButton
int MB_ICONMASK
int MB_DEFMASK
int MB_TYPEMASK
= messageType &
= messageType &
= messageType &
= messageType &
= 0xF0;
= 0xF00;
= 0xF;
0x7F000000;
MB_TYPEMASK;
MB_ICONMASK;
MB_DEFMASK;
Die Verwendung der Deployment Tools Foundation vereinfacht diese Schritte erheblich. In der
Signatur der Nachrichten-Handler ist erkennbar, dass die Informationen zur Gestaltung des
Meldungsfeldes direkt bergeben werden, wie auch in Listing 9.80 gezeigt wird. Hierbei ist natrlich
zu bercksichtigen, dass die behandelten Meldungstypen auch beim Registrieren des Handlers
abonniert wurden.
private MessageResult UIRecordHandler(InstallMessage messageType, Record messageRecord,
{
switch (messageType)
{
case InstallMessage.Error:
// Ein Fehler ist aufgetreten. Die Hinweistexte und die Darstellungsoptionen
// fr das Hinweisfeld werden bernommen
return (MessageResult)MessageBox.Show(messageRecord.ToString(), "Error",
buttons, icon, defaultButton);
case InstallMessage.FatalExit:
return (MessageResult)MessageBox.Show(messageRecord.ToString(), "FatalExit",
default:
// Keine Behandlung der Nachricht. Diese soll durch den Windows Installer behandelt werden
}
}
Listing 9.80: Darstellung eines Meldungsfelds durch einen externen Nachrichten-Handler
Aus diesem Beispiel wir deutlich, dass der Rckgabewert in erster Linie von der Nachrichtenart und
darauf aufbauend vom Ergebnis des Meldungsfeld-Aufrufes abhngig ist. Allerdings gibt es
Rckgabewerte die jederzeit verwendet werden knnen und von keinem Meldungsfeld abhngig sind.
So kann jederzeit der Rckgabewert MessageResult.Error gesendet werden. Hiermit wird ausgedrckt,
dass im externen Nachrichten-Handler ein Fehler aufgetreten ist. Wird hingegen MessageResult.None
zurckgegeben, so besagt dieses, dass die Nachricht durch den externen Handler nicht behandelt wurde
und dass dieses durch den Installer erfolgen soll. Weiterhin existieren Meldungsarten wie
INSTALLMESSAGE_ACTIONDATA
und
INSTALLMESSAGE_PROGRESS,
die
keine
Darstellungsoptionen fr ein Meldungsfeld enthalten. Werden diese Meldungen mit
MessageResult.OK beantwortet, bedeutet dies, dass die Nachricht durch den externen Handler
380
Kapitel 9
behandelt wurde. Wird hingegen MessageResult.Cancel zurckgegeben, wird die Installation

abgebrochen.
Darstellung der Informationen

Im vorherigen Abschnitt wurden die Rckgabeoptionen der Nachrichten-Handler erlutert. Ein
relevanter Aspekt hierbei waren die verschiedenen Nachrichtenarten, die nun detailliert betrachtet
werden. Dieses ist insofern wichtig, da hierdurch zunchst der Nachrichtencharakter und die
Definitionen fr ein Meldungsfeld offengelegt werden. Ein weiterer wichtiger Aspekt betrifft natrlich
den Informationsgehalt der Meldung. Vielfach soll in einer externen Benutzeroberflche eine
Fortschrittsanzeige integriert und verwendet werden. Somit ist es natrlich erforderlich den Aufbau
und den Inhalt des zutreffenden Nachrichtentyps zu kennen, um eine solche Realisierung
durchzufhren.
Die Problematik beim Auswerten der einzelnen Meldungstypen wird durch die beiden Funktionen zur
Registrierung einer externen Benutzeroberflche erschwert. Das hat damit zu tun, dass der Inhalt der
Meldung durch unterschiedliche Objekte prsentiert wird. Bei der Verwendung des Delegaten
ExternalUIRecordHandler() in Verbindung mit der Funktion Installer.SetExternalUI() wird der
Nachrichteninhalt als Objekt vom Typ Microsoft.Deployment.WindowsInstaller.Record dargestellt. Bei
Verwendung des Delegaten ExternalUIHandler() wird der Nachrichteninhalt als Zeichenfolge
bergeben. Beispiele dafr sind:
CommonData: Message type: 1, Argument: Football 2008
ActionStart: Action 18:11:33: InstallFiles. Copying new files
Progress: 1: 1 2: 24000 3: 1 4: 0
User: Are you sure you want to cancel?
Info: Action start 18:11:32: InstallFinalize.
Es ist offensichtlich, dass die Zeichenfolge zunchst in ihre einzelnen Bestandteile zu zerlegen ist,
damit sie weiter verarbeitet werden kann. Bei der bergabe der Informationen als Record, kann dieser
Schritt bersprungen werden, da die Bestandteile der Nachricht bereits eigenen Feldern zugeordnet
wurden. Allerdings gibt es auch Informationen die nicht weiter zerlegt werden knnen und somit direkt
weiterzuverarbeiten sind. In der nachfolgenden Tabelle 9.76 sind die Nachrichtentypen aufgefhrt, die
eine einzelne Zeichenfolge enthalten und zustzlich ber Informationen zur Gestaltung eines
Meldungsfelds verfgen.
Meldung
Beispiel
Beschreibung
INSTALLMESSAGE_
FATALEXIT
Fatal error during installation.

Die Zeichenfolge kann direkt verwendet
werden.
INSTALLMESSAGE_
ERROR
Invalid Drive: E:\
Formatierte Fehlermeldung. Die

Zeichenfolge kann direkt verwendet
werden.
INSTALLMESSAGE_
WARNING
Original source path couldn't be

added to MSI sourcelist.
Formatierte Meldung vom Typ Warnung.

werden.
INSTALLMESSAGE_
INFO
Property(S): VersionMsi = 4.05
Formatierter Installationsprotokolleintrag.
381
Kapitel 9
werden.
INSTALLMESSAGE_
USER
Are you sure you want to cancel?
Formatierte Benutzermeldung durch ein

Meldungsfeld. Die Zeichenfolge kann
direkt verwendet werden.
INSTALLMESSAGE_
OUTOFDISKSPACE
Out of disk space -- Volume: 'E:';

required space: 561.916 KB;
available space: 2.730 KB. Free some
disk space and retry.
Formatierte Meldung die ausgegeben

wird, falls der verfgbare Speicherplatz
nicht ausreichend ist. Die Zeichenfolge
kann direkt verwendet werden.
Tabelle 9.76: Nachrichtentypen mit Informationen zur Gestaltung eines Meldungsfeldes
Der Installationsprozess oder besser gesagt, die durchzufhrenden Aktionen werden durch die
jeweiligen Sequenztabellen festgelegt. Bei einer Standardinstallation sind dieses die Tabellen
InstallUISequence und InstallExecuteSequence. Es ist bekannt, dass beide Tabellen zum Teil
identische Aktionen enthalten, so dass auf Grundlage des Aktionsnamens nicht ermittelt werden kann,
in welcher Sequenz und letztlich in welchem Prozess sie ausgefhrt werden. Ein solches Szenario lsst
sich aber ber die folgenden Nachrichten abprfen.
INSTALLMESSAGE_INITIALIZE und INSTALLMESSAGE_TERMINATE: Diese Nachrichten
kennzeichnen den Beginn und das Ende der Abarbeitung der UI-Sequenz. Sie enthalten keine weiteren
Daten. Obwohl bei einer unbeaufsichtigten und einer Basisinstallation die UI-Sequenztabelle nicht
verwendet wird, werden diese Nachrichten dennoch gesendet. Hieraus lsst sich verlsslich ableiten,
dass alle Aktionen, die nach INSTALLMESSAGE_TERMINATE ausgefhrt werden, aus der
Ausfhrungssequenz stammen und somit durch den Server-Prozess verarbeitet werden.
INSTALLMESSAGE_SHOWDIALOG: Diese Nachricht wird gesendet wenn ein Dialog angezeigt
wird. Entgegen den vorherigen Meldungen wird diese nur gesendet, wenn die UI-Sequenz tatschlich
verarbeitet wird, wie dass bei vollstndiger und reduzierter Benutzeroberflche der Fall ist. Diese
Nachricht verfgt ebenfalls ber den Namen des anzuzeigenden Dialogs, wie auch die nachfolgende
Aufrufsequenz darstellt:
Initialize:
ShowDialog:
ShowDialog:
ShowDialog:
ShowDialog:
Terminate:
PrepareDlg
WelcomeDlg
ProgressDlg
ExitDialog
INSTALLMESSAGE_RESOLVESOURCE: Im Rahmen der Installation muss auf die originale

Installationsquelle zugegriffen werden, die allerdings nicht verfgbar ist. Diese Meldung wird gesendet
um den Benutzer aufzufordern eine neue Installationsquelle festzulegen. Ein externer NachrichtenHandler kann diese Meldung abonnieren, allerdings kann er darauf nicht reagieren, da entsprechende
Funktionalitten in der aktuellen Windows Installer-Version nicht zur Verfgung stehen. Hier bleibt zu
hoffen, dass kommende Windows Installer-Versionen ber solche Funktionalitten verfgen werden.
Aktuell sollte darauf verzichtet werden, diese Meldung von einem externen Handler zu abonnieren.
Falls dieses jedoch unbedingt erforderlich sein sollte, ist die Meldung mit dem Rckgabewert 0 zu
beantworten, damit die erforderlichen Aktivitten vom Windows Installer gesteuert werden.
Hinweis Beginn
Wie bereits angesprochen, sollte die Darstellungsform der internen Benutzeroberflche auf
INSTALLUILEVEL_NONE in Kombination mit INSTALLUILEVEL_SOURCERESONLY festgelegt
382
Kapitel 9
werden.
Hinweis Ende
INSTALLMESSAGE_ACTIONSTART: Diese Nachricht wird beim Starten jeder durchzufhrenden

Installationsaktion gesendet. Sie enthlt den Namen und die Beschreibung der Aktion. Bei der
Verwendung eines zeichenfolgenbasierten Nachrichten-Handlers wird die Meldung im folgenden
Format bertragen:
Aktion [1]: [2]. [3]
Mit [1] wird die Uhrzeit angegeben, an der die Aktion gestartet wurde. Der Name der Aktion wird
durch [2] angegeben. Schlielich wird durch [3] eine Beschreibung der Aktion ausgedrckt. Der
Name der Aktion wird aus der jeweiligen Sequenztabelle bernommen. Die zugehrende
Beschreibung kommt hingegen aus der Spalte Description der Tabelle ActionText, oder wird durch den
Aufruf der Funktion MsiProcessMessage() im Klartext bergeben. Ein Beispiel fr diesen
Meldungstyp ist:
ActionStart: Action 10:02:05: InstallFiles. Copying new files
Die Verwendung eines datensatzbasierten Nachrichten-Handlers ist einfacher umzusetzen, da kein

Parsen der Zeichenfolge erforderlich ist. Die Nutzung der Deployment Tools Foundation vereinfacht
eine Umsetzung erheblich. Die Informationen werden hierbei einem Objekt vom Typ
Microsoft.Deployment.WindowsInstaller.Record zugewiesen. Dieses Objekt verfgt ber die
Eigenschaft FieldCount, in der die Anzahl der Felder abgelegt sind. Weiterhin existiert die Eigenschaft
FormatString, in der die Vorlage zur Darstellung der Meldung abgelegt ist. Diese Information befindet
sich auch im Feld mit dem Index 0. Programmtechnisch knnen die Informationen wie folgt
abgegriffen werden.
string
string
string
string
formatText = messageRecord.GetString(0);
name = messageRecord.GetString(1);
description = messageRecord.GetString(2);
message = messageRecord.ToString():
//
//
//
//
Action 10:02:05: [1]. [2]

InstallFiles
Copying new files
Action 10:02:05: InstallFiles. Copying new files
Es wird deutlich, dass die einzelnen Elemente ber die Methode Record.GetString(Index) ermittelt
werden knnen. Es werden auch noch Nachrichten vorgestellt, die entsprechende Informationen nicht
als Zeichenfolge, sondern als Ganzzahl bereitstellen. Um hier eine sptere Umwandlung des Datentyps
zu vermeiden, knnen diese Informationen durch Record.GetInteger(Index) abgerufen werden.
INSTALLMESSAGE_ACTIONDATA: Nachdem eine Aktion gestartet wurde und somit die
Nachricht INSTALLMESSAGE_ACTIONSTART gesendet wurde, knnen eine beliebige Anzahl
Nachrichten vom Typ INSTALLMESSAGE_ACTIONDATA empfangen werden. Diese Nachricht und
auch die internen Strukturen sind flexibel und orientieren sich an der jeweiligen Aktion. Hierzu wird
auf die Spalte Template der Tabelle ActionText zugegriffen. Diese enthlt beispielsweise fr die Aktion
InstallFiles den folgenden Eintrag:
File: [1] Directory: [9] Size: [6]
Das Objekt vom Typ Record enthlt in diesem Fall 9 Felder, die den folgenden Inhalt aufweisen.
0: {{InstallFiles: }}File: [1],
1: Football.exe
2:
Directory: [9],
Size: [6]
383
Kapitel 9
3:
4:
5:
6: 44032
7:
8:
9: C:\Program Files (x86)\Football 2008\
Durch die Funktion Record.ToString() werden die Parameter in die Vorlage eingefgt, die immer im
Feld mit dem Index 0 zu finden ist. Hierdurch ergibt sich die folgende formatierte Ausgabe:
File: Football.exe,
Directory: C:\Program Files (x86)\Football 2008\,
Size: 44032
Diese Option ist natrlich nicht nur auf diesen Nachrichtentyp begrenzt, sondern ist fr die anderen
Nachrichtenarten sinngem zu verwenden.
und
INSTALLMESSAGE_RMFILESINUSE:
Diese
Nachrichten werden gesendet, falls eine Datei in Verwendung ist, die durch die Installation
berschrieben oder gelscht werden soll. Die Nachricht INSTALLMESSAGE_RMFILESINUSE wird
gesendet, falls der Neustart-Manager von Windows Vista und Windows Server 2008 aktiv ist, und die
entsprechenden Manahmen veranlassen kann. Der Inhalt dieser Meldung ist davon abhngig ober der
zeichenfolgenbasierte Handler oder der datensatzbasierte Handler verwendet wird. Der
zeichenfolgenbasierte Handler enthlt lediglich den Hinweis, dass einige Anwendungen geschlossen
werden mssen. Der datenbankbasierte Handler liefert auch Informationen zu der Anwendung die
geschlossen werden sollte. Hierzu enthlt das Objekt vom Typ Record mehrere Felder. Im Feld mit
dem Index 0 befindet sich die Aufforderung zum Schlieen der Anwendung. Die Anzahl der
weiteren Felder ist abhngig von der Anzahl der zu schlieenden Anwendungen. Fr jede dieser
Anwendungen werden zwei Felder bentigt. Das erste Feld dieses Paares enthlt die Prozess-ID und
das zweite den Namen bzw. Titel der Anwendung, wie auch das folgende Beispiel zeigt.
0:
1:
2:
3:
4:
Die folgenden Anwendungen sollten geschlossen werden, bevor Sie die Installation fortsetzen:
2624
Winword
324
Outlook
Auf Basis dieser Informationen knnen sehr individuelle und komfortable Dialoge konstruiert werden,
wie das Beispiel aus Abbildung 9.83 zeigt:
384
Kapitel 9
Abbildung 9.83: Individueller Dialog zur Verwendung des Neustart-Managers
Der zuvor dargestellte Dialog enthlt Optionen um den weiteren Installationsprozess zu beeinflussen.
So ist es mglich die Anwendungen automatisch schlieen zu lassen oder die Installation abzubrechen.
Weiterhin ist es mglich die Anwendung in diesem Zustand zu belassen, so dass ein Computerneustart
erforderlich wird. Diese Optionen mssen natrlich nach dem Schlieen des Dialogs an den Windows
Installer bermittelt werden, wozu der Nachricht der entsprechende Rckgabewert zuzuweisen ist. Die
Nachricht INSTALLMESSAGE_RMFILESINUSE kann mit den in Tabelle 9.77 aufgefhrten Werten
beantwortet werden.
Rckgabe
Wert
Beschreibung
OK
Der Windows Installer veranlasst den Neustart-Manager die betroffenen

Anwendungen zu schlieen und nach der Installation neu zu starten.
Cancel
Die Installation wird abgebrochen.
Retry
Die Nachricht INSTALLMESSAGE_FILESINUSE wird gesendet.
Ignore
Die Aufforderung wird ignoriert und die Installation wird fortgesetzt. Ein
Computerneustart ist erforderlich.
No
Falls das Installationspaket ber den Dialog MsiRMFilesInUse verfgt, wird die
Nachricht 1610 gesendet. Falls ein solcher Dialog nicht vorhanden ist, wird die
Nachricht INSTALLMESSAGE_FILESINUSE gesendet.
Error
-1
Die Installation wird mit einem Fehler beendet.
Tabelle 9.77: Rckgabewerte der Nachricht INSTALLMESSAGE_RMFILESINUSE
Falls die Nachricht INSTALLMESSAGE_RMFILESINUSE weder vom externen noch vom internen
Handler
behandelt
wurde,
sendet
der
Windows
Installer
die
Nachricht
INSTALLMESSAGE_FILESINUSE. Wird auch diese Nachricht von keinem Handler behandelt und
bleiben die Anwendungen geffnet, ist ein Neustart des Computers erforderlich.
INSTALLMESSAGE_INSTALLSTART: Diese Nachricht steht erst mit dem Windows Installer 4.5
zur Verfgung und wird beim Starten der Installation eines Produkts gesendet. Die Nachricht besteht
aus zwei Feldern, wobei das erste Feld den Produktnamen und das zweite Feld den Produktcode
enthlt.
385
Kapitel 9
INSTALLMESSAGE_ INSTALLEND: Diese Nachricht steht erst mit dem Windows Installer 4.5 zur
Verfgung und wird nach dem Beenden eines Produkts gesendet. Die Nachricht besteht aus drei
Feldern, wobei das erste Feld den Produktnamen und das zweite Feld den Produktcode enthlt. Das
dritte Feld enthlt den Rckgabewert der ausgefhrten Top-Level-Aktion.
INSTALLMESSAGE_COMMONDATA: Hierbei handelt es sich um Nachrichten mit allgemeinen
Informationen zu Sprache, Produktname und Abbruchmglichkeiten. Dieser Nachrichtentyp wird bei
Verwendung einer externen Oberflche bentigt, um Meldungsfelder konfigurationsabhngig anpassen
zu knnen. Somit kann anhand dieser Meldung die Lokalisierung bestimmt und es knnen die
geeigneten Texte ermittelt werden. Darber hinaus kann der Titel des Meldungsfeldes richtig
festgelegt werden. Relevant ist auch die Schaltflche zum Abbrechen der Installation. Die Anzeige
dieser Schaltflche kann beispielsweise durch das Argument INSTALLUILEVEL_HIDECANCEL bei
Verwendung der Funktion SetInternalUI() verhindert werden. Diese Einstellung wirkt sich zunchst
nur auf die interne Oberflche aus, sollte aber auch bei der Darstellung der externen Oberflche
bercksichtigt werden.
Der Nachrichtentyp INSTALLMESSAGE_COMMONDATA besteht aus maximal drei Feldern. Jedes
Feld beginnt mit der Feldnummer der ein Doppelpunkt folgt und anschlieend weitere Daten enthlt,
wie dieses auch nachfolgend dargestellt wird:
1:<Daten> 2:<Daten> 3:<Daten>
Es mssen nicht immer alle Felder verwendet werden; es existieren auch Nachrichten, bei denen
Felder eine leere Zeichenfolge oder Null enthalten. Wichtig ist an dieser Stelle immer der Inhalt des
ersten Feldes, da hiermit der Informationsgehalt der Nachricht dargestellt wird. Ein Beispiel fr eine
Nachricht mit sprachspezifischen Informationen ist nachfolgend dargestellt:
1:0
2:1033
3:1252
Feld 1 enthlt hierbei den Wert 0, denn hierdurch wird eine Nachricht vom Typ
INSTALLMESSAGE_COMMONDATA gekennzeichnet, die Sprachinformationen (Language) enthlt.
Feld 2 enthlt die Sprachkennung (LANGID). In dem Beispiel ist dieses die 1033, die fr Englisch
steht. Feld 3 enthlt letztlich die Codepage, in dem Beispiel die 1252.
Enthlt das Feld 1 den Wert 1, wird damit eine Nachricht bezeichnet, die den Titel fr
Meldungsfelder enthlt (Caption). Dieser Titel resultiert letztlich aus dem Produktnamen und ist
gerade bei paketbergreifenden Transaktionen sehr hilfreich. Denn hiermit kann der Name des
Produktes abgerufen werden, das aktuell installiert wird.
1:1
2: Football 2008
3:Null
Wie bereits erlutert wird durch den Wert 1 im ersten Feld eine Nachricht definiert, die den Titel des
Produkts enthlt, der schlielich in Feld 2 zu finden ist. Feld 3 wird bei diesem Typ nicht verwendet
und enthlt Null oder eine leere Zeichenfolge. Ich bin bereits auf die Mglichkeit des Ausblendens der
Schaltflche Abbrechen zu sprechen gekommen. Enthlt das erste Feld der Nachricht den Wert 2,
wird hiermit der Status der Schaltflche Abbrechen (CancelShow) dargestellt wie das folgende
Beispiel zeigt:
1:2
2:1
Enthlt das Feld den Wert 0, wird hiermit ausgedrckt, dass die Schaltflche Abbrechen bei einer
internen Darstellungsform nicht angezeigt wird. Ein Wert von 1 bedeutet somit, dass die
386
Kapitel 9
Schaltflche angezeigt wird und die Installation somit auch abgebrochen werden kann. Eine
Zusammenfassung dieser Darstellungsformen ist in Tabelle 9.78 zu finden.
Beschreibung
Language
Caption
CancelShow
Feld 1
Feld 2
Enthlt die Sprachkennung.
Enthlt den Titel als

Zeichenfolge.
Bei 1 wird die

Schaltflche Abbrechen
angezeigt, bei 0
hingegen nicht.
Feld 3
Enthlt die Codepage.
Null
Null
Beispiel
1:0 2:1033
1:1 2: Football 2008

3:Null
1:2 2:1
3:1252
Tabelle 9.78: Aufbau und Inhalt der Nachricht INSTALLMESSAGE_COMMONDATA
Ein programmtechnischer Ansatz zum Ermitteln der einzelnen Informationen wird in Listing 9.81
dargestellt.
// Nachricht in die Bestandteile zerlegen und Variablen zuordnen
private void ProcessCommonDataMessage(Record dataRecord)
{
if (dataRecord == null || dataRecord.FieldCount == 0)
return;
int fieldCount = dataRecord.FieldCount;
int progressType = dataRecord.GetInteger(1);
switch (progressType)
{
case 0: // Sprache
if (fieldCount < 3)
return;
// Sprache bernehmen
this.langid = dataRecord.GetInteger(2);
this.codepage = dataRecord.GetInteger(3);
break;
case 1: // Titel
if (fieldCount < 2)
return;
// Titel bernehmen
this.productTitle = dataRecord.GetString(2);
break;
case 2: // Schaltflche Abbrechen
if (fieldCount < 2)
return;
// Schaltflche ausblenden wenn Feld 2 den Wert 0 enthlt
this.hideButton = (dataRecord.GetInteger(2) == 0);
387
Kapitel 9
break;
}
}
Listing 9.81: Programmtechnische Auswertung der Nachricht INSTALLMESSAGE_COMMONDATA
INSTALLMESSAGE_PROGRESS: Dieses ist die wahrscheinlich komplexeste und am hufigsten

gesendete Nachricht vom Windows Installer. Sie dient letztlich dazu, den Installationsfortschritt
darzustellen. Hierzu wird in der Regel ein Steuerelement vom Typ Fortschrittsanzeige (ProgressBar)
verwendet, so dass die bermittelten Informationen darauf abzubilden sind. Die Problematik dieses
Meldungstyps liegt in der Komplexitt des Installationsprozesses. So kann beim Starten der
Installation noch gar nicht abgesehen werden, wie umfangreich die Installation tatschlich werden
wird. Das bedeutet, dass der Bereich der durch die Fortschrittsanzeige dargestellt wird, dynamisch
verndert werden muss. Weiterhin ist auch die Darstellungsrichtung der Fortschrittsanzeige zu
bercksichtigen. Wie bei der INSTALLMESSAGE_COMMONDATA existieren hierbei auch wieder
unterschiedliche Nachrichtentypen, die mit Reset, ActionInfo, ProgressReport und ProgressAddition
bezeichnet werden. Interessant ist hierbei zunchst Reset. Ein externer Handler sollte solange keine
Aktivitten durchfhren bis die erste Nachricht vom Typ Reset empfangen wurde. Hiermit wird auch
die Anzahl der Teilstriche bermittelt, die zur Darstellung der Fortschrittsanzeige bentigt werden. Die
Nachricht ActionInfo bermittelt einen Wert um den die Fortschrittsanzeige bei jeder Nachricht vom
Typ INSTALLMESSAGE_ACTIONDATA zu verndern ist. Mit der Nachricht ProgressReport werden
die bereits fortgeschriebenen Teilstriche mitgeteilt. Schlielich wird mit ProgressAddition der
Begrenzungswert der Teilstriche verndert.
Zum besseren Verstndnis soll ein kleines Beispiel dienen, bei dem das Steuerelement ProgressBar
verwendet wird. Die relevanten Eigenschaften hierbei sind Maximum und Value. Mit Maximum wird
der hchste darstellbare Wert angegeben und mit Value der aktuellen Wert. Zunchst wird die
Nachricht Reset gesendet. Diese enthlt eine Ganzzahl die den Maximalwert darstellt und somit der
Eigenschaft ProgressBar.Maximum zugewiesen wird. Die Anzahl der fortzuschreibenden Teilstriche,
die mit der Meldung ActionInfo bermittelt wird kann durch die Methode ProgressBar.Increment()
beim Empfangen jeder Nachricht vom Typ INSTALLMESSAGE_ACTIONDATA erhht werden. Dieses
ist auch durch den mit ProgressReport bermittelten Wert mglich, der ProgressBar.Value
zugewiesen werden kann. Letztlich kann durch ProgressAddition der Maximalwert verndert werden,
so dass dieser Wert auf ProgressBar.Maximum zu addieren ist.
Dieser Nachrichtentyp besteht aus maximal vier Feldern, von denen der Inhalt des ersten Feldes den
Aufbau und den Verwendungszweck festlegt. Die weiteren Informationen sind in Tabelle 9.79
zusammengefasst.
Beschreibung
Reset
ActionInfo
ProgressReport
ProgressAddition
Feld 1
Feld 2
Maximale Anzahl
der Teilstriche.
Anzahl der
Teilstriche, um die
der Fortschritt bei
jeder Meldung vom
Typ
INSTALLMESSAGE_
ACTIONDATA
verndert wird.
Enthlt die Anzahl

der Teilstriche, um
die die
Fortschrittsanzeige
bisher verndert
wurde.
Enthlt eine Anzahl

von Teilstrichen,
um die die
maximale Anzahl
erhht werden
muss.
Feld 3
Richtung des
Falls dieses Feld 0
Wird nicht
Wird nicht
388
Kapitel 9
Fortschritts:
0 = Vorwrts,
1 = Rckwrts.
enthlt, ist der Inhalt

auf Feld 2 zu
ignorieren.
Bei 1 ist die
Fortschrittsanzeige
um den Wert aus
Feld 2 zu erhhen.
verwendet.
verwendet.
Feld 4
Ausfhrungsstatus:
0 = Berechnung
luft,
1 = Skript wird
ausgefhrt.
Wird nicht
verwendet.
Wird nicht
verwendet.
Wird nicht
verwendet.
Beispiel
1: 0 2: 68032 3: 0 4:
0
1: 1 2: 24000 3: 1 4:
0
1: 2 2: 32768 3: 0
4: 0
1: 3 2: 9000 3: 0 4:
0
Tabelle 9.79: Aufbau und Inhalt der Nachricht INSTALLMESSAGE_PROGRESS
Es wird deutlich, dass beim Konstruieren einer Fortschrittsanzeige einige Faktoren zu bercksichtigen
sind, die letztlich in das Design einflieen sollten. Im nachfolgenden Listing 9.82 findet sich ein
komplexes Beispiel zur Realisierung einer solchen Anforderung, bei dem die gesamte Logik in eine
eigene Klasse mit der Bezeichnung ProgressCounter ausgelagert wurde. Von dieser Klasse ist
zunchst eine Instanz zu erstellen, damit innerhalb des externen Nachrichten-Handlers darauf
zugegriffen werden kann. In diesem sind die folgenden Zeilen letztlich fr die Aktualisierung der
Fortschrittsanzeige erforderlich.
this.progressCounter.ProcessMessage(messageType, messageRecord);
this.progressBar.Value = (int)(this.progressBar.Minimum + this.progressCounter.Progress *
(this.progressBar.Maximum - this.progressBar.Minimum));
Der erste Befehl leitet die Nachricht an die Klasse weiter, in der die einzelnen Berechnungen
ausgefhrt und letztlich an die Eigenschaft Progress ein Wert zwischen 0 und 1 bergeben wird.
Diese Eigenschaft wird im nchsten Befehl angegriffen und mit den Eigenschaften Minimum und
Maximum der Fortschrittsanzeige kombiniert und anschlieend als Wert zugewiesen. Der
Programmcode zum Berechnen des Fortschritts ist relativ unspektakulr und sollte auch einfach
nachvollzogen werden knnen. Beim Instanziieren der Klasse kann ein Wert mit bergeben werden,
der die Gewichtung fr den skriptbasierten Installationsteil festlegt.
internal class ProgressCounter
{
private int maximumValue;
private int currentValue;
private int step;
private bool moveForward;
private bool enableActionData;
private int progressPhase;
private double scriptPhaseWeight;
//
//
//
//
//
//
//
Maximum
Aktueller Wert
Schrittgre
Fortschrittsanzeige vorwrts durchlaufen
Aktionsdaten werden hochgezhlt
Kennzeichnet die jeweilige Phase
Gewichtung der Skriptphase
// Eigenschaft ber die der aktuelle Fortschritt abgerufen werden kann.

public double Progress { get; private set; }
// Erstellt eine Instanz des Objektes
public ProgressCounter()
389
Kapitel 9
: this(0.5) {}
// Erstellt eine Instanz des Objektes. Ermglicht die Vernderung in der Gewichtung der Skriptphase
public ProgressCounter(double scriptPhaseWeight)
{
// Gltigkeit des Wertes prfen und Daten bertragen
if (!(0 <= scriptPhaseWeight && scriptPhaseWeight <= 1))
throw new ArgumentOutOfRangeException("scriptPhaseWeight");
this.scriptPhaseWeight = scriptPhaseWeight;
}
// Nachricht verarbeiten
public void ProcessMessage(InstallMessage messageType, Record messageRecord)
{
// Nachrichtentyp auswerten
{
case InstallMessage.ActionStart: // Start einer Aktion
if (this.enableActionData)
this.enableActionData = false;
break;
case InstallMessage.ActionData: // Aktionsdaten
if (this.enableActionData)
{
// Falls eine Meldung vom Typ ActionInfo empfangen wurde den aktuellen Wert verndern.
if (this.moveForward)
this.currentValue += this.step;
else
this.currentValue -= this.step;
this.UpdateProgress();
}
break;
case InstallMessage.Progress: // Fortschritt aktualisieren
this.ProcessProgressMessage(messageRecord);
break;
}
}
// Nachricht detailliert auswerten

private void ProcessProgressMessage(Record progressRecord)
{
if (progressRecord == null || progressRecord.FieldCount == 0)
return;
int fieldCount = progressRecord.FieldCount;
int progressType = progressRecord.GetInteger(1);
switch (progressType)
{
case 0: // Grundlegende Initialisierung
390
Kapitel 9
if (fieldCount < 4)
return;
// Progress-Phase bestimmen
this.progressPhase++;
// Maximalwert setzen
this.maximumValue = progressRecord.GetInteger(2);
if (this.progressPhase == 1)
this.maximumValue += 50;
// Richtung und aktuellen Wert bestimmen
this.moveForward = (progressRecord.GetInteger(3) == 0);
this.currentValue = (this.moveForward ? 0 : this.maximumValue);
break;
case 1: // Aktionsinformationen
if (fieldCount < 3)
return;
if (progressRecord.GetInteger(3) == 0)
{
}
else
{
// Schrittgre bestimmen, die beim Empfang der Nachricht ActionData verwendet wird
this.enableActionData = true;
this.step = progressRecord.GetInteger(2);
}
break;
case 2: // Aktuellen Wert anpassen
if (fieldCount < 2 || this.maximumValue == 0 || this.progressPhase == 0)
return;
if (this.moveForward)
this.currentValue += progressRecord.GetInteger(2);
else
this.currentValue -= progressRecord.GetInteger(2);
break;
case 3: // Maximalwert korrigieren
this.maximumValue += progressRecord.GetInteger(2);
break;
}
}
// Indikator fr Fortschritt aktualisieren
391
Kapitel 9
private void UpdateProgress()

{
if (this.progressPhase < 1 || this.maximumValue == 0)
{
// Noch keine Aktion erfolgt. Fortschritt zurcksetzen.
this.Progress = 0;
}
else if (this.progressPhase == 1)
{
// Ermitteln der Informationen (Acquisition-Phase)
this.Progress = this.scriptPhaseWeight *
Math.Min(this.currentValue, this.maximumValue) / this.maximumValue;
}
else if (this.progressPhase == 2)
{
// Ausfhrung des Skriptes (Execution-Phase)
this.Progress = this.scriptPhaseWeight + (1 - this.scriptPhaseWeight) *
Math.Min(this.currentValue, this.maximumValue) / this.maximumValue;
}
else
{
// Installation abgeschlossen.
this.Progress = 1;
}
}
}
Listing 9.82: Aktualisieren der Fortschrittsanzeige einer externen Benutzeroberflche

Die Verwendung einer externen Benutzeroberflche erweitert die Funktionalitt des Windows
Installers um ein Vielfaches. Die skizzierten Anforderungen lassen sich damit problemlos umsetzen
und somit die Einschrnkungen der internen Benutzeroberflche umgehen. Allerdings offenbart die
externe Oberflche noch einige Schwachpunkte, so dass eine Verwendung nur eingeschrnkt mglich
ist. Zur Verwendung einer externen Oberflche ist immer ein separater Prozess erforderlich, der den
Windows Installer ber diese Nutzung informiert. Was zunchst nicht sonderlich problematisch
aussieht, offenbart bei nherer Betrachtung doch erhebliche Problempunkte. Hieraus resultiert
allerdings der Umstand, dass nicht alle Installationsoptionen durch eine externe Benutzeroberflche
umgesetzt werden knnen. Wird beispielsweise eine Reparatur mit Hilfe des Dialogs Software der
Systemsteuerung durchgefhrt, wird die externe Oberflche niemals verwendet. Das hat damit zu tun,
dass diese Funktionsaufrufe in der Windows-Shell fest hinterlegt sind und somit immer das
Installationspaket aufgerufen wird und niemals die externe Anwendung. Gleiches gilt bei einer
administrativen Installation und bei einer Installation die im Rahmen einer automatischen Reparatur
ausgefhrt wird. Einige dieser Szenarien lassen sich durch individuelle Workarounds umgehen, aber
nicht alle. Ein weiteres Problem kommt bei der Verwendung von Softwareverteilungsmechanismen
zum Tragen. Viele dieser Technologie untersttzen ausschlielich die Verteilung von Windows
Installer-Dateien, bieten aber keine Mglichkeit ausfhrbaren Dateien zu verteilen. Aus diesen
Faktoren lsst sich zunchst ableiten, dass die Verwendung einer externen Benutzeroberflche als
vollwertiger Ersatz fr die interne Reprsentation nicht gewhrleistet werden kann.
392
Kapitel 9
Windows Installer 4.5 enthlt eine Funktionalitt die als integrierte externe Benutzeroberflche
(Embedded External UI) oder abgekrzt EEUI bezeichnet wird. Wie die Bezeichnung bereits
vermuten lsst, handelt es sich hierbei um eine externe Reprsentation, die in ein Installationspaket
integriert wurde. Einfach ausgedrckt wird hierzu die externe Oberflche als Objektbibliothek (.dll)
kompiliert und in einem spezifischen Datenspeicher des Installationspaketes abgelegt. Whrend der
Installation prft der Windows Installer die Existenz einer solchen Bibliothek und verwendet dieses
dann zur Darstellung der Benutzeroberflche. Durch diesen genderten Ansatz zur Darstellung der
Oberflche und noch einige technische Umsetzungen, knnen damit die folgenden Anforderungen
umgesetzt werden:
Mglichkeit der Integration einer externen Benutzeroberflche in ein Installationspaket, wobei alle
gestalterischen Freiheiten beim Design der Oberflche vorhanden sind.
Verwendung der Benutzeroberflche in allen Szenarien, wobei die gewhlte Aktivierungsart zur
Durchfhrung der Installation unerheblich ist.
Verwenden der Benutzeroberflche oder einer speziell angepassten Variante auch in Szenarien, in
denen der Benutzer die Installation unter Verwendung der Basis-Oberflche durchfhrt.
Effiziente Umsetzung, da nicht alle Darstellungen in der externen Oberflche abgebildet werden
mssen. Es besteht die Mglichkeit bestimmte Optionen von der internen Reprsentation erledigen
zu lassen.
Deaktivierung der Darstellung einer integrierten externen Oberflche durch Systemrichtlinien oder
installationsbezogene Eigenschaften.
Verwenden der externen Oberflche auch im Rahmen von paketbergreifenden Transaktionen als
zentrale Oberflche fr alle Pakete.
Es wird deutlich, dass durch diese Funktionalitt die aufgezeigten Problempunkte der Vergangenheit
angehren und somit interessante Alternativen zur internen Reprsentation gefunden wurden.
Integration
Bevor ich auf die programmtechnische Umsetzung einer solchen Oberflche zu sprechen komme,
werde ich zunchst die datenbankspezifische Integrationsmglichkeit erlutern. Dieses ist insofern
notwendig, da hierbei bestimmte Faktoren beeinflusst werden knnen, die im Rahmen der
Programmierung relevant sein knnten. Zur Integration einer externen Benutzeroberflche existiert
eine neue Datenbanktabelle mit der Bezeichnung MsiEmbeddedUI, die ber folgenden Aufbau verfgt.
Spalte
Typ
Gre
Schlssel
Null
Beschreibung
MsiEmbeddedUI
Identifier
s72
FileName
Filename
l255
Name der Objektbibliothek.
Attributes
Integer
i2
Konfigurationsoptionen.
MessageFilter
DoubleInteger
i4
Data
Binary
v0
Eindeutige Identifizierung fr den

Datensatz.
Filter fr die Nachrichten.

Binrer Datenspeicher.
Tabelle 9.80: Struktur der Tabelle MsiEmbeddedUI
MsiEmbeddedUI: Enthlt eine eindeutige Bezeichnung fr den Datensatz.
393
Kapitel 9
FileName: Hiermit wird der Name festgelegt unter dem die Dateien zur Darstellung der Oberflche
auf dem lokalen System gespeichert werden. Die erforderlichen Dateien befinden sich physisch in dem
Datenspeicher des Feldes Data. Whrend der Installation werden diese extrahiert und unter dem
definierten Namen in einem temporren Verzeichnis gespeichert und von dort verwendet. Die Angabe
des Dateinamens erfolgt im bekannten SFN|LFN-Format (Short FileName|Long Filename) des
Windows Installers. Beim extrahieren wird das lange Dateiformat verwendet, wenn dieses vom
Dateisystem untersttzt wird. Problematisch kann es werden, wenn mehrere Datenstze in dieser
Tabelle vorhanden sind, sich aber der Inhalt dieser Spalte nicht unterscheidet. Hierbei wird letztlich
eine Datei auf dem System abgelegt, aber welche das ist, kann nicht beeinflusst werden.
Attributes: Bei dieser Spalte handelt es sich um ein Bit-Feld, dass die in Tabelle 9.81 dargestellten
Werte aufnehmen kann. Hiermit ist es mglich, zustzliche Informationen zu den binren Daten der
Spalte Data bereit zustellen.
Name
Wert
Beschreibung
None
0 (0x00)
Bei der Datei handelt es sich um keine Objektbibliothek zur

Darstellung der Benutzeroberflche. Bei der Datei handelt es
sich somit um eine Ressource oder eine Support-Datei.
msidbEmbeddedUI
1 (0x01)
Hierbei handelt es sich um die primre Bibliothek zur

Darstellung der Benutzeroberflche. Es drfen nicht mehrere
Eintragungen mit diesem Attribut gekennzeichnet werden. Falls
das dennoch geschieht, kann nicht garantiert werden, welche
Bibliothek verwendet wird.
msidbEmbeddedHandlesBasic
2 (0x02)
Hierdurch wird der Windows Installer angewiesen, zur

Darstellung der Basisoberflche ebenfalls die externe
Oberflche zu verwenden. Dieses Attribut wird ignoriert, falls
es nicht in Kombination mit msidbEmbeddedUI verwendet
wird.
Tabelle 9.81: Spezifizieren der zugeordneten binren Daten
MessageFilter: Hiermit knnen die Nachrichten definiert werden, die an die externe Oberflche
gesendet werden sollen. Dieses Verfahren ist analog zur bereits erluterten Filterung von Nachrichten
unter Verwendung der Funktionen MsiSetExternalUI() und MsiSetExternalUIRecord() zu sehen. Die
Informationen dieser Spalte sind jedoch nur relevant, wenn das Attribut msidbEmbeddedUI fr diesen
Datensatz festgelegt wurde. In diesem Fall darf der Inhalt dieses Feldes nicht Null sein. Im Gegensatz
dazu, darf das Feld Null enthalten, wenn der Datensatz eine Ressource-Datei reprsentiert und die
Spalte Attributes 0 enthlt.
Dieser Spalte kann ein Wert zugewiesen werden, der eine Kombination aus den Elementen der Tabelle
9.82 darstellt. Die hier aufgefhrten Nachrichtentypen sind identisch mit denen, die bei der klassischen
Verwendung einer externen Oberflche zur Verfgung stehen.
Nachricht
InstallMessage
Wert
Bedeutung
INSTALLLOGMODE_
FATALEXIT
FatalExit
1 (0x00001)
INSTALLLOGMODE_
ERROR
Error
2 (0x00002)
Nachricht vom Typ Fehler.
INSTALLLOGMODE_
Warning
4 (0x00004)
Nachricht vom Typ Warnung.
394
Kapitel 9
WARNING
INSTALLLOGMODE_
USER
User
8 (0x00008)
Anfragen des Benutzers.
INSTALLLOGMODE_
INFO
Info
16 (0x00010)
Statusinformationen, die nicht angezeigt werden.
INSTALLLOGMODE_
FILESINUSE
FilesInUse
32 (0x00020)
Dateien sind in Verwendung.
INSTALLLOGMODE_
RESOLVESOURCE
ResolveSource
64 (0x00040)
Festlegen einer gltigen Installationsquelle.
INSTALLLOGMODE_
OUTOFDISKSPACE
OutOfDiskSpace
128 (0x00080)
Der verfgbare Speicherplatz ist nicht ausreichend.
INSTALLLOGMODE_
ACTIONSTART
ActionStart
256 (0x00100)
Beginn der durchzufhrenden Aktion.
INSTALLLOGMODE_
ACTIONDATA
ActionData
512 (0x00200)
Informationen zu den durchzufhrenden Aktionen.
INSTALLLOGMODE_
PROGRESS
Progress
1024 (0x00400)
Informationen zum Fortschritt der Installation.
INSTALLLOGMODE_
COMMONDATA
CommonData
2048 (0x00800)
Parameter zur Initialisierung der

Benutzeroberflche.
INSTALLLOGMODE_
INITIALIZE
Initialize
4096 (0x01000)
Initialisieren der Benutzeroberflche.
INSTALLLOGMODE_
TERMINATE
Terminate
8192 (0x02000)
Terminieren der Benutzeroberflche.
INSTALLLOGMODE_
SHOWDIALOG
ShowDialog
16384 (0x04000)
Wird ausgelst bevor ein Dialog bei vollstndiger

Benutzeroberflche angezeigt wird.
INSTALLLOGMODE_
RMFILESINUSE
RMFilesInUse
33554432
(0x02000000)
Dateien sind in Verwendung.
INSTALLLOGMODE_
INSTALLSTART
InstallStart
67108864
(0x04000000)
Installation des Produktes beginnt. Die Meldung

enthlt die Eigenschaften ProductName und
ProductCode (Nur verfgbar mit Windows
Installer 4.5).
INSTALLLOGMODE_
INSTALLEND
InstallEnd
134217728
(0x08000000)
Installation des Produktes ist abgeschlossen. Die

Meldung enthlt die Eigenschaften ProductName
und ProductCode, sowie den Rckgabewert der
Top-Level-Aktion (Nur verfgbar mit Windows
Installer 4.5).
Tabelle 9.82: Mgliche Werte zum Filtern der Nachrichten
Data: Diese Spalte enthlt die tatschlichen binren Daten, also die Objektbibliothek oder die
Ressource-Dateien. Wurde in der Spalte Attribute der Wert msidbEmbeddedUI verwendet, muss dieses
Feld eine Objektbibliothek beinhalten. Im anderen Fall kann dieses Feld eine Datei im beliebigen
Format enthalten.
395
Kapitel 9
Die Definition der Tabelle MsiEmbeddedUI ist mit Windows Installer-XML durch das Element
<EmbeddedUI/> mglich, wie dieses auch in Listing 9.83 dargestellt wird. Erfolgen keine weiteren
Angaben, werden alle Nachrichten an die externe Oberflche weitergeleitet. Sollen Nachrichten
hingegen von der internen Reprsentation verarbeitet werden, ist dieses mit Hilfe spezieller Attribute
mglich.
<UI>
<EmbeddedUI Id="TestUI" Name="MSIUI.dll" SourceFile =".\Files\EEUI.CA.dll"
IgnoreResolveSource="yes" SupportBasicUI="no">
<EmbeddedUIResource Id="Image1" Name="Setup.png" SourceFile =".\Files\Setup.png"/>
</EmbeddedUI>
</UI>
Listing 9.83: Definition einer integrierten externen Benutzeroberflche in einem Windows Installer-XMLDokument
Wie bereits eingehend erlutert, existiert keine Mglichkeit der Festlegung von Installationsquellen
aus einer externen Benutzeroberflche. Aus diesem Grund wurde das Attribut IgnoreResolveSource
auf Yes gesetzt, so dass diese Nachrichten an die interne Benutzeroberflche weiter geleitet und dort
verarbeitet werden. Voraussetzung dafr ist natrlich die entsprechende Konfiguration der internen
Reprsentation, aber dazu spter mehr.

Zur Realisierung einer integrierten externen Benutzeroberflche ist es erforderlich, die Reprsentation
in eine Objektbibliothek zu integrieren. Diese Objektbibliothek ist im Installationspaket in der Tabelle
MsiEmbeddedUI abzulegen, in der auch spezifisch Konfigurationen vorgenommen werden. Beim
Starten der Installation prft der Windows Installer die Existenz einer solchen Datei. Falls sie
vorhanden ist, wird sie extrahiert und im temporren Datenspeicher abgelegt. Danach wird sie in den
Speicherbereich des aufrufenden Prozesses geladen und es werden die erforderlichen Funktionen
aufgerufen. An dieser Stelle kommt es zu Abweichungen gegenber den externen Oberflchen
klassischer Art. Bei denen konnten Funktionsnamen und Signaturen individuell bestimmt werden. Bei
der integrierten Verwendung ist das nicht mehr der Fall, denn diese Objektbibliotheken fest
vorgegebene Funktionen exportieren. Werden nicht alle Funktionen exportiert, werden nur die
tatschlich Exportierten aufgerufen.
Die Erluterung der Funktionalitten und Vorgehensweise werde ich unter Verwendung der
Deployment Tools Foundation durchfhren. Hiermit wird eine sehr elegante Mglichkeit zur
Verfgung gestellt, eine integrierbare externe Benutzeroberflche in einer .NET Sprache zu erzeugen.
Die Vorgehensweise dazu ist recht einfach. Starten Sie Visual Studio und erzeugen Sie ein neues
Projekt. In dem erscheinenden Dialog whlen Sie das Custom Action Projekt Ihrer bevorzugten .NET
Sprache aus, wie dieses auch in Abbildung 9.84 zu sehen ist.
396
Kapitel 9
Abbildung 9.84: Erstellen eines Projektes fr eine integrierte externe Benutzeroberflche
Visual Studio erstellt nun ein neues Projekt aus dem die automatisch erzeugte Datei customaction.cs
entfernt werden kann. Fgen Sie stattdessen eine neue Klasse hinzu und benennen Sie diese
beispielsweise als eeui.cs. ffnen Sie anschlieend diese Klasse und implementieren Sie das Interface
Microsoft.Deployment.WindowsInstaller.IEmbeddedUI. Fgen Sie dem Projekt weiterhin einen
Verweis auf die Bibliothek System.Windows.Forms.dll hinzu. Danach sollte die Klasse EEUI, das in
Listing 9.84 darstellte Erscheinungsbild aufweisen.
namespace
{
using
using
using
MsiUI
System;
System.Windows.Forms;
Microsoft.Deployment.WindowsInstaller;
public class EEUI : IEmbeddedUI

{
public bool Initialize(Session session, string resourcePath, ref InstallUIOptions internalUILevel)
{
throw new NotImplementedException();
}
public MessageResult ProcessMessage(InstallMessage messageType, Record messageRecord,
{
}
public void Shutdown()
397
Kapitel 9
{
}
}
}
Listing 9.84: Rudimentre Implementierung zur Verwendung einer integrierten externen Oberflche
In dem Listing sind die drei Funktionen zu erkennen, die es nun zu erlutern gilt. Auch ohne weitere
Modifikationen lsst sich das Projekt bereits kompilieren. Das dargestellte Projekt trgt die
Bezeichnung MsiUI wodurch die Dateien msiui.dll und msiui.ca.dll erzeugt werden. An dieser Stelle
kommt eine Besonderheit zum Tragen. Der Windows Installer kann keine .NET Assemblies
verwenden, wodurch von der Deployment Tools Foundation eine spezielle Implementierung verwendet
wird. Bei der erzeugten Datei msiui.ca.dll handelt es sich um eine native Windows-Bibliothek, die als
Proxy fungiert. Das bedeutet, dass die Aufrufe des Windows Installers zu diesem gelangen und von
hieraus zum .NET-Assembly weitergeleitet werden. Das .NET-Assembly und weitere Referenzen, wie
die Microsoft.Deployment.WindowsInstaller.dll befinden sich als Ressource in der nativen Bibliothek
und werden automatisch extrahiert und im aktuellen Verzeichnis gespeichert.
Aus den Erluterungen lsst sich ableiten, dass die Datei msiui.ca.dll der Spalte Data der Tabelle
MsiEmbeddedUI hinzugefgt werden muss. Alle weiteren Aktionen werden automatisch vom
Windows Installer und von der spezifischen Implementierung dieser Bibliothek veranlasst. Eine
potentielle Fehlerquelle ergibt sich bei der Verwendung unglcklich gewhlter Dateinamen. Es ist zu
beachten, dass diese native Bibliothek noch andere Dateien beinhaltet, die extrahiert und unter Ihrem
regulren Namen gespeichert werden. Wird in der Tabelle MsiEmbeddedUI im Feld FileName nun
einer dieser Dateinamen angegeben, fhrt das unweigerlich zum Fehler, da die erforderliche Datei
nicht erzeugt werden kann. In einem solchen Fall hilft allerdings das Installationsprotokoll weiter,
denn diesem werden hilfreiche Informationen angefgt.
SFXCA: Extracting embedded UI to temporary directory: C:\Users\AK\AppData\Local\Temp\MSI3022
SFXCA: Failed to extract to temporary directory. Cabinet error code 11.
SFXCA: Ensure that no MsiEmbeddedUI.FileName values are the same as any file contained
in the embedded UI package.
Die entsprechenden Eintrge sind durch den Prfix SFXCA gekennzeichnet, da diese Probleme in
der Bibliothek auftreten, die fr das Extrahieren der Dateien verantwortlich. Diese Datei trgt die
Bezeichnung sfxca.dll.
Initialisieren der Benutzeroberflche

Nun aber zurck zu der regulren Implementierung des Installers. Nachdem der Windows Installer die
Bibliothek in den Speicher geladen hat, wird geprft, ob die Funktion zum Initialisieren der
Benutzeroberflche exportiert wurde. Diese Funktion trgt die Bezeichnung InitializeEmbeddedUI()
und wird bei der Verwendung der Deployment Tools Foundation durch die Funktion Initialize() des
Interfaces IEmbeddedUI bereitgestellt. Die Funktion hat den folgenden Aufbau:
public bool Initialize(
Session session,
string resourcePath,
ref InstallUIOptions internalUILevel)
398
Kapitel 9
Zeitlich betrachtet wird diese Funktion vom Windows Installer aufgerufen, bevor eine Nachricht
gesendet wird und somit auch bevor die Benutzeroberflche angezeigt wird. Dieses ist notwendig, da
die Darstellung der internen Benutzeroberflche hierdurch modifiziert werden kann. Die Analogie zur
klassischen externen Oberflche wird deutlich. Dabei wurde eine Funktion aufgerufen, in der die
externe Oberflche registriert und die Nachrichten abonniert wurden. Weiterhin wurde die Darstellung
der internen Benutzeroberflche angepasst. Die ersten beiden Optionen werden bei integrierter
Oberflche direkt im Installationspaket festgelegt. Das Modifizieren der internen Benutzeroberflche
erfolgt hingegen in dieser Funktion, wie die folgenden Parameter auch zeigen.
Session: Hierbei handelt es sich um eine Referenz auf die aktuelle Windows Installer-Session, die
durch das Objekt Microsoft.Deployment.WindowsInstaller.Session bereitgestellt wird. Hiermit ist
es mglich auf bestimmte Eigenschaften der Installation zuzugreifen, diese abzurufen und auch zu
verndern. Das Session-Objekt wird aus dem Handle des Installationsmoduls erzeugt, dass den
Installationsprozess ausfhrt. Wird eine Installation unter Verwendung der vollstndigen oder
reduzierten Benutzeroberflche durchgefhrt, geschieht dieses durch den Client-Prozess. Wird
hingegen die Basisdarstellung der Benutzeroberflche gewhlt, erfolgt dieses durch den ServerProzess. Hierbei ist nicht entscheidend, welche Darstellungsoptionen tatschlich zur Verfgung
stehen, sondern die Option, die beispielsweise ber die Befehlszeile festgelegt wurde. Wichtig ist
an dieser Stelle noch, dass das Handle und somit auch das Session-Objekt nur innerhalb dieser
Funktion zur Verfgung steht. Nachdem diese Funktion beendet wurde und die Befehlsausfhrung
zum Windows Installer zurckgekehrt wird, wird das Handle geschlossen. Es ist somit auch nicht
mglich, das Handle oder das Session-Objekt zwischen zu speichern und spter zu verwenden. Es
besteht nur die Mglichkeit, innerhalb dieser Funktion die erforderlichen Werte abzugreifen und
diese statisch abzulegen, damit sie zu einem spteren Zeitpunkt verwendet werden knnen. Es ist
ebenfalls nicht mglich und auch nicht erforderlich das Session-Objekt oder das Handle innerhalb
dieser Funktion zu schlieen. Eine solche Implementierung fhrt zu einem Fehler.
resourcePath: Diesem Argument wird vom Windows Installer der vollstndige Pfad zu dem
Ordner bergeben, in den die Bibliothek und alle weiteren Ressourcen extrahiert wurden. Beim
Speichern der Dateien wird der Dateiname verwendet, der im Feld FileName der Tabelle
MsiEmbeddedUI definiert wurde. Durch diesen Mechanismus wird es mglich, separate Dateien
wie Lizenzbestimmungen oder Bilder dynamisch in die Benutzeroberflche zu laden.
internalUILevel: Hiermit kann der interne Darstellungsmodus geprft und festgelegt werden.
Diesem Argument wird vom Windows Installer der aktuell ausgewhlte Hauptdarstellungsmodus,
also InstallUIOptions.Full, InstallUIOptions.Reduced oder InstallUIOptions.Basic bergeben.
Darber hinaus enthlt dieser Parameter auch zustzliche Darstellungsoptionen wie
InstallUIOptions.EndDialog, InstallUIOptions.ProgressOnly, InstallUIOptions.HideCancel oder
InstallUIOptions.SourceResolutionOnly, sofern vorhanden. Durch diese Implementierung wird es
fr die Darstellungslogik mglich, sehr flexibel auf unterschiedliche Modi zu reagieren und
unterschiedliche Dialogsequenzen bereitzustellen. Wird eine Installation allerdings im
unbeaufsichtigten Modus (InstallUIOptions.Silent) durchgefhrt, wird die integrierte
Benutzeroberflche niemals verwendet.
Da dieser Parameter auch fr die Ausgabe benutzt werden kann, besteht die Mglichkeit die interne
Reprsentation zu verndern. Wie bereits bei der Erluterung zur Funktion SetInternalUI() und
SetExternalUI() angesprochen, sollte die interne Benutzeroberflche im klassischen
Installationsprozess in den unbeaufsichtigten Modus versetzt werden. Hierbei ist natrlich zu
bercksichtigen, dass die Verwaltung der Installationsquellen durch die interne Oberflche
ermglicht wird. Die hiermit festzulegenden Darstellungsoptionen sind in Tabelle 9.83 aufgefhrt.
399
Kapitel 9
Es ist jedoch nicht mglich eine Erhhung der Darstellungsform zu veranlassen. Das bedeutet
beispielsweise dass bei Anforderung der Basisoberflche hier keine Zuweisung fr die vollstndige
Oberflche vorgenommen werden kann. In einem solchen Fall, wird der Ausgabeparameter
zurckgesetzt, so dass die ursprngliche Oberflchenform verwendet wird. Zu beachten ist
weiterhin, dass bei Zuweisung eines ungltigen Wertes automatisch InstallUIOptions.None
verwendet wird.
Die Funktion Initialize() erwartet einen booleschen Rckgabewert, wobei True die erfolgreiche
Initialisierung der Oberflche bedeutet. Wird hingegen False zurckgeliefert wird die Installation ohne
Verwendung der integrierten Oberflche weiter gefhrt.
Wert
Beschreibung
InstallUIOptions.Full
Die integrierte Benutzeroberflche behandelt einige Nachrichten und

leitet diese dann an die interne Benutzeroberflche weiter, die in
vollstndiger Darstellung angezeigt wird.
InstallUIOptions.Reduced
Die integrierte Benutzeroberflche behandelt einige Nachrichten und

leitet diese dann an die interne Benutzeroberflche weiter, die in
reduzierter Darstellung angezeigt wird.
InstallUIOptions.Basic
Die Dialoge der internen Basisoberflche werden gemeinsam mit den

Dialogen der integrierten Reprsentation angezeigt. Hierdurch wird
gleichzeitig die Schaltflche Abbrechen deaktiviert, so dass diese in
der internen Darstellung nicht mehr verwendet werden kann.
InstallUIOptions.None
Alle Nachrichten werden durch die integrierte Benutzeroberflche

behandelt.
InstallUIOptions.SourceResolutionOnly
Alle Nachrichten werden durch die integrierte Benutzeroberflche

behandelt. Wird diese Eigenschaft in Kombination mit
INSTALLUILEVEL_NONE verwendet, wird die interne Oberflche
lediglich zur Auswahl von Installationsquellen verwendet. Andere
Dialoge werden nicht dargestellt.
Tabelle 9.83: Optionen zur Darstellungsnderung der internen Oberflche
Die Implementierung dieser Funktion ist natrlich stark von den Anforderungen und Konfigurationen
abhngig. Sollen beispielsweise die Basis- und die reduzierte Darstellung ebenfalls durch eine externe
Oberflche realisiert werden, sind natrlich unterschiedliche Dialogsequenzen zu implementieren. Das
nachfolgende Listing 9.85 erzeugt eine externe Oberflche hingegen nur bei vollstndiger Darstellung;
alle anderen Szenarien werden durch die interne Reprsentation abgebildet. Zur Deinstallation des
Produktes wird hierbei ebenfalls die interne Oberflche verwendet.
public bool Initialize(Session session, string resourcePath, ref InstallUIOptions internalUILevel)
{
if (session != null)
{
// Eine integrierte Oberflche kann durchaus eine Implementierung fr die Basis- und
// die reduzierte Darstellung besitzen. Hierbei ist das nicht der Fall, so dass
// diese Darstellungsformen durch die interne Reprsentation dargestellt werden.
if ((internalUILevel & InstallUIOptions.Full ) != InstallUIOptions.Full )
return false;
// Die Deinstallation wird ebenfalls ber die interne Reprsentation dargestellt
400
Kapitel 9
if (String.Equals(session["REMOVE"], "All", StringComparison.OrdinalIgnoreCase))

return false;
// Eigenschaften abrufen
string productName = session["ProductName"];
string messageText = string.Format("Mchten Sie '{0}' installieren?", productName);
// Nachfragen ob Produkt installiert werden soll
if (MessageBox.Show(messageText, productName, MessageBoxButtons.YesNo,
MessageBoxIcon.Question) == DialogResult.Yes)
{
// Dialog anzeigen
this.setupWizard = new SetupWizard(productName, resourcePath);
this.setupWizard.Show();
// Die interne Reprsentation wird in den unbeaufsichtigten Modus versetzt, sie wird
// jedoch im Rahmen der Festlegung von Installationsquellen verwendet.
internalUILevel = InstallUIOptions.None | InstallUIOptions.SourceResolutionOnly;
return (true);
}
else
{
// Installation abbrechen
throw new InstallCanceledException();
}
}
// Installation mit interner Oberflche durchfhren
return false;
}
Listing 9.85: Initialisierung einer integrierten externen Benutzeroberflche
In dem vorstehenden Listing wird deutlich, dem Darstellungsdialog der Pfad zu den Ressourcen
bergeben wird, so dass diese dynamisch verwendet werden knnen. Nach Anzeige des externen
Dialoges wird die interne Reprsentation modifiziert. So wird diese in den unbeaufsichtigten Modus
versetzt, allerdings wird sie zur Auswahl von Installationsquellen weiterhin verwendet.
Terminieren der Oberflche

Analog zu der Initialisierung, wird vom Windows Installer auch eine Funktion zum Terminieren der
Oberflche aufgerufen. Diese Funktion trgt die Bezeichnung ShutdownEmbeddedUI() und wird durch
die Funktion Shutdown() des Interfaces IEmbeddedUI bereitgestellt. Die Funktion hat den folgenden
Aufbau:
Die Funktion wird am Ende des Installationsprozesses aufgerufen. Nach diesem Aufruf werden keine
weiteren Nachrichten an den externen Handler gesendet. Die Objektbibliothek wird anschlieend
entladen. Die programmtechnische Umsetzung ist natrlich wieder von den tatschlichen
Anforderungen abhngig. Die Fortfhrung des Beispiels wird in Listing 9.86 dargestellt.
401
Kapitel 9
{
// Externe Oberflche wird geschlossen
if (this.setupWizard != null)
this.setupWizard.Close();
}
Listing 9.86: Terminierung der integrierten externen Oberflche
Die Methode des Beispiels ist sehr einfach, da keine weiteren Terminierungen durchgefhrt werden
mssen. Somit ist es ausreichend den Installations-Dialog zu schlieen.
Aktualisierung der Oberflche

Wie bereits bei der klassischen Implementierung einer externen Benutzeroberflche erlutert, ist auch
bei dieser Verwendungsart ein Nachrichten-Handler erforderlich, der die Bearbeitung der eingehenden
Nachrichten bernimmt. Der Nachrichten-Handler wird durch die Funktion ProcessMessage() des
Interfaces IEmbeddedUI bereitgestellt und verfgt ber die folgende Signatur:
public MessageResult ProcessMessage(
InstallMessage messageType,
Record messageRecord,
MessageBoxButtons buttons,
MessageBoxIcon icon,
MessageBoxDefaultButton defaultButton)
Es wird deutlich, dass die Signatur identisch mit der datensatzbasierten Rckruffunktion ist, die beim
Aufruf von Microsoft.Deployment.WindowsInstaller.Installer.SetExternalUI() zugewiesen wird. Somit
sind auch die Argumente identisch, die folgende Informationen enthalten.
messageType: Hierbei handelt es sich um den Typ der Nachricht. Die mglichen Nachrichtenarten
sind in Tabelle 9.82 zusammengefasst. Der fr diese Funktion relevante Wert wird in der Spalte
InstallMessage aufgefhrt.
messageRecord: Enthlt ein Objekt vom Typ Microsoft.Deployment.WindowsInstaller.Record, das
wiederum Informationen enthlt, die von der Art der Nachricht anhngig sind. Der Aufbau und der
Inhalt dieses Objektes wurde bereits im Abschnitt Darstellung der Informationen erlutert.
buttons: Enthlt einen Wert, der die Darstellung der Schaltflchen eines Dialogfeldes definiert.
icon: Enthlt einen Wert, der das Symbol festlegt, dass im Dialogfeld verwendet wird.
defaultButton: Legt die Standardschaltflche fr das Dialogfeld fest.
Die Weiterfhrung des Installationsprozesses kann natrlich durch die geeignete Wahl des
Rckgabewertes beeinflusst werden. Die mglichen Rckgabewerte und die Auswirkung auf den
Installationsprozess wurden bereits im Abschnitt Beeinflussung des Installationsprozesses erlutert.
Die programmtechnische Umsetzung dieser Funktion ist die wahrscheinlich komplexeste
installationsspezifische Implementierung bei der Verwendung einer externen Oberflche. Das
nachfolgende Beispiel behandelt die relevanten Nachrichten zur Darstellung des
Installationsfortschritts. Dieses Beispiel baut auf den Ausfhrungen des Listing 9.85 auf und
verwendet die darin geffnete Benutzeroberflche zur Darstellung der Informationen.
public MessageResult ProcessMessage(InstallMessage messageType, Record messageRecord,
{
// Fortschrittsanzeige aktualisieren
402
Kapitel 9
this.setupWizard.ProcessMessage(messageType, messageRecord);
{
case InstallMessage.FatalExit:
case InstallMessage.Error:
case InstallMessage.Warning:
case InstallMessage.User:
case InstallMessage.OutOfDiskSpace:
// Ein Problem ist aufgetreten. Die Darstellungsoptionen fr das Hinweisfeld werden bernommen
return (MessageResult)MessageBox.Show(messageRecord.ToString(), this.productTitle,
case InstallMessage.CommonData:
// Daten ermitteln
this.ProcessCommonDataMessage(messageRecord);
break;
case InstallMessage.ActionStart:
// Aktuelle Aktion darstellen
string actionText = messageRecord.GetString(2);
if (!string.IsNullOrEmpty(actionText))
this.setupWizard.ActionText = actionText;
break;
default:
// Keine Behandlung der Nachricht. Diese soll durch den Windows Installer behandelt werden
}
// Installation abbrechen
if (this.setupWizard.Cancel)
return MessageResult.Abort ;
return MessageResult.OK ;
}
Listing 9.87: Aktualisierung der integrierten externen Benutzeroberflche
Zu Beginn dieser Methode wird die Funktion ProcessMessage() des Installationsdialoges aufgerufen.
Hierbei handelt es sich um die bereits bekannte Implementierung zur Auswertung der Nachricht vom
Typ InstallMessage.Progress (INSTALLMESSAGE_PROGRESS), sowie die Aktualisierung der
Fortschrittsanzeige. Im Folgenden werden die einzelnen Nachrichtenarten ausgewertet und davon
abhngige Aktivitten veranlasst und Informationen dargestellt. Alle Nachrichten, die in dieser
Funktion nicht behandelt werden, werden an die interne Reprsentation weiter geleitet. Der
Installationsdialog enthlt eine Schaltflche zum Abbrechen der Installation. Der Status der
Schaltflche wird innerhalb dieser Funktion geprft und falls erforderlich wird die Installation
abgebrochen.
Debuggen
Mitunter kann es erforderlich werden die Objektbibliothek zur Darstellung der Benutzeroberflche zu
debuggen. Die Vorgehensweise hierbei ist identisch mit dem Debuggen von benutzerdefinierten
403
Kapitel 9
Aktionen vom Typ Objektbibliothek. Der Windows Installer verwendet die Umgebungsvariable
MsiBreak, um festzustellen, ob eine solche benutzerdefinierte Aktion im Debugger ausgefhrt werden
soll. Hierbei ist zu beachten, dass der Windows Installer die Existenz dieser Umgebungsvariablen nur
prft, wenn die Installation durch einen Systemadministrator durchgefhrt wird. Zum Debuggen einer
Objektbibliothek weisen Sie zunchst der Umgebungsvariablen MsiBreak den Namen der jeweiligen
benutzerdefinierten Aktion zu und starten Sie dann den Installationsprozess. Beim Aufruf der
benutzerdefinierten Aktion durch den Windows Installer erscheint eine Dialogbox in der die ID des
entsprechenden Prozesses angegeben ist. Verbinden Sie den Debugger mit diesem Prozess, ffnen Sie
die jeweiligen Programmquellen, setzen Sie die Haltepunkte und prfen Sie, ob die Symboldateien der
benutzerdefinierten Aktion geladen sind. Nach dem Schlieen der Dialogbox wird die Ausfhrung der
benutzerdefinierten Aktion am ersten Haltepunkt unterbrochen. Nun knnen Sie schrittweise durch den
Programmcode navigieren und die Problemquellen analysieren.
Wie bereits angedeutet, verhlt es sich mit dem Debuggen der integrierten Oberflche hnlich. Hierzu
ist der Umgebungsvariablen MsiBreak die Zeichenfolge MsiEmbeddedUI zuzuweisen, wobei die
Gro- und Kleinschreibung zu beachten ist.
32-Bit und 64-Bit

Um die erzeugte Objektbibliothek letztlich verwenden zu knnen, muss diese in den Prozessraum der
jeweiligen Anwendung geladen werden. Aus Sicherheits- und Stabilittsgrnden ldt der Windows
Installer diese jedoch nicht in den eigenen Prozessraum, sondern er erzeugt speziell fr diese Zwecke
konzipierte Host-Prozesse. Bei dem Host-Prozess handelt es sich um eine Form der bereits bekannten
Custom Action-Server, die in unterschiedlichen Ausprgungen vorkommen knnen. Diese
Ausprgungen sind von der Art des aufrufenden Prozesses und der Verwendung der Privilegien
abhngig. So existieren Client- und Server-seitige Custom Action-Server, die mit den Privilegien des
Benutzers ausgefhrt werden. Auf Serverseite existiert ein zustzlicher Custom Action-Server der ber
Systemprivilegien verfgt. Im Rahmen der integrierten Benutzeroberflche sind nur die Prozesse
relevant, die im Kontext des Benutzers ausgefhrt werden. Somit ist ebenfalls deutlich, dass alle
Aktivitten, die durch die Oberflche gesteuert werden, ebenfalls ber diese Privilegien verfgen.
Auf einer 64-Bit-Plattform sind die skizzierten Custom Action-Server in doppelter Anzahl vorhanden,
da sie sowohl in einer 32-Bit, als auch in einer 64-Bit-Ausprgung vorliegen. Hierdurch wird es
mglich 32-Bit und 64-Bit-Code innerhalb von benutzerdefinierten Aktionen zu verwenden. Windows
Installer ermittelt automatisch die Architektur der benutzerdefinierten Aktion und fhrt sie in dem
jeweiligen Custom Action-Server aus. Dieses gilt allerdings nur fr Dateien mit PE-Header; bei
Skriptdateien muss die Architektur ber Attribute bestimmt werden. Nun aber zurck zur integrierten
Benutzeroberflche. Hierbei verhlt es sich identisch; liegt die entsprechende Objektbibliothek in 32Bit Ausprgung vor wird sie im 32-Bit Host ausgefhrt. Handelt es sich hingegen um eine 64-Bit
Objektbibliothek kommt natrlich der 64-Bit Host zum Einsatz. Diese gesamte Umsetzung ist
allerdings nur mglich wenn das Installationspaket im Summary Information Stream als 64-Bit-Paket
gekennzeichnet wurde. Die Verwendung von 64-Bit Code in einem 32-Bit Installationspaket ist
natrlich nicht mglich, auch wenn die Installation auf einem 64-Bit Betriebssystem erfolgt.
Hinweis Beginn
Die Verwendung eines integrierten Chainers erfolgt nach dem gleichen Muster. Auch hierbei ist es
mglich 32-Bit oder 64-Bit Code zu verwenden.
Hinweis Ende
404
Kapitel 9
Deaktivieren der integrierten Benutzeroberflche

Bei der Entwicklung einer integrierten externen Oberflche, sollte sich natrlich in jedem Fall an die
Vorgaben und Richtlinien des Windows Installers gehalten werden. Dennoch kann natrlich keine
Garantie dafr gegeben werden, dass dieses tatschlich geschehen wird. Wird die Installation unter
Verwendung der Basis-Oberflche initiiert, sollte natrlich auch bei individueller Umsetzung, eine
hnliche Darstellung verwendet werden. Allerdings erlaubt die programmtechnische Umsetzung
natrlich alle Freiheiten, so dass auch bei Anforderung einer Basis-Oberflche die vollstndige
Reprsentation dargestellt werden knnte. Problematisch sind solche Umsetzungen natrlich
vornehmlich bei einer Softwareverteilung, die ohne Benutzereingriff aber mit Darstellung einer
Fortschrittsanzeige durchgefhrt wird. In solchen Szenarien kann es aus nachvollziehbaren Grnden
erforderlich werden, die Verwendung der integrierten externen Benutzeroberflche zu deaktivieren.
Hierzu stehen die folgenden Mechanismen zur Verfgung:
Systemrichtlinie MsiDisableEmbeddedUI: Wird diese Richtlinie nicht oder auf den Wert 0
gesetzt, wird die integrierte externe Oberflche verwendet. Wird die Richtlinie auf 1 gesetzt, wird
der Inhalt der Tabelle MsiEmbeddedUI bei allen Installation ignoriert.
Eigenschaft MSIDISABLEEEUI: Hierbei handelt es sich natrlich um eine ffentliche
Eigenschaft, die demzufolge auch ber die Befehlszeile gesetzt werden kann. Die Vorgehensweise ist
identisch wie bei der Richtlinie. Wird diese Eigenschaft auf 1 gesetzt, wird der Inhalt der Tabelle
MsiEmbeddedUI ignoriert. Allerdings wirkt sich dieses nur auf das aktuelle Installationspaket aus. Zu
beachten ist auch, dass diese Eigenschaft vor der Initialisierung der integrierten Oberflche geprft
wird. Etwas komplizierter wird es in einer paketbergreifenden Transaktion. Das Installationspaket
b.msi enthlt keine eigene EEUI und verwendet daher, die integrierte Oberflche von a.msi. Wird
durch a.msi die Eigenschaft MSIDISABLEEEUI nicht auf 1 gesetzt, verwendet auch b.msi die
Oberflche von a.msi, wobei es nun unerheblich ist, ob die Eigenschaft MSIDISABLEEEUI in b.msi
gesetzt wurde.
Interne Ablufe
Im bisherigen Verlauf der Erluterungen zur integrierten externen Benutzeroberflche wurden die
hierfr erforderlichen internen Ablufe des Windows Installers nur oberflchig betrachtet. An dieser
Stelle soll nun eine detailliertere Betrachtung folgen, bei der auch relevante Eintragungen im
Installationsprotokoll aufgefhrt werden. Alle Eintragungen des Installationsprotokolls die auf die
integrierte Benutzeroberflche abzielen, sind durch den Prfix EEUI gekennzeichnet.
Initialsierung des Installationsmoduls

Die Existenz und die Verwendung einer integrierten externen Benutzeroberflche werden whrend der
Initialisierungsphase des Installationsmoduls geprft. Die hierzu erforderlichen Aktionen werden
clientseitig ausgefhrt, wenn die Installation in vollstndiger oder reduzierter Darstellung erfolgen soll.
Dem entgegenzusetzen ist die Installation in Basisdarstellung, da hierbei die erforderlichen Aktionen
serverseitig ausgefhrt werden. Das bedeutet natrlich auch, dass bei vollstndiger und reduzierter
Darstellung keine Verarbeitung durch den Server-Prozess erfolgen kann, so dass eine integrierte
Oberflche fr diesen Prozess deaktiviert wird.
MSI (s) (6C:A0) [17:07:56:338]: EEUI - Disabling MsiEmbeddedUI for service because it's
not a quiet/basic install
405
Kapitel 9
Im ersten Schritt wird geprft, ob eine eventuell vorhandene integrierte externe Oberflche verwendet
werden kann und darf. Es wird zunchst geprft, ob die Verwendung durch die Systemrichtlinie
MsiDisableEmbeddedUI oder die Eigenschaft MSIDISABLEEEUI deaktiviert wurde. Falls das der Fall
ist, wird eine solche auch nicht verwendet. Dem Installationsprotokoll wird der nachfolgende Eintrag
angefgt:
MSI (c) (2C:18) [13:34:43:015]: EEUI - Disabling MsiEmbeddedUI due to property or policy
Falls das jedoch nicht der Fall ist, wird geprft, ob bereits eine externe Oberflche aktiv ist. Hierbei ist
es unerheblich ob diese externe Oberflche ber den klassischen Mechanismus oder die
Integrationsmglichkeit verwendet wird. Auch in einem solchen Fall wird eine Nachricht dem
MSI (c) (38:10) [13:41:34:429]: EEUI - Disabling MsiEmbeddedUI due to existing external or embedded UI
In dem Fall dass keine externe Oberflche aktiv ist, wird geprft, ob die Tabelle MsiEmbeddedUI
einen Datensatz enthlt, bei dem das Attribut msidbEmbeddedUI gesetzt wurde und ein entsprechender
Nachrichtenfilter definiert ist. Wird die Installation unter Verwendung der Basisoberflche ausgefhrt,
wie dass beispielsweise durch den nachfolgenden Aufruf ermglicht wird, muss der Datensatz
ebenfalls durch das Attribut msidbEmbeddedHandlesBasic gekennzeichnet sein.
msiexec.exe /i <Installationspaket> /qb
Das Installationsprotokoll stellt dieses ebenfalls dar und weist darauf hin, dass Programmcode nun
ausgefhrt wird.
MSI (c) (30:64) [12:59:52:377]: Machine policy value 'MsiDisableEmbeddedUI' is 0
MSI (c) (30:64) [12:59:52:377]: EEUI - Running MsiEmbeddedUI code
Es folgt die Erstellung eines Verzeichnisses im Ordner %temp% des Benutzers. Das Verzeichnis wird
ausschlielich fr diese Installationssitzung verwendet, so dass keine Dateien durch eine andere
Installation in diesem Verzeichnis abgelegt werden knnen. Das gilt auch fr den Fall, dass eine
Installation mehrfach aufgerufen wird. Der Zugriff auf das Verzeichnis wird ebenfalls geregelt, so dass
nur der Systemadministrator und der Benutzer der die Installation ausfhrt, darauf zugreifen drfen.
Der Pfad zu dem Verzeichnis wird der integrierten Oberflche bergeben, so dass diese darauf
zugreifen kann und falls erforderlich auch Unterverzeichnisse erzeugen und Dateien darin ablegen
kann. Die Dateien der Tabelle MsiEmbeddedUI werden nun extrahiert und in dem erzeugten
Verzeichnis gespeichert. Falls mehrere Datenstze in der Tabelle vorhanden sind, die identische
Dateinamen aufweisen, ist das Endergebnis nicht vorhersehbar. Eine Datei wird hierbei gewinnen, aber
es ist jedoch nicht mglich zu sagen, welche Datei gewinnen wird. Kommt es beim Ablegen der
Dateien in dem Verzeichnis zu einem Fehler, wird die Installation abgebrochen.
Nachdem die Dateien extrahiert wurden, wird die durch das Attribut msidbEmbeddedUI
gekennzeichnete Datei in einem speziellen clientseitigen Custom Action-Server geladen und die
Funktion InitializeEmbeddedUI() wird aufgerufen. Soll die Installation hingegen unter Verwendung
der Basisdarstellung ausgefhrt werden, wird die Bibliothek in den impersonierten Custom ActionServer des Server-Prozesses geladen. Kann die Bibliothek nicht geladen werden, wird dem
Installationsprotokoll eine Meldung angefgt und die Installation wird unter Verwendung der internen
Benutzeroberflche fortgesetzt.
406
Kapitel 9
MSI (c) (80:C4) [14:30:23:236]: EEUI - Unable to load embedded DLL handler
Kommt es beim Ausfhren der Funktion InitializeEmbeddedUI() zum Fehler, so dass die Funktion mit
dem Rckgabewert ERROR_INSTALL_FAILURE beendet wird, wird die Installation ebenfalls mit
diesem Fehlercode abgebrochen. Dem Installationsprotokollwerden entsprechende Hinweise angefgt.
MSI (c) (80:C4) [14:30:23:236]: EEUI - Unable to load embedded DLL handler
Wird die Funktion InitializeEmbeddedUI() nicht ausgefhrt, so wird die interne Benutzeroberflche
auf den angeforderten Darstellungsmodus gesetzt und die Bibliothek zur Darstellung der integrierten
Oberflche wird entladen. Zu diesem Verhalten gelangt man beispielsweise, wenn die Installation aus
Listing 9.85 in Basisdarstellung ausgefhrt wird. Das Installationsprotokoll weist wie folgt hierauf hin.
MSI (c) (84:E8) [16:02:36:608]: EEUI - Setting handler to be nonfunctional and changing internal UI level
Im Normalfall wird die Funktion InitializeEmbeddedUI() natrlich erfolgreich ausgefhrt, so dass

danach der Darstellungsmodus der internen Oberflche auf den im Ausgabeparameter definierten Wert
gesetzt wird. Die Objektbibliothek zur Darstellung der Oberflche bleibt fr die Dauer der Installation
geladen. Wird dem Ausgabeparameter ein fehlerhafter oder nicht umsetzbarer Darstellungswert
zugeordnet, wird dieser Wert vom Windows Installer korrigiert und die nachfolgende Meldung dem
Protokoll angefgt.
MSI (c) (38:68) [14:35:23:563]: EEUI - InitializeEmbeddedUI requested an invalid value UI Level: 0
Die Initialisierungsphase ist danach abgeschlossen und die externe Benutzeroberflche steht zur
Verfgung.
Transformationen und Patches

Die Verwendung einer integrierten Benutzeroberflche basiert im Wesentlichen auf den Informationen
der Tabelle MsiEmbeddedUI. Die Informationen werden beim Initialisieren des Installationsmoduls
abgerufen und verwendet. Bereits vor der Initialisierung werden eventuelle Windows InstallerTransformationen und Windows Installer-Patches auf das im Arbeitsspeicher befindliche
Installationspaket angewendet. Hieraus folgt, dass die Inhalte der Tabelle MsiEmbeddedUI durch diese
Mechanismen auch verndert oder ergnzt werden knnen. Somit wirken sich diese nderungen
bereits auf die Darstellung whrend der Basisinstallation aus, falls die Transformation oder der Patch
referenziert wurden. Werden allerdings durch einen Patch entsprechende Modifikationen an der
Tabelle vorgenommen, stehen diese bei der Deinstallation des Patches nicht mehr zur Verfgung.
Verarbeiten der Nachrichten

Die Darstellung und Ausprgung der Benutzeroberflche sind natrlich von vielen Faktoren abhngig.
So kann sie sehr einfach gehalten sein, aber auch durchaus komplexe Formen annehmen. Unabhngig
von der tatschlichen Funktonalitt, ist normalerweise eine Option zum Starten der Installation
vorhanden. Nachdem die Installation gestartet wurde, werden vom Windows Installer diverse
Nachrichten versandt, die letztlich zum externen Nachrichten-Handler gelangen. Hierbei ist jedoch zu
beachten, dass nur die Nachrichten empfangen werden, die auch abonniert wurden. Der externe
Nachrichten-Handler kann nun die Nachricht selbst verarbeiten oder auch an den internen Handler
weiterleiten. Diese Mglichkeit ist zunchst abhngig vom definierten Darstellungsmodus der internen
Oberflche. Letztlich wird ber den Rckgabewert des externen Nachrichten-Handlers festgelegt, was
407
Kapitel 9
mit der Nachricht geschehen soll, wie dieses auch in Abbildung 9.85 aufgezeigt wird.
Abbildung 9.85: Behandlung von Nachrichten durch den externen Nachrichten-Handler

Wichtig Beginn
Es ist unbedingt zu beachten, dass sich eine externe Benutzeroberflche und eine integrierte externe
Benutzeroberflche gegenseitig ausschlieen. Falls eine externe Oberflche aktiv ist, wird eine
eventuell vorhandene integrierte Oberflche nicht aufgerufen. Wird hingegen eine integrierte
Oberflche bereits verwendet, schlgt ein eventueller Aufruf zur Registrierung einer externen
Oberflche fehl.
Wichtig Ende
Installationsmodul herunterfahren
Nachdem die Installation abgeschlossen wurde, muss die externe Benutzeroberflche noch geschlossen
werden. Dieses geschieht whrend der Terminierung des Installationsmoduls. Zunchst wird die
Funktion ShutdownEmbeddedUI() der Bibliothek zur Darstellung der externen Oberflche aufgerufen.
Innerhalb dieser Funktion ist natrlich die Benutzeroberflche zu schlieen. Weiterhin knnen in
dieser Funktion auch weitere Aufrumarbeiten durchgefhrt werden. Nachdem die Verarbeitung zum
Windows Installer zurckgekehrt ist, wird die Objektbibliothek entladen. Die Host-Prozesse (Custom
Action-Server) in denen die Bibliothek ausgefhrt wurde, werden im Rahmen der Aufrumarbeiten des
Installationsmoduls ebenfalls beendet. Anschlieend wird das erzeugte temporre Verzeichnis
gelscht. Dieses geschieht wie gesagt, nachdem die Custom Action-Server heruntergefahren wurden.
408
Kapitel 9
Hierdurch kann sichergestellt werden, dass die Objektbibliothek keine weiteren Dateien verwendet.
Falls individuelle Unterverzeichnisse erstellt wurden, werden diese natrlich ebenfalls entfernt, wie
das Protokoll auch zeigt.
MSI (c) (84:0C) [17:07:56:541]: FDeleteFolder: Deleting file
'C:\Users\AK\AppData\Local\Temp\MSI15570\MsiUI.dll'
MSI (c) (84:0C) [17:07:56:541]: FDeleteFolder: Deleting folder
'C:\Users\AK\AppData\Local\Temp\MSI15570\EmbeddedUI'
MSI (c) (84:0C) [17:07:56:541]: FDeleteFolder: Deleting file
'C:\Users\AK\AppData\Local\Temp\MSI15570\Setup.png'
Falls das Entfernen der erzeugten Verzeichnisse hingegen nicht mglich ist, wird dieses auf einen
spteren Zeitpunkt verschoben. Das bedeutet, dass die markiert werden, so dass das Lschen nach dem
nchsten Computerneustart durchgefhrt wird.
Verhalten bei paketbergreifenden Transaktionen

Bei der Verwendung von paketbergreifenden Transaktionen zur Durchfhrung der Installation, kann
sich ein etwas abweichendes Bild ergeben. Das ist darauf zurckzufhren, dass eine integrierte
Benutzeroberflche ber Paketgrenzen hinweg verwendet werden kann. Zunchst wird auch hierbei die
Installation des ersten Paketes gestartet, wobei zunchst die Initialisierung durchgefhrt wird und
anschlieend in die Ausfhrungsphase gewechselt wird. In dieser Phase wird das System physisch
modifiziert, aber die Installation noch nicht abgeschlossen, da ja die Commit-Phase erst nach der
Installation aller Paket durchgefhrt wird. Das bedeutet, dass nun die weiteren Pakete innerhalb der
Transaktion installiert werden und die Darstellung ber die integrierte Benutzeroberflche des ersten
Paketes erfolgt. Erst nach Abschluss der Transaktion wird dann die Terminierung der
Benutzeroberflche veranlasst, wie dieses auch in Abbildung 9.86 ersichtlich wird.
409
Kapitel 9
Abbildung 9.86: Paketbergreifende Transaktion in Verbindung mit einer integrierten Benutzeroberflche
Das dargestellte Verhalten entspricht jedoch nicht der Standardeinstellung, ist aber in den meiten
Szenarien die angestrebte Reprsentation. Aus diesem Grund mssen einige Faktoren bercksichtigt
werden. Zunchst geht es um das Starten der Transaktion. Hierzu wird die Funktion
verwendet.
Diese
Funktion
verfgt
ber
den
Parameter
dwTransactionAttributes, dem die Werte 0x0 oder 0x1 zugewiesen werden knnen. Der Wert 0x1 wird
durch die Konstante MSITRANSACTION_CHAIN_EMBEDDEDUI reprsentiert. Wird diesem
Parameter der Wert 0x0 zugeordnet, wird die Benutzeroberflche einer vorherigen Installation
geschlossen. Das bedeutet, dass whrend der Terminierung des Installationsmoduls ebenfalls die
Terminierung der Benutzeroberflche erfolgt, unabhngig davon, ob mehrere Pakete innerhalb einer
Transaktion installiert werden. Anders verhlt es sich, falls der Wert 0x1 zugewiesen wird. In diesem
Fall bleibt die integrierte Benutzeroberflche bis zum Ende der Transaktion geffnet. Das bedeutet,
dass die oben geschilderte Aufrumphase erst durch die Funktion MsiEndTransaction() ausgelst wird.
Zu beachten ist jedoch, dass der Windows Installer automatisch die Transaktionen erzeugt und
beendet, falls dieses nicht explizit durch einen Chainer erfolgt. Der Windows Installer verwendet
hierbei das Attribut MSITRANSACTION_CHAIN_EMBEDDEDUI und stellt somit sicher, dass eine
integrierte Oberflche auch paketbergreifend verwendet wird.
Wichtig ist ebenfalls in diesem Zusammenhang die Funktion MsiJoinTransaction(). Hiermit wird ein
neuer Client als Eigentmer der Transaktion festgelegt. Auch diese Funktion verfgt ber den gerade
dargestellten Parameter, den auch hierbei die identischen Werte zugewiesen werden knnen, die
410
Kapitel 9
natrlich zu einem identischen Verhalten fhren. Bei dieser Funktion kann dem Parameter auch der
Wert
0x2
zugewiesen
werden,
der
durch
die
Konstante
MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI dargestellt wird. Hiermit wird der Windows
Installer angewiesen, die integrierte Benutzeroberflche der Originalinstallation zu verwenden. Verfgt
diese Installation ber keine integrierte Benutzeroberflche, wird dieses Attribut ignoriert.
Anwendungsszenarien
Aus den bisherigen Erluterungen sollte das sehr weite Anwendungsspektrum der integrierten
Benutzeroberflche deutlich geworden sein. Diese bisherigen Betrachtungen waren berwiegend
theoretischer Natur, so dass bestimmte Faktoren noch einiger zustzlicher Erklrungen bedrfen. Ich
denke, dass gerade in Verbindung mit den paketbergreifenden Transaktionen konkrete
Anwendungsszenarien das Verstndnis verbessern sollten.
Szenario 1: Installation eines einzelnen Paketes

Das nachfolgende Szenario stellt die Ablufe bei der Installation eines einzelnen Paketes dar, wobei
eine vollstndige Benutzeroberflche verwendet wird. Dieses Szenario ist bei der erstmaligen
Installation eines Produktes anzutreffen. Weiterhin kommt es zu diesem Verhalten wenn ber den
Dialog Software der Systemsteuerung der Wartungsmodus gestartet wird.
21. Die Installation von a.msi wird durch einen Doppelklick gestartet.
22. Nachdem das Installationspaket geffnet und die Patches und Transformationen angewendet
wurden, prft das clientseitige Installationsmodul, ob die Tabelle MsiEmbeddedUI ber einen
Eintrag verfgt, bei dem das Attribut msidbEmbeddedUI gesetzt und bei dem ein Nachrichtenfilter
definiert wurde. Wurde ein solcher Eintrag gefunden wir die eingebettete Objektbibliothek zur
Darstellung der Benutzeroberflche (ui.dll) extrahiert, im temporren Verzeichnis gespeichert und
anschlieend im clientseitigen Custom Action-Server fr integrierte Oberflchen geladen. Wurde
keine integrierte ui.dll gefunden, wird die Tabelle MsiEmbeddedUI ignoriert und die Installation
wird unter Verwendung der internen Oberflche ausgefhrt.
23. Die Tabelle InstallUISequence wird abgearbeitet. Allerdings werden alle Nachrichten, die dem
Nachrichtenfilter der Tabelle MsiEmbeddedUI entsprechen, an die integrierte Oberflche gesendet.
Es existieren nun zwei Mglichkeiten um die Nachrichten weiter zu verarbeiten.
Der integrierte Nachrichten-Handler behandelt diese Nachrichten und interagiert ber eigene
Dialoge mit dem Benutzer.
Es werden nicht alle Nachrichten durch den integrierten Handler behandelt, so dass diese an die
interne Oberflche weiter geleitet werden. Nachrichten, die nicht dem definierten
Nachrichtenfilter entsprechen, werden ebenfalls an die interne Oberflche weiter geleitet.
24. Nachdem die Installation abgeschlossen ist, wird der Custom Action-Server fr integrierte
Oberflchen heruntergefahren und der temporre Ordner und die Dateien werden gelscht.
Szenario 2: Installation mehrerer Pakete veranlasst durch einen Chainer

Es wird ein Chainer verwendet um die beiden Pakete a.msi und b.msi zu installieren. Hierbei soll
die integrierte Benutzeroberflche von a.msi verwendet werden, damit eine kontinuierliche,
paketbergreifende Darstellung erreicht wird. Die erforderliche ui.dll ist in der Tabelle
MsiEmbeddedUI von a.msi enthalten.
411
Kapitel 9
25. Der
Chainer
ruft
auf,
wobei
das
Attribut
MSITRANSACTION_CHAIN_EMBEDDEDUI gesetzt wird. Das Attribut ist erforderlich, um es der
integrierten Benutzeroberflche von a.msi zu ermglichen, auch die Darstellung weiterer Pakete
zu bernehmen. Durch den Aufruf der Funktion MsiBeginTransaction() wird der Chainer auch als
Eigentmer der Transaktion registriert.
26. Der Chainer ruft MsiInstallProduct() auf um a.msi zu installieren.
Nachdem das Installationspaket geffnet und die Transaktionen und Patches angewendet
wurden, wird die ui.dll aus a.msi in den clientseitigen Custom Action-Server fr integrierte
Oberflchen geladen und die Initialisierung wird vorgenommen.
Die Installation wird wie gewohnt fortgesetzt und wechselt zum Server-Prozess. Die CommitPhase wird nicht ausgefhrt, da der Eigentmer der Transaktion, also der Chainer, dieses noch
nicht explizit veranlasst hat. Die serverseitige Installation wird abgeschlossen und die Kontrolle
wird an den Client zurckgegeben.
Der clientseitige Custom Action-Server fr integrierte Benutzeroberflchen bleibt bestehen, da
das Attribut MSITRANSACTION_CHAIN_EMBEDDEDUI gesetzt wurde. Alle anderen Custom
Action-Server und der Client-Prozess werden terminiert und MsiInstallProduct() wird beendet.
27. Der Chainer ruft MsiInstallProduct() auf um b.msi zu installieren.
Der Chainer verfgt bereits ber den Nachrichten-Kontext um die integrierte
Benutzeroberflche zu verwenden. Hiermit ist gemeint, dass der Custom Action-Server fr
integrierte Oberflchen bereits existiert und der Chainer, als Eigentmer der Transaktion, diesen
auch verwenden kann. Somit wird die ui.dll von a.msi verwendet um die Nachrichten
darzustellen, die bei der Installation von b.msi empfangen werden.
28. Der Chainer ruft MsiEndTransaction() auf um bei allen Paketen die Commit-Phase einzuleiten. Da
fr die Transaktion das Attribut MSITRANSACTION_CHAIN_EMBEDDEDUI gesetzt ist, fhrt
MsiEndTransaction() auch dazu, dass der Custom Action-Server fr integrierte Oberflchen
heruntergefahren wird.
Ein klassisches Anwendungsszenario fr diesen Ablauf ist die Installation mehrerer Pakete unter
Verwendung eines Chainers, wie das beispielsweise bei der Installation des Microsoft SQL Servers
2008 der Fall ist.
Szenario 3: Installation mehrerer Pakete veranlasst durch ein einzelnes

Paket
Zur Installation einer Anwendung sind die Installationspaket a.msi, b.msi und c.msi
erforderlich. Das Paket a.msi verfgt ber eine integrierte Benutzeroberflche und einen Chainer.
Der Chainer befindet sich in der Tabelle MsiEmbeddedChainer.
29. Der Benutzer fhrt die Installation von a.msi unter Verwendung der vollstndigen
Benutzeroberflche durch.
Die in a.msi integrierte ui.dll wird in den clientseitigen Custom Action-Server fr integrierte
Benutzeroberflchen geladen, nachdem das Installationspaket geffnet und die Patches und
Transaktionen angewendet wurden.
Die Installation wechselt zum Server-Prozess und der Server startet automatisch eine
Transaktion und bernimmt die Besitzverhltnisse.
Die Tabelle InstallExecuteSequence wird mit Ausnahme der Aktion InstallFinalize wie erwartet
412
Kapitel 9
ausgefhrt. Da der Server-Prozess der Eigentmer der Transaktion ist, wird bei der Aktion
InstallFinalize nicht die Commit-Phase eingeleitet, sondern die Tabelle MsiEmbeddedChainer
auf Existenz eines geeigneten Chainers geprft. Hierzu werden die in der Tabelle definierten
Bedingungen ausgewertet. Falls ein solcher Chainer gefunden wurde, wird dieser als
benutzerdefinierte Aktion vom Typ Anwendung ausgefhrt. Der zum Starten erforderlichen
Befehlszeile wird das Handle der Transaktion angefgt. Falls weitere Eigenschaften in der
Tabelle definiert wurden, werden diese ebenfalls der Befehlszeile angefgt.
30. Der Chainer-Prozess ruft MsiJoinTransaction() auf, wobei das Handle der Transaktion verwendet
wird, dass ber die Befehlszeile bergeben wurde. Weiterhin wird das Attribut
MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI angewendet.
31. Durch
in
Verbindung
mit
dem
Attribut
MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI wird der Nachrichten-Kontext verndert,
so dass der Chainer den bereits existierenden Custom Action-Server fr integrierte Oberflchen
verwenden kann.
32. Der Chainer ruft dann MsiInstallProduct() fr b.msi und c.msi auf. Der Nachrichten-Kontext
des Chainers wurde fr die Verwendung der integrierten Benutzeroberflche bereits vorbereitet, so
dass diese Oberflche zur Behandlung der Nachrichten von b.msi und c.msi verwendet wird.
33. Der Chainer ruft MsiEndTransaction() auf und veranlasst somit den Commit fr alle Pakete. Der
Chainer wird beendet, die serverseitige Aufrumphase wird ausgefhrt und die Kontrolle wird an
den Client zurckgegeben. Der Client-Prozess und der Custom Action-Server fr integrierte
Oberflchen werden heruntergefahren.
Dieses ist ein zukunftsorientierter Ansatz zur Installation eines Produktes unter Verwendung von
Mikro-Paketen. Somit ergibt sich ein solches Anwendungsszenario natrlich bei der Installation aber
auch wenn der Wartungsmodus ber den Dialog Software der Systemsteuerung aufgerufen wird.
Szenario 4: Paketbergreifende Transaktion in Basisdarstellung

Wie in Szenario 3 sind auch hierbei die Pakete a.msi, b.msi und c.msi zur Installation einer
Anwendung erforderlich. Auch hierbei verfgt a.msi ber einen integrierten Chainer und eine
integrierte Benutzeroberflche. Die zur Darstellung erforderliche ui.dll befindet sich in der Tabelle
MsiEmbeddedUI und wurde mit dem Attribut msidbEmbeddedHandlesBasic gekennzeichnet. Die
Anwendung ist bereits installiert.
34. Der Benutzer veranlasst die Deinstallation von a.msi wobei die Basisoberflche dargestellt wird.
Bei Verwendung dieser Darstellungsart wird die Abarbeitung der Tabelle InstallUISequence durch
den Client-Prozess bersprungen und die Installation oder Deinstallation wird direkt auf ServerSeite begonnen.
Der Server-Prozess startet automatisch eine Transaktion und bernimmt den Besitz.
Nachdem das Installationspaket vom Server geffnet und alle registrierten Transformationen
und Patches angewendet wurden, wird die Existenz einer ui.dll ermittelt. Diese wird in den
serverseitigen Custom Action-Server geladen, der im Kontext des Benutzers ausgefhrt wird.
Der Server informiert die ui.dll whrend der Initialisierung, dass die Basisdarstellung zu
verwenden ist.
Whrend der Installation werden hierdurch die Nachrichten anstelle zum Client-Prozess direkt
zur ui.dll gesendet.
Die Tabelle InstallExecuteSequence wird mit Ausnahme der Aktion InstallFinalize wie erwartet
413
Kapitel 9
ausgefhrt. Beim Ausfhren dieser Aktion wird nicht in die Commit-Phase gewechselt, da der
Server der Eigentmer der Transaktion ist. Somit wird die Tabelle MsiEmbeddedChainer auf
Existenz eines geeigneten Chainers geprft, indem die definierten Bedingungen ausgewertet
werden. Falls ein solcher Chainer gefunden wurde, wird dieser als ausgefhrt. Der zum Starten
erforderlichen Befehlszeile wird das Handle der Transaktion angefgt.
35. Der Chainer ruft MsiJoinTransaction() auf, wobei das bergebende Handle der Transaktion und
das Attribut MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI verwendet werden.
36. Durch
in
Verbindung
mit
dem
Attribut
MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI wird der Nachrichten-Kontext verndert,
so dass der Chainer den bereits existierenden Custom Action-Server fr integrierte Oberflchen
verwenden kann.
37. Der Chainer ruft dann MsiInstallProduct() auf, um die Deinstallation fr b.msi und c.msi zu
veranlassen. Der Nachrichten-Kontext des Chainers wurde fr die Verwendung der integrierten
Benutzeroberflche bereits vorbereitet, so dass diese Oberflche zur Behandlung der Nachrichten
von b.msi und c.msi verwendet wird.
38. Der Chainer ruft MsiEndTransaction() auf und veranlasst somit den Commit oder den Rollback fr
alle Pakete. Der Chainer wird beendet, die serverseitige Aufrumphase wird ausgefhrt und der
Custom Action-Server fr integrierte Oberflchen wird heruntergefahren.
Die mglichen Anwendungsszenarien erstrecken sich zunchst auf die Deinstallation eines aus
mehreren Paketen bestehenden Produktes durch den Dialog Software der Systemsteuerung. Weiterhin
kommt es zu diesem Ablauf, wenn eine solche Anwendung repariert wird. Hierbei ist es unerheblich
ob dieses ber den bekannten Dialog Software erfolgt oder ob die automatische Reparatur dieses
veranlasst.
Szenario 5: Installation mehrerer Pakete veranlasst durch mehrere

Chainer
Ein Chainer mit der Bezeichnung c1.exe wird zur Installation der Anwendungen App1 und App2
bentigt. Allerdings enthlt dieser Chainer nur die Logik zur Installation von App1, die wiederum aus
a.msi und b.msi besteht. Die Anwendung App2 besteht aus x.msi und y.msi so dass der
Chainer c2.exe fr die Installation bentigt wird. Durch den Chainer c1.exe wird zunchst die
Anwendung App1 installiert und anschlieend c2.exe gestartet um App2 zu installieren. Hierbei soll
jeder Chainer eine eigene Benutzeroberflche verwenden.
39. Der von c1.exe durchgefhrte Teil der Installation ist identisch mit den Schritten 1 bis 3 des
Szenarios 2.
40. Chainer c1.exe startet den Chainer c2.exe durch Aufruf der Funktion CreateProcess().
41. Die Funktion MsiJoinTransaction() wird von c2.exe aufgerufen. Da die Oberflche von c1.exe
nicht
verwendet
werden
soll,
wird
auch
das
Attribut
MSITRANSACTION_JOIN_EXISTING_EMBEDDEDUI nicht benutzt. Da c1.exe keine weitere
Installation ausfhren muss, wird die aus a.msi extrahierte ui.dll entladen und die temporren
Daten werden gelscht.
42. Die Installation von x.msi wird von c2.exe durch den Aufruf von MsiInstallProduct()
veranlasst.
Nachdem das Installationspaket geffnet und die Transaktionen und Patches angewendet
wurden, wird die ui.dll aus x.msi in den clientseitigen Custom Action-Server fr integrierte
414
Kapitel 9
Oberflchen geladen und die Initialisierung wird vorgenommen. Anschlieend erfolgt die
Installation in bereits geschilderter Ausprgung.
Der clientseitige Custom Action-Server fr integrierte Benutzeroberflchen bleibt bestehen, da
das Attribut MSITRANSACTION_CHAIN_EMBEDDEDUI gesetzt wurde. Alle anderen Custom
Action-Server und der Client-Prozess werden terminiert und MsiInstallProduct() wird beendet.
43. Der Chainer c2.exe ruft MsiInstallProduct() auf um y.msi zu installieren.
Der Chainer verfgt bereits ber den Nachrichten-Kontext um die integrierte
Benutzeroberflche zu verwenden. Somit wird die ui.dll von x.msi verwendet um die
Nachrichten darzustellen, die bei der Installation von y.msi empfangen werden.
44. Der Chainer c2.exe ruft MsiEndTransaction() auf um die Commit-Phase fr alle Pakete
einzuleiten und die Custom Action-Server fr integrierte Oberflchen herunterzufahren.
Fr dieses Anwendungsszenario existieren derzeitig noch keine konkreten Beispiele. Allerdings sollte
sich dieses perspektivisch gesehen schnellstens ndern. Dieses wre bei Szenarien der Fall, in denen
die eigene Anwendung bestimmte Voraussetzungen installieren muss, die ebenfalls ber einen
externen Chainer bereitgestellt werden. Nahezu identisch sind die Ablufe, falls die eigene
Anwendung ber keinen externen Chainer verfgt, sondern diese mit Hilfe der Tabelle
MsiEmbeddedChainer bereitgestellt wird. Es wird deutlich, dass die Kombination der skizzierten
Szenarien ebenfalls mglich ist und zuknftig wahrscheinlich eine nicht unerhebliche Rolle im
Installationsprozess einnehmen wird.
Fazit
In vielen Bereichen nimmt die Darstellung und die Verwendung einer Benutzeroberflche eine eher
untergeordnete Rolle ein. Dieses ist gerade im Firmenumfeld zu beobachten, da hier die Installationen
automatisch und ohne Benutzereingriffe durchgefhrt werden. Allerdings kommt auch hier
Standardsoftware zum Einsatz, die natrlich auch fr andere Einsatzfelder konzipiert wurde, die
vielfach eine Benutzeroberflche zur Darstellung der Installation erfordern. Gerade bei der Aufteilung
eines Produktes in mehrere Installationspakete und die Verwendung einer paketbergreifenden
Transaktion im Installationsprozess fhrt zu einem Umdenken beim Design der Oberflche. Die hufig
verwendete integrierte Benutzeroberflche ist in solchen Szenarien nur bedingt geeignet, so dass die
Verwendung externer Benutzeroberflchen zunehmen wird. Die klassische Vorgehensweise bentigt
eine separate Anwendung zur Registrierung der Oberflche, so dass diese Vorgehensweise auch nicht
in allen Bereichen umsetzbar ist. Mit dem Windows Installer 4.5 kommt eine neue Funktionalitt zum
Einsatz, die als integrierte externe Benutzeroberflche (EEUI) bezeichnet wird. Hierdurch werden die
Vorteile einer externen Benutzeroberflche mit den Vorzgen der internen Oberflche kombiniert.
Einfache Verwendung und fast grenzenlose Funktionalitt werden wohl dazu fhren, dass
perspektivisch hufiger externe Benutzeroberflchen zum Einsatz kommen.
415
Kapitel 10
10
Optimierungen im Servicemodell
Optimierungen
Fazit
416
425
434
450
464
Das Ziel jedes Servicemodells ist die Aktualisierung der bereits installierten Ressourcen und die
dadurch realisierte berfhrung des Produktes in einen neuen Status. Ein Realisierungskonzept hierfr
verwendet vollstndige Installationspakete, die als minimale oder komplexe Aktualisierungen dieses
Ziel verwirklichen. Ein weiteres Modell sieht den Windows Installer-Patch als optimales Medium fr
solche Anwendungsszenarien vor. Mit den Windows Installer-Versionen 3.0 und 3.1wurde die
Patching-Funktionalitt wesentlich erweitert, so dass seitdem sehr komplexe Aktualisierungsszenarien
mit Hilfe von Windows Installer-Patches umgesetzt werden knnen. Dennoch waren einige Szenarien
gar nicht oder nicht optimal abgedeckt, so dass hier noch Nachbesserungen durchgefhrt werden
mussten. Gerade bei der Deinstallation von Patches, konnten einige Anforderungen nicht vollstndig
abgedeckt werden, so dass diesbezgliche Optimierungen in den Windows Installer 4.5 integriert
wurden.
Die primre Aufgabe der Installation liegt darin, Ressourcen vom Quellmedium auf den Zielcomputer
zu bertragen und hierdurch eine funktionsfhige Anwendung zu erhalten. Weitere Aktionen innerhalb
der Installation sind stark von der verwendeten Technologie abhngig. Die Aufgaben des Windows
Installers sind ja bekanntermaen nach der Erstinstallation noch nicht beendet, sondern erstecken sich
auf den gesamten Lebenszyklus der Anwendung. Zur Realisierung legt der Windows Installer
zustzliche Metainformationen ab, die somit die Grundlage fr die Verwaltung der Anwendung bilden.
So wird eine Kopie des Installationspaketes auf dem lokalen Rechner in einem speziell hierfr
vorgesehenen Verzeichnis (%windir%\Installer) abgelegt. Zur Reduzierung des Speicherbedarfs
werden eingebettete Kabinettdateien zuvor entfernt. Wird zu einem spteren Zeitpunkt die
Wartungsinstallation ausgefhrt oder stellt der Windows Installer fest, dass eine Reparatur notwendig
ist, werden die Informationen aus diesem zwischengespeicherten Paket verwendet. Zustzlich werden
in der Systemregistrierung whrend des Installationsprozesses weitere Informationen abgelegt, wie
Daten, die im Dialogfeld Software der Systemsteuerung erscheinen sollen, Daten ber die
zwischengespeicherte Datei selbst und Informationen zu den Beziehungen und die Verwendung von
Komponenten, Features und Produkten. Das bedeutet natrlich auch, dass im Rahmen einer
Softwareaktualisierung auch diese Metainformationen bercksichtigt werden mssen, wodurch sich die
416
Kapitel 10
folgenden Auswirkungen ergeben:

Aktualisierungen wirken sich auf das zwischengespeicherte Installationspaket aus.
Aktualisierungen werden natrlich auf die Anwendungsdateien angewendet. Dieses ist ja auch der
Hauptgrund fr das Update.
Aktualisierungen wirken sich auf Informationen der Systemregistrierung aus.
Der Aufbau eines Installationspaketes, das zur Softwareaktualisierung verwendet werden soll, ist
identisch mit einem Installationspaket, dass fr die Basisinstallationen bentigt wird. Ein solches
Aktualisierungspaket verfgt ber den vollstndigen Umfang der zu installierenden Ressourcen und
kann somit auch als Basisinstallationspaket verwendet werden. Das folgende Listing 10.88 zeigt ein
generisches WXS-Dokument, zum Erstellen unterschiedlicher Versionen eines Softwareproduktes.
Hierzu ist es erforderlich, entsprechende Unterverzeichnisse wie 1.0 oder 1.1 anzulegen und
diesen die jeweiligen Ressourcen hinzuzufgen. In dem Beispiel sind das die Dateien colors.exe,
infolib.dll und colors.ico. Es ist erkennbar, dass die Referenz auf die Quelldateien ber die Variable
Version definiert wurde, so dass diese beim Aufruf des Compilers, der Befehlszeile anzufgen ist.
candle.exe -dVersion=1.0 Product.wxs
light.exe Product.wixobj -fv -out 1.0\Product.msi -sval
In dem Listing 10.88 ist ebenfalls zu erkennen, dass es sich bei der Datei infolib.dll um ein .NETAssembly handelt, das im Global Assembly Cache abgelegt wird. Dieses wird deutlich, da das Attribut
AssemblyApplication nicht definiert und somit keine Dateizuordnung getroffen wurde. Die
Verwendung des Global Assembly Cache in Verbindung mit unprzise verwendeten AssemblyAttributen kann dazu fhren, dass eine Aktualisierung des Assemblies nicht ordnungsgem erfolgt.
Um diesem Problemfaktor entgegenzuwirken, wurde das Argument -fv dem Aufruf des Linkers
angefgt. Hierdurch werden zustzliche Assembly-Attribute der Tabelle MsiAssemblyName angefgt.
Eine vollstndige Erluterung dieser Gesamtproblematik ist in Anhang D zu finden.
<Product UpgradeCode="{30F18E7F-D3A8-4b41-B120-79010859477A}" Manufacturer="Microsoft Deutschland GmbH"
Language="1031" Version="1.00.0000" Name="Colors 1.0" Id="{AE581993-EA96-4632-A0F8-2D3B7DBB86E8}"
Codepage="1252">
<Package Description="Colors 1.0" Manufacturer="Andreas Kerl" InstallerVersion="200" Platform="x86"
Languages="1031" Compressed="yes" SummaryCodepage="1252" InstallPrivileges="elevated" />
<Condition Message="Das Microsoft .NET Framework ist zur Ausfhrung der Applikation unbedingt
erforderlich.">MsiNetAssemblySupport</Condition>
<Property Id="ARPPRODUCTICON" Value="I__Colors.exe"/>
<Icon Id="I__Colors.exe" SourceFile=".\$(var.Version)\Colors.ico" />
417
Kapitel 10

<Directory Id="INSTALLLOCATION" Name="Colors">

<Component Id="C__Colors.exe" Guid="{CB2AF005-1CE6-4aa8-9924-829E4722E397}" DiskId="1">
<File Id="F__Colors.exe" Source=".\$(var.Version)\" Name="Colors.exe" KeyPath="yes"
AssemblyManifest="F__Colors.exe" AssemblyApplication="F__Colors.exe" Assembly=".net"/>
<Shortcut Id="S__Colors.exe" Directory="DesktopFolder" Name="Colors 1.0" Target="Application"
Hotkey="0" Icon="I__Colors.exe" IconIndex="0" Show="normal" />
</Component>

<Component Id="C__InfoLib.dll" Guid ="{7ECF73D1-84B1-4d1b-98A6-9CF28BB12D7F}" DiskId="1">
<File Id="F__InfoLib.dll" Source=".\$(var.Version)\" Name="InfoLib.dll" KeyPath="yes"
AssemblyManifest="F__InfoLib.dll" Assembly=".net"/>
</Component>
</Directory>
</Directory>
</Directory>
<ComponentRef Id="C__Colors.exe" />
<ComponentRef Id="C__InfoLib.dll" />
</Feature>

</Product>
</Wix>
Listing 10.88: Flexible Vorlage zur Erzeugung von Installationspaketen
Anhand des Listings wird ebenfalls deutlich, dass sich die Modifikationen zwischen den erzeugten
Paketen lediglich auf die installierten Ressourcen beziehen. Die Metainformationen des Paketes wie
die Id oder die Version bleiben in diesem Beispiel unverndert. Dennoch sind diese Eigenschaften
nicht trivial, denn Windows Installer verwendet sie, um die Aktualisierungsart des Installationspaketes
festzulegen, wie dieses in Tabelle 10.84 dargestellt wird. Hier sei anzumerken, dass das Attribut Id des
Elements <Product/> eines WXS-Dokumentes der Eigenschaft ProductCode des spteren
Installationspaketes entspricht. Identisches gilt fr das Attribut Version und der Eigenschaft
ProductVersion.
Aktualisierungsart
418
ProductCode
ProductVersion
Beschreibung
Kapitel 10
Small-Update (QFE,
Hotfix, Security-Fix)
Nicht ndern
Nicht ndern
Wird fr einzelne nderungen an einem

Produkt verwendet. Small-Updates sind nicht
geplant, sondern werden ad-hoc
bereitgestellt.
Minor-Upgrade (Service
Pack)
Nicht ndern
ndern
Wird fr geplante Releases verwendet.

Enthlt alle nderungen von vorherigen
Small-Updates.
Major-Upgrade (RTM)
ndern
ndern
Stellt eine neue Version der Anwendung dar.
Tabelle 10.84: Aktualisierungsarten des Windows Installers
Durch die Informationen der Tabelle 10.84 wird deutlich, dass die Definition des AktualisierungsTyps durch die Eigenschaften ProductCode und ProductVersion erfolgt Bei dem ProductCode handelt
es sich um eine Eigenschaft, die die Softwarelsung eindeutig identifiziert und in Form einer GUID
vorliegt. Die Eigenschaft ProductVersion legt die Version des Produktes fest und wird in dem Format
Major.Minor.Build definiert. Der maximale Wert fr die Major- und fr die Minor-Version betrgt
255. Der maximale Wert fr die Build-Version betrgt 65535. Zur Definition der ProductVersion
kann auch eine Versionsangabe in dem Format xxx.xxx.xxxxx.xxxxx verwendet werden. Der
Windows Installer bercksichtigt das vierte Feld jedoch nicht. Allerdings ist eine solche Formatierung
fr ein effektives Versionsmanagement hervorragend geeignet. Wird ein Aktualisierungspaket
verwendet, bei dem lediglich das vierte Feld verndert wurde, interpretiert Windows Installer dieses
als Small-Update, da nur die ersten drei Felder der Versionsbezeichnung hierfr verwendet werden.
Zur Unterscheidung kann dieses Element jedoch herangezogen werden. Hufig stellt sich jedoch die
Frage, was unter einem Small- oder Minor-Upgrade zu verstehen ist, auch wenn Synonyme wie
Hotfix oder Service Pack aussagekrftiger sind. Zum besseren Verstndnis werden die
Unterschiede der Aktualisierungsarten anhand eines alltglichen Beispiels in Abbildung 10.87
dargestellt.
Abbildung 10.87: Abgrenzung der Aktualisierungsarten.
419
Kapitel 10
Die Festlegung der Aktualisierungsart ist in erster Linie von den Eigenschaften ProductCode und
ProductVersion abhngig. Allerdings ist dieses nur die formale Definition, denn sie ist ebenfalls vom
Umfang der durchzufhrenden Modifikationen abhngig. Die Technologie der minimalen
Aktualisierungen (Small- und Minor Upgrade) wurde in den Windows Installer integriert, um kleinere
nderungen an existierenden Produkten vorzunehmen, ohne hierfr ein neues Produkt zu erstellen. Die
minimalen Aktualisierungen verwenden den Reinstallations-Mechanismus des Windows Installers, um
die nderungen an dem System vorzunehmen. Damit dieser Mechanismus fehlerfrei und effektiv
angewendet werden kann, sind beim Design der Aktualisierungspakete bestimmte Voraussetzungen zu
erfllen, die sich auf den Unterschied zum ursprnglichen Paket beziehen.
Die Feature-Struktur darf nicht neu organisiert werden. Das bedeutet, dass der Wert der Spalte
Feature_Parent der Tabelle Features nicht verndert werden darf. Es drfen jedoch neue Features
hinzugefgt werden. Es drfen auch existierende Features entfernt werden, allerdings mssen dann
auch die untergeordneten Subfeatures ebenfalls entfernt werden.
Der Wert der Spalte ComponentId bei existierenden Windows Installer-Komponenten darf nicht
verndert werden.
Der Wert der Spalte KeyPath darf bei existierenden Windows Installer-Komponenten nicht
verndert werden. Durch eine Vernderung des KeyPath wre diese Komponente nicht mehr
abwrtskompatibel, so dass ebenfalls die ComponentId zu verndern ist.
Der Name der MSI-Datei darf nicht verndert werden.
Ganz erhebliche Auswirkungen hat die Vernderung der ComponentId, da dieses immer dazu fhrt,
dass die Eigenschaft ProductCode verndert werden muss und somit die Regeln fr minimale
Aktualisierungen durchbrochen werden. Hierbei ist besondere Vorsicht geboten, denn eine unberlegte
nderung im Aktualisierungspaket kann dazu fhren, dass das geplante Servicemodell fr die
Softwarelsung nicht mehr aufrechterhalten werden kann. Die nachfolgenden Szenarien sind daher
besonders zu beachten, denn sie stellen dar, wann die ComponentId gendert werden muss.
Die Ressourcen der Komponente des neuen Paketes sind nicht anwendungskompatibel mit den
Ressourcen der Komponente des ursprnglichen Paketes.
Die Dateinamen in der Komponente des neuen Paketes wurden gendert.
Das standardmige Zielverzeichnis der Komponente des neuen Paketes wurde verndert.
Eine Ressource wurde aus der Komponente des neuen Paketes entfernt.
der Komponente des neuen Paketes wurde eine Ressource hinzugefgt.
In vielen Fllen lsst sich ein Produkt installieren, das gegen diese Richtlinien verstt. Das aus diesen
Versten resultierende Fehlverhalten tritt vielfach erst zu einem spteren Zeitpunkt auf, so dass
entsprechende Korrekturen nur sehr schwierig durchzufhren sind. Zur Vermeidung dieser
Fehlerquellen lsst sich die Installation von Aktualisierungspaketen verhindern, die gegen folgende
Regeln verstoen:
Eine Komponente wird aus dem Installationspaket entfernt. Dieser Fall kann auch eintreten, falls
die ComponentId einer existierenden Komponente verndert wird. Hierdurch wird die bisherige
Komponente aus dem Paket entfernt und die neue Komponente dem Paket hinzugefgt.
Ein neues Feature wird erstellt und an den Beginn oder in die Mitte einer existierenden FeatureStruktur integriert, wie dieses auch in Abbildung 10.88 dargestellt wird.
420
Kapitel 10
Der Automatismus zur Verhinderung der Installation solcher Pakete kann durch die Eigenschaft
MSIENFORCEUPGRADECOMPONENTRULES
oder
durch
die
Systemrichtlinie
EnforceUpgradeComponentRules aktiviert werden.
Abbildung 10.88: Nicht kompatible Vernderung der Feature-Struktur
Vorgehensweise bei der Aktualisierung

Bei der Installation eines Produktes wird der PackageCode in den Konfigurationsdaten des Windows
Installers abgelegt. Hierbei handelt es sich um eine Eigenschaft die im Summary Information Stream
des Paketes festgelegt wird und bei jeder nderung am Paket ebenfalls zu verndern ist. Der
PackageCode ist sehr wichtig bei der Anwendung von minimalen Aktualisierungen, denn hierdurch
kann festgestellt werden, ob die Installationspakete identisch oder unterschiedlich sind. Dieses gestaltet
sich in der Form, dass beim Starten einer Installation zunchst geprft wird, ob das Produkt bereits
installiert wurde. Hierzu wird die Existenz des ProductCodes geprft. Ist dies der Fall, wird die
Eigenschaft Installed des Installationspaketes auf einen von Null abweichenden Wert gesetzt und die
Wartungsinstallation gestartet. Danach wird geprft, ob der bereits registrierte PackageCode mit dem
PackageCode des aktuellen Paketes bereinstimmt. In diesem Fall wird die Wartungsinstallation wie
erwartet fortgesetzt. Stimmen die Werte fr den PackageCode nicht berein, wird die Installation mit
dem Fehlercode 1638 abgebrochen.
Das geschilderte Verhalten des Windows Installers erscheint sehr unkomfortabel, da an dieser Stelle
eine automatische Aktualisierung des Produktes das angestrebte Ziel wre. Technisch wre so etwas
durchaus machbar, allerdings wrde sich eine andere Problemquelle daraus ergeben.
Der Windows Installer kann bei einem Vergleich zwischen dem PackageCode des registrierten
Produktes und dem aktuellen Produkt lediglich feststellen, dass eine Abweichung vorliegt. Der
Windows Installer kann jedoch nicht ermitteln welches Produkt das aktuellere ist. Wird die
Aktualisierung in dem geschilderten Szenario automatisch ausgefhrt, kann es sehr leicht passieren,
dass das aktuellere Produkt berschrieben wird. Um das zu verhindern, muss dem ReinstallationsMechanismus des Windows Installer explizit mitgeteilt werden, dass eine Aktualisierung des
Produktes erfolgen soll. Hierzu muss der Eigenschaft REINSTALLMODE das Zeichen v zugeordnet
werden. Falls dieses als Recache-Flag bezeichnete Zeichen benutzt wird, werden die folgenden
Vorgaben durchgefhrt oder bercksichtigt:
Beim Starten der Installation wird das neue Installationspaket an Stelle des zwischengespeicherten
421
Kapitel 10
Paketes verwendet.
Das alte Paket wird aus dem Ordner %windows%\installer entfernt und das neue Installationspaket
wird in diesen Ordner kopiert. Bei knftigen Installationen wird das neue Installationspaket
verwendet.
Der PackageCode des neuen Installationspaketes wird registriert und die Konfigurationsdaten des
Produktes werden entsprechend aktualisiert.
Durch die Reinstallation im Rahmen einer minimalen Aktualisierung wird sichergestellt, dass die
installierten Ressourcen aktualisiert werden. Wird die Aktualisierung lediglich mit dem Parameter
ADDLOCAL=ALL aufgerufen, werden die Ressourcen nicht aktualisiert, falls sie bereits lokal
installiert wurden. Aus diesem Grund sollte eine Aktualisierung immer durch den Parameter
REINSTALL=ALL veranlasst werden. Zur Durchfhrung der Reinstallation sind mehrere
Befehlszeilenoptionen mglich, wobei die folgenden eine vollstndige Reinstallation veranlassen:
msiexec /fvomus [Pfad zum Aktualisierungspaket]
msiexex
/i
[Pfad
zum
Aktualisierungspaket]
REINSTALLMODE=vomus
REINSTALL=ALL
Um nur definierte Teile erneut zu installieren, sind die Optionen wie folgt zu verwenden:
msiexec
/i
[Pfad
REINSTALLMODE=vomus
zum
Aktualisierungspaket]
REINSTALL=[Features]
Der Umfang der Aktualisierung wird ber die Eigenschaft REINSTALL festgelegt. Diese Eigenschaft
kann den Wert ALL oder eine durch Semikolon getrennte Liste der zu aktualisierenden Features
enthalten. Aus dieser Festlegung ergibt sich, dass eine Reinstallation im einfachsten Fall immer fr ein
komplettes Feature ausgefhrt wird, auch wenn nur eine Datei im Aktualisierungspaket verndert
wurde. Die angewendete Logik bezieht sich hierbei auf den logischen Zusammenhang zwischen
Komponenten und Features.
Ein Ziel des Windows Installers liegt darin, eine lauffhige Version der Anwendung auf dem
Zielsystem zu installieren und diesen Zustand durch geeignete Manahmen aufrecht zu erhalten. Das
Feature ist die kleinste installierbare Einheit eines Softwareproduktes aus Sicht des Endanwenders.
Somit ist ein Feature als ein in sich konsistentes Gebilde zu sehen. Beim Design des
Installationspaketes wird ein logischer oder technischer Zusammenhand zwischen den Features und
den Komponenten eines Installationspaketes hergestellt. Eine Reinstallation, die auf Ebene der
Komponenten oder auf Dateiebene erfolgen wrde, wrde zwangslufig zu einer Inkonsistenz
innerhalb des Features fhren. Das Ergebnis wre eine nicht mehr lauffhige Version der Anwendung.
Wie bereits erlutert, verfgt der Windows Installer ber keinen speziellen Updatemodus, sondern
verwendet bei minimalen Aktualisierungen den Reinstallations-Mechanismus. Hierbei gelten smtliche
Spezifikationen, die dieser Modus beinhaltet, auch wenn er in diesem Szenario ein abweichendes Ziel
verfolgt. Somit lsst sich eine Aktualisierung ebenfalls nur auf Ebene der Features ausfhren. Anders
verhlt es sich bei den Windows Installer-Patches, denn diese werden seit dem Windows Installer 3.0
in einem speziellen Update-Modus angewendet, so dass Aktualisierungen auch auf
Komponentenebene mglich sind.
422
Kapitel 10
Hinweis Beginn
Die geschilderte Funktionalitt kann natrlich auch programmtechnisch umgesetzt werden. Hierzu
stehen die Funktionen MsiReinstallProduct() und MsiReinstallFeature() der Windows InstallerProgrammierschnittstelle zur Verfgung. Bei der Verwendung der Deployment Tools Foundation sind
die Funktionen Installer.ReinstallProduct() und Installer.ReinstallFeature() des Namensraums
Microsoft.Deployment.WindowsInstaller zu verwenden.
Hinweis Ende
Selbstextrahierende Archive
Im vorherigen Abschnitt wurden die Befehlszeilenparameter aufgezeigt, die zur Durchfhrung einer
minimalen Aktualisierung zu verwenden sind. Problematisch ist hierbei, dass eine Aktualisierung nicht
durch einen Doppelklick auf die MSI-Datei ausgefhrt werden kann, da immer die Befehlszeile
bergeben werden muss. Um hier eine hheren Komfort zu bieten, knnen Aktualisierungspakete in
selbstextrahierende Archive integriert werden. Bei einem Doppelklick auf ein solches Archiv wird das
enthaltene Installationspaket extrahiert und die Installation unter Verwendung einer konstruierten
Befehlszeile gestartet. Der Komfort ist garantiert und die Fehleranflligkeit durch die Verwendung
ungltiger Befehlszeilen wird minimiert.
Das Betriebssystem stellt zur Erzeugung solcher Archive die Anwendung iexpress.exe zur Verfgung.
Nach dem Starten der Anwendung werden einige Dialoge angezeigt, in denen die Einstellungen fr das
Archiv vorgenommen werden knnen und das Archiv erzeugt werden kann. Es besteht aber auch die
Mglichkeit, die Einstellungen in einer speziellen Datei zu speichern, die als Self Extraction
Directive File bezeichnet wird. Hierdurch ist es mglich, die Einstellungen jederzeit zu korrigieren
und ein neues Archiv zu erzeugen. Es besteht sogar die Mglichkeit, dieses im unbeaufsichtigten
Modus unter Verwendung der folgenden Befehlszeile durchzufhren.
iexpress.exe /n /q setup.sed
In Listing 10.89 wird der Inhalt einer SED-Datei dargestellt, mit dem die Datei product.msi in ein
Archiv eingebettet wird und beim Extrahieren die Installation ber eine konstruierte Befehlszeile
gestartet wird.
[Version]
Class=IEXPRESS
SEDVersion=3
[Options]
PackagePurpose=InstallApp
ShowInstallProgramWindow=0
HideExtractAnimation=0
UseLongFileName=1
InsideCompressed=0
CAB_FixedSize=0
CAB_ResvCodeSigning=0
RebootMode=N
InstallPrompt=%InstallPrompt%
DisplayLicense=%DisplayLicense%
FinishMessage=%FinishMessage%
423
Kapitel 10
TargetName=%TargetName%
FriendlyName=%FriendlyName%
AppLaunched=%AppLaunched%
PostInstallCmd=%PostInstallCmd%
AdminQuietInstCmd=%AdminQuietInstCmd%
UserQuietInstCmd=%UserQuietInstCmd%
SourceFiles=SourceFiles
[Strings]
InstallPrompt=
DisplayLicense=
FinishMessage=
TargetName=Setup.exe
FriendlyName=Colors 1.0
AppLaunched=msiexec /fvomus product.msi /qb
PostInstallCmd=<None>
AdminQuietInstCmd=
UserQuietInstCmd=
FILE0="Product.msi"
[SourceFiles]
SourceFiles0=
[SourceFiles0]
%FILE0%=
Listing 10.89: Steuerdatei zur Erzeugung eines Selbstextrahierenden Archivs
Relevant ist hierbei die Befehlszeile, die durch den Schlssel AppLaunched festgelegt wurde. Es ist
erkennbar, dass der Reparaturmodus ausgefhrt und hierbei die Basisdarstellung der
Benutzeroberflche verwendet wird.
Den minimalen Aktualisierungen steht das Major-Upgrade gegenber. Bei einem Major-Upgrade
handelt es sich um die Installation eines neuen Produktes, wodurch keine zustzlichen
Befehlszeilenoptionen wie REINSTALL oder REINSTALLMODE bergeben werden mssen. Im
Rahmen dieser Installation knnen auch alte Produkte vom System entfernt werden. Durch die
Verwendung eines neuen Produktcodes sind keine Limitierungen beim Design der Komponenten- und
Feature-Struktur vorhanden, wie das bei den minimalen Aktualisierungen noch der Fall war. Minimale
Aktualisierungen waren dadurch gekennzeichnet, dass die Eigenschaft ProductCode nicht gendert
wurde. In einigen Szenarien ist es jedoch unerlsslich eine diesbezgliche nderung vorzunehmen und
somit aus Sicht des Windows Installers ein neues Produkt zu erzeugen. Die nachfolgende Liste fasst
die Szenarien zusammen in denen der Produktcode verndert werden muss:
Ein Parallelbetrieb des Originalproduktes und des aktualisierten Produktes auf demselben System
mssen mglich sein.
Der Name der MSI-Datei wurde gendert.
Die ComponentId einer existierenden Windows Installer-Komponente wurde verndert.
Eine Komponente wurde von einem existierenden Feature entfernt.
Ein existierendes Feature wurde einem neuen Feature untergeordnet. Hierbei wurde zwangslufig
424
Kapitel 10
der Inhalt der Spalte Feature_Parent verndert.

Durch die Vernderung des Produktcodes wird ein neues Produkt erzeugt, das aus Sicht des Windows
Installers, keine Zusammenhnge mit dem lteren Produkt aufweist. Das bisherige ReinstallationsModell zur Aktualisierung des Produktes kann in diesem Fall nicht mehr verwendet werden. Zur
Anwendung von komplexen Aktualisierungen ist somit ein anderes Modell erforderlich. Hierbei
werden alle Produkte, die ber unterschiedliche Produktcodes verfgen als eigenstndige Gebilde
betrachtet, die keine formalen Gemeinsamkeiten enthalten. Somit verfgt jedes Produkt ber einen
separaten Installations-, Reparatur- und Deinstallationsmechanismus. Das Modell zur Installation von
komplexen Aktualisierungen ist somit auf den drei folgenden Grundprozessen aufgebaut:
Installation des neuen Produktes
Auffinden von Produkten mit definierten Kriterien
Deinstallation der gefundenen Produkte
Die Kriterien zum Auffinden der Produkte, die deinstalliert werden sollen, sind in der Tabelle Upgrade
des Aktualisierungspaketes festgelegt. Die Standardaktion FindRelatedProducts ermittelt die Produkte,
wobei die Informationen der Tabelle Upgrade verwendet werden. Durch die Aktion
MigrateFeatureStates wird es mglich, die aktuelle Konfiguration der Features auf das neue
Installationspaket zu bertragen. Die Aktion RemoveExistingProducts ist schlielich fr das Entfernen
der lteren Produkte zustndig; sie kann zu unterschiedlichen Zeiten im Installationsprozess ausgefhrt
werden, wodurch sich verschiedene Verhaltensmuster ergeben.

Die gerade dargestellten Aktualisierungsarten verfolgten das Ziel, ein Produkt in einen neuen
Installationsstatus zu berfhren. Dieses konnte im Rahmen einer minimalen oder einer komplexen
Aktualisierung erfolgen. Die minimale Aktualisierung verendet den Reinstallations-Modus, die
komplexe Aktualisierung fhrt einfach ausgedrckt eine Deinstallation des alten Produktes und eine
Installation des neuen Produktes durch. In beiden Fllen wird jedoch ein vollstndiges
Aktualisierungspaket bentigt.
Anwenden von Patches

Beim Patching handelt es sich um eine alternative Technologie, ein Produkt in einen neuen
Installationsstatus zu berfhren. Die Produktaktualisierung erfolgt hierbei durch die Anwendung
eines Windows Installer-Patches auf ein bereits installiertes Produkt. Auch beim Patching erfolgt eine
Klassifizierung hinsichtlich eines Small-, Minor- oder Major-Upgrades. Das ist darauf begrndet, dass
zur Erstellung ein Vorher- und ein Nachher-Paket bentigt wird und sich somit die in Tabelle
10.84 durchgefhrten Abweichungen auf die Klassifizierung des Patches auswirken.
Prinzipiell knnen Patches auch als sogenannte Major-Upgrade-Patches erzeugt werden. Allerdings
wird diese Option nur aus Grnden der Kompatibilitt untersttzt, so dass die neuen Funktionalitten
im Umfeld der Patches, hiermit nicht funktionieren. Das Servicemodell der Anwendung sollte so
konzipiert werden, dass Small- und Minor-Updates in Form von Patches und ein Major-Upgrade als
vollstndiges Installationspaket verteilt und installiert werden. Somit bleiben die Patches zur
Durchfhrung der minimalen Aktualisierungen. Auch hierbei muss sich an die Richtlinien gehalten
werden, die beim Design von Installationspaketen fr minimale Aktualisierungen gelten. Dennoch
425
Kapitel 10
existieren einige Vorteile die im weiteren Verlauf dieses Kapitels dargelegt werden. Einer davon
bezieht sich auf die Befehlszeile. Zum Einspielen eines Patches sind keine speziellen
Befehlszeilenargumente erforderlich, wie es noch bei den minimalen Aktualisierungspaketen der Fall
sein musste. Aus diesem Grund ist es mglich, den Patch durch einen Doppelklick zu installieren. Falls
dennoch die Befehlszeile verwendet werden soll, stehen die folgenden Mglichkeiten zur Verfgung,
die synonym zu verwenden sind. Hierbei wird deutlich, dass nicht nur ein Patch angegeben werden
kann, sondern dass im Rahmen einer Installationstransaktion mehrere Patches eingespielt werden
knnen.
msiexec.exe /p <Patch-Datei 1>[; Patch-Datei 2]
msiexec.exe /update <Patch-Datei 1>[; Patch-Datei 2]
Ich hatte bereits erwhnt, dass Major-Upgrade-Patches nur aus Grnden der Kompatibilitt noch
untersttzt werden. Das steht damit im Zusammenhang, dass mit dem Windows Installer 3.x die
gesamte Verwendung von Patches erheblich verbessert und erweitert wurde. Um diese neuen
Funktionalitten nutzen zu knnen, muss ein Patch entsprechend als Windows Installer-Patch 3.0
gekennzeichnet werden. Wie das funktioniert, kommt spter. Ein nicht gekennzeichneter Patch wird
als Patch 2.0 identifiziert und wird somit nach dem alten Modell verwendet. Ein Major-UpgradePatch kann nicht als Patch 3.0 gekennzeichnet werden, so dass die neuen Funktionalitten hierbei nicht
verfgbar sind. An dieser Stelle sei angemerkt, dass sich alle weiteren Betrachtungen und
Erluterungen auf einen Patch 3.0 beziehen, der somit im Rahmen eines Small- oder Minor-Upgrades
verwendet wird.
Die Zielsetzung eines Patches liegt ganz klar in der Aktualisierung eines Softwareproduktes. Hierzu
sind einige Aktionen erforderlich, die nachfolgend dargestellt werden:
45. Das Anwenden des Patches wird durch die Befehlszeile oder durch einen Doppelklick auf die
MSP-Datei gestartet.
46. Der Summary Information Stream des Patches wird ausgewertet und die Anwendbarkeit des
Patches wird hierdurch geprft.
47. Der Client-Prozess verwendet diese Informationen und den Aufrufkontext, um das Produkt zu
bestimmen, auf das der Patch angewendet werden kann.
48. Der Client-Prozess ermittelt das Installationspaket des Produktes, das aktualisiert werden soll.
49. Der Client-Prozess prft alle Transformationen des Patches und ermittelt diejenigen, die fr das
Produkt zutreffend sind. Im Anschluss werden die ermittelten Transformationen auf eine im
Arbeitsspeicher befindlichen Kopie des Paketes angewendet.
50. Basierend auf der gewhlten Darstellungsform der Benutzeroberflche, werden die entsprechenden
Sequenztabellen verarbeitet. Wird die Installation nur mit der Basisoberflche oder ohne
Benutzeroberflche ausgefhrt, wird direkt die Tabelle InstallExecuteSequence verwendet und die
Kontrolle an den Server-Prozess bergeben.
51. Der Server-Prozess verarbeitet ebenfalls die geschilderten Schritte 47-49 und wendet die
Transformationen auf seine im Speicher befindliche Kopie des Paketes an.
52. Im Folgenden ermittelt der Windows Installer, welche Komponenten und Features im Rahmen
dieser Installation aktualisiert werden sollen. Bei einem Patch 3.0 werden diese automatisch
ermittelt, so dass sich die Aktualisierung nur auf die tatschlich vernderten Komponenten bezieht.
426
Kapitel 10
Beim Patch 2.0 ist das nicht der Fall. Hierbei muss der bereits bekannte Parameter REINSTALL
verwendet werden, um somit die betroffenen Features zu definieren.
53. Anschlieend werden die Aktionen der Sequenztabelle ausgefhrt. Bei einem Patch 2.0 werden
alle Aktionen ausgefhrt, bei einem Patch 3.0 jedoch nur diejenigen, die fr die Aktualisierung
tatschlich bentigt werden.
54. Bei einem Patch 2.0 werden schlielich alle Ressourcen erneut installiert, die den zu
aktualisierenden Features zugeordnet wurden. Bei einem Patch 3.0 werden hingegen nur die
aktualisierten Komponenten ersetzt.
Ganz entscheidend, fr die weiteren Erluterungen ist das Verstndnis fr die Anwendung eines
Patches. Das Windows Installer-Paket wird in den Arbeitsspeicher geladen und der Patch wird darauf
angewendet. Hieraus ergibt sich somit eine verbundene Ansicht, wie das auch in Abbildung 10.89
dargestellt wird.
Abbildung 10.89: Anwenden eines Patches auf ein Installationspaket
Die gerade erwhnte verbundene Ansicht lsst sich sehr schn mit Orca nachvollziehen. Hierzu ist ein
Installationspaket zu ffnen und der oder die Patches sind darauf anzuwenden. In den Tabellen wird
nun diese verbundene Ansicht verwendet, so dass sich die nderungen durch den Patch direkt ablesen
lassen. Zur Verbesserung des Komforts hebt Orca die nderungen auch farbig hervor.
Anatomie eines Patches

Bei einem Windows Installer-Patch handelt es sich um eine Datei mit der Endung MSP, die lediglich
die Differenz der Installationspakete enthlt. Hierdurch offenbart sich ein weiterer Vorteil; die Gre
eines Patches im Verhltnis zu einem klassischen Aktualisierungspaket ist wesentlich geringer, so dass
die Mglichkeiten zur Verteilung wesentlich zahlreicher sind. Wie im vorherigen Abschnitt bereits
angedeutet wurde, verfgt das Patchpaket ber einen Summary Information Stream. Hieraus lsst sich
ableiten, dass es sich bei einer MSP-Datei wiederum um ein Verbunddokument handelt. Die interne
Struktur von Verbunddokumenten kann mit dem Windows NT DocFile Viewer (dfview.exe) betrachtet
werden. Auffallend ist bei der Betrachtung einer MSI-Datei oder einer MSP-Datei, dass die Namen der
Storage-Objekte lesbar sind und die Namen der Stream-Objekte verschlsselt dargestellt werden.
Dieses lsst sich auf die Limitierungen bei der Namensvergabe in einem Verbunddokument und die
spezielle Implementierung hierfr seitens des Windows Installers zurckfhren. Die Spezifikation fr
Verbunddokumente besagt, dass die Namen der Stream- und Storage-Objekte aus maximal 32 Zeichen
(31 Zeichen + Null) bestehen drfen. Der Windows Installer speichert die Namen der Stream-Objekte
jedoch unter Verwendung einer speziellen Komprimierung, wodurch sich die Anzahl der mglichen
Zeichen auf maximal 62 erhht. Der oben dargestellte Viewer kann diese spezielle Komprimierung
nicht entschlsseln, so dass der Name der Stream-Objekte unter Verwendung von Sonderzeichen
dargestellt wird. Die Ausnahme hiervon bildet das Objekt ISummaryInformation, da es kein spezielles
Windows Installer-Objekt ist, sondern als gemeinsamer Bestandteil in allen Verbunddokumenten
vorhanden sein muss. Abbildung 10.90 zeigt, wie sich die direkte Ansicht ber den DocFile-Viewer
427
Kapitel 10
auf eine schematische Darstellung des Patches bertragen lsst.
Abbildung 10.90: Schematische Darstellung eines Patches
Die schematische Darstellung zeigt sowohl die unbedingt erforderlichen Elemente, als auch die neuen
Elemente eines Patches 3.0. Ein Windows Installer-Patch enthlt immer:
Mindestens ein Transformationspaar.
Ressourcen in Form von integrierten Kabinettdateien (Payload).
Ein Patch, der die Funktionalitt des Windows Installers 3.0 und hher verwenden soll, enthlt darber
hinaus:
Tabelle MsiPatchSequence
Tabelle MsiPatchMetadata
Ein Windows Installer-Patch kann im Gegensatz zu einem konventionellen Update auf mehrere
Produktversionen angewendet werden. So ist es mglich einen Patch zu erstellen, der ein Produkt auf
die Version 2.0 aktualisiert, unabhngig davon, ob die Version 1.0 oder 1.5 des Produktes auf dem
System installiert ist. Ein solcher Patch wird als Multi-Target-Patch bezeichnet. Darber hinaus
besteht auch die Mglichkeit einen Patch zur Aktualisierung von verschiedenen Produktlinien zu
erstellen und zu verwenden. Ein solcher Patch ist eine spezielle Form des Multi-Target-Patch und kann
sehr gut mit Multi-SKU-Patch (Stock Keeping Unit) umschrieben werden.

Bevor ein Patch auf ein Produkt angewendet werden kann, muss zunchst geprft werden, ob dieses
Produkt auf dem System vorhanden ist und ob es aktualisiert werden kann. Hierzu werden die
Metainformationen des Patches ausgewertet und anhand dieser Informationen die Existenz eines
definierten Produktcodes geprft. Mit einem einfachen Patch wird normalerweise nur eine Produktlinie
aktualisiert, so dass sich die berprfung lediglich auf einen Produktcode erstreckt. Bei einem
komplexen Patch, also einem Multi-SKU-Patch werden mehrere Produktlinien aktualisiert, so dass die
428
Kapitel 10
berprfung auf mehrere Produktcodes erfolgen muss. Die Produktcodes der Anwendungen, die durch
den Patch aktualisiert werden knnen, sind im Summary Information Stream abgelegt.
Wie zuvor erlutert, wird beim Anwenden des Patches zunchst die Existenz eines qualifizierten
Produktes geprft. Wurde kein qualifiziertes Produkt gefunden, wird die Installation mit dem
Fehlercode 1642 (ERROR_PATCH_TARGET_NOT_FOUND) beendet. Die berprfung auf
existierende Produkte wird nicht im Installationsprotokoll vermerkt, da das Installationsprotokoll erst
erstellt wird, wenn mindestens ein qualifiziertes Produkt gefunden wurde. Wurde hingegen ein Produkt
gefunden, dass rein formal aktualisiert werden kann, muss im nchsten Schritt festgestellt werden, ob
dieses auch ber die geeignete Produktversion oder Sprache verfgt. Hierzu werden die im Patch
befindlichen Transformationen bentigt.
Eingebettete Transformationen
Ein Windows Installer-Patch enthlt im Minimalfall einen Satz an eingebetteten Transformationen, die
das entsprechende Zielprodukt kennzeichnen. Jeder Satz besteht hierbei aus zwei Transformationen;
der Datenbank-Transformation und der Patch-Transformation. Beide Transformationen verfgen ber
einen identischen Namen, wobei dem Namen der Patch-Transformation das Zeichen # vorangestellt
wird. Alle Namen, der im Patch enthaltenen Transformationen sind in der Eigenschaft
PID_LASTAUTHOR des Summary Information Streams abgelegt. Da es sich um eingebettete
Transformationen handelt, wird den Bezeichnungen der Doppelpunkt : vorangestellt, wie
beispielsweise :1TTo1U;:#1TTo1U. Wie bereits erlutert besteht die Mglichkeit einen Patch zu
erstellen, der mehrere Produktversionen aktualisiert, also einen Multi-Target-Patch. Fr jedes
Zielprodukt eines solchen Patches existiert ein Transformationspaar. Bei der Anwendung eines Patches
der mehrere Transformationspaare beinhaltet, wird vom Windows Installer zunchst das zutreffende
Transformationspaar ermittelt. Hierzu werden die Daten des Summary Information Stream der
Datenbanktransformationen verwendet
Der Summary Information Stream der Datenbanktransformation bildet somit den zweiten und letzten
Prfpunkt, der feststellt, ob der Patch auf ein existierendes Produkt angewendet werden kann. Im Feld
PID_CHARCOUNT sind hierbei die Validierungsbedingungen festgelegt, die beim Anwenden der
Transformation erfllt sein mssen. In Abhngigkeit zu dem hier definierten Wert, werden die Inhalte
der Felder PID_TEMPLATE und PID_REVNUMBER fr die weitere berprfung herangezogen.
Kabinettdateien
Ein Windows Installer-Patch enthlt mindestens eine eingebettete Kabinettdatei, in der die zu
installierenden Ressourcen enthalten sind. Die Anzahl der Kabinettdateien in einem Patch richtet sich
nach der Anzahl der Datenstze in der Tabelle ImageFamilies der PCP-Datei. Bei einem normalen
Patch und bei einem Multi-Target-Patch enthlt diese Tabelle lediglich einen Datensatz, so dass
hierfr auch nur eine Kabinettdatei erstellt wird. Bei einem Multi-SKU-Patch existiert fr jedes
Ausgangsprodukt ein Eintrag in der Tabelle. Somit wird fr jedes Ausgangsprodukt eine Kabinettdatei
erstellt und in das Patch-Paket eingebettet. Bei der Erstellung eines Patches wird der Name der
Kabinettdateien durch patchwiz.dll nach dem folgenden Schema automatisch generiert:
PCW_CAB_ + Wert der Spalte Family aus der Tabelle ImageFamilies.
Eine Referenz auf das Kabinett muss bei der Anwendung des Patches in die Tabelle Media des
Installationspaketes bertragen werden. Hierzu ist ein entsprechender Eintrag in der PatchTransformation vorhanden, der ebenfalls von den weiteren Eintragungen der Tabelle ImageFamilies
der PCP-Datei abhngig ist.
429
Kapitel 10
In der Kabinettdatei sind die Ressourcen enthalten, die zur Aktualisierung des jeweiligen
Installationspaketes bentigt werden. Diese Ressourcen gliedern sich in zwei Typen von Dateien:
Vollstndige Dateien
Binr-Patches (Byte-Level-Patches)
Bei Binr-Patches handelt es sich um Dateifragmente (Delta), die beim Anwenden des Patches, die
existierende Datei in eine neuere Version berfhren. Vollstndige Dateien werden verwendet, falls
diese in der ursprnglichen Produktversion noch nicht vorhanden waren, also der neuen
Produktversion erst hinzugefgt wurden. Eine weitere Verwendungsmglichkeit von vollstndigen
Dateien ergibt sich aus einer integrierten Logik in der Bibliothek patchwiz.dll. Wurde eine Datei
extrem modifiziert, so kann es passieren, dass die Gre aller erforderlichen Binr-Patches, die
bentigt werden, um die Datei in die neue Version zu berfhren, die Gre der Datei bersteigt. In
einem solchen Fall verwendet patchwiz.dll ebenfalls eine vollstndige Datei.
Die gerade erluterten Dateitypen werden in der folgenden Reihenfolge in der Kabinettdatei abgelegt:
Zuerst die vollstndigen Dateien in der Reihenfolge wie sie in der Spalte Sequence der Tabelle File
definiert wurden.
Im Anschluss folgen die Binr-Patches in der Reihenfolge der Definition in der Spalte Sequence
der Tabelle Patch. Diese Reihenfolge wird nicht vom Autor sondern von patchwiz.dll festgelegt.
Die Verwendung von Binr-Patches kann bei der Erstellung des Patches deaktiviert werden, so dass
ausschlielich vollstndige Dateien verwendet werden. Hierzu ist in der Tabelle Property der PCPDatei die Eigenschaft IncludeWholeFilesOnly auf den Wert 1 zu setzen.
Datenbanktabellen
Mit dem Windows Installer 3.0 und hher werden neue Funktionalitten zur Verfgung gestellt, die bei
der Anwendung von Patches zum Tragen kommen. Bei einem Patch 3.0 sind zustzliche
Informationen notwendig, um diese neuen Funktionalitten zu verwenden. Aus diesem Grund enthlt
ein solcher Patch eine Datenbank die aus zwei Tabellen besteht. Alle erforderlichen Informationen sind
in diesen Tabellen abgelegt, so dass das restliche Format des Patches unverndert bleibt. Diese
Implementierung ermglicht die uneingeschrnkte Verwendung von Patches 3.0 auch auf Systemen,
auf denen einen ltere Version des Windows Installers vorhanden ist.
Tabelle MsiPatchSequence
Bei der Tabelle MsiPatchSequence handelt es sich um die wichtigste Tabelle in einem Patch 3.0. Eine
neue Funktionalitt beim Windows Installer 3.0 und hher bezieht sich auf die Festlegung der
Anwendungsreihenfolge von Patches. Hierdurch wird es mglich, eine logische Ordnung vorzugeben,
in der die Patches auf das Produkt angewendet werden sollen. Hierbei ist es unerheblich in welcher
chronologischen Reihenfolge die tatschliche Anwendung erfolgt. Die Tabelle MsiPatchSequence
enthlt alle Informationen, die der Windows Installer bentigt, um einen Small-Update-Patch relativ
zu anderen Patches anzuordnen. Bei der Anwendung eines Minor-Upgrade-Patches wird diese Tabelle
bentigt, um vorherige Patches in einen pseudoinstallierten Zustand zu versetzen (Supersedencing).
Bei der Anwendung von Patches prft der Windows Installer zunchst, ob es sich um einen Patch der
Version 3.0 handelt. Dieses ist insofern erforderlich, da modifizierte Algorithmen im Gegensatz zu
einem Patch 2.0 verwendet werden. Die Prfung auf einen Patch 3.0 wird vom Windows Installer
anhand der Existenz der Tabelle MsiPatchSequence durchgefhrt. Bei einem Patch, der ber diese
Tabelle verfgt, handelt es sich um einen Patch der Version 3.0, im anderen Fall um einen Patch der
430
Kapitel 10
Version 2.0.
Hinweis Beginn
Durch die Bezeichnung Patch 3.0 wird lediglich ausgedrckt, dass bei der Anwendung des Patches die
neuen Funktionalitten des Windows Installers 3.0 und hher verwendet werden. Hiermit wird kein
Bezug zu einer expliziten Windows Installer-Version hergestellt, denn ein solcher Patch kann zunchst
auf jedem System verwendet werden. Um die erforderliche Windows Installer-Version dennoch
festzulegen, ist die Eigenschaft PID_WORDCOUNT des Summary Information Streams zu verndern.
Hinweis Ende
Tabelle MsiPatchMetadata
Diese Tabelle ist ebenfalls im Patchpaket zu finden und enthlt beschreibende Informationen zu dem
Patch, die im Dialog Software der Windows-Systemsteuerung angezeigt werden. Darber hinaus ist die
Tabelle MsiPatchMetadata zur Kennzeichnung eines deinstallierbaren Patches erforderlich und kann
auch zur Festlegung von Optimierungseinstellungen verwendet werden. Tabelle 10.85 zeigt die
mglichen Eigenschaften der Tabelle MsiPatchMetadata.
Eigenschaft
Wert
Erforderlich
Beschreibung
AllowRemoval
Integer
Ja
Legt fest ob der Patch deinstalliert werden kann. Bei

einem Wert von 1 kann der Patch deinstalliert
werden, bei einem Wert von 0 hingegen nicht.
Classification
String
Ja
Eine Klassifizierung oder eine Kategorie fr den Patch,

die durch den Autor festgelegt wurde. Mgliche Werte
wren: Hotfix, Security Rollup, Critical Update,
Update, Service Pack oder Update Rollup.
CreationTimeUTC
String
Description
String
Ja
Beschreibung des Patches.
DisplayName
String
Ja
Ein Titel fr den Patch der im Dialog Software der

Windows-Systemsteuerung angezeigt wird.
ManufacturerName
String
Ja
Name des Herstellers der Anwendung.
MinorUpdateTargetRTM
Integer
MoreInfoURL
String
OptimizeCA
String
Ermglich die Performanceoptimierung beim

Ausfhren von benutzerdefinierten Aktionen whrend
der Anwendung von Patches. Mgliche Werte sind
hierfr 0x0, 0x1, 0x2 und 0x4.
OptimizedInstallMode
Integer
Legt fest ob beim Anwenden des Patches die

Performance optimiert werden soll (FlyweightPatches). Verfgbar mit Windows Installer 3.1 und
Legt das Erstellungsdatum und -zeit des Patches im

Format mm-dd-yy HH:MM (Monat-Tag-Jahr
Stunde:Minute) fest.
Legt fest dass dieser Patch als Zielprodukt die

ursprngliche Produktversion verwendet. Verfgbar
mit Windows Installer 3.1 und hher.
Ja
Eine URL, die zustzliche Informationen zu diesem

Update bereitstellt.
431
Kapitel 10
hher.
TargetProductName
String
Ja
Name des Zielproduktes. Multi-Target-Patches sollten

hierbei ber einen geeigneten Produktnamen verfgen.
Tabelle 10.85: Standardeigenschaften zur Definition von Metainformationen
Anwendungsreihenfolge von Patches

Zur Festlegung der Anwendungsreihenfolge wurde durch den Windows Installer 3.0 ein neues Modell
zur Verfgung gestellt, das eine effektivere Prozesssteuerung ermglicht. Durch dieses neue Modell ist
es dem Autor von Patches mglich, auf eine Logik zuzugreifen, die die Anwendungsreihenfolge von
Patches steuert, unabhngig von der chronologischen Ordnung in der die Patches auf das Produkt
angewendet wurden. Zur Realisierung mssen Abhngigkeiten zwischen den zusammengehrenden
Patches definiert werden, die bei jedem Installationsprozess erneut ausgewertet und umgesetzt werden.
Diese Abhngigkeiten werden in der Tabelle MsiPatchSequence festgelegt. Wird beispielsweise der
Hotfix 1 auf ein Produkt angewendet, das bereits ber einen installierten Hotfix 2 verfgt, wird der
Hotfix 1 zwar registriert, die Daten des Hotfix 2 werden jedoch nicht berschrieben. Wird zu einem
spteren Zeitpunkt der Hotfix 2 deinstalliert, konfiguriert der Windows Installer die Anwendung in der
Form, dass anschlieend der Hotfix 1 aktiv ist.
Bevor die beiden Modell vorgestellt werden, mchte ich nochmals auf den internen Ablauf beim
Anwenden von Patches zurckkommen. An vorheriger Stelle in diesem Kapitel und auch in
Abbildung 10.89 wurde verdeutlicht, dass der Patch auf das im Arbeitsspeicher befindliche
Installationspaket angewendet wird und somit die Produktaktualisierung auf Basis der verbundenen
Ansicht veranlasst wird. Dieser Ablauf muss noch ergnzt werden, denn es wird nicht nur der aktuell
anzuwendende Patch hierbei bercksichtigt, sondern auch alle fr das Produkt bereits registrierten
Patches. Beim Einspielen eines Patches wird dieser bekanntermaen im Ordner %windir%\installer
gespeichert und fr das Produkt registriert. In allen folgenden Installationsprozessen, wie der Reparatur
des Produktes oder dem Einspielen eines weiteren Patches, wird der registrierte Patch immer bei der
Konstruktion der verbundenen Ansicht verwendet. Aus diesem Grund ist die Anwendungsreihenfolge
entscheidend, denn diese bezieht sich auf alle Patches fr das Produkt; die bereits registrierten und
natrlich auch die neu zu installierenden. Eine Ausnahme gibt es hierbei dennoch. Es besteht die
Mglichkeit einen Patch in einen pseudoinstallierten Zustand (Supersedence) zu versetzen. Ein solcher
Patch verbleibt physisch auf dem System und auch die Registrierung fr das Produkt wird
aufrechterhalten. Allerdings wird dieser Patch nicht mehr zur Konstruktion der verbundenen Ansicht
verwendet.
Chronologische Reihenfolge
Vor der Einfhrung des Windows Installers 3.0 wurden Patches ausschlielich in chronologischer
Ordnung auf ein installiertes Produkt angewendet. Fr die meisten Szenarien war dieser Lsungsansatz
vollkommen ausreichend, obwohl einige problematische Aspekte hierbei zu bercksichtigen waren.
Ein Patch konnte hierbei eine inkorrekte Dateiversion installieren, indem ein lterer Patch nach einer
aktuelleren Version des Patches auf das Produkt angewendet wurde. Das nachfolgende
Installationsprotokoll wurde bei der Anwendung des Patches QFE1 auf ein Produkt mit bereits
installierten Patch QFE2 erstellt. Hierbei ist ersichtlich, in welcher Reihenfolge die Patches auf das
Produkt angewendet werden. Patches, die hierbei lediglich durch eine GUID dargestellt werden, sind
bereits registriert und werden zur Konstruktion der verbundenen Ansicht bentigt. Die neuen
Patches sind an der zustzlichen Pfadangabe zu erkennen. In der Darstellung der Dateiaktionen ist
432
Kapitel 10
ersichtlich, dass die bereits existierende Datei, somit mit der Datei des vorherigen Patches
berschrieben wird.
MSI (s) (A4:E0) [12:54:52:993]: PATCH SEQUENCER: 2.0 QFE patch D:\Setup\QFE1.msp is applicable.
MSI (s) (A4:E0) [12:54:52:993]: SequencePatches returns success.
MSI (s) (A4:E0) [12:54:52:993]: Final Patch Application Order:
MSI (s) (A4:E0) [12:54:52:993]: {8E11C8A0-14A6-41C0-87D3-FA3C474F9FA6} MSI (s) (A4:E0) [12:54:52:993]: {CDE584C5-07C7-425B-B3BA-5CF4642F3C45} - D:\Setup\QFE1.msp
MSI (s) (A4:E0) [12:54:54:011]: Executing op: FileCopy(SourceName=CONFIG~1.INI|Configuration.ini,

SourceCabKey=Configuration.ini,DestName=Configuration.ini,Attributes=4096,FileSize=61,
PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,
HashPart1=161935765,HashPart2=633994049,HashPart3=2099008228,HashPart4=789992881,,)
MSI (s) (A4:E0) [12:54:54:011]: File: C:\Program Files (x86)\Colors\Configuration.ini; Overwrite;
Won't patch; Existing file is unversioned and unmodified - hash doesn't match source file
Da dieses Verhalten nicht in allen Fllen gewnscht wird, besteht die Notwendigkeit im Rahmen der
Patch-Erstellung eine Logik zu verwenden, die dieses Verhalten unterbindet. Hierzu ist es erforderlich
die Validierungsbedingungen fr den Patch auf den ProductCode und die ProductVersion
auszudehnen. Solange Patches verwendet werden, die auch die Produktversion verndern, also MinorUpgrade-Patches, erfllt diese Implementierung die definierten Anforderungen. Bei der Verwendung
von Small-Update-Patches kann diese Implementierung jedoch nicht den gewnschten Erfolg
vorweisen. Da ein solcher Patch die Produktversion nicht verndert, ist bei der Anwendung eines
weiteren Patches anhand der Validierungsbedingungen nicht berprfbar, ob die Installation im
Original- oder einem bereits aktualisierten Zustand auf dem System vorhanden ist. Eine wirkungsvolle
Lsung fr dieses Problem ist mit den Funktionen des Windows Installers 2.0 und frher nicht
mglich.
Logische Reihenfolge
Bei der Verwendung des Windows Installers 3.0 und hher existiert fr den Autor des Patches eine
Implementierung, mit der die Anwendungsreihenfolge von Patches festgelegt werden kann. Hierbei ist
die chronologische Reihenfolge unerheblich, in der die Patches auf das Produkt angewendet werden.
Es wird bereits beim Design des Patches die erforderliche Reihenfolge definiert. Der Windows
Installer kombiniert bei der Anwendung die festgelegten logischen Ordnungsmerkmale mit den
Inhalten des Patches, um hieraus die exakten Ressourcen fr das Produkt zu bestimmen, unabhngig
davon, in welcher chronologischen Reihenfolge der Patch auf das Produkt angewendet wurde.
In dem vorherigen Beispiel wurde der Patch QFE1 in der zeitlichen Abfolge nach dem Patch QFE2 auf
das Produkt angewendet. Als Ergebnis wurden hierbei neuere Ressourcen berschrieben, da keine
logische Anwendungsreihenfolge zwischen den beiden Patches definiert wurde bzw. definiert werden
konnte. Den beiden Patches wurden nun Sequenzinformationen hinzugefgt, die definieren, dass der
Patch QFE1 in einer logischen Ordnung immer vor dem Patch QFE2 angewendet wird. Bei der
tatschlichen Anwendung des Patches wertet der Windows Installer diese Informationen aus und
erstellt daraufhin die exakte Anwendungsreihenfolge fr die Patches. Diese Informationen werden
detailliert dem Installationsprotokoll angefgt.
MSI (s) (AC:F4) [13:13:19:957]: PATCH SEQUENCER: verifying the applicability of QFE patch D:\Setup\QFE1.msp
against product code: {AE581993-EA96-4632-A0F8-2D3B7DBB86E8}, product version: 1.00.0000, product language
1031 and upgrade code: {30F18E7F-D3A8-4B41-B120-79010859477A}
MSI (s) (AC:F4) [13:13:19:957]: PATCH SEQUENCER: QFE patch D:\Setup\QFE1.msp is applicable.
433
Kapitel 10
MSI (s) (AC:F4) [13:13:19:958]: PATCH SEQUENCER: The resulting #_OrderedGUIDs table:
MSI (s) (AC:F4) [13:13:19:958]: Patch: {CDE584C5-07C7-425B-B3BA-5CF4642F3C45} Order: 0 (Family: RM)
MSI (s) (AC:F4) [13:13:19:958]: Patch: {8E11C8A0-14A6-41C0-87D3-FA3C474F9FA6} Order: 1 (Family: RM)
MSI (s) (AC:F4) [13:13:19:958]: The ordered #_QFESequence table: - has the final sequence of QFEs. It lists
each PatchGUID only once.
MSI (s) (AC:F4) [13:13:19:958]: PatchGUID: {CDE584C5-07C7-425B-B3BA-5CF4642F3C45} ResultantVersion: 1.00.0000
PatchFamily: RM Sequence: 1.0.0.100 Order: 0
MSI (s) (AC:F4) [13:13:19:958]: PatchGUID: {8E11C8A0-14A6-41C0-87D3-FA3C474F9FA6} ResultantVersion: 1.00.0000
PatchFamily: RM Sequence: 1.0.0.200 Order: 1
MSI (s) (AC:F4) [13:13:19:958]: PATCH SEQUENCER: there's no supersedence information available, so no patches
will be superseded.
MSI (s) (AC:F4) [13:13:19:958]: SequencePatches returns success.
MSI (s) (AC:F4) [13:13:19:958]: Final Patch Application Order:
MSI (s) (AC:F4) [13:13:19:958]: {CDE584C5-07C7-425B-B3BA-5CF4642F3C45} - D:\Setup\QFE1.msp
MSI (s) (AC:F4) [13:13:19:958]: {8E11C8A0-14A6-41C0-87D3-FA3C474F9FA6} -
In dem Protokollauszug ist vornehmlich an den letzten Eintrgen zu erkennen, dass der Patch QFE1 in
der logischen Reihenfolge vor dem Patch QFE2 angeordnet wurde, obwohl er von der zeitlichen
Abfolge erst danach eingespielt wird.
Hinweis Beginn
Die
Windows
Installer-Programmierschnittstelle
enthlt
die
Funktionen
MsiDeterminePatchSequence() und MsiDetermineApplicablePatches() mit deren Hilfe die
Anwendungsreihenfolge von Patches ermittelt werden kann. Bei der Verwendung der Deployment
Tools Foundation ist die Funktion Installer.DetermineApplicablePatches() zu verwenden.
Hinweis Ende

Wie im Kapitel 2 bereits erlutert, werden zur Erstellung von Windows Installer-Patches zunchst die
Installationspakete der bisherigen- und der neuen Produktversion bentigt. Hierbei ist es erforderlich,
dass die enthaltenen Ressourcen im nicht komprimierten Zustand vorliegen, also nicht in Form von
Kabinettdateien, die in das Paket integriert wurden. Sind diese Voraussetzungen geschaffen, ist ein
Tool oder eine Implementierung erforderlich, um die Differenz der Installationspakete zu ermitteln und
daraus einen Windows Installer-Patch zu generieren. Das Windows Installer-SDK enthlt zu diesem
Zweck das Befehlszeilentool msimsp.exe. Dem Befehlszeilenaufruf ist eine Datei anzufgen, in der die
individuellen Einstellungen fr den zu erzeugenden Patch vorgenommen werden. Bei dieser Datei
handelt es sich um ein speziell fr diese Zwecke strukturiertes Windows Installer-Paket, dass als Patch
Creation Property File, oder kurz PCP-Datei bezeichnet wird.
Klassischer Lsungsansatz
In Abbildung 10.91 wird der Prozess zur Erstellung von Patches schematisch verdeutlicht. Es soll ein
Produkt, dass die Dateien dd.exe und hilfe.chm enthlt, auf die Version 1.2 aktualisiert werden. Als
Ausgangsprodukt wird sowohl die Version 1.0, als auch die Version 1.1 untersttzt. Die tatschliche
Erstellung erfolgt durch das Tool msimsp.exe, das die Informationen der PCP-Datei verwendet. Das
434
Kapitel 10
Ergebnis des Erstellungsprozesses ist letztlich ein Windows Installer-Patch. Hier bei sei anzumerken,
dass die Logik zum Erstellen von Patches in der Datei patchwiz.dll aus dem Windows Installer-SDK
verankert ist. Diese Datei wird von nahezu allen Tools und Anwendungen zur Erstellung von Patches,
einschlielich des Befehlszeilentools msimsp.exe verwendet. Ergnzende Erluterungen zu der
patchwiz.dll folgen an spterer Stelle.
Abbildung 10.91: Schematischer Prozess zur Erstellung von Patches.
Das Erstellen eines Windows Installer-Patches ist als nicht trivialer Prozess anzusehen, da viele
strukturierte Ablufe einflieen mssen. Um bereits im Vorfeld Problemflle bei der Anwendung eines
Windows Installer-Patches auszuschlieen, sollten die folgenden Hinweise beachtet werden:
Die Primrschlssel der Tabelle File (FTK) zwischen den Originalpaketen und dem
Aktualisierungspaket drfen nicht verndert werden.
Es drfen keine Dateien von einem Installationsordner in einen anderen verschoben werden.
Es drfen keine Dateien von einer Kabinettdatei in eine andere verschoben werden.
Die Reihenfolge der Dateien in einer Kabinettdatei darf nicht verndert werden.
Die Verwendung von Primrschlsseln der Tabelle File, die sich lediglich durch Gro- und
Kleinschreibung unterscheiden, ist zu vermeiden.
Falls die erforderlichen Ressourcen vorliegen und die entsprechenden Hinweise beachtet wurden, kann
mit der Erstellung des Patches begonnen werden. An dieser Stelle wird nun die klassische
Vorgehensweise erlutert, die mit dem Bordmitteln des Windows Installer-SDK durchgefhrt wird.
Die abweichende Methode unter ausschlielicher Verwendung von Windows Installer-XML wurde
bereits im Kapitel 2 erlutert. Zur Erstellung eines Patches auf eben diese klassische Weise, gehen Sie
wie folgt vor:
Erstellen Sie eine Kopie des Basisinstallationspaketes und nehmen Sie die entsprechenden
Modifikationen daran vor. Beachten Sie, dass das Originalinstallationspaket zur Erzeugung eines
Patches bentigt wird.
Erstellen Sie vom Basisinstallationspaket ein administratives Abbild, indem Sie die Installation mit
dem Parameter /a ausfhren. Bei der Verwendung mehrerer Ausgangsprodukte mssen Sie von
jedem Produkt ein administratives Abbild erstellen.
435
Kapitel 10
Erstellen Sie vom Aktualisierungspaket ebenfalls ein administratives Abbild.

Legen Sie die Einstellungen fr die Erstellung des Patches fest, indem sie diese der PCP-Datei
anfgen. Erstellen Sie hierzu eine PCP-Datei mit Hilfe von Windows Installer-XML oder
verwenden sie die Vorlage aus dem Windows Installer-SDK, die mit Orca angepasst wurde.
Erstellen Sie den Patch, indem Sie das Tool msimsp.exe aus dem Windows Installer-SDK
verwenden und die entsprechenden Informationen als Parameter bergeben. Alternativ knnen Sie
auch die Funktion UICreatePatchPackageEx() der Datei patchwiz.dll aufrufen. Diese Datei ist
ebenfalls im Windows Installer-SDK enthalten.
Das Ergebnis dieses Vorgangs ist ein Windows Installer-Patch, der auf die entsprechenden Produkte
angewendet werden kann.
Der wahrscheinlich komplizierteste Schritt bei der Erstellung eines Patches ist die Erzeugung oder
Aktualisierung der PCP-Datei mit Hilfsmitteln wie Orca. Einfacher und effektiver lsst sich dieser
Schritt durch die Implementierungen der Toolsammlung Windows Installer-XML durchfhren. Zu
diesem Zweck wird das XML-Element <PatchCreation/> zur bentigt. Listing 10.90 zeigt ein WXSDokument zur Erzeugung einer solchen Datei, mit der spter ein Small-Update-Patch erzeugt werden
kann. Zu beachten ist hierbei die Definition der Anwendungsreihenfolge des Patches durch das
Element <PatchSequence/>. Das Attribut Sequence legt die Relation zu anderen Patches fr dieses
Produkt fest. In diesem Beispiel wurde hierfr der Wert 1.0.0.100 vergeben. Soll ein Patch in der
logischen Anwendungsreihenfolge nach diesem Patch angeordnet werden, ist eine hhere
Sequenznummer zu verwenden.
<PatchCreation Id="CDE584C5-07C7-425b-B3BA-5CF4642F3C45" AllowMajorVersionMismatches="yes"
AllowProductCodeMismatches="yes" CleanWorkingFolder="yes" Codepage="1252">

<PatchInformation Description="Windows Installer Patch Package" Manufacturer="Microsoft Deutschland GmbH"
Compressed="yes" Platforms="Intel" Languages="1031" SummaryCodepage="1252"/>

<PatchMetadata Description="Dieser Patch enthlt die Logik und die Daten zur Aktualisierung des Produktes
Colors 1.0." DisplayName="QFE1" ManufacturerName="Microsoft Deutschland GmbH"
MoreInfoURL="http://www.microsoft.com/germany" TargetProductName="Colors 1.0"
AllowRemoval="yes" Classification="Hotfix" OptimizedInstallMode="yes"/>

<Family Name="F6A1AAC2" DiskId="5000" SequenceStart="5000" MediaSrcProp="MNPSrcPropName" >
<UpgradeImage Id="U1" SourceFile="$(env.Temp)\WIX\1.1\product.msi">
<TargetImage Id="T1" Order="1" SourceFile="$(env.Temp)\WIX\1.0\product.msi" IgnoreMissingFiles="yes"
Validation="0x00000922"/>
</UpgradeImage>
</Family>

<PatchSequence PatchFamily="RM" Sequence="1.0.0.100" Supersede="no" />

<TargetProductCode Id="*" />
436
Kapitel 10


<PatchProperty Name="MinimumRequiredMsiVersion" Value="300"/>
</PatchCreation>
</Wix>
Listing 10.90: Erstellen einer PCP-Datei mit Windows Installer-XML.
Durch das Kompilieren und Linken der erforderlichen Dateien, wird eine vollstndige PCP-Datei
erzeugt, die smtliche Informationen zur spteren Erstellung des Patches enthlt.
Objektbibliothek patchwiz.dll
Nachdem die administrativen Abbilder und die PCP-Datei erstellt wurden, kann auf Grundlage dieser
Informationen das Patchpaket erzeugt werden. Das Windows Installer-SDK stellt zu diesem Zweck die
Objektbibliothek patchwiz.dll bereit, in der alle notwendigen Funktionalitten integriert sind. Diese
Bibliothek kann sowohl programmtechnisch, als auch ber das Tool msimsp.exe zur Erstellung eines
Patches verwendet werden, wobei dieses durch die nachfolgenden Schritte realisiert wird:
Analyse der Dateien des Aktualisierungspaketes und der Zielpakete.
Erstellen der Transformationen.
Erstellen der Kabinettdatei.
Integration der Transformationen und der Kabinettdatei in das Patchpaket.
Die Erstellung von Patches unter Verwendung der Bibliothek patchwiz.dll hat sich im Vergleich zu
vorherigen Versionen des Windows Installers nicht wesentlich gendert. Allerdings wurde diese
Bibliothek bei der Entwicklung des Windows Installer 4.0 vollstndig neu entwickelt, wobei ein
Schwerpunkt auf die Geschwindigkeit beim Erstellen von Patches gelegt wurde. Allerdings verfgte
die Version 4.0 der patchwiz.dll ber gravierende Fehler, die sogar zu Datenverlusten fhren konnten.
Aus diesem Grund wurde eine fehlerbereinigte Version dem Windows Installer-SDK 4.5 hinzugefgt
und deswegen erst an dieser Stelle des Buches erlutert.
Achtung Beginn
Zur Vermeidung von Datenverlusten sollte unbedingt die Version 4.5 der patchwiz.dll verwendet
werden.
Achtung Ende
Verwenden des Tools msimsp.exe

Das Tool msimsp.exe dient dazu, aus den vorliegenden Informationen und den existierenden Dateien,
einen Windows Installer-Patch zu erzeugen. Die Funktionalitt zur Erzeugung von Patches wird jedoch
von der Bibliothek patchwiz.dll zur Verfgung gestellt, so dass msimsp.exe lediglich die
Benutzersteuerung ermglicht, um die Funktionalitten dieser Bibliothek zu verwenden. Bei
msimsp.exe handelt es sich um ein Befehlszeilentool, dass durch die folgende Aufrufsyntax verwendet
werden kann.
msimsp.exe -s [Pfad zur PCP-Datei] -p [Pfad zur PCP-Datei] {Optionen}
Die dargestellten Optionen sind zwingend notwendig. Es knnen jedoch noch weitere optionale
437
Kapitel 10
Parameter, beispielsweise zur Spezifikation eines Protokolls verwendet werden.

Option
Parameter
Beschreibung
-s
{Pfad zur PCP-Datei}
Enthlt den vollstndigen Pfad zur existierenden PCP-Datei.
-p
{Pfad zur MSP-Datei}
Legt das zu erstellende Patchpaket fest.
-f
{Temporrer Ordner}
Enthlt den vollstndigen Pfad zu einem temporren Ordner.

Standardmig wird der Ordner %temp%\~pcw_tmp.tmp\ verwendet.
(Optional)
-l[p]
{Pfad zum Protokoll}
Enthlt die vollstndige Pfadangabe zu dem Protokoll, das erstellt werden

soll oder an das die Eintragungen angefgt werden sollen. Bei
Verwendung der zustzlichen Option p werden Performancedaten dem
Protokoll angefgt. Hierzu wird die patchwiz.dll in der Version 4.0 oder
hher bentigt. (Optional)
-k
Der Erstellvorgang schlgt fehl, wenn der Ordner fr die temporren

Daten bereits vorhanden ist. (Optional)
-d
Zeigt einen Hinweisdialog nachdem der Patch erstellt worden ist.

(Optional)
-?
Zeigt den Hilfedialog an.
Tabelle 10.86: Befehlszeilenoptionen von msimsp.exe
Verwenden der Funktionen UiCreatePatchPackageEx() und

UiCreatePatchPackage()
Zur Erstellung von Patches ist das Tool msimsp.exe nicht unbedingt erforderlich. Es besteht ebenfalls
die Mglichkeit, die Generierung eines Patches durch eine eigene Implementierung zu veranlassen.
Hierzu ist die Objektbibliothek patchwiz.dll erforderlich, die fr diesen Zweck die beiden Funktionen
UiCreatePatchPackage() und UiCreatePatchPackageEx() zur Verfgung stellt. Die Funktion
UiCreatePatchPackageEx() verfgt ber die nachfolgend aufgefhrten Aufrufparameter. Hierbei
handelt es sich um eine optimierte Fassung der Funktion UiCreatePatchPackage(), die in der
patchwiz.dll der Version 4.0 und hher enthalten ist.
[DllImport("patchwiz.dll", CharSet = CharSet.Unicode)]
private static extern uint UiCreatePatchPackageEx(
string szPcpPath,
string szPatchPath,
string szLogPath,
System.IntPtr hwndStatus,
string szTempFolder,
bool fRemoveTempFolderIfPresent,
int dwFlags,
int dwReserved);
Die Signatur der Funktion UiCreatePatchPackage() ist hiermit nahezu identisch, allerdings sind die
Parameter dwFlags und dwReserved nicht vorhanden. Die nachfolgende Erluterung der Argumente
kann dennoch auf beide Funktionen bertragen werden.
szPcpPath: Enthlt die vollstndige Pfadangabe zur PCP-Datei, die zur Generierung des Patches
438
Kapitel 10
verwendet werden soll.

szPatchPath: Enthlt die vollstndige Pfadangabe zur MSP-Datei, die erstellt werden soll. Dieser
Parameter kann Null oder eine leere Zeichenfolge enthalten. In diesem Fall muss allerdings das zu
erstellende Patchpaket durch die Eigenschaft PatchOutputPath in der Tabelle Properties der PCPDatei festgelegt werden.
szLogPath: Enthlt den vollstndigen Pfad zu einer Protokolldatei, die erstellt werden soll oder der
neue Eintrge angefgt werden sollen. Dieser Parameter kann Null oder eine leere Zeichenfolge
enthalten, aber er darf nicht fortgelassen werden.
hwndStatus: Enthlt das Handle zu einem Fenster, in dem die Statusinformationen ausgegeben
werden sollen. Dieser Parameter kann Null enthalten, aber er darf nicht fortgelassen werden.
Beachten Sie jedoch, dass es zu Datenverlusten fhren kann, falls dieser Parameter auf Null
festgelegt wird.
szTempFolder: Enthlt eine vollstndige Pfadangabe zu einem Ordner, in dem die temporren
Dateien abgelegt werden sollen. Standardmig werden diese im Ordner %temp%\~pcw_tmp.tmp\
gespeichert. Dieser Parameter kann Null oder eine leere Zeichenfolge enthalten, aber er darf nicht
fortgelassen werden.
fRemoveTempFolderContents: Legt die Verwendung des Ordners fr die temporren Dateien fest.
Wird dieser Parameter auf True gesetzt, werden der temporre Ordner und dessen Inhalt entfernt.
Wird hingegen False verwendet, schlgt der Funktionsaufruf fehl, falls der Ordner bereits existiert.
dwFlags: Dieser Parameter kann auf einen Wert oder eine Kombination von Werten der Tabelle
10.87 festgelegt werden. Hiermit kann primr der Umfang der Protokollierung festgelegt werden.
dwReserved: Reserviert. Dieser Parameter muss auf 0 gesetzt werden.
Wert
Bedeutung
0x00000000
Es werden keine Nachrichten dem Protokoll angefgt.
0x00000001
Es werden Informationen dem Protokoll angefgt.
0x00000002
Es werden Warnungen dem Protokoll angefgt.
0x00000004
Es werden Fehlermeldungen dem Protokoll angefgt.
0x00000008
Es werden Informationen zur Performance bei der Erstellung des Patches dem Protokoll
angefgt.
0x00000000f
Es wird keine Benutzeroberflche angezeigt.
0x00000010
Die Benutzeroberflche wird angezeigt.
Tabelle 10.87: Attribute zur Festlegung des Protokollumfangs
Bei fehlerfreier Ausfhrung der Funktion UiCreatePatchPackageEx() oder UiCreatePatchPackage()

wird ERROR_SUCCESS zurckgegeben. Sollte es hingegen zu einem Fehler kommen, kann ber den
Rckgabewert die exakte Fehlerursache bestimmt werden. Die mglichen Rckgabewerte sind in der
Dokumentation des Windows Installer-SDK erlutert.
Im nachfolgenden Listing 10.91 wird beim Auftreten eines von ERROR_SUCCESS abweichenden
Rckgabewertes eine System.ComponentModel.Win32Exception() ausgelst und somit der aufrufenden
Funktion mitgeteilt, dass kein Patch erstellt werden konnte. Ansonsten ist erkennbar, dass hierbei die
439
Kapitel 10
Funktion UiCreatePatchPackageEx() verwendet wurde.

internal static class Patching
{
// Protokollierung der Patcherstellung
internal enum LoggingMode : int
{
None
= 0x00000000,
Info
= 0x00000001,
Warning
= 0x00000002,
Error
= 0x00000004,
Performance = 0x00000008
}
// Deklaration der Funktion
[DllImport("patchwiz.dll", CharSet = CharSet.Unicode)]
private static extern uint UiCreatePatchPackageEx(
string szPcpPath,
string szPatchPath,
string szLogPath,
System.IntPtr hwndStatus,
string szTempFolder,
bool fRemoveTempFolderIfPresent,
int dwFlags,
int dwReserved);
// Erstellen eines Patches
internal static void CreatePatch(string fileNamePCP, string fileNamePatch, LoggingMode loggingMode)
{
// Protokollname konstruieren
string logFileName = Path.ChangeExtension(fileNamePatch, "log");
// Patch erstellen
uint ret = UiCreatePatchPackageEx(fileNamePCP, fileNamePatch, logFileName, IntPtr.Zero,
string.Empty, true, (int)loggingMode, 0);
// Exception auslsen
if (ret != 0)
throw new Win32Exception((int)ret);
}
}
Listing 10.91: Erstellen eines Patches durch Verwenden der Funktion UICreatePatchPackageEx()
Wie zuvor schon angedeutet, kann die Verwendung der Version 4.0 von patchwiz.dll zu
Datenverlusten fhren, falls die Bibliothek auf folgende Weise verwendet wird:
Die Funktion UiCreatePatchPackage() wird aufgerufen und der Parameter hwndStatus wird auf
Null gesetzt.
Oder die Funktion UiCreatePatchPackageEx() wird aufgerufen, der Parameter hwndStatus wird
auf Null und dwFlags wird auf 0x8000 gesetzt.
Oder die Bibliothek patchwiz.dll 4.0 wird durch die Version 3.0 der msimsp.exe aufgerufen.
Intern wird in diesen Fllen der Fehlercode falsch ausgewertet und als Indikator zum Lschen der
temporren Daten angesehen. Hierbei wird jedoch nicht das temporre Verzeichnis entfernt, sondern es
440
Kapitel 10
werden die Daten des schreibbaren Bereichs des Stammverzeichnisses gelscht.

Zur Vermeidung dieses gravierenden Problems sollte die Version 4.5 der patchwiz.dll verwendet
werden. Falls das nicht mglich ist sollte auf die Version 3.1 ausgewichen werden. Soll jedoch die
Version 4.0 verwendet werden, drfen die Parameter nicht in der skizzierten Darstellung benutzt
werden. Auch die Verwendung der msimsp.exe der Version 4.0 ist mglich, denn dieses kann gefahrlos
in Verbindung mit der patchwiz.dll 4.0 verwendet werden.
Interne Ablufe
Die patchwiz.dll 4.0 wurde vollstndig auf neu entwickelt. Ihr liegt nun ein modernes WorkflowKonzept zu Grunde, so dass sich der Gesamtablauf sehr strukturiert und transparent darstellt, wie das
auch in Abbildung 10.92 ersichtlich ist.
Abbildung 10.92: Workflow zur Erstellung eines Patches
Dem Funktionsaufruf von UICreatePatchPackage() werden die PCP-Datei und einige zustzliche
Parameter bergeben, wie das auch im Workflow dargestellt ist. Im Folgenden werden mehrere Phasen
durchlaufen, in denen Zwischenergebnisse erzeugt und spter zusammengefgt werden. Das Ergebnis
ist letztlich die spezifizierte Patch-Datei. In dem Protokoll des Generierungsvorgangs werden die
einzelnen Phasen entsprechend dargestellt.
Phase 1: Validierung
Den Beginn macht die Phase 1, in der eine Validierung der Eingabeparameter und der erforderlichen
Dateien durchgefhrt wird. Die berprfung der Eingabeparameter erstreckt sich sowohl auf die
Argumente des Funktionsaufrufs, als auch auf die Informationen der PCP-Datei. Entspricht ein
441
Kapitel 10
Parameter nicht den Vorgaben, wird die Erstellung an dieser Stelle beendet, wie auch der Auszug des
Protokolls verdeutlicht.
INFO: Using Pcp Path: D:\Fix1.1\qfe1.pcp.
INFO: Using Temporary Directory: C:\Users\AK\AppData\Local\Temp\~pcw_tmp.tmp.
INFO: Passed all of the main control parameter validation to PatchWiz, now calling the next 5 phases.
INFO: Phase I: Entered validation and processing phase.
INFO:
Validation of Pcp.
ERROR: The property `MinimumRequiredMsiVersion` in the PCP File is invalid.
ERROR:
The Last Error Received is: 87
PERF INFO: Time Spent Validating: 14 ms
INFO: Temporary folder is about to be cleaned out and deleted: C:\Users\AK\AppData\Local\Temp\~pcw_tmp.tmp
ERROR: Internal PatchWiz Error occurred.
ERROR:
The Last Error Received is: -1072803326
PERF INFO: Total Patch Creation Time: 17 ms
ERROR: The Last Error Received is: -1072803326
Anschlieend wird geprft, ob die bentigten Installationspakete vorhanden sind und ob diese im
entsprechenden Format vorliegen. Auch hier wird abgebrochen, falls die Vorgaben nicht erfllt
wurden.
INFO: Using Pcp Path: D:\Fix1.1\qfe1.pcp.
INFO: Using Temporary Directory: C:\Users\AK\AppData\Local\Temp\~pcw_tmp.tmp.
INFO: Passed all of the main control parameter validation to PatchWiz, now calling the next 5 phases.
INFO: Phase I: Entered validation and processing phase.
INFO:
Validation of Pcp.
INFO:
MinimumRequiredMsiVersion is 300.
INFO:
SEQUENCE_DATA_GENERATION_DISABLED is 0.
INFO:
ListOfPatchGUIDsToReplace is .
INFO:
ListOfTargetProductCodes is *.
INFO:
PatchGUID is {CDE584C5-07C7-425B-B3BA-5CF4642F3C45}.
INFO:
PatchOutputPath is D:\Fix1.1\qfe1.msp.
INFO:
AllowProductCodeMismatches is 1.
INFO:
AllowProductVersionMajorMismatches is 1.
INFO:
ApiPatchingSymbolFlags is 0.
INFO:
DontRemoveTempFolderWhenFinished is 0.
INFO:
IncludeWholeFilesOnly is 0.
INFO:
OptimizePatchSizeForLargeFiles is 0.
INFO:
TrustMsi is 0.
INFO:
AllowLaxValidationFlags is 0.
ERROR: TargetImages.MsiPath 'D:\Setup\FB.msi' is marked as having compressed files (PID_WORDCOUNT property
of Summary Information stream). PatchWiz is unable to patch files compressed in a cabinet.
ERROR:
The Last Error Received is: 0
PERF INFO: Time Spent Validating: 36 ms
ERROR:
The Last Error Received is: -1072803554
Phase 2: Erzeugen der Datenbank-Transformation

Nach dieser Prfung ist die Phase 1 abgeschlossen und es wird in Phase 2 gewechselt. In dieser Phase
442
Kapitel 10
wird die erste Transformation erzeugt und auf dem Datentrger gespeichert. Hierbei handelt es sich um
die Datenbank-Transformation, die letztlich die Modifikationen zwischen der Datenbank des
Basispaketes und der Datenbank des Aktualisierungspaketes enthlt. Diese Transformation wird
demzufolge nur bentigt, um die vorgenommenen nderungen in der verbundenen Ansicht
abzubilden. Das bedeutet auch, dass die Transformation keine Mechanismen enthlt um die
Ressourcen physisch zu aktualisieren. Die Erstellung der Transformation ist relativ einfach, denn
dieses geschieht unter Verwendung der Funktion MsiDatabaseGenerateTransform(), wobei das Basisund das Aktualisierungspaket bergeben werden.
Phase 3: Analyse und Erstellen der Patch-Transformation
Die Phase 3 ist nochmals unterteilt, denn hierbei handelt es sich um den komplexesten Vorgang
innerhalb der Patch-Generierung. Letztlich wird hierbei die Patch-Transformation erzeugt und es
werden die Dateien ermittelt, die sich im Aktualisierungspaket gendert haben.
Der erste Schritt betrifft die Ermittlung dieser Dateien, wobei die Eigenschaft TrustMsi entscheidend
ist, die in der Tabelle Properties der PCP-Datei festgelegt werden kann. Der Standardwert dieser
Eigenschaft ist 0. Wurde dieser Wert nicht verndert, werden die administrativen Abbilder zur
Feststellung der genderten Dateien verwendet. Das bedeutet, dass ein physischer Vergleich jeder
Datei zwischen dem Basis- und dem Aktualisierungs-Abbild durchgefhrt wird. Ausgenommen sind
jedoch die Dateien, die in der Tabelle UpgradedFilesToIgnore enthalten sind. Es wird zunchst geprft
ob die Dateigre und oder die Dateiversion abweicht. In diesem Fall wurde die Datei auf jeden Fall
verndert und sie wird der Liste der genderten Dateien hinzugefgt. Ist die Dateigre und die
Version identisch, wird Byte fr Byte geprft, ob Unterschiede vorhanden sind. Wurde hingegen die
Eigenschaft TrustMsi auf den Wert 1 festgelegt, wird die in Phase 2 erzeugte DatenbankTransformation zur Ermittlung der genderten Dateien verwendet. Hierbei werden nun alle Dateien der
Liste hinzugefgt, die ber abweichende Daten in der Tabelle File oder MsiFileHash verfgen.
Das Ergebnis der Phase3a ist somit eine Auflistung der genderten Dateien, die nun nacheinander
abgearbeitet und an Phase 3b bergegen werden. Das bedeutet, dass in dieser Phase jede der
genderten Dateien fr die physische Modifikation des Zielsystems vorbereitet wird. Hier wird
zunchst die Eigenschaft IncludeWholeFilesOnly ausgewertet, die in der Tabelle Properties der PCPDatei festgelegt werden kann. Wurde diese Eigenschaft auf den Wert 1 festgelegt, werden
vollstndige Dateien in den Patch bertragen. Das bedeutet, dass von jeder Datei zunchst eine Kopie
erstellt und im Ausgabeverzeichnis abgelegt wird. Weiterhin wird ein Verweis hierauf in die DDFDatei bertragen. Hierbei handelt es sich um eine Steuerdatei, die zur Erzeugung der Kabinettdatei
bentigt wird. Wurde die Eigenschaft IncludeWholeFilesOnly hingegen auf den Wert 0 gesetzt oder
wurde diese Eigenschaft gar nicht definiert, wird ein Binr-Patch erstellt. Das bedeutet, dass die
binren Abweichungen zwischen der ursprnglichen und der aktuellen Datei ermittelt und diese in eine
Datei bertragen werden. Falls konfiguriert werden hierbei noch eventuelle Symboldateien
ausgewertet, da hiermit eine effektivere Identifikation der Abweichungen ermglicht wird. Zur
Generierung der binren Deltas wird die Funktion CreatePatchFileEx() der Bibliothek mspatchc.dll
aufgerufen. Die so erzeugten Deltas werden ebenfalls im Ausgabeverzeichnis abgelegt und eine
Referenz wird der DDF-Datei hinzugefgt. Wird hingegen eine Datei dem Produkt durch den Patch
hinzugefgt, kann kein Delta erstellt werden, da eine ursprngliche Datei gar nicht vorhanden ist. Die
Datei wird somit in vollstndiger Form in den Patch integriert. Nachdem alle binren Deltas erstellt
wurden, wird noch geprft, ob diese grer sind, als die entsprechende vollstndige Datei. Falls das
der Falls ist, wird anstelle des binren Deltas die vollstndige Datei verwendet.
Nachdem fr jede genderte Datei, ein binres Delta oder eine vollstndige Datei ins
443
Kapitel 10
Ausgabeverzeichnis abgelegt wurden und die DDF-Datei erzeugt wurde, wird die PatchTransformation erzeugt. Die Patch-Transformation ist erforderlich um die Ressourcen physisch zu
modifizieren. Fr die Erstellung dieser Transformation wird zunchst eine Kopie des
Aktualisierungspaketes erstellt und die unten aufgefhrten nderungen darin vorgenommen. Im
Anschluss daran wird eine Transformation zwischen dem vernderten und dem unvernderten
Aktualisierungspaket erstellt. Die in den nachfolgenden Tabellen dargestellten nderungen, die an der
Kopie des Aktualisierungspaketes vorgenommen werden, resultieren berwiegend aus den
Einstellungen und Daten der PCP-Datei.
Die Tabelle PatchPackage beschreibt alle Patches, die auf dieses Produkt angewendet wurden. Dieser
Tabelle wird ein Datensatz mit den folgenden Informationen angefgt:
Feld der Tabelle
Informationen aus der PCP-Datei
PatchPackage.PatchId
Property.PatchGUID
PatchPackage.Media
ImageFamilies.MediaDiskId
Tabelle 10.88: Modifizieren der Tabelle PatchPackage
Die Tabelle Media enthlt Informationen ber die Quellmedien, die zur Installation bentigt werden.
Dieser Tabelle wird ebenfalls ein neuer Datensatz hinzugefgt.
Feld der Tabelle
Media.DiskId
ImageFamilies.MediaDiskId
Media.LastSequence
ImageFamilies.FileSequenceStart + die Anzahl der Dateien oder BinrPatches in der Kabinettdatei.
Media.DiskPrompt
ImageFamilies.DiskPrompt
Media.Cabinet
Name der Kabinettdatei, die in den Patch integriert wurde. Der zu

verwendende Name ist nicht konfigurierbar, sondern wird aus mehreren
Werten konstruiert.
Media.VolumeLabel
ImageFamilies.VolumeLabel
Media.Source
ImageFamilies.MediaSrcPropName
Tabelle 10.89: Modifizieren der Tabelle Media
Die Tabelle File enthlt eine komplette Aufstellung der Quelldateien mit den bentigten Attributen.
Dateien knnen auf dem Quellmedium im nicht komprimierten Zustand oder in einer Paketdatei
gespeichert werden. Dieser Tabelle wird fr jede vollstndige Datei, die der Kabinettdatei hinzugefgt
wird, ein Datensatz mit den dateispezifischen Informationen angefgt.
Feld der Tabelle
File.Attributes
msidbFileAttributesPatchAdded
File.Sequence
Die Sequenznummer, die mit dem Wert aus ImageFamilies.FileSequenceStart beginnt

und fr jede Datei oder jeden Binr-Patch der Kabinettdatei um eins erhht wird. Die
Sequenznummer entspricht hierbei der Reihenfolge der Elemente in der Kabinettdatei. In
der Kabinettdatei sind zuerst die vollstndigen Dateien und dann die Binr-Patches
angeordnet.
Tabelle 10.90: Modifizieren der Tabelle File
444
Kapitel 10
In der Tabelle Patch sind alle Dateien enthalten, die durch Binr-Patches aktualisiert werden. Dieser
Tabelle wird fr jeden Binr-Patch, der der Kabinettdatei hinzugefgt wird, ein Datensatz mit
entsprechenden Informationen angefgt
Feld der Tabelle
Verwendete Daten
Patch.File_
Schlssel fr den Binr-Patch, der identisch ist mit dem Schlssel der Datei die
aktualisiert werden soll.
Patch.Sequence
Die Sequenznummer, die mit dem Wert aus ImageFamilies.FileSequenceStart beginnt

und fr jede Datei oder jeden Binr-Patch der Kabinettdatei um eins erhht wird. Die
Sequenznummer entspricht hierbei der Reihenfolge der Elemente in der Kabinettdatei. In
der Kabinettdatei sind zuerst die vollstndigen Dateien und dann die Binr-Patches
angeordnet.
Patch.PatchSize
Gre des Binr-Patches in Byte.
Patch.Attributes
Ein Wert von 1 (msidbPatchAttributesNonVital) in diesem Feld bedeutet, dass ein

referenzierter Datensatz in der Tabelle UpgradedFiles_OptionalData der PCP-Datei
existiert und dass in diesem Datensatz der Wert der Spalte AllowIgnoreOnPatchError auf
1 gesetzt wurde.
Patch.Header
Enthlt einen Hash (24 Byte) des Binr-Patches. Dieser Hash wird bentigt um zu prfen,
ob die entsprechende Datei bereits gepatcht worden ist. In diesem Fall wird der BinrPatch nicht extrahiert.
Tabelle 10.91: Modifizieren der Tabelle Patch
Die Tabellen InstallExecuteSequence und AdminExecuteSequence stellen die Ausfhrungssequenz der

jeweiligen Installationsart dar. Sie enthalten alle Aktionen, die ausgefhrt werden sollen, wenn die
entsprechende Top-Level-Aktion aufgerufen wird. Beiden Tabellen wird der folgende Datensatz
angefgt.
Feld der Tabelle InstallExecuteSequence und
AdminExecuteSequence
Verwendete Daten
Action
PatchFiles
Sequence
Die Sequenznummer der Aktion InstallFiles +1.
Tabelle 10.92: Modifizieren der Tabellen InstallExecuteSequence und AdminExecuteSequence
Das Ergebnis gesamten Phase 3 ist somit die Patch-Transformation, die DDF-Datei und die
modifizierten Dateien, wobei letztere entweder in vollstndiger Form oder als binres Delta vorliegen.
Der Umfang der diesbezglichen Eintragungen im Generierungsprotokoll ist natrlich von der
Komplexitt des Patches abhngig. Sie bieten jedoch den nachfolgend dargestellten
Informationsgehalt.
INFO: Phase III: Entering Prepare Files.
INFO Comparing Files: C:\Users\AK\AppData\Local\Temp\WIX\1.0\Colors\Colors.exe
C:\Users\AK\AppData\Local\Temp\WIX\1.1\Colors\Colors.exe...
INFO File Key: F__Colors.exe is modified
PERF INFO: File Info Lookup Time: 1 ms
INFO Comparing Files: C:\Users\AK\AppData\Local\Temp\WIX\1.0\Colors\InfoLib.dll
C:\Users\AK\AppData\Local\Temp\WIX\1.1\Colors\InfoLib.dll...
INFO File Key: F__InfoLib.dll is modified
PERF INFO: File Info Lookup Time: 1 ms
445
Kapitel 10
PERF INFO: C:\Users\AK\AppData\Local\Temp\WIX\1.0\product.msi 15 ms

PERF INFO: C:\Users\AK\AppData\Local\Temp\WIX\1.1\product.msi 18 ms
PERF INFO: Time spent generating the patch transform: 158 ms
Phase 4: Kabinettdatei erzeugen

Die folgende Phase 4 ist wiederum sehr einfach gehalten, den hier wird lediglich die Kabinettdatei
erstellt und ins Ausgabeverzeichnis kopiert. Zur Erstellung wird die Anwendung makecab.exe
verwendet, die letztlich die Informationen aus der erzeugten DDF-Datei benutzt. Im Protokoll ist diese
Phase durch die folgenden Zeilen gekennzeichnet.
INFO: Phase IV: Entering Generate Payload.
PERF INFO: Time spent generating the payload:
67 ms
Die schematische Darstellung dieser Phase zeigt Abbildung 10.94.
Abbildung 10.93: Erstellen der Kabinettdatei
Phase 5: Einzelteile kombinieren und Patch erzeugen

Nach dem die Phase 4 abgeschlossen wurde, sind somit allen erforderlichen Dateien vorhanden, so
dass hieraus in Phase 5 der Patch erstellt werden kann. Zunchst werden die DatenbankTransformation, die Patch-Transformation und die Kabinettdatei in die leere MSP-Datei integriert.
Anschlieend wird die Eigenschaft SEQUENCE_DATA_GENERATION_DISABLED ausgewertet, die
in der Tabelle Properties der PCP-Datei festgelegt werden kann. Wurde diese Eigenschaft gar nicht
oder auf den Wert 0 gesetzt, werden die Sequenzinformationen automatisch erzeugt. Hierdurch wird
somit die logische Anwendungsreihenfolge des Patches definiert, die auf Basis des folgenden
Algorithmus ermittelt wird.
Fr jedes Zielprodukt der Tabelle TargetImages, das durch einen unterschiedlichen Produktcode
reprsentiert wird, wird der Tabelle MsiPatchSequence ein neuer Datensatz hinzugefgt.
Hierbei wird der Inhalt der Spalte PatchFamily aus dem Produktcode der Zielprodukte konstruiert.
Da der Produktcode ungltige Sonderzeichen enthlt, werden diese entfernt, so dass beispielsweise
fr den Produktcode {E4FCADB1-545F-4F38-97BE-1C4246189209} der Bezeichner
446
Kapitel 10
E4FCADB1545F4F3897BE1C4246189209 erzeugt wird.

Die Daten der Spalte Sequence werden aus den Produktversionen und einem Zeitstempel im
Format <Minor-Produktversion>.<Major-Buildversion>.<Time Stamp 1>.<Time Stamp 2>
erstellt. Das erste Feld enthlt hierbei die Minor-Produktversion und das zweite Feld die MajorBuildversion des in der Tabelle TargetImages der PCP-Datei definierten Zielproduktes mit der
hchsten Versionsnummer. Sind in der Tabelle TargetImages beispielsweise drei Zielprodukte
angegeben, die ber die Produktversionen 1.1.100, 1.1.200 und 1.2.300 verfgen, wird zur weiteren
Berechnung das Produkt mit der hchsten Versionsnummer, also 1.2.300 verwendet. Somit wird
fr das erste Feld der Sequenznummer die 2 und fr das zweite Feld die 300 verwendet. Die
restlichen beiden Felder enthalten jeweils einen Zeitstempel, der auf Grundlage des
Erstellungsdatums des Patches erzeugt wird.
Der Spalte Attribute wird automatisch der Wert msidbPatchSequenceSupersedeEarlier zugewiesen,
falls sich die Produktversionen des Ziel- und des Aktualisierungsproduktes unterscheiden und es
sich somit um ein Minor-Upgrade handelt. Handelt es sich hingegen um ein Small-Update wird der
Spalte Attributes der Wert 0 zugewiesen. Dieses Verhalten begrndet sich auf der Annahme,
dass ein Minor-Upgrade alle vorherigen Fixes (Kumulativ) enthlt, und diese somit in einen
pseudoinstallierten Zustand versetzt werden knnen. Darber hinaus besteht die Mglichkeit diese
Logik zu deaktivieren, indem der Tabelle Properties der PCP-Datei die Eigenschaft
SEQUENCE_DATA_SUPERSEDENCE hinzugefgt wird. Diese Eigenschaft kann auf die Werte
0 und 1 gesetzt werden, wobei durch den Wert 1 alle Eintragungen der Spalte Sequence in
der Tabelle MsiPatchSequence mit dem Attribut msidbPatchSequenceSupersedeEarlier
gekennzeichnet werden.
Wurde hingegen die automatische Generierung der Sequenzinformationen deaktiviert, werden die
Informationen aus der Tabelle PatchSequence der PCP-Datei in die Tabelle MsiPatchSequence des
Patches bertragen. Es ist jedoch zu beachten, dass eine PCP-Datei, in der die Eigenschaft
MinimumRequiredMsiVersion auf den Wert 300 oder hher gesetzt wurde, ber die Tabelle
PatchSequence verfgen muss oder die automatische Generierung der Sequenzinformationen
veranlasst wird. Findet diese Vorgabe keine Beachtung, werden die erforderlichen Informationen von
patchwiz.dll automatisch erstellt und im Protokoll entsprechend vermerkt.
WARNING: SEQUENCE_DATA_GENERATION_DISABLED property is set to 1 and PatchSequence table is not provided.
An MSI 3.0 patch can not exist with out sequencing information. Sequencing information will be generated
automatically for this patch.
Nachdem die Sequenzinformationen erzeugt wurden, mssen noch die Metainformationen angefgt
werden. Hierbei werden die Informationen der Tabelle PatchMetadata der PCP-Datei in die Tabelle
MsiPatchMetadata bertragen, wie dieses auch in Abbildung 10.94 zustzlich verdeutlicht wird. Die
Ablufe hierzu sind ebenfalls im Protokoll zu finden.
INFO: Phase V: Entering Generate MSP.
INFO:
Generating Patch Metadata.
PERF INFO: Time spent stuffing everything into the MSP: 7 ms
INFO: Patch created successfully.
Wie auch im Protokoll dargestellt wird, ist die Erstellung des Patches nun abgeschlossen. Zuvor wurde
jedoch noch der Summary Information Stream des Patches erzeugt, so dass einer Verwendung des
447
Kapitel 10
Patches nun nichts mehr im Wege steht.
Abbildung 10.94: Schematischer Ablauf der finalen Phase
Die gerade dargestellten Aktionen und Ablufe beziehen sich auf einen normalen Patch, also ein Patch
der letztlich auf Grundlage eines Basis- und eines Aktualisierungspaketes erzeugt wurde. Der
Workflow wird natrlich auch bei Multi-Target-Patches und Multi-SKU-Patches beibehalten,
allerdings werden hierbei einige Aktionen mehrfach ausgefhrt, so dass der Gesamtprozess
komplexere Zge annimmt.
Programmtechnischer Zugriff auf die Metainformationen

Unabhngig davon auf welche Weise der Patch erstellt wurde, besteht mitunter die Anforderung, die
Inhalte des Patches zu betrachten. Eine Mglichkeit hierzu bieten natrlich Tools wie Orca, die den
Patch in der verbundenen Ansicht darstellen. Geht es jedoch um die Darstellung der
Metainformationen oder interner Elemente, knnen solche Tools nicht verwendet werden. An dieser
Stelle hilft vielfach nur ein programmtechnischer Lsungsansatz weiter, da die erforderlichen
Informationen hufig sehr individuell aufzubereiten sind. Die Deployment Tools Foundation stellt im
Namensraum Microsoft.Deployment.WindowsInstaller.Package die Klassen PatchPackage und
TransformInfo zur Verfgung, mit denen solche Informationen problemlos abgerufen werden knnen.
Der Funktionsumfang und die Beziehungen dieser Klassen sind in Abbildung 10.95 dargestellt.
448
Kapitel 10
Abbildung 10.95: Diagramm der Klassen PatchPackage, TransformInfo und Database
Das relevante Objekt zur Ermittlung der Informationen eines Patches ist die Klasse PatchPackage, die
wiederum von der Klasse Database abgeleitet ist. Die Klasse Database verfgt ber einige interessante
Eigenschaften wie SummaryInfo, mit der die Inhalte des Summary Information Streams ausgelesen
werden knnen. Interessant ist hier beispielsweise die Eigenschaft Template, denn diese enthlt die
Produktcode der Produkte, auf die dieser Patch angewendet werden kann. Zurckblickend handelt es
sich hierbei um den ersten Prfpunkt, bei der Anwendung eines Patches. Diese Produkte knnen
jedoch auch durch die Funktion PatchPackage.GetTargetProductCodes() abgerufen werden. Der
zweite diesbezgliche Prfpunkt bezieht sich auf die Ermittlung der geeigneten Transformationen. Zur
Ermittlung dieser Transformation enthlt die Klasse PatchPackage einige Funktionen wie
GetTransforms() oder GetTransformsInfo(). Wie bereits erlutert, enthlt ein Patch immer mehrere
Transformationen, so dass diese Funktionen immer eine Ergebnisliste zurckliefern. Zur Ermittlung
eines geeigneten Transformationspaares kann die Funktion GetValidTransforms() verwendet werden,
die allerdings eine Referenz auf das entsprechende Produkt bentigt. Die Vorgehensweise zum Abruf
der Informationen ist denkbar einfach und wird im Listing 10.92 dargestellt.
private void ViewPatch(string fileName)
449
Kapitel 10
{
using (PatchPackage patchPackage = new PatchPackage(fileName))
{
TransformInfo[] transformInfos = patchPackage.GetTransformsInfo(true);
}
}
Listing 10.92: Zugriff auf die Eigenschaften eines Patches
Die hieraus resultierenden Ergebnisse werden sehr deutlich, wenn ein Haltepunkt gesetzt wird, so dass
die Objekte und Eigenschaften im berwachungsfenster angezeigt werden, wie dieses in Abbildung
10.96 der Fall ist.
Abbildung 10.96: Darstellung einiger Objekte im berwachungsfenster
Zustzlich zu den gerade gezeigten Eigenschaften, kann auch direkt auf die Patch-Datenbank
zugegriffen werden, so dass ebenfalls die Metadaten und Inhalte der Tabellen MsiPatchSequence und
MsiPatchMetadata ermittelt werden knnen. Die erforderliche Vorgehensweise ist identisch mit dem
Zugriff auf die Datenbank eines Installationspaketes, wie es bereits in Kapitel 4 erlutert wurde.
Optimierungen
Mit dem Windows Installer 4.5 wird das schon hervorragende Servicemodell des Windows Installer
weiter optimiert. Konkret wurden hierbei drei Anwendungsflle aufgegriffen, die in lteren Windows
Installer-Versionen keine optimale Lsung geboten haben. Diese Anwendungsflle beziehen sich
vornehmlich auf die Deinstallation von Patches, aber auch im Rahmen der pseudoinstallierten Patches
gibt es eine Verbesserung.
450
Kapitel 10
Eine der grundstzlichen Anforderungen in einem Servicemodell ist die Steuerung der
Gltigkeitsdauer von Patches, also die Festlegung, wann ein Patch fr die Ausfhrung des Produktes
nicht mehr bentigt wird. Diese Anforderungen kommen hufig zum Tragen, wenn ein Patch auf ein
installiertes Produkt angewendet werden soll, der die Aktualisierungen vorheriger Patches bereits
enthlt (Kumulativ) oder der neue Funktionalitten hinzufgt, die ltere, bereits aktualisierte
Funktionalitten auer Kraft setzen. Die Steuerung der Gltigkeitsdauer von Patches bedeutet nicht,
dass der entsprechende Patch physisch vom System entfernt wird, vielmehr wird hierdurch ein Patch
aus der Anwendungsreihenfolge ausgeschlossen, so dass er in einem Pseudoinstallierten Zustand auf
dem System verbleibt. Das bedeutet, dass er zur Konstruktion der verbundenen Ansicht nicht mehr
bercksichtigt wird, wie dieses auch bereits zuvor schon erlutert wurde.
Bei der Installation eines Patches, erstellt der Windows Installer ein im Arbeitsspeicher befindliches
Abbild des Produktes, auf das der Patch angewendet werden soll. Auf dieses Abbild werden dann alle
gltigen Patches in der definierten Reihenfolge angewendet. Der Windows Installer aktualisiert
daraufhin die installierten Ressourcen auf Grundlage der Informationen des im Speicher befindlichen
Abbildes des Produktes. Patches, deren Gltigkeitsdauer verstrichen ist, werden auf das im Speicher
befindliche Abbild nicht mehr angewendet, so dass die enthaltenen Informationen bei der physischen
Aktualisierung der Ressourcen nicht mehr bercksichtigt werden. Diese Vorgehensweise des Windows
Installers lsst sich auch in einem Installationsprotokoll nachvollziehen.
MSI (s) (1C:08) [10:20:29:239]: PatchGUID: {CDE584C5-07C7-425B-B3BA-5CF4642F3C45} PatchFamily: RM
Sequence: 1.0.0.100 SequenceOrder: 0 Type: QFE
MSI (s) (1C:08) [10:20:29:239]: PatchGUID: {8E11C8A0-14A6-41C0-87D3-FA3C474F9FA6} PatchFamily: RM
Sequence: 1.0.0.200 SequenceOrder: 1 Type: QFE
MSI (s) (1C:08) [10:20:29:239]: PatchGUID: {07C6F87F-F3CC-47F7-B00B-D1F92BC0F97C} PatchFamily: RM
Sequence: 1.5.0.300 SequenceOrder: 2 Type: minor upgrade
MSI (s) (1C:08) [10:20:29:239]: PATCH SEQUENCER: minor upgrade patch {07C6F87F-F3CC-47F7-B00B-D1F92BC0F97C}
cannot be superseded because there is no supersedence defined in RM family yet for this type
MSI (s) (1C:08) [10:20:29:239]: PATCH SEQUENCER: minor upgrade patch {07C6F87F-F3CC-47F7-B00B-D1F92BC0F97C}
will attempt to supersede in RM family, starting from sequence 1.5.0.300
MSI (s) (1C:08) [10:20:29:239]: PATCH SEQUENCER: QFE patch {8E11C8A0-14A6-41C0-87D3-FA3C474F9FA6}
is superseded
MSI (s) (1C:08) [10:20:29:239]: PATCH SEQUENCER: QFE patch {CDE584C5-07C7-425B-B3BA-5CF4642F3C45}
is superseded
MSI (s) (1C:08) [10:20:29:239]: SequencePatches returns success.
Die berfhrung eines Patches in einen pseudoinstallierten Zustand kann mit dem Windows InstallerVersionen 3.0 und hher durch zwei unterschiedliche Verfahren erfolgen, die als Obsolescence
(Veralten) und Supersedence (Ablsung) bezeichnet werden. Das als Supersedence bezeichnete
Verfahren basiert auf den Sequenzinformationen eines Patches und steht daher erst seit der Version 3.0
des Windows Installers zur Verfgung. In den Sequenzinformationen kann fr jeden Patch festgelegt
werden, ob ltere Patches der gleichen Patch-Familie abgelst werden sollen, also auf das im Speicher
befindliche Abbild nicht mehr angewendet werden. Hierzu muss die Spalte Attributes der Tabelle
MsiPatchSequence ber den Wert 1 verfgen. Als Obsolescence wird eine Mglichkeit bezeichnet,
die auf das gleiche Ergebnis abzielt, aber nur mit Patches der Windows Installer-Version 2.0 mglich
ist. Ein Patch, der ber Sequenzinformationen verfgt, also ein Patch 3.0, kann ausschlielich das
Verfahren Supersedence verwenden, um die Gltigkeitsdauer von Patches zu beeinflussen.
451
Kapitel 10
Auswirkungen auf das System

Wird ein Patch abgelst, werden die enthaltenen Informationen nicht mehr auf das Produkt
angewendet. Dieses bedeutet, dass weder die Transformationen noch die enthaltenen Ressourcen im
Aktualisierungsprozess bercksichtigt werden. Der Patch bleibt nach wie vor auf dem System
registriert, allerdings wird der Status Applied in den Status Superseded gendert, wodurch der
pseudoinstallierte Zustand gekennzeichnet wird. Wird nun der Patch, der die Ablsung veranlasst hat,
wieder deinstalliert, wird der pseudoinstallierte Patch wieder in den Status Applied versetzt und die
Transformationen und Ressourcen werden wieder auf das Produkt angewendet. Ein Patch 2.0, der
unter Verwendung des Windows Installer 3.0 und hher als Obsoleted gekennzeichnet wurde, verhlt
sich entsprechend. Wird hingegen ein Patch unter Verwendung des Windows Installers 2.0 als
Obsoleted gekennzeichnet, ergibt sich ein anderes Resultat. Hierbei wird die Registrierung des Patches
vollstndig aufgehoben und die zwischengespeicherte MSP-Datei wird aus dem Verzeichnis
%windir%\installer gelscht. Es gilt natrlich zu beachten, dass mit dem Windows Installer 2.0 keine
Patches deinstalliert werden knnen, wodurch diese genderte Implementierung geringe Auswirkungen
offenbart.
Zusammenfassend lsst sich erkennen, dass Supersedence und Obsolescence verwendet werden, um
einen oder mehrere Patches in einen pseudoinstallierten Zustand zu versetzen. Obwohl das Ziel beider
Mglichkeiten identisch ist, unterscheiden sie sich in der Art und Weise, wie dieses Ziel erreicht wird.
Verhalten
Obsolescence
Supersedence
Art des Patches
Patch 2.0 (Verfgt ber keine

Sequenzinformationen)
Patch 3.0 (Enthlt

Sequenzinformationen)
Zielbestimmung
Definiert durch die Eigenschaft

PatchCode.
Resultat aus der Patch-Familie und

der Sequenz.
Umfang
Alle Patches
Nur die Patches einer Familie.
Bedingung
Nein
Ja, durch die Eigenschaft

ProductCode
Verketten (Chaining)
Ja, falls die Patches in richtiger

chronologischer Reihenfolge
angewendet werden.
Ja
Patches entfernen
Ja, aber nur beim Windows Installer

2.0.
Nein, auer die Patches werden

nicht mehr bentigt
Rcknahme der nderungen
Nein
Ja
Tabelle 10.93: Unterschiede zwischen Obsolescence und Supersedence
Bei der Verwendung des Windows Installers 2.0 kann ein Patch nur in einen pseudoinstallierten
Zustand versetzt werden, indem dieser als Obsoleted gekennzeichnet wird. Hierzu ist es erforderlich
den PatchCode des veralteten Patches der Eigenschaft Obsolete des Summary Information Stream des
aktuellen Patches hinzuzufgen. Bei der Installation des aktuellen Patches, wird der veraltete Patch
vollstndig vom Produkt entfernt. Dies bedeutet, dass sowohl die Registrierungsinformationen, als
auch das zwischengespeicherte Patchpaket entfernt werden; allerdings sind die modifizierten
Ressourcen hiervon ausgenommen. Da smtliche Konfigurationsdaten hierbei entfernt werden, lsst
sich zu einem spteren Zeitpunkt nicht mehr feststellen, dass dieser Patch jemals installiert war. Dieses
ist insofern ein Problem, da im Rahmen einer Inventarisierung des Systems, dieses durchaus erwnscht
452
Kapitel 10
wre. Weiterhin kann ein solcher Patch zu einem spteren Zeitpunkt wieder problemlos auf das
Produkt angewendet werden, wodurch nderungen des aktuellen Patches eventuell berschrieben
werden.
Wird hingegen ein Patch unter Verwendung des Windows Installer 3.0 und hher in den Status
Obsoleted oder Superseded versetzt, bedeutet dies, dass der Patch bei Installationsttigkeiten nicht
mehr auf das im Speicher befindliche Abbild des Produktes angewendet wird. Allerdings bleiben die
Status- und Metainformationen des Patches erhalten, so dass im Rahmen einer Inventarisierung
jederzeit exakte Informationen zur Verfgung stehen. Diese nderungen gegenber dem Windows
Installer 2.0 resultieren in den folgenden vernderten Verhaltensmustern:
Pseudoinstallierte Patches bleiben dem System erhalten: Patches, die in den Zustand Obsoleted
oder Superseded versetzt werden, bleiben in den Konfigurationsdaten des Produktes erhalten.
Hierdurch ist es mglich, dass Patches, die nicht mehr zu den aktiven Patches eines Produktes
gehren, trotzdem ber die Inventarisierungsfunktionen des Windows Installers abgerufen werden
knnen. Die Inventarisierungsdaten enthalten hierbei einen Hinweis auf den aktuellen
Installationsstatus des Patches.
Patches werden reaktiviert, wenn sich die Bedingung ndert: Befindet sich ein Patch im Status
Obsoleted oder Superseded und wird die hierfr zustndige Bedingung gendert, wird der Patch
wieder aktiviert und auf das Produkt angewendet. Die Reaktivierung wird in der gleichen
Transaktion ausgefhrt, in der auch die Bedingung verndert wird. Durch die Installation des
Patches SP1 wird beispielsweise der Patch QFE1 in den Status Superseded versetzt. Wird nun der
Patch SP1 deinstalliert, wird der Patch QFE1 in der gleichen Transaktion wieder auf das Produkt
angewendet. Die Ressourcen befinden sich anschlieend in der Version auf dem System, wie sie im
Patch QFE1 definiert wurden.
Eine erneute Installation des Patches versetzt das Produkt in keinen ungltigen Status: Befindet
sich ein Patch im Status Obsoleted oder Superseded und wird dieser Patch erneut auf das Produkt
angewendet, behalten die Ressourcen und der Patch den aktuellen Status bei. Durch die Installation
des Patches SP1 wird beispielsweise der Patch QFE1 in den Status Superseded gesetzt. Wird im
Anschluss der Patch QFE1 erneut auf das Produkt angewendet, behalten die Ressourcen den
aktuellen Status bei, das bedeutet, dass sie nicht verndert werden.
Gerade bei Produkten, die ber einen sehr langen Zeitraum verwendet und gepflegt werden, nimmt die
Anzahl der aktuellen und natrlich auch der pseudoinstallierten Patches stndig zu. Die Forderung
nicht mehr bentigte Patches in einem pseudoinstallierten Zustand auf dem System zu belassen, anstatt
sie zu deinstallieren, bleibt unbestritten.
Inventarisierung
Im Kapitel 4 wurden bereits Lsungsanstze aufgezeigt, mit denen die bereits installierten Produkte
eines Systems ermittelt werden konnten. Zustzlich zu den Produkten knnen natrlich auch die
Patches ermittelt werden, die sich auf dem System befinden. Hierbei knnen ebenfalls der Status des
Patches, der Installationszeitpunkt und weiteren Daten abgerufen werden, wodurch der Updateverlauf
sehr gut dargestellt werden kann. Wie bereits bei den Produkten stellt auch hierzu die Deployment
Tools Foundation die notwendigen Werkzeuge zur Verfgung. Das wesentliche Objekt hierzu ist die
Klasse PatchInstallation die sich im Namensraum Microsoft.Deployment.WindowsInstaller befindet
und deren Struktur in Abbildung 10.97 dargestellt ist.
453
Kapitel 10
Abbildung 10.97: Struktur der Klasse PatchInstallation
Die Klasse PatchInstallation ist wiederum sehr einfach zu verwenden. Um alle registrierten Patches
abzurufen, kann die Eigenschaft PatchInstallation.AllPatches verwendet werden. Um die
Ergebnismenge im Vorfeld einzuschrnken sollte die die Funktion PatchInstallation.GetPatches()
verwendet werden. Beim Aufruf der Funktion knnen diverse Filterbedingungen, wie das zugeordnete
Produkt, der Installationskontext, der Benutzer oder der Status des Patches vorgegeben werden. Das
Ergebnis ist wie bei der zuvor genannten Mglichkeit eine Liste aller Patches, die diesen Kriterien
entsprechen. Die Liste kann einfach durchlaufen und die Eigenschaften knnen abgerufen werden, wie
dieses in Listing 10.93 dargestellt wird.
private void ViewPatches()
{
// Patches fr ein speziellen Produkt abrufen
IEnumerable<PatchInstallation> patches = PatchInstallation.GetPatches(
null,
"{AE581993-EA96-4632-A0F8-2D3B7DBB86E8}",
null,
UserContexts.UserUnmanaged,
true);
// Informationen aller Patches ausgeben
foreach (PatchInstallation patch in patches)
{
Console.WriteLine("DisplayName: " + patch.DisplayName);
Console.WriteLine("IsSuperseded: " + patch.IsSuperseded.ToString());
Console.WriteLine("IsObsoleted: " + patch.IsObsoleted.ToString());
Console.WriteLine("InstallDate: " + patch.InstallDate.ToShortDateString());
Console.WriteLine("Uninstallable: " + patch.Uninstallable.ToString());
Console.WriteLine("LocalPackage: " + patch.LocalPackage);
}
}
Listing 10.93: Inventarisierung von installierten Patches
454
Kapitel 10
Die Klasse PatchInstallation kann ebenfalls verwendet werden um die registrierten Installationsquellen
des Patches abzurufen oder zu modifizieren. Weiterhin knnen Eigenschaften des Patches wie
PatchCode oder ProductCode verwendet werden, um weitere Funktionen der Deployment Tools
Foundation aufzurufen. Die Mglichkeiten sind somit sehr gro und der Phantasie sind nahezu keine
Grenzen gesetzt.
Problemfall Verwaiste Komponenten

Wie in diesem Abschnitt bereits erlutert, knnen durch das Installieren neuerer Patches, vorherige
Patches in einen pseudoinstallierten Zustand versetzt werden. Dieses als Supersedence bezeichnete
Verfahren ist erforderlich, damit bei einer Deinstallation der neueren Patches die vorherigen Patches
wieder reaktiviert werden knnen. Pseudoinstallierte Patches bleiben zwar fr das Produkt registriert,
werden jedoch nicht mehr zur Konstruktion der verbundenen Ansicht verwendet, wodurch die
enthaltenen Komponenten auch nicht mehr verwaltet werden.
Zum besseren Verstndnis soll hier ein Beispiel dienen. Der Patch QFE1 enthlt im Gegensatz zum
ursprnglichen Installationspaket RTM einige neue Komponenten. Der Patch QFE1 wird nun auf das
Produkt angewendet, wodurch diese neuen Komponenten dem System hinzugefgt werden. Im
Folgenden wird der Service Pack SP1 erstellt. Gem Definition muss dieser immer von der letzten
oder von der nativen Baseline erstellt werden. Die native Baseline kennzeichnet immer das Produkt in
seiner ursprnglichsten Form, in diesem Beispiel also RTM. Diese Produktversion enthlt aber die mit
QFE1 zugefgten neuen Komponenten nicht, so dass diese auch nicht im SP1 enthalten sind. Nach der
Installation von SP1 wird QFE1 nun in den pseudoinstallierten Zustand versetzt. Hieraus ergibt sich
nun die Problematik der verwaisten Komponenten. Die neu hinzugefgten Komponenten sind nur
QFE1 bekannt und knnen somit auch nur durch diesen Patch verwaltet werden. Dieser Patch ist
jedoch in einem pseudoinstallierten Zustand und wird nicht mehr zur Konstruktion der verbundenen
Ansicht verwendet. Somit werden die neu hinzugefgten Komponenten nicht mehr verwaltet. Das
bedeutet auch, dass die Komponenten bei der Deinstallation des Produktes auf dem System verbleiben.
Dieses Beispiel stellt sicherlich nicht die Regel dar, denn in den meiten Fllen wird ein Service Pack
als kumulatives Update erstellt und angewendet. Hierbei wrde der Service Pack auch ber die neuen
Komponenten verfgen und wrde somit auch deren Verwaltung bernehmen. Ein gutes
Servicemodell untersttzt jedoch nicht nur die Regeln sondern bietet auch Lsungsanstze zur
Behandlung der Ausnahmen.
Mit dem Windows Installer 4.5 wurde diese Thematik aufgegriffen und ein effektiver Lsungsansatz
zur Vermeidung dieses Problems integriert. Hierzu mssen die neu hinzugefgten Komponenten mit
dem Attribut msidbComponentAttributesUninstallOnSupersedence versehen werden. So
gekennzeichnete Komponenten werden automatisch vom System entfernt, wenn der Patch, der diese
Komponente hinzufgt, in einen pseudoinstallierten Zustand versetzt wird. Entsprechende
Informationen finden sich natrlich auch im Installationsprotokoll.
MSI (s) (F8:C4) [13:29:06:755]: Patch Supersedence: Component 'C__New.txt' with
ID '{57B2DC5A-BFC6-4C8C-B573-8E04B3608D68}' is added by a superseded patch and marked for uninstall.
MSI (s) (F8:C4) [13:29:06:756]: Patch Supersedence: File 'F__Readme.txt' is scheduled for removal
due to superseded component 'C__New.txt'.
MSI (s) (F8:C4) [13:29:06:756]: Patch Supersedence: Feature 'Application' is scheduled for reinstall
due to superseded component 'C__New.txt'.
MSI (s) (F8:C4) [13:29:07:020]: Executing op: ComponentUnregister(ComponentId=

{57B2DC5A-BFC6-4C8C-B573-8E04B3608D68},ProductKey={F653B398-F77E-4E74-AE15-5824235001A9},BinaryType=0,)
MSI (s) (88:34) [13:52:10:817]: Executing op: FileRemove(,FileName=C:\Program Files (x86)\MSI\ReadMe.txt,,
455
Kapitel 10
ComponentId={57B2DC5A-BFC6-4C8C-B573-8E04B3608D68})
Wie bereits angedeutet, sind die neu hinzugefgten Komponenten mit dem Attribut
msidbComponentAttributesUninstallOnSupersedence zu kennzeichnen. Das bedeutet, dass in der
Tabelle Components des Aktualisierungspaketes auf den Wert der Spalte Attributes der Wert 1024
addiert werden muss. Bei der Verwendung von Windows Installer-XML ist dem Element Component
das Attribut UninstallWhenSuperseded anzufgen, wie dieses auch auszugsweise in Listing 10.94
zeigt.

<Component Id="C__New.txt" Guid="{57B2DC5A-BFC6-4c8c-B573-8E04B3608D68}" UninstallWhenSuperseded="yes">
<File Id="F__Readme.txt" Source=".\Binaries\ReadMe.txt" Name="ReadMe.txt" KeyPath="yes" DiskId="1" />
</Component>
Listing 10.94: Kennzeichnung einer Komponente die in bestimmten Situationen automatisch entfernt wird
Der skizzierte Lsungsansatz ist einfach umsetzbar, offenbart jedoch eine groe Schwachstelle, da er
nur fr knftige Patches verwendet werden kann. Es ist jedoch zu vermuten, dass eine Vielzahl von
Patches bereits existiert, bei denen die neuen Komponenten noch nicht gekennzeichnet sind und somit
wieder zu dem problematischen Verhalten fhren werden. Auch fr diese Flle stellt der Windows
Installer 4.5 in Form der Eigenschaft MSIUNINSTALLSUPERSEDEDCOMPONENTS einen
Lsungsansatz zur Verfgung. Bei der Installation des Patches, der die vorherigen Patches in den
pseudoinstallierten Zustand versetzt, muss diese Eigenschaft auf den Wert 1 gesetzt werden. Hierbei
ist es unerheblich, ob die Eigenschaft ber die Befehlszeile gesetzt wird oder ob Sie bereits in der
Tabelle Property des Aktualisierungspaketes definiert wurde. Wichtig ist nur, dass durch diese
Kennzeichnung, die Komponenten der Patches entfernt werden, die in den Status Superseded gesetzt
wurden.
Bleibt
an
dieser
Stelle
nur
noch
anzumerken,
dass
das
Attribut
msidbComponentAttributesUninstallOnSupersedence
und
die
Eigenschaft
MSIUNINSTALLSUPERSEDEDCOMPONENTS erst seit der Version 4.5 des Windows Installers zur
Verfgung stehen und dass frhere Versionen des Windows Installer diese Daten ignorieren.
Deinstallation von Patches

Zur Vervollstndigung des Servicemodells fr Windows Installer-Patches wurde eine native
Deinstallationsmglichkeit in den Windows Installer 3.0 und hher integriert. Die Deinstallation eines
Patches erfordert die Zurcksetzung von Dateien in einen frheren Versionsstand, sowie die
Zurcknahme aller weiteren nderungen durch diesen Patch. Fr den Windows Installer bedeutet es
weiterhin, dass die Registrierung des Patches von den Konfigurationsdaten des Produktes entfernt
werden muss. Darber hinaus muss das im Cache befindliche Patchpaket gelscht werden, falls es sich
um das letzte Produkt handelt, von dem der Patch entfernt wurde.
Interne Ablufe
Zur Deinstallation von Patches verwendet der Windows Installer den Reinstallations-Modus des
Produktes, der fr diesen Zweck speziell angepasst wurde. Durch diese Anpassung werden nur die
Dateien durch eine ltere Dateiversion ersetzt, die tatschlich von dem Patch gendert wurden. Die
Eigenschaft REINSTALLMODE verwendet hierbei generell die Option a, so dass unabhngig vom
Ergebnis der Versionierungsregel, die Dateien berschrieben werden knnen. Hieraus lsst sich
ableiten, dass die Eigenschaft REINSTALLMODE nicht global fr das gesamte Produkt gilt, sondern
sich ausschlielich auf die durch den Patch modifizierten Dateien auswirkt. Durch diese
456
Kapitel 10
Vorgehensweise wird eine performante Ausfhrung bei der Deinstallation des Patches gewhrleistet.
Weiterhin wird der Zugriff auf die Installationsquellen vermieden, da nur Ressourcen bentigt werden,
die bereits auf dem System vorhanden sind oder durch die Informationen des zwischengespeicherten
Installationspaketes und des Patch-Paketes hergestellt werden knnen. Der vollstndige
Deinstallationsprozess von Patches lsst sich somit in mehrere Abschnitte unterteilen, die nachfolgend
aufgefhrt werden:
55. Festlegung der Anwendungsreihenfolge der Patches: Es werden alle bereits angewendeten
Patches bei der Festlegung bercksichtigt. Der zu deinstallierende Patch wird jedoch aus dieser
Auflistung entfernt. Die erneute Festlegung ist erforderlich, um den Status der pseudoinstallierten
Patches erneut auszuwerten und diese bei Bedarf wieder zu reaktivieren.
56. Erstellen einer Dateiliste: Es wird eine Liste der genderten Dateien unter Verwendung der im
Patch enthaltenen Transformationen erstellt.
57. Generierung einer Liste von Features: Zur Anwendungsoptimierung werden die Features
ermittelt, die von den nderungen des Patches tatschlich betroffen sind. Zustzlich werden die
Elemente ermittelt, die durch die Anwendung des Patches, dem Produkt hinzugefgt wurden, wie
beispielsweise neue Eintragungen in der Systemregistrierung. Zum einen werden die hiervon
betroffenen Features der Auflistung hinzugefgt und zum anderen werden zum Entfernen dieser
Elemente die erforderlichen Operationsanweisungen erstellt.
58. Setzen der Eigenschaften: Es werden die Eigenschaften REINSTALL und REINSTALLMODE auf
die ermittelten Werte gesetzt. Die Eigenschaft REINSTALL wird entweder auf ALL oder auf die
optimierte Liste der Features gesetzt. Die Eigenschaft REINSTALLMODE wird auf amus gesetzt,
um Dateien unabhngig vom Ergebnis der Versionsprfung zu berschreiben. Zu beachten ist
hierbei, dass die Option a nicht global fr das Produkt gilt, sondern nur fr die Dateien der
generierten Dateiliste.
59. Entfernen der Patch-Informationen: Es werden Operationsanweisungen zum Entfernen der
Registrierungsinformationen des Patches und zum Lschen des zwischengespeicherten PatchPaketes erstellt.
Der entscheidende Punkt ist wiederum das Festlegen der Anwendungsreihenfolge der Patches, wobei
der zu entfernende Patch auer Acht gelassen wird. Bildlich dargestellt wird der zu deinstallierende
Patch aus der ursprnglichen verbundenen Ansicht entfernt um die neue Sicht auf das finale Produkt
zu erhalten, wie dieses auch Abbildung 10.98 zeigt. Dieser Punkt ist so entscheidend, da alle weiteren
Aktivitten, diese neue verbundene Darstellung nutzen und somit eventuelle Probleme weitreichende
Folgen htten.
Abbildung 10.98: Entfernen eines Patches von einem Installationspaket
Voraussetzungen und Vorgehensweise

Windows Installer 3.0 und hher enthlt die notwendigen Funktionalitten, um Patches deinstallieren
zu knnen. Diese Deinstallationsmglichkeit steht standardmig zur Verfgung, allerdings kann ein
457
Kapitel 10
Patch nicht in allen Fllen deinstalliert werden. Diese Einschrnkung ist von dem Inhalt und der Art
des Patches abhngig, sowie von Systemrichtlinien und den Rechten des jeweiligen Benutzers. Um
einen Patch deinstallieren zu knnen mssen die folgenden Vorgaben erfllt sein:
Die Deinstallation darf nicht durch die Systemrichtlinie DisablePatchUninstall verhindert werden.
Der Benutzer muss ber die erforderlichen Privilegien verfgen und die Deinstallation muss im
geeigneten Kontext erfolgen.
Der Patch muss fr die Deinstallation gekennzeichnet sein.
Gerade der letzte Punkt ist uerst interessant, da er nicht in allen Fllen direkt beeinflusst werden
kann. Bei der Installation eines Patches wird bereits festgelegt, ob ein Patch wieder deinstalliert
werden kann. Diese Informationen werden in den Konfigurationsdaten abgelegt, und knnen jederzeit
abgeprft werden. In Listing 10.93 wurde bereits dargestellt wie bestimmte Eigenschaften der
Konfigurationsdaten eines Patches abgerufen werden knnen. In dem Beispiel wird ebenfalls die
Eigenschaft Uninstallable ausgegeben, die ber die Deinstallierbarkeit eines Patches informiert. Diese
Kennzeichnung wird vom Windows Installer automatisch vergeben und orientiert sich an den
folgenden Faktoren.
Der Patch muss formal fr die Deinstallation gekennzeichnet werden. Hierzu muss die Eigenschaft
AllowRemoval der Tabelle MsiPatchMetadata den Wert 1 enthalten.
Es darf sich um keinen Major-Upgrade-Patch handeln.
Der Patch darf nur nderungen vornehmen, die auch zurckgenommen werden knnen. Das
bedeutet auch, dass nderungen an bestimmten Tabellen der Datenbank den Patch in einen nicht
deinstallierbaren Zustand versetzen.
Sind diese Voraussetzungen geschaffen, stehen mehrere Mglichkeiten zur Verfgung, einen Patch zu
deinstallieren. Diese Verfahren erstrecken sich auf Optionen der Befehlszeile, auf programmtechnische
Funktionsaufrufe oder auf Erweiterungen in der Benutzeroberflche des jeweiligen Betriebssystems.
Die letztgenannte dialoggesttzte Option zur Deinstallation von Patches ist wesentlich vom
verwendeten Betriebssystem abhngig. Bei der Verwendung von Windows XP und Windows Server
2003 werden diese Optionen im Dialog Software der Systemsteuerung angeboten. Bei Windows Vista
und Windows Server 2008 ist eine Deinstallation mit Hilfe des Dialogs Installierte Updates mglich
wie auch Abbildung 10.99 zeigt.
458
Kapitel 10
Abbildung 10.99: Dialoge des Betriebssystems zum Entfernen von Patches
Die Deinstallation von Patches kann auch durch Befehlszeilenoptionen realisiert werden. Hierzu stehen
zwei unterschiedliche Aufrufmglichkeiten zur Verfgung.
msiexec /i <Referenz auf das Produkt> MSIPATCHREMOVE=<Referenz auf
den Patch>[;<Referenz auf den Patch>]
msiexec /package <Referenz auf das Produkt> /uninstall <Referenz auf
den Patch>[;<Referenz auf den Patch>]
Bei allen Mglichkeiten zur Deinstallation von Patches muss immer das Produkt angegeben werden,
von dem der Patch entfernt werden soll. Bei Verwendung von Multi-SKU-Patches mssen demzufolge
mehrere Befehlszeilenaufrufe erfolgen, um den Patch von allen Produkten zu entfernen. Zur Angabe
des Produktes kann sowohl eine Pfadangabe zu dem Installationspaket, als auch die Eigenschaft
ProductCode verwendet werden. Der zu deinstallierende Patch kann ebenfalls ber eine Pfadangabe
oder die Eigenschaft PatchCode festgelegt werden. Es besteht auch die Mglichkeit mehrere Patches
innerhalb einer Transaktion von einem Produkt zu entfernen. Hierzu sind die Referenzen auf die
Patches durch Semikolon voneinander zu trennen.
Ein Patch kann natrlich auch programmtechnisch entfernt werden, wobei die gleichen Vorgaben und
459
Kapitel 10
Einschrnkungen gelten. Bei Verwendung der Deployment Tools Foundation steht zum Entfernen von
Patches die Funktion Installer.RemovePatches() zur Verfgung. In Kombination mit den
Inventarisierungsmglichkeiten, kann eine Funktion erstellt werden, die einen Patch von allen
Produkten entfernt, auf die er angewendet wurde.
private void RemovePatch(string patchCode)
{
// Installierte Patches abrufen
IEnumerable<PatchInstallation> patches = PatchInstallation.GetPatches(
patchCode,
null,
null,
UserContexts.All,
true);
// PatchCode einer Liste hinzufgen
List<string> patchGuids = new List<string>();
patchGuids.Add(patchCode);
// Patch von allen Produkten entfernen
foreach (PatchInstallation patch in patches)
{
if (patch.Uninstallable)
{
Installer.RemovePatches(patchGuids, patch.ProductCode, string.Empty);
}
}
}
Listing 10.95: Entfernen eines Patches von allen Produkten
Problemfall Gemeinsame Komponenten

Der kritischste Abschnitt im Deinstallationsprozess eines Patches ist das Zurcksetzen der Dateien in
den Zustand, den sie innehatten, bevor der Patch angewendet wurde. Die grten Problemfaktoren
ergeben sich hierbei in der Verwendung von gemeinsam genutzten Dateien, also Dateien, die von
mehreren Produkten bentigt werden. Bei der Deinstallation von Patches wird jedoch nicht
unterschieden, ob es sich um private Dateien oder um gemeinsam verwendete Dateien handelt, also um
Dateien deren Komponenten von mehreren Produkten installiert und verwendet werden. Die
Zielsetzung des Deinstallationsprozesses von Patches liegt in der Rcknahme aller nderungen durch
diesen Patch, wobei der Funktionsfhigkeit des aktuellen Produktes die hchste Prioritt eingerumt
wird. Das bedeutet auch, dass gemeinsam genutzte Dateien durch eine ltere Version berschrieben
werden, obwohl durch eine andere Produktinstallation eine neuere Version der Datei dem System
hinzugefgt wurde. Die Problematik ist offensichtlich. Die Ausfhrung anderer Produkte kann
fehlschlagen, falls diese eine andere Version der Datei erwarten. Zur Verdeutlichung der
Problemstellung soll das folgende Beispiel dienen.
Microsoft Word 2007 installiert die Datei mso.dll, Version 12.0 in das Verzeichnis
%CommonFilesFolder%\Microsoft Shared\Office 12.
Microsoft Outlook 2007 installiert die Datei mso.dll, Version 12.5 ebenfalls in das Verzeichnis
%CommonFilesFolder%\Microsoft Shared\Office 12.
Ein Patch wird auf das Produkt Microsoft Word 2007 angewendet. Hierdurch wird die Datei
460
Kapitel 10
mso.dll auf die Version 12.6 aktualisiert.

Bei der Deinstallation des Patches wird die Datei mso.dll durch die Version 12.0 ersetzt. Der
Algorithmus fr die Deinstallation legt fest, dass eine Datei in den Zustand versetzt wird, der sich aus
der im Arbeitsspeicher befindlichen Kopie des Installationspaketes ergibt. Auf das Produkt Microsoft
Word 2007 sind keine weiteren Patches angewendet, so dass hierdurch die Version 12.0 der Datei
mso.dll im Verzeichnis %CommonFilesFolder%\Microsoft Shared\Office 12 erwartet wird. Die
Problematik ist offensichtlich. Bevor der Patch eingespielt wurde, befand sich die Datei mso.dll in der
Version 12.5 im entsprechenden Verzeichnis. Nachdem der Patch entfernt wurde, ist hingegen die
Version 12.0 der Datei vorhanden.
Mit dem Windows Installer 4.5 wurde diese Problemstellung adressiert und es wurde eine Mglichkeit
geschaffen, individuell auf bestimmte Anforderungen zu reagieren. Bei der Deinstallation eines
Patches kann nun der globale Status der Komponente anstelle des produktspezifischen Status
herangezogen werden. In dem gerade dargestellten Beispiel wrde somit nach der Deinstallation des
Patches von Microsoft Word 2007, die Datei mso.dll in der Version 12.5 auf dem System verbleiben.
Es wird hierbei also nicht der Versionsstand von Microsoft Word 2007 wieder hergestellt, sondern der
systemweite Versionsstand der Datei mso.dll, wie dieses auch in Abbildung 10.100 gezeigt wird.
Abbildung 10.100: Deinstallation von Patches und gemeinsam verwendete Dateien
Dieser neue Algorithmus des Windows Installers wird jedoch nicht automatisch verwendet, vielmehr
muss die jeweilige Komponente mit dem Attribut msidbComponentAttributesShared gekennzeichnet
werden. Die Kennzeichnung muss nicht in jedem Paket vorgenommen werden, mit dem diese
Komponente installiert wird, sondern die Kennzeichnung in mindestens einem Paket ist hierfr
ausreichend. In dem Beispiel ist es somit unerheblich, ob die Komponenten im Installationspaket von
461
Kapitel 10
Microsoft Word 2007 oder Microsoft Outlook 2007 gekennzeichnet wurde. Wichtig ist nur, dass die
Komponente in mindestens einem Paket fr die gemeinsame Verwendung markiert wurde.
Hinweis Beginn
Es gilt zu beachten, dass aus Grnden der Kompatibilitt oder sonstiger Anforderungen, das optimierte
Verhaltensmuster bei gemeinsamen Komponenten auer Kraft gesetzt werden kann. Hierzu ist die
neue Systemrichtlinie DisableSharedComponent auf den Wert 1 zu setzen.
Hinweis Ende
Die zuvor erwhnte Kennzeichnung ist in der Tabelle Components vorzunehmen, indem fr die
gemeinsame Komponente der Wert der Spalte Attributes um 2048 erhht wird. Bei der Verwendung
von Windows Installer-XML ist dem Element Component das Attribut Shared anzufgen, wie dieses
auch auszugsweise in Listing 10.96 aufgezeigt wird.
<Directory Id="CommonFilesFolder">
<Directory Id="COMMONINSTALLLOCATION" Name ="Windows Installer-Shared">
<Component Id="C__Spellchecker.dll" Guid="{EC60E883-8FD6-4bd3-85A9-FD995174F491}" Shared="yes" >
<File Id="F__Spellchecker.dll" Source=".\Binaries\SpellChecker_120.dll" Name="Spellchecker.dll"
KeyPath="yes" AssemblyManifest="F__Spellchecker.dll" AssemblyApplication="F__Spellchecker.dll"
</Component>
</Directory>
</Directory>
Listing 10.96: Kennzeichnung einer gemeinsam genutzten Komponente
Die grundstzliche Vorgehensweise zur Nutzung von gemeinsam verwendeten Komponenten, sollte
natrlich in der Verwendung von Mergemodulen oder alternativen Technologien wie Windows
Installer-XML-Bibliotheken liegen. Hierdurch wird die Komponente nur an einer Stelle definiert und
kann von mehreren Quellen referenziert werden, so dass die erzeugten Installationspakete identische
Daten enthalten und sich natrlich im Installationsprozess auch identisch verhalten. Es wird deutlich,
dass durch die Verwendung geeigneter Werkzeuge und der neuen Mglichkeiten des Windows
Installers 4.5, die Nutzung gemeinsamer Komponenten wesentlich effektiver gestaltet werden kann.
Problemfall Benutzerdefinierte Aktion

Ein weiterer Problempunkt bei der Deinstallation von Patches ergibt sich in Verbindung mit
benutzerdefinierten Aktionen. Diese knnen sowohl im Installationspaket definiert, als auch durch
einen Patch dem Installationspaket hinzugefgt werden. Wird eine benutzerdefinierte Aktion in einem
Patch definiert und diese in einer der Sequenztabellen referenziert, wird die benutzerdefinierte Aktion
bei der Installation des Patches problemlos ausgefhrt. Anders verhlt es sich bei der Deinstallation
des Patches. Wie bereits vorhergehend erlutert, wird der zu entfernende Patch whrend des
Deinstallationsprozesses nicht auf das im Arbeitsspeicher befindliche Abbild des Installationspaketes
angewendet. Der Patch wird vielmehr getrennt betrachtet, so dass die Operationsanweisungen zur
Deinstallation der jeweiligen Ressourcen anderweitig erstellt werden. Aus diesem Grund kann die
benutzerdefinierte Aktion, die durch den Patch hinzugefgt wurde, whrend der Deinstallation des
Patches nicht ausgefhrt werden. Hieraus ergibt sich, dass benutzerdefinierte Aktionen whrend der
Deinstallation eines Patches nur ausgefhrt werden, wenn diese direkt im Installationspaket definiert
oder mit einem frheren Patch dem Installationspaket hinzugefgt wurden. Die hieraus resultierende
Problematik ist nicht zu vernachlssigen, wie ein einfaches Beispiel zeigt.
Es wird der Microsoft SQL Server installiert. Mit einem spteren Patch werden Teile des
462
Kapitel 10
Datenbankmoduls ersetzt. Weiterhin werden durch eine benutzerdefinierte Aktion einige der
Systemtabellen angepasst, damit sie von dem aktualisierten Datenbankmodul verwendet werden
knnen. Wird zu einem spteren Zeitpunkt der Patch wieder entfernt, wird zwar das Datenbankmodul
auf die ursprngliche Version zurck gesetzt, aber die Systemtabellen bleiben unverndert. Hierdurch
bedingt, kann die Ausfhrung des Produktes nicht mehr sichergestellt werden. Zur Vermeidung einer
solchen Problematik existieren im Prinzip nur zwei Lsungsanstze.
Der Patch wird als nicht deinstallierbar gekennzeichnet. Diese Methode ist sehr einfach
durchfhrbar, setzt aber einige der relevanten Funktionen des Servicemodells auer Kraft.
Die Aktualisierung des Microsoft SQL Servers wird durch zwei Patches realisiert. Der erste Patch
enthlt die benutzerdefinierte Aktion, die bei der Deinstallation des zweiten Patches ausgefhrt
werden soll.
Die zuletzt genannte Vorgehensweise ist mglich und stellt bei Verwendung des Windows Installers
4.0 die einzige echte Mglichkeit zur Lsung des Problems dar. Die Umsetzung ist problematisch
und unkomfortabel. Zunchst muss die Ausfhrung der benutzerdefinierten Aktion mit einer
Bedingung versehen werden, damit sie nur bei der Deinstallation des entsprechenden Patches
ausgefhrt wird und nicht bei der Deinstallation jedes Patches. Hierzu kann die Eigenschaft
MsiPatchRemovalList verwendet werden. Dieser Eigenschaft werden die Patchcodes aller Patches
angefgt, die whrend der Patch-Deinstallation entfernt werden. Somit muss der erste Patch den
Patchcode des zweiten Patches kennen, damit die Bedingung entsprechend definiert werden kann. Ein
weiterer problematischer Punkt liegt in der Aufteilung des Codes zur Durchfhrung der nderungen,
da ja fr die Installation und Deinstallation unterschiedliche Patches verwendet werden mssen. Dieses
durchbricht auch die Symmetrielsung, die beim Design von benutzerdefinierten Aktionen gefordert
ist. Weiterhin wird natrlich auch die Pflege und Verwaltung der Codefragmente wesentlich erschwert.
Mit dem Windows Installer 4.5 wird das Portfolio der benutzerdefinierten Aktionen um eine echte
Patch Uninstall Custom Action erweitert, also um eine benutzerdefinierte Aktion, die im Patch
definiert werden kann aber auch nur bei der Deinstallation des Patches ausgefhrt wird. Zur
Kennzeichnung einer solchen benutzerdefinierten Aktion wurde das Schema der Tabelle CustomAction
angepasst, indem eine neue Spalte mit der Bezeichnung ExtendedType angefgt wurde, wie das auch
nachfolgend dargestellt wird.
Spalte
Typ
Gre
Schlssel
Null
Beschreibung
Action
Identifier
s72
Type
Integer
i2
Source
CustomSource
s72
Enthlt den Namen einer Eigenschaft oder

einen Wert, der auf einen Schlssel einer
weiteren Tabelle verweist.
Target
Formatted
s255
Enthlt einen Ausfhrungsparameter, der

abhngig vom verwendeten Typ der
benutzerdefinierten Aktion ist.
ExtendedType
DoubleInteger
i4
Dient zur Festlegung einer benutzerdefinierten

Aktion, die whrend der Deinstallation eines
Patches ausgefhrt wird.
Eindeutige Identifizierung des Datensatzes.

Definition des Basis-Typs der
benutzerdefinierten Aktion.
Tabelle 10.94: Struktur der Tabelle CustomAction
463
Kapitel 10
Zur Kennzeichnung einer benutzerdefinierten Aktion, die nur bei der Deinstallation eines Patches
ausgefhrt werden soll, ist diese mit dem Attribut msidbCustomActionTypePatchUninstall zu versehen.
Das bedeutet, dass der Spalte ExtendedType der Wert 32768 zuzuweisen ist. Noch ein Wort zu der
Vernderung der Tabellenstruktur und der Frage warum die Kennzeichnung nicht in der Spalte Type
vorgenommen werden kann. Der Spalte Type liegt der Datentyp Integer zu Grunde, so dass als
Maximalwert 32767 verwendet werden kann. Das bedeutet, dass sich der Wert
msidbCustomActionTypePatchUninstall auerhalb des gltigen Bereichs befindet und kleinere Werte
nicht mehr zur Verfgung stehen. Eine nachtrgliche nderung des Datentyps der Spalte Type in
DoubleInteger wrde die Kompatibilitt durchbrechen.
Die Definition in einem WXS-Dokument ist wiederum relativ einfach und richtet sich natrlich auch
nach der Art der benutzerdefinierten Aktion. Wesentlich ist jedoch das Attribut PatchUninstall des
Elementes <CustomAction/>, das auf den Wert yes zu setzen ist, wie das auch in Listing 10.97
gezeigt wird.

<CustomAction Id="PatchUnstallCA" PatchUninstall ="yes" BinaryKey="CADLL" Execute="deferred"
Impersonate="no" DllEntry="RemoveTable"/>

<Custom Action="PatchUnstallCA" After="RemoveFiles" />
Listing 10.97: Benutzerdefinierten Aktion, die bei der Deinstallation eines Patches ausgefhrt wird
Eine benutzerdefinierte Aktion, die bei der Deinstallation eines Patches ausgefhrt werden soll, ist im
Aktualisierungspaket zu definieren, so dass sie in den Patch bertragen wird. Bei der Deinstallation des
Patches, wird auf die im Patchpaket enthaltene Aktion zugegriffen und sie wird ausgefhrt. Es ist nicht
mglich eine benutzerdefinierte Aktion, die bereits im Installationspaket vorhanden ist, nachtrglich
durch einen Patch zu modifizieren und somit fr den Deinstallationsfall nutzbar zu machen.
Problematische Aspekte ergeben sich bei der Verwendung des Windows Installers 4.0 oder frher in
Verbindung mit solchen benutzerdefinierten Aktionen. Wird ein entsprechend definierter Patch auf
einem solchen System angewendet, wird die benutzerdefinierte Aktion nicht bei der Deinstallation des
Patches ausgefhrt, da die diesbezgliche Funktionalitt nicht zur Verfgung steht. Vielmehr wird die
benutzerdefinierte Aktion bei jeder Installationsttigkeit, also bei der Installation, der Reparatur oder
der Aktualisierung ausgefhrt. Zur Vermeidung ist die Ausfhrung von einer Bedingung abhngig zu
machen, die auf die Eigenschaft MSIPATCHREMOVE abzielt und somit die Installation unter lteren
Versionen des Windows Installers nicht beeintrchtigt.
Fazit
Durch die Verwendung von Windows Installer-Patches wird das Servicemodell zur Aktualisierung von
Windows Installer-Produkten extrem erweitert. Das begrndet sich dadurch dass kleine, kompakte
Daten fr diese Zwecke zur Verfgung gestellt werden knnen, die weiterhin auch noch auf mehrere
Zielprodukte angewendet werden knnen. Mit dem Windows Installer 3.0 wurden neue funktionale
Ergnzungen eingefhrt, die viele Probleme bei der Verwendung von Patches beseitigen, die mit
frheren Versionen des Windows Installers aufgetreten sind. Mit dem Windows Installer 4.5 wurde
noch ein wenig nachgebessert, um nahezu optimale Ergebnisse im Aktualisierungsprozess erzielen zu
464
Kapitel 10
knnen. Diese Nachbesserungen beziehen sich nicht nur auf optimierte und flexiblere Ablufe im
tatschlichen Installationsprozess sondern beinhalten auch Verbesserungen in der Toollandschaft.
Das ist jedoch nicht alles was der Windows Installer 4.5 zu bieten hat, denn es sind auch
Erweiterungen und Verbesserungen in anderen Bereichen vorgenommen worden. Ein groes Plus
ergibt sich zunchst durch die breite Plattformuntersttzung. So kann diese Windows Installer-Version
auf den Betriebssystemen der aktuellen Generation verwendet werden, aber auch die vorherigen
Betriebssysteme Windows XP und Windows Server 2003 werden noch untersttzt. Der Hauptgrund
der zur Entwicklung des Windows Installer 4.5 gefhrt hat, ist der Wandel, den die moderne
Softwareinstallation derzeitig durchluft. Die zuknftige Installationslandschaft ist nicht mehr durch
monolithische Installationspakete gekennzeichnet, sondern orientiert sich an einem Modell, in dem
modular aufgebaute Pakete verwendet werden und somit flexibler auf Marktanforderungen reagiert
werden kann. Der Windows Installer 4.5 stellt nun alle Funktionalitten zur Verfgung, um die
modularen Installationspakete zu einer Gesamtinstallation zusammenzufassen, die transaktional ber
Paketgrenzen hinweg arbeitet und darber hinaus noch eine konsistente Benutzerinteraktion whrend
des gesamten Lebenszyklus des Produktes ermglicht.
465
Anhang A
Glossar
Glossar
Hier wird automatisch ein Inhaltsverzeichnis generiert, bitte nicht manuell bearbeiten!
A
ACL: Siehe Zugriffssteuerlisten
Administrative Installation: Kennzeichnet eine Installationsart, bei der das Produkt in keinen
ausfhrbaren Zustand versetzt wird, sondern lediglich die Inhalte eines Installationspaketes extrahiert
werden. Solche Installationen knnen wiederum als Installationsquelle fr klassische
Installationsprozesse dienen oder zur Erzeugung von Windows Installer-Patches verwendet werden.
Advertising: Bezeichnet eine Installationsform des Installers, bei der nur Schnittstellen auf dem
System registriert werden, ohne das Produkt physisch zu installieren. Wird eine dieser Schnittstellen
aktiviert, wird das Produkt automatisch installiert.
B
Basisinstallation: Die klassische erstmalige Installation eines Produktes. Andere Bezeichnungen
hierfr sind Client- oder Erstinstallation.
Benutzerdefinierte Aktion (engl. custom action): Eine Aktion, die durch den Autor des
Installationspaketes erstellt wurde mit dem Ziel eine funktionsspezifische Aufgabe im
Installationsprozess auszufhren, fr die keine Standardaktion vorhanden ist.
Benutzerkontensteuerung (engl. User Account Control): Ein Mechanismus in den Betriebssystemen
Windows Vista und Windows Server 2008, mit dem die unbefugte Ausfhrung von Software
verhindert oder eingeschrnkt wird.
Bootstrapper: Eine Anwendung zur Steuerung der Installation mehrerer Produkte. Der Bootstrapper
sehr nur bei der Erst- oder Basisinstallation zur Verfgung.
C
Chainer: Eine Anwendung zur Installation, Aktualisierung und Deinstallation mehrerer Produkte. Im
Vergleich zum Bootstrapper wird der Chainer whrend des gesamten Produktlebenszyklus verwendet.
Clientinstallation: Siehe Basisinstallation.
D
Deployment Tools Foundation [Abk. DTF]: Eine Programmierschnittstelle fr die .NET-Welt zum
Zugriff auf die Windows Installer-Funktionalitt. Die Deployment Tools Foundation ist Bestandteil der
Toolsammlung Windows Installer-XML.
Driver Installation Framework [Abk. DIFx]: Eine Toolsammlung, durch die eine Installation von
466
Glossar
Anhang A
Gertetreibern mit den Windows Installer ermglicht wird.
E
ECMA: [Abk. fr European Computer Manufacturers Association]: Eine 1961 gegrndete
Industrievereinigung von europischen Computerherstellern, die Vorschlge fr die Normung und
Standardisierung von Informations- und Kommunikationssystemen erarbeitet.
Ereignisprotokoll: Diese Informationen knnen zur Diagnose von fehlerhaften Installationsablufen
verwendet werden.
Erstinstallation: Siehe Basisinstallation
F
Feature: Die kleinste installierbare Einheit eines Produktes aus Sicht des Benutzers. Ein Feature
enthlt immer ein oder mehrere Komponenten.
G
GUID (engl. globally unique identifier): Ein Identifikationsschema zur eindeutigen Bezeichnung von
Objekten.
K
Komponente: Die kleinste installierbare Einheit eines Produktes aus Sicht des Autors. Eine
Komponente fasst die zu installierenden Ressourcen zu logischen Gruppierungen zusammen.
M
Managed Installation: Siehe Verwaltete Installation
Managed Kontext: Bezeichnet den Per-User-Managed oder den Per-Machine Kontext.
Mergemodul (MSM-Datei): Bei einem Mergemodul handelt es sich um eine Datenbank, die in ein
Installationspaket integriert werden kann und somit neue Komponenten fr die Anwendung zur
Verfgung stellt. Mergemodule stehen nur im Entwicklungsprozess zur Verfgung und knnen daher
nicht separat installiert werden.
MSI: Kurzform der Microsoft Windows Installer-Technologie, die ursprnglich als Microsoft
Software Installer-Technologie bezeichnet werden sollte. Wird ebenfalls als Dateiendung fr ein
Windows Installer-Paket verwendet.
Multi Package Transaktion: Siehe paketbergreifende Transaktionen
N
Neustart-Manager (engl. Restart Manager): Eine Technologie in Windows Vista und Windows
Server 2008 zur Reduzierung der Computerneustarts.
O
Orca: Orca ist ein Tool zur direkten Bearbeitung von Windows Installer-Paketen, das im Windows
467
Anhang A
Glossar
Installer-SDK enthalten ist.
P
Paketbergreifende Transaktion: Eine neue Funktionalitt im Windows Installer 4.5 zur Installation
mehrerer Produkte innerhalb einer Transaktion.
Patch 2.0: Ein Windows Installer-Patch, der nicht ber die Tabelle MsiPatchSequence verfgt.
Patch 3.0: Ein Windows Installer-Patch, der die Tabelle MsiPatchSequence enthlt.
Patching: Bezeichnet eine Methode, um Dateien zu aktualisieren. Hierbei werden nicht die
vollstndigen Dateien ausgetauscht, sondern auf physischer Ebene nur die tatschlich abweichenden
Bytes.
Privilegierte Installation: Bezeichnet Installationen, in denen die durchzufhrenden Aktionen
privilegiert, also unter Verwendung erhhter Rechte, ausgefhrt wurden.
Privilegierter Account: Ein Benutzerkonto mit administrativen Berechtigungen oder das lokale
Systemkonto.
Protokollierung: Der Windows Installer schreibt Fehlermeldungen und zustzliche Informationen in
ein eigenes Protokoll und einzelne Teile davon in das Windows-Ereignisprotokoll.
R
Rollback: Die automatische Wiederherstellung des ursprnglichen Systemzustandes im Falle einer
fehlgeschlagenen Installation.
Restart Manager: Siehe Neustart-Manager
S
Strukturierte Speicherung (engl. structured storage): Die strukturierte Speicherung realisiert die
permanente Speicherung von COM-Objekten, wobei jedes Objekt ber einen privaten Bereich
innerhalb der Datei verfgt, in dem es seine Daten ablegen kann. Es gibt Storage- und Stream-Objekte,
die bei einer Projektion auf das Dateisystem mit Ordnern und Dateien verglichen werden knnen. Die
auf diese Weise zusammengesetzte Datei wird als Verbunddokument bezeichnet.
Systemzugriffssteuerungsliste (engl. System Access Control List) [Abk. SACL]: Diese
Systemzugriffssteuerungsliste ist erforderlich, um alle erfolgreichen oder gescheiterten
Zugriffsversuche auf eine Ressource in ein spezielles Ereignisprotokoll zu schreiben
T
Transaktion: Eine feste Folge von Operationen, die als logische Einheit betrachtet werden.
Transformation (MST-Datei): Eine Transformation ist ein Dokument, das die Differenz zweier
Installationsdatenbanken enthlt und im Rahmen der Erstinstallation auf ein Produkt angewendet
werden kann.
U
User Account Control [Abk. UAC]: Siehe Benutzerkontensteuerung
468
Glossar
Anhang A
V
Validierung: Die Validierung prft die Inhalte eines Windows Installer-Paketes auf interne Konsistent
und fehlerfreie Daten.
Verbunddokument (engl. compound document): Bezeichnung eines Dokumentes, in der
unterschiedliche Objekte unter Verwendung der strukturierten Speicherung persistiert werden.
Verwaltete Installationen (engl. Managed Installation): Verwaltete Anwendungen sind Installationen
die unter der Kontrolle des Systemadministrators durchgefhrt wurden, also alle
Maschineninstallationen (per-machine) und bestimmte Benutzerinstallationen (per-user managed).
W
W3C: Siehe World Wide Web Consortium
Wartungsmodus (engl. maintenance mode): Der Windows Installer wechselt in diesen Modus, falls
der Installationsprozess fr ein Produkt gestartet wird, das bereits auf dem System vorhanden ist. Im
Wartungsmodus kann dieses Produkt erneut installiert oder zustzliche Komponenten nachinstalliert
werden.
Windows Installer-XML [Abk. WiX]: Eine Sammlung von Tools und Spezifikationen, mit denen die
Inhalte eines Windows Installer-Paketes oder eines Mergemoduls durch XML-Dokumente (Extensible
Markup Language) definiert und anschlieend in die entsprechende Windows Installer-Datei berfhrt
werden knnen.
World Wide Web Consortium [Abk. W3C]: Eine 1994 von Tim Berners-Lee, einem der Initiatoren des
World Wide Web, zusammen mit dem europischen Kernforschungszentrum CERN und anderen
Institutionen gegrndete, nicht staatliche und nicht kommerzielle Organisation. Das W3C hat sich die
Aufgabe gesetzt, offene Standards zu entwickeln und zu publizieren, durch die ein allgemeiner
Informationsaustausch im Internet mglich wird.
Z
Zugriffssteuerlisten [Abk. ACL]: Verzeichnis der Zugriffsberechtigungen fr Dateien und Ressourcen.
469
Anhang B
Tools und Anwendungen fr den Windows Installer
Tools und Anwendungen fr den

Windows Installer
Der Markt fr Tools und Anwendungen fr den Windows Installer ist mittlerweise riesengro, so dass
eine Orientierung nur sehr schwer mglich ist. Um ein bisschen Licht in das Dunkel zu bringen, habe
ich meine persnlichen Lieblingstools angefgt.
Eine Toolsammlung zum Erzeugen von Installationspaketen auf Basis von XML-Dateien. Weitere
Infos und Downloads unter http://wix.sourceforge.net/.
Windows Installer-SDK
Eine Zusammenfassung von Tools und Spezifikationen, die bei der professionellen Arbeit mit dem
Windows
Installer
unerlsslich
sind.
Das
SDK
steht
als
Download
unter
http://www.microsoft.com/downloads/details.aspx?familyid=e96f8abc-62c3-4cc3-93adbfc98e3ae4a3&displaylang=en zur Verfgung.
Orca
Hierbei handelt es sich um den Tabelleneditor fr Windows Installer-Dateien. Orca ist Bestandteil des
Windows Installer-SDK.

Hierbei handelt es sich um eine Programmierschnittstelle fr die Microsoft .NET Plattform zum
Zugriff auf die Windows Installer-Funktionalitten. Deployment Tools Foundation ist Bestandteil der
Toolsammlung Windows Installer-XML.
InstEd
Dieses ist ebenfalls ein Tabelleneditor wie Orca, allerdings mit einem wesentlich erweiterten
Funktionsvorrat. Weitere Infos sind unter http://www.instedit.com/ zu finden.

Dieses Tool ist Bestandteil von Visual Studio 6.0 und ermglicht die Betrachtung von
Verbunddokumenten.
470
Anhang B
SharpDevelop
Hierbei handelt es sich um eine Entwicklungsumgebung zur Erzeugung von C#, VB.NET und Boo
Projekten fr die Microsoft .NET Plattform. Die Entwicklungsumgebung enthlt ebenfalls eine
Implementierung zur komfortablen Erzeugung von Windows Installer-XML-Projekten. Weitere Infos
sind unter http://www.icsharpcode.net/OpenSource/SD/ zu finden.
Microsoft Cabinet Software Development Kit

Dieses SDK enthlt Tools und die bentigten Dokumentationen zur effizienten Erstellung von
Kabinettdateien. Sie finden das SDK unter http://support.microsoft.com/kb/310618.
Bootstrapper Manifest-Generator
Hierbei handelt es sich um ein Tool, mit dem auf einfache Weise die Strukturen und Elemente zur
Erzeugung eines Bootstrapper erstellt und implementiert werden knnen. Der Generator steht unter
http://www.codeplex.com/bmg zum Download zur Verfgung.
IExpress
Dieses ist ein Tool zur Erzeugung von selbstextrahierenden Archiven und ist Bestandteil des
Windows-Betriebssystems.
MSI LogfileAnalyzer
Wie der Name bereits vermuten lsst, handelt es sich hierbei um eine coole Anwendung zur Analyse
von Windows Installer-Protokollen. Die Anwendung steht auf http://www.hoschi.biz/ zum Download
bereit.

Bei der Windows Installer Suite 2008 handelt es sich um eine Toolsammlung fr den Windows
Installer. Enthalten sind Tools und Anwendungen zum Auswerten von Installationsprotokollen,
Validieren und Dokumentieren von Installationspaketen, Vergleichen von Patches, Paketen und
Transformationen, Erstellen von Transformationen und Patches, Analysieren von Installationsskripten
und vieles mehr. Informationen zu den Tools sind auf http://windows-installer.net/ zu finden.
Windows Installer-Debugger 2008

Diese Anwendung ermglicht ein effizientes Debuggen durch eine Vielzahl von Funktionalitten, wie
Einzelschrittausfhrung, Haltepunkte und bedingungsabhngige Haltepunkte, Bearbeiten und
Fortfahren (Edit and Continue), Berichte und vieles mehr. Informationen sind ebenfalls auf
http://windows-installer.net/ zu finden.
Logo Testing Tools for Windows

Dieses ist eine Toolsammlung mit der die Logo-Konformitt eines Installationspaketes geprft werden
kann. Die Toolsammlung steht unter http://download.microsoft.com/download/d/2/5/d2522ce4-a441459d-8302-be8f3321823c/LogoToolsv1.0.msi zum Download zur Verfgung.
471
Anhang B
Visual Studio 2008

Hierbei handelt es sich um die Entwicklungsumgebung zum Erzeugen von Anwendungen jeder Art,
Installationspaketen und vielen anderen mehr. Von Visual Studio 2008 gibt es auch kostenlose
Express-Versionen, die auf http://www.microsoft.com/express/download/ zu finden sind.
472
Limitierungen
Anhang C
Limitierungen
Bei der Erstellung von Installationspaketen und den entsprechenden Kabinettdateien sind bestimmte
Limitierungen zu beachten, die nicht berschritten werden drfen. Die Limitierungen beziehen sich auf
den Windows Installer 2.0 und hher bei der Verwendung auf dem Betriebssystem Windows 2000 und
hher. Unter Bercksichtigung der Limitierungen mssen Installationspakete die folgenden Vorgaben
bercksichtigen.
Die Namen von Tabellen und Binr-Streams sind auf 32 Zeichen beschrnkt. Diese Vorgabe
resultiert aus der Limitierung von Streams in Verbunddokumenten. Hier sind die Namen auf 32
Zeichen (31 Zeichen plus Null-Terminator) beschrnkt. Windows Installer verwendet zwar einen
Komprimier-Algorithmus zum Speichern der Namen, so dass theoretisch 62 Zeichen verwendet
werden knnten. Aber durch die Verwendung des DBCS-Zeichenformates (Double Byte Character
Set) wird diese mgliche Anzahl wieder auf die Hlfte reduziert.
Ein Windows Installer-Paket kann maximal 32.767 Dateien aufnehmen. Dieses liegt darin
begrndet, dass bestimmte Datenfelder vom Typ i2, also Int16 sind und somit eine entsprechende
Obergrenze aufweisen. Es besteht jedoch die Mglichkeit, das Schema der Datenbank zu
verndern, so dass weitaus mehr Dateien verwendet werden knnen.
Die maximale Anzahl von Komponenten darf 65.536 pro Installationspaket nicht bersteigen.
Ein Feature darf ber maximal 15 untergeordnete Features verfgen. Wird diese Tiefe von 16
Features berschritten wird die Installation mit Fehler 2701 abgebrochen.
Die Eigenschaft ProductName darf nicht mehr als 63 Zeichen enthalten.
Einem Feature drfen maximal 1600 Komponenten zugeordnet werden. Diese Limitierung wird
mit ICE47 geprft.
Kabinettdateien sind die einzigen Archive, die vom Windows Installer verwendet werden knnen. Die
Kabinettdateien unterliegen ebenfalls Limitierungen, die sich auf die Spezifikation des Headers
zurckfhren lassen, wie dieses Listing C.98 zeigt.
struct CFHEADER
{
u1 signature[4];
u4 reserved1;
u4 cbCabinet;
u4 reserved2;
u4 coffFiles;
u4 reserved3;
u1 versionMinor;
u1 versionMajor;
u2 cFolders;
/*
/*
/*
/*
/*
/*
/*
/*
/*
Dateisignatur des Kabinetts */

Reserviert */
Gre der Kabinettdatei in Byte */
Reserviert */
Offset des ersten Eintrags vom Typ CFFILE */
Reserviert */
Major-Version des Kabinett-Dateiformats */
Minor-Version des Kabinett-Dateiformats */
Anzahl der Eintrge vom Typ CFFOLDER des Kabinetts */
473
Anhang C
u2
u2
u2
u2
u2
u1
u1
u1
u1
u1
u1
u1
cFiles;
flags;
setID;
iCabinet;
cbCFHeader;
cbCFFolder;
cbCFData;
abReserve[];
szCabinetPrev[];
szDiskPrev[];
szCabinetNext[];
szDiskNext[];
Limitierungen
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
Anzahl der Eintrge vom Typ CFFILE des Kabinetts */

Optionale Indikatoren */
Muss fr alle Kabinetts einer Serie identisch sein */
Anzahl der Kabinettdateien einer Serie */
(optional) Gre des reservierten Bereichs pro Kabinett */
(optional) Gre des reservierten Bereichs pro Ordner */
(optional) Gre des reservierten Bereichs pro Datenblock */
(optional) Reservierter Bereich pro Kabinett */
(optional) Name der vorherigen Kabinettdatei */
(optional) Name des vorherigen Datentrgers */
(optional) Name der nchsten Kabinettdatei */
(optional) Name des nchsten Datentrgers */
};
Listing C.98: Header einer Kabinettdatei
Bei den verwendeten Datentypen u1, u2 und u4 handelt es sich um vorzeichenlose 8-, 16-, und 32-Bit
Integer-Werte, worin die folgenden Limitierungen begrndet sind:
Die Gre einer komprimierten Kabinettdatei darf maximal 2 Gigabyte betragen.
Die maximale Gre aller Dateien eines Ordners darf im nicht komprimierten Zustand maximal 2
Gigabyte betragen.
Die maximale Gre aller Dateien eines Ordners darf im komprimierten Zustand maximal 2
Gigabyte betragen.
Die maximale Anzahl von Dateien innerhalb einer Kabinettdatei darf 65.535 nicht bersteigen.
474
Aktualisierung von .NET Assemblies
Anhang D
Bei der Aktualisierung von Dateien des Global Assembly Cache sind einige zustzliche Faktoren zu
bercksichtigen, die im Aktualisierungsprozess normaler Dateien in der Form nicht vorhanden sind.
Entscheidend ist hierbei die richtige Versionierung der Assemblies, was auf den ersten Blick nicht
unbedingt abweichend erscheint. Bei nherer Betrachtung ist jedoch auffllig, dass zur Versionierung
unterschiedliche Attribute zur Verfgung stehen und somit unterschiedliche Versionsnummern erzeugt
werden knnen. Das ist etwas verwirrend, insbesondere weil nur eine dieser drei Nummern von der
Common Language Runtime ausgewertet und letztlich fr das Auffinden und Laden verwendet wird.
Die anderen Versionsnummern haben eigentlich nur informativen Charakter, werden aber von
Installationsroutinen und dem Explorer verwendet.
Attribut AssemblyFileVersion: Wird auf die Win32-Ressource FileVersion abgebildet und richtet
sich nach dem bersetzungszeitpunkt eines individuellen Assemblies. Ein Assembly das im dritten
Major-Release eines Programms erstmals enthalten ist, hat hier die Nummer 1.0.x.x, auch wenn das
Programm selbst bereits Version 3.0 trgt. Wird das Assembly weiterentwickelt, wird diese Nummer
unabhngig von anderen Assemblies erhht. Die Common Language Runtime ignoriert die FileVersion
beim Laden von Assemblies. Installations- und Aktualisierungsroutinen verwenden hingegen die
FileVersion zur Prfung welche Dateien aktualisiert werden mssen.
Attribut AssemblyInformationalVersion: Wird auf die Win32-Ressource ProductVersion
abgebildet und richtet sich nach dem Zeitpunkt, an dem das gesamte Programm mit allen Assemblies
neu bersetzt und ausgeliefert wird. Sie wird also immer dann erhht, wenn eine neue CD-ROM oder
eine Installations-Routine fr den Internet-Download produziert wurde. Bei Teilaktualisierungen wird
die ProductVersion nicht verndert. Die Common Language Runtime ignoriert beim Laden von
Assemblies auch die ProductVersion.
Attribut AssemblyVersion: Die einzige Versionsnummer die von der Common Language Runtime
beim Laden von Assemblies zur eindeutigen Identifikation genutzt wird. Aber auch nur dann, wenn
starke Namen vergeben wurden. Jede referenzierende Assembly trgt den starken Namen der
referenzierten Assembly in die eigene AssemblyRef-Tabelle ein. Das bedeutet, das referenzierende
Assembly wird an exakt diese Version gebunden. Wird die Funktionalitt eines referenzierten
Assemblies gendert oder erweitert, muss deren AssemblyVersion erhht werden. Das hat zur Folge,
dass dieses Assembly von der Common Language Runtime zunchst als inkompatibel erachtet wird
und die Common Language Runtime liefert eine FileLoadException.
Versionsnummern werden ber Attribute im Quelltext spezifiziert, wie das folgende Beispiel zeigt.
using System.Reflection;
[assembly: AssemblyVersion("1.0.719.2")]
[assembly: AssemblyFileVersion("1.0.719.2")]
[assembly: AssemblyInformationalVersion("3.0.719.2")]
475
Anhang D
class Foo
{
Bei der AssemblyVersion knnen Build und Revision alternativ durch den Platzhalter * spezifiziert
werden (z.B. 1.0.* oder 1.0.719.*), wobei der Compiler dann passende Werte einsetzt. Die in Tabelle
D.95 dargestellten Berechnungen werden hierbei angewendet. Bei den anderen beiden Attributen wird
die automatische Vergabe durch den Compiler nicht untersttzt.
Nummer
Erluterung
Build
Anzahl der Tage seit dem 01. Januar 2000
Revision
Halbe Anzahl der Sekunden seit Mitternacht.
Tabelle D.95: Algorithmus zur automatischen Generierung von Versionsnummern
Es gilt jedoch zu beachten, dass gerade bei der AssemblyVersion das automatische Inkrementieren
durch den Compiler nicht empfehlenswert ist, denn hierdurch wrden permanent Versionskonflikte bei
Assemblies mit starken Namen auftreten. Im Installationsprozess hingegen, wrde die Beibehaltung
der AssemblyVersion dazu fhren, dass das Assembly nicht ersetzt wird, worauf auch durch
entsprechende Eintrge des Installationsprotokolls hingewiesen wird.
MSI (s) (10:A8) [17:52:59:465]: skipping installation of assembly component:
{02A3FAF9-6D59-4553-887E-A5E5719AFD6A} since the assembly already exists
Um zwei Versionen der gleichen Datei dennoch zu unterscheiden ist das Attribut AssemblyFileVersion
zu verwenden, das sich letztlich in der FileVersion niederschlgt und somit auch durch die StandardVersionierungsregel des Windows Installers ausgewertet wird. Die grundlegende Problematik ist
jedoch an dieser Stelle zu finden, denn die Versionierungsregel wird in der Form nur bei Assemblies
angewendet, die sich nicht im Global Assembly Cache befinden oder in diesen installiert werden
sollen. Bei der Installation und der Aktualisierung von Assemblies des Global Assembly Cache, wird
hingegen der starke Name ausgewertet, der Installations-seitig aus den Elementen der Tabelle
MsiAssemblyName konstruiert wird. Es ist somit erforderlich, die Eigenschaft FileVersion dieser
Tabelle anzufgen, damit sie ebenfalls bercksichtigt werden kann. Ein Beispiel hierfr zeigt Tabelle
D.96.
Component_
Name
Value
C__Gac
name
AssemblyPatchDemo
C__Gac
fileVersion
1.0.5000.0
C__Gac
version
1.0.5000.0
C__Gac
culture
neutral
C__Gac
processorArchitecture
MSIL
C__Gac
publicKeyToken
443DEF79785F24A9
Tabelle D.96: Verwenden des Attributs FileVersion in der Tabelle MsiAssemblyName
Bei der Verwendung von Windows Installer-XML zur Erstellung von Installationspaketen ist dieses
ebenfalls zu beachten, denn standardmig fgt Windows Installer-XML die Eigenschaft FileVersion
476
Anhang D
der Tabelle MsiAssemblyName nicht hinzu. Allerdings ist dieses Standardverhalten relativ einfach
umzundern, so dass alle erforderlichen Informationen angefgt werden. Die nderung des Verhaltens
ist abhngig von der Vorgehensweise bei der Erzeugung des Paketes. Wird hierzu die Windows
Installer-XML Integration von Visual Studio oder die Microsoft Build Engine (msbuild.exe)
verwendet, muss die WIXPROJ-Datei angepasst werden. Hierzu ist der Parameter
<SetMsiAssemblyNameFileVersion/> dieser Projektdatei anzufgen, wie auch der nachfolgende
Dateiauszug zeigt.
<PropertyGroup>
<SetMsiAssemblyNameFileVersion>True</SetMsiAssemblyNameFileVersion>
</PropertyGroup>
Wird das Installationspaket hingegen auf direkte Art erstellt, so ist das Argument -fv dem Aufruf des
Linkers light.exe anzufgen.
477
Anhang E
Datenbanktabellen des Windows Installers 4.5
Datenbanktabellen des Windows

Installers 4.5
Dieser Anhang enthlt eine Auflistung aller Tabellen, die im Datenbankschema der Windows InstallerVersion 4.5 vorhanden sind. Hierbei ist ebenfalls die korrespondierende Bezeichnung des Elementes
im WXS-Dokument angegeben, falls ein solches existiert. Bei der Betrachtung der Tabellennamen ist
auffllig, dass einige Namen mit dem Prfix Msi beginnen. Dieses ist darauf zurck zufhren, dass
Tabellen, die seit dem Windows Installer 2.0 dem Datenbankschema hinzugefgt wurden, mit diesem
Prfix versehen werden. Von der Verwendung dieses Prfix fr benutzerdefinierte Tabellen wird
abgeraten, da es einen Versto gegen existierende Design-Richtlinien darstellt.
Tabelle
WIX-Element
Beschreibung
ActionText
<ProgressText/>
Die Tabelle ActionText enthlt lokalisierte

Zeichenfolgen, die im Dialogfeld Progress
angezeigt und bei lngeren Aktionen in das
Installationsprotokoll geschrieben werden.
AdminExecuteSequence
<AdminExecuteSequence/>
Die Tabelle AdminExecuteSequence enthlt alle

Aktionen, die ausgefhrt werden sollen, wenn die
Top-Level-Aktion ADMIN ausgefhrt wird.
AdminUISequence
<AdminUISequence/>
Die Tabelle AdminUISequence enthlt alle

Top-Level-Aktion ADMIN ausgefhrt und die
Benutzeroberflche vollstndig oder reduziert
angezeigt wird.
AdvtExecuteSequence
<AdvertiseExecuteSequence/>
Die Tabelle AdvtExecuteSequence enthlt alle

Top-Level-Aktion ADVERTISE ausgefhrt wird.
AdvtUISequence
Der Windows Installer verwendet diese Tabelle

nicht. Die Tabelle AdvtUISequence sollte in der
Windows Installer-Datenbank nicht existieren oder
keine Eintragungen enthalten.
AppId
<AppId/>
Die Tabellen AppId und Registry enthalten

Informationen, die der Windows Installer bentigt,
um eine DCOM-Komponente bei der Installation
zu registrieren und zu konfigurieren.
AppSearch
<AppSearch/>
Die Tabelle AppSearch enthlt eine Liste von
478
Anhang E
Eigenschaften, die whrend der gleichnamigen
Aktion verwendet werden.
BBControl
<Billboard/>,
<Control/>
Die Tabelle BBControl enthlt die Steuerelemente,

die auf Billboards angezeigt werden.
Billboard
<Billboard/>
Bei einem Billboard handelt es sich um den Teil

eines Dialogfeldes, der in Abhngigkeit von
Aktionen oder Prozessen dynamisch verndert
wird.
Binary
<Binary/>
Die Tabelle Binary enthlt die binren Daten fr

Elemente wie Bitmaps, Animationen und Symbole.
Die Tabelle Binary kann ebenfalls verwendet
werden, um Daten fr benutzerdefinierte Aktionen
zu speichern.
BindImage
<BindImage/>
Der Windows Installer berechnet die virtuelle

Adresse jeder Funktion, die von einer
Laufzeitbibliothek importiert wird und speichert
diese in der importierten Images Adress Table
(IAT). Die Tabelle BindImage enthlt die Daten,
die zur Ausfhrung der Aktion BindImage
notwendig sind.
CCPSearch
<CCPSearch/>
Die Tabelle CCPSearch enthlt eine Liste von

Dateisignaturen, die zur Kompatibilittsprfung
(Compliance Checking Program) herangezogen
werden sollen.
CheckBox
<Control/>
Die Tabelle CheckBox enthlt Eigenschaften, die

von Steuerelementen vom Typ CheckBox
verwendet und bentigt werden.
Class
<Class/>
Die Tabelle Class enthlt Informationen, die zur

Registrierung von COM-Komponenten bentigt
werden.
ComboBox
<ComboBox/>,
<Control/>
Die Tabelle ComboBox enthlt die Zeichenfolgen

und die zugehrigen Werte, die in dem Listenfeld
des Steuerelementes ComboBox angezeigt und
ausgewhlt werden sollen.
CompLocator
<ComponentSearch/>
Die Tabelle CompLocator wird verwendet, um

Dateien oder Ordner aufzufinden, die durch
Windows Installer-Konfigurationsdaten bestimmt
werden knnen.
Complus
<Component/>
Die Tabelle ComPlus enthlt Informationen, die

zur Installation von COM+ Applikationen bentigt
werden.
Component
<Component/>
Die Tabelle Component enthlt die Komponenten

der Windows Installer-Datenbank.
Condition
<Condition/>
Die Tabelle Condition kann verwendet werden, um

fr jeden Eintrag in der Tabelle Feature eine eigene
479
Anhang E

Bedingung festzulegen und einen Installationslevel
zuzuweisen.
Control
<Control/>
Die Tabelle Control enthlt detaillierte

Informationen zu jedem Steuerelement der
Windows Installer-Datenbank.
ControlCondition
<Condition/>
Die Tabelle ControlCondition ermglicht es,

Aktionen in Abhngigkeit zu einer Bedingung
auszufhren.
ControlEvent
<Publish/>
Die Tabelle ControlEvent ermglicht es,

Ereignisse zu definieren, die in Abhngigkeit zu
dem verwendeten Steuerelement ausgefhrt
werden.
CreateFolder
<CreateFolder/>
Die Tabelle CreateFolder enthlt Referenzen auf

Ordner, die bei der Installation einer Komponente
explizit erstellt werden sollen.
CustomAction
<CustomAction/>
Die Tabelle CustomAction ermglicht es, die

Funktionalitt des Windows Installers durch
individuellen Code und Daten zu erweitern.
Dialog
<Dialog/>
Die Tabelle Dialog enthlt alle Dialogfelder, die in

der Benutzeroberflche whrend der Installation im
vollstndigen oder reduzierten Modus angezeigt
werden. Fr jedes Dialogfeld existiert ein
Datensatz in dieser Tabelle.
Directory
<Directory/>
Die Tabelle Directory legt die Ordnerstruktur fr

das Produkt fest. Jede Zeile dieser Tabelle
reprsentiert das Quell- und das Zielverzeichnis fr
einen Ordner.
DrLocator
<DirectorySearch/>
Die Tabelle DrLocator enthlt Informationen, die

bentigt werden, um Dateien oder Ordner
aufzufinden.
DuplicateFile
<CopyFile/>
Die Tabelle DuplicateFile enthlt eine Liste aller

Dateiduplikate, die in einem anderen Verzeichnis
oder unter einen anderen Dateinamen abgelegt
werden sollen als die Originaldatei. Bei der
Originaldatei muss es sich um eine Datei handeln,
die whr
Environment
<Environment/>
Die Tabelle Environment wird verwendet, um

Umgebungsvariablen zu setzen.
Error
<Error/>
Die Tabelle Error wird vom Installer verwendet,

um Fehlernummern und zugeordnete Daten in
aussagekrftige Meldungen umzuwandeln.
EventMapping
<Subscribe/>
Die Tabelle EventMapping enthlt alle

Steuerelemente, die auf bestimmte Ereignisse
reagieren sollen.
480
Anhang E
Extension
<Extension/>
Die Tabelle Extension enthlt Informationen ber

Dateinamenerweiterungen, die als Teil der
Produktanmeldung generiert werden sollen.
Feature
<Feature/>
Die Tabelle Feature definiert die logische Struktur

der Windows Installer-Features.
FeatureComponents
Die Tabelle FeatureComponents definiert die

Beziehungen zwischen den Features und den
Komponenten. Durch diese Tabelle ist es mglich
n:m-Verknpfungen zwischen den beiden
genannten Tabellen herzustellen.
File
<File/>
Die Tabelle File enthlt eine komplette

Aufstellung der Quelldateien mit den bentigten
Attributen. Dateien knnen auf dem Quellmedium
im nicht komprimierten Zustand oder in einer
Kabinettdatei gespeichert werden.
FileSFPCatalog
<SFPFile/>
Die Tabelle FileSFPCatalog verknpft spezielle

Dateien mit den Katalogdateien von Microsoft
Windows ME fr den enthaltenen WindowsDateischutz (Windows File Protection).
Font
<File/>
Die Tabelle Font enthlt Informationen, um eine

Schriftart auf dem System zu registrieren.
Icon
<Icon/>
Die Tabelle Icon enthlt die Dateien, um

entsprechende Symbole zu erstellen.
IniFile
<IniFile/>
Die Tabelle IniFile enthlt die Informationen, die

whrend der Installation in eine
Initialisierungsdatei geschrieben werden sollen.
IniLocator
<IniFileSearch/>
Die Tabelle IniLocator wird verwendet, um

Dateien oder Ordner aufzufinden, die durch
Eintragungen in einer Initialisierungsdatei
bestimmt werden knnen. Die Initialisierungsdatei
muss sich im Windows-Verzeichnis befinden.
<InstallExecuteSequence/>
Die Tabelle InstallExecuteSequence enthlt alle

Top-Level-Aktion INSTALL ausgefhrt wird.
InstallUISequence
<InstallUISequence/>
Die Tabelle InstallUISequence enthlt alle

Top-Level-Aktion INSTALL ausgefhrt und die
Benutzeroberflche vollstndig oder reduziert
angezeigt wird.
IsolatedComponent
<IsolateComponent/>
Die Tabelle IsolatedComponent stellt die

Installation von Side-By-Side Komponenten
sicher. Eine solche Komponente wird im gleichen
Verzeichnis wie die aufrufende Anwendung
abgelegt.
481
Anhang E
LaunchCondition
<Condition/>
Die Tabelle LaunchCondition wird von der Aktion

LaunchCondition verwendet. Die Tabelle enthlt
eine Liste mit Bedingungen, die zur Ausfhrung
der Installation erfllt sein mssen.
ListBox
<ListBox/>,
<ListItem/>
Die Tabelle ListBox enthlt Zeichenfolgen und die

zugehrenden Werte, die in dem Listenfeld
angezeigt und ausgewhlt werden sollen.
ListView
<ListView/>,
<ListItem/>
Die Tabelle ListView enthlt Zeichenfolgen und

die zugehrenden Werte, die in dem Listenfeld des
Steuerelementes ListView angezeigt und
ausgewhlt werden knnen.
LockPermissions
<Permission/>
Die Tabelle LockPermissions wird verwendet, um

individuell festlegbare Teile der Anwendung bei
der Ausfhrung auf abgesicherten Computern
durch das Festlegen von Zugriffsberechtigungen
einzuschrnken.
Media
<Media/>
Die Tabelle Media enthlt Informationen ber die

Quellmedien, die zur Installation bentigt werden.
Werden fr die Installation mehrere Datentrger
bentigt, muss fr jeden Datentrger ein Datensatz
in dieser Tabelle angelegt werden.
MIME
<MIME/>
Die Tabelle MIME enthlt Informationen, die zur

Registrierung von MIME-Dateitypen
(Multipurpose Internet Mail Extensions) in die
Systemregistrierung geschrieben werden mssen.
MoveFile
<CopyFile/>
Die Tabelle MoveFile enthlt eine Liste aller

Dateien, die von einem Quellverzeichnis in ein
definiertes Zielverzeichnis verschoben werden
sollen.
MsiAssembly
<File/>
Die Tabelle MsiAssembly legt Windows Installer

Einstellungen fr .NET Framework Assemblies
und Win32 Assemblies fest.
MsiAssemblyName
<File/>
Die Tabellen MsiAssembly und Tabelle

MsiAssemblyName legen Windows Installer
Einstellungen fr .NET Framework Assemblies
und Win32 Assemblies fest. Die Tabelle
MsiAssemblyName enthlt die Elemente zur
Festlegung eines starken Namens (Strong
Names).
MsiDigitalCertificate
<DigitalCertificate/>
Der Windows Installer verwendet digitale

Signaturen, um fehlerhafte Ressourcen
festzustellen. Die Tabelle MsiDigitalCertificate
speichert Zertifikate als binren Datenstrom und
verknpft jedes Zertifikat mit einem
Primrschlssel.
482
Anhang E
MsiDigitalSignature
<DigitalSignature/>
Die Tabelle MsiDigitalCertificate enthlt die

Signaturinformationen fr jedes digital signierte
Objekt in der Windows Installer-Datenbank.
MsiEmbeddedChainer
<EmbeddedChainer/>
Dieser Tabelle knnen individuelle ChainerAnwendungen zugefgt werden, die automatisch

gestartet werden und somit eine
paketbergreifende Transaktionen ermglichen.
MsiEmbeddedUI
<EmbeddedUI/>
Der Tabelle MsiEmbeddedUI wird zur Darstellung

einer individuell gestalteten, externen
Benutzeroberflche bentigt.
MsiFileHash
Die Tabelle MsiFileHash wird zum Speichern

eines durch den Windows Installer berechneten,
128-Bit Hash der Quelldatei verwendet. Der Hash
wird in vier 32-Bit groe Teile aufgeteilt und in
separaten Feldern abgelegt. Der Windows Installer
verwendet den Hashcode, um unntige
Kopieraktionen zu vermeiden.
MsiPackageCertificate
< PackageCertificates/>
Dieser Tabelle kann ein Zertifikat hinzugefgt

werden, dass im Rahmen einer
paketbergreifenden Transaktion in Verbindung
mit der UAC bentigt wird.
MsiPatchCertificate
<PatchCertificates/>
Die Tabelle MsiPatchCertificate enthlt

Informationen um einen Patch digital zu signieren
und somit das LUA-Patching zu ermglichen.
MsiPatchHeaders
MsiPatchMetadata
Die Tabelle MsiPatchHeaders enthlt die binren

Daten zur berprfung vom Vorspann (Header)
des Patches. Ein Patch, der eine gefllte Tabelle
MsiPatchHeaders enthlt, kann nur von dem
Windows Installer Version 2.0 oder hher
angewendet werden.
<PatchProperty/>,
<OptimizeCustomActions/>
Die Tabelle MsiPatchMetadata enthlt

Informationen zu dem Windows Installer Patch,
die bentigt werden um den Patch zu entfernen und
zustzliche Informationen im Dialog Software
anzuzeigen. (Diese Tabelle existiert nur in einem
Patch 3.0)
MsiPatchOldAssemblyFile
Die Tabellen MsiPatchOldAssemblyFile und

MsiPatchOldAssemblyName werden bentigt, um
gemeinsam verwendete Assemblies im Global
Assembly Cache zu aktualisieren ohne auf die
Originalquellen zuzugreifen.
MsiPatchOldAssemblyName
Die Tabellen MsiPatchOldAssemblyName und

MsiPatchOldAssemblyFile werden bentigt um
gemeinsam verwendete Assemblies im Global
Assembly Cache zu aktualisieren ohne auf die
Originalquellen zuzugreifen. Diese Tabelle enthlt
483
Anhang E

die Elemente des starken Namens des zu
aktualisierenden Assemblies.
MsiPatchSequence
<PatchSequence/>
Die Tabelle MsiPatchSequence enthlt alle

Informationen die der Windows Installer bentigt,
um einen Patch relativ zu allen anderen Patches
einzuordnen. (Diese Tabelle existiert nur in einem
Patch 3.0)
MsiSFCBypass
Ermglicht die Umgehung des Dateischutzes bei

Windows ME.
ODBCAttribute
<ODBCDriver/>,
<Property/>
Die Tabelle ODBCAttribute enthlt Informationen

ber die Attribute von ODBC-Treibern.
ODBCDataSource
<ODBCDataSource/>
Die Tabelle ODBCDataSource enthlt eine Liste

der zu installierenden ODBC-Datenquellen.
ODBCDriver
<ODBCDriver/>
Die Tabelle ODBCDriver enthlt Informationen,

die zur Installation der ODBC-Treiber bentigt
werden.
ODBCSourceAttribute
<ODBCDataSource/>,
<Property/>
Die Tabelle ODBCSourceAttribute enthlt

Informationen ber die Attribute der Datenquellen.
ODBCTranslator
<ODBCTranslator/>
Die Tabelle ODBCTranslator enthlt

Informationen, die zur Installation des ODBCbersetzers bentigt werden.
Patch
Die Tabelle Patch enthlt eine Liste von BinrPatches, die auf die Tabellen angewendet wurden.
PatchPackage
Die Tabelle PatchPackage beschreibt alle Patches,

die auf dieses Produkt angewendet wurden. Fr
jedes Patch-Paket werden zu der eindeutigen
Kennzeichnung, Informationen ber das
Quellmedium angezeigt.
ProgId
<ProgId/>
Die Tabelle ProgId enthlt Informationen, die der

Windows Installer bentigt, um das Advertising fr
eine COM-Komponente durchzufhren und die
ProgID zu registrieren.
Property
<Property/>
Die Tabelle Property enthlt die Namen und Werte

aller definierten Eigenschaften fr die Installation.
Eigenschaften, die den Wert Null enthalten, sind in
dieser Tabelle nicht aufgefhrt.
PublishComponent
<Category/>
Die Tabelle PublishComponent verknpft

Komponenten der Tabelle Components mit einer
qualifizierten Zeichenfolge und einer Kategorie.
RadioButton
<RadioButton/>
Die Tabelle RadioButton enthlt Zeichenfolgen

und die zugehrenden Werte, die in einer Gruppe
von Optionsfeldern dem jeweiligen Einzelelement
zugeordnet werden sollen.
484
Anhang E
Registry
<RegistryValue/>
Die Tabelle Registry enthlt Informationen, die in

die Systemregistrierung geschrieben werden sollen.
RegLocator
<RegistrySearch/>
Die Tabelle RegLocator wird verwendet, um

Elemente aufzufinden, die durch Eintragungen in
der Systemregistrierung bestimmt werden knnen.
RemoveFile
<RemoveFile/>
Die Tabelle RemoveFile enthlt eine Liste aller

Dateien, die beim Ausfhren der Aktion
RemoveFiles vom System entfernt werden.
RemoveIniFile
<IniFile/>
Die Tabelle RemoveIniFile enthlt die

Informationen, die vom Windows Installer aus
einer Initialisierungsdatei entfernt werden sollen.
RemoveRegistry
<RemoveRegistryKey/>,
<RemoveRegistryValue/>
Die Tabelle RemoveRegistry enthlt Informationen,

die aus der Systemregistrierung entfernt werden
sollen.
ReserveCost
<ReserveCost/>
Bei der Tabelle ReserveCost handelt es sich um

eine optionale Tabelle, die es dem Autor des
Installationspaketes erlaubt, fr die angegebenen
Ordner zustzlichen Speicherplatz zu reservieren,
der bei der berprfung auf die
Mindestvoraussetzungen einbezogen wird.
SelfReg
<File/>
Die Tabelle SelfReg enthlt eine Liste aller

Bibliotheken die selbstregistrierend sind. Der
Installer fhrt bei der Installation die Funktion
DllRegisterServer() und bei der Deinstallation die
Funktion DllUnregisterServer() aus.
ServiceControl
<ServiceControl/>
Die Tabelle ServiceControl wird verwendet, um

installierte Betriebssystemdienste zu verwalten und
zu deinstallieren.
ServiceInstall
<ServiceInstall/>
Die Tabelle ServiceInstall enthlt Informationen,

die zur Installation des Betriebssystemdienstes
bentigt werden.
SFPCatalog
<SFPCatalog/>
Die Tabelle SFPCatalog enthlt die

Katalogdateien, die Microsoft Windows ME fr
den Windows-Dateischutz bentigt.
Shortcut
<Shortcut/>
Die Tabelle Shortcut enthlt Informationen, die der

Windows Installer bentigt, um Verknpfungen
auf dem Zielcomputer anzulegen.
Signature
<FileSearch/>
Die Tabelle Signature enthlt Informationen, um

eine Datei eindeutig zu identifizieren.
TextStyle
<TextStyle/>
Die Tabelle TextStyle enthlt eine Liste der

Schriftarten, die von Steuerelementen verwendet
werden.
TypeLib
<TypeLib/>
Die Tabelle TypeLib enthlt Informationen, die zur

Registrierung von Typbibliotheken in die
485
Anhang E

Systemregistrierung geschrieben werden mssen.
UIText
<UIText/>
Die Tabelle UIText enthlt lokalisierte

Zeichenfolgen zur Verwendung in der
Benutzeroberflche, die nicht in anderen Tabellen
definiert sind.
Upgrade
<Upgrade/>,
<UpgradeVersion/>
Die Tabelle Upgrade enthlt Informationen, die fr

die Durchfhrung eines Major-Upgrades
bentigt werden.
Verb
<Verb/>
Die Tabelle Verb enthlt Informationen, die

verwendet werden, um Befehle mit diesem
Dateityp zu verknpfen. Beispiele hierzu sind die
Befehle ffnen und Drucken im Kontextmen des
Windows Explorers.
_Columns
Die schreibgeschtzte Tabelle _Columns enthlt

eine Liste aller Spalten der Datenbank.
_Storages
Die Tabelle _Storages enthlt eine Liste aller

Speicherbereiche (Storages) der aktuellen
Windows Installer-Datenbank.
_Streams
Die Tabelle _Streams enthlt eine Liste aller

Datenstrme (Stream) der aktuellen Windows
Installer-Datenbank.
_Tables
Die schreibgeschtzte Tabelle _Tables enthlt eine

Liste aller Tabellen der Datenbank.
_TransformView
Hierbei handelt es sich um eine schreibgeschtzte

temporre Tabelle zur Anwendung von
Transformationen.
_Validation
Die Tabelle _Validation enthlt eine Liste aller

Spaltennamen und Datentypen der aktuellen
Windows Installer-Datenbank. Diese Tabelle wird
zur Durchfhrung der Validierung bentigt und
verwendet.
Tabelle E.97: Datenbanktabellen der Windows Installer-Version 4.5
486
Systemrichtlinien
Anhang F
Systemrichtlinien
487
490
Das Verhalten des Windows Installers kann unter Windows 2000 und hher durch Systemrichtlinien
konfiguriert werden. Sie knnen diese Anweisungen ber den Gruppenrichtlinien-Editor definieren
oder die Einstellungen direkt in der Systemregistrierung vornehmen.
Mit Hilfe der Computerkonfiguration knnen Richtlinien fr den Computer festgelegt werden. Diese
Richtlinien werden in jedem Fall angewendet, unabhngig davon, welcher Benutzer sich letztlich an
dem betreffenden Computer anmeldet. Die Einstellungen werden unter dem Registrierungsschlssel
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer gespeichert.
Richtlinie
Beschreibung
AllowLockdownBrowse
(Durchsuchen fr Benutzer mit erhhten
Rechten aktivieren)
Durch diese Einstellung wird die Schaltflche Durchsuchen im

Dialogfeld Funktion verwenden von aktiviert. Somit knnen Benutzer
nach Installationsdateien suchen, auch wenn das
Installationsprogramm mit erhhten Systemberechtigungen
ausgefhrt wird.
AllowLockdownMedia
(Verwendung von Medienquellen fr
Benutzer mit erhhten Rechten
aktivieren)
Diese Einstellung erlaubt es allen Benutzern Programme von

Wechselmedien zu installieren, auch wenn das Installationsprogramm
mit erhhten Systemberechtigungen ausgefhrt wird. Standardmig
knnen Benutzer nur Programme von Wechselmedien installieren,
wenn die Installation ihren Berechtigungen entsprechend ausgefhrt
wird. Whrend einer privilegierten Installation knnen nur
Systemadministratoren solche Programme installieren.
AllowLockdownPatch
(Patch-Verwendung fr Programme mit
erhhter Sicherheit zulassen)
Die Einstellung erlaubt allen Benutzern Patches zu installieren, sogar

dann, wenn ein Installationsprogramm mit erhhten Berechtigungen
ausgefhrt wird. Standardmig knnen nur Systemadministratoren
Patches whrend Installationen verwenden.
AlwaysInstallElevated
(Immer mit erhhten Rechten
installieren)
Diese Einstellung vergibt erhhte Berechtigungen fr alle

Programme. Sie ermglicht es Benutzern, Programme in
Verzeichnissen zu installieren, auf die sie normalerweise keinen
Zugriff haben.
Hinweis: Diese Einstellung besteht sowohl fr die
Computerkonfiguration als auch fr die Benutzerkonfiguration. Sie
487
Anhang F
Systemrichtlinien
mssen die Einstellung in beiden Ordnern aktivieren.
Debug
(Einstellung kann nur direkt in der
Systemregistrierung vorgenommen
werden)
Diese Einstellung ermglicht die Echtzeitausgabe von

Installationsnachrichten ber die Windows-Funktion
OutputDebugString(). Weiterhin werden zustzlich Eintrge dem
(Verwenden des Neustart-Managers nicht
zulassen)
Die Neustart-Manager-API kann Systemneustarts vermeiden oder die

Anzahl von Systemneustarts reduzieren, die erforderlich sind, um
eine Installation oder Aktualisierung abzuschlieen. Durch diese
Einstellung wird die Interaktion von Windows Installer mit dem
Neustart-Manager gesteuert.
Hinweis: Verfgbar ab Windows Installer 4.0 unter Windows Vista
und Windows Server 2008.
DisableBrowse
(Dialogfeld Durchsuchen fr die Suche
nach einer neuen Quelle, entfernen)
Durch diese Einstellung wird die Schaltflche Durchsuchen neben

der Liste Funktionen verwenden von im Dialogfeld Windows Installer
deaktiviert. Folgendermaen mssen Benutzer einen
Installationsdateipfad verwenden, den der Administrator fr die Liste
Funktionen verwenden von konfiguriert hat.
DisableFlyWeightPatching
(Flyweight Patching nicht zulassen)
Wenn diese Richtlinieneinstellung aktiviert wird, werden alle PatchOptimierungsoptionen whrend der Installation deaktiviert.
(Protokollierung ber Paketeinstellungen
deaktivieren)
Mithilfe der Eigenschaft MsiLogging in einem Installationspaket

knnen Sie die automatische Protokollierung eines
Installationsvorgangs fr das Paket aktivieren. Durch diese
Einstellung wird gesteuert, wie Windows Installer diese Eigenschaft
verarbeitet.
Hinweis: Verfgbar ab Windows Installer 4.0.
DisableLUAPatching
(Installation von Updates, die durch den
Hersteller signiert wurden, fr
Nichtadministratoren nicht zulassen)
Nichtadministratorupdates bieten dem Autor einer Anwendung einen

Mechanismus zum Erstellen digital signierter Updates, die von
Benutzern ohne Administratorrechte installiert werden knnen.
Diese Einstellung legt fest, ob Benutzer, die keine Administratoren
sind, Updates installieren knnen, die vom Anwendungshersteller
digital signiert wurden.
DisableMSI
(Windows Installer deaktivieren)
Diese Einstellung verhindert, dass Benutzer Software auf ihren

Computern installieren knnen. Sie erlaubt Benutzern nur die
Programme zu installieren, die von einem Systemadministrator
angeboten werden.
DisablePatch
(Patchverwendung nicht zulassen)
Patches sind Aktualisierungen oder Updates, die nur vernderte

Programmdateien ersetzen. Patches knnen leicht durch
zerstrerische Programme missbraucht werden, so dass einige
Installationsprogramme deren Verwendung nicht zulassen.
DisablePatchUninstall
(Entfernen von Updates nicht zulassen)
Wenn diese Einstellung aktiviert wird, knnen Benutzer und

Administratoren keine Updates vom Computer entfernen. Windows
Installer kann weiterhin Updates entfernen, die nicht mehr auf das
Produkt anwendbar sind.
488
Systemrichtlinien
Anhang F
DisableRollback
(Zurcksetzen nicht zulassen)

whrend einer Installation aufzeichnet. Zustzlich wird verhindert,
dass Windows Installer Dateien beibehlt, die spter gelscht werden
sollen. Somit kann der Windows Installer den Computer nicht in den
ursprnglichen Zustand zurcksetzen, falls die Installation nicht fertig
gestellt wird.
(Deaktivieren von gemeinsam genutzten
Komponenten)
Bei der Deinstallation eines Patches kann der Komponentenstatus

systemweit ausgewertet werden. Durch diese Richtlinie kann diese
systemweite Betrachtung verhindert werden.
DisableUserInstalls
(Benutzerinstallationen nicht zulassen)
Durch Aktivieren dieser Einstellung knnen Sie festlegen, ob das

Installationsprogramm fr den Benutzer installierte Produkte fr
weitere Installationen erkennen und verwenden soll.
EnableAdminTSRemote
(Administrator erlauben, Installationen
von Terminaldienstesitzungen
auszufhren )
Standardmig knnen Systemadministratoren nur Programme

installieren, wenn sie an dem Computer, auf dem das Programm
installiert wird, angemeldet sind. Diese Einstellung erstellt eine
Ausnahmeregelung fr Computer, die Terminaldienste ausfhren.
EnableUserControl
(Benutzersteuerung bei Installationen
zulassen)
Diese Einstellung umgeht einige Sicherheitsfunktionen vom

Windows Installer, so dass Installationen, die normalerweise
aufgrund von Sicherheitsverletzungen angehalten werden, fertig
gestellt werden.
EnforceUpgradeComponentRules
(Upgradekomponentenregeln erzwingen)
Durch diese Einstellung erzwingt Windows Installer strenge Regeln

fr Komponentenupdates. Die Aktivierung dieser Einstellung kann
bei manchen Updates zu Fehlern fhren.
LimitSystemRestoreCheckpointing
(Erstellung von Prfpunkten zur
Systemwiederherstellung deaktivieren)
Standardmig erstellt Windows Installer bei jeder Installation einer

Anwendung automatisch einen Systemwiederherstellungsprfpunkt.
Dadurch knnen Benutzer ihren Computer in dem Zustand
wiederherstellen, den er vor der Installation der Anwendung aufwies.
Hinweis: Diese Einstellung gilt nicht fr die Home-Editionen der
Betriebssysteme Windows XP und Windows Vista und auch nicht bei
Server-Betriebssystemen.
Logging
(Protokollierung)
Durch Aktivieren dieser Einstellung knnen Sie die Ereignistypen,

die der Windows Installer protokollieren soll, festlegen.
MaxPatchCacheSize
(Maximalgre fr den Basisdateicache)
Windows Installer verwendet den Basisdateicache zum Speichern

von Basisdateien, die von binren Deltadifferenzupdates gendert
wurden. Der Cache wird zum Abrufen der Basisdatei fr zuknftige
Updates verwendet. Wenn diese Richtlinieneinstellung aktiviert wird,
kann die maximale Gre des Basisdateicaches fr Windows Installer
gendert werden
(Anzeige der integrierten externen
Benutzeroberflche deaktivieren)
Standardmig wird die Anzeige und Verwendung von integrierten

externen Benutzeroberflchen gestattet. Durch diese Richtlinie kann
das verhindert werden.
489
Anhang F
Systemrichtlinien
SafeForScripting
(Internet Explorer Sicherheitshinweis fr
Windows Installer Skripts deaktivieren)
Standardmig werden Benutzer gewarnt, wenn ein Skript von einem

Internetbrowser versucht ein Programm auf dem System zu
installieren, und Benutzer knnen entscheiden, ob Sie die Installation
durchfhren oder abbrechen mchten. Sie sollten diese Einstellung
aufgrund eines Sicherheitsrisikos mit Vorsicht verwenden.
TransformsSecure
(Transformationen an einem sicheren Ort
auf der Arbeitsstation zwischenspeichern)
Transformationsdateien bestehen aus Anweisungen zum ndern und

Anpassen eines Programms whrend der Installation. Standardmig
werden Transformationsdateien von Windows Installer im
Verzeichnis Anwendungsdaten des Benutzerprofils gespeichert.
Durch Aktivieren dieser Einstellung wird die Transformationsdatei an
einem sicheren Ort auf dem Computer des Benutzers anstelle im
Benutzerprofil gespeichert.
Tabelle F.98: Konfiguration fr den Computer
Mithilfe der Benutzerkonfiguration knnen Richtlinien fr Benutzer festgelegt werden, die in jedem
Fall angewendet werden, unabhngig davon, an welchem Computer sich die betreffenden Benutzer
anmelden.
Die
Richtlinien
werden
unter
dem
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer abgelegt.
Richtlinie
Auswirkungen
AlwaysInstallElevated
(Immer mit erhhten Rechten installieren)
Diese Einstellung vergibt erhhte Berechtigungen fr alle

Programme. Sie ermglicht es Benutzern, Programme in
Verzeichnissen zu installieren, auf die sie normalerweise keinen
Zugriff haben.
Hinweis: Diese Einstellung besteht sowohl fr die
Computerkonfiguration als auch fr die Benutzerkonfiguration. Sie
mssen die Einstellung in beiden Ordnern aktivieren.
DisableMedia
(Wechselmedienquellen fr andere
Installationen verhindern)
Bei dem Versuch ein Programm von einem Wechselmedium zu

installieren, wird dem Benutzer eine Meldung angezeigt, die
erlutert, dass diese Funktion nicht verfgbar ist.
DisableRollback
(Zurcksetzen nicht zulassen)

whrend einer Installation aufzeichnet. Zustzlich wird verhindert,
dass Windows Installer Dateien beibehlt, die spter gelscht werden
sollen. Somit kann der Windows Installer den Computer nicht in den
ursprnglichen Zustand zurcksetzen, falls die Installation nicht
fertig gestellt wird.
SearchOrder
(Suchreihenfolge)
Standardmig durchsucht der Windows Installer zuerst das

Netzwerk, dann Wechselmedien (Disketten-, CD-, DVD-Laufwerke)
und zum Schluss das Internet (URL). Aktivieren Sie diese
Einstellung, und geben Sie die Buchstaben ein, die die Dateiquellen
darstellen, in der Reihenfolge, in der Windows Installer suchen soll,
490
Systemrichtlinien
Anhang F
wenn Sie die Suchreihenfolge ndern mchten:
n steht fr Netzwerk;
m steht fr Wechselmedien
u steht fr URL oder das Internet.
TransformsAtSource
(Transformationen vom
Stammverzeichnis anwenden)
Transformationsdateien bestehen aus Anweisungen zum ndern und

Anpassen eines Programms whrend der Installation. Durch
Aktivieren dieser Einstellung knnen bei Reparaturen oder ReInstallationen ausschlielich Transformationen verwendet werden,
die sich im Stammverzeichnis des Installationspaketes befinden.
Tabelle F.99: Konfiguration fr den Benutzer
491
Anhang G
Automatische Reparaturen und das Microsoft Active Setup
Automatische Reparaturen und das

Microsoft Active Setup
492
493
Beim Microsoft Active Setup handelt es sich um keine direkte Implementierung oder Funktionalitt des
Windows Installers, sondern um eine Grundfunktionalitt des Betriebssystems die hervorragend in
Kombination mit dem Windows Installer verwendet werden kann. Dieses betrifft vornehmlich
Szenarien, in denen Anwendungsteile im Benutzerprofil abgelegt werden, die mitunter eine Reparatur
veranlassen um die Funktionsfhigkeit der Anwendung herzustellen.
Beim Starten einer Anwendung ber einen der drei mglichen Aktivierungspunkte des Windows
Installers, also ber die Advertised-Shortcuts, die Datei-Erweiterungen oder bei der Referenzierung
ber COM, findet eine berprfung der Schlsselressourcen statt. Die Aktivierungspunkte
referenzieren immer ein Feature, wodurch bei allen Komponenten, die mit diesem Feature verknpft
sind, die Existenz der Schlsselressource geprft wird. Bei der Schlsselressource handelt es sich um
den Bestandteil der Komponenten, die in der Spalte KeyPath der Tabelle Component referenziert
wurde. Ist eine solche Schlsselressource nicht vorhanden, wird die automatische Reparatur fr das
jeweilige Feature gestartet und die fehlende Ressource wird nachinstalliert. Ein gravierendes Problem
betrifft hierbei die Dateien, die sich im Benutzerprofil befinden. Benutzer A installiert die
Anwendung, wodurch Datei X in seinem Benutzerprofil abgelegt wird. Wird diese Datei nun als
Schlsselressource fr die Komponente definiert, wird der absolute Pfad zu dieser Datei in den
Windows Installer-Konfigurationsdaten abgelegt. Nun meldet sich Benutzer B am System an und
startet die Anwendung. Der Windows Installer prft die Existenz der Schlsselressourcen, also auch
die von Datei X, wobei er feststellt, dass sie existiert. Allerdings kann Benutzer B nicht
zwangslufig darauf zugreifen und sie verwenden, da sie im Benutzerprofil von A abgelegt ist und
die Privilegien fr den Zugriff nicht immer ausreichen. Relevant ist hierbei, dass die Datei physisch
immer vorhanden ist, unabhngig davon, welcher Benutzer angemeldet ist.
Die Problematik ist offensichtlich und es ist daher zwingend notwendig, dass bei einer Komponente,
die Dateien im Benutzerprofil ablegt, die Schlsselressource ein Eintrag in der Systemregistrierung
unter HKEY_CURRENT_USER sein muss. Bei der Verwendung eines solchen Eintrages kommt es
nicht zu diesem Problem. Denn der Schlsseleintrag wird in dem benutzerspezifischen Teil der
Systemregistrierung (ntuser.dat) von Benutzer A abgelegt. Meldet sich Benutzer B jedoch am
System an, wird nicht die ntuser.dat von Benutzer A geladen, sondern die von Benutzer B. Hier
492
Anhang G
ist aber der Schlsseleintrag nicht vorhanden, so dass Windows Installer die Komponente automatisch
nach installiert.
Hinweis Beginn
Da diese Vorgehensweise wirklich wichtig ist, wird sie auch durch die Validierungsart ICE38 geprft
Hinweis Ende
Der relevante Punkt in dem zuvor skizzierten Szenario sind die Aktivierungspunkte, da durch diese die
automatische Reparatur veranlasst wird. Problematisch ist hierbei, dass nicht immer
Aktivierungspunkte vorhanden sind oder tatschlich verwendet werden. Unter diesem Kontext kann
hervorragend ein Add-In fr Microsoft Outlook betrachtet werden. Ein solches Add-In bentigt in der
Regel Benutzer- und Maschinendaten. Bei der Installation werden beide Datenkategorien auf dem
System abgelegt, wobei die Benutzerdaten zwangslufig nur fr den aktuellen Benutzer geschrieben
werden. Meldet sich ein anderer Benutzer am System an, fehlen diese Benutzerdaten, so dass das AddIn nicht fehlerfrei ausgefhrt werden kann. Die Problematik liegt nun darin, dass ein solches Add-In
nicht ber Aktivierungspunkte gestartet, sondern durch Outlook geladen wird und somit der Windows
Installer nicht angewiesen wird, die fehlenden Elemente zu erstellen.
An dieser Stelle kommt nun das Microsoft Active Setup ins Spiel, denn hiermit ist es mglich,
Benutzerinformationen bereitzustellen, ohne dass Aktivierungspunkte im Installationspaket existieren.
Die Implementierung ist relativ einfach. Beim Anmelden eines Benutzers werden durch das
Betriebssystem die folgenden Eintragungen der Systemregistrierung berprft:
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\<ID>
HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Installed Components\<ID>
Mit ID ist ein eindeutiges Identifizierungsmerkmal gemeint, dass diesen Eintrag definiert. In der Regel
wird hierfr eine GUID verwendet. Dem Eintrag sind noch einige Werte anzufgen, so dass sich
folgendes Bild ergibt:
[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44CCA842-CC51-11CF-AAFA-00AA00B6015B}]
"Version"="1"
"StubPath"="Msiexec.exe /fpu {44CCA842-CC51-11CF-AAFA-00AA00B6015B}"
Relevant ist hierbei der Eintrag unter StubPath. Durch den Parameter fpu wird eine Reparatur aller
benutzerspezifischen Eintrge der Systemregistrierung durchgefhrt und es werden fehlende Dateien
wieder hergestellt. Beim Anmelden eines Benutzers an das Betriebssystem wird zunchst der Eintrag
unter HKEY_LOCAL_MACHINE ausgewertet. Hier wird nun geprft, ob ein identischer Eintrag auch
unter HKEY_CURRENT_USER existiert. Ist dieses nicht der Fall, wird die Befehlszeile aus StubPath
des Maschineneintrages ausgefhrt und der komplette Eintrag aus der Systemregistrierung nach
HKEY_CURRENT_USER kopiert. Ist der Eintrag unter HKEY_CURRENT_USER hingegen vorhanden
wird keine Aktivitt gestartet. Diese Aktivitten werden automatisch vom Betriebssystem veranlasst,
so dass keinerlei zustzliche Implementierungen erforderlich werden.
Hinweis Beginn
Die Funktionalitt ist nicht auf den Windows Installer beschrnkt. Unter dem Registrierungseintrag
493
Anhang G
StubPath kann jede Anwendung oder Skriptdatei angegeben werden.

Hinweis Ende
494
Struktur und Inhalt des Beispielarchivs
Anhang H
Struktur und Inhalt des

Beispielarchivs
Alle im Buch beschriebenen Beispiele sind online unter http://www.microsoft-press.de/support.asp

verfgbar. Tragen Sie im Eingabefeld fr die ISBN-Nummer die Zahl 431 ein. Klicken Sie auf Suchen.
Nach kurzer Wartezeit erscheint das Suchergebnis. Klicken Sie im Suchergebnis auf den angezeigten
Link. Klicken Sie auf den Link neben Downloads und speichern Sie die Datei auf Ihrem Computer.
Whlen Sie dabei direkt den Ordner, in den Sie die Beispiele ablegen mchten. Bei der gespeicherten
Datei handelt es sich um ein Archiv, dass zur Nutzung noch entpackt werden muss.
Hinweis Beginn
Zustzliche Informationen zu den Beispielen und Voraussetzungen zur Nutzung sind im Abschnitt
Beispieldateien zu finden.
Hinweis Ende
In der folgenden Tabelle werden die Beispiele mit einer entsprechenden Kurzbeschreibung, sowie der
Angabe des Speicherorts aufgelistet.
Ordner
Beschreibung
\Kapitel 01 - Installer
\01 SubStorage
Visual Studio-Projekt zum ffnen und Analysieren eines

Verbunddokumentes.
\Kapitel 02 - WIX
\01 WixLanguage
Verwenden von Sprach- und Includedateien mit Windows InstallerXML und Visual Studio.
\02 WixFragment
Aufteilung eines Windows Installer-XML-Dokumentes in mehrere

physische Dateien unter Verwendung von Fragmenten.
\03 WixTools\01 WixCop
Verwenden des Tools wixcop.exe zum Konvertieren eines

existierenden WXS-Dokumentes der Version 2.0.
\03 WixTools\02 Heat
Ermitteln von Datei- und COM-Informationen mit Hilfe des Tools

heat.exe.
\03 WixTools\03 Dark
Dekompilieren eines Windows Installer-Paketes und einer Windows

Installer-Transformation unter Verwendung des Tools dark.exe.
\03 WixTools\04 Melt
Verwenden des Tools melt.exe zum konvertieren eines Windows

Installer-Mergemoduls in ein Windows Installer-XML-Fragment.
\03 WixTools\05 Lit
Erstellen von mehrsprachigen, vorkompilierten Bibliotheken mit

dem Tool lit.exe.
495
Anhang H
\03 WixTools\06 Torch
Erstellen von klassischen und XML-Transformationen unter

Zuhilfenahme von torch.exe.
\03 WixTools\07 Pyro
Erstellen von Installationspakten und Windows Installer-Patches.

Hierbei wird nicht die klassische Vorgehensweise gewhlt, sondern
die optimierte Variante durch Nutzung des Tools pyro.exe.
\04 WixCustomExtension
Demonstriert die Implementierung und die Verwendung einer

benutzerdefinierten Erweiterung, die im Rahmen der
Dekompilierung benutzt werden kann.
\05 WIXExtensions\01 WixUI
Verwenden der Windows Installer-XML-Erweiterung zur Erstellung

einer von Benutzeroberflchen in unterschiedlichen Ausprgungen.
\05 WIXExtensions\02 WiXQueryOS
Abfragen von Informationen zur Ermittlung von Systemordnern.
\05 WIXExtensions\03 WixVSExtension
Abfrage von Systeminformationen die sich auf die Installation von

Visual Studio beziehen.
\05 WIXExtensions\04 User
Anlegen und Konfigurieren von Benutzerkonten im Rahmen der

Installation.
\05 WIXExtensions\05 FileShare
Einrichten einer Ordnerfreigabe und Festlegen der

Zugriffsberechtigungen im Rahmen des Installationsprozesses.
\Kapitel 04 - DTF
\01 Allgemein
Visual Studio-Projekt zur Verwendung der Deployment Tools

Foundation, mit dessen Hilfe CAB-Dateien betrachtet und das
System inventarisiert werden kann.
\02 Immediate
Benutzerdefinierte Aktion zur Festlegung des

Installationsverzeichnisses.
\03 Deferred
Benutzerdefinierte Aktion zum Anlegen und Entfernen eines

Benutzerkontos.
\Kapitel 05 - UAC
\01 CheckToken
Visual Studio-Projekt zum Ermitteln von prozessspezifischen

Informationen, die sich auf die Benutzerkontensteuerung beziehen.
\02 Vista Package
Demonstration der Installation einer Anwendung unter Windows

Vista oder Windows Server 2008.
\03 Create Shield Icon
Erstellen einer Symboldatei, die mit einem Manifest versehen wurde

und daher ber eine Schild-Kennzeichnung verfgt.
\04 PrivilegedCA
Benutzerdefinierte Aktion zur Sicherstellung der vollstndigen

Privilegien bei der Installation unter Windows Vista und Windows
Server 2008.
\05 Vista Validierung
Prfung der im Installationspaket enthaltenen benutzerdefinierten

Aktionen auf Kompatibilitt mit der Benutzerkontensteuerung von
Windows Vista und Windows Server 2008.
\Kapitel 06 - Restartmanager
\01 GUI
496
Verwenden des Neustart-Managers im Rahmen der Installation.
Anhang H
\02 Console
Konsolenanwendung, die den Neustart-Manager nutzt.
\03 Restart Manager Tools
Visual Studio-Projekt zur Simulation und zur Prfung der

Funktionalitt des Neustart-Managers.
\04 RestartCustomAction
Benutzerdefinierten Aktion die auf die Programmierschnittstelle des

Neustart-Managers zugreift.
\Kapitel 07 - Troubleshooting
\01 WRP
Installationspaket und Anwendung zur Demonstration und Analyse

des Windows-Ressourcenschutzes.
\02 Logging
Demonstration der neuen Protokollierungsfunktionalitt des

Windows Installer 4.0.
\03 MUI
Verwenden der mehrsprachigen Benutzeroberflche von Windows

Vista und Windows Server 2008.
\Kapitel 08 - Multi-Package-Transaction
\01 Bootstrapper
Erstellung und Integration eines Bootstrapper-Projektes zur

Nutzung mit msbuild.exe oder Visual Studio.
\02 Chainer
Komplexes Beispiel zur Demonstration der paketbergreifenden

Transaktionen mit dem Windows Installer 4.5.
\Kapitel 09 - Embedded UI
\01 Simple
Einfaches Beispiel zur Demonstration der Grundfunktionalitt bei

den integrierten Benutzeroberflchen.
\02 Complex
Komplexes Beispiel zur Demonstration der paketbergreifenden

Transaktionen in Verbindung mit einer integrierten
Benutzeroberflche.
\Kapitel 10 - Patches
\01 Upgrade
Installationspakete zum Nachstellen diverser

Aktualisierungsszenarien.
\02 Patch (Default)
Erstellen von Windows Installer-Patches unter Verwendung des

Windows Installer-SDK.
\03 Superseded
Demonstration der neuen Funktionalitt des Windows Installers 4.5

die sich auf den Problemfall mit verwaisten Komponenten bezieht.
\04 Shared Component
Demonstration der neuen Funktionalitt des Windows Installers 4.5

die sich auf den Problemfall mit den gemeinsam verwendeten
Komponenten bezieht.
\05 Patch Uninstall CA
Windows Installer-Patch der eine benutzerdefinierte Aktion enthlt,

die bei der Deinstallation des Patches ausgefhrt wird.
497
Stichwortverzeichnis Stichwortverzeichnis
.cub 107
.ddf 443
.ipi 362
.msi 101
.msm 101
.msp 101, 112, 427
.mst 101
.pcp 101, 112, 436
.sed 423
.sln 82
.wixlib 96
.wixmsp 96
.wixmst 96
.wixobj 95
.wixout 96
.wixpdb 96
.wixproj 82
.wxi 84, 95
.wxl 88, 95
.wxs 95
64-Bit-Architektur 132
AMD64 133
Benutzerdefinierte
Aktionen 144
Dateisystem 137
Fehlernummern 147
IA64 133
ICE80 148
Integrierte
Benutzeroberflche 404
Intel64 133
Kennzeichnungen 135
Mergemodule 133
ODBC Driver Manager 147
Registry Redirection 138
Registry Reflection 139,
142
Summary Information
Stream 133
Systemregistrierung 138
VersionNT64 143
Virtualisierung 199
498
WOW64-Subsystem 136,
147
x64 133
x86 133
A
Abschieen 253
Access Control Entry Siehe
Zugriffssteuerungseintrag
Accessibility options Siehe
Benutzeroberflche
ACE Siehe
Zugriffssteuerungseintrag
ACID 338
ACL Siehe Zugriffssteuerlisten
Acquisition-Phase Siehe
Installationsphasen
ActionState Siehe
Aktionsstatus
Active Directory 204
Add-In 493
Admin Approval Mode Siehe
Sicherheit
Siehe Installationsarten
Advertised Shortcuts Siehe
Dateiverknpfungen
Advertising 466
Aktionen
ADMIN 44, 46
ADVERTISE 44, 46
AppSearch 46
CostFinalize 45, 46
CostInitialize 45, 46
DisableRollback 351, 359
DoAction 65
ExecuteAction 46
FileCost 45, 46
FindRelatedProducts 425
ForceReboot 50, 246, 364
INSTALL 44, 46
InstallExecute 50
InstallExecuteAgain 50
InstallFiles 49
InstallFinalize 48, 50, 64,
65, 170, 353
InstallInitialize 47, 50, 64,
170
InstallValidate 47, 247, 252,
279, 302, 321
LaunchCondition 46
MigrateFeatureStates 425
RemoveExistingProducts
48, 425
ScheduleReboot 50, 247,
364
StartServices 280
StopServices 280
WriteRegistryValues 49
Aktionsstatus Siehe
Aktivierungspunkte 492, Siehe
Windows Installer-Paket
Aktualisierungsprozess 475
Aktualisierungsarten 419
Dateien 56
424
Kopieren und Entfernen von
Dateien 56
Metadaten 53
420
Modifikation des
Zielsystems 125
Patchen von Dateien 56
Recache-Flag 421
423
Skriptdateien 52
416
Systemregistrierung 55
Anforderungsstatus Siehe
Anwenderprivilegien 41
Anwendungsreihenfolge 43
Anwendungsstrategie 9, 323
Application Information
Service Siehe Sicherheit
asInvoker 189
Atomaritt 338
Atomicity Siehe Atomaritt
Attribute
ApplicationFile 329
AssemblyDefaultWixExtensi
on() 120
AssemblyFileVersion 475
AssemblyInformationalVersi
on 475
AssemblyVersion 475
CustomActionAttribute
163, 169
FileVersion 475
INSTALLMESSAGE_
INSTALLEND 386
INSTALLMESSAGE_ACTIOND
ATA 383
INSTALLMESSAGE_ACTIONS
TART 383
INSTALLMESSAGE_COMMO
NDATA 386
INSTALLMESSAGE_FILESINU
SE 384
INSTALLMESSAGE_INITIALIZ
E 382
INSTALLMESSAGE_INSTALLS
TART 385
INSTALLMESSAGE_PROGRE
SS 388
INSTALLMESSAGE_RESOLVE
SOURCE 382
INSTALLMESSAGE_RMFILESI
NUSE 384
INSTALLMESSAGE_SHOWDI
ALOG 382
INSTALLMESSAGE_TERMIN
ATE 382
InstallPrivileges 214
INSTALLUILEVEL_BASIC 373
INSTALLUILEVEL_NONE 374
msidbComponentAttributes
64bit 140, 146
DisableRegistryReflection
142, 177
Shared 461
UninstallOnSupersedenc
e 455
msidbControlAttributesElev
ationShield 234
msidbCustomActionType64
BitScript 146
msidbCustomActionTypeCo
mmit 68
msidbCustomActionTypeEx
e 58
msidbCustomActionTypeHid
eTarget 171
msidbCustomActionTypeInS
cript 58, 65, 232
msidbCustomActionTypeNo
Impersonate 57, 206,
213
msidbCustomActionTypePat
chUninstall 322, 464
msidbCustomActionTypeRol
lback 67
msidbEmbeddedHandlesBas
ic 406
msidbEmbeddedUI 394
msidbFileAttributesCompre
ssed 26
msidbFileAttributesNoncom
pressed 26
msidbFileAttributesVital
380
msidbLocatorType64bit
143, 147
msidbPatchSequenceSupers
edeEarlier 447
MSITRANSACTION_CHAIN_
EMBEDDEDUI 346, 349,
410
MSITRANSACTION_JOIN_EX
ISTING_EMBEDDEDUI
349, 411
MSITRANSACTIONSTATE_C
OMMIT 347
MSITRANSACTIONSTATE_R
OLLBACK 347, 353
ProductVersion 475
UninstallWhenSuperseded
456
Aufgabenplanung 250
Automatische Reparatur 492
Automatisierungsmodell 63
B
Basisinstallation Siehe
Installationsarten
Benutzerdefinierte Aktion 466
58, 144, 161, 230, 282, 462
Architektur 59
Bedingungen 70
Commit-Ausfhrung 68
Custom Action-Server 42,
58, 144, 231, 404
CustomActionAttribute 169
CustomActionData 66, 171
Debuggen 168
Deinstallation 70
Elevated 58, 231
Erstellung 163
Host-Prozess 144
Impersoniert 58, 231
Installationssession 65
Inverse Platform Invocation
Service 162
jscript.dll 63
Kompiliervorgang 167
Komplexe
Erweiterungsbibliotheke
n 122
Konfigurationsdatei 164
Objektbibliothek 62
Patch Uninstall Custom
Action 463
Projektvorlagen 166
Proxy 167
Remote-API 63
Rollback Ausfhrung 173
Rollback-Ausfhrung 67
499
Rckgabewerte 68
scrrun.dll 63
Sofortige Ausfhrung 64
Systemvoraussetzungen
163
vbscript.dll 63
Verzgerte Ausfhrung 65,
171
Benutzerkonfiguration Siehe
Systemrichtlinien
Benutzerkontensteuerung
179, 466
Ausfhrungsprivilegien 188
Besttigungsdialog 193,
205
ICE57 213
Installation 208
Installer-Erkennung 211
Interaktion 208
Kennzeichnung 191, 233
Paketbergreifende
Transaktionen 366
Patch 216
Problemquellen 238
Prompt for Consent 193
Prompt for Credentials 194
Richtlinien 241
Schild 233
Standardbenutzerinstallatio
nen 212
Standardbenutzerrechte
190
Virtualisierung 197
VirtualStore 197, 198
Zertifikat 210
Anwendungsszenarien 411
Basisdarstellung 277
Darstellung 381, 402
Darstellungsformen 34
Debuggen 403
Eingabehilfen 370
Externe Benutzeroberflche
371
FilesInUse 247, 252
Fortschrittsanzeige 388
Gestaltung 369
HyperLink-Steuerelement
370
500
Integrierte externe
Interne Ablufe 405
Interne Benutzeroberflche
375
MsiRMFilesInUse 247, 274
Nachrichten-Handler 373
Paketbergreifende
Transaktionen 409
Unbeaufsichtigter Modus
34
Windows Installer-Patches
407
Windows InstallerTransformationen 407
BinariesRoot 83
Binr-Patch Siehe Patch
Bootstrapper 211, 290, 327,
466
Bootstrapper ManifestGenerator 333
Einschrnkungen 333
Visual Studio 2008 332
Bootstrapper ManifestGenerator 471
Build-Systeme 82
Byte-Level-Patch Siehe BinrPatch
C
Chainer 333, 466
Abhngigkeiten 337
Beziehungen 337
Definition 333
Eingebetteter Chainer 353
Funktionalitt 334
Individualitt 335
Interaktion 337
Mehrere Chainer 361
Clientinstallation Siehe
Installationsarten
Client-Prozess Siehe
Codepage 23
Commit 339
Commit-Ausfhrung Siehe
Benutzerdefinierte
Aktionen
Commit-Phase 361, Siehe
Installationsphasen
Common Language Runtime
475
Common Public License 72
Compound Document Siehe
Computerkonfiguration Siehe
Systemrichtlinien
Computerneustart Siehe
Neustart-Manager
config.msi 56
Consistency Siehe Konsistenz
Cost-Linking 48
Credential Provider 257
Custom Action-Server Siehe
Benutzerdefinierte
Aktionen
D
DACL Siehe Freigegebene
Zugriffssteuerungsliste
Siehe Windows InstallerPaket
Dateiverknpfungen 29
Angekndigte
Verknpfungen 235
DISABLEADVTSHORTCUTS
235
Lokalisierte
Manifest 236
Shortcut 315
Sicherheitsschildsymbol
236
Datenbank
Codepage 23
KeyPath 420
Schema 478
Storage-Objekt 23
Stream-Objekte 23
Stringpool 23
Tabellenformat 23
Datenbanktabellen 478
_Property 44
_Streams 157
_StringData 23
_StringPool 23
ActionText 383
AdminExecuteSequence 46,
445
AdminUISequence 44
AdvtExecuteSequence 46
AdvtUISequence 44
AppSearch 147
Binary 355
Codepage 23
Component 146, 177, 322,
492
Components 456, 462
Control 120, 234
CustomAction 62, 163, 170,
232, 287, 322, 355, 463
Dialog 120
Directory 45, 73
DuplicateFile 48
Features 420
File 282, 355, 444
Group 128
ImageFamilies 429
IniFile 48
InstallExecuteSequence 46,
60, 170, 229, 426, 445
InstallUISequence 44
LaunchCondition 229, 260,
325, 342
LockPermissions 56, 128
Media 156, 444
MoveFile 48
MsiDigitalCertificate 218
MsiDigitalSignature 218
MsiEmbeddedChainer 322,
353, 355
MsiEmbeddedUI 322, 393
MsiPackageCertificate 322,
366
MsiPatchCertificate 218,
367
MsiPatchMetadata 431
MsiPatchSequence 430
Patch 430, 445
PatchMetadata 447
PatchPackage 444
PatchSequence 447
Properties 443
Property 31, 78, 299, 355

Registry 48
RegLocator 142, 147
RemoveFile 48
ReserveCost 48, 323
RestartManagerFiles 284
ServiceControl 280
ServiceInstall 280
Shortcut 48, 177, 235, 314
TargetImages 446
Upgrade 425
UpgradedFilesToIgnore 443
User 128
UserGroup 128
Dauerhaftigkeit 338
Deferred Execution Siehe
Benutzerdefinierte
Aktionen
Deinstallation Siehe
Installationsarten
Deklarationssprache Siehe
149, 466, 470
Externe Benutzeroberflche
377
Installation 150
Inventarisierung 453
Transaktionsklasse 351
Discretionary Access Control
List Siehe Freigegebene
Zugriffssteuerungsliste
Doppelter Unterstrich 48
Driver Installation Framework
466
Durability Siehe
Dauerhaftigkeit
E
ECMA 467
EEUI Siehe Embedded
External UI
Eigenschaften
ACTION 34
AdminProperties 44
AdminToolsFolder 225, 226
AdminUser 227
ADVERTISE 44
AFTERREBOOT 247
AllowRemoval 431, 458
ALLUSERS 207, 224
AMD64 133
AppDataFolder 225, 226
ARPNOREPAIR 37
ARPSYSTEMCOMPONENT
352
Build Action 167
Classification 431
CommonAppDataFolder
225, 226
CommonFiles64Folder 140
CommonFilesFolder 141,
225, 226
Copy Local 167
CostingComplete 48
CreationTimeUTC 431
CustomActionData 66
Description 431
DesktopFolder 225, 226
DISABLEADVTSHORTCUTS
235
DisableRollback 68
DISABLEROLLBACK 52, 57,
342, 351, 359
DisplayName 431
EnableUserControl 44
FavoritesFolder 225, 226
FontsFolder 225, 226
IncludeWholeFilesOnly 430,
443
Installed 37, 421
Intel 133, 143
Intel64 133, 143
IsAdminPackage 34
KeyPath 29
LocalAppDataFolder 212,
226
ManufacturerName 431
MinimumRequiredMsiVersi
on 447
MinorUpdateTargetRTM
431
MoreInfoURL 431
MsiAMD64 143
MSIARPSETTINGSIDENTIFIE
R 177
MSIDISABLEEEUI 322, 405
501
220
MSIDISABLERMRESTART
177, 247, 278
MSIENFORCEUPGRADECOM
PONENTRULES 421
MsiLogFileLocation 177,
299
MsiLogging 177, 298, 488
MsiNetAssemblySupport
125
MsiPatchRemovalList 463
MSIPATCHREMOVE 464
MSIRESTARTMANAGERCON
TROL 177, 247, 273
MsiRestartManagerSession
Key 177, 279
MsiRestartManangerSessio
nKey 283
MSIRMSHUTDOWN 177,
247, 278
MsiRunningElevated 177,
229
177, 247, 260
MSIUNINSTALLSUPERSEDED
COMPONENTS 322, 456
MSIUSEREALADMINDETECTI
ON 177, 229
Msix64 143
MyPicturesFolder 226, 227
OptimizeCA 431
OptimizedInstallMode 431
PackageCode 78, 421
ParentOriginalDatabase
324
ParentProductCode 324
PatchOutputPath 439
PersonalFolder 225, 226
PID_CHARCOUNT 429
PID_LASTAUTHOR 429
PID_PAGECOUNT 140, 146
PID_REVNUMBER 429
PID_TEMPLATE 133, 146,
429
PID_WORDCOUNT 25, 155,
177, 213, 431
Privileged 227
PrivilegedPatchingAuthorize
502
d 220
ProcessorArchitecture 136
ProductCode 46, 78, 161
ProductName 78
ProductVersion 419
ProgramFiles64Folder 141
ProgramFilesFolder 141,
225, 226
ProgramMenuFolder 225,
226
PROMPTROLLBACKCOST
351, 359
REBOOT 52, 247
REBOOTPROMPT 247
REINSTALL 36, 422
REINSTALLMODE 36, 421,
456
REMOVE 37
ReplacedInUseFiles 247,
254, 260
RollbackDisabled 342, 359
SecureCustomProperties
40, 44, 302
SendToFolder 225, 226
StartMenuFolder 225, 226
StartUpFolder 225, 226
System64Folder 141
SystemFolder 141, 226
TargetProductName 432
TemplateFolder 225, 226
TRANSFORMS 43
TrustMsi 443
UILevel 209
Upgradecode 161
VersionNT 143
VersionNT64 143, 147
WindowsFolder 226
x64 133
Eingeschrnkter Token Siehe
Gefilterter Token
Elevated Installation Siehe
Privilegierte Installation
EM64T Siehe Intel64
Embedded External UI Siehe
Benutzeroberflche
-Embedding 145
Ereignisprotokoll 467
Siehe Windows Installer-
XML
Execution Engine Siehe
Ausfhrungsmodul
Execution-Phase Siehe
Installationsphasen
Extended Memory 64
Technology Siehe EM64T
Extension Siehe
F
Features Siehe Windows
Installer-Paket
FIFO 341, 348
ForceReboot Siehe Aktionen
Fragment Siehe Windows
Installer-XML
Freigegebene
Zugriffssteuerungsliste 181
Full-File-Patch Siehe Patch
Funktionen
AdvertiseProduct() 178
AdvertiseScript() 178
CoCreateInstance() 63
Commit() 351
ConfigureProduct() 161
CreateAdvertiseScript() 178
CreatePatchFileEx() 443
CreateProcessAsUser() 61,
183
CreateRestrictedToken()
187
DetermineApplicablePatche
s() 434
DLLRegisterServer() 245
EmbeddedUIHandler() 322
EnableLog() 153, 298
ExitWindowsEx() 271
ExternalUIHandler() 372
ExternalUIRecordHandler()
372
ExtractFiles() 157
GetApplicationRestartSettin
gs() 271
GetInteger() 383
GetMode() 173
GetPatches() 454
GetPatchFileList() 291
GetProcAdresss() 63
GetRelatedProducts() 161
GetStream() 157
GetString() 383
GetTargetProductCodes()
449
GetTokenInformation()
196, 200
GetTransforms() 449
GetTransformsInfo() 449
GetValidTransforms() 449
Initialize() 398
InitializeEmbeddedUI() 322,
398
InitiateShutdown() 271
InstallProduct() 152, 249
IsWow64Process() 137
Join() 351
MoveFileEx() 255, 363
MsiAdvertiseProduct() 38,
350
MsiAdvertiseProductEx()
39, 350
MsiAdvertiseScript() 206
MsiApplyMultiplePatches()
337, 350
MsiApplyPatch() 337, 350
MsiBeginTransaction() 321,
344, 346
MsiConfigureFeature() 350
MsiConfigureProduct() 37,
350
MsiConfigureProductEx()
37, 337, 350
MsiDatabaseGenerateTrans
form() 443
MsiDetermineApplicablePat
ches() 434
MsiDeterminePatchSequen
ce() 434
MsiDoAction() 65
MsiEnableLog() 298
MsiEndTransaction() 321,
345, 347
MsiFormatRecord() 66
MsiGetLanguage() 66
MsiGetMode() 66
MsiGetPatchFileList() 177,
291
MsiGetProperty() 66
MsiInstallMissingComponen
t() 350
MsiInstallMissingFile() 350
MsiInstallProduct() 35, 37,
248, 337, 350
MsiJoinTransaction() 321,
348
MsiProcessMessage() 66,
383
MsiProvideAssembly() 350
MsiProvideComponent()
350
MsiProvideQualifiedCompo
nent() 350
MsiProvideQualifiedCompo
nentEx() 350
MsiQueryProductState()
332
MsiReinstallFeature() 350,
423
MsiReinstallProduct() 36,
350, 423
MsiRemovePatches() 350
MsiSetExternalUI() 337,
371
MsiSetExternalUIRecord()
337, 371
MsiSetInternalUI() 35, 337
MsiSetMode() 245
NtQueryInformationFile()
263
OpenPackage() 157
OpenProduct() 157
OutputDebugString() 488
ProcessMessage() 402
ProvideAssembly() 178
RegisterApplicationRestart()
270
ReinstallFeature() 423
ReinstallProduct() 423
RemovePatches() 460
RmAddFilter() 263
RmCancelCurrentTask() 263
RmEndSession() 263
RMEndSession() 283
RmGetFilterList() 263
RmGetList() 263
RmJoinSession() 263
RMJoinSession() 283
RmRegisterResources()
263, 283
RmRemoveFilter() 263
RmRestart() 263
RmShutdown() 263
RmStartSession() 264
Rollback() 352
SetConsoleCtrlHandler()
272
SetExternalUI() 377
SetInternalUI() 152, 377
SfcGetFiles() 296
SfcGetNextProtectedFile()
296
SfcIsFileProtected() 296
SfcIsKeyProtected() 297
Shutdown() 401
ShutdownEmbeddedUI()
322, 401
UiCreatePatchPackage()
438
UiCreatePatchPackageEx()
438
Unpack() 156
UnregisterApplicationRestar
t() 271
WinVerifyTrust() 218
G
Gefilterter Token Siehe
Zugriffstoken
Gemeinsame Komponenten
460
Gesperrte Umgebungen 17
GINA 257
Global Assembly Cache 137,
475
GUID 78, 467
H
Hierarchische Strukturen 73
highestAvailable 189
I
Identittswechsel 41, 202
503
IExpress 471
Immediate Execution Siehe
Benutzerdefinierte
Aktionen
Includedateien Siehe
Installation bei Bedarf 17
Installationsarten 32
37, 466
38
492
Basisinstallation 34, 466
Basisinstallationen 417
Clientinstallation 33, 466
Deinstallation 37
Erstinstallation 467
Maintenance Installation
35
Post-Admin-Install 34
Reparaturoptionen 35
ScriptType 53
Wartungsinstallation 421
Installationslogik 16
Installationspaket Siehe
Installationsphasen 39
Acquisition-Phase 39, 340
Commit-Phase 341
Execution-Phase 41, 340
Rollback-Phase 341
Installationsprozess 41
Aktionsstatus 47
Anforderungsstatus 47
Ausfhrungsmodul 39, 51
Berechnung des
Speicherbedarfs 46
Client-Prozess 42, 301
Computerneustart 52, 245
Cost-Linking 48
DirectoryManager 47
Execution-Phase 51
Initialisierungsphase 43
Installationsmodul 46
Installationsskript 49
Installationsstatus 47
IPI-Datei 49
504
Konfigurationsmanager 41,
46
Modifikation des
Zielsystems 51
msiexec.exe 41
Operationsanweisung 49
Rollback-Skript 52, 67
SelectionManager 47
Sequenztabellen 44
Server-Prozess 46, 301
Skriptdateien 52
Systemvoraussetzungen 46
Terminierung 52
Top-Level-Aktionen 44
Unbeaufsichtigte
Installation 46
Wiederherstellungspunkt
49
Windows Installer-Service
16
Installationsstatus Siehe
Installationsttigkeiten 16
InstallExecute Siehe Aktionen
InstallExecuteAgain Siehe
Aktionen
InstallState Siehe
Installationsstatus
InstEd 470
Intel Architecture 64-Bit Siehe
IA64
IntelliSense Siehe Windows
Installer-XML
Internal Consistency
Evaluators (ICE) Siehe
Validierung
Inventarisierung 158, 453
IPI-Datei Siehe
Isolation 338, 351
Itanium Siehe IA64
K
Kabinettdateien Siehe
424
Komponenten Siehe Windows
Installer-Paket
Konfigurationsdatei 97
323
Aktualisierung 324
Deinstallation 324
Installationsfortschritt 324
Problematik 324
Konsistenz 338
L
Language INtegrated Query
150
Least User Access Siehe
Least-privileged User Account
Siehe
LIFO 341, 348
Limited User Account Siehe
Limitierungen 473
LINQ Siehe Language
INtegrated Query
Logo Testing Tools for
Windows 471
Lokalisierte
Benutzeroberflche Siehe
Mehrsprachige
Benutzeroberflchen
Siehe Windows InstallerXML
LUA Siehe
LUA-Patches Siehe Patch
M
Maintenance Installation
Major-Upgrade 419, 424
Managed Installation Siehe
Verwaltete Installationen
Managed Kontext 467
Managed Libraries for
Windows Installer Siehe
Deployment Tools
Foundation
Mehrsprachige
Benutzeroberflchen 307
Checksumme 314
Installationspaket 314
Lokalisierte
308
Resource Configuration
Data 312
309, 310
Ressourcenskript 311
Mergemodul 467
Mergemodule 325, 467
Problematik 326
Microsoft Active Setup 492
Microsoft Build Engine 76, 82,
83, 328, 477
Microsoft Cabinet Software
Development Kit 471
Microsoft Intermediate
Language 136
Microsoft Outlook 493
Microsoft Silverlight 368
Mikro-Pakete 323
420
Minor-Upgrade 419
MMsiBreak 169
MSBuildBinPath 83
MSBuildExtensionsPath 83
MSI LogfileAnalyzer 471
MsiBreak 168, 404
msiexec.exe 61, 145, Siehe
MSIL Siehe Microsoft
Intermediate Language
MUI Siehe Mehrsprachige
Benutzeroberflchen
Multi-Lingual User Interface
Siehe Mehrsprachige
Benutzeroberflchen
Multi-Package-Transaktion
Siehe Transaktionen
Mutex 46
N
Nested Installations Siehe
Konkurrierende
Installationen
Neustart-Manager 467
Benutzerdefinierte
Aktionen 282
Darstellungsmodus 277
Dateien in Verwendung
251
Dienststeuerungs-Manager
272
Funktionsweise 260
Installationsprozess 245
Klassifizierungen 267
Kommunikationsproblem
244
Legacy-Mechanismus 276
Prozessauflistung 267
RegisterApplicationRestart()
270
O
Object Linking and Embedding
17
One-Package-One-Product 9,
323
Operationsanweisung Siehe
Orca 467
Ordnerstruktur 73
P
Patch
Aktualisierungsarten 419
Anatomie 427
Anwenden 425
Anwendungsmodelle 426
Anwendungsreihenfolge
432
Baseline-Caches 48
Befehlszeilenargumente
426
Benutzerdefinierte
Aktionen 462
216
Binr-Patches 430
Datenbank-Transformation
429
Deinstallation 456
Erstellen 434
460
Kabinettdateien 429
LUA-Patching 217
Major-Upgrade-Patch 425
MsiPatchMetadata 431
MsiPatchSequence 430
Multi-SKU-Patch 428
Multi-Target-Patch 428
Obsolescence 451
Patch 2.0 468
Patch 3.0 431, 468
Patch Creation Property File
112
Patch Uninstall Custom
Action 463
Patch-Transformation 429
patchwiz.dll 437
451
Pseudoinstallierter Zustand
432
Servicemodell 416
Supersedence 432, 451
Transformationspaar 429
UAC-Patches 216
Validierungsbedingungen
433
Verbundene Ansicht 427
Verwaiste Komponenten
455
patchwiz.dll 437
Datenverluste 440
Interne Ablufe 441
Per-Machine 53, 206
Per-User-Managed 53, 206
Per-User-Unmanaged 53, 207
Portable Executable File
Format 144
PE-Dateien 253
Prprozessor-Variablen Siehe
Privilegierte Installation 204,
505
206, 468
Privilegierter Account 468
Produkt Siehe Windows
Installer-Paket
Produktankndigung Siehe
Installationsarten
Produkte entfernen 48
Programmierschnittstelle
ComponentInstallation 160
CustomActionData 171
Database 153, 449
IDisposable 163
IEmbeddedUI 398
Microsoft.Deployment.Com
pression.Cab.dll 153
Microsoft.Deployment.Com
pression.dll 153
Microsoft.Deployment.Win
dowsInstaller.dll 152
Microsoft.Deployment.Win
dowsInstaller.Package.dll
157
PatchInstallation 160, 453
PatchPackage 448
ProductInstallation 160,
220
Record 157, 383
Rckgabewerte 69
Session 65, 157
Session.FormatRecord 66
Session.Language 66
Session.Mode 66
Session.ProcessMessage 66
Session.Property 66
SourceList 161
SQL-Funktionsvorrat 156
SummaryInfo 153
System.Configuration.Install
.Installer 162
Transaktionsklasse 351
TransformInfo 448
View 157
ProjectAggregator2 74
Prozedursprache 78
451
506
Q
Q929467 210
Quellcodefrbung Siehe
R
Registrierung
AuthorizedLUAApp 220
COM-Komponenten 54
InProgress 49
Installed Components 493
LastKnownGood 258
PendingFileRenameOperati
ons 256, 365
Produktverffentlichung 54
RunOnce 51
RunOnceEntries 51
RUNONCEENTRY 51
ServiceDllUnloadOnStop
272
WOW6432node 138
Reparaturoptionen Siehe
Installationsarten
RequestState Siehe
Anforderungsstatus
requireAdministrator 189, 229
Resource Configuration Data
312
Ressource-Bibliotheken Siehe
Mehrsprachige
Benutzeroberflchen
Ressourcenskript 311
Restart Manager Siehe
Neustart-Manager
Richtlinien fr
Softwareeinschrnkungen
43
RID Siehe Sicherheit
Rollback 339
Rollback-Ausfhrung Siehe
Benutzerdefinierte
Aktionen
Rollback-Phase Siehe
Installationsphasen
Rckgabewerte Siehe
Benutzerdefinierte
Aktionen
S
SACL Siehe
Systemzugriffssteuerungslis
te
SAM Siehe
Sicherheitskontenverwaltun
g
ScheduleReboot Siehe
Aktionen
Scripting-Engine 63
Security Account Manager
Siehe
Sicherheitskontenverwaltun
g
Security Descriptor Siehe
Sicherheitsbeschreibung
423
Selbstheilung 16
Self Extraction Directive File
423
Server-Prozess Siehe
Servicemodell Siehe Patch
Session Manager Siehe
Sitzungs-Manager
Setup- und
Bereitstellungsprojekte 328
Shared Components Siehe
SharpDevelop 471
Sicherheit 178
Administratorbesttigungs
modus 188
Administratorenkonto 179
Anwendungsinformationsdi
enst 192
Authentifizierungspakete
182
Gltigkeitsdauer der
Zertifikate 218
Kerberos 182
NTLM 182
Privilegien 184, 185
Relative ID 183
ScriptAttributes 54
SeBackupPrivilege 321
Sicherheitskontext 179
TrustedInstaller 294
Virtualisierung 197
Vollstndiger Token 187
Vollstndiger Zugriffstoken
208
293
Zugriffstoken 182, 184
Sicherheitsbeschreibung 181
Sicherheitskennung 181, 183
Sicherheitskontenverwaltung
182, 258
Sicherheitsschildsymbol 234
SID Siehe Sicherheitskennung,
Siehe Sicherheitskennung
Sitzungs-Manager 257
Skriptbasierte
Installationssysteme 15
Skripterzeugung 64
Small-Update 419
Sofortige Ausfhrung Siehe
Benutzerdefinierte
Aktionen
Softwareaktualisierungen 416
Softwareerstellungsprozess 76
Speicherbedarf Siehe
Sprachneutrale Dateien 312
Sprachspezifische Dateien 312
Standardbenutzerinstallatione
n 212
Startvorgang 256
Status-Management 17
Sticky Elevation 205
Strukturierte Speicherung 468
Siehe Windows InstallerPaket
System Access Control List
Siehe
Systemzugriffssteuerungslis
te
Systemordner 141
Systemrichtlinien
AllowLockdownBrowse 487
AllowLockdownMedia 230,
487
AllowLockdownPatch 487
AlwaysInstallElevated 48,
205, 239, 487, 490

ConsentPromptBehaviorAd
min 194
ConsentPromptBehaviorUse
r 194
Debug 488
DisableAutomaticApplicatio
nShutdown 177, 247,
274, 488
DisableBrowse 488
DisableFlyWeightPatching
488
177, 301, 488
DisableLUAPatching 220,
488
DisableMedia 490
DisableMsi 44
DisableMSI 206, 488
DisablePatch 488
DisablePatchUninstall 458,
488
DisableRollback 342, 351,
359, 489, 490
322, 462, 489
DisableUserInstalls 489
EnableAdminTSRemote 489
EnableInstallerDetection
188
EnableUserControl 44, 489
EnableVirtualization 200
EnforceUpgradeComponent
Rules 421, 489
FilterAdministratorToken
195
LimitSystemRestoreCheckp
ointing 489
Logging 489
MaxPatchCacheSize 489
322, 405, 489
PromptOnSecureDesktop
193
SafeForScripting 490
SearchOrder 490
TransformsAtSource 491
TransformsSecure 490
Systemvoraussetzungen 328
Systemzugriffssteuerungsliste
182, 468
T
Temporre Komponente 48
Tools
bmg.exe 333
candle.exe 85, 94, 103
dark.exe 94, 100
dfview.exe 427
heat.exe 94, 97
iexpress.exe 423
light.exe 85, 94, 104, 477
link.exe 237, 311
lit.exe 94, 108
makecab.exe 26, 446
MakeSfxCA.exe 165
melt.exe 94, 101
movefile.exe 256
msbuild.exe 76, 328, 477
msidb.exe 24
msiexec.exe 33
msiinfo.exe 24, 213
msimsp.exe 112, 434, 437
msitran.exe 110
mt.exe 190
muirct.exe 312
patchwiz.dll 112, 437
pendmoves.exe 256
psexec.exe 203
pyro.exe 94, 112
rc.exe 237
reg.exe 198
regsvr32.exe 245
rmtool.exe 265
schtasks.exe 250
SfxCA.dll 165
sigcheck.exe 191
signcode.exe 218
signtool.exe 218
smoke.exe 94, 107
torch.exe 94, 109
whoami.exe 187
wilogutl.exe 307
wixcop.exe 94, 96
Top-Level-Aktionen Siehe
Transaktion 468
507
Transaktionalitt 16
Transaktionen 338
ACID 338
Algorithmus 350
Anwendungsszenarien 411
Commit 339
Computerneustart 362
Installationsprozesse 339
Integrierte
MsiBeginTransaction() 346
MsiEndTransaction() 347
MsiJoinTransaction() 348
Paketbergreifende
Transaktion 468
Paketbergreifenden
Transaktionen 344
Paketbergreifender
Rollback 344
Programmierung 346
Rollback 339
Rollbackskript 342
Windows Installer 4.5 343
Transformation 468
Transformationen
Instanztransformationen 43
Kompatibilittstransformati
onen 43
Patchtransformationen 43
Sprachtransformationen 43
Troubleshooting
ActionState 47
Debugging-Informationen
301
EEUI 405
End 51
ERROR_PATCH_TARGET_NO
T_FOUND 429
ERROR_ROLLBACK_DISABLE
D 359
Fehlersuche 305
Installationsprotokoll 298,
373
InstallState 47
Operationsanweisungen
303
Property(N) 324
Protokollargumente 298
Protokollerstellung 301
508
Protokollierung 468
RegOpenKey 142
RequestState 47
Rckgabewerte 69, 303
Running Script 51
Selbstregistrierung 245
Skriptausfhrung 303
Skripterstellung 303
Statusinformationen 48
Switching to server 40, 302
WIN64DUALFOLDERS 141
297
XML-Format 250
U
UAC-Token Siehe Gefilterter
Token
Umgebungsvariable 61
User Account Control Siehe
V
Validierung 469
ICE100 322
ICE38 493
ICE39 322
ICE57 213
ICE72 353
ICE86 228
ICE92 322
ICE-Validierung 105
Internal Consistency
Evaluators 107
Interne Konsistenz 107
Stringpool 24
Verbunddokument 469, Siehe
Versionierungsregel 476
Verwaiste Komponenten 455
Verwaltete Installationen 204,
469
Verzeichnisstruktur 80
Verzgerte Ausfhrung Siehe
Benutzerdefinierte
Aktionen
Virtualisierung 197
Virtuelle Komponente 48
Visual Studio 2008 472
Visual Studio Team Foundation
Server 76, 83
W
Wartungsinstallation Siehe
Installationsarten
Wartungsmodus Siehe
Installationsarten
Wiederherstellungspunktes
52
Windows 7 210
Windows File Protection Siehe
Windows-Dateischutz
Windows Installer
AKID-Eigenschaften 339
Transaktionalitt 339
Kompatibilitt 224
Versionen 177
Optimierungen 450
Transaktionen 343
Versionen 321
Windows Installer-Datenbank
Siehe Datenbank
Windows Installer-Debugger
2008 471
Windows Installer-Paket 17
64-Bit-Paket 135
Aktivierungspunkte 29, 492
Autorisierung 202
Codepage 23
29
Feature 467
Features 30
Kabinettdateien 26, 429,
473
Komponente 467
Komponenten 29, 473
Limitierungen 473
Logische Betrachtung 28
Logischer Zusammenhang
422
Mikro-Pakete 323
Physische Betrachtung 17
Produkt 31
Ressourcen 25, 29
Schlsselressourcen 492
Streams 157
Summary Information
Stream 20, 78, 132, 153
UAC-Konformitt 212
Verbunddokument 17
Windows InstallerDatenbank 21
Windows Installer-SDK 470
Windows Installer-Service
Siehe Installationsprozess
471
Windows Installer-Technologie
16
Windows Installer-XML 469,
470, 476
Bedingung 85
Benutzerdefinierte
Variablen 84
Deklarationssprache 78
Dekompilieren 100
Dokumentenstruktur 77
117
Fragment 91
Includedateien 84
Installation 74
IntelliSense 75
Iteration 85
Kompilieren 103
Konvertierung 96, 102
Linken 103
Lizenz 72
Lokalisierte
Installationspakete 88
Modularitt 93
Prprozessor-Elemente 83
Prprozessor-Variablen 87
Projekteinstellungen 85
Quellcodefrbung 75
Sprachmerkmale 77
Systemvariablen 84
Tabellennamen 478
Umgebungsvariablen 84
Verweise 86
Visual Studio 75
WiXVariable 85
Windows Management
Instrumentation 203
470
Windows Presentation
Foundation 368
Windows Ressource
Protection Siehe WindowsRessourcenschutz
Windows Scripting Host 63
Windows Server 2003 318,
320
Windows Server 2008 176,
233, 260, 293, 310, 320
Windows Vista 176, 233, 260,
293, 310, 320
Windows XP 318, 320
Windows-Dateischutz 293
Windows-On-Windows 64-Bit
Siehe WOW64-Subsystem
293
Funktionsweise 294
TrustedInstaller 294
WIXPROJ-Datei 477
WIX-Sprachmerkmale
BinaryRef 92
Component 80
ComponentGroupRef 81,
92
ComponentRef 81, 92
Control 120
CustomAction 146, 464
CustomActionRef 92
define 84
Dialog 120
DialogRef 92
DirectoryRef 92
DirectorySearchRef 92
DisableRegistryReflection
142
EmbeddedChainer 356
EmbeddedChainerRef 92
EmbeddedUI 396
FeatureGroupRef 92
FeatureRef 92
File 80
FileSearchRef 92
FileShare 129
FileSharePermission 129
Fragment 78, 92
Group 127
GroupRef 127
IconRef 92
InstallPrivileges 78
Media 80, 115
MergeRef 92
Module 78
Package 134, 214
Patch 78
PatchBaseline 115
PatchCreation 78, 436
PatchFamily 114
PatchFamilyRef 92
PatchSequence 436
Platform 134
Product 78, 418
PropertyRef 92
RegistrySearchRef 92
UI 120
UIRef 92, 121
User 126
Win64 140
WixLocalization 88
WixUI_Advanced 121
WixUI_ErrorProgressText
121
WIXUI_EXITDIALOGOPTION
ALCHECKBOXTEXT 300
WixUI_FeatureTree 121
WixUI_InstallDir 121
WixUI_Minimal 121
WixUI_Mondo 121
WixUIBannerBmp 122
WixUIDialogBmp 122
WixUIExclamationIco 122
WixUIInfoIco 122
WixUILicenseRtf 122
WixUINewIco 122
WixUIUpIco 122
WOW64-Subsystem Siehe 64Bit-Architektur
X
XAML 368
509
XML-Dokument 73
Z
Zertifizierungsrichtlinien 298,
325
Zugriffssteuerlisten 56, 469
Zugriffssteuerungseintrag 181
Zugriffstoken Siehe Sicherheit
Zuverlssigkeits- und
Leistungsberwachung 252
510
Der Autor
Andreas Kerl
Andreas Kerl ist Senior Consultant im Premier Support for
Developers der Microsoft Deutschland GmbH. Zu seinem
Verantwortungsbereich gehrt die Konzeptionierung, Beratung
und Portierung von kommerziellen Kundenanwendungen auf
die Microsoft .NET Plattform. Er ist Spezialist fr die Windows
Installer-Technologie seit der Version 1.0 und betreut Kunden
im gesamten deutschsprachigen Raum zu diesem Thema.
Auerdem fhrt Andreas Kerl technische Trainings fr
Systemadministratoren und Softwareentwickler durch und
spricht auf fachspezifischen Konferenzen. Als Autor ist er durch
Inside Windows Installer und Windows Installer 3.1, sowie
mehreren verffentlichten Artikeln in Fachzeitschriften bekannt.
511

MSI: Inside Windows Installer

Hochgeladen von

Dokumentinformationen

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

MSI: Inside Windows Installer

Hochgeladen von

Copyright:

Verfügbare Formate

Inhaltsverzeichnis

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Fr Werner und Bernd.

Fr wen ist dieses Buch gedacht?

Persnliche Ausfertigung fr Martin Martinsson

Fr wen ist dieses Buch gedacht?

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

Grundlagen der Windows InstallerTechnologie

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

Windows Installer 1.0

Enthalten in Office 2000 und verffentlicht als

Windows Installer 1.1

Enthalten in Windows 2000.

Verffentlicht als Installationspaket.

Enthalten in Windows 2000 Service Pack 1.

Enthalten in Windows 2000 Service Pack 2.

Enthalten in Windows Millennium Edition.

Verffentlicht als Installationspaket.

Enthalten in Windows XP.

Enthalten im Windows 2000 Service Pack 3.

Verffentlicht als Installationspaket.

Enthalten in Windows XP Service Pack 1.

Enthalten im Windows 2000 Service Pack 4.

Enthalten in Windows Server 2003.

Windows Installer 3.0

Enthalten in Windows XP Service Pack 2 und verffentlicht

Windows Installer 3.1

Verffentlicht als Installationspaket.

Enthalten in Windows Server 2003 Service Pack 1.

Verffentlicht als Installationspaket. Behebt den in Q898628

Enthalten in Windows Vista.

Enthalten in Windows Vista Service Pack 1 und Windows

Verffentlicht als Installationspaket fr Windows Vista.

Verffentlicht als Installationspaket fr Windows Vista

Windows Installer 1.11

Windows Installer 1.2

Windows Installer 2.0

Windows Installer 4.0

Windows Installer 4.5

Tabelle 1.1: Verfgbare Versionen des Windows Installers

Grundlagen der Windows Installer-Technologie

Aktion, die vom Windows Installer zur Modifikation des Systems

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

Aufbau und Struktur des Installationspaketes

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

dieses Format zum Speichern der Informationen.

Listing 1.1: Bestimmung der Art eines Verbunddokumentes

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

Word Dokument (97 2003)

Excel Workbook (97 2003)

Powerpoint Prsentation (97 2003)

Windows Installer-Paket (.msi)