wpm-Blog WinPE-Extension-Pack 1.3

Aufgrund der Windows 11 Implementierung und Unterscheidung im OS-Installer habe das PrepareDRVbyModel_Packages Paket überarbeiten „müssen“. Der Vorteil für Euch – auch eine weitere Funktion ist nun für alle nutzbar. Es ist die CommonDrivers Funktion. Ein Ordner mit Treibern wird für alle Modelle kopiert. So könnt ihr in diesem Ordner, die (neuen?) Dockingstation oder USB-Netzwerkadapter Treiber ablegen und müsst dazu nicht alle Modellpakete erneut anpassen. Es gibt einen Standard-Ordner (CommonDrivers) der kopiert wird, alternativ könnt ihr per Variable einen anderen Namen angeben. Den Gedanke hatte ich auch schon einmal und ein Nutzer hat mich da noch etwas „geschuppst“ – jetzt steht es Euch allen zur Verfügung. Ich hoffe, es gefällt Euch.

Das Paket, dass den Hotfix installiert, damit Windows 10 Pro keine ungewollten Neustart direkt nach WinPE Phase durchführt, habe ich in das Extension Pack aufgenommen. Ihr könnt selbst entscheiden, ob ihr es benötigt, oder nicht.

Das aktuelle wpm-Blog WinPE-Extension-Pack bekommt ihr hier.

innomea WinPE Extension Pack

Neben den WinPE Erweiterungen die ihr hier auf meinem Blog seht, arbeite ich auch den WinPE Erweiterungen der innomea mit. Die Erweiterungen der innomea sind hauptsächlich Ergänzungen zu den Paketen die Matrix42 anbietet. Mit den Ergänzungspaketen (HardwareProfileValidator und CommonDrivers) sollen annährend die Funktionen bereitgestellt werden, die z.B. hier mit PrepareDrvByModel_Packages erreicht werden.

Das innomea PostWindowsInstallation Paket wiederum ist eine starke Weiterentwicklung des hier angebotenen PostOSInstallation. Dieses Paket ermöglicht viele Anpassungen an der Windows Installation, die einige von Euch noch von den Betriebssystemvorlagen her kennen. Dabei wurde teilweise auch auf Einträge im Matrix42 ideas Portal eingegangen.

Hier ein kleiner Auszug der Funktionen, die ihr zum Großen Teil per Variablen steuern könnt: Installation von Treibern per EXE/MSI, Firewall Modifikationen, Festplatte/Partition C: umbenennen, Support, Besitzer Informationen hinterlegen, EmpirumServer der OS-Installation als Umgebungsvariable setzen, „Kennwort läuft nicht ab“ für den zusätzlichen lokalen Admin setzen, uvm.

Den kompletten Umfang und die weiteren Pakete könnt ihr hier einsehen.

Matrix42 DomainJoin Paket

Das Matrix42 DomainJoin Paket wird in Kürze auch eine neue Version erhalten, dessen Vorteil einige zu nutzen wissen werden. Vielen Dank an die Beteiligten der Matrix42 für eure offene Kommunikation und Umsetzung!

Beyond Empirum WinPE

Natürlich dreht sich die hier zumeist angesprochene Matrix42 Empirum Welt nicht nur um WinPE. Jedoch kann man ganz gut erkennen, dass diese mir sehr viel Spaß bereitet. Matrix42 ist dabei eine größere Änderung im UEM-Agent vorzunehmen. Darauf werde ich mit Euch in Kürze schauen.

Stay save!

Wer mich kennt, weiß wie sehr ich versuche „Anglizismen“, wenn möglich, zu umgehen. Es gibt meines Erachtens jedoch einige Situationen bei diesen diese Worte oder Sätze einfach kürzer und treffender sind. Wie auch immer: Bleibt weiterhin gesund in dieser „unbekannten“ und noch „verrückteren“ Zeit!

Der Beitrag Aktualisierungen Frühjahr 2022 erschien zuerst auf Workplace Management Blog.

Matrix42 SubDepot PXE Service Configuration

Da dies neben dem Self Provisioning die zweite Konfiguration für den PXE-Dienst ist, habe ich es kurzfristig in einem Empirum Paket umgesetzt. Somit kannst Du die Einstellung einfach und nachvollziehbar auf einer Vielzahl von SubDepots bzw. PXE-Servern setzen.

Schritte …

