Sie sind auf Seite 1von 511

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
Benutzerdefinierte Aktionen
Interne Ablufe
Erstellen einer benutzerdefinierten Aktion
Optimierung des Erstellungsvorgangs
Debuggen
Erweiterte Implementierungen
Fazit
5. Benutzerkontensteuerung in Windows Vista und Windows Server 2008

Persnliche Ausfertigung fr Martin Martinsson

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
Benutzerdefinierte Aktionen
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
Benutzerdefinierte Aktionen

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

Persnliche Ausfertigung fr Martin Martinsson

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
berblick ber den Windows Installer 4.5
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

Persnliche Ausfertigung fr Martin Martinsson

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
Beschreibung der Funktionen
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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

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

Fr wen ist dieses Buch gedacht?


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

Persnliche Ausfertigung fr Martin Martinsson

Einleitung
Installationsprozess einfacher und effektiver gestalten.

Fr wen ist dieses Buch gedacht?


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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

Teil A
Allgemeines zum
Windows Installer

Kapitel 1

Grundlagen der Windows Installer-Technologie

Grundlagen der Windows InstallerTechnologie

berblick
Aufbau und Struktur des Installationspaketes
Installationsarten und Installationsphasen
Analyse des Installationsprozesses
Individuelle Erweiterungen
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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

Kapitel 1

Release

Version

Anmerkungen

Windows Installer 1.0

1.0.5104.0

Enthalten in Office 2000 und verffentlicht als


Installationspaket.

Windows Installer 1.1

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

Verffentlicht als Installationspaket.

2.0.2600.0

Enthalten in Windows XP.

2.0.2600.1

Enthalten im Windows 2000 Service Pack 3.

2.0.2600.2

Verffentlicht als Installationspaket.

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.

Windows Installer 3.0

3.0.3790.2180

Enthalten in Windows XP Service Pack 2 und verffentlicht


als Installationspaket.

Windows Installer 3.1

3.1.4000.1823

Verffentlicht als Installationspaket.

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.

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

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
Persnliche Ausfertigung fr Martin Martinsson

15

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Aufbau und Struktur des Installationspaketes


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

Persnliche Ausfertigung fr Martin Martinsson

17

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Persnliche Ausfertigung fr Martin Martinsson

19

Kapitel 1

Grundlagen der Windows Installer-Technologie

Abbildung 1.2: Interne Struktur eines Windows Installer-Paketes

Summary Information Stream


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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

21

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

23

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

25

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

27

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

29

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

31

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Installationsarten und Installationsphasen


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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

33

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.
Persnliche Ausfertigung fr Martin Martinsson

35

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Administrative Installation
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

Persnliche Ausfertigung fr Martin Martinsson

37

Kapitel 1

Grundlagen der Windows Installer-Technologie

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.

Angekndigte Installation
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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

39

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Analyse des Installationsprozesses


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.

Persnliche Ausfertigung fr Martin Martinsson

41

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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\

Persnliche Ausfertigung fr Martin Martinsson

45

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

47

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Persnliche Ausfertigung fr Martin Martinsson

49

Kapitel 1

Grundlagen der Windows Installer-Technologie

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
Registrierungsschlssel
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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

51

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

53

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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,)

Persnliche Ausfertigung fr Martin Martinsson

55

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Benutzerdefinierte Aktion mit


verzgerter Ausfhrung die nur
beim Commit ausgefhrt wird.

Action, ActionType, Source, Target,


CustomActionData

CustomActionRollback

Benutzerdefinierte Aktion mit


verzgerter Ausfhrung, die nur
beim Rollback ausgefhrt wird.

Action, ActionType, Source, Target,


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

Persnliche Ausfertigung fr Martin Martinsson

57

Kapitel 1

Grundlagen der Windows Installer-Technologie

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.

Individuelle Erweiterungen
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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Persnliche Ausfertigung fr Martin Martinsson

59

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Persnliche Ausfertigung fr Martin Martinsson

61

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

63

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

65

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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
Persnliche Ausfertigung fr Martin Martinsson

67

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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

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 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

Persnliche Ausfertigung fr Martin Martinsson

69

Kapitel 1

Grundlagen der Windows Installer-Technologie

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

Persnliche Ausfertigung fr Martin Martinsson

Grundlagen der Windows Installer-Technologie

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.

Persnliche Ausfertigung fr Martin Martinsson

71

Kapitel 2

Windows Installer-XML

Windows Installer-XML

Installation und Integration


Dokumentenstruktur und Sprachmerkmale
Modularitt und Zusammenspiel
Erweiterungsbibliotheken
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.

Installation und Integration


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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

