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.

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.

Was war der Auslöser?

Am Ende war das Problem vorwiegend auf ein Problem zurückzuführen. Microsoft hat ein aktualisiertes Update für die hier bereits beschriebene Problematik herausgebracht. Das Update KB5020683 wird zwangsweise installiert und startet das System ohne Nachfrage neu. Im Vorjahr hatte ich auch Meldungen von Empirum Admins, die Windows 10 Enterprise nutzen und meinen davon nicht betroffen sein zu dürfen. Diese Fälle hatte ich dieses Mal auch wieder.

Folgende Umstände scheinen damit reinzuspielen:

• Wie erreichen die Computer das Internet während der Betriebssystem-Installation (Proxy, direkt)?
• Das Windows wird erst mit/nach dem DomainJoin Paket aktiviert

Wie löst man die obigen Probleme?

Wie vor einem Jahr habe ich das Microsoft Update in ein WinPE PreOS Paket gepackt, welches geplant installiert wird. Dieses Paket sollte in der Reihenfolge nach dem PxeOffAndReboot Paket einsortiert werden. Man sollte zusätzlich schauen, das man eine aktuelle EmpirumAgentSetup Version, wie z.B. die Version 2.8, einsetzt, da hier auch noch ein bis zwei mögliche Problempunkte behoben sind.

WinPE PreOS Paket

KB5020683_x64 (84 Downloads )
SHA256 Hash der Downloaddatei: 655F4C7F74E905B58CC9242AFB16F47FAD059DB66C7A2F290CE304E166A616DE

Hilfestellung: Hinweise, wie man ein PreOS Paket einbindet, findet ihr hier.

Der Beitrag Unterschiedliche Probleme bei OS Installationen mit Empirum erschien zuerst auf Workplace Management Blog.

Optionale Installation

Warum gibt es nun die optionale Installation. Da müssen wir in der Empirum Agent „Historie“ etwas zurück gehen. Mit dem UEM Agent, als Nachfolger vom Advanced Agent, hielt eine neue reduzierte und weniger technische Oberfläche Einzug, die sich auf die Einfachheit für den Anwender konzentriert. Wenn eine oder mehrere Installationen mit der Verteiloption „Verschieben“ anstehen, wird der kleinste Nenner (z.B. 1 Tag) dem Anwender zum Verschieben angezeigt und nicht wie zuvor, jede Software mit ihrer aktuellen Verschiebemöglichkeit (eine Software 5 Tage, eine andere 1 Tag).
An dieser Stelle greift die optionale Installation „wieder“ ein. Die Optionale Installation ermöglicht es die Ausführung von vielleicht nicht sicherheitskritischen, jedoch lang andauernden Installationen von kurzen sicherheitskritischen (erforderlichen) Installationen zu entkoppeln. Als zusätzliches Merkmal kann man nun auch im Software Depot in den Paketeigenschaften einem Paket mitgeben, ob ein Neustart „möglich, nicht oder auf jeden Fall erforderlich“ ist.

Verteilungsoptionen

Optionale Installation, mit der „Option“ eines Zieldatums.

Paketeigenschaften

Neustart erforderlich: Nein, Ja, Möglich (falls die Setup.inf das in Laufzeit bestimmt).

Anzeige beim Anwender

Steht nun ein „optionales“ Windows 11 Upgrade und ein viel kleineres Paket, wie hier ein 7-zip zur Verteilung an, wird das wie folgt angezeigt …

Mit einem Klick auf „Zeige Details“ landet man in der folgenden Anzeige …Die optionalen Installationen muss man auf der Detail Seite bewusst zur Installation aktivieren.

Der Beitrag Matrix42 UEM Agent – neues Gesicht, neue Möglichkeiten erschien zuerst auf Workplace Management Blog.