Dazu ist das unten angefügte ZIP zu entpacken und in/über die Empirum Struktur zu kopieren, wie man das von Empirum Erweiterungen und Updates bereits kennt. Im Anschluss importierst Du im SoftwareDepot das Paket „Matrix42 SubDepot PXE Service Configuration 1.0“, welches im Register „Empirum“ eingebunden wird. Das Paket bringt für die zwei Optionen Variablen mit, die Du unter SUBDEPOT_PXESERVICE_CONFIG für die SubDepots anpassen kannst. Im Standard sind beide Optionen deaktiviert. Dann fehlt nur noch die Zuweisung und Installation des Paketes.

Variablen

EnableSelfProvisioning
[1|0] 1= Aktiviere SelfProvisioning, 0=Deaktiviere SelfProvisioning
Standardwert = 0

DisableDhcpRelayAgentOption
[0|1] 1=Deaktiviere DhcpRelayAgentOption Nutzung, 0=Aktiviere die Nutzung der DHCP Option 82
Standardwert = 1

Download

Matrix42 SubDepot PXE Service Configuration (398 Downloads )
MD5 Hash der Downloaddatei: 7E386171796ECD409B1EF827B970B1E5

Zusammenfassung

• ZIP entpacken und in die Empirum Struktur kopieren
• Paket im SoftwareDepot importieren
• Paket den SubDepots zuweisen
• Variablen je nach Anforderung anpassen
• Paket installieren

Fertig!

Der Beitrag Erweiterte Empirum PXE-Server Konfiguration erschien zuerst auf Workplace Management Blog.

Auf der anderen Seite hat das Patch-Management auch Vorteile. So wird selbst Software, die man von Hand installiert hat, aktuell gehalten. Ergo – die Aufwände die eingesetzten Windows-Systeme, hinsichtlich Sicherheitslücken, aktuell zu halten sind gering.

Neben den beiden genannten Vor- und Nachteile, gibt es noch ein paar mehr Dinge, die jeder für sich betrachten muss. Jetzt heißt der Artikel jedoch Anpassungsmöglichkeiten und nicht Vor- und Nachteile Patch-Management.

Anpassungsmöglichkeiten

Damit man jedoch gewisse Anpassungen rund um den Patch-Vorgang durchführen kann, hat Matrix42 Vorkehrungen getroffen. Im Fix Paket (Fix.inf) gibt es sogenannte Einsprungpunkte. Die Fix.inf schaut, ob es im gleichen Verzeichnis eine PreSettings.inf, PostSettings.inf oder KillOpenApplications.inf gibt und führt diese aus. Dies bietet die Möglichkeit: vor (PreSettings) und nach (PostSettings) dem Patch-Vorgang einzugreifen. Die KillOpenApplications.inf ist wiederum dazu gedacht, den Anwender auf ein geöffnetes Programm hinzuweisen, dass nun zur Aktualisierung ansteht. Alle drei Skripte sind unabhängig von den Veränderungen an den maßgeblichen Abläufen und können einfach bei neuen Empirum Major Versionen übernommen werden.

Nutzungsbeispiele

PostSettings.inf

• Lösche Verknüpfungen vom Desktop oder aus dem Startmenü.
• Deaktiviere die AutoUpdate Funktion der entsprechenden Software

KillOpenApplications.inf

• Ist eine Office Anwendung geöffnet?
• Ist Notepad++ geöffnet?

Aufgaben

Im Endeffekt muss man schauen, welche Anpassungen man heute vielleicht schon in seinen Paketen hat und muss diese Anpassungen für die mittel Patch-Management zu aktualisierenden Produkte wieder übernehmen.

Kleine Appetithappen

Im Anhang befinden sich beispielhafte Dateien. Viel Spaß damit!

PM_Post_KillOpenApplications (513 Downloads )
MD5 Hash der Downloaddatei: 42EA2A18E13EC498F5050359F01B3A92

Der Beitrag Anpassungsmöglichkeiten – Matrix42 Patch-Management Pakete erschien zuerst auf Workplace Management Blog.

Was ist drin?

Im Empirum WinPE Extension Pack 1.0 sind enthalten:

• WinPE-D-2PXE 1.6
• PrepareDRVbyModel_Packages 1.7
• InstallNetFX3 1.2
• PostOSInstallation 1.2

Was hat sich geändert?

