Reboot Möglichkeiten

Fangen wir vorne an. Es gibt in der Empirum Setup.inf mindestens zwei Möglichkeiten einen Neustart aus dem Paket heraus anzufordern. Wie das Ganze dann vom Empirum UEM Agenten dann verarbeitet wird, liegt dann zusätzlich an den Agenten Einstellungen, dem Agent-Template.
In der [Application] Sektion gibt es den Paramter Reboot=[Wert von 1 bis 5] für die Anforderung eines Neustarts. Zusätzlich kann man im Verlauf der Setup.inf mit dem Befehl SetReboot [Wert] eine Reboot-Anforderung setzen.

Wo ist der Unterschied?

In der [Application] Sektion setzt man einen Wert für die Installation und Deinstallation, ganz gleich, wie der Verlauf des Paketes ist. Mit dem Befehl SetReboot wiederum kann man fallweise eine Neustart-Anforderung platzieren. Dies kann man sich z.B. bei Paketen basierend auf der MSI Vorlage ansehen. Falls sich ein MSI Paket mit einem ReturnCode 3010 beendet (erfolgreich, jedoch Neustart notwendig), dann wird in der Sektion [RebootRequired] ein SetReboot 1 ausgeführt.

Welchen Wert nutzen?

Wie oben bereits geschrieben, gibt es Werte von 0 bis 5 mit unterschiedlicher Ausprägung und Funktion. Dabei bedeutet der Wert 0 nicht, dass dieses Paket keinen Neustart benötigt, wie zumeist angenommen. Der Wert 0 steht vielmehr für den „Automatikmodus“. Kann zum Beispiel eine Datei im Paketablauf (Ablauf der Setup.inf) nicht ersetzt oder gelöscht werden, fordert beim Wert 0 das Software-Paket trotzdem einen Reboot einen, um beim Neustart, wenn die Datei nicht in Benutzung ist, zu ersetzen oder zu löschen. Möchte man einen Neustart des Paketes unterbinden, so muss man Reboot=2 setzen. Dagegen ist der Wert 1, wie man es sich schon denken konnte, eine direkte Anforderung eines Neustarts. Neben den genannten Werten, wir dann noch häufig der Wert 5 genutzt. Dieser bestimmt, dass nach der Beendigung dieses Paketes ein Neustart angefordert wird (wie bei 1), jedoch auch keine weiteren Pakete zur Ausführung kommen. Die weiteren Pakete werden dann nach dem ausgeführten Reboot durchgeführt.

Wer einen Neustart in gewisser Weise erzwingen mag, kann sich auch meinen Beitrag zum SystemShutdown anlesen.

Komplette Übersicht

Da nun die Eigenschaften für 3 und 4 unter den Tisch gefallen sind, möchte ich diese zur Vollständigkeit hier auch noch erläutern:

• 0 – startet das System nach der Installation neu, wenn ein Neustart erforderlich ist, weil z.B. Dateien überschrieben/gelöscht werden müssen, die in Benutzung sind.
• 1 – startet das System in jedem Fall neu
• 2 – startet das System nicht neu
• 3 – abmelden des Benutzers
• 4 – Herunterfahren (kein Neustart)
• 5 – nach der Installation kein weiteres Paket installiert und zwingend ein Neustart durchgeführt. Dies entspricht dem Verhalten der Option „Installation weiterer Pakete nicht fortsetzen“ in den Paketeigenschaften

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

Grober Ablauf – MSI Paketerstellung

Eine MSI Datei ist „eigentlich“ ein fertiges Paket für den Windows-Installer. Bei der Erstellung einer Empirum Setup.inf werden beim Packaging diverse Werte aus der MSI ausgelesen und in die Setup.inf übertragen. Die Setup.inf enthält am Ende die Logik und Erfolgsüberprüfung für die Installation, Reparatur und Deinstallation der MSI Datei und bietet Raum für Erweiterungen, die über die reine MSI Installation hinausgehen.

Aufmerksam sein …

Die aus der MSI Datei ausgelesen Werte für Hersteller, Software(name) und Version werden im Packaging Vorgang vorgeschlagen.

Hier sollte man wachsam sein und darauf achten, dass ..
1. bei Software auch nur der „Softwarename“ steht und nicht gleich der Hersteller und die Version zusätzlich.
2. es sich beim vorgeschlagenen Text um Zeichen handelt, die auch im Dateisystem verwendet werden können. Ansonsten fällt einem das später auf die Füße.

