• https://www.wpm-blog.de/empirum-paket-deinstallation-ohne-quellen/
• https://www.wpm-blog.de/empirum-errorlevel-abfrage-bei-unattended-installationen/

Reparatur Logik

Das Resultat wird, je nach Betrachtung, nicht das Optimum darstellen. Meines Erachtens ist dies jedoch schon ein gutes Stück weiter als das Original. Wir betreiben also etwas Tuning :). In diesem Beitrag soll es um die Reparatur gehen.
Das Reparatur-Handling hilft uns …

• für die Reparatur einer Software durch Deinstallation und Neuinstallation
• falls die Software zuvor anderweitig ggf. manuell installiert wurde, damit diese zuvor deinstalliert wird
• falls die Software durch das Matrix42 Patch-Management vielleicht schon auf eine andere Version angehoben wurde

Grober Ablauf

Die Reparatur setzt grob auf folgenden Ablauf:
1) Erkennung, ob diese Software ggf. auch in einer anderen Version bereits installiert ist.
2) Falls ja, entfernen dieser Installation.
3) Anschließend wird mit dem „normalen Installationsablauf“ fortgefahren.

Anpassungen

Der nachfolgende Code-Schnipsel kann in die unattended.inf übernommen werden, oder ihr wartet noch die nächsten zwei Artikel ab und übernehmt dann eine gesamte unattended.inf. Was wird noch folgen? Erkennung und Abfangen von geöffneten Programmen, sowie „verstecken“ der originären Installation in der Systemsteuerung unter „Programme“.

Falls ihr diesen Schnipsel nutzt …

In der [Product] Sektion muss vor die Installation die
#CheckExistingInstallation, DONTDELETE
eingebaut werden.

Die Erkennung bzw. das Deinstallationsprogramm hinter der Variablen „VM_UnInstCMD“ muss angepasst werden.

Code-Schnipsel

[CheckExistingInstallation]
;---setzen der Variable mit dem Deinstallationsprogramm
Set VM_UnInstCMD=%ProgramFilesDirx86%\My Program\unins000.exe
;---falls das Deinstallationsprogramm vorhanden ist, dann springe in die Sektion zu Deinstallation
If DoesFileExist ("%VM_UnInstCMD%") == "1" Then "DoUninstallBeforeInstall" EndIf

[DoUninstallBeforeInstall]
;---führe die Deinstallation durch und warte zur Sicherheit 3 Sekunden
-Call "%VM_UnInstCMD%" /S
Sleep 3000
;---Wurde die Deinstallation erfolgreich durchgeführt und ist die Deinstallationsroutine entfernt worden? Falls nicht, melde einen Fehler.
If DoesFileExist ("%VM_UnInstCMD%") == "1" Then "ErrorOnUninstallBeforeInstall" EndIf

[ErrorOnUninstallBeforeInstall]
ErrorLogMsg %ErrorText% %ErrorLevel% %CallingText% %VM_UnInstCMD%
Abort

Der Beitrag Empirum Setup.inf – Reparatur Unattended Setup erschien zuerst auf Workplace Management Blog.

Welche Datei meine ich denn nun genau?

Es geht um die Unattended.inf im Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates Ordner. Diese wird bei der Auswahl „Unattended“ im Verlaufe des „Package Wizards“ herangezogen.

Erfolgsüberprüfung

Nach dem „silent“ Aufruf einer EXE Datei, wird eine, wie ich sie nenne, „Erfolgsüberprüfung“ durchgeführt. Denn jede Setup.inf, die nicht mit einem „Abort“ beendet wird, wird per se als Erfolg gewertet. Sprich, wir sollten nach dem Aufruf eines externen Programms (Setup.exe, Installer, etc.) überprüfen, ob eingetroffen ist, was wir erwarten würden. Andernfalls, kann ein Paket ein „Success“ zurückmelden und die Software ist nicht installiert.

ErrorLevel Abfrage in der Vorlage

Die oben angesprochene Setup.inf Vorlage prüft deswegen nach einem Aufruf einer Installation den ErrorLevel ab. Weit verbreitet ist ein ErrorLevel mit dem Wert 0 ein Erfolg. Deswegen enthält die Vorlage auch die nachfolgende Zeile:

If "%ErrorLevel%" <> "0" Then "SET:InstallationError" EndIf

