Prüfmöglichkeiten

Die neuen Vorbedingungen sind „universal“ einsetzbar und können folgende Eigenschaften prüfen:

• Registrierung
• WMI
• Datei
• Ordner

Ideen

Nachfolgend möchte ich nicht auf alle Möglichkeiten eingehen, euch jedoch ein paar Anregungen geben, die ich schon genutzt habe.

• Ist das .NET Framework in einer bestimmten Version oder neuer installiert?
• Hat das Windows einen bestimmten Versionsstand?
• Handelt es sich um einen bestimmten Hardwaretyp?
• Ist eine VPN Verbindung aktiv?

Ihr könnt auch mehrer Bedingungen „UND“ oder „ODER“ verknüpfen, wie ich das schon für Treiber gemacht habe. Vielleicht habt ihr auch coole Ideen oder Einsatzmöglichkeiten für Euch erkannt und wollt diese hier teilen. Ich bin gespannt und freue mich auf Feedback!

Beispiel

Zumeist habe ich bis dato auf Registry Werte geprüft, wie beim nachfolgenden detaillierteren Beispiel: „Ist das .NET Framework in einer bestimmten Version oder neuer installiert?“

Hier nochmals die Werte für eine einfachere Eingabe:

Registry Wert vergleichen
Registry Pfad: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\V4\Full
Wert Name: Release
Vergleichstyp: Nummer
Operator: Größer als oder gleich
Wert: 461808

Übertragen von Vorbedingungen

Die Vorbedingungen, wie z.B. eine .NET Framework Voraussetzung beim UEM Agent Paket, müssen bei einer neuen Versionen eines Paketes nicht auch erneut eingeben werden. Zur einfachen Übernahme der vorhandenen Vorbedingungen könnt ihr die Funktion: „Vorbedingungen kopieren“ und „Vorbedingungen einfügen“ nutzen.

Matrix42 Hilfe

Da ich hier jetzt nicht alle Möglichkeiten eingehen werde und eingegangen bin, möchte ich Euch den Eintrag in der Matrix42 Hilfe natürlich nicht vorenthalten.

Der Beitrag Erweiterte Paketvoraussetzungen erschien zuerst auf Workplace Management Blog.

Das PreOS Paket …

• matrix42\DriverIntegration oder
• wpm-blog\PrepareDRVbyModel_Packages

übernimmt die „Vorbereitung“ in Bezug auf die Windows Treiber. Dieses habt ihr hier bereits eingebunden und zugeordnet.

Was passiert da?

Beide Pakete bestimmen anhand einer WMI Abfrage, wie die Hersteller und die Modellbezeichnung des Gerätes sind. Anhand dieser Daten wird in eine Zuordnungsdatei geschaut, welche ZIP oder CAB Datei bzw. Ordner kopiert werden soll. Der Kopiervorgang bzw. das Entpacken findet in den lokalen Ordner C:\EmpirumAgent\Drivers statt. Die unattend.xml des WindowsInstallation Paketes, das im Anschluss läuft, sucht dann bei Bedarf in dem oben genannten Ordner nach passenden Treibern.

Wo liegt die Zuordnungsdatei?

Die Zuordnungsdatei liegt auf dem EmpirumServer unter \\%EmpirumServer%\Configurator$\Packages\Matrix42\OSPackages\Drivers\ und heißt drivers.json (ehemals drivers.ini).

Wie wird die Zuordnungsdatei „gepflegt“

Die drivers.json Datei muss man nicht mit einem Editor anpassen. Dazu bietet Matrix42 eine Oberfläche an, die hier zur Verfügung steht: \\%EmpirumServer%\Empirum$\AddOns\WinPEDriverAssistant\Matrix42WinPEDriverAssistant.exe
Zur Sicherheit sollte man die Matrix42WinPEDriverAssistant.exe mit der Option „Als Administrator ausführen“ starten.

Woher bekomme ich den Hersteller und das Modell?

Den Hersteller bzw. das Modell bekommt man mittels des Paketes

• matrix42\HardwareInfo oder
• wpm-blog\WinPE-D-2PXE

heraus. Bei Systemen, die man bereits im Einsatz hat, kann man die Werte auch dem Inventory (WMI, Computersystem) entnehmen.

Woher bekomme ich die Treiber?

Für die „Business“ Modelle der „großen“ Hersteller gibt es sogenannte „SCCM Driver Packages“. Die Einstiegsseiten dazu hatte ich in diesem Artikel bereits aufgeführt.

Nur Plug&Play Treiber reichen mir nicht aus!

Wer noch mehr machen möchte, nutzt mein PrepareDRVbyModel_Packages Paket.

Ausführliche Anleitung

Weiteren Lesestoff findet ihr im Dokument Treiberintegration in WinPE HowTo der Matrix42.

Das für’s Erste als kurze und knappe Übersicht. Bei Gelegenheit, werde ich mit eigenen Worten und Bildern diesen Artikel nochmals weiter „ausschmücken“.

Der Beitrag Empirum WinPE – Treiber für Windows 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 (324 Downloads )
SHA256 der Downloaddatei: EE118815DBD4DC80D6CBBFB9855C44C6639D08F63C0B8AE6779104176FB462A2

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

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

