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.

Reboot Möglichkeiten

Fangen wir vorne an. Es gibt in der Empirum Setup.inf mindestens zwei Möglichkeiten einen Neustart aus dem Paket heraus anzufordern. Wie das Ganze dann vom Empirum UEM Agenten dann verarbeitet wird, liegt dann zusätzlich an den Agenten Einstellungen, dem Agent-Template.
In der [Application] Sektion gibt es den Paramter Reboot=[Wert von 1 bis 5] für die Anforderung eines Neustarts. Zusätzlich kann man im Verlauf der Setup.inf mit dem Befehl SetReboot [Wert] eine Reboot-Anforderung setzen.

Wo ist der Unterschied?

In der [Application] Sektion setzt man einen Wert für die Installation und Deinstallation, ganz gleich, wie der Verlauf des Paketes ist. Mit dem Befehl SetReboot wiederum kann man fallweise eine Neustart-Anforderung platzieren. Dies kann man sich z.B. bei Paketen basierend auf der MSI Vorlage ansehen. Falls sich ein MSI Paket mit einem ReturnCode 3010 beendet (erfolgreich, jedoch Neustart notwendig), dann wird in der Sektion [RebootRequired] ein SetReboot 1 ausgeführt.

Welchen Wert nutzen?

Wie oben bereits geschrieben, gibt es Werte von 0 bis 5 mit unterschiedlicher Ausprägung und Funktion. Dabei bedeutet der Wert 0 nicht, dass dieses Paket keinen Neustart benötigt, wie zumeist angenommen. Der Wert 0 steht vielmehr für den „Automatikmodus“. Kann zum Beispiel eine Datei im Paketablauf (Ablauf der Setup.inf) nicht ersetzt oder gelöscht werden, fordert beim Wert 0 das Software-Paket trotzdem einen Reboot einen, um beim Neustart, wenn die Datei nicht in Benutzung ist, zu ersetzen oder zu löschen. Möchte man einen Neustart des Paketes unterbinden, so muss man Reboot=2 setzen. Dagegen ist der Wert 1, wie man es sich schon denken konnte, eine direkte Anforderung eines Neustarts. Neben den genannten Werten, wir dann noch häufig der Wert 5 genutzt. Dieser bestimmt, dass nach der Beendigung dieses Paketes ein Neustart angefordert wird (wie bei 1), jedoch auch keine weiteren Pakete zur Ausführung kommen. Die weiteren Pakete werden dann nach dem ausgeführten Reboot durchgeführt.

Wer einen Neustart in gewisser Weise erzwingen mag, kann sich auch meinen Beitrag zum SystemShutdown anlesen.

Komplette Übersicht

Da nun die Eigenschaften für 3 und 4 unter den Tisch gefallen sind, möchte ich diese zur Vollständigkeit hier auch noch erläutern:

• 0 – startet das System nach der Installation neu, wenn ein Neustart erforderlich ist, weil z.B. Dateien überschrieben/gelöscht werden müssen, die in Benutzung sind.
• 1 – startet das System in jedem Fall neu
• 2 – startet das System nicht neu
• 3 – abmelden des Benutzers
• 4 – Herunterfahren (kein Neustart)
• 5 – nach der Installation kein weiteres Paket installiert und zwingend ein Neustart durchgeführt. Dies entspricht dem Verhalten der Option „Installation weiterer Pakete nicht fortsetzen“ in den Paketeigenschaften

Der Beitrag Reboot Werte – Empirum Setup.inf erschien zuerst auf Workplace Management Blog.

Der Matrix42 UEM Agent für Windows bringt ab dem Oktober 2022 in der SFR Version einige Änderungen mit. Mit den Änderungen soll die Stabilität, als auch das Verhalten bei Aktualisierungen signifikant verbessert werden. Zusätzlich halten weitere Verbesserungen hinsichtlich der Sicherheit Einzug.

Der Beitrag Anstehende Matrix42 UEM Agent Änderungen erschien zuerst auf Workplace Management Blog.

