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 ist so anders bei Office 365?

Generell besteht die Umstellung darin, dass das die Office 365 Installation nicht mehr aus MSI und MSP Dateien besteht. Die „neue“ Installationsvariante hört auf den Namen „Click-To-Run“ oder kurz C2R bzw. ins deutsche übersetzt Klick und Los. Die nachfolgenden Links geben Antworten auf viele Fragen rund um das Thema „Breitstellung und Aktualisierung von Office 365“. Zusätzlich habe ich Links zur Aktualisierung von Office 365 per Matrix42 Patch-Management hinzugefügt.

Die häufigsten Fragen

Die hauptsächlichen Fragen bei der Bereitstellung von Office 365 sind:

• Welche Programme sollen alles verteilt werden?
• Was soll nicht Bestandteil der Bereitstellung sein (Publisher, OneDrive, Teams, …)?
• Welche Sprachen sollen bereitgestellt werden?
• Welcher Update-Kanal soll gewählt werden?
• Wo halten sich meine Clients am häufigsten auf?
• Wie und wo sollen die Updates-Quellen bereitgestellt werden?

Wie man sieht, sind das einige Fragen die beantwortet werden wollen, bevor man so richtig loslegen kann.

Was muss ich beachten, wenn ich zusätzlich Visio und Project installieren möchte?
https://docs.microsoft.com/de-de/deployoffice/install-different-office-visio-and-project-versions-on-the-same-computer

Was sind die Office Update Channels und was unterscheidet diese und welches ist der richtige Update Channel für mich oder meine Benutzer?https://docs.microsoft.com/en-us/deployoffice/overview-update-channels

Welchen Update Channel habe ich aktuell konfiguriert?
https://techcommunity.microsoft.com/t5/office-365-blog/how-to-manage-office-365-proplus-channels-for-it-pros/ba-p/795813

Wie aktuell bin ich?
Überblick über die aktuellen Versionen in den jeweiligen Update Channels:
https://docs.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date

Office 365 Updates

Welche Gruppenrichtlinien sind für das Update per Matrix42 Patch-Management zu setzen?
Wichtig zu wissen: Das Matrix42 Patch-Management für Office 365 „triggert“ nur die Aktualisierung und bringt nicht die Updates mit. Dazu müssen die aktualisierten Quellen für die Aktualisierung entweder auf einer UNC Freigabe, einer Web-Freigabe oder im Internet (Standard) abgelegt sein. Mein Wissensstand heute: Wenn man das Office365 Update gegen das Internet „triggert“, wird immer die aktuell verfügbare Version installiert, unabhängig von dem Office 365 „Patch“ den ich im Empirum Patch-Management freigegeben habe. Dies könnte man mit dem Parameter „Targetversion“ in der Gruppenrichtlinie steuern.
https://helpfiles.matrix42-web.de/2020_DE/M42_WebDocu.htm#WM/Manuals/Patch_Management/PM_Office.htm?

Gruppenrichtlinien setzen per GPO oder Registry
Eine Übersicht über die Einstellmöglichkeiten zu Office Click To Run per GPO findest Du hier.
https://admx.help/?Category=Office2016&Policy=office16.Office.Microsoft.Policies.Windows::L_UpdatePath

Wo in der Registry finde ich die Gruppenrichtlinien zu Office 365?
HKEY_LOCAL_MACHINE\software\policies\microsoft\office\16.0\common\officeupdate

Was muss ich beachten, wenn ich eine eigene Update Freigabe erstelle?
Wenn man die Aktualisierungen im internen Netz bereitstellen mag, muss man noch die Entscheidung fällen, ob die Freigabe per UNC oder http/https erreichbar sein soll.
Erstellt man eine UNC-Freigabe, so darf diese keine versteckte („$“) Freigabe sein. Hinweis: Die NTFS Berechtigungen sollten Zugriff für Everyone oder das Computerkonto erlauben! Die Quellen müssen im Unterordner Office\Data liegen (Die Quellen liegen dann also unter dem zuvorgenannten „updatepath“ + „\Office\Data“). Darin gibt es eine v<Architektur>.cab, eine v<Architektur>_<Version>.cab und ein Unterordner mit der <Version>. Der Unterordner mit der Version enthält die Quellen für die Installation. Die Dateien haben für eine deutsche Installation folgendes Namensschema: $$$1031.cab. In den Quellen können mehr Office Produkte/Module enthalten sein, als installiert werden. Sprich, die Quellen können in der Freigabe das Access beinhalten, aber in der Configuration.xml ist das Access ausgeschlossen.

