Unattended Uninstallation Dialog

Wenn Du beim Nutzen des Package Wizards zum Erstellen einer „Unattended“ sprich „Silent“ Installation einer EXE an den Dialog zur Deinstallation kommst, kannst Du das „Basis Verzeichnis“ nicht anpassen. In das Eingabefeld für das Deinstallationsprogramm kannst Du den Aufruf „C:\Program Files (x86)\My Program\unins000.exe“ eintragen und den Assistenten erfolgreich beenden.

Deinstallation schlägt fehl

Die Tests zur Deinstallation des Programms im Rahmen der Paketierung schlagen fehl. Warum?

Fehlersuche / Behebung

Um herauszufinden, warum der Fehler auftritt, müssen wir uns die Abfolge der Befehle zur Deinstallation der Software in unserem erstellten Paket ansehen. Ein Blick in die Sektion [Set:Deinstallation] der Setup.inf, die für die Deinstallation zuständig ist, bringt den Fehler schnell zum Vorschein. Hier wird versucht, den folgenden Befehl auszuführen:

-Call "%Src%\C:\Program Files (x86)\My Program\unins000.exe" /S

Der Teil „%SRC%\C:\…“ sieht nicht nur seltsam aus, sondern kann auch nicht funktionieren. Angepasst, sollte der Aufruf wie folgt ausschauen:

-Call "C:\Program Files (x86)\My Program\unins000.exe" /S

oder besser noch

-Call "%ProgramFilesDirx86%\My Program\unins000.exe" /S

Mit diesen Anpassungen sollte die Deinstallation nun erfolgreich durchgeführt werden.

Anpassen der Vorlage

Damit die Anpassung nicht immer wieder im erstellten Paket vorgenommen werden muss, passt man die Vorlage „Unattended.inf“ (Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates) an. Dazu entfernt man aus der nachfolgenden Zeile:

-Call "%Src%\{UnattDeInst}" {UnattDeInstPar}

das %SRC%\ und macht daraus:

-Call "{UnattDeInst}" {UnattDeInstPar}

Der Beitrag Empirum Paket – Deinstallation ohne Quellen 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.

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.

Deswegen hatte ich zum Paketieren bereits den Empirum – Software Paketierung Selbststudium Sammelbeitrag erstellt. Für das Thema Empirum und WinPE habe ich nun den Beitrag Empirum – WinPE OS Installer Zusammenfassung erstellt. Diesen werde ich auch unter Links (im Menü) verknüpfen, damit man immer wieder schnell die Empirum WinPE Beiträge zur Hand hat.

In diesem Zusammenhang möchte ich auch anmerken, dass ich die Tage die Pakete PrepareDRVbyModel_Packages und WinPE D-2PXE von der Version und Funktionalität angehoben habe.

Der Beitrag Hinweis zu Empirum – WinPE OS Installer Zusammenfassung erschien zuerst auf Workplace Management Blog.

Empirum WinPE Support

Einfach mal machen …
Empirum WinPE – PXE Image Erstellung
Empirum WinPE – Betriebssysteme in Empirum importieren
Empirum WinPE – PreOS Packages
Empirum WinPE – Windows Installation
Empirum WinPE – neues Computermodell
Empirum WinPE – Treiber für Windows

Empirum WinPE PreBoot Update mit “doppeltem Boden”

Troubleshooting

Ein paar erste Troubleshooting Tipps.
Empirum WinPE Boot Troubleshooting
Empirum WinPE OS-Installation und danach Troubleshooting

Voraussetzungen / EPE Gegenüberstellung

Welches WADK ist auf dem EmpirumServer installiert, woher bekomme ich ein aktuelles?
Microsoft WADK / WinPE Versionen (Stand 06/2019)

Was sind die Voraussetzungen an den EmpirumServer bzgl. der WinPE OS Installer Thematik?
Matrix42 OS Deployment mit WinPE – Vorausetzungen

Achtung, der nachfolgende Beitrag bezieht sich auf einen frühen Stand der WinPE OS Installer Unterstützung. Es sind nun mehr einzelne Pre OS Pakete geworden, um eine granularere Steuerung vorzunehmen.
Empirum: WinPE anstatt EPE als PXE-Image

Für alle Umsteiger, was hat sich so geändert?
Empirum WinPE – EPE Gegenüberstellung

PreOS-Packages

Die aktuellen und nahezu alle nachfolgend aufgelisteten PreOS-Packages sind in einem Empirum WinPE Extension Pack zusammengestellt.
Empirum WinPE Extension Pack