Heute möchte ich auf eine Bitte eingehen, die ich per Mail und in der Vergangenheit bereits mehrmals ähnlich gestellt bekommen habe. Das Software Depot bzw. weitläufig bekannt als Kiosk, das der Benutzer über den Empirum Agenten am Client starten kann, verwenden (bzw. verwendeten) einige, um weitere Software für den Anwender zu installieren. Warum spreche ich in der Vergangenheit. Es gibt und gab Mechanismen, das Software Depot aufzurufen wozu der Anwender keine Berechtigungen hat. Dann wurde die Software aus dem Software Depot gegebenenfalls unter anderen Berechtigungen installiert.

Warum wird das gemacht?

Man ist gerade beim Anwender vor Ort oder aufgeschaltet und möchte „mal eben schnell“ die Software-Installation durchführen oder nachholen, die man vergessen hat. Den Weg, jetzt zurück an seinen Arbeitsplatz oder „irgendwie“ in die Management Console zu gehen, sieht man als „umständlich“ an.

Warum bin ich nicht für diese Methode?

Wie man oben aus den Zeilen lesen kann, möchte ich nicht darauf eingehen, wie das einige gemacht haben bzw. machen.
Das mache ich deswegen, weil „veraltete“ Empirum Methoden genutzt werden, die unter Umständen nicht die volle Unterstützung erlangen. Ein weiterer Grund, warum ich nicht „Fan“ dieser Methode bin, ist in den Grundgedanken des Software Depots / Kiosks verankert.

• Die Software wird nicht in der Management Console dem Client zugordnet. Ergo wird Sie bei einer Reinstallation des Computers, Vergabe eines neuen Computers nicht berücksichtigt.
• Ein etwaiger Client-Teil des Paketes wird unter Umständen für diesen und andere Benutzer nicht installiert. Die Software kann sich also anders verhalten/voreingestellt sein, als auf den Computern, bei denen die Software zugewiesen wurde in der Management Console.

Was ist mein Vorschlag?

Kennen Sie die Empirum Web Console? Wenn nicht … Die Emprum Web Console ist, anders als ihr Name suggeriert, ein WebServer, der die wichtigsten Dinge der Empirum Management Console bereitstellt. Deswegen gehört die Empirum Web Console auch nur einmalig auf einen Server installiert und nicht als Paket auf die Clients verteilt (meine Meinung!).
Anschließend ist im Standard die Web Console über http://<ServerName>:8080/Empirum erreichbar (Firewall Einstellungen berücksichtigen!). Die Web Console kann auch auf https umgestellt werden. Wie das geht, kann unter help.matrix42.com nachgeschlagen werden.

Nun könnt ihr von jedem Arbeitsplatz die Console starten und mit wenigen Klicks die Software „normal“ dem Arbeitsplatz zuordnen. Damit entfallen dann auch die oben genannten Nachteile hinsichtlich Client-Teile und vergessen geraten bei einer Neu-Installation.

Als Idee: Die URL zur Web Console könnt ihr auch bei dem Agenten-Template hinterlegen, dann ist es auch an ähnlicher Stelle, wie das Kiosk.

Das sind meine Hinweise, meine Meinung zum Thema – „volles“ Kiosk für bestimmte Benutzer. Vielleicht haben Mitleser aus der Gemeinschaft weitere Ideen oder Erfahrungen, die Sie teilen/kommentieren wollen. Dank und Grüße Jochen

Der Beitrag Software Depot / Kiosk mit anderem Benutzer starten erschien zuerst auf Workplace Management Blog.

Variable USER_UPDATE

Eine Variable steuert, wie das Paket sich verhalten soll. Die nachfolgende Zeile in der Setup.inf verrät, was man machen muss.
If „%VM_SUBDEPOT_USER_UPDATE%“ != „0“ Then „Set:DeleteUser2“ EndIf

Erstellen der Variable

Erstellt man unterhalb der Variablendefinition „SUBDEPOT“ eine Variable mit dem Namen „USER_UPDATE“ (Typ: Zahl oder Text), so kann man steuern, was bei einem „Update“ geschehen soll. Setzt man die Variable explizit auf „0“, so wird der Benutzer nicht bei jedem Update gelöscht und neu angelegt

