MSI Snapshots werden nur erstellt, wenn der Hersteller keine qualitativ genügende Installationssource zur Verfügung stellt. Für das Erstellen dieser Pakete gibt es diverse kommerzielle Produkte.
Die MSI Snapshot Installation ist ein standartisierter Ablauf, der keine spezielle Anpassung benötigt.
Die MSI Snapshot Deinstallation ist ein standartisierter Ablauf, der keine spezielle Anpassung benötigt.
Generell sollten alle Ressourcen, die bei der Installation installiert wurden, bei der Deinstallation entfernt werden. Dies ist das Standardverhalten der MSI-Technologie. Die Ausnahmen sind Dateien, die über Komponenten installiert wurden, die mit anderen installierten Paketen geteilt werden.
Dateien und INI-Einträge, die nach der Installation der Software erstellt wurden, werden bei der Deinstallation standardmäßig nicht entfernt. Der Anwendungsordner verbleibt auf dem Computer mit einigen angelegten Inhalten. Er sollte vom Packager erkannt und korrigiert werden.
Benutzerspezifische Dateien und Registry-Einträge sollten nicht gelöscht werden.
Die MSI Snapshot Reparatur ist ein standartisierter Ablauf, der keine spezielle Anpassung benötigt.
Titel = Installationsdatenbank
Autor = ClueBiz
Betreff = Paketname
Kommentare = leer gelassen
Stichwörter = Installieren,MSI
Plattform = Intel oder x64
Standardmäßig wird das Installationsverzeichnis der Herstelleranwendungen verwendet. Wenn nichts anderes angegeben ist, sollten alle Anwendungen unter dem Verzeichnis "%ProgramFiles%" oder "%ProgramFiles(x86)%" installiert werden. Gemeinsam genutzte Dateien werden unter "%CommonProgramFiles%", "%ALLUSERPROFILE%", "%CommonProgramFiles(x86)%" installiert. Abweichungen sollten im Installationsdokument des Pakets definiert werden.
Standardspeicherort der Anwendungsverknüpfungen ist der vom Software-Setup-Programm vorgeschlagene Ordner. Es sollten die Namen der Verknüpfungen des Herstellers verwendet werden. Allgemeine Regeln können vom Anwendungsbesitzer bei der Paketbestellung geändert werden. Die folgenden Verknüpfungen sollten bei der Setup-Erfassung ausgeschlossen werden: Desktop-Verknüpfungen, Schnellstart, Online-Updates, Online-Registrierung, andere Internet-Verknüpfungen, Online-Hilfe, Versionshinweise, Deinstallations-Verknüpfungen, ReadMe-Verknüpfungen.
Verknüpfungen zu Hilfedateien sollten nur entfernt werden, wenn die Ziel-Hilfedatei aus der Anwendung heraus gestartet werden kann (z. B. durch Drücken von F1). Alle Verknüpfungen sollten ausgeschrieben werden, außer Verknüpfungen zu einem Ordner und Verknüpfungen zu einer externen Datei.
| ALLUSERS | 1 | Installation pro Maschine unter Verwendung von Ordnern im Profil "Alle Benutzer". |
| ARPNOMODIFY | 1 | Deaktiviert die Änderungsfunktionalität in ARP |
| ARPPRODUCTICON | file.ico | Eintrag aus Icon-Tabelle |
| LIMITUI | 1 | Die Ebene der Benutzeroberfläche (UI), die bei der Installation des Pakets verwendet wird, ist auf Basic beschränkt |
| Hersteller | Name des Herstellers der Anwendung ODER Wenn der Hersteller unbekannt ist, setzen Sie den Wert = ClueBiz | |
| MSIDISABLERMRESTART | 1 | Windows Restart Manager: Die Eigenschaft wird ignoriert, wenn der Neustart-Manager nicht verfügbar oder deaktiviert ist. |
| MSIRESTARTMANAGERCONTROL | Deaktivieren | Windows-Neustart-Manager: Deaktiviert den Neustart-Manager |
| MSIRMSHUTDOWN | 2 | Windows Restart Manager: Die Eigenschaft wird ignoriert, wenn der Neustart-Manager nicht verfügbar oder deaktiviert ist. |
| Produktname | Name der Anwendung entsprechend dem Eintrag im ARP | |
| ProduktVersion | Version der Anwendung im ARP | |
| REBOOT | ReallySuppress | Unterdrückt alle Reboots und Reboot-Aufforderungen, die durch ForceReboot während der Installation ausgelöst werden. |
| ROOTDRIVE | C:\ | Legt das Standardlaufwerk für das Zielverzeichnis der Installation fest. |
Enthält das Installationspaket eine benutzerspezifische Konfiguration, die beim Start der Anwendung von einem MSI-Einstiegspunkt ausgeführt werden soll, sollte diese mit allen relevanten Anzeigen im Feature "UserPart" hinzugefügt werden. "UserPart" sollte das übergeordnete Feature des Hauptfeatures der Anwendung sein Begründung: Bei sehr großen Anwendungen trägt diese Strukturierung zu einer wesentlich schnelleren Umsetzung der Konfiguration bei.
| Feature | UserPart |
| Feature_Parent | |
| Title | Benutzerteil |
| Description | |
| Display | 0 |
| Level | 1 |
| Directory_ | |
| Attributes | 32 |
Das Hauptmerkmal sollte wie folgt ausgefüllt werden:
| Feature | Produktname ohne Leerzeichen und Punkte |
| Feature_Parent | UserPart |
| Title | Produktname ohne Leerzeichen und Punkte |
| Description | |
| Display | 0 |
| Level | 1 |
| Directory_ | |
| Attributes | 32 |
Komponenten, die Dateien vom Typ DLL, OCX, EXE, SYS, TLB, CHM in die Systemordner wie system32 oder %CommonProgramFiles% installieren, sollten die Option "Always increment shared .DLL count" haben (Attributwert der Komponente = 8 oder höher).
Alle Komponenten, außer "CreateFolder", "INIFiles" und "RemoveFiles", müssen einen Keypath haben.
Wenn eine Komponente eine DLL-, OCX-, EXE-, SYS- oder TLB-Datei enthält, muss diese Datei ein Schlüsselpfad der Komponente sein. Diese Komponenten dürfen nicht mehr als eine Datei enthalten.
Wenn INI- oder Registry-Einträge für eine DLL-, OCX-, SYS- oder TLB-Datei benötigt werden, sollten diese Einträge und die Datei in derselben Komponente gespeichert werden.
Kennzeichnen Sie Komponenten für 64Bit-Anteile korrekt (Attribut 256 + zusätzlich z.B. 8).
Kleinbuchstaben in der GUID sind nicht erlaubt. Für eine neue Komponente muss eine neue GUID erzeugt werden.
Pro-Maschine- und Pro-Benutzer-Daten in der gleichen Komponente sind verboten.
Leere Komponenten müssen aus dem Paket entfernt werden.
Wenn ein Paket Current-User-Einträge enthält, stellen Sie sicher, dass diese Einträge wirklich notwendig sind. Wenn nicht, können sie aus dem Paket entfernt werden. Wenn möglich, sollten alle Pro-Benutzer-Daten zu der Komponente namens CurrentUser gehören. Der Schlüsselpfad für eine Pro-Benutzer-Komponente muss ein Registry-Eintrag unter HKCU sein, der für jedes Paket eindeutig ist (z. B. Verwendung von PackageCode), um die Funktionalität der Selbstreparatur zu gewährleisten.
Beispiel für einen Dummy-Schlüssel:
| Root | Schlüssel | Name | Wert | |||
| 1 | SOFTWARE | [Hersteller] | [Produktname] | Paketcode | AktuellerBenutzer | [Produktcode] |
Im Falle von nicht beworbenen Verknüpfungen oder wenn die Daten pro Benutzer aktualisiert werden müssen und mit Standard-MSI-Mitteln nicht korrekt aktualisiert werden können, muss ein Active Setup in das Paket aufgenommen werden.
Hier kann der
Alle *.log, uninstall* update* Dateien sollten aus dem Paket entfernt werden. Auch alle Verweise auf die entfernten Dateien in der Registry und der Shortcut-Tabelle sollten entfernt werden.
Es sollte eine einzelne externe CAB-Datei verwendet werden. Die externe CAB sollte den Namen
INI-Dateien sollten über die Tabelle "IniFile" installiert werden. Wenn eine Datei jedoch eine INI-Erweiterung und eine falsche interne Struktur hat, sollte die Datei direkt über die Tabelle File installiert werden. In Ausnahmefällen: Wenn die Reihenfolge der INI-Dateieinträge relevant ist und der IniFile-Tabellenmechanismus von MSI ungeeignete Ergebnisse liefert, ist es zulässig, INI-Dateien durch die gleichzeitige Verwendung von MSI-Datei-Tabelle und IniFile-Tabelle zu installieren. Wenn INI-Dateieinträge für DLL-, OCX-, SYS- oder TLB-Dateien erforderlich sind, sollten diese Einträge und die Datei in derselben Komponente gespeichert werden. Festcodierte Werte werden durch Eigenschaften ersetzt. Benutzerdefinierte Eigenschaften werden dem Paket hinzugefügt (um Hardcodes zu ersetzen usw.).
Alle Registry-Einträge sollten über die Registry-Tabelle installiert werden. Die Ausnahme sind die Registry-Einträge, die unter HKEY_CLASSES_ROOT über die Tabelle Class, ProgId, Extension etc. installiert werden können. Die Verwendung der TypeLib-Tabelle wird nicht empfohlen. Alle HKCR\CLSID-, HKCR\TypeLib-, HKCR\Interface-Einträge sollten zu dem entsprechenden DLL/OCX-Komponentennamen gehören. Stellen Sie sicher, dass die Registrierungsschlüssel für die 64Bit-Registrierungsstruktur unter Verwendung einer 64Bit-Komponente installiert werden. Andernfalls werden sie in die 32Bit-Registrierungsstruktur installiert. Die Schlüssel sind auf hart kodierte Einträge zu untersuchen, z. B.: Rechnernamen, IP-Adressen, Portnummern usw. Diese Einträge sollten durch MSI-Eigenschaften ersetzt werden. Die Verwendung der SelfReg-Tabelle im Setup-Capture ist verboten.
Die Zuordnung von Dateierweiterungen muss über den MSI-Standardmechanismus (Erweiterungstabelle) erfolgen. Entsprechende Einträge in der Registry-Tabelle müssen entfernt werden.
Werte übernehmen, wenn Umgebungsvariable bereits vorhanden. Bei der Installation angelegte Umgebungsvariable muss beim Entfernen des Pakets entfernt werden.
Beispiel: *=Pfad
Die Installation von Diensten sollte über die entsprechenden Tabellen (ServiceControl und ServiceInstall) und nicht direkt über die Registry-Einstellungen erfolgen. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services sollte nur dann geändert werden, wenn die Anwendung Dienstparameter benötigt, die nicht mit den MSI-Dienstetabellen selbst ausgeliefert werden. Während der Deinstallation der Anwendung sollten die installierten Dienste gestoppt und entfernt werden. ODBC ODBC-Einträge sollten über die entsprechenden Tabellen installiert werden und nicht über die direkte Installation der Registry-Einstellungen. ODBC-Einträge für 64Bit müssen über die Komponenteneigenschaften markiert werden. Ansonsten werden die ODBC-Einträge stattdessen in 32Bit geschrieben. Es ist auch erlaubt, ODBC-Einträge über die Registry-Tabelle zu installieren.
Benutzerdefinierte Aktionen können nur in Ausnahmefällen verwendet werden. Alle benötigten erweiterten Aktionen sollten über die Deploy.xml implementiert werden.
Zugriffsberechtigungen für Dateien, Ordner, Registrierungsschlüssel und Dienste (falls erforderlich) werden durch Anweisungen in der deploy.xml festgelegt, die nach der Installation ausgeführt werden. Es sollten die Dienstprogramme SECEDIT oder icacls verwendet werden. LockPermissions, MsiLockPermissionsEx Tabelle sind verboten.
Bei der MSI-Validierung wird die Konsistenz und referenzielle Integrität der MSI-Dateidatenbank überprüft. Dies geschieht mit sogenannten ICE-Tests (Internal Consistency Evaluators).
Die Standardvalidierung mit der "Full MSI Validation Suite" muss verwendet werden. Die Validierung sollte mit der "Full Windows Validation Suite" durchgeführt werden (alle ICE-Tests sollten ausgeführt werden), es sollten keine ERRORS in der MSI-Datei vorhanden sein und es sollten nur bestimmte Warnungen erlaubt sein.
Nachfolgend finden Sie eine Liste der erlaubten Fehler/Warnungen in einer ICE-Validierung:
ICE03 (Fehler): Nur Fehler, die "String-Überlauf (größer als die erlaubte Länge in der Spalte)" anzeigen.
ICE33 (Warnung)
ICE48 (Warnung)
ICE49 (Warnung)
ICE51 (Warnung)
ICE60 (Warnung)
ICE90 (Warnung)
ICE91 (Warnung)