Wie lade ich die Office 365 Quellen für eine Installation oder Aktualisierung herunter?
Die Quellen werden mit dem Microsoft Bereitstellungstool (Setup.exe) und einer passenden Konfigurationsdatei heruntergeladen.
Setup.exe /download <Datei.xml>
Die Konfigurationsdatei benötigt die Angabe des Ablageortes SourcePath=“<Pfad>“.
Bereitstellungskonfiguration: https://config.office.com/
Bereitstellungstool: https://www.microsoft.com/en-us/download/details.aspx?id=49117

Protokollierung

Das Logging der Installation als auch der Aktualisierung erfolgt nach %WinDir%\Temp\%Computername%-<Datum>-<Uhrzeit>.log
Wenn die Datei %Computername%-<Datum>-<Uhrzeit>.log größer oder annähernd 100kb groß ist, dann hat zumeist ein Update stattgefunden.
Die kann man u.a. auch daran festmachen, ob in der Datei „Update mode context starting: /update“ zu finden ist.
Wenn etwas fehlschlägt, oder man nach einem Fehler sucht. Dann sollte man in der Datei nach „error“ suchen.
Für die Installation kann man einen alternativen Log Pfad in der Bereitstellungskonfiguration angeben.

Erweiterte Protokollierung
Falls die standardmäßige Protokollierung von Office 365 nicht ausreichend ist, so kann man diese wie folgt erweitern:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3 /f
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1 /f

Quelle: https://docs.microsoft.com/de-de/office/troubleshoot/diagnostic-logs/how-to-enable-office-365-proplus-uls-logging

Weitergehende Scripte für Office 365 (Click to Run)
https://github.com/OfficeDev/Office-IT-Pro-Deployment-Scripts

Der Beitrag Office 365 Installation und Update – Gesammelte Werke erschien zuerst auf Workplace Management Blog.

UEM Agent Einführung und Funktionen

Ein Vorteil des UEM Agenten ist, das er unabhängig von der eingesetzten Empirum Version ist. So muss man nicht warten bis eine neue Empirum Version erscheint, um neue Empirum Agenten Funktionen nutzen zu können. Eine Übersicht über die Neuerungen und die jeweils aktuelle Version steht im Marketplace bereit.

UEM Agent Rollout

So sollte der Advanced Agent durch den UEM Agent ersetzt werden, wenn dies noch nicht geschehen ist. Der Rollout kann unter anderem durch die Neu-Installation des Windows 10 geschehen. Die Vielzahl der Agenten Aktualisierungen passieren jedoch im laufenden Windows Betrieb. Dies wird durch die Zuweisung des UEM Agenten per Paket erledigt.
Der Austausch des gerade laufenden Agenten ist bis zu einem gewissen Teil „Operation am Herzen“. Damit meine ich, wenn die „Operation“ fehlschlägt, verliert man mit unter Verbindung zum Endgerät und somit das Endgerät aus der aktiven Verwaltung.

Fehlerprävention

Wie sich bei den letzten Empirum Agent Updates herausgestellt hat, sollte man vor der Aktualisierung des UEM Agents sicherstellen, dass der Client über das .NET Frameworks 4.7.2 oder neuer verfügt. Dazu empfiehlt es sich das .NET Framework bereits vor dem UEM Agenten zu aktualisieren – besser noch eine Abhängigkeit des UEM Agenten auf die .NET Framework Version vorzunehmen. Diese Abhängigkeit setzt man als erweitere Bedingung im UEM Agent Paket. Wie das geht, habe ich in folgendem Artikel erklärt. Die Release Nummern des .NET Frameworks wiederum sind auf dieser Seite aufgelistet.