Möchte man die vorgenannte Funktion nutzen, so erstellt man die Variable „USER_UPDATE“ vom Typ Zahl in der Variablendefinition: SUBDEPOT.
Dazu wählt man in der Matrix42 Management Console, Administration, Extras, Variablendefinitionen … aus und navigiert zur vorhandenen Variablendefinition „SUBDEPOT“. Durch einen Doppelklick oder der Auswahl und Bearbeiten, landet man in den Eigenschaften der Variablengruppe SUBDEPOT. Hier fügt man die Variable mit einem Klick auf das „+“ Symbol hinzu. Wer einen vorgefertigten Beschreibungstext haben möchte: 0 – Don not delete user | 1 – Delete and create user

Zuweisung des Wertes

Anschließend setzt man diese Variable für einen Computer, eine Konfigurations- oder Zuweisungsgruppe. Weitergehende Informationen zur Übernahme des Wertes für untergeordnete Objekte findet man hier.

Der Beitrag Empirum SubDepot Paket und lokaler Agenten Benutzer erschien zuerst auf Workplace Management Blog.

Zutaten zusammenführen

Die Zutaten habt ihr bestenfalls mit Hilfe der zuvor getätigten Beschreibungen bereits vorbereitet. In diesem Blog-Eintrag geht es darum, die letzten Schritte vorzunehmen.
Nun werden die Zutaten in der Management Console (EMC), von der rechten Seite zur Mitte, in einer Konfigurations- oder Zuweisungsgruppe zusammengeführt:

• PreOS Pakete bzw. die erstellte UND-Klasse zuweisen
• WinPE PXE-Image zuweisen
• Betriebssystem zuweisen
• Agent-Template zuweisen
• die Variablen auf die Gruppe setzen und übertragen

Variablen setzen

Die Variablen übernehmen die Definition der kundenspezifischen Windows Installation. Die zu setzenden Variablen(gruppen) heißen identisch wie die genutzten PreOS Pakete.
Am besten geht man die Liste der zugewiesenen Pakete namentlich durch und stellt die für sich passenden Werte ein. Viele Variablen sind bereits vorbelegt und können auf den vordefinierten Werten belassen werden.

Somit konzentriere ich mich hier auf die meines Erachtens wichtigen Werte für eine Windows Installation in deutscher Sprache inklusive Domain Join.

• DiskPartitioning\PreferFastDisk
• WindowsInstallation\LocalUserName
• WindowsInstallation\LocalUserPassword
• WindowsInstallation\LocalUserDisplayName
• WindowsInstallation\SetupUILanguage
• WindowsInstallation\InputLocale
• WindowsInstallation\SystemLocale
• WindowsInstallation\UILanguage
• WindowsInstallation\UserLocale
• DomainJoin\DomainJoinCredentialsUser
• DomainJoin\DomainJoinCredentialsPassword

Zusätzlich sind die nachfolgenden Variablen, die nicht so lauten wie die zugewiesenen Pakete, wichtig anzusehen bzw. zu setzen:

• FQDN – WindowsInstallation, DomainJoin
• ORGANIZATIONAL_UNIT (optional) – DomainJoin
• TIMEZONE – WindowsInstallation
• MX42_AGENT_PUSH_PACKAGE_FOLDER\Windows – EmpirumAgentSetup

Aktivieren

Anschließend wird das Computerobjekt der Gruppe hinzugefügt und aktiviert. Beim Aktivieren für eine WinPE basierte Windows Installation braucht keine „Betriebssystemkonfiguration (OS.INI)“ mehr erstellt werden. Diese Aufgabe übernehmen die PreOS Packages samt der gesetzten Variablen.

Et voilà

Nun den Computer vom Netzwerk booten lassen und nach ca. 20 min ist das frisch installierte Windows fertig angerichtet!

Besonderheiten

Bis zu diesem Punkt wurde beschrieben, dass sich die PreOS Pakete wie herkömmliche Software Pakete verhalten. Es gibt (Stand Oktober 2019 – WinPE 1.6.6) jedoch ein paar Besonderheiten:

• es werden alle zugewiesenen Pakete ausgeführt, nicht nur die aktuellste/höhere Version
• mittels einer Verteilungsoption „Uninstall“ kann die Verarbeitung von Paketen nicht verhindert werden
• PreOS Pakete, die vor dem DiskPartitioning Paket ausgeführt werden, werden aus dem SWDepot-Log gelöscht und der Status bleibt „undefiniert = gelb“

Der Beitrag Empirum WinPE – Windows Installation erschien zuerst auf Workplace Management Blog.

Zentrale Steuerung – Agent Template

Sein Verhalten bekommt der Empirum Agent über das sogenannte Agent-Template mitgegeben. Dieses Agent-Template ist unabhängig, ob der Advanced oder UEM Agent eingesetzt wird. Funktionen die nur der UEM Agent bedienen kann sind mit einem fliederfarbenen Symbol gekennzeichnet. In Bezug auf die Verbindungsmöglichkeiten gibt es bis dato jedoch keine Unterschiede.

DHCP Optionen

In Empirum DBUtil muss zuerst die Option EmpirumServer aktiviert werden und mit einer Options-Nummer versehen sein. Dies geht in den Eigenschaften zu den PXE-Servern.Im Anschluss sollte man das Agent-Template erstellen bzw. aktualisieren mit der DHCP Option gesetzt (siehe Abbildung 1). Vertrauen ist gut – Kontrolle ist besser! Am besten man schaut nach der Erstellung in die daraus resultierende XML Datei im \\%EmpirumServer%\Configurator$\User Verzeichnis (<Konfigurationsname>.xml). In der Datei sollte eine Suche nach DHCP einen ähnlichen Eintrag wie folgt finden …

<DHCPOptions enabled="true">
     <DHCPEntry id="128">EmpirumServer</DHCPEntry>
</DHCPOptions>

Anschließend ist zu prüfen, ob die zuvor genutzte DHCP Options ID (hier 128) auf dem DHCP Server für den entsprechenden IP-Adressraum konfiguriert ist. Falls die Option 128 noch nicht vorhanden ist, so muss diese auf dem DHCP Server noch erstellt werden. Eine Anleitung, die man sich als Vorlage nutzen kann, ist hier verfügbar. Die zu erstellende Option (ab ID 128) ist vom Typ: Zeichenkette bzw. String und sollte mit dem Namen „EmpirumServer“ belegt werden.

Zugewiesene EmpirumServer verwenden

Wenn man mit der Zuweisung des EmpirumServers über die Konfigurations- bzw. Zuweisungsgruppen arbeiten will, muss man diverse Voraussetzungen erfüllen.
In den Computereigenschaften des zuzuweisenden EmpirumServers müssen die folgenden Werte gesetzt sein:

• die Computerrolle: Empirum Master Server oder Empirum Depot Server
• die Variablen: SubDepot\USER_x / PASSWORD_x

Der EmpirumServer wird über die Eigenschaften der Konfigurations-/Zuweisunggruppe zugewiesen und vererbt. Dem Computerobjekt wird automatisch nochmals direkt der Empirum Master Server zugewiesen.Die Reihenfolge der EmpirumServer Nutzung kann optisch oder in der %Computername%.ini Datei eingesehen werden. In den Eigenschaften der Gruppe entspricht die Reihenfolge von open nach unten. In der %Computername%.ini entspricht die Reihenfolge von unten (höchste Zahl) nach oben (kleinste Zahl).

Verbindungs-Versuchs-Reihenfolge
Die Reihenfolge der Verbindungsversuche geschieht vorwiegend, wie in der Abbildung des Agent-Templates zu sehen ist, von oben nach unten:

• DHCP Option
• Zugewiesene EmpirumServer (unter Berücksichtigung der Sub-Optionen: zufällige Reihenfolge, MasterServer auslassen)
• bereits gesetzte Umgebungsvariable %Empirumserver%
• Ausfall Server (das sollte zumeist der Empirum Master Server sein) – angegebener Server in der AgentConfig.xml

Die Verbindung wird ausschließlich nach der Erreichbarkeit des Servers bzw. der Freigaben (SMB/https) bestimmt, nicht an der Qualität der Verbindung.

Wie sieht es am Client aus?

