Author Archives: Stefan Hotan

Wise Setup Capture – security restriction

April 6, 2010 12:06 ⋅ Leave a Comment ⋅

Mit der aktuellen Version des Wise Package Studios erscheint ab Windows Vista beim Setup-Capture die Meldung ‘The operating system currently has a security restriction that interferes with Virtual Capture and SmartMonitor’.

Wenn der SmartMonitor und der Virtual Capture nicht verwendet werden, also nur das klassische Snap-Shot Verfahren gebraucht wird, dann kann diese Meldung mit ‘No’ ignoriert werden.
Mit folgendem Registry-Key kann diese Nachricht unterdrückt werden:
[HKCUSoftwareWise SolutionsWindows Installer EditorHideMessages]
“20153”=dword:00000006

Hinter dieser Option steht eine Sicherheitserweiterung, die mit der Vista Version von Windows eingeführt wurde. Wird der Hinweis mit ‘Yes’ beantwortet, so wird folgender Registry-Key geschrieben:
[HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionWindows]
“LoadAppInit_DLLs”=dword:00000001

Die LoadAppInit DLLs ist eine Beriebsystem-Funktion, welche bei jedem Prozess zusätzliche DLL’s ladet. Wise Package Studio verwendet diese Funktion um die Datei HookDll.dll in den Speicher eines jeden Prozesses einzubinden. Damit wird es ermöglicht, einen Installationsprozess zu überwachen und dessen Vorgehen mit SmartMonitor oder VirtualCapture aufzuzeichnen.
HookDll.dll

Posted in: Windows Installer

Class IDs verification Test

March 16, 2010 12:28 ⋅ Leave a Comment ⋅

Dieser Post geht auf den Test Expert ein, welcher mit einer Wise Package Studio Quality Assurance Erweiterung oder mit der Wise Package Studio Suite Edition zur Verfügung steht.
Im Wise Test Expert existiert unter ‘Application Verification Tests’ ein Class IDs  Test Case.  Mit diesem Test Case lassen sich Klassen, also Registry Einträge unter HKCRCLSID automatisch Testen, ohne die Applikation starten und alle Funktionen sowie Unterfunktionen testen zu müssen.

Dieser Test Case unterliegt  der ClassID Tabelle der ausgewählten Applikation und verwendet die CoCreateInstance Funktion um die Funktionalität der Klasse zu verifizieren. Natürlich erhofft man sich bei der Verwendung des Wise Test Expert ein Erfolgs-Resultat von 100%. Die Praxis zeigt uns jedoch, dass bei den Class IDs Tests ein Resultat von 20% schon eine voll funktionierende Applikation ausweissen kann.

Der Grund für diesen Beitrag besteht darin offen zu legen, warum im Test Expert bei den Class IDs Test ein Resultat von 20% schon gut genug sein kann.

Ich habe über die Jahre alle möglichen Resulate aus dem Test Experten analysiert und eine Liste erstellt, worin zu ersehen ist, bei welchen ‘Error Numbers’ eine Installation auf Fehler zu überprüfen ist und bei welchen Nummern die Klasse als funktionsfähig einzustufen ist.

Error Number Error Description Real Error
0x80040154 Class not registered maybe
0x80004002 No such interface supported no
0x80080005 Server execution failed no
0x80004005 Unspecified error no
0x80040111 cannot supply requested class no
0x8007007E The specified module could not be found yes
0x8000FFFF Catastrophic failure no
0x80040112 Class is not licensed for use no

Die Liste zeigt auf, es gibt verschiedene Gründe, warum ein Klassen-Test fehlschlagen kann.

Bei folgenden Fehler-Nummern kann die betroffene Klasse korrigiert werden:

Class not registered: Der Test kann nochmals durchgeführt werden, nach dem die betroffene Klassen-Datei (.DLL oder .OCX) mit dem Programm regsvr32.exe registriert wurde. Sollte nach einem erneuten Test die Klasse erfolgreich gestet werden können, so kann die fehlende Klasse in die Installation eingebaut werden.

The specified module could not be found: Verwenden Sie den Dependency Walker von Microsoft um die fehlende(n) Datei(en) in die Installation einzubauen.