Fehleranalyse

Die Aktualisierung des UEM Agenten wird im nachfolgenden Log auf dem entsprechenden Endgerät aufgezeichnet: „%ProgramData%\Matrix42\Logs\UEM Agent Update\UEMAgentUpdate.log“. Hier kann man Hinweise für die fehlgeschlagene Aktualisierung finden bzw. sollte diese Datei für den Support sichern.

Möglichkeiten der Reparatur

Eine Reparatur einer gestrandeten Aktualisierung kann per Agent-Push geschehen, wenn der Computer erreichbar ist und diverse Voraussetzungen erfüllt sind. Wer es noch nicht kennt, den Agent-Push erreicht man über das Kontextmenü des Computers bzw. der Gruppe: Experte\Push Agent …
Weiterführende Informationen sind in der Matrix42 Hilfe zu finden:
Die wichtigsten Voraussetzungen habe ich bereits im Artikel „Empirum Agent Verteilung per Push“ beschrieben.

Agent Push

Möchte man mehrere Clients mit dem Agent Push erreichen, so kann man sich eine Zuweisunggruppe mit den betroffenen Systemen erstellen. Zusätzlich muss ein passendes Agent-Template zugewiesen sein und die Variable „MX42_AGENT_PUSH_PACKAGE_FOLDER“ auf die zu pushende Agent Version gesetzt sein. Um eine definierte UEM Agent Version zu installieren, ist es erforderlich, die Variable MX42_AGENT_PUSH_PACKAGE_FOLDER mit dem Pfad zur gewünschten UEM Agent Version zu belegen. Beispiel: UEM Agent Windows\2006.4

Bestimmen der Systeme …

Wenn eine Installation fehlschlägt, so verbleibt gerne die Installation des UEM Agents mit dem Status Running im SWDepot-Log. Diese fehlgeschlagenen Updates kann man mittels eines Filters in in der Rollout-Koordination oder im SWDepot-Log bestimmen. Für eine andere Art der Übersicht, habe ich einen Filter erstellt, der per Empirum DBUtil erstellt werden kann. Dieser Filter enthält alle Computer, die einen „Install“ Eintrag zum „UEM Agent“ mit dem Status „Running“ haben. Falls es nachfolgende erfolgreiche Installationen gibt, so sind diese derzeit trotzdem in diesem Filter enthalten. Dieser Filter kann also „false positive“ Ergebnisse beinhalten.

Dazu die angehängte Datei entpacken und über die Empirum Struktur kopieren. Nachdem das SQL Script „SW_UEM-Agent_Install_Running“ aus dem Unterordner Custom über Empirum DBUtil ausgeführt wurde, steht der Filter in der Management Console zur Verfügung.

Download

SW_UEM-Agent_Install_Running (523 Downloads )
MD5 Hash der Downloaddatei: B27EAA30786436633DBB1AB63409353F

Der Beitrag UEM Agent Rollout erschien zuerst auf Workplace Management Blog.

EmoCheck

Das Japan CERT stellt das Werkzeug EmoCheck auf GitHub zum Download bereit. Die Datei(en) müssen von dort heruntergeladen werden, ggf. auf Virustotal geprüft und in das unten stehende Paket eingebunden werden.

wpm-blog EmoCheck Paket

Nachfolgend gib es das wpm-blog EmoCheck Paket zum Download. In der ZIP Datei sind wiederum zwei ZIP Archive. Eines was man für den Import nutzen kann, oder alternativ das Paket zum Entpacken für den Packages Ordner und selbst hinzufügen in das SoftwareDepot. Welche Methode ihr auch immer präferiert, die zuvor genannten EmoCheck*.exe Dateien müssen im „pTools“ Unterordner des Paketes abgelegt werden.

EmoCheck Empirum Package (449 Downloads )
MD5 Hash der Downloaddatei: FEB7522A6A138EED59D779828E784D55

