You searched for setup.inf IF EXIST - Workplace Management Blog https://www.wpm-blog.de/ ... ideas and solutions making workplace management easier Sun, 24 Nov 2024 16:33:30 +0000 de hourly 1 https://wordpress.org/?v=6.1.7 Empirum Setup.inf – Reparatur Unattended Setup https://www.wpm-blog.de/empirum-setup-inf-reparatur-unattended-setup/ https://www.wpm-blog.de/empirum-setup-inf-reparatur-unattended-setup/#respond Sun, 02 Jul 2023 17:46:31 +0000 https://www.wpm-blog.de/?p=2877 Vor einiger Zeit hatte ich eine Serie begonnen, die unattended.inf Paketvorlage zu verbessern. Dazu hatte ich bereits zwei Blog Beiträge geschrieben. Leider hatte mich die mangelnde Zeit etwas vom Pfad abgebracht, diese Serie weiter zu … Weiterlesen

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

]]>
Vor einiger Zeit hatte ich eine Serie begonnen, die unattended.inf Paketvorlage zu verbessern. Dazu hatte ich bereits zwei Blog Beiträge geschrieben. Leider hatte mich die mangelnde Zeit etwas vom Pfad abgebracht, diese Serie weiter zu vervollständigen. Diesem will ich nun nachkommen. Wer diese Beiträge noch nicht gelesen hatte, dem stelle ich diese Beiträge hier nochmals vor:

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

]]>
https://www.wpm-blog.de/empirum-setup-inf-reparatur-unattended-setup/feed/ 0
ErrorLevel Abfrage bei Unattended Installationen https://www.wpm-blog.de/empirum-errorlevel-abfrage-bei-unattended-installationen/ https://www.wpm-blog.de/empirum-errorlevel-abfrage-bei-unattended-installationen/#respond Mon, 19 Oct 2020 19:33:23 +0000 https://www.wpm-blog.de/?p=2652 Matrix42 liefert eine Setup.inf Vorlage mit, die für „Silent“ Installationen von EXE Dateien genutzt werden kann. Diese Vorlage ist jedoch meines Erachtens sehr „rudimentär“ und an einer Stelle sogar gefährlich bis falsch. In den kommenden … Weiterlesen

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

]]>
Matrix42 liefert eine Setup.inf Vorlage mit, die für „Silent“ Installationen von EXE Dateien genutzt werden kann. Diese Vorlage ist jedoch meines Erachtens sehr „rudimentär“ und an einer Stelle sogar gefährlich bis falsch. In den kommenden Tagen möchte ich mit Euch diese Vorlage Stück für Stück verändern. Wahrscheinlich gibt es am Ende immer noch „Luft“ nach oben, da jeder noch ein paar andere Vorstellungen, Vorlieben, etc. hat. Doch halten wir es Mal wie mit einer Fahrt in den Urlaub – „der Weg ist das Ziel“.

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.

]]>
https://www.wpm-blog.de/empirum-errorlevel-abfrage-bei-unattended-installationen/feed/ 0
Empirum Agent Steuerung per Registry https://www.wpm-blog.de/empirum-agent-steuerung-per-registry/ https://www.wpm-blog.de/empirum-agent-steuerung-per-registry/#comments Fri, 20 Sep 2019 07:23:37 +0000 https://www.wpm-blog.de/?p=2311 Nachdem ich die Tage beim Kunden für mein Gedächtnis gelobt wurde, habe ich es als Ansporn gesehen, alle mir bekannten Möglichkeiten zur Steuerung des Empirum Agenten per Registry Einträge zusammenzufassen. Der größte Teil der Einträge … Weiterlesen

Der Beitrag Empirum Agent Steuerung per Registry erschien zuerst auf Workplace Management Blog.

]]>
Nachdem ich die Tage beim Kunden für mein Gedächtnis gelobt wurde, habe ich es als Ansporn gesehen, alle mir bekannten Möglichkeiten zur Steuerung des Empirum Agenten per Registry Einträge zusammenzufassen. Der größte Teil der Einträge kommt aus dem ganz offiziellen PDF zum UEM Agenten der Matrix42. Einige andere Eigenschaften aus den jeweiligen „Neue Funktionen und Änderungen“ Dokument. Somit habe ich hier weitestgehend nichts neu erfunden, sondern mehr zusammengetragen. Wobei einige wenige Hinweise, meines Wissens nach, nicht ganz so öffentlich zugänglich sind. 

Die nachfolgende Auflistung enthält zumeist eine Kurzbeschreibung, den Registry Wert in der .reg und Setup.inf Syntax und einen möglichen Quellenverweis.
Falls Ihr noch Werte kennt, die hier fehlen, so nutzt bitte die Kommentarfunktion oder schickt mir eine E-Mail.

Danke und Grüße – Jochen

Hinweis: Bei der Übernahme der Registry Werte in Empirum o.ä. bitte auf das Format der Hochkommas achten. Gerne wird ein „falsches“ Format der Hochkommas in den Editor übernommen. Zur Sicherheit im Editor oder in der Setup.inf die Hochkommas nochmals überschreiben.