Bei den restlichen Fehlermeldungen liegt fast sicher kein Problem vor, oder dieser lässt sich aus Sicht eines System-Administrator nur sehr selten verbessern.

Zusammenfassend muss ich festhalten, dass ein Klassen-Test mit der CoCreateInstance Funktion keine optimale Lösung ist, um eine verlässliche Aussage treffen zu können, ob eine Klasse wirklich funktioniert. Die Test-Resulate liefern viele Error Codes zurück, obwohl die Applikation funktionieren wird. Schlussendlich hat ein Software Hersteller verschiedene Möglichkeiten eine Klasse  für seine Applikation zu inizialisieren.

Posted in: Best Practices, Tech, Wise Package Studio

REMOVE Kondition – Die Wahrheit

February 25, 2010 15:20 ⋅ Leave a Comment ⋅

Als ich kürzlich den Artikel Test your conditions von Heath Stewart gelesen habe, wusste ich sogleich, dass es nun an der Zeit ist die letzten technischen Details über die REMOVE Kondition preis zu geben.

Wie die REMOVE Kondition optimal eingesetzt wird entscheidet die Feature Struktur eines Produktes. Eine einfache Aussage wie REMOVE~=”ALL” zu verwenden, ist keine gute Idee, da es Situationen gibt, wo diese Kondition nicht greift.

Fact ist, dass die REMOVE Kondition im Falle einer Deinstallation verwendet werden kann.
Fact ist, dass bei einer repaketierten Applikation, im Generellen die Kondition REMOVE verwendet werden kann.

Der Ausdruck REMOVE~=”ALL” hat sich über ein Jahrzehnt stark verbreitet. Der Wert ALL bedeutet, dass alle Features eines Produktes deinstalliert werden, sprich die Installation wird komplett deinstalliert. Dies ist die allgemeine Annahme in der Software Paketierung.

REMOVE~=”ALL” wird jedoch nicht in allen Situationen funktionieren, wie es Heath Stewart schon angedeutet hat. Es gibt eine Situation, den Wartungsmodus um es genau zu benennen, wo diese Kondition nicht greift. Betroffen davon sind besonders Software-Entwickler, da dessen Deinstallationen öfters mit dem Wartungsmodus durchgeführt werden und von diesem Problem betroffen sind.

Ein Produkt  kann über folgende vier Wege deinstalliert werden.

Deinstallation mittels Befehlszeile (msiexec.exe -x <product code> /qb) wie gewöhnlich ein Produkt automatisch deinstalliert wird:
MSI (s) (28:5C): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Deinstallation über Control Panel > Add or Remove Programs, wie es ein Endanwender eine Deinstallation durchführen wird:
MSI (s) (28:F8): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Deinstallation über den Wartungsmodus einer MSI Installation (Modify, Repair oder Remove Option im Setup Wizard)
MSI (s) (28:5C): Command Line:
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL

Deinstallation über die Windows Installer API
MSI (s) (28:EC): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Es wird nun ersichtlich, das eine Deinstallation über den Wartungsmodus anders abläuft als die restlichen Deinstallationswege. Beim Wartungsmodus steht es von beginn an nicht fest, welche Windows Installer Aktion der Anwender ausüben wird. Daher kann die REMOVE Property nicht  von Beginn an definiert werden.
MSI (s) (28:5C): Command Line:

In der REMOVE Property stehen alle Feature Namen des aktuell installierten Produktes (Features werden mit ; getrennt falls mehrere installiert sein sollten).
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.

Anhand der Windows Installer SDK steht fest, das der Remove Control Event das Argument ALL  dem REMOVE Property der Installations-Session weiter geben muss, damit das gesamte Produkt deinstalliert wird.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL

Entscheidend ist, die Action InstallValidate erkennt den Remove Control Event Eingriff  und ändert den Wert in der REMOVE Property auf ALL.

Dies bedeutet: Wird ein Produkt über den Wartungsmodus deinstalliert, so werden Konditionen mit dem Argument REMOVE~=”ALL” erst nach der InstallValidate Aktion funktionieren.

Sollte früher eine Aktion diese Kondition verwenden, so wird diese nicht ausgeführt.

