Wie ist die Syntax zur Erstellung einer Verknüpfung?

Die Syntax bzw. Abfolge der Angaben ist wie folgt.

<Verknüpfung>, <Kommando>, <Argumente>, <Arbeitsverzeichnis>, <Beschreibung>, <Symboldatei>, <Symbolindex>, <Fensterzustand>, <Tastenkombination>

Es müssen nicht alle Angaben gesetzt werden, wie die nachfolgenden Beispiele zeigen.

Beispiele:

;---Erstellung einer einfachen Verknüpfung auf dem Desktop abhängig von CommonShellLinks
%Desktop%\Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

;---Erstellung einer einfachen Verknüpfung auf dem Desktop aller Benutzer unabhängig von CommonShellLinks
%CommonDesktop%\Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

;---Erstellung einer Verknüpfung auf dem Desktop aller Benutzer
%CommonDesktop%\ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

;---Erstellung einer Verknüpfung ServicePortal im Startmenü abhängig von CommonShellLinks
ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

;---Erstellung einer Verknüpfung ServicePortal im Startmenü Ordner "MyComany" unabhängig von CommonShellLinks
%CommonPrograms%\MyCompany\ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

Besonderheiten

Die mittels Shell:Product erstellen Verknüpfungen werden beim Deinstallieren auch wieder entfernt. Möchte man beim Installieren Verknüpfungen entfernen, so geht das nur über den Del bzw. Deltree Befehl.

Beispiele:

;---löschen des Startmenü Ordners MyComany
Deltree "%CommonPrograms%\MyCompany"

;---löschen einer Verknüpfung vom Desktop aller Benutzer
Del "%CommonDesktop%\ServicePortal.lnk"

;---löschen einer Verknüpfung vom Desktop des jeweiligen angemeldeten Benutzers - Achtung: Das Paket muss mit /AW ausgeführt werden.
Del "%UserDesktop%\ServicePortal.lnk"

Abhängigkeiten

Die Shell:Product Ausführung ist von mindestens zwei Eigenschaften in der Application Sektion abhängig

CommonShellLinks=[1|0]
Wenn CommonShellLinks den Wert 1 hat, so ist die Variable %Desktop% gleichzusetzen mit %CommonDesktop%, genauso wie %Programs% mit %CommonPrograms%.
Ist der Wert 0, so ist %Desktop% gleichzusetzen mit %UserDesktop% und %Programs% mit %UserPrograms%.

ShellLinks=[0|1]
Ist der Wert 1, werden die Verknüpfungen erst am Ende der Installation, für jede Option der Abschnitt [Shell:<Option>], automatsich erzeugt ohne explizit aufgerufen zu werden. Ist der Wert 0, können Verknüpfungen auch durch den direkten Aufruf von #Shell:<Option> erstellt werden.

Der Beitrag Verknüpfungen / Links erstellen erschien zuerst auf Workplace Management Blog.

Betriebssystem importieren

Der Start für den Importvorgang befindet sich unter Konfiguration, OS Installer, Import. Die im weiteren Verlauf des Beitrages gezeigten Abbildungen führen durch den Importvorgang und bedürfen nur wenigen Kommentaren. Die zu importierende Windows Quelle (ISO) können Sie entweder mittels Windows Bordmitteln „Bereitstellen“ oder per 7-zip o.ä. entpacken. Der Import Wizard kann leider nicht direkt auf eine ISO Datei zugreifen.

Auswahl des Quellverzeichnisses bzw. des Laufwerkes, in dem die Betriebssystemquellen vorliegen …

Nach der „Untersuchung“ der Quellen, schlägt Empirum vor, was es importieren kann. Nach der Auswahl des Suchergebnisses, kann im nachfolgenden Dialog der Name angepasst werden, was ich auch stark empfehle!

Nach der gewünschten Anpassung, erfolgt der tatsächliche Importvorgang, der auch einen Moment andauert …

Nach einer Weile, zeigt der grüne Text in der Zusammenfassung den Erfolg des Imports an!

Weiter geht’s!

Der Beitrag Empirum WinPE – Betriebssystem in Empirum importieren erschien zuerst auf Workplace Management Blog.

PrepareDRVbyModel_Packages