Der Beitrag Empirum WinPE Extension Pack 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 (518 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

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

Los geht’s

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

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

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

Schritt 3:
Zuweisen eines Computers

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

Rückmeldungen sind willkommen!

Fehlersuche:

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

Beispielhafte Screenshots:

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

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

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

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

Das 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 (3041 Downloads )

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

MS14-049

Microsoft hat im Oktober 2014 einen Patch unter der Bulletin ID MS14-049 veröffentlicht. Dieser Patch schließt eine Lücke im Windows Installer Dienst: „Vulnerability in Windows Installer Service Could Allow Elevation of Privilege“. Damit einhergehend werden für MSI Installationen neue Hash Werte ermittelt bzw. erstellt. Dies führt bei einer Reinstallation einer bereits installierten MSI Installation zu Problemen.

Mögliche Abhilfen

Whitelisting der Installation

Microsoft hat direkt Methoden zur Erstellung von Whitelist Einträgen, pro getätigter MSI Installation die repariert werden soll, angeboten. Bei dem Einsatz einer Softwareverteilung und einer Fülle an getätigter Software Installationen bereitet das keinen Spaß.
Die Informationen dazu wurden hier veröffentlicht.

Patch zur Behebung des UAC Problems

Im November wiederum wurde dann ein Hotfix veröffentlicht, der mit Hilfe eines Registry Keys generell die UAC Meldungen bei einem nicht vorhandenen MSI Hash Wert unterbinden soll.
Dieser Hotfix samt Vorgehensweise ist hier veröffentlicht.

Die Vorgehensweise mit dem nachgelagerten Hotfix scheint eine sinnvolle Behebung bzw. Umgehung der Problematik zu sein. Doch auch diese Umgehung scheint nach Rückmeldungen nicht zu 100% zu funktionieren.

Deinstallation des MS14-049

Letztendlich bleibt einem bei allen oben getroffenen Maßnahmen und keinem Erfolg (UAC Meldung erscheint trotz aller Maßnahmen) nur noch die Deinstallation des Patches.
Dies wiederum kann auch per Empirum geschehen. Dazu habe ich unten eine beispielhafte Deinstallationsroutine angehängt.

Ich drücke Euch die Daumen!

[Product]
#CheckWUSA, DONTDELETE
#Set:Product, DONTDELETE

[CheckWUSA]
Set VM_WUSA=%HKLM,"SYSTEM\CurrentControlSet\Services\wuauserv","Start"%
If "%VM_WUSA%" == "4" Then "EnableWUSA" EndIf

[EnableWUSA]
CallHidden sc config "wuauserv" start= demand error= ignore

[Set:Product]
SET QFE=2918614
Addmeter -1
DEL "%TEMP%\qfe.txt"
Callhidden %comspec% /C ECHO %sysdate% %systime% - Searching for installed hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C wmic.exe qfe >"%TEMP%\qfe.txt"
If DoesTextInFileExist ("%QFE%", "%TEMP%\qfe.txt") == "1" Then "UninstallQFE" ELSE "QFEnotExist" EndIf

[UninstallQFE]
Callhidden %comspec% /C ECHO %sysdate% %systime% - Installed hotfix found: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C ECHO %sysdate% %systime% - Uninstall hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
CallHidden sc config "wuauserv" start= demand error= ignore
Callhidden wusa /uninstall /kb:%QFE% /quiet /norestart
Set WusaError=%ErrorLevel%
IF %wusaError% == "3010" Then "RebootRequired" EndIf
Callhidden %comspec% /C ECHO %sysdate% %systime% - ErrorLevel: %WusaError% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C wmic.exe qfe >"%TEMP%\qfe.txt"
If DoesTextInFileExist ("%QFE%", "%TEMP%\qfe.txt") == "1" Then "SET:InstallationError" EndIf
Callhidden %comspec% /C ECHO %sysdate% %systime% - Successfully uninstalled hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
DEL "%TEMP%\qfe.txt"

[QFEnotExist]
Callhidden %comspec% /C ECHO %sysdate% %systime% - The following hotfix is not installed: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"

[RebootRequired]
SetReboot 1

[SET:InstallationError]
Callhidden %comspec% /C ECHO %sysdate% %systime% - Failed uninstall hotfix: %qfe% >>"%WINDIR%\TEM\qfe_uninstall.log"
ErrorLogMsg %ErrorText% %WusaError% %CallingText% wusa /uninstall /kb:%QFE% /quiet
Abort

Setup.inf Beispiel zur Hotfix Deinstallation als Datei: MSHotfix_Uninstall (955 Downloads )

Der Beitrag UAC Meldungen bei der Reinstallation von MSI Paketen erschien zuerst auf Workplace Management Blog.

wmic useraccount where name = '<AlterName>' call rename name = '<NeuerName'>

In einem Empirum Paket kann man es zum Beispiel wie folgt einbauen …

[Product]
...
#RenameAdmin
...

[RenameAdmin]
CALLHIDDEN wmic useraccount where name = 'Administrator' call rename name = 'LAdmin'

Der Beitrag Umbenennen eines Benutzerkontos erschien zuerst auf Workplace Management Blog.