Posted in: Tech, Windows Installer

Java Runtime Silent Repair

February 18, 2010 17:33 ⋅ Leave a Comment ⋅

Nicht überall wo MSI draufsteht, ist auch MSI drin. Ein Paketierer-Sprichwort, was sich bei der Sun Java Runtime bewahrheitet.
Ein aktuelles Problem der Java Runtime besteht bei einer unbeaufsichtigten Reparatur (Silent Repair), denn die Java Installation unterstützt keine Reparatur. Dies wird ersichtlich in der Systemsteuerung, es besteht nur die Möglichkeit das Produkt zu deinstallieren. Auch bei einer erneuten Installation bekommt der Endanwender über die Installationsdialoge eine Mitteilung:


Ein ‘Reinstall’ wird jedoch nicht durchgeführt. Das Java Setup wird die bestehende Installation deinstallieren und die gleiche Intallationsrutine erneut aufstarten.

Der Grund dieses Vorgehens liegt im Design der Installation. Es handelt sich bei der Java Installation um keine echte Windows Installer Rutine, sondern die MSI Technologie wird verwendet um Basis Dateien zu installieren, welche durch Benutzerdefinierte Aktionen (Custom Actions) die Hauptinstallation durchführen.

Ein fataler Nebeneffekt besteht nun, wenn eine Repartur oder die Installation ein zweites mal im unbeaufsichtigten Modus  durchgeführt wird.
Anstelle einer Reparatur, wird eine fehlerhafte Neuinstallation durchgeführt.

Ein Blick hinter die Kulissen zeigt, das nicht alle Benutzerdefinierten Aktionen ausgeführt werden.

Fatal: Basis-Dateien wie java.exe werden aus dem System32 Verzeichnis gelöscht und die Java Runtime ist nicht mehr funktionsfähig.

Wir empfehlen daher, die Intallation mittels Transformationsdatei anzupassen, damit dieser unerwünschte Vorgang unterbunden wird.

Folgende Eintäge in der Custom Action Tabelle sind nötig:

 Die InstallExecuteSequence Tabelle mit der Kondition:

Posted in: Application Best Practices

Firefox Plugins Repaketieren

January 29, 2010 17:13 ⋅ Leave a Comment ⋅

Die Plugins von Firefox zu repaketieren ist im Grunde einfach. Wissenswert ist, dass es zwei verschiedene Möglichkeiten gibt, um Plugins bereitzustellen.

Firefox Plugins

In diesem Beispiel sind die Plugins für den RealPlayer und Quicktime auf einem Rechner installiert.

Diese Plugins werden auf unterschiedliche Wege eingelesen. Das RealPlayer Plugin wird über die Registry eingelesen, dessen Weg viele Software Hersteller verwenden.

plugins2

Die Registry-Einträge für ein Firefox Plugin können über Local Machine Keys bereit gestellt werden.

Das Quicktime Plugin wird über Dateien bereitgestellt. Diese werden in die von Firefox vorgesehenen Ordner (Components und Plugins) abgelegt. Dieser Weg der Plugin Bereitstellung ist seltener anzutreffen.

plugins4

Im Ordner Components wird die XPT (XPCOM Type Library) Datei Abgelegt, im Ordner plugins werden die Plugins selber abgelegt.

Fazit:
Firefox Plugins sind einfach zu Installieren, da diese Per-Machine Ressourcen sind. Wenn Firefox Plugins repaketiert werden sollen, dann ist Firefox vor einem Snap-Shot zu installieren, da nicht alle Applikationsentwickler die Plugins ohne Firefox installieren.

Mehr über XPCOM kann in Wikipedia nachgeschlagen werden.
http://en.wikipedia.org/wiki/XPCOM

Posted in: Application Best Practices

Exclusion Liste für Windows 7

November 19, 2009 09:38 ⋅ Leave a Comment ⋅

Die Software Repaketierung unter Windows 7 baut grundsätzlich auf die gleichen Repackaging Best Practices wie bei Windows Vista auf.