Mein Ersatz bietet (meines Erachtens:)) einige Vorteile und weicht in den nachfolgenden Punkten von dem Matrix42 Grundgedanken ab:

• es ist „gesprächiger“ und man kann eher nachvollziehen, was es macht (siehe Screenshots am Ende des Beitrages)
• der Ablageort der Treiber kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
• der Ablageort der Drivers.ini kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
• es kann festgelegt werden, ob die WinPE Installation weitergehen soll, auch wenn kein Eintrag in der drivers.ini, Treiber, etc. gefunden wurde.

Übersicht dieses Beitrages

• Import der OS-Packages
• Kurze Einführung: Hardware Model zu Treiber/Software Zuordnung per drivers.ini
• Möglichkeiten mit PrepareDRVbyModel_Packages
• Einführung PostOSInstallation Paket
• Download
• Fehlersuche
• Screenshots

Import der OS-Packages

Zuerst ist es notwendig, die zusätzlichen OS-Package über das Software-Depot zu importieren. Danach muss die Reihenfolge arrangiert werden, damit die richtige Abarbeitung während der OS-Installation gewährleistet ist:

• <WinPE-D-2PXE> (optional aber empfohlen)
• DiskPartitioning
• <PrepareDRVbyModel_Packages>
• WindowsInstallation
• PxeOffAndReboot
• DomainJoin
• <PostOSInstallation> (optional aber empfohlen)
• EmpirumAgentSetup

Hardware Model zu Treiber/Software Zuordnung

Die Zuordnung Model zu Treiber geschieht wie bei dem Paket der Matrix42 über die drivers.ini Datei. Diese ist im Standard unter Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt.

Aufbau der Drivers.ini
[<WMI Manufacturer>]
<WMI Model>=<Ordner, *.ZIP, *.cab unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers>

z.B.
[Dell Inc.]
OptiPlex 7010=DellOptiplex7010
;alternativ OptiPlex 7010=DellOptiplex7010.zip
;alternativ OptiPlex 7010=DellOptiplex7010.cab

Möglichkeiten mit PrepareDRVbyModel_Packages

Nachfolgend sind die Möglichkeiten erläutert, die sich aufgrund der Anpassung und Erweiterung ergeben. Diese Möglichkeiten können über die Variablen in der Management Console gesteuert werden. Die aufgeführten Variablen sind alle unter der Variablen Sammlung „PrepareDRVbyModel_Packages“ zu finden.

DriversAreMandatory:
Das Matrix42 Paket drehte sich bis vor kurzem solange in der Schleife bis ein Treiber in der drivers.ini gefunden wurde.
Dies ist für eine produktive Umgebung, den Dienstleister etc. gut so.
Wenn man jedoch einen Computer ohne spezifische Treiber installieren will (zum Test), dann muss man im Matrix42 Falle einen drivers.ini Eintrag erzeugen mit einem Verweis auf ein leeres Verzeichnis.
Dieses Verhalten wurde mit dem DriverIntegration 2.6 Pakete verändert – man kann es jedoch nicht steuern.

Variablenwerte:
0, WinPE fährt mit der WindowsInstallation fort, auch wenn kein Treiber in der drivers.ini gefunden wurde.
1, Matrix42 Standardverhalten – das System läuft in der Schleife und führt die WindowsInstallation nicht fort.
Somit kann man für eine produktive Struktur (Konfigurationsgruppe) sicherstellen, dass die Installation nur mit bekannten Hardware-Typen durchgeführt wird.

DriversRootPath:
Die Idee, den DriversRootPath anpassbar zu machen, hatte mehrere Gründe:
Selektive Synchronisation der Treiber: Hiermit kann man die Treiber direkt unter Packages\Drivers ablegen und mit einem angepassten „ESubDepot_Packages“ SyncJob diese für bestimmte Standorte auslassen und mit einem selbsterstellten ESubDepot_PackagesDrivers diese separat synchronisieren lassen.
Treiber-Update Softwarepakete: Durch eine Erweiterung der Ablage um eine Setup.inf, DPInst.exe und xml kann man eine Aktualisierung der Treiber auf bestehenden Systemen durchführen und mass dazu die Treiber nicht mehrmals ablegen. Dies werde ich in einem späteren Beitrag nochmals aufgreifen.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Kommentar:
Hinweis: Man kann in der drivers.ini auch Teilpfade angeben.
Für eine Kopie eines Ordners zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP
Für die Nutzung einer ZIP Datei zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP\Optiplex7010.zip
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