Nun folgen ein paar Beiträge mit eigenen Paketen und Hinweisen zum WinPE OS Installer. Das erste Paket läuft am besten auch als erstes, auch wenn es nach dem DiskPartitioning Paket aus dem SWDepot „verschwindet“. Wer das nicht mag, kann es auch direkt danach laufen lassen, dann bleibt der Status „grün“ :).
WinPE: PXE.log mit Basisinformationen

Nachfolgend ein Ersatz für das standardmäßige DriverIntegration Paket.
Wieso, weshalb ich mir die Mühen gemacht habe, lest ihr am besten direkt in den Beiträgen.
WinPE Paket – DriverIntegration Ersatz aktualisiert
Empirum WinPE Paket – DriverIntegration Ersatz

Ein Ergänzungspaket zum DomainJoin, bei dem ich Ideen und Umsetzungen gebündelt habe, da das standardmäßige Paket unserer Meinung nach einen entscheidenden Makel hat.
PreOS Paket: MoveComputerToEmpirumOU

Der Beitrag Empirum – WinPE OS Installer Zusammenfassung erschien zuerst auf Workplace Management Blog.

Empirum PE (Linux)

Das EPE (Empirum PreInstallation Environment) auf Linux Basis verarbeitet mittels des EIS Interpreters die zugewiesenen Jobs (EIS Skripte), die per OS.INI im MAC8 Verzeichnis (letzten 8 Stellen der MAC-Adresse) zugewiesen werden. Die Abfolge der Aufträge sind durch das EIS Skript weitestgehend vorgegeben. An definierten Punkten kann man mittels der Custom EIS Skripte in den Ablauf eingreifen. Bei einer Betriebssysteminstallation werden das Windows PE und die Betriebssystemquellen auf die lokale Festplatte übertragen und von dort die Windows Installation per Windows PE gestartet. Die Installation wird mittels der Betriebssystemvorlage (OS.INI) beschrieben und parametrisiert (Windows Einstellungen, Lizenz-Schlüssel, Partitionierung, Domain-Join, uvm.). Am Ende einer Betriebssysteminstallation wird mittels des Parameters „Befehl“ der Empirum Agent installiert und der Übergang zur Softwareverteilung bereitet.

Empirum WinPE (Windows PE)

Das Empirum WinPE wird ebenso über die Management Console, Konfiguration, Bootkonfiguration erstellt. Bei der Erstellung bedient sich Empirum dem auf dem EmpirumServer installierten WADK (C:\Program Files (x86)\…), nicht dem in Empirum importieren WADK. Das erstellte Empirum WinPE beinhaltet einen EmpirumAgenten (Matrix42 UAF) und diverse WinPE Erweiterungen. Der im WinPE integrierte UAF Agent verarbeitet die zugewiesenen PreOS Pakete (aus der %Computername%.DDC).

Hier gilt die Reihenfolge, von oben nach unten, wie sie im SoftwareDepot festgelegt wurde. Die WinPE Pakete (auf Basis von powershell) werden über die EMC Variablen parametrisiert und nicht mehr über die OS.INI. Deswegen muss bei einer Aktivierung auch kein Haken mehr bei „Betriebssystemkonfiguration (OS.INI) erstellen“ gesetzt werden. Die Variablen bzw. die Variablengruppierungen sind nach den zugewiesenen Paketen benannt (z.B. DiskPartitioning, WindowsInstallation). Im Paket WindowsInstallation wird ebenso ein minimaler Matrix42 UAF Dienst installiert, der nach dem Paket „PxeOffAndReboot“ bis zur Installation des eigentlichen Matrix42 Windows Agenten durch das Paket EmpirumAgentSetup aktiv ist. Somit werden die PreOSPakete bis zum PxeOffAndReboot im Kontext des WinPE ausgeführt und im Anschluss im Kontext des installierten Windows. In dem Installations-Vorgang mittels WinPE stellt die erfolgreiche Ausführung des EmpirumAgentSetup Paketes den Übergang zur Softwareverteilung dar. Eigene PreOS Pakete können mittels Powershell Kenntnissen und dem PreOS Package Editors erzeugt und in die Abfolge eingebaut werden.

PreOS Paket Variablen

Die folgende Variablen bzw. Variablengruppen müssen für eine erfolgreiche Installation per WinPE gesetzt werden.

• DiskPartitioning (optional)
• DriverIntegration (optional)
• WindowsInstallation
• FQDN
• ORGANIZATIONAL_UNIT
• TimeZone
• DomainJoin
• MX42_AGENT_PUSH_PACKAGE_FOLDER

