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.

Der Blog wird „alt“ – Neuerung seit Empirum v14.2

Vergleich der Versionsnummer: Ist die Version im Abschnitt [Setup] der Setup.inf GRÖSSER GLEICH 14.2 gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt bis zum nächsten Punkt als komplette Zahl verglichen (45 kleiner 100). Daher ist die Version 1.100 höherwertiger als die Version 1.45 .

Ist die Version im Abschnitt [Setup] der Setup.inf KLEINER 14.2 (z.B. 10.5) gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt Spaltenweise verglichen. Daher ist die Version 1.45 höherwertiger als die Version 1.100. Die Zahlen nach dem ersten Punkt werden nicht als eine Zahl verglichen (45 kleiner 100), sondern Zahlenweise (4 ist größer 1 und 5 ist größer 0). Da die erste Zahl 4 nach dem Punkt bereits größer als die Zahl 1 ist, wird nicht geprüft.

Quelle: Matrix42 Online Hilfe

Ab hier folgt nun die Erläuterung zu [Setup] Version=10.5 …

Martin Niemann hat dies sehr anschaulich und ausführlich auf seinem Blog erläutert. Beim Treffen auf dem vor wenigen Tagen stattgefundenen Matrix42 CustomerDay habe ich in darauf angesprochen, ob ich seinen Eintrag samt Quellenverweis hierher übernehmen darf. Vielen Dank Martin für Deine Erlaubnis!

So hier nun die Erläuterung:

Fast ein jeder wunderte sich schon, wieso die neue Version 4.10 des Paketes von Empirum nicht als höherwertig identifiziert wurde, als das alte 4.9er Paket – „die Zehn ich doch höher als die Neun!“

Hierzu muss man wissen, das in Empirum nur die Zahl vor dem ersten Punkt als ganze Zahl verstanden wird. Alle Werte danach werden Ziffer für Ziffer verglichen.

Hier eine Liste von Versionsnummer in absteigender Reihenfolge:

Die grauen Zahlen zeigen, wie man sich beim Vergleichen von Versionsnummern diese Vorstellen sollte. Vergleicht man nun eine 3.10 mit einer 3.90, ist die 3.9 selbstverständlich höher als die 3.10.

Um zukünftig nicht an die Grenzen der Versionierung zu stoßen, empfiehlt es sich die Versionsnummern nach einem einheitlichen Schema zu erstellen: Die Hauptversion kann aus einer beliebigen Zahl bestehen – bei der Nebenversion sollte man mindestens “zweistellig” vorgehen. Anstelle einer 3.1 sollte man daher besser eine 3.01 verwenden. So ist es später problemlos möglich, nach der 3.09 noch weitere Versionen anzubieten. Vorsichtigere Naturen verwenden für die Nebenversion sogar eine dreistellige Zahl: 3.009. Dies sollte man jedoch nur bei Paketen vornehmen, von denen man weiß, dass sie sich häufig verändern und die Erhöhung der Revisionsnummer nicht verwendet werden kann. Ist man jedoch in die “.9-Falle” getreten, empfiehlt es sich für die neue Version einen weiteren Zahlenblock anzuhängen: 3.9.01. Das sieht zwar nicht so schön aus, rettet einen jedoch aus der misslichen Lage die Version 4.00 einzuführen.

Autor: Martin Niemann

Der Beitrag Empirum Paket Versionen – Früher an später denken? erschien zuerst auf Workplace Management Blog.

In einer Sektion die mit Reg: beginnt, dürfen jedoch auch nur Registry Veränderungen enthalten sein, da mittels dieser Sektion die Registry API angesprochen wird.

Wie erstellt man nun einen Registry Eintrag oder wie so häufig genannt – Reg Key?

• Aufzeichnung per Differenzanalyseverfahren (Diff)
• Erstellen der Einträge mittels des Package Editors
• Import von Reg Dateien mittels des Package Editors
• Erstellen der Registry Einträge von Hand
• Erstellen eines „Standard“eintrag
• Weitere Erläuterungen
• Benutzerteil

Aufzeichnung per Differenzanalyseverfahren (Diff)

Wenn man ein Paket per „Diff“ aufzeichnet, hat man die erstellten Registry Einträge auch direkt in der REG:Product und ggf. auch der Reg:OnUninstallProduct vorliegen. Hat man ein Paket mit dem MSI oder Unattended Verfahren erstellt, so kann man anschließend die weiteren Anpassungen per Diff festhalten.