Prüfung auf ausstehenden Windows Reboot verhindern

In der Registry kann festgelegt werden, dass der Agent die Überprüfung ausstehender Windows Reboots (z.B. vorhandene Pending.xml) nicht durchführt und anstehende Software Management-Aktionen durchführt. Die Prüfung kann durch Setzen des Registry Wertes WindowsUpdateRebootCheck unter dem Schlüssel HKLM,Software\Matrix42\Agent auf 0 deaktiviert werden.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootCheck“=dword:00000000

HKLM,“SOFTWARE\Matrix42\Agent“,“WindowsUpdateRebootCheck“,0x00010001,0

Weiterführende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2017/Matrix42_Empirum_17.0_New_Features_and_Changes_DE.pdf

Erweiterungen zur Neustart Steuerung (UEM Agent 2009.x und neuer)
Der Wert „2“ ist der neue „Standard“, wie wenn kein Wert gesetzt ist. Nach einer Verzögerung erscheint ein UEM Agent Fenster, das den Benutzer zu einem Neustart auffordert. Wem dieses Verhalten nicht gefällt, kann den Wert auf „1“ setzen, welches dem alten Standard entspricht (keine UEM Agent Aktivitäten bis ein Neustart durch den Anwender durchgeführt wurde).

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootCheck“=dword:00000002

Das „neue“ Reboot-Verhalten wird verzögert initiiert. Wer möchte kann den Verzögerungswert (in Sekunden) anpassen. Wenn kein Wert gesetzt ist, ist der Standardwert 15 Minuten (900 Sekunden).

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootDelaySeconds“=dword:00000120

Weiterführende Informationen: https://marketplace.matrix42.com/details/uem-agent-windows-release/

Getaktete Verbindung erkennen (ab UEM Agent 1808)

Der UEM Agent Windows erkennt eine getaktete Verbindung und schreibt am Anfang des Pollings einen Registry Schlüssel:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
“ NetworkCostType“ (DWORD) = Wert der Microsoft API
Mögliche Werte:
0 – Unknown: Cost information is not available.
1 – Unrestricted: The connection is unlimited and has unrestricted usage charges and capacity constraints.
2 – Fixed: The use of this connection is unrestricted up to a specific limit.
3 – Variable: The connection is costed on a per-byte basis.

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Globaler Silent Level (UEM Agent)

Alle zu installierenden Software-Pakete werden mit einem Silent Wert ausgeführt. Es greifen keine paketspezifischen Werte aus dem Feld „Befehl“ der Paketeigenschaft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„GlobalSilentLevel“=dword:00000004
Einschränkungen aktuell: Pakete, die eine Eingabe erfordern, funktionieren nicht mit dem Modus “0” und “1”.
Wenn der Eintrag (GlobalSilentLevel) nicht vorhanden ist, funktioniert es wie unter dem Advanced Agent und die individuellen Paket Parameter werden angezogen.

HKLM,“SOFTWARE\Matrix42\Agent“,“GlobalSilentLevel“,0x00010001,4
oder
-HKLM,“SOFTWARE\Matrix42\Agent“,“GlobalSilentLevel“

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

InstallAtShutdown – Shutdown nach der OS Installation (UEM Agent)

Wenn der untenstehende Registry Key auf 1 steht, dann ist der „InstallAtShutdown“ Modus für den Agent aktiv.
Der Wert kann jedoch auch gezielt gesetzt werden, um die Funktionalität zu nutzen.
Dieser Wert kann beispielsweise in der UEMAgent.bat gesetzt werden um den Computer nach der OS Installation komplett auszuschalten.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„InstallAtShutdown“=dword:00000001

HKLM,“SOFTWARE\Matrix42\Agent“,“InstallAtShutdown“,0x00010001,1

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Ausblenden der Option Installation beim Herunterfahren (UEM Agent)

Die Funktion „Installation beim Herunterfahren“ kann für Anwender verborgen werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„AllowPostponeUntilShutdown „=dword:00000000

HKLM,“SOFTWARE\Matrix42\Agent“,“AllowPostponeUntilShutdown“,0x00010001,0

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Suspend Modus (UEM Agent)

Mit einem Registry-Key kann der UEM Agent in einen Modus versetzt werden, in dem
keinerlei Polling-, Download- oder Installationsaktionen durchgeführt werden. Intern wird
dieser Modus für den Auto Update verwendet. Bei Bedarf kann man diesen Modus
beispielsweise verwenden um beim Aufbau einer VPN-Verbindung über ein Satellitentelefon
den möglichen Datenverbrauch des Agent zu unterbinden.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„Suspenduntil“ (Typ: STRING) = Endedatum des Suspendmodes
Der Wert gibt den Termin zur Beendigung des Suspendmode an. Beispielsweise 2018-12-
24T18:00. Jeder angegebene Wert, der nicht vom Agent als ISO Zeit-Wert in der
Vergangenheit erkannt wird, wird den Agent pausieren

Paket Validierung