Doch was passiert, wenn die Installation z.B. einen Wert von 3010 zurückliefert? Ist dann ein Fehler aufgetreten? Nein. Der Wert 3010 bedeutet beispielsweise, die Installation war erfolgreich, doch es wird zusätzlich ein Neustart benötigt. Microsoft hat es mit den MSI Installern begonnen und einige haben diese Werte übernommen oder rufen in ihrer EXE Datei eine MSI Installation auf und geben den ErrorLevel der MSI Installation zurück.

Anpassung

Diese Anpassung setzt automatisch eine Neustart-Anforderung für dieses Paket und wertet den Rückgabewert von 3010 nicht als Fehler.

If "%ErrorLevel%" == "3010" Then "RebootRequired" EndIf
If "%ErrorLevel%" <> "0" & "%ErrorLevel%" <> "3010" Then "SET:InstallationError" EndIf

[RebootRequired]
SetReboot 1
-SetReboot 1

Wer noch weiter gehen möchte, für z.B. VCRedist Installationen oder Updates, der kann zusätzlich noch den Wert 1638 (Another version of this product is already installed) überprüfen.

ErrorLevel oder gibt es auch andere Methoden

Der ErrorLevel ist nicht die einzig wahre Methode. Natürlich kannst Du auch überprüfen, ob es einen bestimmten Registry Wert nach der Installation gibt, den es zuvor nicht gibt. Eine Überprüfung, ob die Software in Form ihrer ausführbaren Date vorhanden ist, kann genauso gut sein. Zu diesen Abfragen kommen wir dann bei den nächsten Tipps. Falls Du bereits Neugierig bist, so kannst Du in der Hilfe nach DoesRegKeyExist oder DoesFileExists suchen. Die DoesRegKeyExist Abfrage ist auch in der MSI.inf (Vorlage für MSI Installationen) enthalten ;-).

Der Beitrag ErrorLevel Abfrage bei Unattended Installationen erschien zuerst auf Workplace Management Blog.

Szenario – Was ist zu beachten?

Dieses Szenario kommt vor, wenn zuvor die Software „von Hand“ oder einer zuvor eingesetzten Software-Management Lösung auf den Endgeräten installiert wurde und man sich nun für den Einsatz von Empirum entschieden hat. Jetzt kann man alle Geräte komplett neu installieren, oder eben die Endgeräte „wie sie sind“ in Empirum mittels der Verteilung des Empirum Agenten und des Empirum Inventorys in Empirum aufnehmen. Letzteres Verfahren spart zumindest erst einmal Zeit, jedoch muss man bei der Erstellung und Verteilung der weiteren Software-Pakete beachten, dass man ggf. nicht die gleiche Installationsgrundlage antrifft. Dies bedeutet wiederum ausgiebigere Tests und eine größere, oder andere Pilotgruppe.

Umsetzung in der Setup.inf

Wie ergänzt man nun sein Software-Paket, dass Microsoft Office eben nicht noch einmal installiert wird, wenn es zuvor schon anderweitig auf einem Endgerät installiert wurde? Diese Abfrage kann wie folgt umgesetzt werden. Natürlich kann man die Mehrsprachigkeit über die Strings Sektionen noch schöner handhaben ;-).

[Product]
#CheckAlreadyInstalled, DONTDELETE
;... eigentliche Installationsabfolge ...

[CheckAlreadyInstalled]
;*** Prüfen ob bereits Office 2010 manuell/anderweitig installiert wurde.
;*** Check existing Office 2010 Installation prior to Empirum Software-Distribution
IF DoesRegKeyExist ("HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90140000-0019-0407-0000-0000000FF1CE},InstallDate") == "1" & DoesRegKeyExist ("HKLM,SOFTWARE\%MachineKeyName%\Setup,DisplayName") == "0" Then "AlreadyInstalled" EndIf

[AlreadyInstalled]
ErrorLogMsg %DeveloperName% %ProductName% %Version% ist bereits installiert ohne Empirum | is already installed without Empirum
Exit %DeveloperName% %ProductName% %Version% ist bereits installiert ohne Empirum | is already installed without Empirum

Der Beitrag Empirum – Übernehmen von vorhandenen Installationen erschien zuerst auf Workplace Management Blog.

Dann habe ich angefangen mir den Wert der SoftwareDepotDistributionFlags Variable durch Logging zu erarbeiten …