Aus unseren Erfahrungen, die wir bei Windows 7 Migrationprojekten gesammelt haben, empfehlen wir die Ausschlussliste-Liste mit folgenden Einträgen zu erweitern, um eine bessere Qualität des Deltas eines Snap-Shots unter Windows 7 zu erreichen.

Verzeichnis C:Boot excl. Sub-Directory
Verzeichnis C:UsersAll Users excl. Sub-Directory
Verzeichnis C:UsersAppDataLocalTemp excl. Sub-Directory
Verzeichnis C:UsersAppDataLocalLowMicrosoftCryptnetUrlCache excl. Sub-Directory
Verzeichnis C:UsersAll UsersMicrosoftRAC excl. Sub-Directory
Verzeichnis C:UsersAll UsersMicrosoftSearch excl. Sub-Directory
Verzeichnis C:ProgramDataMicrosoftRAC excl. Sub-Directory
Verzeichnis C:ProgramDataMicrosoftSearch excl. Sub-Directory
Verzeichnis C:WindowsServiceProfiles excl. Sub-Directory
Verzeichnis C:WindowsSystem32LogFiles excl. Sub-Directory
Verzeichnis C:WindowsSystem32winevtLogs excl. Sub-Directory
Datei ntuser.dat.LOG1 File/Wildcard
Datei UsrClass.dat File/Wildcard
Datei UsrClass.dat.LOG1 File/Wildcard
Registry HKCU SoftwareClassesLocal SettingsMuiCache Ignore entire subtree
Registry HKCU SoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShell Ignore entire subtree
Registry HKLM SOFTWAREMicrosoftWindows Search Ignore entire subtree
Registry HKLM SOFTWAREMicrosoftReliability AnalysisRAC Ignore entire subtree
Registry HKLM SOFTWAREMicrosoftWindows NTCurrentVersionSPP Ignore entire subtree
Registry HKLM SOFTWAREMicrosoftWindows NTCurrentVersionSystemRestore Ignore entire subtree
Registry HKLM SYSTEMCurrentControlSetservicesVSS Ignore entire subtree
Registry HKLM COMPONENTS Ignore entire subtree
Registry HKLM Schema Ignore entire subtree

Weitere Informationen, was bei einer Windows 7 Migration zu beachten ist, können Sie an unserem User Group Meeting erfahren.
Nebst verschiedenen Keynotes zu aktuellen Themen erwarten Sie Technologie- und Produkte-News sowie Live Demos und Praxisberichte. Nutzen Sie die Gelegenheit sich effektiv zu informieren und mit Fachkollegen und Spezialisten zu diskutieren.

usergroup

Posted in: Best Practices, Wise Package Studio

Internal Error 2709

November 11, 2009 16:30 ⋅ Leave a Comment ⋅

Die Windows Installer 2709 Fehlermeldung ist eine Benachrichtigung, die bei einer Update Installation erscheinen kann. Wird eine betroffene Installation auf einer Clean Machine installiert, so sieht alles gut aus, keine Fehlermeldung erscheint. Sollte die gleiche Installation als Update Installation durchgeführt werden, so erscheint die 2709 Fehlermeldung. Interessant dabei ist, das der Test auf einer Clean Machine eigentlich das gleiche Problem haben sollte, das Problem aber aus internen Abläufen der Windows Installer Session automatisch korrigiert wird.

2709

Das Problem kann unter anderem durch ein Setup-Capture mit Wise Package Studio entstehen, wenn Dateien mit Merge Modulen ersetzt werden. Wie in diesem Beispiel wurde die Datei comdlg32.ocx durch ein Merge Module von Microsoft ersetzt. Dieser Vorgang löscht jedoch nicht die Verweise der bereits erstellten Componenten in der FeatureComponents Tabelle.

FeatureComponent
Komponenten die während einem Setup-Capture mit einem Merge-Module ersetzt wurden, bleiben in der FeatureComponents Tabelle zurück

Das etwas mit diesen Komponenten nicht stimmt, wird in der Tabellenansicht des Windows Installer Editors ersichtlich. Werden diese Einträge übersehen, so wird auf diesen Misstand während der Validierung darauf hingewiesen:
Not a valid foreign key; Table: FeatureComponents, Column: Component_, Key(s): Complete.comdlg32.ocx ice03.html FeatureComponents Component_ Complete comdlg32.ocx
Evaluation: ICE03

