Voraussetzungen

Aus meinen Erfahrungen heraus gibt es zwei Dinge, auf die man achten sollte. Seinen volle Leistung entfaltet der UEM Agent erst mit dem aktuellen Hotfix auf der Empirum Server Seite. Zusätzlich sollte man eine kleine Verbesserung in Form einer Setup.inf Anpassung vornehmen, bevor man diese Version einsetzt.

Matrix42 Empirum v21.0.3

Wichtig bei der Nutzung des neuen UEM Agents ist, das man beim Einsatz von Empirum v21.0.3 auch den aktuellen Hotfix Installer vom 28.10.2022 oder später ausführt.

Download

Matrix42 stellt alle UEM Agent für Windows Versionen an der gleichen Stelle zum Download bereit.
Den aktuellen Hotfix Installer für Matrix42 Empirum v21.0.3 gibt es hier.

Anpassungen

Nachdem man den UEM Agenten in das Empirum Software-Depot eingebunden hat, sollte man jedoch auf Dateiebene in der Setup.inf noch eine Anpassung vornehmen. Die Datei findet ihr auf dem EmpirumServer unter Empirum\Configurator\Packages\Matrix42\UEM Agent Windows\2210.1.2\Install.
Dazu die Finish Sektion der ausgelieferten Setup.inf wie folgt anpassen.
Hinzukommen sollte die Zeile mit dem Callhidden.

[Finish]
Callhidden reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\RebootPackagesPending /v "Restart Matrix42 UEM Agent Windows" /f
Exit

Hinweis

Trotz aller Empfehlungen von meiner Seite, sollte man, wie bei jedem Stück neuer Software, diese stückweise bzw. in Wellen (Test, Pilot, Rollout) an die Clients verteilen.

Der Beitrag UEM Agent für Windows 2210.1.2 released erschien zuerst auf Workplace Management Blog.

Da war es von Vorteil, dass man mit mehreren Kunden in Kontakt steht und ich ähnliches schon einmal gehört hatte. Meine Nachfrage hat ergeben, dass es dazu derzeit ein spezielles Firmware Update gibt, welches im besten Falle in Zukunft im BIOS Update erhalten sein wird.

Dieses Firmware Update (USB PD Firmware Update Tool V1.0C013.1) sollte bei der oben genannten Konstellation eingespielt werden. Zur Sicherheit sollte geprüft werden, ob diese Firmware nicht sogar in Zukunft im BIOS Update enthalten ist.

USB PD Firmware Update Tool (direkter Link) – dieses Tool sollte auch unter „Flash -Firmware“ bei den einzelnen Modellen aufgelistet sein.
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=8CA9F197-A6BF-4C0E-8DDA-E82ECF2FC2B0

Portreplikator
https://www.fujitsu.com/de/products/computing/peripheral/accessories/connectivity/usb-port-replicator-pr09.html

Wer das Device Update per Softwareverteilung installieren mag, dem sind die nachfolgenden Kommandozeilenparameter und Rückgabewerte ans Herz zu legen.

Parameter

/N für silent
/X für kein automatischr Reboot

ExitCodes

0 Normal end
1 Tool is already running
2 Invalid parameter
3 Capsule file is not found
4 Incorrect signature
5 Abnormality is found in Capsule file
6 AC adapter is not connected
7 Target device is not connected
8 Target device is not found
9 Failed to deploy driver
10 Failed to load driver
11 GABI API call error
12 Failed to proceed Capsule
13 Not Fujitsu PC
14 Battery capacity is not enough
15 FUJ0420, FUJ0430 Device Driver is not installed
16 FW version check error
17 FW GUID mismatch
255 Other error

Der Beitrag Fujitsu Lifebook E und Portreplikatoren Probleme erschien zuerst auf Workplace Management Blog.

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.

Das Update enthält Detailverbesserungen und Erweiterungen in den Bereichen:

• MAC OS X Unterstützung
• Silverback Integration in Empirum
• Sicherheit
• WebConsole
• Inventory Erweiterung bzgl. SQL und Exchange Server Editionen
• Empirum SubDepot Services (Offline PXE/WOL)

Persönlich finde ich die Verbesserungen im Bereich Sicherheit und SubDepot Services am interessantesten. Gerade für letzteres wurden mit dem Update auf die Empirum Version 16.1.1 nochmals Veränderungen durchgeführt.

SubDepot Services (Offline PXE/WOL)