Nach dem Logging, der anschließenden Bestätigung durch den Support (Danke an Hr. Zinn) und weitere erfahrene Empirum Nutzer habe ich die nachfolgende Tabelle erstellt, die Euch bei der Nutzung hoffentlich schneller zum Ziel bringt als mich ursprünglich. In der Nachbetrachtung hat mich am meisten zum Stolpern gebracht, dass in der Hilfe vom bitweisen Vergleich mit Dezimal Werten gesprochen wird und dann die aufgeführte Tabelle Hex Werte enthält!

Anbei die von mir zusammengestellte Tabelle mit den Verteilbefehlen aus der DDC, den dazugehörigen Dezimal Werten für den bitweisen Vergleich sowie dem Verteilbefehl aus der deutschen Oberfläche.

Arbeiten mit den Werten in der Setup.inf

Setup.inf Beispiele:

;---Abfragen eines gesamten Verteilbefehls (Reinstallation per Pull/Push ohne vorherige Deinstallation)
 If BitXor (%SoftwareDepotDistributionFlags%, 99) == "0" | BitXor (%SoftwareDepotDistributionFlags%, 8291) == "0" Then "ReInstall" Else "EverythingElse" EndIf

;---Abfragen einer einzelnen Verteiloption
 If BitAnd (%SoftwareDepotDistributionFlags%, 32) != "0" then "ForceOnceMachine_is_set" else "ForceOnceMachine_is_not_set" endif

Der Beitrag Empirum Setup.inf – SoftwareDepotDistributionFlags erschien zuerst auf Workplace Management Blog.

Los geht’s!

Diese Linksammlung ist auf dem Stand: 07.04.2020

Generelles

• Software-Paketierung / Repaketierung
• Aufwand zur Erstellung eines Softwarepaketes
• Verzeichnisse und Freigaben des Empirum Servers
• Softwareverteilung mit Empirum von Matrix42
• Wissenswertes zum Installationskontext

Erstes Paket erstellen und verteilen

• Softwarepakete erstellen und verfeinern
• Empirum Paket erstellen – MSI
• Aufgepasst im Package Wizard – MSI
• Platform Eigenschaft – Empirum Setup.inf
• Empirum Setup.inf – Platform Wert Tabelle
• Setup.inf Abarbeitung
• Erste Setup.inf Anpassungen
• Aufgepasst beim Einfügen eines Paketes in das SoftwareDepot
• Einbinden eines Software-Paketes in Empirum (Basis)

Paketierung – Erweitert

• Umgebungsvariablen
• Empirum Setup.inf – Variablen
• Empirum Paket Versionen – Früher an später denken?
• Empirum Kopierbefehl und Kopierflags
• Empirum Paket – Registry ändern
• Registry ändern mit REG Dateien
• Setup.inf – Datei pro Benutzer kopieren
• Empirum Setup.inf Skript vorzeitig verlassen
• Neustart oder nicht
• SystemShutdown vs. SetReboot
• Empirum – Übernehmen von vorhandenen Installationen
• Empirum und For – Next Schleife
• Empirum – NTFS Berechtigungen setzen
• Verknüpfungen / Links erstellen
• Empirum Setup.inf – SoftwareDepotDistributionFlags
• Schließen von geöffneten Programmen
• Verstecken von Software in der Systemsteuerung
• Empirum Sektionen mehrfach aufrufen
• Unattended Paket – ErrorLevel Abfrage verbessern
• Unattended Paket – Reparatur Funktion einbauen
• Unattended Paket – Deinstallation ohne Quellen

Software-Management

• Empirum – Paket in das SoftwareDepot einfügen
• Aufgepasst beim Einfügen eines Paketes in das SoftwareDepot
• Einbinden eines Software-Paketes in Empirum (Basis)
• Einbinden eines Software-Paketes in Empirum (Erweitert)
• Empirum Paketeigenschaft – Erlaube Deinstallation
• Erweiterte Paketvoraussetzungen

Paketierung – Besonderes zur Verteilung

• Empirum Paket Versionen
• Softwarepakete-Updateverhalten Verteilen von neuen Versionen
• Empirum Paket – Registry, SoftwareDepot, Version
• Empirum Paket – Revision
• Empirum Paket – Revisionserhöhung bei großen Installationen
• Definition des Zeitplaners