Diese Einträge sind aus der FeatureComponents Tabelle zu löschen. Es kann jedoch vorkommen, das die Validierung aus unbekannten Gründen bei dieser Überprüfung fehlschlägt und keine Probleme angezeigt werden. Bei einem anschliessenden Testdurchlauf der Installation wird keine Fehlermeldung erscheinen, da die Windows Installer Session diese fehlerhaften Einträge überspringt.

Doing action: InstallValidate
Feature: Complete; Installed: Absent;   Request: Local;   Action: Local
Component: CreateFolder; Installed: Absent;   Request: Local;   Action: Local
Component: registry44; Installed: Absent;   Request: Local;   Action: Local
Component: findmsm.exe; Installed: Absent;   Request: Local;   Action: Local

Während der InstallValidate Aktion werden die betroffenen Komponenten ausgewählt, die fehlerhaften Einträge werden einfach übergangen.

Soweit scheint alles zu funktionieren, bis zu dem Tag, an dem mit der gleichen Installation ein Update durchgeführt wird. Bei einer Update Installation wird zusätzlich die MigrateFeatureStates Aktion durchgeführt. Diese überprüft die Stati der bereits Installierten Features und vererbt die Feature States bei der Update Installation (Die Vererbung von Feature Stati kann mit der Upgrade Tabelle deaktiviert werden). Die Aktion  MigrateFeatureStates übergeht  die fehlerhaften Einträge in der FeatureComponents Tabelle jedoch nicht und wird mit der Fehlermeldung 2709 die Installation abbrechen.

DEBUG: Error 2709:  The specified Component name (‘comdlg32.ocx’) not found in Component Table.

In diesem Fall sind in der Installation die fehlerhaften Einträge in der FeatureComponents Tabelle zu beheben. Wir empfehlen diese Überprüfung in die Best-Practices von Software-Paketierungs Guidelines aufzunehmen, um diesem Problem zuvor zukommen.

Posted in: Best Practices, Windows Installer

Verzeichnisverfügbarkeit bei Custom Actions

November 9, 2009 11:58 ⋅ Leave a Comment ⋅

Nach den Regeln der alten Windows Installer Schule wird gelernt, das beim Einsatz von Custom Actions Verzeichnisse der Directory Tabelle erst nach der CostFinalize Aktion zur Verfügung stehen.
Demnach sollen Custom Actions, die mit Verzeichnis-Verweise arbeiten, erst nach der CostFinalize Aktion ausgeführt werden.

Die CostFinalize Aktion wird alle Verzeichnisse für die Windows Installer Session bereitstellen.
MSI (s) (F8:E8): Doing action: CostFinalize
MSI (s) (F8:E8): PROPERTY CHANGE: Adding TARGETDIR property. Its value is ‘C:’.

Interessanterweise kann bei der AppSearch Aktion mit Verzeichnissen wie WindowsFolder und ProgramFilesFolder gearbeitet werden obwohl diese vor der CostFinalize Aktion ausgeführt wird. Dementsprechend gibt es Verzeichnisse die schon vor der CostFinalize Aktion verwendet werden können.

Bei der Analyse einer Log-Datei wird ersichtlich, das vor der INSTALL Session, also noch bevor überhaupt eine Aktion ausgeübt werden kann, alle SpecialFolders (Magic Folders) aufgelöst werden und danach sofort zur Verfügung stehen.

Mit dem APICall SHGetFolderPath werden SpecialFolders aufgelöst.
MSI (s) (F8:E8): SHELL32::SHGetFolderPath returned: C:Documents and SettingsAdministratorApplication Data

Bei der Analyse der Log-Datei, sieht man jedoch den WindowsFolder, SystemFolder und den ProgramFilesFolder nicht aufgelistet. Diese Verzeichnisse stehen wie die restlichen SpecialFolders bei Beginn der INSTALL Session zur Verfügung.

Somit lässt sich aussagen, das SpecialFolders von Beginn der Installation verwendet werden können und Verzeichnisse, welche die Installation selber erstellt, nach der CostFinalize Aktion.