Validierung von Paketen für UEM Agent aktivieren (UEM Agent 1903)
Um die Validierung von Software Paketen auf Client-Seite zu aktivieren setzten Sie „CheckPackageHash“ als DWORD auf einen Wert größer 0 in der Registry.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„CheckPackageHash“=dword:00000001

HKLM,“SOFTWARE\Matrix42\Agent“,“CheckPackageHash“,0x00010001,1

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Behandeln von fehlerhaften Paket Validierungen

Stellt die Paketvalidierung einen Unterschied der Hashwerte auf dem Server zu dem auf dem Client fest, wird für dieses Paket der Zähler FailedInstallationRetries hochgezählt.
Dieses Verhalten lässt sich mit dem Schlüssel CountHashValidationErrors als DWORD gezielt steuern. Existiert der Eintrag nicht oder besitzt einen Wert ungleich „1“, so wird der Zähler nicht hochgezählt (Standard). Existiert der Eintrag und hat den Wert „1“, so wird der FailedInstallationRetries Zähler hochgezählt.

HKLM,“SOFTWARE\Matrix42\Agent“,“CountHashValidationErrors“,0x00010001,1

Feedback URL ausschalten/anpassen (UEM Agent)

Die Anzeige des Icons und der Link zum Matrix42 Feedback Portal ausschalten.
Wenn man eine URL angibt, kann man auf ein eigenes Portal bzw. Internetseite verzweigen.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„Feedback_URL“=““

HKLM,“SOFTWARE\Matrix42\Agent“,“Feedback_URL“,0x00000000,““

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

UEM Agent Autoupdate Zeitraum beeinflussen (ab UEM Agent 1811)

Wenn man die UEM Agent Autoupdate Funktion nutzt, so kann man den Zeitraum des automatischen Updates beeinflussen.
Dazu gibt es zwei Einträge, die eine Angabe von Minuten (Typ: DWORD) annehmen.

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„MinAutoUpdateDelayAfterSystemStart“=dword:00000015
„MaxAutoUpdateDelayAfterProcessStart“=dword:00000030

HKLM,“SOFTWARE\Matrix42\Agent“,“MinAutoUpdateDelayAfterSystemStart“,0x00010001,15
HKLM,“SOFTWARE\Matrix42\Agent“,“MaxAutoUpdateDelayAfterProcessStart“,0x00010001,30

Hinweise: MaxAutoUpdateDelayAfterProcessStart muss mindestens das Doppelte des Wertes MinAutoUpdateDelayAfterSystemStart sein. Die Werte in Minuten nutzt der UEM Agent beim Start des Dienstes um einen zufälligen Wert in diesem Zeitraum zu ermitteln. Wenn der Dienst-Neustart nach dem ersten Wert (Min…) liegt, dann ist nur noch der Wert (Max…) relevant.

Anpassen der Berechtigungen auf den Agent Cache

Um eine größtmögliche Sicherheit zu gewährleisten setzten der Advanced und der UEM Agent die lokalen NTFS Berechtigungen bei jedem Start des Agent nach den Matrix42 Vorgaben auf den Empirum Agent Cache (zumeist C:\EmpirumAgent). Um Kunden spezielle Szenarien zu ermöglichen kann dieses Verhalten mit einem Registry-Wert unterbunden werden, wenn beispielsweise der lokale Benutzer Zugriff auf Dateien im Cache-Verzeichnis benötigt.
Registry Schlüssel „HKLM\SOFTWARE\Matrix42\Agent,SetNTFSCacheRights“, 0 = Keine Anpassung der NTFS Rechte, 1 oder nicht vorhanden (Standard) = Anpassung der NTFS Rechte, 2 = Der Agent setzt die Standard Zugriffsrechte, jedoch keine Zugriffsrechte für „Jeder“ auf das „User“-Verzeichnis (ab UEM-Agent SFR 2011.1.2 )

HKLM,“SOFTWARE\Matrix42\Agent“,“SetNTFSCacheRights“,0x00010001,0

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2018/Matrix42_Empirum_18.0_Update2_New_Features_and_Changes_DE.pdf

Prüfung auf Scriptdateien für Kiosk Pakete

Ab dem UEM Agent 2009.1.2 findet für Pakete im Kiosk keine Prüfung auf Existenz der Scriptdateien auf dem Server statt. Dies führt auf den Depotservern zu einer deutlichen Lastreduzierung, insbesondere bei Verwendung von http(s). Die Prüfung der Scriptdateien auf dem Depotserver kann über folgenden Registry Key wieder aktiviert werden:

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„UseCheckFileForKiosk“=dword:00000001

Zurücksetzen der fehlgeschlagenen Installationen

Die Anzahl der auf dem Computer fehlgeschlagenen Softwareinstallationen werden unter dem Registry Baum „HKLM\SOFTWARE\Matrix42\Agent\software“ abgelegt.
Diese Pakete werden beim Erreichen des jeweiligen Maximalwertes nicht erneut ausgeführt. Damit die Pakete erneut ausgeführt werden, muss man entweder das Paket auf dem entsprechenden Computer „reinstallieren“, oder den Wert im Agent-Template erhöhen – das gilt dann jedoch für alle fehlgeschlagenen Installationen. Wenn man den Computer „zwingen“ möchte, die Ausführung der Installation aller fehlgeschlagenen Pakete nochmals zu starten, kann man alternativ den nachfolgend genannten Registry-Baum löschen.
Es besteht die Möglichkeit das per Paket, oder auch als externes Programm in der Management Console (erforderliche Rechte vorausgesetzt), einzubinden.