Wie läuft es ab, was kann konfiguriert werden?

Das Paket kopiert das Tool nach „C:\ProgramData\EmoCheck\Exe“ und generiert eine Ausgabe nach „C:\ProgramData\EmoCheck\Log“. Findet es im aktuellen Log einen definierten Text, so wird „Alarm“ geschlagen, indem das Paket auf einen Fehler läuft und je nach gesetzter Variable im Paket auch die Ausgabe auf den EmpirumServer nach „Empirum\Configurator\Log\EmoCheck\<Computername>“ überträgt (Voreinstellung). Die Log Dateien werden auf dem Client in „C:\ProgramData\EmoCheck\Log\Archive“ archiviert. Das Paket kann somit gerne komplett „silent“, mit der Verteilungsoption „Nicht anzeigen“ mittels Zeitplaner regelmäßig ausgeführt werden. Die Deinstallation räumt alles wieder weg.

Nur Überprüfung!

Das EmoCheck Tool, und somit auch dieses Softwarepaket, überprüft nur auf verdächtige Dateien! Falls eine verdächtige Datei gefunden wurde, muss noch Hand angelegt werden. Das Paket erstellt bereits einen Registry-Eintrag mittels dem man, ähnlich der Patch-Management Scan und Fix Kombination, mit einem Aufräumpaket hinterhergehen könnte. Aufgrund der Log/Rollout-Koordinations-Rückmeldungen sollte man die betroffenen Computer jedoch besser vom Netz nehmen bzw. per OS Installation komplett überschreiben.

Letzter Hinweis

Das Paket muss keine verlässliche Prüfung sein, da die Malware Schreiber und Jäger natürlich ein stetes Katz und Maus Spiel betreiben. Einen besseren Schutz bieten hier eher sogenannte NextGen AntiVirus Lösungen, die ausgefeiltere Mechanismen zur Malware Erkennung und Behandlung beinhalten.

Der Beitrag EmoCheck per Empirum Paket erschien zuerst auf Workplace Management Blog.

Los geht’s!

WADK

Eine Installation des WADK auf dem EmpirumServer ist eine Voraussetzung zur Erstellung der WinPE PXE-Images. Dazu habe ich bereits zwei Artikel geschrieben, die die Hintergründe und die Bereitstellung erläutern:

• Empirum: WinPE anstatt EPE als PXE-Image
• Microsoft WADK / WinPE Versionen

Matrix42 WinPE Erweiterung

Mit jeder neuen Empirum Version kommt auch ein Stand des WinPE PreBoot Supports in das Empirum System. Die PreBoot Support Entwicklung ist jedoch nahezu völlig von der Empirum Entwicklung entkoppelt. Man kann den jeweils aktuellsten WinPE PreBoot Support mit einer noch unterstützen Empirum Version einsetzen. Den aktuellen WinPE PreBoot Support gibt es im Matrix42 Marketplace zum Download.

Der WinPE PreBoot Support, der derzeit als EXE angeboten wird, entpackt, mit einem Doppelklick, im gleichen Ordner eine Empirum Struktur. Falls man in diesem Ordner in der Vergangenheit bereits einen WinPE PreBoot Support entpackt hat, sollte man das vorhandene Empirum Verzeichnis löschen. Nur zur Sicherheit: Nicht das produktiv genutzte Empirum Verzeichnis löschen! Alternativ kann man auch ein Komprimierungsprogramm (7-zip) nutzen, um es in einen Ordner des EXE Namens zu entpacken.

Die entpackte Struktur wird dann über die vorhandene produktive Empirum Struktur kopiert und bestehende Dateien werden ersetzt.
Laut Matrix42 wird ein Backup der produktiven Empirum Struktur empfohlen. Soweit bin ich bis dato noch nicht gegangen. Meines Erachtens vorteilhaft kann jedoch eine Sicherung des nachfolgenden Ordners sein: Empirum\EmpInst\Sys\Images\WinPE sein. Im zuvor angegebenen Ordner liegen die Matrix42 Quellen zur Erstellung des Empirum WinPE PXE-Images.