So wird ab der Version 16.1.1 das SubDepot Services Paket durch separate SubDepot PXE Service und SubDepot WOL Service Paket ersetzt. Damit hat man die Komplexität aus dem bekannten SubDepot Services Paket herausgenommen und kann die Installation der genannten Dienste nun sehr schön über die separaten Pakete durchführen. Gerade in Empirum Umgebungen mit einer Vielzahl an SubDepots ist damit eine Aktualisierung dieser Komponenten wesentlich einfacher geworden.

Leider hatten sich bei der Umsetzung der neuen Funktionen noch kleinere Fehler eingeschlichen. Es wurden bereits Hotfixe für diese Probleme veröffentlicht und können mit dem aktuellen Hotfix Installer vom 06.12.2016 installiert werden. Die Installation der Hotfixe kann ich für Umgebungen die die Offline PXE/WOL Funktionen nutzen nur empfehlen.

Hinweis: Der Hotfix Installer benötigt PowerShell 3.0 oder neuer auf dem EmpirumServer installiert.

Sicherheit

Wer alle Empirum Komponenten auf die Version 16.1 aktualisiert hat, kann die Sicherheit beim Einsatz von Empirum weiter erhöhen. Zur Umsetzung dieser Änderungen empfehle ich die Dokumentation bzw. das dazugehörige „New Features and Changes“ Dokument.

Empirum Version 16.1.2

Zu dem Zeitpunkt, als ich diesen Artikel geschrieben habe, ist die Version 16.1.2 erschienen. Hierzu werde ich in Kürze etwas schreiben.

Der Beitrag Empirum V16.1.1 und Updates erschien zuerst auf Workplace Management Blog.

• EXIT – das Skript wird vorzeitig verlassen und die Installation wird als Erfolg gewertet. Reboot Anforderungen werden verarbeitet.
• ABORT – das Skript wird vorzeitig verlassen und die Installation wird als Fehler gewertet. In der Management-Console ist der Status „FAILURE“ (Fehler aufgetreten). Das bedeutet, dass das Paket am Client immer wieder ausgeführt wird. Das wiederholte Ausführen wird ggf. durch die maximale Fehleranzahl, die der Agent (ab Empirum v15) zulässt, eingegrenzt. Wird ein Paket mit einem ABORT verlassen, werden Reboot (Reboot= bzw. SetReboot) Anforderungen des Skriptes an den Agenten verworfen!
• ABORTSILENT – das Skript wird vorzeitig verlassen und die Installation wird auf dem Client als Fehler gewertet. In der Management-Console ist der Status wiederum „SUCCESS“ (erfolgreich). Das bedeutet, dass das Paket am Client immer wieder ausgeführt wird. Das wiederholte Ausführen wird ggf. durch die maximale Fehleranzahl, die der Agent (ab Empirum v15) zulässt, eingegrenzt. Wird ein Paket mit einem ABORTSILENT verlassen, werden Reboot (Reboot= bzw. SetReboot) Anforderungen des Skriptes an den Agenten verworfen!
• ABORTREBOOT – das Skript wird vorzeitig verlassen und die Installation wird auf dem Client als Fehler gewertet. In der Management-Console ist der Status „Reboot Pending“ (Neustart ausstehend). Die Installation des Paketes wird nach dem durchgeführten Neustart erneut gestartet. Die Reboot Anweisungen werden somit nicht verworfen!

Welchen Befehl nutzt man nun wann?
Der Abort wird gerne genutzt, wenn die Überprüfung einer extern aufgerufenen Installation (MSI, Unatteded) überprüft wird und die Überprüfung auf den erwarteten Erfolg nicht erfüllt ist.
Dies kann man sich in den Paketvorlagen MSI.inf und Unattended.inf ansehen.

Den EXIT Befehl kann man zum Beispiel nutzen, wenn man ein Paket vorzeitig beendet möchte, weil die Installation der Software ggf. bereits außerhalb von Empirum erfolgt ist.

Der AbortSilent wird genutzt, wenn ein Paket ggf. mehrmals aufgerufen werden muss, damit die eigentliche Installation der Software erfolgreich ist. Ein anderer Anwendungsfall ist zum Beispiel einen Benutzerteil o.ä. vorzeitig zu verlassen, weil die Voraussetzung (Programm noch nicht gestartet, …) noch nicht vorhanden ist.

Der AbortReboot wird ähnlich wie der AbortSilent eingesetzt, lässt jedoch auch zu das eine Reboot Anforderung nicht verworfen wird. Wenn zum Beispiel eine erfolgreiche Installation zuerst eine weitere Software Installation/Deinstallation und einen Neustart erfordert, muss man das Paket zwischenzeitlich mit einem AbortReboot verlassen. Nach dem Neustart wird dann das Paket nochmals ausgeführt und die ggf. zuvor fehlenden Voraussetzungen für eine erfolgreiche Installation sind nun erfüllt.