Beispiel für einen Eintrag in einem Software Paket:
-HKLM,“SOFTWARE\Matrix42\Agent\software“

Beispiel für einen externen Aufruf:
reg delete \\%Computername%\HKLM\SOFTWARE\Matrix42\Agent\software /f

Verhalten bei Problemen beim Paket-Download (ab UEM Agent 2203.1.2 SFR)

Sollte es beim Herunterladen eines Paketes zu Problemen kommen (z. B. temporäre Netzwerkfehler, Zugriffsprobleme), dann kann der Agent veranlassen, dass der Vorgang automatisch wiederholt werden soll. Hierfür kann man die Anzahl der erneuten Versuche (Standard: 5) sowie die Pause zwischen den Versuchen in Sekunden (Standard: 60) einstellen. Der Standard kann in der Registry überschrieben werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„RetryTransferRepetitionLimit“=dword:00000005
„RetryTransferPause“=dword:00000060

Weitergehende Informationen: https://m42marketplacemediathek.blob.core.windows.net/matrix42-ag-pub/2022/03/Matrix42-UEM-Agent-Windows-2203_1_2-SFR-EN.pdf

Der Beitrag Empirum Agent Steuerung per Registry erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-agent-steuerung-per-registry/feed/ 4
SystemShutdown vs. SetReboot https://www.wpm-blog.de/systemshutdown-vs-setreboot/ https://www.wpm-blog.de/systemshutdown-vs-setreboot/#respond Thu, 18 Jul 2019 18:42:07 +0000 https://www.wpm-blog.de/?p=2222 Vielleicht ist dem ein oder anderen schon der Neustart Dialog beim Installieren des EmpirumAgenten aufgefallen, der keine Möglichkeit hat den anstehenden Neustart zu verschieben? Wenn nicht, so schaut der Dialog aus: Damit sind wir auch … Weiterlesen

Der Beitrag SystemShutdown vs. SetReboot erschien zuerst auf Workplace Management Blog.

]]>
Vielleicht ist dem ein oder anderen schon der Neustart Dialog beim Installieren des EmpirumAgenten aufgefallen, der keine Möglichkeit hat den anstehenden Neustart zu verschieben?

Wenn nicht, so schaut der Dialog aus:

Damit sind wir auch schon mitten im Thema. Der SystemShutdown Befehl der Empirum Setup.inf gibt dem Benutzer einen Hinweis, dass ein Neustart ansteht, den der Benutzer je nach Parameter nicht umgehen kann. Darin unterscheidet sich der SystemShutdown gegenüber dem Reboot= bzw. SetReboot Befehl. Der SetReboot Befehl gibt die Neustart Anforderung an den Agenten weiter und ermöglicht somit dem Benutzer, dass dieser den Neustart, je nach Agenten Konfiguration, verschieben kann. Bei BIOS Updates oder Windows Feature Upgrades ist dies, nach der teilweise vorgenommenen Änderungen, nicht unbedingt gewünscht. An dieser Stelle kann der SystemShutdown eingesetzt werden, um dem Benutzer keine Wahl zu lassen, wann er den Computer neu starten möchte.

SystemShutdown <ShutdownText>, <Reboot>, <Force>, <Timeout in Seconds>, <Asynchron>
Befehl Bemerkung
<ShutdownText> Text für den Neustart Dialog
<Reboot> 0=Herunterfahren,
1=Herunterfahren+Neustarten
<Force> 1=die Applikation(en) mit Zwang beenden,
0=nicht forciert die Applikation(en) schließen
<Timeout in Seconds> Wartezeit in Sekunden, bevor der Dialog geschlossen wird.
<Asynchron> 0=synchon,
1=asynchron

Beispiel:

SystemShutdown In fünf Minuten erfolgt ein Neustart!/nBitte beenden Sie alle offenen Anwendungen, 1, 1, 300, 1
Befehl für das Auslösen eines „SystemShutdowns“ innerhalb der Setup.inf:
[Strings:07]
ShutdownTextDesc=Das BIOS Update erfordert einen Neustart des Computers.\nSpeichern Sie Ihre Daten und schließen Sie alle offenen Anwendungen.\n\nKlicken Sie 'OK' um den Computer neu zu starten.

[Strings:09]
ShutdownTextDesc=The BIOS update needs to restart your computer.\nSave your work and close all open applications.\n\nClick 'OK' to restart your computer.

[Set:FinishedBIOSUpdate]
If DoesProcessExist ("Explorer.exe") == "1" Then "UserIsLoggedOn" Else "NoUserIsLoggedOn" EndIf