73

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Persnliche Ausfertigung fr Martin Martinsson

75

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Dokumentenstruktur und Sprachmerkmale


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
Persnliche Ausfertigung fr Martin Martinsson

77

Kapitel 2

Windows Installer-XML

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">
<!-- Produktdefinition -->
<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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

Kapitel 2

<!-- Definition des Summary Information Streams -->


<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" />
<!-- Eigenschaften und Bedingungen -->
<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 fr Dateiverknpfung -->
<Icon Id="AdminIcon.exe" SourceFile="..\Binaries\Admin.ico.exe" />
<!-- Ordner, Komponenten und Dateien -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="MSI Demo">
<!-- Anwendung -->
<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>
<!-- Bibliothek -->
<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>
<!-- Definition der Feature-Struktur -->
<Feature Id="Application" Title="Anwendung" Display="expand" Level="3">
<ComponentRef Id="Admin.exe" />
<ComponentRef Id="Forms.Vista.dll" />
</Feature>
<!-- Festlegen des Mediums -->
<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />

Persnliche Ausfertigung fr Martin Martinsson

79

Kapitel 2

Windows Installer-XML

</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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Persnliche Ausfertigung fr Martin Martinsson

81

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Windows Installer-XML

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"?>

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.
<!-- WIX-Varible, die per Kommandozeile von light.exe berschrieben werden kann -->
<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:

Persnliche Ausfertigung fr Martin Martinsson

85

Kapitel 2

Windows Installer-XML

<?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:
<!-- Falls Debug die Symboldatei einbinden -->
<?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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

87

Kapitel 2

Windows Installer-XML

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.

Lokalisierte Installationspakete
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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.
<?xml version="1.0" encoding="utf-8"?>
<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.
<?xml version="1.0" encoding="utf-8"?>
<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.
<?xml version="1.0" ?>
<!-- Konfigurationsinformationen einbinden -->
<?include Config.wxi ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!-- Produktdefinition -->

Persnliche Ausfertigung fr Martin Martinsson

89

Kapitel 2

Windows Installer-XML

<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">
<!-- Definition des Summary Information Streams -->
<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" />
<!-- Eigenschaften und Bedingungen -->
<Condition Message="!(loc.FrameworkExist)">MsiNetAssemblySupport</Condition>
<!-- Icon fr Dateiverkpfung -->
<Icon Id="AppIcon.exe" SourceFile="$(var.SourceFolder)AppIcon.exe" />
<!-- Ordner, Komponenten und Dateien -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<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>
<!-- Definition der Featurestruktur -->
<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>
<!-- Festlegen des Mediums -->
<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
</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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Persnliche Ausfertigung fr Martin Martinsson

91

Kapitel 2

Windows Installer-XML

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.
<?xml version="1.0" encoding="windows-1252"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!-- Definition des Produktes -->
<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">
<!-- Paketdefinition -->
<Package Keywords="Microsoft Windows Installer, MSI" Description="MSI-Test 1.0"
Manufacturer="Andreas Kerl" InstallerVersion="200" Platform="x86" Languages="1031"
Compressed="yes" SummaryCodepage="1252" />
<!-- Ordner, Komponenten und Ressourcen -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="MSI-Test 1.0">
</Directory>
</Directory>
</Directory>
<!-- Definition der Featurestruktur -->
<Feature Id="Application" Title="Anwendung" Description="Installiert die Anwendung" Level="1">
<FeatureRef Id="SubApplication"/>
</Feature>
<!-- Medien -->
<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
</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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<!--Zielverzeichnis, Komponenten und Dateien-->
<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>
<!--Zuordnung zu Features-->
<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

Modularitt und Zusammenspiel


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

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Persnliche Ausfertigung fr Martin Martinsson

95

Kapitel 2

Windows Installer-XML

.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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

97

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<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>

Persnliche Ausfertigung fr Martin Martinsson

99

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

101

Kapitel 2

Windows Installer-XML

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

Die Anzeige des Logos der Anwendung wird unterdrckt.

-notidy

Die temporren Dateien werden nicht gelscht. Diese Option ist beim Debugging hilfreich.

-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


(Beispiel: -wx1059 -wx1067)

-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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

Kapitel 2

wird. Zu erkennen sind hierbei sehr gut die Identifizierungsmerkmale des Mergemoduls, die jedoch im
Rahmen der Konvertierung angepasst werden knnen.
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<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
Persnliche Ausfertigung fr Martin Martinsson

103

Kapitel 2

Windows Installer-XML

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

Die Anzeige des Logos der Anwendung wird unterdrckt.

-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]

Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1009 -sw1103)

-trace