Der Beitrag Empirum Setup.inf Skript vorzeitig verlassen erschien zuerst auf Workplace Management Blog.

Zweiteres kann man über die Logik der Revisionserhöhung realisieren. Möchte bei einem bereits verteilten Paket mit einer MSI oder Unattended Installation nun noch ein paar Dateien oder Registry Einträge austauschen/hinzufügen, so kann man den nachfolgend erläuterten Mechanismus nutzen. Dieser Mechanismus ermöglicht, dass bei bereits vorhandenen Installationen mit der Revision=0 nur minimale Änderungen durchgeführt werden und bei Neuinstallationen, die komplette Installation zuzüglich der nachträglichen Änderung.

[Product]
#CheckRevisionChanges, DONTDELETE
...
;<Installationslogik MSI / Unattended>
;<z.B.: Set:Product>
;<z.B.: Set:Installation>
#DoMinorUpdate

[CheckRevisionChanges]
Set LocalRevision=%%HKLM,Software\%MachineKeyName%\Setup,Revision%%
ReplaceEnv LocalRevision
IF "%LocalRevision%" < "%Revision%" & "%LocalRevision%" <> "" THEN "OnlyDoRevisionUpdate" EndIf

[OnlyDoRevisionUpdate]
#DoMinorUpdate
Exit

[DoMinorUpdate]
;Examples / Beispiele
;#CopyAdditionalFiles
;#Reg:Changes

Der Beitrag Empirum Paket – Revisionserhöhung bei „großen“ Installationen erschien zuerst auf Workplace Management Blog.

Aufruf und Ergebnis

Wie nutzt man nun das Tool während der Softwareverteilung? Dazu ruft man die GetPowerState.exe auf und prüft anschließend die Registry. Die GetPowerState.exe speichert das Ergebnis unter „HKLM\SOFTWARE\matrix42\ClientInfo\PowerState“. Hier werden die Eigenschaften „PowerState“ und „BatteryState“ gespeichert.

• PowerState kann die Werte „Battery“ (Batteriebetrieb) oder „AC“ (Netzbetrieb) annehmen.
• BatteryState enthält den prozentualen Ladezustand der Batterie.

Im Empirum Paket kann dies in der Setup.inf wie folgt abgeprüft werden:

CALLHIDDEN "%SRC%\GetPowerState.exe"
IF %HKLM,Software\Matrix42\ClientInfo\PowerState,PowerState% <> "AC" THEN "ErrorHandling" EndIf

[ErrorHandling]
ErrorLogMsg "Computer is on battery. Exiting Script! | Computer ist nicht am Stromnetz angeschlossen. Script wird beendet!" 
AbortSilent

GetPowerState.exe gibt es hier zum Download:
GetPowerState (1215 Downloads )
MD5 Hash der Downloaddatei: D74C4B71639872DABA45C844584F609D38CE427C

Der Beitrag HowTo: Akku oder Netzbetrieb unterscheiden erschien zuerst auf Workplace Management Blog.

Die angezeigten ERRORLEVEL haben ihren Ursprung zumeist im Kommando Interpreter oder in den Installern. Unten angefügt habe ich zwei Tabellen mit den häufigsten Fehlermeldung. Diese Tabellen erheben jedoch keinen Anspruch auf Vollständigkeit.

Was sind die gängigen Fehler und wie lassen sie sich beseitigen?

Die ERRORLEVEL Meldungen rühren aus der Setup.inf des fehlerhaften Empirum Paketes.

Fehler 2 oder 3
In diesem Fall ist zumeist ein Befehl falsch geschrieben, die Setup.exe ist zu alt für den genutzten Befehl, ein aufzurufendes Programm wurde versucht als Befehl zu interpretieren.

Fehler 5
Kein Zugriff möglich oder auch Zugriff verweigert bedeutet zumeist, dass der Befehl aufgrund von nicht vorhandenen Berechtigungen fehlschlägt. In Empirum ist das zumeist, wenn in der Registry Änderungen durchgeführt werden sollen, zu der der Benutzer nicht berechtigt ist. Das können Änderungen im Bereich HKLM\SYSTEM, als auch HKCU\Software\Microsoft\Policies sein. Der Benutzer hat zwar Berechtigungen auf den HKCU Zweig, jedoch nicht im Bereich der Policies, denn diese soll er ja auch nicht „manipulieren“ können.