[UserIsLoggedOn]
SystemShutdown %ShutdownTextDesc%, 1, 0, 600, 1

[NoUserIsLoggedOn]
SystemShutdown %ShutdownTextDesc%, 1, 0, 15, 1

Der Beitrag SystemShutdown vs. SetReboot erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/systemshutdown-vs-setreboot/feed/ 0
Empirum – Übernehmen von vorhandenen Installationen https://www.wpm-blog.de/empirum-uebernehmen-von-vorhandenen-installationen/ https://www.wpm-blog.de/empirum-uebernehmen-von-vorhandenen-installationen/#comments Wed, 16 Aug 2017 10:25:52 +0000 https://www.wpm-blog.de/?p=1884 Wenn man mit der Empirum Softwareverteilung nicht auf der „grünen Wiese“ beginnt, jedoch trotzdem die Zuweisung der Software anhand der Konfigurationsgruppen vornehmen möchte, läuft man Gefahr das eine Installation einer bereits vorhandenen Software startet. Gerade bei … Weiterlesen

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

]]>
Wenn man mit der Empirum Softwareverteilung nicht auf der „grünen Wiese“ beginnt, jedoch trotzdem die Zuweisung der Software anhand der Konfigurationsgruppen vornehmen möchte, läuft man Gefahr das eine Installation einer bereits vorhandenen Software startet. Gerade bei größeren Software Installationen, wie einem Microsoft Office, SAP Client, Lotus Notes Client, o.ä. möchte man genau dies vermeiden. Auf der anderen Seite möchte man trotzdem die Konfigurationsgruppen und ihre Vorteile nutzen.

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.

]]>
https://www.wpm-blog.de/empirum-uebernehmen-von-vorhandenen-installationen/feed/ 5
Empirum Treiberintegration – einfacher gemacht! https://www.wpm-blog.de/empirum-treiberintegration-einfacher-gemacht/ https://www.wpm-blog.de/empirum-treiberintegration-einfacher-gemacht/#comments Mon, 16 Mar 2015 21:17:58 +0000 https://www.wpm-blog.de/?p=1100 Heute möchte ich meine aktuelle und erprobte Idee zur einfacheren Treiberintegration und Hardwareprofilhandling erläutern. Stand heute muss man die Treiber für Netzwerk und Grafikkarte über den Hardwareassistenten in den OS-Installer integrieren und für alle weiteren … Weiterlesen

Der Beitrag Empirum Treiberintegration – einfacher gemacht! erschien zuerst auf Workplace Management Blog.

]]>
Heute möchte ich meine aktuelle und erprobte Idee zur einfacheren Treiberintegration und Hardwareprofilhandling erläutern. Stand heute muss man die Treiber für Netzwerk und Grafikkarte über den Hardwareassistenten in den OS-Installer integrieren und für alle weiteren Geräte die Treiber über den Hardwareassistenten unter Sonstiges (Sonstige Hardware). Dann muss man nochmals die gerade eingebundenen Treiber einem neu erstellten Hardwareprofil zuordnen. Dieser Vorgang kann sehr aufwändig sein und ist nochmals aufwändiger, wenn man ein und die gleiche Hardware in mehrere unabhängige Empirum Systeme integrieren muss (wie z.B. Test, QA und Produktion). Zusätzlich gibt es immer wieder die Frage, wie man mit Software verfährt die nur für diese Hardware bzw. diesen Hardwaretypen gilt.

Das im Anhang zusammengestellte Verfahren aus Skripten erweitert den OS-Installer bzw. die Installation von Computern.

Meines Erachtens bietet dies dann:

  • Einfachere Integration von einer Vielzahl von Treibern.
  • Einfachere Aktualisierung der Treiber in der Test und Integrations-Phase
  • Schnellere Einbindung neuer Hardwaretypen
  • Einfachere Übernahme in einer andere Empirum Installation (Test, QA, Produktion)
  • Einfache Installation von hardwarespezifischen Treibern und Software per EXE und MSI.

Vorbereitungen

Verzeichnisse und Skripte

Was ist vorzubereiten, was wurde angepasst und was ist in der Download Datei?

  • End_winvista.eis Script
  • Vorlage (Template) für ein Hardwareprofil mit div.Logik
  • Batch-Datei zur Installation von hardwarespezifischer Software je Hardwareprofil nach der OS-Installation

Angepasstes End_winvista.eis Script

Die angepasste „end_winvista.eis“ prüft, ob im Hardwareprofil-Ordner ein PnP Ordner vorhanden ist. Wenn dieser existiert, wird der Pfad zum PnP Ordner zu den Plug & Play-Pfaden für die OS-Installation hinzugefügt. Das bedeutet, dass dieser Ordner während der Windows Installation nach passenden Treibern durchsucht wird. Es ist zu prüfen, ob bereits Änderungen an der End_winvista.eis (Empirum\Empinst\Wizard\Scripts2\Custom) durchgeführt wurden. Wenn dies der Fall ist sind die Änderungen zusammenzuführen (die beigefügten Zeilen werden dann angehängt).