Anpassen der Paketierungsvorlagen

• Anpassung Paketierungsvorlage – Einleitung
• Anpassung Paketierungsvorlage – Kopfdaten
• Anpassung Paketierungsvorlage – MSI Paket
• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Anpassung Paketierungsvorlage – lokaler Setup.inf Ablageort

Der Beitrag Empirum – Software Paketierung Selbststudium erschien zuerst auf Workplace Management Blog.

• Wie verteile ich neue Versionen von bestehender Software?
• Wie rolle ich diese Versionen aus?
• Was ist zu beachten?

Wichtige Grundlagen zu diesem Thema sind bereits in diesem Beitrag erläutert: Empirum Paket – Registry, SoftwareDepot, Version.

In Kurzform ist folgendes für die neue Version wichtig:

• Der Herstellername (DeveloperName) und Softwarename (ProductName) der Versionen sind identisch.
• Es ist lediglich die Version unterschiedlich und in diesem Falle die neuere Version höher als die alte.
• Die MachinekeyName Einträge (und somit im SoftwareDepot: Registrierung, Schlüssel) sind identisch.

Sind diese Voraussetzungen erfüllt kann das neue Paket dem Computer, der die Vorgängerversion zugewiesen hat, zugewiesen werden. Dazu die neue Version dem Computer mit den Verteilungsoptionen „Installieren, Erneuern“ zuweisen. Die alte Version aus der Zuweisung löschen. Bei der kommenden Abfrage: „Löschen“ auswählen. Dies bedeutet, dass der Verteilbefehl gelöscht wird und somit nur noch der Verteilbefehl für die neuere Version aktiv ist.

Findet nun die Softwareverteilung auf dem Zielcomputer eine Altversion anhand der MachineKeyName Werte in der Registry vor, so wird eine Deinstallation mit der lokal vorgehaltenen Setup.inf durchgeführt (AskUninstallOld=1). Dazu ist es wichtig, dass die Deinstallationsbefehle oder Zugriffe alle lokal erfolgen können! Häufig sorgen Zugriffe, in den betroffenen Sektionen für die Deinstallation, auf %SRC% oder ähnlich für Fehler bei der Deinstallation der Altversion. Ist die Altversion erfolgreich deinstalliert, beginnt die Installation der neuen Version.

Gibt es beim Testen (Deinstallation der Altversion), wie zuvor beschrieben, Probleme – und diese Probleme tauchen zumeist erst auch dann auf, wenn man die Nachfolgeversion paketiert hat, hat man noch „Handlungsspielraum“. Entweder man setzt nun die Vorgängerversion auf „Deinstallieren…“ anstatt „Löschen“ oder man passt das „neue“ Paket an (AskUninstallOld=0 und die Deinstallation auf Bedarf durchführen).

In einem anderen Beitrag werde ich der zumeist nachfolgenden Frage: „Wann passe ich die Version und wann die Revision an?“ nachgehen.

Der Beitrag Softwarepakete: Updateverhalten, Verteilen von neuen Versionen erschien zuerst auf Workplace Management Blog.

„SetComputerOwner“ definiert den Hauptbenutzer eines Computers anhand der Häufigkeit der letzten Logins. Wenn ein Benutzer sich für eine bestimmte Anzahl hintereinander an einem Computer anmeldet, so wird dieser in einem separaten Registry Wert abgelegt. Hier wird je nach Konfiguration entweder nur der Login Name, oder zusätzlich der „Fullname“ aus dem Active Directory geholt.

Weitere Konfigurationsmöglichkeiten könnt ihr der unteren Übersicht entnehmen.

Dieses Programm ist dafür gedacht, mit dem Matrix42 Software-Management und Inventory zusammenzuarbeiten, da die Ziel Registry Schlüssel auch für einen normalen Benutzer beschreibbar sind. Wenn Sie dieses Programm auch anderweitig einsetzen wollen, so müssen Sie sicherstellen, dass „Vollzugriff“ Berechtigungen auf den HKLM\Software\Matrix42 Registry Schlüssel vorhanden sind.

Management Console

Darüber hinaus können diese Informationen auch direkt in der Management Console angezeigt werden. Dazu sind die „Zusätzlichen Informationen“ (Custom Fields) zu konfigurieren (EMC, Extras, Einstellungen, Zusätzliche Informationen).