Konfiguration WinPE PXE-Image

Dazu wechselt man in der Management Console in den Bereich „Konfiguration\Boot Konfigurationen“. Mit einem Klick auf das „+ Neu“ (unten links) beginnt man mit der Erstellung eines neuen PXE-Images.

Dem PXE-Image gibt man einen Namen – der Dialog weißt einen schon darauf hin, welche Zeichen und Buchstaben erlaubt sind.
In der Beschreibung kann man für sich die Grundlage des WinPE PXE-Images festhalten.
Der Konfigurationstyp ist in diesem Fall natürlich: WinPE.

Die Auswahl des Agent-Templates hat folgende Funktion:
Aus dem Agent-Template werden die Informationen bzgl. des EmpirumAgent Benutzernamens, des Ausfall-Servers und ob DHCP Optionen genutzt. Diese Informationen werden vom erstellten PXE-Image genutzt, um während der Ausführung des WinPE die Verbindung zum EmpirumServer herzustellen.

Ab einem Hotfix für die Empirum Version 19.0.1 werden standardmäßig die „erweiterten Eigenschaften“ zur Erstellung ausgeblendet.

Mit der TFTP Blockgröße kann man „spielen“, um die Übertragung des WinPE zu beschleunigen bzw. auf Stabilität zu trimmen.

Zusätzliche Treiberverzeichnisse
Unter „Zusätzliche Treiberverzeichnisse“ gibt man eine Quelle für Treiber an, die in das WinPE eingebunden werden sollen.

• Das sind nicht alle Treiber die später für das zu installierende Windows genutzt werden:
• Zumeist werden hier Netzwerkkartentreiber für das WinPE auf Windows 10 Basis benötigt, damit das WinPE PXE-Image eine Verbindung zum EmpirumServer herstellen kann.
• Bis dato war nur einmal ein Storage Treiber notwendig – damit verfährt man jedoch in gleicher Weise.
• Ich nutze in der Abbildung ein selbst erstelltes Verzeichnis, was separat vom vorhandenen DRV Ordner liegt, da dies meines Erachtens in absehbarer Zeit überflüssig wird.
• Es werden alle Treiber, die in diesem Ordner und auch Unterordner liegen, in das WinPE eingebunden.
• Idealerweise generiert man im angegebenen Ordner Unterordner mit den Namen der Modelle oder Netzwerkkarten.

Erstellung PXE-Image

Bei der Erstellung des WinPE PXE-Images, mit Klick auf Speichern (unten rechts), werden dann die …

• Windows PE Quellen (C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment)
• Matrix42 WinPE Erweiterung (Empirum\EmpInst\Sys\Images\WinPE)
• angegebene „Zusätzliche Treiberverzeichnisse“
• mit Hilfe des Skriptes (CreatePXEWinPEMultiPlatform.ps1)

zu einem PXE-Image zusammengeführt.

Status der Erstellung

Die Erstellung dauert ca. 15-20 Minuten. Den Status der Erstellung kann man am Symbol bei der Konfigurationsübersicht (oben links) oder unter Management im Menü „Info“ unter „Back-end tasks …“ einsehen.

In der Konfigurationsübersicht gibt es die:

• Sanduhr – warten das der BTQHx64 Dienst es verarbeitet
• Zahnräder – der BTQHx64 Dienst ist dabei, Dauer ca. 15-20min
• grüner Haken – erfolgreich erstellt
• rotes Kreuz – Fehler bei der Erstellung

Fertig!

Die erfolgreiche Fertigstellung kann, wie zuvor beschrieben, an mehreren Stellen eingesehen werden. Hier ein Auszug aus dem Back-end task Log:

Für technisch Interessierte: Das erstelle PXE-Image ist anschließend unter „Empirum\EmpInst\Wizard\Image\VirtualRoots\BootEnvironment\<PXE-ID>“ zu finden.

Einmalige Einrichtung ist getan. Was nun?