Nachfolgend gehe ich auf die wesentlichen Änderungen in den Paketen ein. Wie ich sehe, hat sich am meisten im WinPE-D-2PXE getan. Dieses Paket hilft immer wieder beim Troubleshooting, da es u.a. schon immer die WADK Version und nun auch die Empirum WinPE Version ausgibt.

WinPE-D-2PXE
liefert Informationen über den Computer und Umgebung

• neben den PXE-Einträgen wird auch eine Log-Datei mit den gleichen Informationen erstellt
• eine Import-Datei für den Matrix42WinPEDriverAssistant wird erzeugt
• die Dateien werden bereits nach dem WinPE 1.8.0 Verfahren übertragen
• die genutzte Empirum WinPE Version wird ausgegeben
• die erkannten eingebauten Festplatten und Netzwerkkarten werden ausgegeben

PrepareDRVbyModel_Packages
ist eine Alternative zum DriverIntegration Paket der Matrix42

• Kosmetik und anpassen von Ausgaben
• kann nun auch für Hardware genutzt werden, die keine Hersteller oder Modell-Information per WMI liefert

InstallNetFx3
installiert/aktiviert das .NET Framework 3.5 aus den zugewiesenen Betriebssystemquellen

• … hatte ich noch nicht veröffentlicht

PostOSInstallation
führt eine Batch Datei nach der Betriebssysteminstallation aus, die als Ersatz für die EmpirumAgent/UEMAgent.bat dienen kann. Diese Batch-Datei spielt auch mit dem PrepareDRVbyModel_Packages Paket zusammen.

• kann nun auch mit der %EmpirumServer% Variable in der PostOSInstall.bat umgehen
  
• öffnet den Firewall Port für den Push von Software Pakete

Weitere Vereinfachung

Die nachfolgende ZIP-Datei enthält nun eine Empirum Struktur, wie ihr die von Matrix42 Hotfixen und der WinPE Erweiterung bereits kennt, und kann „einfach“ in/über die Empirum Struktur kopiert werden.
Zusätzlich habe ich im „Empirum\Configurator\Packages\Matrix42\OSPackages\Drivers“ Ordner eine beispielhafte Verzeichnisstruktur und Setup.inf abgelegt, um mit PrepareDRVbyModel_Packages und PostOSInstallation Treiber nach der Betriebssysteminstallation zu installieren. Das ging schon immer, hat jedoch auch immer wieder nachfragen aufgeworfen, da ich dies nicht genug erläutert und dokumentiert habe. Ich hoffe, es ist nun einfacher aufzugreifen und zu nutzen.

Falls nicht, so gebt mir per Kommentar oder Mail eine Rückmeldung.
Wie immer – viel Spaß und gutes Gelingen!

Empirum WinPE Extension Pack 1.3 (305 Downloads )
SHA256 der Downloaddatei: EE118815DBD4DC80D6CBBFB9855C44C6639D08F63C0B8AE6779104176FB462A2

Empirum WinPE Extension Pack 1.2 (437 Downloads )
MD5 Hash der Downloaddatei: E10E01545793D0C4326D041CC1931FDD920CEAA0

Empirum WinPE Extension Pack 1.1 (507 Downloads )
MD5 Hash der Downloaddatei: 15A1A232F6D0C9124DB85CB14456C5D1D96F6BCA

Der Beitrag Empirum WinPE Extension Pack 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.

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

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

Ursachenforschung (Empirum v15.x/16.x)

Auf dem Computer waren die VCRedist Versionen des Empirum Agenten installiert und im %WinDir%\System32\Empirum Verzeichnis gab es einen Install Ordner mit der Setup.inf des Empirum Agenten. Das bedeutete, dass die Installation des Empirum Agenten durch die EmpirumAgent.bat gestartet wurde, jedoch abgebrochen ist. Nach den VCRedist Varianten wird das .NET Framework 4.0 installiert. Die Installation des .NET Framework schreibt ein Log in den %TEMP% Ordner des administrativen Kontos, das sich bei der OS-Installation einmalig automatisch anmeldet. Diesem Log war zu entnehmen, dass das .NET Framework einen KB Hotfix installieren möchte, den die Installation nicht bei sich hat. Dieses Problem scheint jedoch nur in bestimmten Konstellationen (bereits installierte Treiber) aufzutreten.

Lösung

Das Problem kann man nun beheben, indem man den Hotfix vorab in die Windows 7 Installation einbringt oder eben vor dem Emprium Agenten Aufruf in der EmpirumAgent.bat bereits installiert. Den fehlenden Hotfix KB958488 gibt es hier.