Beispiel: Dell Command Update

Im angezeigten Beispiel sind gleich mehrere „Hürden“ enthalten.
1. Es handelt sich um das Dell Command Update. Der Softwarename ist dann genau genommen nur noch „Command Update“. Also Dell am Anfang kann entfernt werden.
2. Vorgeschlagen wird „Command | Update“. Bitte macht daraus ein Command Update! Die „Pipe“ wird bei der Verzeichniserstellung für Probleme sorgen.
3. Der Hersteller ist „Dell Inc.“. Hier empfehle ich „Dell“ oder „Dell Inc“ daraus zu machen, weil es sonst weitere Probleme geben wird.

Man sollte also darauf achten, dass Hersteller, Softwarename und Version nicht auf einen „Punkt“ (.) enden!

Gemeistert

Hat man die Dinge oben beachtet, sollten keine Probleme bei der Paket-Erstellung, Import und Verteilung auftreten.
War man „clever“ und hat sich im die ein oder anderen Probleme „herumgearbeitet“, aber in der Setup.inf vielleicht noch „Dell Inc.“ stehen, dann kann das wie folgt enden.
Die Installation des Paketes schlägt fehl. Beim genaueren Hinsehen hat einen Ordner „Dell Inc.“, auf den man jedoch nicht zugreifen kann…

Wenn er stört, dann löscht man ihn halt. Argh – das funktioniert leider auch nicht so einfach.

Egal wie man es dreht und wendet, man bekommt den Ordner weder per Explorer oder den normalen Angaben in der CMD nicht entfernt.

Mit folgenden Befehl kann man den Ordner jedoch entfernen:

rd /s /q "\\?\C:\ProgramData\$Matrix42Scripts$\Dell Inc."

Der Beitrag Aufgepasst im Package Wizard – MSI erschien zuerst auf Workplace Management Blog.

Warum schreibe ich diesen Artikel?

Lange Zeit gab es keine Frage danach, wie ein Software-Paket in das Software-Depot aufgenommen wird, da es nur eine Methode gab. Da sich seit geraumer Zeit auch der Package Wizard verändert hat, stellt sich die Frage vielleicht um so mehr. Der Package Wizard ist das Werkzeug der Matrix42 zur Paket-Erstellung. Der Package Wizard wurde angepasst, damit die Pakete besser vorbereitet sind, um sie nicht nur in einer klassischen Empirum Console einfacher zu importieren, sondern auch, wenn man Empirum von Matrix42 als SaaS Angebot bezieht. Gerade im letzteren Fall, geschieht der Upload und Import von Software-Paketen über die sogenannte UUX Oberfläche.

Wie und wo importiert man Software-Pakete in Empirum?

Wenn ich hier vom Import von Software-Paketen in Empirum schreibe, dann beziehe ich mich in diesem Artikel auf die Empirum Oberfläche und nicht die Matrix42 UUX. Für den Import startet man die Empirum Console oder auch als Matrix42 Management Console bekannt und wechselt in den Bereich Konfiguration, Software Management, Depot.

Anschließend klickt man mit der rechten Maustaste auf das Register, in das man das erstellte Paket einfügen möchte …

Welche Methode nutzt man wann?

Doch welchen der beiden gezeigten Einsprungspunkte nutze ich denn nun?

Paket einfügen …

Hat man ein Software-Paket durch Kopieren eines vorhandenen Empirum Paketes auf dem EmpirumServer erstellt und dabei höchst wahrscheinlich selbst die Setup.inf angepasst, dann nutzt man die Methode „Paket einfügen …“. Welche Angaben man dabei treffen muss und kann, habe ich bereits in den Links zuvor beschrieben. Diese Methode benötigt man auch, wenn man einen Package Wizard vor der Empirum Version 22 nutzt, wenn mich nicht alles täuscht. Am besten, man achtet auf den Ablage des Paketes am Ende des Package Wizard Vorganges. Endet dieser mit einer Kopie des Paketes nach \\%EmpirumServer%\Configurator$\Packages, dann ist das hier die richtige Methode.

Import/Export

Wann nutzte ich nun die Import/Export Methode? Nun, diese Methode wird zumeist genutzt, wenn man Pakete übergeben bekommt wie z.B. der Matrix42 PackageCloud, der innomea Paketbox oder weiteren Paketanbietern … oder eben, wenn man einen aktuellen Empirum Package Wizard nutzt. Den aktuellen Package Wizard erkennt man daran, dann er mit den folgenden vier Bildern endet. Diese Abfragen hat die Vorgängerversion nicht getätigt.