DriversINIPath:
Die Idee hierbei war, dass man eine zweite drivers.ini Datei, unabhängig von einer produktiv genutzten, einsetzen kann.
Darin kann man Einträge für eine bekannte Hardware auf einen anderen Pfad, ZIP, etc. setzen und somit vorab bzw. parallel testen.
Somit kann für eine bestimmte Konfigurationsgruppe ggf. der Wert: Matrix42\OsPackages\Drivers\Test sein.
In diesem Ordner muss dann die alternative drivers.ini abgelegt sein.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

Perfekt funktioniert PrepareDRVbyModel_Packages mit dem PostOsInstallation Paket von mir. Das genannte Paket prüft ob es eine C:\EmpirumAgent\Drivers\HWspecificSW\Setup.inf gibt und führt diese aus.

Möglichkeiten des PostOsInstallation

Das PostOSInstallation Paket ist einfach und ruft eine abgelegt PostOSInstall.bat auf.
Hinweis: Diese Datei solltet ihr vor der ersten Benutzung einsehen und anpassen!
Die Batch Datei hat heute mindestens drei Funktionen:

• Es importiert eine von dem PrepareDRVbyModel_Packages Paket erstellte Registry Datei, die ähnliche Werte in die Registry schreibt (HKLM\Matrix42\Installer), wie die EPE Installation.
• Es passt die durch Matrix42 vorgegebenen Firma, Benutzer, Support etc. Informationen in der Registry an, die man bei der EPE Installation in der Betriebssystemvorlage angegeben hat.
• Es führt eine Setup.inf aus dem C:\EmpirumAgent\Drivers\HWspecificSW Ordner aus, falls diese vorhanden ist. Somit kann man wieder im „Hardware-Profil“ Treiber per PNP und per EXE/MSI installieren.

Somit ist die PostOSInstall.bat eine Art Ersatz für die EmpirumAgent.bat/UEMAgent.bat.

Download

Empirum WinPE PreOS Package zum optimierten Treiberhandling.