Damit die Werte in der Management Console angezeigt werden, muss das Matrix42 Inventory nach dem Schreiben der Registry-Wert ausgeführt werden.

Konfiguration per Registry

Liste der Konfigurations-Möglichkeiten (alle REG_SZ):

• CustomValueOSLogin = Custom29 (Standard)
• CustomValueUsername = Custom30 (Standard)
• GetFullname_from_AD = 1(Standard) oder 0 – Wenn der Wert 0 ist, wird keine Active Directory Abfrage getätigt bzw. versucht.
• LastLogon = Zwischengespeicherte letzte Anmeldung.
• LoginCount = Anzahl der Anmeldungen des LastLogon.
• Threshold = 10 (Standard) – Setzt die Schwelle, ab wann der LastLogon als Besitzer gespeichert wird.
• UserBlacklist = Komma separierte Liste von auszuschließenden Benutzern.
• Debug = 1 – Wenn eine Log-Datei (SetComputerOwner.log) nach %TEMP% geschrieben werden soll.
• CustomValueDepartment = Custom28 (Standard) (ab Version 1.1.0).
• GetDepartment_from_AD = 0 (Standard) oder 1 – Wenn der Wert 0 ist, wird keine Active Directory Abfrage getätigt bzw. versucht (ab Version 1.1.0).
• ForceGetADValues = 0 (Standard) oder 1 – Wenn der Wert 1 ist, dann werden nach dem Überschreiten des Schwellwertes die AD Werte immer aktualisiert (ab Version 1.1.0).

Die Konfiguration wird über die Registry, und hier der 32bit Schlüssel, getätigt.
Bei 32bit Windows Systemen hier: HKEY_LOCAL_MACHINE\SOFTWARE\matrix42\SetComputerOwner
Bei 64bit Windows Systemen hier: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\matrix42\SetComputerOwner

Wenn es keine Vorkonfiguration gibt, läuft SetComputerOwner mit Standard Einstellungen!

Download

Hier geht es zum Download:
SetComputerOwner (1599 Downloads )
MD5 Hashwert der Version 1.1.0: 4FB63950099CD81F7F21B780B0A7B52D

Aktualisierungen

Update (21.10.2013) – Seit heute steht eine neue Version 1.0.3 zur Verfügung, da es im vorbereiteten Paket zu Problemen unter Windows x64 kam.

Update (05.01.2020) – Seit heute steht die Version 1.1.0 zur Verfügung, die auch die Abteilungsinformation aus dem ActiveDirectory auslesen kann.

Genereller Hinweis

Der Beitrag Wer ist der Hauptbenutzer eines Computers? erschien zuerst auf Workplace Management Blog.

Die Empirum Setup.inf Skriptsprache ermöglicht einem jedoch weitere Möglichkeiten.

• Vornehmen von benutzerspezifischen Einstellungen
• Kopieren von Dateien pro Benutzer
• Abfragen von Werten auf dem Zielcomputer und „reagieren“ im Software-Paket, wie z.B. Prozessor-Architektur, Registrierungseinträge, Dateien, Dateiversionen, offene Prozesse, uvm.
• Nutzen von Variablen aus der EMC und steuern der Installation
• uvm.

Um Veränderungen an den vorhandenen Software-Paketen vorzunehmen, muss man zuerst verstehen, an welcher Stelle man die Veränderung vornehmen kann und welche Befehle und somit Möglichkeiten einem zur Verfügung stehen.

Gehen wir zuerst auf die Abfolge in der Setup.inf ein.

Die meisten Software-Pakete bzw. Vorlagen enthalten die unten stehenden Zeilen (am Ende dieses Blogeintrages), die für die Erläuterung der Abfolge herangezogen werden. Für die Erläuterungen habe ich jedoch ein paar Befehle bereits in die Vorlage eingebaut, um die Funktionsweise besser zu verdeutlichen.

Das Semikolon (;) sagt aus, dass diese Zeile nicht verarbeitet wird und ein Kommentar darstellt.