Bei Fehlern, Warnungen und zustzlichen Informationen wird die exakte Position
der Problemquelle im WXS-Dokument ausgegeben.

-v

Gibt zustzliche Informationen mit aus.

-wx[N]

Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert


(Beispiel: -wx1009 -wx1103)

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Hiermit kann eine zustzliche Erweiterungs-Bibliothek angegeben werden.

-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

Persnliche Ausfertigung fr Martin Martinsson

105

Kapitel 2

Windows Installer-XML
werden.

-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 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

Die berprfung auf Basis des Schemas wird bersprungen (Performancegewinn).

-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]

Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1009 -sw1103)

-v

Gibt zustzliche Informationen mit aus.

-wx[N]

Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert


(Beispiel: -wx1009 -wx1103)

-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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Hiermit kann eine zustzliche Erweiterungs-Bibliothek angegeben werden.

-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

Die Anzeige des Logos der Anwendung wird unterdrckt.

-notidy

Die temporren Dateien werden nicht gelscht. Diese Option ist beim Debugging
hilfreich.

-pdb

Pfad zu den korrespondierenden PDB-Dateien.

-sice:<ICE>

Die Ausfhrung der Prfroutine wird unterbunden.

-sw[N]

Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1011 -sw1012)

-v

Gibt zustzliche Informationen, sowie die gerade durchgefhrte Validierungsart aus.

-wx[N]

Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert


(Beispiel: -wx1011 -wx1012)

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

Persnliche Ausfertigung fr Martin Martinsson

107

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

Kapitel 2

-ext

Hiermit kann eine zustzliche Erweiterungs-Bibliothek angegeben werden.

-loc <loc.wxl>

Festlegen eines WXL-Dokumentes, aus dem lokalisierte Zeichenfolgen verwendet


werden.

-nologo

Die Anzeige des Logos der Anwendung wird unterdrckt.

-o[ut]

Festlegen einer Ausgabedatei. Standardmig verwendet light.exe das aktuelle


Verzeichnis.

-pedantic

Wie beim Linken erfolgt hierdurch eine genauere Prfung der Quelldateien.

-ss

Die berprfung auf Basis des Schemas wird bersprungen (Performancegewinn).

-sv

Die berprfung auf abweichende Dateiversionen wird nicht ausgefhrt.

-sw[N]

Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1009 -sw1103)

-v

Gibt zustzliche Informationen mit aus.

-wx[N]

Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert


(Beispiel: -wx1009 -wx1103)

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.

Persnliche Ausfertigung fr Martin Martinsson

109

Kapitel 2

Windows Installer-XML

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.
<?xml version="1.0" encoding="utf-8"?>
<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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Hiermit kann eine zustzliche Erweiterungs-Bibliothek angegeben werden.

-nologo

Die Anzeige des Logos der Anwendung wird unterdrckt.

-notidy

Die temporren Dateien werden nicht gelscht. Diese Option ist beim Debugging
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)

Persnliche Ausfertigung fr Martin Martinsson

111

Kapitel 2

Windows Installer-XML

-t <Typ>

Ermglicht die automatische Zuordnung von Validierungsbedingungen, die vom Typ der
Transformation abhngig sind. Mgliche Typen sind language, instance, patch.

-v

Gibt zustzliche Informationen mit aus.

-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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.
<!-- Icons fr Shortcuts -->
<Icon Id="I__Colors.exe" SourceFile=".\$(var.Version)\Colors.ico" />
<!-- Ordner, Komponenten und Ressourcen -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="Colors">
<Component Id="C__Colors.exe" Guid="1ACC3C89-9E07-418a-B4DD-9D1DA89C3E4F">
<!--Datei-->
<File Id="F__Colors.exe" Source=".\$(var.Version)\" Name="Colors.exe" KeyPath="yes" DiskId="1" />
<!--Shortcut-->
<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 Id="DesktopFolder" />
</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.
Persnliche Ausfertigung fr Martin Martinsson

113

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<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-->
<Media Id="1" Cabinet="RTM.cab">
<PatchBaseline Id="RTM">
<Validate IgnoreAddExistingRow="yes" IgnoreAddExistingTable ="yes" ProductId ="yes"
ProductVersion ="Update" ProductVersionOperator ="LesserOrEqual"/>
</PatchBaseline>
</Media>
<!-- PatchSequence -->
<PatchFamily Id="RM" Version ="1.0.0.100" Supersede="no">
<IconRef Id="I__Colors.exe"/>
<ComponentRef Id="C__Colors.exe"/>
</PatchFamily>
<!-- Eigenschaften -->
<PatchProperty Name="MinimumRequiredMsiVersion" Value="300"/>
<PatchProperty Name="TrustMSI" Value="1"/>
<PatchProperty Name="AllowLaxValidateFlags" Value ="0"/>
<!--Optimierung von benutzerdefinierten Aktionen-->
<OptimizeCustomActions SkipAssignment="yes" SkipDeferred="yes" SkipImmediate="yes" />
</Patch>
</Wix>