Hinweis: Zwei Aufrufe in der End_winvista.eis sind Empirum Versions abhängig. Nur die Zeilen der eingesetzten Empirum Version aktivieren!

Batch Datei für den Aufruf nach der OS-Installation

  • Installation des .NET Framework 3.5 SP1 oder 4.0 und ggf. weiterer Hotfixe (optional)
  • Aufruf einer Setup.inf, falls vorhanden, zur Installation weiterer Treiber und Software (siehe Hardwareprofil)
  • Installation des Internet Explorers (optional)
  • Schreiben von Hardware und OS-Installations Informationen in die Registry für die spätere Verwendung (optional – nicht enthalten)
  • Aufruf der von Matrix42 gelieferten EmpirumAgent.bat

Kopieren der Empirum\Configurator\User\PostOSInstallation_W<OS><Architektur>.bat in den Empirum\Configurator\User Ordner. Einige Treiber und zusätzliche Software setzen das .NET Framework voraus, weshalb es hier direkt installiert wird. Hier wird entweder das .NET Framework über ein vorhandenes Paket installiert, oder separat. Wenn ein Paket vorliegt, wird der Aufruf zur Installation des .NET Framework 4.0 adaptiert, ansonsten verfährt man wie bei .NET Framework 3.5 aufgezeigt. Die Quellen dazu müssen in diesem Fall noch integriert werden, wie in der „Missing Files.txt“ Datei angegeben.

Die Installation des Internet Explorers und des .NET Framework Paketes sind nicht zwingend erforderlich. Gerade das Paket für den Internet Explorer muss selbst beigesteuert werden.

EmpirumAgent.bat

Beim Aufruf zur Installation des Empirum-Agenten in der EmpirumAgent.bat wird an die Zeile ein /X8 zur Unterdrückung des Neustarts angefügt. Dies sorgt für einen zuverlässigeren Ablauf der Skripte.

Call \\%EmpirumServer%\Configurator$\User\Setup.exe \\%EmpirumServer%\Configurator$\Packages\matrix42\EmpirumAgent\%EmpirumVersion%\Install\Setup.inf /S1 /X8

Betriebssystemvorlage

In der bzw. den genutzten Betriebssystemvorlagen wird der „Abschließende Befehl“ angepasst. Hier wird nun, je nach Betriebssystem die oben erstelle PostOSInstallation_W<OS><Architektur>.bat aufgerufen. Wenn Sie keine unterschiedlichen Installationen hinsichtlich des Betriebssystems an dieser Stelle durchführen, können Sie auch nur eine PostOSInstallation_W7.bat o.ä. erstellen.

Vorgehensweise und Ablauf

Was ist nun bei einer Einbindung eines neuen Hardwaretyps zu tun?

  • Einbinden der Netzwerkkarte, wie gehabt (optional)
  • Einbinden der Grafikkarte, wie gehabt (optional)
  • Erstellen eines Hardwareprofils mit der Angabe eines Ordner (letztes Feld) (Wichtig! – Namen merken!)
  • Kopieren der Vorlage in den erstellten Hardwareprofilordner
  • Ablegen der weiteren PnP Treiber in den Hardwareprofilordner\PnP
  • Einbinden von Treiber bzw. Softwareinstallationen per EXE/MSI (Ablage in HWspecificSW und anpassen der HWspecificSW\Setup.inf)

Erstellen eines Hardwareprofils

Der erste Schritt ist die Erstellung eines Hardwareprofils in der Management Console, unter Konfiguration, OS-Installer, Hardware, Hardwareprofil. Matrix42 Hilfe bis Punkt 14 durchführen.

Wo befindet sich das Hardwareprofilverzeichnis?

Anschließend wird der Ordner des erstellten Hardwareprofils mit den weiteren Treibern und ggf. Aufrufen versehen. Das Verzeichnis für das Hardwareprofil befindet sich je nach Architektur des Betriebssystems in den hier angegebenen Pfaden.

  • X86 = Empirum\Empinst\DRV\Win7\HWMisc
  • X64 = Empirum\Empinst\DRV\Win7\x64\HWMisc

Hardwareprofil

Es liegt eine Vorlage für ein Hardwareprofilordner in Empirum\Empinst\DRV\Win7\<Architektur>\HWMisc\_Template vor, damit alle Skripte zusammen funktionieren. Bitte jeweils für x86/x64 die Datei „Missing Files.txt“ in „HWspecificSW\VCRe100“ beachten, da hier ggf. noch die notwendigen Dateien abgelegt werden müssen. Nachfolgend ist die Wirkungsweise und Nutzung der Verzeichnisse und Skripte im Hardwareprofil erläutert. Es kann auch ohne die VCRedist100 Dateien getestet werden.

PNP Verzeichnis

