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.

Download der neuen WinPE Erweiterung vom Matrix42 Marketplace

Den aktuellen WinPE PreBoot Support findest Du im Matrix42 Marketplace. Lade die aktuelle Version und das dazugehörige WinPE How-To herunter. Der PreBoot Support steht als selbstextrahierendes Archiv zur Verfügung, kann aber auch gezielt mittels z.B. 7-zip entpackt werden.

Sicherung der genutzten WinPE Umgebung

Empirum Updates erstellen automatisch eine Sicherung des WinPE Ordners unter:
\\%EmpirumServer%\EmpInst$\Sys\Images\WinPE_Backup
Da die im Marketplace bereitgestellten WinPE Aktualisierungen lediglich kopiert werden, muss man sich selbst um die Sicherung kümmern.
Dazu kopierst Du am besten den Ordner
\\%EmpirumServer%\EmpInst$\Sys\Images\WinPE
nach
\\%EmpirumServer%\EmpInst$\Sys\Images\WinPE_Backup
Zur Sicherheit gibst Du der Sicherung noch die WinPE Version oder ein Datum mit.
Die WinPE Cersion kannst Du aus den Dateiinformationen der
\\%EmpirumServer%\EmpInst$\Sys\Images\WinPE\binaries\UAF\Matrix42.Empirum.PeAgent.dll
entnehmen.

Entpacken des WinPE PreBoot Supportes

Der entpackte WinPE PreBoot Support steht als Empirum Verzeichnis Struktur zur Verfügung.

Kopieren der Aktualisierung

Kopiere nun die entpackte Empirum Struktur über die vorhandene aktive Empirum Installation.

Anpassungen / Customizings

Falls Anpassungen hinsichtlich Logos, Hintergrundbilder, Standard-Timeouts, etc. getätigt wurden, so sind diese Anpassungen wieder im
\\%EmpirumServer%\EmpInst$\Sys\Images\WinPE
Ordner vorzunehmen. Dazu kannst Du auch in Deiner zuvor getätigten Sicherung nachsehen bzw. dich bedienen.

Importieren der aktualisierten PreOS Pakete

Anschließend sind die aktualisierten PreOS Pakete in der Management Console unter Konfiguration\Software Management\Depot zu importieren.
Wenn Du Dich hier noch nicht so sicher fühlst, so kannst Du dies ist im Kapitel 2.1.1 des oben genannten WinPE How-Tos nachvollziehen. Mit dem PreBoot Support Version 1.8.1 werden die Pakete möglichst bereits in die richtige Reihenfolge gebracht und direkt zur Installation freigegeben. Falls Du Dir bzgl. der Reihenfolge der Pakete nicht sicher bist, so kannst Du Dir diesen Artikel nochmals ansehen.

Bootkonfiguration neu erstellen

Lese diesen Abschnitt zuerst zu Ende bevor Du aktiv wirst.
Der einfachste Weg ist die vorhandene Boot-Konfiguration zu öffnen und unten rechts auf Speichern zu drücken. Dann wird die vorhandenen Boot-Konfiguration mit den neuen Quellen der WinPE Umgebung aktualisiert. Mit einem kleinen „Umweg“ erstellst Du eine zweite/neue Boot-Konfiguration und übernimmst die Einstellungen der derzeitig genutzten Boot-Konfiguration (Einstellungen: Agent-Template, TFTP-Blockgröße, Self-Provisioning und zusätzliche Treiberverzeichnisse, etc.). Diese Konfiguration kannst Du auch immer wieder für die neuen Versionen nutzen. Wenn also die kommenden Schritte und Tests funktionieren, erstellst Du die produktiv genutzte Konfiguration neu.

Testen!

Nachdem die Boot-Konfiguration fertig erstellt ist, kannst Du die neuen Komponenten testen. Für den Test erstellt Du Dir eine gesonderte Zuweisungsgruppe und ordnest ihr die neue Boot-Konfiguration und neuen Pre-OS Pakete zu. Bitte beachte, dass die notwendigen Variablen auch hier gesetzt sein müssen. An dieser Stelle könnte es nützlich sei, sich mit den neuen „Variablen Konfigurationen“ auseinander zu setzen.