Persnliche Ausfertigung fr Martin Martinsson

115

Kapitel 2

Windows Installer-XML

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

Hiermit kann eine zustzliche Erweiterungs-Bibliothek angegeben werden.

-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 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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

Kapitel 2

-spdb

Es werden keine WIXPDB-Dateien erstellt.

-sw[N]

Es werden alle oder bestimmte Warnungen unterdrckt (Beispiel: -sw1009 -sw1103)

-t Baseline

Festlegen der zu verwendenden Transformationen und Definition der Baseline.

-v

Gibt zustzliche Informationen mit aus.

-wx[N]

Es werden alle oder nur bestimmte Warnungen als Fehler interpretiert


(Beispiel: -wx1009 -wx1103)

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.

Erweiterungsbibliotheken
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.

Persnliche Ausfertigung fr Martin Martinsson

117

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

119

Kapitel 2

Windows Installer-XML

{
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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Persnliche Ausfertigung fr Martin Martinsson

121

Kapitel 2

Windows Installer-XML

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.
<!-- UI Definition -->
<UIRef Id="WixUI_InstallDir" />
<UIRef Id="WixUI_ErrorProgressText" />
<!--Installationsverzeichnis vernderbar gestalten-->
<Property Id="WIXUI_INSTALLDIR" Value="APPLICATIONFOLDER" />
<!--Individuelle Bitmaps verwenden-->
<WixVariable Id="WixUIBannerBmp" Value=".\Banner.jpg" />
<WixVariable Id="WixUIDialogBmp" Value=".\Dialog.jpg" />
<!--Lizenzbestimmungen festlegen-->
<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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.
<?xml version="1.0" encoding="windows-1252"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" >
<!-- Definition des Produktes -->
<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">
<!-- Paketdefinition -->
<Package Description=" WiXQueryOS" Manufacturer="Andreas Kerl" InstallerVersion="200"
Platform="x86" Languages="1031" Compressed="yes" SummaryCodepage="1252" />
<!--WixQueryOsInfo-Eigenschaften und Order-->
<PropertyRef Id="WIX_SUITE_MEDIACENTER" />
<PropertyRef Id="WIX_DIR_MYVIDEO" />
<!-- Systemvoraussetzung -->
<Condition Message="Windows Media Center Edition wird bentigt.">WIX_SUITE_MEDIACENTER</Condition>

Persnliche Ausfertigung fr Martin Martinsson

123

Kapitel 2

Windows Installer-XML

<!-- Ordner, Komponenten und Ressourcen -->


<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<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>
<!-- Definition der Featurestruktur -->
<Feature Id="Application" Title="Anwendung" Level="1">
<ComponentRef Id="C__Video" />
</Feature>
<!-- Medien -->
<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
<!-- UI Definition -->
<Property Id="WIXUI_INSTALLDIR" Value="WIX_DIR_MYVIDEO" />
<UIRef Id="WixUI_InstallDir" />
<UIRef Id="WixUI_ErrorProgressText" />
</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.
<?xml version="1.0" encoding="windows-1252"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" >
<!-- Definition des Produktes -->
<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">
<!-- Paketdefinition -->
<Package Description="WixVSExtension" Manufacturer="Andreas Kerl" InstallerVersion="200"
Platform="x86" Languages="1031" Compressed="yes" SummaryCodepage="1252" />

124

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

Kapitel 2

<!--WixVSExtension-Eigenschaften-->
<PropertyRef Id="VS90_SCHEMAS_DIR" />
<PropertyRef Id="VS90DEVENV" />
<PropertyRef Id="VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED" />
<!-- Systemvoraussetzung -->
<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>
<!-- Ordner, Komponenten und Ressourcen -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<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>
<!-- Definition der Featurestruktur -->
<Feature Id="Application" Title="Anwendung" Level="1">
<ComponentRef Id="C__Schema" />
</Feature>
<!-- Medien -->
<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
<!-- UI Definition -->
<Property Id="WIXUI_INSTALLDIR" Value="VS90_SCHEMAS_DIR" />
<UIRef Id="WixUI_InstallDir" />
<UIRef Id="WixUI_ErrorProgressText" />
</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

Persnliche Ausfertigung fr Martin Martinsson

125

Kapitel 2

Windows Installer-XML

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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">
<!-- Definition des Produktes -->
<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}">
<!-- Paketdefinition -->
<Package Description="WiXAccount" Manufacturer="Andreas Kerl" InstallerVersion="200"
Platform="x86" Languages="1031" Compressed="yes" SummaryCodepage="1252" />
<!-- Passwort sollte ber die Befehlszeile oder UI angegeben werden -->
<Property Id="PASSWORD" Value="ABCDE*1" Secure="yes" Hidden="yes"/>
<Property Id="ACCOUNTNAME" Value="WIXUser" Secure="yes"/>
<!-- Gruppen -->
<util:Group Id="UserGroup" Name="Users" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<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" />
<!-- Hinzufgen oder aktualisieren des Benutzers -->
<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>
<!-- Definition der Featurestruktur -->
<Feature Id="Application" Title="Anwendung" Level="1">
<ComponentRef Id="C__Account" />
</Feature>