PrepareDRVbyModel_Packages 1.5 (404 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

PrepareDRVbyModel_Packages 1.1 (427 Downloads )
MD5 Hash der Downloaddatei: 0D3415555E6197DC510B02E946D96C5169FD8529

Los geht’s

Schritt 1:
Zuweisen der Pakete für eine Konfigurationsgruppe:

• <WinPE-D-2PXE> (optional aber empfohlen)
• DiskPartitioning
• PrepareDRVbyModel_Packages
• WindowsInstallation
• PxeOffAndReboot
• DomainJoin
• PostOSInstallation (optional aber empfohlen)
• EmpirumAgentSetup
• Betriebssystem (per Variable oder aus dem rechten Baum)
• WinPE (Bootkonfiguration)
• Agent-Template

Schritt 2:
Setzen der Variablen für die oben genannten Pakete (siehe hierzu ggf. auch das WinPE Dokument der Matrix42).
Zuordnung des Betriebssystems

Schritt 3:
Zuweisen eines Computers

Schritt 4:
Aktivieren von PXE und Software (OS.INI ist nicht notwendig!)
Achtung:nicht während einer aktiven WinPE Phase den Computer nochmals aktivieren (dies kann ab WinPE 1.4.11 wieder getan werden).

Rückmeldungen sind willkommen!

Fehlersuche:

• Erster Anlauf: In der Management Console auf dem entsprechenden Computer das PXE-Log ansehen
• Informationen zum Ablauf der OS-Packages befinden sich in Empirum\EmpInst\Wizard\OS\Auto\<MAC8> oder <UUID>\debug_Matrix42.Platform.Service.Host.log.
  Suchen nach [wpm-blog und darunter sollten weitere Informationen zu finden sein …

Beispielhafte Screenshots:

DriversAreMandatory = 0 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1, passende Zuordnung/Treiber in drivers.ini gefunden, abweichende DriversIniPath Variable, Treiber werden kopiert

Der Beitrag Empirum WinPE Paket – DriverIntegration Ersatz erschien zuerst auf Workplace Management Blog.

• BiosSet.exe
  https://www.fujitsu.com/de/solutions/business-technology/manageability/downloads/index.html
• BiosConfigUtility64.exe
  http://ftp.hp.com/pub/caps-softpaq/cmit/HP_BCU.html

Bei beiden Anbietern kann man einzelne Einstellungen per Kommandozeile tätigen, oder per Antwortdatei mehrere Einstellungen gleichzeitig setzen. Änderungen die auch beim manuellen Setzen einen Neustart zur Anpassung/Auswahl einer weiteren Einstellung benötigen, wie z.B.: PXE/Bootreihenfolge, UEFI Aktivierung + Anpassung der Bootreihenfolge, können auch hier einen Neustart erfordern.

Beispiele …

Hier habe ich ein paar Beispiele und festgestellte Besonderheiten aufgeführt.

Fujitsu

Mit der BiosSet.exe kann man recht einfach und modellübergreifend z.B. per
BiosSet.exe /WOL=ON z.B.: das WakeOnLan aktivieren.
Wenn man das Kennwort mittels des /CRYPT Parameters verschlüsseln will, so muss man das unbedingt auf einer Fujitsu Hardware durchführen. Mittels BIOSSET /? erhält man eine weitreichende Hilfe und Parameterliste angezeigt. Ebenso bietet das Tool eine große Varianz an unterschiedlichen ReturnCodes/ErrorLevel an, die man sich mit BIOSSET /E aufgelistet bekommt.

Hewlett-Packard

Bei HP funktioniert das Setzen der Einstellungen nicht unbedingt modellübergreifend, sondern nur bei den Modellen bei denen die BIOS Einträge gleichlautend sind. Die aktiven Einstellungen kann man mittels
BiosConfigUtility64.exe /get:<Dateiname> aufzeichnen und mittels /set: wieder setzen.
Die mittels /get erstellte Datei kann man auf die notwendigen Einstellungen reduzieren. Aktivierte BIOS Einstellungen sind mit einem * gekennzeichnet (z.B.: *Disabled). Hewlett-Packard bietet eine spezielle 64bit Variante des Tools an, sowie ein separates Programm zum Erstellen einer *.bin Datei die das BIOS Kennwort verschlüsselt enthält.

Bei dem Tool von HP hatte ich jedoch Probleme die Log Datei in ein definiertes Verzeichnis zu lenken, mittels des /LogPath Parameters. Der /L Parameter erstellt jedoch im Unterverzeichnis /Logs (relativ zur BiosConfigUtility64.exe) für jeden Vorgang eine Datei.

Beispielsdatei:

BIOSConfig 1.0
;
Remote Wakeup Boot Source
   Remote Server
   *Local Hard Drive

Der Beitrag BIOS Einstellungen vornehmen per Skript erschien zuerst auf Workplace Management Blog.

Die automatische Anpassung der Auflösung kann in Empirum ganz ohne zusätzliche Tools bewerkstelligt werden.

Suche dazu die unattend.xml Datei auf, die für die Betriebssysteminstallation herangezgen wird.
Hier ein Beispiel für einen Pfad zur Datei: Empirum\EmpInst\Sys\win7\x64\pro\1\DE.
Der Pfad kann natürlich je nach Sprache, Architektur und eingebundenen Service Pack abweichen.
Vor der Veränderung der Datei ist eine Sicherungskopie ratsam.

In der XML Datei gibt es eine Display Sektion. Diese Sektion beginnt mit <Display> und hört mit </Display> auf.

Hier ein Beispiel dafür:

<Display>
   <HorizontalResolution>1024</HorizontalResolution>
   <VerticalResolution>768</VerticalResolution>
   <ColorDepth>32</ColorDepth>
   <RefreshRate>60</RefreshRate>
</Display>

Lösche nun die gesamte (abgebildete) Sektion, inklusive der <Display> und </Display> Einträge und speichere die Datei. Dieser Schritt muss ggf. für alle eingebundenen und genutzten Betriebssystemquellen durchgeführt werden.

Nun sollte sich die Bildschirmauflösung dynamisch an die jeweiligen Monitore anpassen.

Der Beitrag Automatische Anpassung der Bildschirmauflösung erschien zuerst auf Workplace Management Blog.

Reihenfolge und Abhängigkeiten

Bezüglich der Reihenfolge der Verteilung hat die Reihenfolge (von oben nach unten) der Pakete im SoftwareDepot grundlegenden Einfluss. Diese Reihenfolge kann mit der Option „Reihenfolge“ auf dem Reiter „Version“ überschrieben werden. Hier werden die Software Pakete angegeben, die vor dieser Software installiert werden muss. Im Dialog „Abhängigkeiten“ können Pakete angegeben werden, die installiert sein müssen, damit diese Software auch installiert wird. Hierüber können auch „Verbote“ definiert werden. Dieses Paket wird nicht installiert, wenn bereits Software xy bereits installier ist. (Bespiele sind die Matrix42 Pakete SubDepot Services und DataCollector).

Betriebssystem Freigabe

Auf diesem Reiter werden die Betriebssysteme „angehakt“, auf denen die Setup.inf erfolgreich ausgeführt wird und getestet ist. Ist ein Paket nur für Windows 7 freigegeben und wird einem Windows XP Computer in der EMC zugewiesen, wird die Setup.inf erst gar nicht „angestartet“, da das Paket nicht dafür freigegeben wurde.

Computerumgebung 

Die Einstellungen auf dem Reiter Computerumgebung wirken sich genauso auf die Verteilung aus, wie auf dem Reiter Betriebssystem. Hier können jedoch Rahmenbedingungen bzgl. RAM, Festplattenplatz, etc. definiert werden. Sind die Rahmenbedingungen nicht erfüllt, startet die Installation erst gar nicht. Die „nicht erfüllte Voraussetzung“ wird mit einer „Requirement“ Meldung im SoftwareDepot Log dokumentiert.

Sonstiges

Wie der Name schon sagt, vereinen sich auf dem Reiter „Sonstiges“ alle weiteren Einstellungen.  Die Einstellungen „Externes Installationsprogramm“ und „Installationsprogramm asynchron aufrufen“ werden in den allermeisten Fällen nicht genutzt und haben mehr eine „historische“ Bedeutung. Beim zweiten Falle, werden die Pakete nicht in einer Stapelverarbeitung eins nach dem anderen installiert, sondern eine weitere Installation wird bereits gestartet. Dies führt in den überwiegenden Fällen zu Installationsproblemen!

„Nur bei Verteilung“ benutzen steuert, ob eine Software im Kiosk sichtbar ist oder nicht, oder nur mittels EMC/EWC verteilt werden kann. „Erlaube Deinstallation“ hat auch nur Einfluss auf das Kiosk und ermöglicht dem Endbenutzer nur eine Deinstallation einer Software zu starten, wenn dies hiermit „erlaubt“ wird.

„Installation weiterer Pakete nicht fortsetzen“ ist interessant zu nutzen, wenn eine abhängige Software-Installation einen Neustart oder ähnlich voraussetzt. Sehr häufig ist dies nach einem Windows Service Pack oder Internet Explorer Update nötig, damit die nachfolgenden Installationen die richtige Version erkennen (mittlerweile auch durch den Wert SetReboot 5 in der Setup.inf steuerbar).

Die Option „Installationskontext“ erlaubt einem einzustellen, ob das Paket nur vor oder nach der Anmeldung ausgeführt werden darf, oder ob es „immer“ installiert werden kann. Wenn das Paket auf eine Abfrage vom Benutzer warten soll, so wäre „Nur nach der Benutzeranmeldung“ passend.

„Installationsdauer“ wird dem Benutzer vor bzw. während der Installation im sogenannten Z-Dialog angezeigt. Der Z-Dialog zeigt die anstehenden Installationen an und gibt ggf. die Möglichkeit  die Installation zu verschieben (je nach Agenten-Konfiguration und Verteilungsoption des Software-Paketes).

„Lizenzen“ – diese Eingabe kann komplett „vergessen“ werden und wird nicht mehr unterstützt.

„Sync. Bandbreite“ bezieht sich auf die Synchronisation der Pakete auf den Client. So kann hier für ein großes Software-Paket eine minimale verfügbare Bandbreite zur Synchronisation der Quellen auf den Client angegeben werden.

Die Eigenschaft „Pakettyp“ ist für die Zusammenarbeit mit dem Matrix42 Service Store relevant. Somit können die Pakettypen beim Import bereits unterschieden werden, wie diese weiter im Service Store zur Verfügung stehen bzw. „verarbeitet“ werden.

Prüfung

Auf diesem Reiter ist der Wert für Prüfdatei/Prüfwert noch sehr interessant. Nur wenn diese Kriterien erfüllt sind, findet die Ausführung des Software-Paketes statt. Hier lohnt sich ein Blick in die Matrix42 Pakete “Patch-Management (Install) bzw (Fix)“.

SetupInfo

Die Nutzung der Paketinformationen durch den bzw. die Paketierer habe ich hier bereits erklärt.

Registrierung

Auf dem Reiter Registrierung wird beim Import der Wert für Schlüssel aus der Setup.inf und der Eigenschaft „MachineKeyName“ übernommen. Dazu sind die bereits vorhandenen Blog Beiträge wichtig zu lesen:

• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Empirum Paket – Registry, SoftwareDepot, Version

AUT

Auf dem Reiter AUT kann eine zu „überwachende“ EXE Datei einem Software-Paket zugeordnet werden. Damit wird die Zuordnung und Erkennung auf dem Eigenschaften Reiter eines Computerobjektes vorgenommen.

Variablen

Hier werden Variablen, die zu dem Softwarepaket gehören und mit der Setup.inf importiert wurden angezeigt.

Der Beitrag Einbinden eines Software-Paketes in Empirum (Erweitert). erschien zuerst auf Workplace Management Blog.

Wenn man nicht weiß, in welcher Datei sich die Einstellung niederschlägt bzw. in welcher Datei die Anpassung vorgenommen werden, kann man die Änderung mittels des PackageWizards und dem Differenzanalyseverfahren (Diff) festhalten.

Variante 1 – Diff bzw. Differenzanalyseverfahren

Das bedeutet, man startet den PackageWizard und wählt den Punkt „Systemanalyse vor und nach der Installation …“ und führt den PreScan durch. Ist der PreScan abgeschlossen, führt man seine Änderung der Einstellung durch bzw. kopiert eine Datei manuell in das Benutzerverzeichnis. Anschließend führt man den PostScan durch. Ist der PostScan erfolgreich abgeschlossen, führt man den PackageWizard Assistenten bis zum Ende durch. Kopieren Sie die Datei nicht auf den EmpirumServer. Wenn man den Haken bei Datei mit dem PackageEditor öffnen wählt, kann man sich die kommenden Schritte sparen.

Nun kann man die gerade erzeugte Setup.inf Datei öffnen. Geben Sie dazu %TEMP% im Windows Explorer ein. Hiermit landet man direkt im temporären Verzeichnis. Hier sollte ein Verzeichnis mit der Herstellerbezeichnung (aus der Eingabe im PackageWizard) vorhanden sein. Darunter befindet sich ein Verzeichnis mit dem Softwarenamen, dann der Version und dann „Install„. Im „Install“ Verzeichnis befindet sich die gerade erstellte Setup.inf.
Jetzt können Sie den Kopierbefehl, als auch die dazugehörige Datei in Ihr ggf. bereits vorhandenes Paket einfügen bzw. übernehmen.

Variante 2 – Empirum Kopierflag CLIENT (pro Benutzer):

Ergänzen der Setup.inf wie folgt. Eintragen eines Sektionsaufrufes unterhalb von [Product] in der passenden Reihenfolge. Vorteilhaft ist es, wenn man den benutzerspezifischen Teil nach der eigentlichen Installation des Programmes ausführt, hier mit Set:Product symbolisiert. Zusätzlich muss die benutzerspezifische Datei (hier: Freecommander.ini) im Ordner (hier: APPDATA\Freecommander) des Programmes unter „Source“ (hier: Packages\<Hersteller>\<Softwarename>\<Version>\) abgelegt werden.

Kopierflags

Die Datei wird in diesem Falle bei einer Deinstallation auch wieder vom Computer entfernt. Ist dies nicht gewünscht, da dann Einstellungen nicht zu einer neu installierten Version übernommen werden, so kann zu den vorhandenen Flags CLIENT ALWAYS auch noch das DONTDELETE hinzugefügt werden. Ein weiterer Blog Artikel zum Kopierbefehl kann hier eingesehen werden, alle Kopierflags sind hier aufgeführt.

ALWAYS

Das Flag ALWAYS überschreibt eine gegebenenfalls existierende Datei. Bei benutzerspezifischen Einstellungen sollte man das Flag ALWAYS immer setzen, da die installierten Programme zumeist eine vordefinierte Einstellungsdatei einrichten und diese hat dann das Datum der Installation der Software und die eigene Einstellungsdatei hätte ggf. ein älteres Datum und würde im Standard nicht installiert/kopiert werden. Mit ALWAYS stellt man somit sicher, dass die eigene Datei mit Einstellungen eine gegebenenfalls vorhandene Datei überschreibt!

[Product]
...
;---Beispiel für eine Installation, diese Zeile nicht übernehmen! 
#Set:Product 
...
#Benutzereinstellungen 
...

[Benutzereinstellungen]
1:APPDATA\Freecommander\Freecommander.ini, %APPDATA%, CLIENT ALWAYS, 0

Variante 3 – Empirum Kopierbefehl copy

Ergänzen der Setup.inf wie folgt. Eintragen zweier Sektionsaufrufe unterhalb von [Product] in der passenden Reihenfolge. Vorteilhaft ist es, wenn man den benutzerspezifischen Teil nach der eigentlichen Installation des Programmes ausführt, hier mit Set:Product symbolisiert. Die Sektion „BenutzereinstellungenMachine“ kopiert die Einstellungsdatei (hier wurde eine config.xml Datei angenommen) auf den Computer zur lokalen Ablage. Die Sektion „BenutzereinstellungenClient“ kopiert die Datei dann pro Benutzer in das angegebene Verzeichnis. Zusätzlich muss die benutzerspezifische Datei im Ordner des Programmes unter „Source“ (hier: Packages\<Hersteller>\<Softwarename>\<Version>) abgelegt werden.

[Product]
...
;---Beispiel für eine Installation, diese Zeile nicht übernehmen!
#Set:Product 
...
 #BenutzereinstellungenMachine, MACHINE 
#BenutzereinstellungenClient, CLIENT 
...

[BenutzereinstellungenMachine]
;---kopiert die Einstellungsdatei im Maschinenteil auf den Computer 
-DEL "%APP%\Config.xml"
Copy "%SRC%\Config.xml" "%APP%\Config.xml"

;---Alternative für einen anderen lokalen Ablageort der Konfigurationsdatei 
;-DEL "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\Config.xml" 
;Copy "%SRC%\Config.xml" "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\Config.xml"

[BenutzereinstellungenClient] 
;---kopiert die Einstellungsdatei im Benutzerteil von der lokalen Ablage in das benutzerspezifische Verzeichnis 
Copy "%APP%\Config.xml" "%AppData%\<Hersteller>\Config.xml"

;---Bei einem alternativen lokalen Ablageort der Konfigurationsdatei 
;Copy "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\Config.xml" "%AppData%\<Hersteller>\Config.xml"

;---Falls bei einer Deinstallation auch die Einstellungen wieder entfernt werden sollen. 
;---Achtung, somit werden Einstellungen nicht in eine neue Version übernommen, da die Config.xml beim Deinstallieren gelöscht wird. 
-DEL "%AppData%\Config.xml"

Setup.exe Aufruf

Als letztes ist es wichtig, dass dem Paket beim Einbinden in das SoftwareDepot auch mitgeteilt wird, das ein Benutzertzeil ausgeführt werden muss. Dies wird auf dem Reiter „Prüfung“ im Feld „Befehl“ vorgenommen. Weitere Informationen dazu sind in diesem Artikel vermerkt.

Der Beitrag Setup.inf – Datei pro Benutzer kopieren erschien zuerst auf Workplace Management Blog.

Der Beitrag Aktivierung / Deaktivierung der Webanalyse erschien zuerst auf Workplace Management Blog.