Slipstream in die OS Quellen

Die Integration des Hotfixes in die Betriebssystemquellen wurde hier von Marco bereits detailliert erklärt.

Installation vor dem Empirum Agenten

Man kann jedoch auch den Hotfix in einem Ordner unterhalb von Configurator$ ablegen und vor dem EmpirumAgenten Installation bereits installieren. Entweder ruft man die nachfolgende Zeile in der EmpirumAgent.bat vor der Agenten Installation auf, oder fügt dies in einer PostOSInstallationxxx.bat hinzu, die ich in meiner Treiberintegration bereits erwähnt habe. Wenn man die PostOSInstallationxxx.bat am Ende der Betriebssysteminstallation aufruft, kann man bei einem Empirum Versionswechsel/Update einfacher die EmpirumAgent.bat aktualisieren und braucht nicht die Änderungen die man gemacht hat zu überführen.

Hier ein Beispiel für die Installation des x64 Hotfixes.
CALL wusa.exe „\\%EmpirumServer%\Configurator$\<Ablage-Ort>\Windows6.1-KB958488-v6001-x64.msu“ /quiet /norestart

Weiterer Tipp

Generell sollte man auch, für eine zuverlässige Ausführung der EmpirumAgent.bat, den PostDelaySeconds Wert auf 120-180 setzen .
Die Erstellung der Variable und das Setzen des Wertes habe ich in diesem Artikel bereits erläutert.

Der Beitrag Empirum Agent wird nicht installiert nach der OS-Installation erschien zuerst auf Workplace Management Blog.

Das im Anhang zusammengestellte Verfahren aus Skripten erweitert den OS-Installer bzw. die Installation von Computern.

Meines Erachtens bietet dies dann:

• Einfachere Integration von einer Vielzahl von Treibern.
• Einfachere Aktualisierung der Treiber in der Test und Integrations-Phase
• Schnellere Einbindung neuer Hardwaretypen
• Einfachere Übernahme in einer andere Empirum Installation (Test, QA, Produktion)
• Einfache Installation von hardwarespezifischen Treibern und Software per EXE und MSI.

Vorbereitungen

Verzeichnisse und Skripte

Was ist vorzubereiten, was wurde angepasst und was ist in der Download Datei?

• End_winvista.eis Script
• Vorlage (Template) für ein Hardwareprofil mit div.Logik
• Batch-Datei zur Installation von hardwarespezifischer Software je Hardwareprofil nach der OS-Installation

Angepasstes End_winvista.eis Script

Die angepasste „end_winvista.eis“ prüft, ob im Hardwareprofil-Ordner ein PnP Ordner vorhanden ist. Wenn dieser existiert, wird der Pfad zum PnP Ordner zu den Plug & Play-Pfaden für die OS-Installation hinzugefügt. Das bedeutet, dass dieser Ordner während der Windows Installation nach passenden Treibern durchsucht wird. Es ist zu prüfen, ob bereits Änderungen an der End_winvista.eis (Empirum\Empinst\Wizard\Scripts2\Custom) durchgeführt wurden. Wenn dies der Fall ist sind die Änderungen zusammenzuführen (die beigefügten Zeilen werden dann angehängt).

Hinweis: Zwei Aufrufe in der End_winvista.eis sind Empirum Versions abhängig. Nur die Zeilen der eingesetzten Empirum Version aktivieren!

Batch Datei für den Aufruf nach der OS-Installation

• Installation des .NET Framework 3.5 SP1 oder 4.0 und ggf. weiterer Hotfixe (optional)
• Aufruf einer Setup.inf, falls vorhanden, zur Installation weiterer Treiber und Software (siehe Hardwareprofil)
• Installation des Internet Explorers (optional)
• Schreiben von Hardware und OS-Installations Informationen in die Registry für die spätere Verwendung (optional – nicht enthalten)
• Aufruf der von Matrix42 gelieferten EmpirumAgent.bat

Kopieren der Empirum\Configurator\User\PostOSInstallation_W<OS><Architektur>.bat in den Empirum\Configurator\User Ordner. Einige Treiber und zusätzliche Software setzen das .NET Framework voraus, weshalb es hier direkt installiert wird. Hier wird entweder das .NET Framework über ein vorhandenes Paket installiert, oder separat. Wenn ein Paket vorliegt, wird der Aufruf zur Installation des .NET Framework 4.0 adaptiert, ansonsten verfährt man wie bei .NET Framework 3.5 aufgezeigt. Die Quellen dazu müssen in diesem Fall noch integriert werden, wie in der „Missing Files.txt“ Datei angegeben.