Wie zuvor beschrieben, dient das PNP Verzeichnis zur Ablage mehrerer Verzeichnisse mit Treibern die während der OS-Installation durchsucht werden.  Das heißt, hier können weitere Verzeichnisse erstellt werden, die dann wiederum die notwendigen Plug & Play (kurz PnP) Treiber beinhalten. Dieses Verzeichnis kann auch mit einer Zusammenstellung von DoubleDriver befüllt werden, dass zuvor mit Hilfe eines Backups von einem vorhandenen System erstellt wurde. Eine andere Methode ist es die DriverPacks, DriverKits, SCCM Driver Packages, o.ä. die Hersteller wie Dell, Fujitsu, HP, uvm. bereitstellen, entpackt in den PnP Ordner abzulegen.

Install\Setup.inf

Die Setup.inf im Install Ordner sorgt für das Kopieren des HWspecifcSW Ordners nach %WinDir%\HWspecifiSW, damit er nach der OS-Installation zur Verfügung steht. In meinem Falle wird die Setup.inf des HWspecifSW Ordners durch die PostOSInstallation_W<OS><Architektur>.bat aus Empirum\Configurator\User aufgerufen. Zusätzlich kann hier bereits eine VCRedist Installation stattfinden, da dies von immer mehr Grafikkartentreibern vorausgesetzt wird.

Aufgrund dessen, dass im Hardwareprofilordner ein Install Ordner mit einer Setup.inf liegt, bedarf es der Anpassung der End_Winvista.eis (siehe oben). Matrix42 erstellt für jeden Treiberordner in dem sich eine Install\Setup.inf befindet einen Installationsbefehl (Früher: EmpirumJob=Yes) und nimmt diesen Ordner nicht in die PnP Pfade mit auf.

HWspecificSW Verzeichnis

In diesem Verzeichnis werden Treiber und Software für diesen Hardwaretyp abgelegt, die mittels einer EXE oder MSI installiert werden. Die Durchführung der Installation(en) findet nach der OS-Installation und vor der EmpirumAgent Installation im Kontext des lokalen Administrators statt. Beispielhafte Aufrufe dazu befinden sich in der HWspecificSW\Setup.inf Datei. Es bietet sich an, für die Treiber ggf. nochmals Unterverzeichnisse zu erstellen. Wird kein Treiber oder sonstige hardwarespezifische Installation nach der OS-Installation mehr benötigt, kann dieser Ordner auch weggelassen werden. Wenn die PostOSInstallation_W<OS><Architektur>.bat keine Setup.inf im %WinDir%\HWspecificSW findet, wird auch keine Installation durchgeführt.

Weitere Optimierung

PostDelaySeconds

Falls die PostDelaySeconds Variable noch nicht als Betriebssystemvariable in der Empirum Management Console vorhanden ist, so sollte diese noch erstellt und auf den Standardwert 180 gesetzt werden.

Empirum Management Console starten, im Menü unter  „Extras, Variablendefinition“

  • Variable: PostDelaySeconds
  • Variablentyp: Betriebssystem
  • Kontrollelement: Zahl
  • Null-Wert erlauben: Ja
  • Standardwert: 180

Falls der Wert trotz Standardwert nicht in die Variablendateien der Computer eingetragen wird, so hilft ein Setzen der Variable auf die oberste Konfigurationsgruppe und Aktivierung der „Zwangsvererbung“.

Fertig

Das sollten alle Schritte sein, damit die „Rädchen“ ineinander greifen. Diese Methode kann auch für Windows 8, 8.1 übernommen werden.

Viel Spaß und einfache Umsetzung wünsche ich Euch!

Benötigte Dateien für den oben genannten Ablauf:  TreiberFramework (2896 Downloads )

Der Beitrag Empirum Treiberintegration – einfacher gemacht! erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-treiberintegration-einfacher-gemacht/feed/ 23
UAC Meldungen bei der Reinstallation von MSI Paketen https://www.wpm-blog.de/uac-meldungen-bei-msi-paketen/ https://www.wpm-blog.de/uac-meldungen-bei-msi-paketen/#comments Tue, 09 Dec 2014 19:14:27 +0000 https://www.wpm-blog.de/?p=1444 Seit geraumer Zeit kann es zu UAC Meldungen bei der Reinstallation von MSI Paketen kommen. Ich habe auch schon die Meldung bekommen das es auch bei Installationen passiert ist. Was ist der Hintergrund und wie … Weiterlesen

Der Beitrag UAC Meldungen bei der Reinstallation von MSI Paketen erschien zuerst auf Workplace Management Blog.

]]>
Seit geraumer Zeit kann es zu UAC Meldungen bei der Reinstallation von MSI Paketen kommen. Ich habe auch schon die Meldung bekommen das es auch bei Installationen passiert ist. Was ist der Hintergrund und wie kann sich behelfen.

MS14-049

Microsoft hat im Oktober 2014 einen Patch unter der Bulletin ID MS14-049 veröffentlicht. Dieser Patch schließt eine Lücke im Windows Installer Dienst: „Vulnerability in Windows Installer Service Could Allow Elevation of Privilege“. Damit einhergehend werden für MSI Installationen neue Hash Werte ermittelt bzw. erstellt. Dies führt bei einer Reinstallation einer bereits installierten MSI Installation zu Problemen.

Mögliche Abhilfen

Whitelisting der Installation