Fehler 1602
Dieser Fehler rührt vom Windows Installer und bedeutet, dass der Benutzer die „Abbrechen“ Schaltfläche des MSIEXEC Dialoges betätigt hat. Diese Schaltfläche kann mit dem „!“ entfernt werden, wie z.B. /qb-! oder /qr!. Nutzt man direkt /qn – so wird nichts angezeigt, auch nicht die „Abbrechen“ Schaltfläche.

Fehler 1603
Der „1603“ ist der beliebteste Fehler unter den Software-Paketieren, denn er bedeutet soviel wie „Es ist ein schwerwiegender Fehler aufgetreten…“. Das heißt soviel wie alles und nichts! Hier kann man dem Fehler nur durch Analyse des MSI Logs näher kommen. Das Log wird im Standard in den %TEMP% Ordner des jeweiligen Computers geschrieben und beginnt mit MSI_. Wenn die Installation mit dem Empirum Advanced Agent durchgeführt wird, so ist die Datei im Ordner %WinDir%\TEMP wiederzufinden. Häufig wird der Fehler am Ende des Logs angezeigt, das man sehr einfach mit STRG+ENDE anspringen kann.

Fehler 0
Warum ist der ERRORLEVEL 0 ein Fehler? Wieso wird das Paket als fehlerhaft in der Console angezeigt bzw. läuft immer wieder, obwohl alles „gut“ aussieht und das Programm auch funktioniert? Dies liegt häufig damit zusammen, dass in Empirum Software-Paketen in denen externe Installer (Hersteller-Setups) aufgerufen werden, auch anschließend eine „Erfolgsüberprüfung“ stattfindet. Da man nicht weiß, ob die Hersteller-Setuproutine das gemacht hat was man von ihr erwartet, prüft man im Anschluß den Erfolg durch die Überprüfung auf das Vorhandensein von Registry Einträgen, Dateien oder Texte in Dateien. Können die zu erwartenden Prüfpunkte nicht erfolgreich geprüft werden, so verzweigt die Installationsabfolge in der Setup.inf in eine Sektion, in der die Empirum Installation mit „Abort“ abgebrochen wird. Der Fehler 0 tritt sehr gerne in MSI Paketen auf.

Folgendes ist zu prüfen bzw. anzupassen:

• Ist der UninstallString in der Registry unterhalb der GUID vorhanden? (Änderung auf InstallDate hilft häufig.)
• Ist es überhaupt die richtige GUID die abgeprüft wird?
• Wird die ReInstSuccessMessageXXXX in dem MSILogFile richtig geprüft? Die aktuellen MSI Vorlagen prüfen 4 ReInstSuccessMessages, da sich die Meldungen mit der Aktualisierung der MSIExec Version geändert haben. Dieser Fehler tritt auch gerne beim Testen der Windows XP Pakete unter Windows 7 auf. Abhilfe schafft hier die Übernahme der 4 ReInstSuccessMessages und das Anpassen der Überprüfung (IF …) in der RepairMSI Sektion. Die Vorlage liefert die aktuelle MSI.inf.

Liste von Fehlermeldungen bzw. ERRORLEVEL Werten

Fehler – Beschreibung
0 – Fehlerfrei
2 – Datei nicht vorhanden
3 – Pfad nicht gefunden
5 – Kein Zugriff möglich
6 – Ungültiger Zugriff/ungültiges Handle
8 – Zu wenig Speicher
10 – Ungültiger Bereich/ungültige Environment Variablen
11 – Ungültiges (Befehls-)Format

MsiExec.exe und InstMsi.exe Fehlermeldungen
Hier geht es zur Microsoft Seite mit der vollständigen Liste der „MsiExec.exe and InstMsi.exe Error Messages (Windows)“

Wert – Fehler-Code – Beschreibung
0 – ERROR_SUCCESS – Die Installation war erfolgreich.
1602 – ERROR_INSTALL_USEREXIT – Der Benutzer hat die Installation abgebrochen.
1603 – ERROR_INSTALL_FAILURE – Es ist ein schwerwiegender Fehler während der Installation aufgetreten.
1642 – ERROR_PATCH_TARGET_NOT_FOUND Der Patch kann nicht installiert werden, weil die zu aktualisierende Software nicht installiert ist.
3010 – ERROR_SUCCESS_REBOOT_REQUIRED Die Installation war erfolgreich, benötigt jedoch einen Neustart!

Der Beitrag Fehler und ErrorLevel aus der Setup.inf erschien zuerst auf Workplace Management Blog.