Das Hash Zeichen (#) oder von manchem auch Lattenzaun genannt, ist gleichzusetzen mit einem GOSUB aus Basic oder einem Prozedur Aufruf aus anderen Sprachen. Das bedeutet die entsprechende Sektion wird aufgerufen und nach der Beendigung springt die Verarbeitung wieder zurück und geht eine Zeile weiter.

Installationsabfolge

Es wird die Sektion [Product] als „Hauptprogramm“ ausgeführt und die dort angegebenen Sektionen der Reihe nach (von oben nach unten) angesprungen bzw. verarbeitet.

1. Die erste Zeile ohne Kommentar ist der Aufruf der #Set:Product Zeile. Hiermit wird die [Set:Product] Sektion angesprungen.
2. Es wird „Es geht los“ ausgegeben.
3. Die Datei Datei.exe wird in das Verzeichnis „%ProgramFiles%\Hersteller Software\“ kopiert. Ist kein Ziel nach der Datei.exe angegeben, dann enspricht das Ziel dem Wert von ApplicationDir=.
4. Jetzt ist die Sektion [Set:Product] fertig und es wird die Zeile
5. #Reg:OnUninstallProduct, DELETE angesprungen. Diese wird jedoch nicht verarbeitet, da diese das Flag „DELETE“ besitzt, was aussagt, dass die Sektion nur bei der Deinstallation ausgeführt wird.
6. Jetzt wird die Zeile #Reg:Product, DONTDELETE angesprungen. Diese wird ausgeführt, und das nur bei der Installation, da die Sektion das Flag „DONTDELETE“ besitzt.
7. Es wird der Registry Eintrag Version = 2 unter HKLM\Software\Hersteller\Software vom Typ REG_SZ gesetzt.
8. Anschließend wird die Sektion [INI:Product] und danach
9. [Security:Product] angesprungen. In beiden Fällen gibt es nichts zu tun.
10. Als letztes, obwohl es nicht unter [Product] aufgeführt ist, wird die Sektion [Shell:Product] ausgeführt.

Die Installation ist fertig, es gibt eine Verknüpfung auf dem Desktop, dass das Programm „Datei.exe“ startet.

Deinstallationsabfolge

Die Deinstallation wird in umgekehrter Reihenfolge verarbeitet und startet somit von unten in der [Product] Sektion.

1. Ähnlich wie die Ausnahme, dass [Shell:Product] beim Installieren als letztes aufgerufen wird, wird diese Zeile beim Deinstallieren zuerst ausgeführt. Die Verknüpfung wird entfernt.
2. Nun werden die Sektionen in der Reihenfolge von unten nach oben angesprungen, und dann ausgeführt wenn die Sektion kein FLAG (nach einem Komma) besitzen, oder das Flag „DELETE“ gesetzt haben.
3. So wird bei der Deinstallation der Registry Eintrag Version = 1 unter HKLM\Software\Hersteller\Software vom Typ REG_SZ gesetzt, da die Sektion [Reg:OnUninstallProduct] verarbeitet wird.
4. Nun wird als letztes die Sektion [Set:Product] verarbeitet.
5. Hier wird nun der Kopiervorgang „1:…“ rückgängig gemacht und die Datei gelöscht. Bestimmten Befehlen muss ein „-“ vorangestellt werden, damit diese bei der Deinstallation ausgeführt werden.

Die Deinstallation ist nun abgeschlossen.

Wenn man sich das selbst einmal anschauen möchte, so kann man den Empirum Package Editor starten, in die „Erweiterte Ansicht“ wechseln und die Setup.inf im Einzelschrittmodus durchlaufen.

Auszug aus einer Setup.inf

...
[Product]
;#FileCheckMachine, MACHINE
;#FileCheckClient, CLIENT
;ReplaceEnv <Variable>
#Set:Product
#Reg:OnUninstallProduct, DELETE
#Reg:Product, DONTDELETE
#Ini:Product, DONTDELETE
#Security:Product

[Set:Product]
ECHO "Es geht los"
1:Datei.exe,%ProgramFiles%\Hersteller Software\, NORMAL, 12345

[Reg:OnUninstallProduct]
HKLM,"Software\Hersteller\Software","Version",0x00000000,1

[Reg:Product]
HKLM,"Software\Hersteller\Software","Version",0x00000000,2

[Ini:Product]

[Security:Product]
;Hier könnten Veränderungen an den Berechtigungen im Dateisystem, der Registry, etc. stattfinden

[Shell:Product]
%Desktop%\Dateiaufruf, Datei.exe

Der Beitrag Setup.inf Abarbeitung erschien zuerst auf Workplace Management Blog.