ClearAllDisks Variable erstellen

Möchte man die vorgenannte Funktion nutzen, so erstellt man die Variable „ClearAllDisks“ vom Typ Zahl in der Variablendefinition: DiskPartitioning.
Dazu wählt man in der Matrix42 Management Console, Administration, Extras, Variablendefinitionen … aus und navigiert zur vorhandenen Variablendefinition „DiskPartitioning“.
Durch einen Doppelklick oder der Auswahl und Bearbeiten, landet man in den Eigenschaften der Variablengruppe DiskPartitioning.
Hier fügt man die Variable mit einem Klick auf das „+“ Symbol hinzu.

Setzen der Variable

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.

Matrix42 Hilfe

Anbei der Text aus der Empirum Hilfe. Über diese Variable, die Sie selbst hinzufügen müssen, können Sie beim Ausführen des DiskPartitioning Paketes alle Festplatten bereinigen.
Hierzu muss man in der EMC > Administration unter „Extras > Variablendefinitionen“ die Variable „ClearAllDisks“ als Zahl zu DiskPartitioning hinzufügen und diese auf 1 setzen.

Der Beitrag Empirum WinPE – Löschen von Partitionen 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.

Zutaten zusammenstellen …

Import der Pakete

Wer die vorhandenen PreOS Pakete nutzen mag, kann direkt zum nächsten Punkt springen. Wer wiederum aktuelle Pakete importieren mag, muss in der Management Console unter Konfiguration, Software-Depot mit der rechten Maustaste auf das Register „Matrix42 PreOS Packages“ klicken und „Import/Export“ auswählen. Im darauffolgenden Dialog wählt man dann den zumeist vorgegebenen Ordner „\\%EmpirumServer%\Configurator$\PackageStore“ aus.
Die Schritte für einen erfolgreichen Import von PreOS Paketen sind nun hier per Screenshots dokumentiert:

Auswählen des Quellverzeichnisses, wie z.B.: \\%EmpirumServer%\Configurator$\PackageStore …
Da im „PackageStore“ bestimmt mehr als die gewünschten Pakete vorliegen und angeboten werden, ist es ratsam zuvor per „Keine auswählen“ die Auswahl zu negieren. Dann wählt man die für sich notwendigen Pakete aus der Liste aus und startet den Importvorgang. Die Liste der Pakete ist weiter unten zu entnehmen. Die Abbildung zeigt eine exemplarische Auswahl, da das Paket PxeOffAndReboot bis dato unverändert blieb.

Werden die Pakete auf der Zusammenfassung rot angezeigt und nicht importiert, dann startet entweder die Management Console nochmals neu und versucht die Schritte noch einmal, oder schaut nach, ob das Paket vielleicht schon in der Dateistruktur vorliegt. Wenn ja, so löscht es aus der Dateistruktur und startet anschließend den Importvorgang nochmals von neuem.

Nach einem erfolgreichen Importvorgang, werden die Pakete im Matrix42 PreOS Packages Ordner ähnlich wie folgt angezeigt.

Die neu importierten Pakete werden im Status „nicht freigegeben“ importiert und sind braun eingefärbt. Dies kann sich in Zukunft noch ändern, doch derzeit müssen die Pakete noch einzeln zur Installation freigegeben werden. Dazu öffnet man die Paketeigenschaften mit einem Doppelklick bzw. wählt „Eigenschaften“ im Kontextmenü eines jeden Paketes.

Welche Pakete werden benötigt?

Zur Durchführung einer Windows Installation benötigt man die nachfolgenden Pakete.

• DiskPartitioning – Vorbereiten der Festplatte
• DriverIntegration – Kopieren der Treiber des Models auf die vorbereitete Festplatte
• WindowsInstallation – durchführen der Windows Installation samt der Treiber und kopieren/installieren des UAF Agents vom WinPE
• PxeOffAndReboot – deaktivieren des WinPE PXE-Boots
• DomainJoin – Hinzufügen des Computers zur Domäne
• EmpirumAgentSetup – Installieren des vollwertigen Empirum Agenten und entfernen des UAF Agenten, Neustart …

Besonderheiten: Wenn man die PreOS Pakete aktualisiert bzw. aktuelle Pakete nutzt, muss man auch sein Empirum WinPE PXE-Image aktualisieren.

Die Reihenfolge ist wichtig!

Die Pakete müssen sich zur korrekten Verarbeitung in der oben aufgeführten Reihenfolge befinden. Auch bei neu importierten Versionen von Paketen muss auf die Reihenfolge geachtet werden. Dazu arrangiert man die Pakete, per Drag & Drop, von oben nach unten im SoftwareDepot.

Windows Installation Bundle

Man kann die zuvor genannten PreOS Pakete später einzeln zu seiner Konfigurations- oder Zuweisungsgruppe hinzufügen, oder eine UND-Klasse (Bundle) erstellen die diese Pakete enthält. Bei der Zuweisung der Pakete zu einer UND-Klasse muss die Reihenfolge nicht beachtet werden. Bei der clientseitigen Verarbeitung ist die Reihenfolge im SoftwareDepot maßgebend. Hier ein Beispiel für eine UND-Klasse, die im SoftwareDepot erstellt werden kann.