Produktive Nutzung oder Rollback?

Treten bei den Tests keine Ungereimtheiten auf, so kannst Du die Änderungen in Deine produktiv genutzten Konfigurations- oder Zuweisungsgruppen übernehmen. Dazu kannst Du entweder die alte Boot-Konfiguration mit der neuen ersetzen, oder aktualisierst die produktiv genutzte Boot-Konfiguration nun mit den neuen Quellen. Die neuen Pre-OS Pakete musst du jedoch trotzdem zuweisen, oder eben eine genutzte Software-Gruppe aktualisieren.

Sollte etwas nicht wie gewünscht funktionieren, brauchst Du es nicht zu überführen bzw. kannst mit der Übernahme noch warten.
Die Erstellung der Boot-Konfiguration greift immer auf das „WinPE“ Verzeichnis zu. Im „schlimmsten“ Falle, kannst Du das WinPE Verzeichnis aus dem WinPE_Backup Verzeichnis wiederherstellen, wenn Du z.B. neue Treiber in das „ältere“ funktionierende WinPE integrieren musst.

Der Beitrag Empirum WinPE PreBoot Update mit „doppeltem Boden“ 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.

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.

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.

• Wie verteile ich neue Versionen von bestehender Software?
• Wie rolle ich diese Versionen aus?
• Was ist zu beachten?

Wichtige Grundlagen zu diesem Thema sind bereits in diesem Beitrag erläutert: Empirum Paket – Registry, SoftwareDepot, Version.

In Kurzform ist folgendes für die neue Version wichtig:

• Der Herstellername (DeveloperName) und Softwarename (ProductName) der Versionen sind identisch.
• Es ist lediglich die Version unterschiedlich und in diesem Falle die neuere Version höher als die alte.
• Die MachinekeyName Einträge (und somit im SoftwareDepot: Registrierung, Schlüssel) sind identisch.

Sind diese Voraussetzungen erfüllt kann das neue Paket dem Computer, der die Vorgängerversion zugewiesen hat, zugewiesen werden. Dazu die neue Version dem Computer mit den Verteilungsoptionen „Installieren, Erneuern“ zuweisen. Die alte Version aus der Zuweisung löschen. Bei der kommenden Abfrage: „Löschen“ auswählen. Dies bedeutet, dass der Verteilbefehl gelöscht wird und somit nur noch der Verteilbefehl für die neuere Version aktiv ist.

Findet nun die Softwareverteilung auf dem Zielcomputer eine Altversion anhand der MachineKeyName Werte in der Registry vor, so wird eine Deinstallation mit der lokal vorgehaltenen Setup.inf durchgeführt (AskUninstallOld=1). Dazu ist es wichtig, dass die Deinstallationsbefehle oder Zugriffe alle lokal erfolgen können! Häufig sorgen Zugriffe, in den betroffenen Sektionen für die Deinstallation, auf %SRC% oder ähnlich für Fehler bei der Deinstallation der Altversion. Ist die Altversion erfolgreich deinstalliert, beginnt die Installation der neuen Version.

Gibt es beim Testen (Deinstallation der Altversion), wie zuvor beschrieben, Probleme – und diese Probleme tauchen zumeist erst auch dann auf, wenn man die Nachfolgeversion paketiert hat, hat man noch „Handlungsspielraum“. Entweder man setzt nun die Vorgängerversion auf „Deinstallieren…“ anstatt „Löschen“ oder man passt das „neue“ Paket an (AskUninstallOld=0 und die Deinstallation auf Bedarf durchführen).

In einem anderen Beitrag werde ich der zumeist nachfolgenden Frage: „Wann passe ich die Version und wann die Revision an?“ nachgehen.

Der Beitrag Softwarepakete: Updateverhalten, Verteilen von neuen Versionen erschien zuerst auf Workplace Management Blog.