Die Installation des Internet Explorers und des .NET Framework Paketes sind nicht zwingend erforderlich. Gerade das Paket für den Internet Explorer muss selbst beigesteuert werden.

EmpirumAgent.bat

Beim Aufruf zur Installation des Empirum-Agenten in der EmpirumAgent.bat wird an die Zeile ein /X8 zur Unterdrückung des Neustarts angefügt. Dies sorgt für einen zuverlässigeren Ablauf der Skripte.

Call \\%EmpirumServer%\Configurator$\User\Setup.exe \\%EmpirumServer%\Configurator$\Packages\matrix42\EmpirumAgent\%EmpirumVersion%\Install\Setup.inf /S1 /X8

Betriebssystemvorlage

In der bzw. den genutzten Betriebssystemvorlagen wird der „Abschließende Befehl“ angepasst. Hier wird nun, je nach Betriebssystem die oben erstelle PostOSInstallation_W<OS><Architektur>.bat aufgerufen. Wenn Sie keine unterschiedlichen Installationen hinsichtlich des Betriebssystems an dieser Stelle durchführen, können Sie auch nur eine PostOSInstallation_W7.bat o.ä. erstellen.

Vorgehensweise und Ablauf

Was ist nun bei einer Einbindung eines neuen Hardwaretyps zu tun?

• Einbinden der Netzwerkkarte, wie gehabt (optional)
• Einbinden der Grafikkarte, wie gehabt (optional)
• Erstellen eines Hardwareprofils mit der Angabe eines Ordner (letztes Feld) (Wichtig! – Namen merken!)
• Kopieren der Vorlage in den erstellten Hardwareprofilordner
• Ablegen der weiteren PnP Treiber in den Hardwareprofilordner\PnP
• Einbinden von Treiber bzw. Softwareinstallationen per EXE/MSI (Ablage in HWspecificSW und anpassen der HWspecificSW\Setup.inf)

Erstellen eines Hardwareprofils

Der erste Schritt ist die Erstellung eines Hardwareprofils in der Management Console, unter Konfiguration, OS-Installer, Hardware, Hardwareprofil. Matrix42 Hilfe bis Punkt 14 durchführen.

Wo befindet sich das Hardwareprofilverzeichnis?

Anschließend wird der Ordner des erstellten Hardwareprofils mit den weiteren Treibern und ggf. Aufrufen versehen. Das Verzeichnis für das Hardwareprofil befindet sich je nach Architektur des Betriebssystems in den hier angegebenen Pfaden.

• X86 = Empirum\Empinst\DRV\Win7\HWMisc
• X64 = Empirum\Empinst\DRV\Win7\x64\HWMisc

Hardwareprofil

Es liegt eine Vorlage für ein Hardwareprofilordner in Empirum\Empinst\DRV\Win7\<Architektur>\HWMisc\_Template vor, damit alle Skripte zusammen funktionieren. Bitte jeweils für x86/x64 die Datei „Missing Files.txt“ in „HWspecificSW\VCRe100“ beachten, da hier ggf. noch die notwendigen Dateien abgelegt werden müssen. Nachfolgend ist die Wirkungsweise und Nutzung der Verzeichnisse und Skripte im Hardwareprofil erläutert. Es kann auch ohne die VCRedist100 Dateien getestet werden.

PNP Verzeichnis

Wie zuvor beschrieben, dient das PNP Verzeichnis zur Ablage mehrerer Verzeichnisse mit Treibern die während der OS-Installation durchsucht werden.  Das heißt, hier können weitere Verzeichnisse erstellt werden, die dann wiederum die notwendigen Plug & Play (kurz PnP) Treiber beinhalten. Dieses Verzeichnis kann auch mit einer Zusammenstellung von DoubleDriver befüllt werden, dass zuvor mit Hilfe eines Backups von einem vorhandenen System erstellt wurde. Eine andere Methode ist es die DriverPacks, DriverKits, SCCM Driver Packages, o.ä. die Hersteller wie Dell, Fujitsu, HP, uvm. bereitstellen, entpackt in den PnP Ordner abzulegen.

Install\Setup.inf