Persnliche Ausfertigung fr Martin Martinsson

127

Kapitel 2

Windows Installer-XML

<!-- Medien -->


<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
<!-- UI Definition -->
<UIRef Id="WixUI_Minimal" />
<UIRef Id="WixUI_ErrorProgressText" />
</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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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">
<!-- Definition des Produktes -->
<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}">
<!-- Paketdefinition -->
<Package Description="WiXFileShare" Manufacturer="Andreas Kerl" InstallerVersion="200"
Platform="x86" Languages="1031" Compressed="yes" SummaryCodepage="1252" />
<PropertyRef Id="WIX_ACCOUNT_USERS" />
<PropertyRef Id="WIX_ACCOUNT_ADMINISTRATORS" />
<!-- Benutzergruppen -->
<util:User Id="USERS" Name="[WIX_ACCOUNT_USERS]" />
<util:User Id="ADMINS" Name="[WIX_ACCOUNT_ADMINISTRATORS]"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<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" />
<!--Netzwerkfreigabe einrichten-->
<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>
<!-- Definition der Featurestruktur -->
<Feature Id="Application" Title="Anwendung" Level="1">
<ComponentRef Id="C__Share" />
</Feature>
<!-- Medien -->

Persnliche Ausfertigung fr Martin Martinsson

129

Kapitel 2

Windows Installer-XML

<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />


<!-- UI Definition -->
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" />
<UIRef Id="WixUI_InstallDir" />
<UIRef Id="WixUI_ErrorProgressText" />
</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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer-XML

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.

Persnliche Ausfertigung fr Martin Martinsson

131

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

Windows Installer und 64-BitBetriebssysteme

Architekturen
Dateisystem und Systemregistrierung
Benutzerdefinierte Aktionen
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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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
Persnliche Ausfertigung fr Martin Martinsson

133

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!-- Definition des Produktes -->
<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">
<!-- Paketdefinition -->
<Package Keywords="Microsoft Windows Installer, MSI" Description="Football 2008"
Manufacturer="Andreas Kerl" InstallerVersion="200" Platform="x64" Languages="1033"
Compressed="yes" SummaryCodepage="1252" InstallPrivileges="elevated" />
<!-- Weitere Daten -->
</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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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

Windows Installer-XML

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?

Persnliche Ausfertigung fr Martin Martinsson

135

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

Dateisystem und Systemregistrierung


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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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.

Persnliche Ausfertigung fr Martin Martinsson

137

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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
Persnliche Ausfertigung fr Martin Martinsson

139

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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

32-Bit-Paket auf x64


Plattform

64-Bit-Paket auf x64


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\

C:\Program Files (x86)\

C:\Program Files (x86)\

System64Folder

Null

C:\Windows\SysWOW64\

C:\Windows\system32\

SystemFolder

C:\Windows\system32\

C:\Windows\SysWOW64\

C:\Windows\SysWOW64\

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

Persnliche Ausfertigung fr Martin Martinsson

141

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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.

Persnliche Ausfertigung fr Martin Martinsson

143

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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.

Benutzerdefinierte Aktionen
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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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.

Persnliche Ausfertigung fr Martin Martinsson

145

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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.
<!--Visual Basic-Skript verwenden-->
<Binary Id="VBScript" SourceFile=".\Binaries\GetInfos.vbs" />
<!--Definition der benutzerdefinierten Aktion-->
<CustomAction Id="CheckEnvironment" BinaryKey="VBScript" VBScriptCall="Main"
Win64="yes" Execute="immediate"/>
<!--Einordnung in die Ausfhrungssequenz-->
<InstallExecuteSequence>
<Custom Action="CheckEnvironment" Before="LaunchConditions"/>
</InstallExecuteSequence>

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

Persnliche Ausfertigung fr Martin Martinsson

Windows Installer und 64-Bit-Betriebssysteme

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-