Die Frage lässt sich zumeist gut beantworten, bedarf jedoch eines Blickes „unter die Motorhaube“, sprich in die Log Dateien des Agenten. Diese findet man für den UEM Agent unter: C:\ProgramData\Matrix42\Logs\UAF\ und für den Advanced Agent unter: C:\ProgramData\Matrix42\Logs\ERIS. Dazu nimmt man am besten die Datei ohne Datum im Dateinamen (aktuelle Datei) und sucht nach DHCP. Somit findet man zumeist schnell den Start des Empirum Agenten bzw. die Informationen zum aktuellen Polling. Nachfolgend ein beispielhaftes Log mit Kommentaren in kursiver Schrift.

>Welches Agent Template wurde genutzt? Name und Version ist hier aufgeführt.
[Warning] [MxLog.LogS] DLL.Transport [SAC] Using Agent Template ‚AgentConfigSample‘ (Version 18.0.0.3) <19>
>Was sind die aus der AgentConfig.xml (auf dem Client heißt die Konfigurationsdatei immer gleich) ausgelesenen Einstellungen?
[Warning] [MxLog.LogS] DLL.Transport [SAC] Use DHCP options <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Use assigned EmpirumServers ; Use random order ; Exclude Empirum Master Server <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Fallback Server: empirumserver.domain.loc, account: Domain\EmpirumAgent <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Active protocol: SMB <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] END Configuration for checking server availability <19>
>sind EmpirumServer zugewiesen?
[Warning] [MxLog.LogS] DLL.Transport [SAC] Machine values file for this computer is „C:\EmpirumAgent\Values\MachineValues\Domain\ComputerName.ini“ <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Loading assigned EmpirumServers from „C:\EmpirumAgent\Values\MachineValues\Domain\ComputerName.ini“ <19>
>hier sind keine EmpirumServer zugeordnet …
[Warning] [MxLog.LogS] DLL.Transport [SAC] No assigned EmpirumServer found! <19>
>nutze den EmpirumServer aus der Umegbungsvariable: EmpirumServer …
[Warning] [MxLog.LogS] DLL.Transport [SAC] Loading configuration from environment variables <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] ENV-EmpirumServer: empirumserver.domain.loc, ENV-User: Domain\EmpirumAgent, ENV-Password: is set <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Checking availability of server with user <Domain\EmpirumAgent> using configured protocol <19>

>im Falle eines zugewiesenen EmpirumServers per DHCP …
[Warning] [MxLog.LogS] DLL.Transport [SAC] Use DHCP options <9>
…
[Warning] [MxLog.LogS] DLL.Transport [SAC] Reading DHCP options from network stack <9>
[Information] [MxLog.LogS] DLL.Transport Dhcp environment variables from xml read <9>
[Information] [MxLog.LogS] DLL.Transport [DhcpOptions] START SelectAdapters <9>
…
[Information] [MxLog.LogS] DLL.Transport [DhcpOptions] START GetDhcpOptions <9>
…
[Information] [MxLog.LogS] DLL.Transport Dhcp Option „EmpirumServer“ with ID 128 will be requested <9>
[Information] [MxLog.LogS] DLL.Transport Dhcp Received 19 bytes from DHCP server: „empirumserver.domain.loc“ for option 129 <9>
[Information] [MxLog.LogS] DLL.Transport [DhcpOptions] END GetDhcpOptions successful. ‚1‘ values found <9>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Get for DHCP option ‚EmpirumServer‘ value ‚empirumserver.domain.loc‘ successfully <9>

>Verbindungsversuche
[Information] [MxLog.LogS] DLL.Transport SMB Session Manager Connection to \\empirumserver.domain.loc\Configurator$\Packages with user Domain\EmpirumAgent establishing. <34>
>hierauf sollte ein „established“ folgen, oder eben eine Fehlermeldung, warum der EmpirumServer nicht erreichbar ist.

Der Beitrag Empirum Agent – Troubleshooting Verbindungsaufbau erschien zuerst auf Workplace Management Blog.

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

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

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.

„Makel“ DomainJoin 1.4

Das vorhandene Matrix42 PreOS Paket DomainJoin 1.4 hat meiner Meinung jedoch diverse Makel, die das angehängte PreOS Paket besser machen soll.
In Zusammenarbeit mit einem Kollegen und einem Kunden ist somit das angehängte MoveComputerToEmpirumOU PreOS Paket entstanden. Die Makel aus unserer Sicht sind:

• Für das Verschieben des Computer in eine OU werden die RSAT Tools benötigt bzw. versucht bei Bedarf nachzuladen, was bei den meisten Nutzern zu Problemen führt und einen „Add-WindowsCapability“ Fehler im PXE-Log anzeigt.
• Wenn das Paket ausgeführt wurde und der Computer nicht verschoben wurde, wird trotzdem die Ziel OU angezeigt.

MoveComputerToEmpirumOU

Das MoveComputerToEmpirumOU ist ein AddOn zum DomainJoin Paket, da wir es als Zugabe sehen und Matrix42 vielleicht zukünftig das eigene Paket überarbeitet.
So ist MoveComputerToEmpirumOU zusätzlich und nach dem DomainJoin (getestet mit Version 1.4) auszuführen.

• Es benötigt keine RSAT Tools und gibt die am Ende „aktive / resultierende“ OU aus.
• Das Paket bedient sich den DomainJoin Variablen und kann somit auch bzgl. des „führenden“ Systems (Empirum oder AD) konfiguriert werden.
• Eine eigene Variable „NotMandatory“ kann gesetzt werden, damit das Paket auch bei einem Fehler oder Misserfolg mit Erfolg beendet wird.

Weitere Informationen können der dem Download beiliegenden ReadMe.txt entnommen werden.

Feedback

Rückmeldung zum Paket ist ausdrücklich erwünscht, um die Funktion/Stabilität weiter zu verbessern. Angedacht ist zusätzlich eine Erweiterung, die Mobile Computer (Notebooks, Tablets,…) in eine noch zu definierende alternative OU verschieben kann.

Download

Empirum WinPE PreOS Paket: MoveComputerToEmpirumOU
MoveComputerToEmpirumOU (572 Downloads )
MD5 Hash der Downloaddatei: 885AD1614EFC476345A8BE1FA95F1A1A08C27AF3

Beispielsausgaben des PXE-Log

DomainJoin Authority: Empirum

[PEAgent] [Windows] Finished execution of wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Active OU: OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Moving the computer succeeded!
[PEAgent] [Windows] Try moving the computer to the defined OU ...
[PEAgent] [Windows] Empirum defined OU : OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Computers current OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] DomainJoin Authority: Empirum
[PEAgent] [Windows] Start to execute wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Finished execution of Matrix42\OsPackages\DomainJoin\1.4 package.
[PEAgent] [Windows] Domain join failed: Fehler bei Add-WindowsCapability". Fehlercode: 0x8024402c, Domain 'wpm-blog.de' and OU 'OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de'"
[PEAgent] [Windows] Start to execute Matrix42\OsPackages\DomainJoin\1.4 package.

DomainJoin Authority: AD

[PEAgent] [Windows] Finished execution of wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Active OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Empirum defined OU : OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Computers current OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] DomainJoin Authority: AD
[PEAgent] [Windows] Start to execute wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Finished execution of Matrix42\OsPackages\DomainJoin\1.4 package.
[PEAgent] [Windows] Domain join (option 33) successful: Domain 'wpm-blog.de' and OU 'OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de'
[PEAgent] [Windows] Start to execute Matrix42\OsPackages\DomainJoin\1.4 package.

Der Beitrag PreOS Paket: MoveComputerToEmpirumOU erschien zuerst auf Workplace Management Blog.

PrepareDRVbyModel_Packages

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

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

Übersicht dieses Beitrages

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

Import der OS-Packages

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

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

Hardware Model zu Treiber/Software Zuordnung

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

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

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

Möglichkeiten mit PrepareDRVbyModel_Packages

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

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

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

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

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

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

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

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

Möglichkeiten des PostOsInstallation

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

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

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

Download

Empirum WinPE PreOS Package zum optimierten Treiberhandling.

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

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

Los geht’s

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

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

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

Schritt 3:
Zuweisen eines Computers

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

Rückmeldungen sind willkommen!

Fehlersuche:

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

Beispielhafte Screenshots:

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

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

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

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