Zu diesem Thema werde ich in Kürze einen gesonderten Artikel erstellen. Wer nicht warten mag, sollte das PDF, dass der Empirum WinPE Erweiterung beiliegt, nutzen.

Vorteil der PreOS Pakete

Die sogenannten PreOS Pakete kann man, wie oben beschrieben, auch selbst erstellen. Damit man die Pakete in Empirum importieren und nutzen kann, muss man diese mit dem PreOS Package Editor erstellen. Durch das beschriebene Konstrukt kommen die Vorteile des WinPE Boots und der einzelnen Pakete erst richtig zum Vorschein. Beispielhaft, kann man bei einer Windows 7 zu Windows 10 Migration direkt auch das BIOS aktualisieren, auf UEFI umstellen, uvm. Diese Möglichkeiten waren mit dem EPE und der EIS basierten Installation nicht bis schwer umzusetzen.

Beispiele selbsterstellter PreOS Pakete

In Kundenumgebungen habe ich bereits Pakete wie:

• BIOS Update
• BIOS Konfiguration in unterschiedlicher Art und Weise
• UEFISecureBootValidator
• PostOSInstallation

erstellt und genutzt.
Einen Teil der Pakete hatte ich bereits veröffentlicht.

In Kürze werde ich ein Update der gesammelten und universellen Werke bereitstellen.

Der Beitrag Empirum WinPE – EPE Gegenüberstellung 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 (643 Downloads )
MD5 Hash der Downloaddatei: FD2338429A180ECF02DF16027B991230B8E63E5

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

Was muss man tun, um es zu nutzen?

WinPE Erweiterung installieren.

Zu aller erst muss man die WinPE Erweiterung installieren. Wie zuvor beschrieben gibt es die WinPE Booterweiterung im Matrix42 Marketplace. Diese Erweiterung musst Du in Deine Empirum Umgebung installieren/kopieren. Dazu liegt dem Download ein PDF bei, dass die Installation beschreibt.

Installation des WADK auf dem EmpirumServer

Auf dem EmpirumServer muss das WADK (möglichst aktuell) installiert sein. Die WinPE Erweiterung bedient sich dem installierten WADK und nicht dem in Empirum importierten WADK. Die Installation des WADK habe ich im Beitrag „Matrix42 OS Deployment mit WinPE – Vorausetzungen“ bereits beschrieben.

Erstellen einer Bootkonfiguration

Anschließend muss eine Bootkonfiguration vom Typ „WinPE“ anstatt „EPE“ erstellt werden. Dabei wird das PXE-Image mit dem Inhalt des WinPE erstellt. Die Besonderheiten bzgl. der Optionen EFI und BIOS sind ebenfalls in dem WinPE HowTo PDF Dokument erläutert.

WinPE PXE-Image

Das erstellte WinPE PXE-Image enthält den Matrix42 UAF (Universal Agent Framework). Der UAF wird dazu benutzt die PreOS-Pakete (Empirum Pakete für die WinPE Verarbeitung) auszuführen. Matrix42 liefert einige WinPE Beispielspakete mit. Schlußendlich bestimmen mehrere einzelne PreOS-Pakete die WinPE Auftragsabfolge bis der PXE-Boot deaktiviert wird.
Zum Beispiel kann man mit den folgenden drei Paketen eine Windows 10 Installation durchführen.

• DiskPartitioning (Vorbereiten/Partitionieren der Festplatte)
• DriverIntegration (Ablegen der Hardware-Modell spezifischen Treiber)
• WindowsInstallation (Installation von Windows 10 unter Nutzung der abgelegten Treiber)

Gesteuert werden diese Pakete über dazugehörige Variablen die pro Gruppe oder Computer gesetzt werden. Hier muss man etwas umdenken, da man keine Betriebssystemvorlage mehr erstellt und zuweist, sondern die PreOS-Pakete zuweist und die dazugehörigen Variablen setzt.

Bei der zuvor genannten Abfolge muss nicht Schluß sein. So kann man vor der OS Installation ggf. auch das BIOS aktualisieren und konfigurieren uvm. Für die BIOS Aktualisierung hat Matrix42 auch bereits ein Paket bereitgestellt.

Mein Fazit