Persnliche Ausfertigung fr Martin Martinsson

147

Kapitel 3

Windows Installer und 64-Bit-Betriebssysteme

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

Kapitel 4

Deployment Tools Foundation

Allgemeine Informationen
Struktur und Objektmodell
Benutzerdefinierte Aktionen
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.

Allgemeine Informationen
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.

Persnliche Ausfertigung fr Martin Martinsson

149

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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

Struktur und Objektmodell


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

Persnliche Ausfertigung fr Martin Martinsson

151

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.

Persnliche Ausfertigung fr Martin Martinsson

153

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

155

Kapitel 4

Deployment Tools Foundation


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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

157

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.

Persnliche Ausfertigung fr Martin Martinsson

159

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.

Benutzerdefinierte Aktionen
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

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.

Persnliche Ausfertigung fr Martin Martinsson

163

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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
Microsoft.Deployment.WindowsInstaller.dll
Natrlich sind die Pfade noch entsprechend anzupassen. Das Tool MakeSfxCA.exe und die Datei
Microsoft.Deployment.WindowsInstaller.dll
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.

Persnliche Ausfertigung fr Martin Martinsson

165

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.
<!--Datei in den Binrstream intrgrieren-->
<Binary Id="CADLL" SourceFile="$(var.CAFilePath.TargetDir)$(var.CAFilePath.TargetName).CA.dll"/>

Persnliche Ausfertigung fr Martin Martinsson

167

Kapitel 4

Deployment Tools Foundation

<!--Definition der benutzerdefinierten Aktion-->


<CustomAction Id="SetTargetPath" BinaryKey="CADLL" DllEntry="SetTargetPath"

Execute="firstSequence"/>

<!--Referenzieren von der InstallUISequence-Tabelle-->


<InstallUISequence>
<Custom Action="SetTargetPath" Before="CostFinalize"/>
</InstallUISequence>
<!--Referenzieren von der InstallExecuteSequence-Tabelle-->
<InstallExecuteSequence>
<Custom Action="SetTargetPath" Before="CostFinalize"/>
</InstallExecuteSequence>

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.
Persnliche Ausfertigung fr Martin Martinsson

169

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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
Persnliche Ausfertigung fr Martin Martinsson

171

Kapitel 4

Deployment Tools Foundation

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
return ActionResult.Success;
}
}

Listing 4.42: Verwalten von Benutzerkonten durch benutzerdefinierte Aktionen

172

Persnliche Ausfertigung fr Martin Martinsson

Deployment Tools Foundation

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.
<!-- Passwort sollte ber die Befehlszeile oder UI angegeben werden -->
<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"/>
<!--Objektbibliothek dem Binr-Stream anfgen-->
<Binary Id="CADLL" SourceFile="$(var.ManageUsers.TargetDir)$(var.ManageUsers.TargetName).CA.dll"/>
<!--Benutzerdefinierte Aktionen-->
<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" />
<!--Einordnen in die Sequenztabelle-->
<InstallExecuteSequence>
<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>
</InstallExecuteSequence>

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

Persnliche Ausfertigung fr Martin Martinsson

173

Kapitel 4

Deployment Tools Foundation

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

Persnliche Ausfertigung fr Martin Martinsson

Teil B
Installationen
unter Windows
Vista und
Windows Server
2008
Persnliche Ausfertigung fr Martin Martinsson

175

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

Benutzerkontensteuerung in Windows
Vista und Windows Server 2008

berblick ber den Windows Installer 4.0


Sicherheit
Anwendungen fr Windows Vista und Windows Server 2008
Installationen in geschtzten Umgebungen
Installationen unter Windows Vista und Windows Server 2008
Kompatibilitt mit lteren Installer-Versionen
Identifizieren von Problemquellen
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.

berblick ber den Windows Installer 4.0


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

Windows Installer 4.0

4.0.6000.16386

Enthalten in Windows Vista.

Windows Installer 4.0

4.0.6001.18000

Enthalten in Windows Server 2008 und Windows Vista SP1.

Tabelle 5.39: Verfgbare Versionen des Windows Installers 4.0

176

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

177

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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.

Persnliche Ausfertigung fr Martin Martinsson

179

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