Wird man also nach den Paket-Informationen, den Betriebssystemfreigaben, diversen Paket-Eigenschaften, zusätzlich zu den essentiellen Angaben wie: Hersteller, Softwarename und Version gefragt, dann hat man die „neue“ Version. Der Package Wizard schlägt dann auch im letzten Dialog die Kopie des Paketes nach \\%EmpirumServer%\Configurator$\PackageStore vor.

Nachfolgend die Dialoge des aktuellen Package Wizards …

Der Beitrag Empirum – Paket in das SoftwareDepot einfügen erschien zuerst auf Workplace Management Blog.

Wie können wir darauf in der Softwareverteilung bzw. der Paketierung darauf reagieren?
Wie kann ich das in der Matrix42 Empirum Setup.inf handhaben?

Die harte Methode

Wenn also ein geöffnetes Programm stört, dann beenden wir es halt vor der Installation. Nehmen wir für die nächsten Beispiele an, es geht um Microsoft Visio. Man kann das in Windows enthaltene Tool TaskKill.exe nutzen und damit den Prozess beenden. In der Empirum Setup.inf würde der Befehl grob wie folgt ausschauen:
Callhidden TaskKill.exe /IM visio.exe /F
Es gibt jedoch auch einen Setup.inf eigenen Befehl:
Killprocess visio.exe
Beide haben gemeinsam, sie beenden sofort den laufenden Prozess und gehen in der Installationsabfolge weiter. Was aber, wenn der Benutzer gerade die letzten Minuten oder Stunden Änderungen in seinem Visio-Diagramm vorgenommen hat? Diese Änderungen „darf“ der Benutzer höchstwahrscheinlich mit der neuen Visio Version erneut durchführen.

Sanftere Methoden

Die sanftere Methode ist, mit dem Benutzer zu interagieren. Dies geht in der Empirum Setup.inf über den Befehl AsKillProcesses und der dazugehörigen [Processes] Sektion. In der [Processes] Sektion wird konfiguriert, bei welchem Prozess, welcher Name in der GUI angezeigt wird und wie nach dem Ablauf des Timeouts (des AskKillProcesses  Befehls) verfahren werden soll. Während des TimeOut’s hat der Benutzer die Möglichkeit die Anwendung selbsttätig zu schließen. Die Installation wird direkt nach dem Schließen durch den Anwender fortgesetzt. Reagiert der Benutzer während der Timeout Zeit nicht auf den angezeigten Dialog zum Schließen der Anwendung, bestimmt der Parameter CONTINUE oder ABORT, ob das Paket „Abgebrochen“ wird, oder die Installation fortgesetzt wird. Bei einem Abbruch wird dies auch mit der entsprechenden Meldung in der Management Console signalisiert.

[Processes]
;---beenden des Processes visio.exe nach dem Timeout (hier 300) und mit der Installation voranschreiten
VisioProc=visio.exe, Microsoft Visio, KILLPROCESS CONTINUE
;---Alternativ: KEIN beenden des Processes visio.exe nach dem Timeout (hier 300) und Abbrechen der Installation
;VisioProc=visio.exe, Microsoft Visio, KILLPROCESS ABORT

[CheckOpenProcesses]
AskKillProcesses 300, VisioProc
-AskKillProcesses 300, VisioProc

[Product]
#CheckOpenProcesses, DONTDELETE
...
#CheckOpenProcesses, DELETE

Weitere Hilfe

Man kann auch auf einen Fenstertitel reagieren und anschließend das entsprechende Fenster schließen, etc. Dies ist in der Empirum Online Hilfe ausgiebig erläutert.

Der Beitrag Dialog zum Schließen von Programmen erschien zuerst auf Workplace Management Blog.

Hintergrund

Damit man eine Software mit Matrix42 Empirum verteilen kann, benötigt man ein Software-Paket. Dies muss im Falle von Matrix42 Empirum ein gewisses Format haben und ist am Ende eine Steuerdatei bzw. ein Skript mit dem Namen Setup.inf. Diese Setup.inf wird auch vom Matrix42 Package Wizard ein Paket erstellt, wenn man sich für die Installation einer MSI oder EXE, die unattended installiert werden kann, entscheidet. Der Vorteil ist, dass die Setup.inf neben der Fehler- bzw. Erfolgsbehandlung auch weitere Aufgaben übernehmen kann, die für diese Software nötig ist. Beispiele: Löschen der Desktop-Verknüpfung, Installation einer VCRedist vorab, Kopieren einer Datei danach, uvm.