Microsoft hat direkt Methoden zur Erstellung von Whitelist Einträgen, pro getätigter MSI Installation die repariert werden soll, angeboten. Bei dem Einsatz einer Softwareverteilung und einer Fülle an getätigter Software Installationen bereitet das keinen Spaß.
Die Informationen dazu wurden hier veröffentlicht.

Patch zur Behebung des UAC Problems

Im November wiederum wurde dann ein Hotfix veröffentlicht, der mit Hilfe eines Registry Keys generell die UAC Meldungen bei einem nicht vorhandenen MSI Hash Wert unterbinden soll.
Dieser Hotfix samt Vorgehensweise ist hier veröffentlicht.

Die Vorgehensweise mit dem nachgelagerten Hotfix scheint eine sinnvolle Behebung bzw. Umgehung der Problematik zu sein. Doch auch diese Umgehung scheint nach Rückmeldungen nicht zu 100% zu funktionieren.

Deinstallation des MS14-049

Letztendlich bleibt einem bei allen oben getroffenen Maßnahmen und keinem Erfolg (UAC Meldung erscheint trotz aller Maßnahmen) nur noch die Deinstallation des Patches.
Dies wiederum kann auch per Empirum geschehen. Dazu habe ich unten eine beispielhafte Deinstallationsroutine angehängt.

Ich drücke Euch die Daumen!

[Product]
#CheckWUSA, DONTDELETE
#Set:Product, DONTDELETE

[CheckWUSA]
Set VM_WUSA=%HKLM,"SYSTEM\CurrentControlSet\Services\wuauserv","Start"%
If "%VM_WUSA%" == "4" Then "EnableWUSA" EndIf

[EnableWUSA]
CallHidden sc config "wuauserv" start= demand error= ignore

[Set:Product]
SET QFE=2918614
Addmeter -1
DEL "%TEMP%\qfe.txt"
Callhidden %comspec% /C ECHO %sysdate% %systime% - Searching for installed hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C wmic.exe qfe >"%TEMP%\qfe.txt"
If DoesTextInFileExist ("%QFE%", "%TEMP%\qfe.txt") == "1" Then "UninstallQFE" ELSE "QFEnotExist" EndIf

[UninstallQFE]
Callhidden %comspec% /C ECHO %sysdate% %systime% - Installed hotfix found: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C ECHO %sysdate% %systime% - Uninstall hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
CallHidden sc config "wuauserv" start= demand error= ignore
Callhidden wusa /uninstall /kb:%QFE% /quiet /norestart
Set WusaError=%ErrorLevel%
IF %wusaError% == "3010" Then "RebootRequired" EndIf
Callhidden %comspec% /C ECHO %sysdate% %systime% - ErrorLevel: %WusaError% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C wmic.exe qfe >"%TEMP%\qfe.txt"
If DoesTextInFileExist ("%QFE%", "%TEMP%\qfe.txt") == "1" Then "SET:InstallationError" EndIf
Callhidden %comspec% /C ECHO %sysdate% %systime% - Successfully uninstalled hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
DEL "%TEMP%\qfe.txt"

[QFEnotExist]
Callhidden %comspec% /C ECHO %sysdate% %systime% - The following hotfix is not installed: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"

[RebootRequired]
SetReboot 1

[SET:InstallationError]
Callhidden %comspec% /C ECHO %sysdate% %systime% - Failed uninstall hotfix: %qfe% >>"%WINDIR%\TEM\qfe_uninstall.log"
ErrorLogMsg %ErrorText% %WusaError% %CallingText% wusa /uninstall /kb:%QFE% /quiet
Abort

Setup.inf Beispiel zur Hotfix Deinstallation als Datei: MSHotfix_Uninstall (910 Downloads )

Der Beitrag UAC Meldungen bei der Reinstallation von MSI Paketen erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/uac-meldungen-bei-msi-paketen/feed/ 1
Setup.inf – Datei pro Benutzer kopieren https://www.wpm-blog.de/setup-inf-datei-pro-benutzer-kopieren/ https://www.wpm-blog.de/setup-inf-datei-pro-benutzer-kopieren/#comments Mon, 06 May 2013 17:19:44 +0000 https://www.wpm-blog.de/?p=909 Häufig steht man vor der Aufgabe in einem Empirum Paket pro Benutzer eine Datei zu kopieren, um benutzerspezifische Einstellungen vorab vorzunehmen. Wie kann dies in der Setup.inf vorgenommen werden und worauf sollte man achten? Wenn … Weiterlesen

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

]]>
Kopieren pro BenutzerHäufig steht man vor der Aufgabe in einem Empirum Paket pro Benutzer eine Datei zu kopieren, um benutzerspezifische Einstellungen vorab vorzunehmen. Wie kann dies in der Setup.inf vorgenommen werden und worauf sollte man achten?

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.

Wichtig: Der Sektion „Benutzereinstellungen“ nicht das Flag „CLIENT“ hinzufügen, sonst wird die Datei nicht im Maschinenteil lokal kopiert!

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.

]]>
https://www.wpm-blog.de/setup-inf-datei-pro-benutzer-kopieren/feed/ 5