181

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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 (

Persnliche Ausfertigung fr Martin Martinsson

183

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

185

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

187

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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">

Persnliche Ausfertigung fr Martin Martinsson

189

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

<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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

191

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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,
Persnliche Ausfertigung fr Martin Martinsson

193

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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.

Eingeschrnkter Token

Aufforderung zur Eingabe


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

Anwendung wird mit


Standardprivilegien
ausgefhrt.

Anwendung wird mit


vollstndigen Privilegien
ausgefhrt. Einfacher
Besttigungsdialog wird
angezeigt.

Eingeschrnkter Token

Aufforderung zur Eingabe


der
Anmeldeinformationen
(Prompt for Credentials).

Anwendung wird mit


Standardprivilegien
ausgefhrt.

Anwendung wird mit


vollstndigen Privilegien
ausgefhrt. Erweiterter
Besttigungsdialog wird
angezeigt.

Vollstndiger Token

(Nicht relevant)

Anwendung wird mit


vollstndigen Privilegien
ausgefhrt. Es wird kein
Dialog angezeigt.

Anwendung wird mit


vollstndigen Privilegien
ausgefhrt. Es wird kein
Dialog angezeigt.

Tabelle 5.42: Richtlinie fr den Besttigungsdialog bei Aktionen durch Administratoren


bergeordneter
Prozesstoken

Einstellungen

asInvoker,
highestAvailable oder
kein Manifest

requireAdministrator

Eingeschrnkter Token

Anhebungsaufforderung
automatisch abweisen
(Automatically deny
elevation requests).

Anwendung wird mit


Standardprivilegien
ausgefhrt.

Start der Anwendung


schlgt fehl.
Fehlermeldung Zugriff
verweigert wird
angezeigt.

Eingeschrnkter Token

Aufforderung zur Eingabe


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

Anwendung wird mit


Standardprivilegien
ausgefhrt.

Anwendung wird mit


vollstndigen Privilegien
ausgefhrt. Erweiterter
Besttigungsdialog wird
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

Persnliche Ausfertigung fr Martin Martinsson

195

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

197

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

199

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

Abbildung 5.41: Virtualisierung beim Zugriff auf das Dateisystem und die Systemregistrierung

Installationen in geschtzten Umgebungen


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
Persnliche Ausfertigung fr Martin Martinsson

201

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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();

Persnliche Ausfertigung fr Martin Martinsson

203

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

// 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

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

205

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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.

Persnliche Ausfertigung fr Martin Martinsson

207

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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 dargestellt.

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);

Persnliche Ausfertigung fr Martin Martinsson

209

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

// 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

Persnliche Ausfertigung fr Martin Martinsson

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
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 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.
Persnliche Ausfertigung fr Martin Martinsson

211

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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
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 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

Persnliche Ausfertigung fr Martin Martinsson

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.

Persnliche Ausfertigung fr Martin Martinsson

213

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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.
<?xml version="1.0" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!-- Produktdefinition -->
<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">
<!-- Definition des Summary Information Streams -->
<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" />
<!-- Eigenschaften und Bedingungen -->
<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" />
<!-- Icons fr Shortcuts -->
<Icon Id="AdminIcon.exe" SourceFile="$(var.SourceFolder)Admin.ico.exe" />

214

Persnliche Ausfertigung fr Martin Martinsson

<Icon Id="NonAdminIcon.exe" SourceFile="$(var.SourceFolder)NonAdmin.ico.exe" />


<!-- Ordner, Komponenten und Dateien -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="AppDataFolder">
<Directory Id="INSTALLLOCATION" Name="Vista UAC Non-Admin">
<!-- Anwendung mit administrativen Privilegien -->
<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>
<!-- Anwendung mit Standardprivilegien -->
<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>
<!-- Bibliothek -->
<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"
Assembly=".net" DiskId="1" />
</Component>
</Directory>
</Directory>
<Directory Id="DesktopFolder" />
</Directory>
<!-- Definition der Featurestruktur -->
<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>
<!-- Festlegen des Mediums -->
<Media Id="1" EmbedCab="yes" Cabinet="Data.cab" />
<!-- Patchzertifikat integrieren -->
<PatchCertificates>
<DigitalCertificate Id ="PatchCertificate" SourceFile ="$(var.CertificateFolder)Certificate.cer"/>
</PatchCertificates>

Persnliche Ausfertigung fr Martin Martinsson

215

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

<!-- UI Definition -->


<Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" />
<UIRef Id="WixUI_InstallDir" />
<UIRef Id="WixUI_ErrorProgressText" />
</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

Persnliche Ausfertigung fr Martin Martinsson

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.
Persnliche Ausfertigung fr Martin Martinsson

217

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

219

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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.
Persnliche Ausfertigung fr Martin Martinsson

221

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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
MSIDISABLELUAPATCHING
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

Persnliche Ausfertigung fr Martin Martinsson

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.
Persnliche Ausfertigung fr Martin Martinsson

223

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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.

Kompatibilitt mit lteren Installer-Versionen


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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

225

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008


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