Warum nun doppelte Einträge?

Die eben genannte Setup.inf ist im Ursprung eine Installationsroutine für Programme, die sich eben nicht „unattended“ bzw. „silent“ installieren lassen. Wenn man nun innerhalb der Setup.inf eine MSI oder EXE installiert, die selbst eine Installationsroutine mitbringt, haben wir eben zwei Installationsroutinen. Beide Installationsroutinen tragen sich in der Registry ein, womit sie dann in den oben genannten Dialogen erscheinen.

Bei MSI Paketen ist dies nicht der Fall!

Erstellt man mit dem Matrix42 Package Wizard ein Paket auf der Grundlage von MSI Quellen passiert das zumeist nicht – warum? In der MSI.inf Vorlage wird dem MSI Aufruf standardmäßig der Parameter ARPSYSTEMCOMPONENT=1 angehängt. Dieser MSI Parameter sorgt dafür, das die zu installierende Software anschließend mit dem Flag SYSTEMCOMPONENT versehen wird, welches die Anzeige in der Systemsteuerung bzw. unter Einstellungen unterdrückt wird: https://learn.microsoft.com/en-us/windows/win32/msi/arpsystemcomponent

Was passiert da?

Die Software bzw. die Anzeige in der Systemsteuerung bzw. unter Einstellungen wird zumeist über die Registry sichergestellt. Dazu legen die Installationsroutinen Einträge in den folgenden Registry Zweigen ab …
64bit Programme bzw. Installationsroutinen:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

32bit Programme bzw. Installationsroutinen:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Erstellt man nun in einem Zweig einer entsprechenden Software einen Eintrag: SYSTEMCOMPONENT vom Typ: REG_DWORD und setzt dessen Wert: 1, so wird diese Software anschließend nicht mehr angezeigt.

Empirum Inventory

Dieses verstecken der Software bezieht sich nur auf die Anzeige direkt am Computer! Das Empirum Inventory erfasst trotz alledem beide Einträge, was man auch eher als Vorteil sehen sollte.

Unatteded.inf Anpassung

In der Setup.inf können wir diesen Wert nach der Installation durch Empirum auch selbsttätig setzen und löschen. Dazu sind die folgenden Anpassungen in der unattended.inf notwendig. Anpassen des Reg:Product Aufrufes unter [Product]. Der wahrscheinlich vorhandene Parameter ,DONTDELETE ist zu entfernen.

[Product]
...
#Reg:Product
...

Die Reg:Product Sektion ist entsprechend der Software anzupassen…

[Reg:Product]
;32bit - oder [Setup] Platform Wert entsprechend setzen!
;HKLM,SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<SoftwareName>,SystemComponent,0x00010001,1
;64bit
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<SoftwareName>,SystemComponent,0x00010001,1

Der Beitrag Software in der Systemsteuerung verstecken erschien zuerst auf Workplace Management Blog.

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

Mir ist es dies das erste Mal in der Setup.inf zum Empirum TFTP Dienst aufgefallen, indem Matrix42 es für einen wiederkehrenden Aufruf einer Log Sektion nutzt.
In der Online-Hilfe ist dazu folgender Satz zu finden “ … Befindet sich direkt hinter dem Zeichen ‚#‘ das Zeichen ‚!‘, wird der Abschnitt auch ausgeführt, wenn er vorher schon ausgeführt wurde. …“

Der Beitrag Setup.inf – Sektionen mehrfach aufrufen erschien zuerst auf Workplace Management Blog.

Unattended Uninstallation Dialog

Wenn Du beim Nutzen des Package Wizards zum Erstellen einer „Unattended“ sprich „Silent“ Installation einer EXE an den Dialog zur Deinstallation kommst, kannst Du das „Basis Verzeichnis“ nicht anpassen. In das Eingabefeld für das Deinstallationsprogramm kannst Du den Aufruf „C:\Program Files (x86)\My Program\unins000.exe“ eintragen und den Assistenten erfolgreich beenden.

Deinstallation schlägt fehl

Die Tests zur Deinstallation des Programms im Rahmen der Paketierung schlagen fehl. Warum?

Fehlersuche / Behebung