Wenn man sich für eine neue WinPE Erweiterung (siehe oben) entscheidet, muss das PXE-Image neu erstellt werden, da die neuen WinPE PreOS Packages zumeist auch auf Neuerungen im Empirum WinPE zurückgreifen. Ob man dazu eine neue Konfiguration erstellt, oder nur die vorhandene mittels „Speichern“ mit den neuen Quellen aktualisiert, muss man selbst entscheiden. Benötigt das vorhandene PXE-Image aufgrund einer noch nicht getesteten oder neuen Hardware einen zusätzlichen Netzwerkkartentreiber, so legt man den Treiber im oben genannten Ordner („Zusätzliche Treiberverzeichnisse“) ab und generiert durch „Speichern“ das PXE-Image neu.

Fehler bei der Erstellung …

Bei Fehlern bei der Erstellung kann man entweder in die Back-end task Verarbeitung schauen, oder direkt in das aktuelle Log des BTQHx64 Dienstes auf dem EmpirumServer unter
%ProgramData%\Matrix42\Logs\BackendTaskQueueHost64.

Der Beitrag Empirum WinPE – PXE-Image Erstellung 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 (620 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 (434 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

PrepareDRVbyModel_Packages 1.1 (461 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.

Das hat mich dazu gebracht, ein WinPE Paket zu erstellen, die die meines Erachtens hilfreichen Informationen zusammenträgt und in das PXE.log schreibt. Ein Kunde hat mir hier auch schon passendes Feedback gegeben und weitere Wünsche geäußert. Somit wird es bestimmt nicht die letzte Version sein.

In Anlehnung an den Protokoll Droiden aus Star Wars „C-3PO“ habe ich das Paket nun WinPE „D-2PXE“ (Data to PXE.log) getauft. Das Paket kann eigentlich bei jeder WinPE Aktion vorweg bzw. als erstes laufen. Einen kleinen Auszug, was es protokolliert, findet ihr hier.

Zum Einbinden müsst ihr die angehängte ZIP entpacken und mittels des Paket Imports in Eure Empirum Umgebung einbinden. Konfiguriert werden muss in diesem Falle nichts. In der Matrix42 Hilfe gibt es ein verlinktes Dokument das vom Einbinden bis zum Nutzen der WinPE Pakete vieles erläutert.

Beispielausgabe PXE.log

Hier ein Screenshot und Beispiel des Log Inhaltes:

[PEAgent] [WinPE] Computername: PC006, Domain: wpm, FQDN: wpm-blog.local
[PEAgent] [WinPE] Manufacturer Model: [Dell Inc.] [OptiPlex 9010]
[PEAgent] [WinPE] BIOS Version: A08, FirmwareType: UEFI, SecureBoot: Disabled
[PEAgent] [WinPE] UUID: 4C4C4544-004A-5710-8038-C8C04F445831
[PEAgent] [WinPE] Mac-Address: 00B11C942953 - MAC8: 1C942953
[PEAgent] [WinPE] Size PhysicalDrive0: 233 GB
[PEAgent] [WinPE] Running Windows: Windows (TM) 10 Preinstallation Environment, Version 1803 (Build 17134.1)
[PEAgent] [WinPE] Client IP Address: 192.168.44.117
[PEAgent] [WinPE] UAF EmpirumServer: myEmpirumServer.wpm-blog.local
[PEAgent] [WinPE] UAF User: wpm-blog.local\Empirum
[PEAgent] [WinPE] Matrix42 UAF Version: 1.0.25.0
[PEAgent] [WinPE] PeBootServer: myEmpirumServer IP: 192.168.0.5

Ich bin gespannt über Euer Feedback und Anregungen.

Download

Empirum PreOS Package zur Anzeige der oben aufgeführten Informationen im Empirum PXE.log.
WinPE D-2PXE (639 Downloads )
MD5 Hash der Downloaddatei: FD2338429A180ECF02DF16027B991230B8E63E5

Der Beitrag WinPE: PXE.log mit Basisinformationen erschien zuerst auf Workplace Management Blog.