Vollstndiger Pfad zum Ordner Anwendungsdaten fr alle Benutzer.

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

Vollstndiger Pfad zum Ordner Anwendungsdaten fr alle Benutzer.

MyPicturesFolder

Vollstndiger Pfad zum Ordner Eigene Bilder fr den aktuellen Benutzer.

226

Persnliche Ausfertigung fr Martin Martinsson

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.

Benutzerinstallation.
Verwendet Ordner im
Profil des Anwenders.

Administrative Rechte

Benutzerinstallation.
Verwendet Ordner im
Profil des Anwenders.

Computerinstallation.
Verwendet Ordner im
Profil aller Benutzer.

Computerinstallation.
Verwendet Ordner im
Profil aller Benutzer.

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

Benutzerinstallation.
Verwendet Ordner im
Profil des Anwenders.

Nicht mglich. Gibt einen


Fehler zurck, der darauf
hinweist, dass der
Anwender nicht die
bentigten Rechte besitzt.

Nicht mglich. Gibt einen


Fehler zurck, der darauf
hinweist, dass der
Anwender nicht die
bentigten Rechte besitzt.

Kein StandardbenutzerPaket

Benutzerinstallation.
Verwendet Ordner im
Profil des Anwenders.

Computerinstallation.
Verwendet Ordner im
Profil aller Benutzer.

Computerinstallation.
Verwendet Ordner im
Profil aller Benutzer.

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
Persnliche Ausfertigung fr Martin Martinsson

227

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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.
<!--Fehlermeldung definieren-->
<CustomAction Id="CheckPrivilges" Error ="Zur Installation sind erhhte Privilegien erforderlich."/>
<!--Einordnen in die Tabelle der Ausfhrungssequenz-->
<InstallExecuteSequence>
<Custom Action="CheckPrivilges" Before ="LaunchConditions">NOT Privileged</Custom>
</InstallExecuteSequence>

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.
Persnliche Ausfertigung fr Martin Martinsson

229

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Benutzerdefinierte Aktionen
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

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

231

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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:
<!--Definition der benutzerdefinierten Aktion-->
<CustomAction Id="ElevatedAction" DllEntry ="CreateDatabase" Impersonate ="no"
Execute="deferred" BinaryKey ="CADLL" />
<!--Integrieren in die Ausfhrungssequenz-->
<InstallExecuteSequence>
<Custom Action="ElevatedAction" Before ="InstallFinalize" />
</InstallExecuteSequence>

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

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

233

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

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)

Persnliche Ausfertigung fr Martin Martinsson

235

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

{
// 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"/>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

236

Persnliche Ausfertigung fr Martin Martinsson

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.

Persnliche Ausfertigung fr Martin Martinsson

237

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

Identifizieren von Problemquellen


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

Persnliche Ausfertigung fr Martin Martinsson

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.
Persnliche Ausfertigung fr Martin Martinsson

239

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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,
RemoteURTInstalls=0,ProductDeploymentFlags=2)

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

Persnliche Ausfertigung fr Martin Martinsson

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.
Persnliche Ausfertigung fr Martin Martinsson

241

Kapitel 5

Benutzerkontensteuerung in Windows Vista und Windows Server 2008

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

Persnliche Ausfertigung fr Martin Martinsson

Computerneustarts im
Installationsprozess

Ursachen fr einen Computerneustart


Neustarts im Installationsprozess
Funktionsweise des Neustart-Managers
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.

Ursachen fr einen Computerneustart


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.

Persnliche Ausfertigung fr Martin Martinsson

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

Persnliche Ausfertigung fr Martin Martinsson

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.

Neustarts im Installationsprozess
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

Persnliche Ausfertigung fr Martin Martinsson

245

Kapitel 6

Computerneustarts im Installationsprozess

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

Persnliche Ausfertigung fr Martin Martinsson

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:
MSIRESTARTMANAGERCONTROL

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:
DisableAutomaticApplicationShutdown

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

Persnliche Ausfertigung fr Martin Martinsson

247

Kapitel 6

Computerneustarts im Installationsprozess

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

Persnliche Ausfertigung fr Martin Martinsson

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");
}
catch (Exception ex)
{
// 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
Persnliche Ausfertigung fr Martin Martinsson

249

Kapitel 6

Computerneustarts im Installationsprozess

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

Persnliche Ausfertigung fr Martin Martinsson

</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.
Persnliche Ausfertigung fr Martin Martinsson

251

Kapitel 6

Computerneustarts im Installationsprozess

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

Persnliche Ausfertigung fr Martin Martinsson

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
Persnliche Ausfertigung fr Martin Martinsson

253

Kapitel 6

Computerneustarts im Installationsprozess

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