Paketeigenschaften

Hier nochmals ein Screenshot der Paketeigenschaften, um die Option in Erinnerung zu rufen:

Computervariable – ReadyToInstall_Test

Software-Pakete, die nicht „zur Installation freigegeben“ sind, werden trotz Zuweisung zu einem oder mehrerer Computer nicht in deren Auftragsdatei (DDC) geschrieben und somit installiert. In Abhängigkeit der Computervariablen „ReadyToInstall_Test“ werden nun auch diese Pakete und somit Installationsaufträge in die Auftragsdatei aufgenommen. Mit dieser Variable definiert man somit, dass ein Computer auch nicht freigegebene (noch im Test befindliche) Software installiert bekommt.

Nachfolgend eine Aufstellung, was die Werte der Option bewirken:

• 0 (deaktiviert) = Software Installationsauftrag nicht in die DDC schreiben
• 1 (aktiviert) = Software Installationsauftrag in die entsprechende DDC des Computers schreiben

Die Computervariable kann man nun über den althergebrachten Weg, oder per definierter und zugewiesener Variablen Konfiguration setzen und somit einen Computer in die Lage versetzen, auch die nicht freigegeben Pakete zu installieren.

UEM Agent AutoUpdate

Die oben genannte Paketeigenschaft hat im Falle der Matrix42 UEM Agent Windows Pakete auch eine Auswirkung auf die UEM Agent Auto Update Funktion. Möchte man die UEM Agent Auto Update Funktion nutzen, so geschieht die Aktivierung auch über entsprechende Computervariablen.

Die Konfiguration und das unterschiedliche Verhalten geschieht über die Variable: MX42_UEM_Agent, Auto Update.

Meine Präferenz zum UEM Agent Auto Update

Ich selbst nutze bevorzugt die klassische Art der UEM Agent Verteilung und lasse das Auto Update deaktiviert. Meines Erachtens ist es besser transparenter, nachvollziehbar, welcher Computer, welche Version bekommen soll und wann das geschieht. Aber wie immer gibt es verschiedene Geschmäcker und Vorgehensweisen/Vorlieben.

Der Beitrag Empirum Paketeigenschaften – Zur Installation freigeben erschien zuerst auf Workplace Management Blog.

Aktualisierung Windows Preinstallation Environment

In diesem Fall ist das Windows PE-Add-On auf dem EmpirumServer zu prüfen. Bis dato war eine Version 10.1.19041.1 des WADK WinPE-Add-Ons vollkommen ausreichend. Mit der Installation von Windows 11 22H4 wird jedoch unbedingt eine aktuellere Version benötigt.

Die auf dem EmpirumServer installierte Version kann in der Systemsteuerung überprüft werden:

Nachdem die Windows PE-AddOn Version 10.1.19041.1 o.ä. deinstalliert wurde, muss die aktuelle Version 10.1.26100.1 installiert werden.

Diese kann von der nachfolgenden Seite bezogen werden: https://learn.microsoft.com/de-de/windows-hardware/get-started/adk-install

Boot Konfiguration neu erstellen

Ist die Installation des WADK Windows-PE-Add-On erfolgreich abgeschlossen, muss die Bootkonfiguration unter Konfiguration, Boot Konfigurationen neu gespeichert werden.

Falls SubDepots im Einsatz sind, sollte im Anschluss das PXE-Image auch auf das SubDepot übertragen werden. Im Anschluss sollte einer erfolgreichen Windows 11 24H2 Installation nichts mehr im Wege stehen.

Der Beitrag Empirum: Fehler bei der Windows 11 Installation erschien zuerst auf Workplace Management Blog.

Was können Probleme bei der WindowsInstallation und danach sein?

WindowsInstallation Paket

Falls es zu Problemen bei der Ausführung des WindowsInstallation Paketes kommt, sollte man prüfen, ob ein Betriebssystemimport zugewiesen ist, oder der Computer in den Eigenschaften mit einer statischen IP-Adresse versehen ist.

DomainJoin

Bei Fehlern, die während des DomainJoin Paketes auftauchen, hilft ein Blick in das Log unter WinPEStatus. Häufig liegt es jedoch mit dem für den DomainJoin verwendeten Benutzer zusammen. Entweder hat er gar keine oder nicht die erforderlichen Berechtigungen, das Computerkonto zu erstellen oder ein bestehendes zu verändern. Testweise kann man das, vielleicht bereits vorhandene, Computerobjekt in der Domäne vor einer Installation löschen.

EmpirumAgentSetup

Das Paket wurde gerade in den aktuellen Versionen (2.8/2.9) der Empirum WinPE Erweiterung 1.9.0 (und neuer) wesentlich robuster aufgestellt. Falls es bei diesem Paket zu Problemen kommt, dann sollte man einen Blick auf die Variable „MX42_AGENT_PUSH_PACKAGE_FOLDER“ (Windows) legen. Ist die hier angegebene Version auf dem EmpirumServer bzw. dem zuständigen SubDepot unter „Empirum\Configurator\Packages\Matrix42\UEM Agent Windows“ abgelegt?

Keine Software-Installation nach der OS-Installation

Findet nach der OS-Installation keine Software-Installation statt, dann wurde in den meisten Fällen in den Eigenschaften des Computers bei Domäne der FQDN der Domäne anstatt der NetBIOS Name der Domäne angegeben. Wenn dies der Fall ist und angepasst wurde, reicht eine Aktivierung der Software (keine komplette Neu-Installation per PXE) aus. Zur Sicherheit startet man den Client-Computer einmal neu, damit er nach dem Neustart auf ausstehende Software-Installationen prüft.

Der Beitrag WinPE Installation und Troubleshooting erschien zuerst auf Workplace Management Blog.

Hier gibt es das Tool zum Download:
SWDepotInfo183 (2661 Downloads )
SHA256 Hash der Version 1.8.3: A133D895D75FE01EB50B5BFC78106C2793AE42A481E26955C64FBD69264A01DE

Der Beitrag SWDepotInfo – Jahrgang 2023 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.

Variablen

Nachfolgend sollten die meistgenutzten Variablen aufgeführt sein. Falls ihr eine Variable häufig nutzt, die hier nicht aufgeführt ist, so lasst es mich wissen.

Beispiele

Del "%CommonDesktop%\WinSCP.lnk"

Del "%CommonPrograms%\TotalCommander Repair und Uninstall.lnk"

Deltree "%ProgramFiles%\WinSCP"

Callhidden %ComSpec% /C Echo %%date%% %%time%% [Set:Product] Install or repair >>"%App%\Debug.log"

Copy "%Src%\filezilla.xml" "%App%\FileZilla.xml"

Copy "%App%\filezilla.xml" "%AppData%\FileZilla\FileZilla.xml"

Der Beitrag Empirum Setup.inf – Variablen 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.