Die Idee WinPE zum Starten und Verarbeiten von Befehlen per PXE birgt viel Potential für die Zukunft, da u.a. die Basis Windows anstatt Linux und die genutzte Skript-Sprache powershell anstatt „EIS“ ist. Von den bereitgestellten PreOS-Paketen bin ich jedoch etwas enttäuscht. Das DriverIntegration, WindowsInstallation und BIOSUpdate Paket kann man meines Erachtens als Grundlage und erahnen der Möglichkeiten nutzen bzw. auf deren Grundlage eigene Pakete erstellen. Die Nutzung dieser Pakete zur produktiven Installation von Windows 10 Systemen stehe ich jedoch noch kritisch gegenüber. Mehr dazu in Kürze.

Wenn Du es bereits getestet hast – wie ist Dein bisheriges Fazit?

Der Beitrag Empirum: WinPE anstatt EPE als PXE-Image erschien zuerst auf Workplace Management Blog.

Ich hatte mir schon lange vorgenommen, die Basis des Blogs zu aktualisieren und Kleinigkeiten an der Seite zu überarbeiten. Nun ist die Zeit gekommen und es war ausnahmsweise mal einfacher als vermutet. Das darf es ja auch mal geben!

So wünsche ich Dir/Euch einen guten Start in´s neue Jahr! Bleibt gesund und aktiv.
Ich hoffe, es gibt weiterhin regen Austausch rund um die hier vorgestellten bzw. vielleicht auch noch nicht vorgestellten Themen.

Viele Grüße
Jochen

Der Beitrag Neues Jahr! erschien zuerst auf Workplace Management Blog.

Los geht’s!

Diese Linksammlung ist auf dem Stand: 07.04.2020

Generelles

• Software-Paketierung / Repaketierung
• Aufwand zur Erstellung eines Softwarepaketes
• Verzeichnisse und Freigaben des Empirum Servers
• Softwareverteilung mit Empirum von Matrix42
• Wissenswertes zum Installationskontext

Erstes Paket erstellen und verteilen

• Softwarepakete erstellen und verfeinern
• Empirum Paket erstellen – MSI
• Aufgepasst im Package Wizard – MSI
• Platform Eigenschaft – Empirum Setup.inf
• Empirum Setup.inf – Platform Wert Tabelle
• Setup.inf Abarbeitung
• Erste Setup.inf Anpassungen
• Aufgepasst beim Einfügen eines Paketes in das SoftwareDepot
• Einbinden eines Software-Paketes in Empirum (Basis)

Paketierung – Erweitert

• Umgebungsvariablen
• Empirum Setup.inf – Variablen
• Empirum Paket Versionen – Früher an später denken?
• Empirum Kopierbefehl und Kopierflags
• Empirum Paket – Registry ändern
• Registry ändern mit REG Dateien
• Setup.inf – Datei pro Benutzer kopieren
• Empirum Setup.inf Skript vorzeitig verlassen
• Neustart oder nicht
• SystemShutdown vs. SetReboot
• Empirum – Übernehmen von vorhandenen Installationen
• Empirum und For – Next Schleife
• Empirum – NTFS Berechtigungen setzen
• Verknüpfungen / Links erstellen
• Empirum Setup.inf – SoftwareDepotDistributionFlags
• Schließen von geöffneten Programmen
• Verstecken von Software in der Systemsteuerung
• Empirum Sektionen mehrfach aufrufen
• Unattended Paket – ErrorLevel Abfrage verbessern
• Unattended Paket – Reparatur Funktion einbauen
• Unattended Paket – Deinstallation ohne Quellen

Software-Management

• Empirum – Paket in das SoftwareDepot einfügen
• Aufgepasst beim Einfügen eines Paketes in das SoftwareDepot
• Einbinden eines Software-Paketes in Empirum (Basis)
• Einbinden eines Software-Paketes in Empirum (Erweitert)
• Empirum Paketeigenschaft – Erlaube Deinstallation
• Erweiterte Paketvoraussetzungen

Paketierung – Besonderes zur Verteilung

• Empirum Paket Versionen
• Softwarepakete-Updateverhalten Verteilen von neuen Versionen
• Empirum Paket – Registry, SoftwareDepot, Version
• Empirum Paket – Revision
• Empirum Paket – Revisionserhöhung bei großen Installationen
• Definition des Zeitplaners

Anpassen der Paketierungsvorlagen

• Anpassung Paketierungsvorlage – Einleitung
• Anpassung Paketierungsvorlage – Kopfdaten
• Anpassung Paketierungsvorlage – MSI Paket
• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Anpassung Paketierungsvorlage – lokaler Setup.inf Ablageort

Der Beitrag Empirum – Software Paketierung Selbststudium erschien zuerst auf Workplace Management Blog.