Die Setup.inf im Install Ordner sorgt für das Kopieren des HWspecifcSW Ordners nach %WinDir%\HWspecifiSW, damit er nach der OS-Installation zur Verfügung steht. In meinem Falle wird die Setup.inf des HWspecifSW Ordners durch die PostOSInstallation_W<OS><Architektur>.bat aus Empirum\Configurator\User aufgerufen. Zusätzlich kann hier bereits eine VCRedist Installation stattfinden, da dies von immer mehr Grafikkartentreibern vorausgesetzt wird.

Aufgrund dessen, dass im Hardwareprofilordner ein Install Ordner mit einer Setup.inf liegt, bedarf es der Anpassung der End_Winvista.eis (siehe oben). Matrix42 erstellt für jeden Treiberordner in dem sich eine Install\Setup.inf befindet einen Installationsbefehl (Früher: EmpirumJob=Yes) und nimmt diesen Ordner nicht in die PnP Pfade mit auf.

HWspecificSW Verzeichnis

In diesem Verzeichnis werden Treiber und Software für diesen Hardwaretyp abgelegt, die mittels einer EXE oder MSI installiert werden. Die Durchführung der Installation(en) findet nach der OS-Installation und vor der EmpirumAgent Installation im Kontext des lokalen Administrators statt. Beispielhafte Aufrufe dazu befinden sich in der HWspecificSW\Setup.inf Datei. Es bietet sich an, für die Treiber ggf. nochmals Unterverzeichnisse zu erstellen. Wird kein Treiber oder sonstige hardwarespezifische Installation nach der OS-Installation mehr benötigt, kann dieser Ordner auch weggelassen werden. Wenn die PostOSInstallation_W<OS><Architektur>.bat keine Setup.inf im %WinDir%\HWspecificSW findet, wird auch keine Installation durchgeführt.

Weitere Optimierung

PostDelaySeconds

Falls die PostDelaySeconds Variable noch nicht als Betriebssystemvariable in der Empirum Management Console vorhanden ist, so sollte diese noch erstellt und auf den Standardwert 180 gesetzt werden.

Empirum Management Console starten, im Menü unter  „Extras, Variablendefinition“

• Variable: PostDelaySeconds
• Variablentyp: Betriebssystem
• Kontrollelement: Zahl
• Null-Wert erlauben: Ja
• Standardwert: 180

Falls der Wert trotz Standardwert nicht in die Variablendateien der Computer eingetragen wird, so hilft ein Setzen der Variable auf die oberste Konfigurationsgruppe und Aktivierung der „Zwangsvererbung“.

Fertig

Das sollten alle Schritte sein, damit die „Rädchen“ ineinander greifen. Diese Methode kann auch für Windows 8, 8.1 übernommen werden.

Viel Spaß und einfache Umsetzung wünsche ich Euch!

Benötigte Dateien für den oben genannten Ablauf:  TreiberFramework (2982 Downloads )

Der Beitrag Empirum Treiberintegration – einfacher gemacht! erschien zuerst auf Workplace Management Blog.

Die Informationen, welche Betriebssystemkonfiguration und welches Quellverzeichnis genutzt wird, steht jedoch zur Installationszeit zur Verfügung. Mit der Anpassung der „end_winvista.eis“ aus dem Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\Scripts2\Custom stehen diese Informationen nach der Installation dauerhaft zur Verfügung. Die nachfolgenden Zeilen müssen zur „end_winvista.eis“ Datei hinzugefügt werden. Wer weitere Informationen für sich interessant findet, kann den Tipp auch auf weitere Werte der OS.INI ausweiten.

;ServicePack definies the folder containing the os source files
TEXTOUT %HDM%Postjob/POSTSYS.CMD %%windir%%\System32\reg.exe ADD "HKLM\SOFTWARE\MATRIX42\Empirum Installer" /v ServicePackLevel /t REG_SZ /d "%ServicePack%" /f >>%%PostsysLog%%

;Write the used OS-Template to the registry
IF "%TemplateName%"<>"" THEN  
 TEXTOUT %HDM%Postjob/POSTSYS.CMD %%windir%%\System32\reg.exe ADD "HKLM\SOFTWARE\MATRIX42\Empirum Installer" /v OS_Template /t REG_SZ /d "%TemplateName%" /f >>%%PostsysLog%%
ENDIF

Der Beitrag Empirum OS-Installationsinformationen in der Registry speichern erschien zuerst auf Workplace Management Blog.