Mit dieser Erkenntnis können viele Custom Actions, welche mit SpecialFolders arbeiten, schon vor der CostFinalize Aktion ausgeführt werden.

Posted in: Windows Installer

Wise Package Studio 8 Download

November 2, 2009 16:13 ⋅ Leave a Comment ⋅

Das Wise Package Studio 8 wurde wie angekündigt am 29. Oktober 2009 veröffentlicht.

Kunden mit einem laufenden ‘Annual Upgrade Protection’ (AUP) können, nach erhalt des Registrierungscodes der per Email zugestellt wird, die neue Version über das Altiris License Management Portal herunterladen.
Es wird ein neuer Lizenzschlüssel benötigt, dieser kann im License Management Portal mit dem neuen Registrierungscode freigeschalten werden.

Für Evaluationzwecke kann eine Trialversion des Wise Package Studio 8  über die Symantec Homepage bezogen werden:
www.symantec.com/business/package-studio

Als langjähriger Wise Produkte Partner und Wise Added Value Reseller können wir bei einer Evaluation oder Upgrade des neuen Wise Package Studio professionelle Dienstleistungen anbieten.

Das Wise Package Studio 8 Getting Started Guide ist eine hilfreiche Dokumentation zur Installation einer Professional Edition im Serverumfeld.

Posted in: News, Wise Package Studio

Eine INI Datei nicht reparieren

October 28, 2009 14:39 ⋅ Leave a Comment ⋅

In dem heutigen Post geht es in der Windows Installer Technologie um die Situation, dass eine INI Datei während einer Reparatur nicht aktuallisiert werden soll.

Das Standard-Verhalten bei einer Reparatur ist wiefolgt: Der Inhalt einer INI-Datei wird mit den Werten aus der INIFile Tabelle verglichen und bei einer Differenz mit den ursprünglichen Werten überschrieben.
Sollte ein Endbenutzer Änderungen an einer INI-Datei vorgenommen haben, so gehen diese bei einer Reparatur des Produktes verloren.

Gemäss der Windows Installer SDK kann über die Aktions-Spalte mit dem Wert 1 festgelegt werden, dass ein Eintrag nur überschrieben wird, falls dieser nicht vorhanden sein sollte. In vielen Fällen wird die Änderung der Aktion die Situation entschärfen, da die Vorgabe auch bei einer Reparatur angewendet wird.

IniFileTable
Mit der Action-Spalte lassen sich zusätzliche Modifikations-Optionen für INI-Dateien einstellen

Betrachtet man die Situation genauer, so kann es sein, dass ein Endanwender Werte aus der INI-Datei löscht. Diese werden bei einer Reparatur wieder hergestellt und verwirft damit die Konfiguration des Endanwenders. Es gibt keine Modifikations-Option die diese Situation berücksichtigt. Eine Möglichkeit bietet die Verwendung einer Kondition in der InstallExecuteSequence Tablle bei der WriteIniValues Aktion. Die WriteIniValues Aktion schreibt die Werte einer INI-Datei anhand der Instruktionen der INIFile Tabelle. Mit der Kondition NOT REINSTALL kann die Aktion bei einer Reparatur ausgelassen werden. Damit geht die Reparaturfunktion aller INI-Dateien verloren, was an dieser Stelle zu erwähnen ist.

INIFile
Bei der Reparatur kann die Modifikation von INI-Dateien ausgeschaltet werden

Sollten die beschriebenen Möglichkeiten keine Alternative zur Situation sein, so stehen weitere Möglichkeiten über Benutzerdefinierte Aktionen (Custom Actions) zur Verfügung. Eine einfache Möglichkeit ohne viel Aufwand mit Scripting-Sprachen zu verbringen bietet der Wise Script Editor. Mit der Funktion Editet INI File kann eine INI-Datei erstellt werden. Die Custom Action ist mit der Kondition NOT Installed  zu versehen, dann wird die Datei nur erstellt jedoch nicht geändert bei einer Reparatur.

Edit
Mit dem WiseScript Editor lassen sich einfach INI-Dateien erstellen.

Posted in: Windows Installer