Der Beitrag Empirum WinPE – PreOS Packages 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.

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 (422 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

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

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.

Neue EPE4 Quellen …

Der Download neuer EPE Quellen erfolgt über den Matrix42 Marketplace. Dazu muss ein Marketplace bzw. ein Matrix42 Account vorhanden sein. Die neuen EPE4 Versionen, samt ihrer Historie werden unter folgendem Link im Marketplace angeboten.

Import der EPE Version in die eigene Empirum Umgebung

Die heruntergeladene ZIP Datei legt man am besten in einem separaten Ordner ab, auf den von der Management Console zugegriffen werden kann. Die Matrix42 Management Console „Als Administrator starten …“ ausführen und auf den Tabulator Konfiguration, OS Installer, Import wechseln. Starten des Import Vorganges wie ab Kapitel 2.3 dieser Matrix42 Hilfe Seite erläutert.

Wichtig ist hier, dass auf dem zweiten Import-Dialog der Name angepasst wird für eine bessere Unterscheidung bzw. Zuordnung beim Erstellen der Bootkonfiguration – ansonsten heißen alle „Empirum Preboot Environment 4“. Dieser Hinweis ist auch beim Import von Betriebssystem-Quellen wie Windows 7 und Windows 10 von Vorteil. Bei den Betriebssystem kann man hier wunderbar den Namen um Informationen wie Service Pack, Patch-Stand, PRO oder Enterprise, uvm. erweitern.

Der angepasste Import führt dann zu einem individuellen „BS Paket“ Namen, wie in dem hier verlinkten Artikel bereits angezeigt wird.

Erstellen einer Boot-Konfiguration

Das Erstellen der Boot Konfiguration ist ab Kapitel 2.4 des obigen Links erklärt. Hier sind ein paar Punkte besonders erwähnenswert: Wichtig ist hier, dass man eine Aktualisierung anstößt, wenn man gerade zuvor neue EPE Quellen importiert hat.
Meines Erachtens erzeugt man pro EPE Version auch eine eigene EPE Konfiguration, wie. z.B.: EPE464 für die EPE Quellen mit der Version 4.6.4. So kann man diese EPE4 Version explizit testen und ggf. auch nur einer bestimmten Hardware zuweisen.

Ein weiterer wichtiger Punkt kann sein, dass man unter Konfiguration, OS Installer, Bootdisk, Diskettenkonfiguration ggf. einen anderen Benutzer eingetragen hat, als den Benutzer den man in der Agenten-Konfiguration nutzt. Dies kann sich auf den Zugriff auf die EmpInst$ Freigabe, als auch den Domain-Join auswirken, wenn in der Betriebssystem-Vorlage definiert ist, dass der Domain-Join mit dem Benutzer aus der „Diskettenkonfiguration“ geschehen soll.

Der Beitrag EPE4 Import und Konfiguration ab Empirum 16.1.3 erschien zuerst auf Workplace Management Blog.

EDIT 09.01.2018: Die Erfahrung hat gezeigt, dass die Nutzung bzw. das Setzen des Wertes auf 1 für Windows 10 problemlos funktioniert. Windows 7 wiederum bleibt ab und zu bei der OS Installation mit dem gesetzten Wert stehen. Hier sollte man von der Optimierung absehen.

Die Variable WINPE_WIMBOOT befindet sich als Sammlung unterhalb von INTERNAL_OS_INSTALLER_CONFIG.

An dieser Stelle kann man mittlerweile auch diverse Kernel-Parameter bzw. Variablen setzen, wie den rot eingezeichneten Wert EIS_REINSTALLALLOW.

Der Beitrag Kleiner Boost für die OS-Installation erschien zuerst auf Workplace Management Blog.

SSD Erkennung per Tool

Dazu muss man das Rad nicht neu erfinden. Es gibt bereits fertige Tools wie dieses hier. An dieser Stelle ist auch beschrieben bzw. auf einen Microsoft Artikel verwiesen, welche Kriterien alles für eine SSD Erkennung herangezogen werden.

Wie nutze ich das Tool?

Der Aufruf geschieht wie folgt:
IsSSD.exe <Laufwerksbuchstabe>, z.B.: IsSSD.exe C:

Wie nutze ich es in der Empirum Setup.inf?

Hier ein Beispiel:

[Set:Product]
CALL "%SRC%\IsSSD.exe" C:
IF "%ErrorLevel%" == "1" THEN "IsSSD" Else "IsNoSSD" EndIf

[IsSSD]
Echo SSD installed!

[IsNoSSD]
Echo No SSD installed!

Wie nutze ich es in einer Batch Datei?

Auch dazu ein kleines Beispiel:

:Begin_SSD_Check
IsSSD.exe C:
IF "%ERRORLEVEL%" == "1" goto Hdd_is_SSD
Echo Hdd is not a SSD Drive!
Goto End_SSD_Check
:Hdd_is_SSD
Echo Hdd is a SSD Drive!
:End_SSD_Check

Gutes gelingen und viel Spaß damit!

Der Beitrag SSD Festplatten Erkennung im Script erschien zuerst auf Workplace Management Blog.