Um herauszufinden, warum der Fehler auftritt, müssen wir uns die Abfolge der Befehle zur Deinstallation der Software in unserem erstellten Paket ansehen. Ein Blick in die Sektion [Set:Deinstallation] der Setup.inf, die für die Deinstallation zuständig ist, bringt den Fehler schnell zum Vorschein. Hier wird versucht, den folgenden Befehl auszuführen:

-Call "%Src%\C:\Program Files (x86)\My Program\unins000.exe" /S

Der Teil „%SRC%\C:\…“ sieht nicht nur seltsam aus, sondern kann auch nicht funktionieren. Angepasst, sollte der Aufruf wie folgt ausschauen:

-Call "C:\Program Files (x86)\My Program\unins000.exe" /S

oder besser noch

-Call "%ProgramFilesDirx86%\My Program\unins000.exe" /S

Mit diesen Anpassungen sollte die Deinstallation nun erfolgreich durchgeführt werden.

Anpassen der Vorlage

Damit die Anpassung nicht immer wieder im erstellten Paket vorgenommen werden muss, passt man die Vorlage „Unattended.inf“ (Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates) an. Dazu entfernt man aus der nachfolgenden Zeile:

-Call "%Src%\{UnattDeInst}" {UnattDeInstPar}

das %SRC%\ und macht daraus:

-Call "{UnattDeInst}" {UnattDeInstPar}

Der Beitrag Empirum Paket – Deinstallation ohne Quellen 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.

Die Anpassung der NTFS Berechtigung ist dann notwendig, wenn das paketierte Programm:

• in Laufzeit Änderungen im gleichen Verzeichnis vornimmt (INI+LOG Dateien, o.ä)
• eine AutoUpdate Funktionen für sich selbst anbietet

Wo und wie wird die Berechtigungsvergabe vorgenommen?

Die „Wo“ Frage ist recht einfach beantwortet. Dafür gibt es die [Security:Product] Sektion. Die Security:Product Sektion muss nach der Installation durchgeführt werden, damit der Ordner oder die Dateien bereits vorhanden sind. In den Standard Inf Vorlagen ist dies auch der Fall.

Kommen wir zur „Wie“ Frage …

Um die Berechtigung zu setzen, gibt für Windows 2000 und neuer den Befehl FileDaclEx.Add. Der Befehl ist in der Setup.inf wie folgt aufgebaut:
FileDaclEx.Add (<Datei>, <Name>, <Operation>, <Rechte>, <Vererbung>)

Will man nun der Gruppe der lokalen Benutzer, der im Standard alle Domänen Benutzer angehören Vollzugriff gewähren, dann sieht der Befehl wie folgt aus:

FileDaclEx.Add ("%App%", "%$LocalUsers%", GRANT, ALL, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

Will man jedoch nicht so freizügig mit den Berechtigungen umgehen und der Gruppe lediglich Ändern Berechtigungen geben, dann wird der Befehl etwas komplexer, da es für Ändern (Change) keine einzelne Berechtigung gibt. Die Berechtigung „Ändern“ entspricht den nachfolgenden Teil-Berechtigungen: TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC EXECUTE

Das sieht in der Windows 10 Oberfläche nicht viel anders aus, wenn man mal in den Sicherheitseinstellungen unter Erweitert nachschaut.

Wie sieht nun ein solcher Befehl in der Praxis aus? Hier ein paar Beispiele:

FileDaclEx.Add ("%App%", "%$LocalUsers%", GRANT, TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

FileDaclEx.Add ("%ProgramFiles%\%Developername%", "%$LocalUsers%", GRANT, TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

FileDaclEx.Add ("%App%\Application.ini", "%$LocalUsers%", GRANT, TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

Wenn ihr diese Anforderung häufiger habt, so könnt ihr einen der obigen Befehle in eure Paketierungsvorlagen (Template.inf, MSI.inf, Unattend.inf) einbauen und bei Bedarf den Kommentar (;) wegnehmen und den Befehl den Anforderungen nach anpassen.

Ist das alles?

Weiterführende Informationen, da die Security:Sektion noch mehr kann als NTFS Berechtigungen zu setzen:

• Welche Befehle darüber hinaus zur Verfügung stehen und welche andere Berechtigungen ihr setzen könnt, findet ihr in der Online Hilfe unter „Security:Product„.
• Welche Benutzer bzw. Gruppen per Variable und somit sprachunabhängig zur Verfügung stehen findet ihr am Ende der Tabelle „Vordefinierte Umgebungsvariablen“ der Online-Hilfe.

Der Beitrag Empirum – NTFS Berechtigungen setzen erschien zuerst auf Workplace Management Blog.