Dazu startet man das installierte Programm, wechselt zu dem Menü oder ähnlich, wo man seine Änderung (z.B.: Automatische Updates, Speicherort der Einstellungen, etc.) vornehmen möchte, startet den PackageWizard, wählt die Option „Differenzanalyseverfahren“ und führt den „PreScan“ durch. Ist der „PreScan“ abgeschlossen, führt man die Veränderung, wie die Programmeinstellung durch. Hat man die Einstellungen im Programm abgeschlossen, folgt man den Schritten des PackageWizard Assistenten bis zum Ende. Falls sich die Programmeinstellungen in Registry Änderungen „niederschlagen“, so kann man die Zeilen aus der [REG:Product] Sektion der gerade erstellten Setup.inf in das vorhandene Paket zur Programminstallation übernehmen.

Erstellen der Einträge mittels des Package Editors

Der Empirum Package Editor unterstützt den Benutzer bei der Erstellung von Registry Einträgen in der „Normalen“ und in der „Erweiterten Ansicht“ auf seine Weise. In beiden Fällen muss man zuvor in „Alle Abschnitte“ die Sektion „Reg:Product“ unter „Options“ auswählen.

In der „Normalen Ansicht“ „klickt“ man sich den Eintrag zusammen, in der „Erweiterten Ansicht“ kann man die Unterstützung mittels der Tastenkombination STRG-Leertaste nutzen.

Import von Reg Dateien mittels des Package Editors

Liegt einem bereits eine *.reg Datei vor, so kann man diese mittels des Empirum Package Editors importieren. Wie das geht ist in der Empirum Hilfe beschrieben.

Erstellen der Registry Einträge von Hand

Die Syntax der Registry Änderungen in der Setup.inf sieht auf den ersten Blick „unerlernbar“ aus. Das ist es aber auf keinen Fall! Der Pfad trennt die Wurzel (HKLM, HKCU, etc.) nicht mit einem „\“ (Backslash), sondern mit einem „,“ (Komma). Die meisten Änderungen betreffen Registry Werte vom Typ REG_SZ oder REG_DWORD.

In der Setup.inf steht nicht der Typ in Form von REG_SZ oder REG_DWORD, sondern 0x00000000 bzw. 0x00010001. Hier eine kleine „Eselsbrücke“, wie ich die wichtigsten Änderungen von Hand vornehme.

REG_SZ entspricht 0x00000000 = „NULL X 8 mal die NULL“
REG_DWORD entspricht 0x00010001 = „NULL X, 3 mal NULL, EINS, 3 mal NULL, EINS“

[Reg:Product]
HKLM,"Software\Hersteller\Produkt","Eigenschaft",0x00000000,"Zeichenkette"
HKLM,"Software\Hersteller\Produkt","AutoUpdate",0x00010001,"0"

Hier geht es zur vollständigen Beschreibung.

Erstellen eines „Standard“eintrag

In der Registry gibt es auch die sogenannten (Standard) bzw. (Default) Werte. Diese werden wie folgt erstellt:

[Reg:Product]
HKCR,"Software\Adobe\Acrobat\Exe",,0x00000000,'"%ProgramFiles%\Adobe\Reader 9.0\Reader\AcroRd32.exe"'

Weitere Erläuterungen

Wird die Reg: Sektion auch bei der Deinstallation aufgerufen, so wird die aufgeführte Änderung rückgängig gemacht, was zumeist bedeutet, dass der Eintrag gelöscht wird. Soll ein Eintrag bei der Deinstallation wieder auf den Wert vor der Installation „zurückgesetzt“ werden, so ist in der Setup.inf unter Reg:OnUninstallProduct der „vor der Installations Registry Wert“ einzutragen.

Soll ein Eintrag oder Baum auch bei der Installation gelöscht werden, so ist der Zeile ein „-“ voranzustellen. Hier ein Beispiel:

[Reg:Product]
-HKLM,"Software\Hersteller\Produkt"

So kann man auch bei der Deinstallation die Registry bereinigen, indem man in  der Reg:OnUninstallProduct Sektion ein „löschen“ mittels „-HKLM,…“  durchführt. Doch hier sollte man mit Vorsicht vorgehen, nicht „zuviel“ zu bereinigen!

Benutzerteil

Hat man eine Setup.inf mit „HKCU,…“ Einträgen, so besitzt dieses Paket einen sogenannten Benutzerteil. Damit der Benutzerteil ordnungsgemäß ausgeführt wird, muss die „Command Line Options =“ ein /AW aufweisen. Viel wichtiger ist jedoch, dass das /AW auch im SoftwareDepot, wo das Paket in die Empirum Management Console eingebunden ist unter den Paketeigenschaften, auf dem Register „Prüfung“, der „Befehl“ um ein „/AW“ erweitert wird. Näheres dazu ist wiederum hier zu finden.

Der Beitrag Empirum Paket – Registry ändern erschien zuerst auf Workplace Management Blog.