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

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

Aktualisierung der Quellen

Möchte man die Quellen für das Paket mit einer unveränderten Version aktualisieren, reicht ein verändern des Zeitstempels der Setup.inf aus. Dazu kann man die Setup.inf öffnen und wieder speichern (sogenannt „touchen“), oder gar einen Vermerk in den Header [SetupInfo] schreiben, warum man eine Änderung durchgeführt hat.

Löschen von Paketen aus dem Cache

Möchte man jedoch auf die automatische Cacheverwaltung Einfluss nehmen und ein Paket vorzeitig, oder mit Absicht, komplett aus dem Cache löschen, so hilft das angefügte Tool, um dies von der Kommandozeile aus zu machen. Dies kann unter anderem dann notwendig sein, wenn man den Ablauf des Caches auf „0“, also niemals, stehen hat.

CleanUpEmpirumAgentCache.exe löscht die Registry Einträge und die Quellen aus dem lokalen Empirum Advanced Agent Cache-Verzeichnis für ein angegebenes Paket.

Die folgenden Parameter sind vorhanden:

/ITEM:“<Paketname>“ – ITEM muss angegeben werden, und der Paketname sollte zur Sicherheit in Hochkommas eingeschlossen werden. Der Paketname entspricht dem Namen aus dem Softwaredepot. {Developername}\{ProductName}\{Version}.

/S – Silent. Ist dieser Parameter nicht gesetzt, so werden die Rückmeldungen per Messageboxen angezeigt, was gefunden wurde und welche Änderungen durchgeführt werden bzw. wurden.

/L – LogFile. Erstelle eine Log-Datei in %TEMP% mit dem Namen CleanUpEmpirumAgentCache.log und enthält Debug und Log Informationen bei der Ausführung.

/T – Test only. Mittels dieses Schalters werden die Funde und möglichen Löschvorgänge angezeigt bzw. protokolliert, jedoch nicht durchgeführt.

Beispielhafte Aufrufe: CleanUpEmpirumAgentCache.exe /ITEM:“Microsoft\Office\12.0″ /S /L
– löscht das Microsoft Office 12.0 Paket ohne Anzeige aus dem Empirum Agent Cache und schreibt dazu Informationen in die Log-Datei.

CleanUpEmpirumAgentCache.exe /ITEM:“Matrix42″ /S /L
– löscht ALLE Pakete, die Matrix42 im Namen beinhalten ohne Anzeige aus dem Empirum Agent Cache und schreibt dazu Informationen in die Log-Datei.

CleanUpEmpirumAgentCache.exe /ITEM:“Matrix42″ /T
– zeigt ALLE Pakete an, die Matrix42 im Namen beinhalten und ohne den Parameter /T gelöscht werden.

Hier gibt es das CleanUpEmpirumAgentCache Tool:
CleanUpEmpirumAgentCache (1907 Downloads )

Der Beitrag Empirum Advanced Agent Cache – Aktualisieren und Löschen erschien zuerst auf Workplace Management Blog.

Voraussetzungen

• Es wird ein Benutzer mit administrativen Berechtigungen auf dem Zielsystem benötigt.
• Die Namensauflösung muss funktionieren!
• Die Admin$ Freigaben müssen vorhanden sein.
• Die Firewall muss SMB Verbindungen zulassen.
• Für Windows 7 muss die UAC mindestens dem Standard oder „lockerer“ entsprechen.
• Der Dienst „Remote-Registrierung“ muss aktiviert sein.
• Für Windows XP müssen die Terminal-Dienste aktiv sein, da der Empirum Advanced Agent Dienst davon abhängig ist.

Wer auf Nummer sicher bezüglich Neustarts bei der Agenten Verteilung gehen will, der setzt im matrix42\EmpirumAgent Paket den Reboot auf 2 (Reboot=2) und kommentiert die SetReboot 1 Befehle aus.

Zu guter letzt können einem nun noch übervorsichtige Virenscanner Probleme bei der Verteilung machen.

Kaspersky – Konfiguration von Vertrauenswürdigen Anwendungen bzw. Programmausnahmen auf:

1. %windir%\temp\EmpirumAgent_tmp\Install\Setup.exe
2. %windir%\temp\Setup64.exe

• Zu öffnende Dateien nicht untersuchen
• Programmaktivität nicht kontrollieren
• Netzwerkverkehr nicht untersuchen

und je nach Version

• Zugriff auf Registrierung nicht untersuchen
• Aktivität der Unterprogramme nicht untersuchen.

TrendMicro
Im Matrix42 Forum wurde das Thema auch bereits diskutiert. Dies zeigt auf, dass es kein Problem eines einzelnen Client-Management Herstellers ist. Hier geht es zur Forums Diskussion.

„Probleme“ mit dem Virenscanner kann man dem DebugView Log auf dem EmpirumServer entnehmen. Der Empirum Agent Push Dienst endet dann jeweils mit dem Setup.exe Aufruf auf dem entfernten System. Beim weiteren Versuch wird dann gemeldet, dass die Setup.exe bereits im Zugriff durch ein anderes Programm ist.
Wie sind Eure Erfahrungen?
Habt Ihr funktionierende Einstellungen mit anderen Virenscannern?

Ansonsten, Viel Erfolg!

Der Beitrag Empirum Agent Verteilung per Push erschien zuerst auf Workplace Management Blog.

Dieser Problematik lässt sich zumeist in 3 Ursachen unterscheiden und somit mit unterschiedlichen Lösungen beheben. Lesen Sie dazu den Artikel bis zum Ende, damit sie sehr zielgerichtet ihr Problem einkreisen können.

Mögliche Ursachen für das Problem

1. Die Netzwerkkarte wurde nicht installiert
2. Der Benutzer für den Domain-Join
3. Namensauflösung

Die Netzwerkkarte wurde nicht installiert.

Diese Problematik kann am einfachsten festgestellt werden, in dem man einen Blick auf den Geräte-Manager des betroffenen Gerätes wirft. Häufig bleibt dann auch die Betriebssystem Installation am Ende „hängen“, wenn die Agent.bat bzw. EmpirumAgent.bat aufgerufen werden soll. Fehler 2 bzw. 5 – Die zuvor beschriebene BAT Datei kann nicht gefunden werden oder der Zugriff darauf ist nicht möglich.

Der Benutzer für den Domain-Join

Rund um den Benutzer für den Domain-Join kann es mehrere Probleme geben. Zuerst muss in der Betriebssystemvorlage nachgesehen werden, welcher Benutzer diese Aufgabe wahrnimmt. Häufig wird auch der „Diskettenbenutzer“ mit der entsprechenden Aufgabe versehen. Dann muss man in dem Active Directory oder anderem Verzeichnisdienst nachsehen, ob der Benutzer die erforderlichen Berechtigungen besitzt. Dem Benutzer können auf unterschiedliche Art und Weise die Berechtigungen gegeben werden. Manche machen es sich einfach und der Benutzer ist „Domänen-Administrator“. Das ist für meinen Geschmack etwas zu viel des Guten, aber das muss jeder Verantwortliche für sich entscheiden. Eine weitere Möglichkeit besteht darin den Benutzer zu den „Konten Operatoren“ hinzuzufügen, oder gar nur die Sicherheitseinstellung „Hinzufügen von Arbeitsstationen zur Domäne“ für den betroffenen Benutzer zu setzen. Das Wirken dieser Berechtigungen muss in dem Verzeichnisdienst an der richtigen Stelle überprüft werden.

Namensauflösung

Häufig verhindert auch die Namensauflösung den Domain-Join. Empirum versucht den Domain-Join durch Nutzung des „NetBIOS“ Domain Namens in den Computer Eigenschaften. Schlägt dies fehl, so kann man den Domain-Join während der Betriebssystem-Installation auch durch Angabe des FQDNs durchführen. Dazu kann man die Variable „FQDN“ eines Computers setzen. Dies geht über das Setzen von Variablen auf einem Computerobjekt in der Empirum Management Console (rechte Maustaste auf ein Computerobjekt, Variablen, FQDN, …) oder ab der Empirum Version 14.2 auch über die Eigenschaften eines Computers. Funktioniert der Domain-Join über diesen Weg, so muss man die Variable nicht für jeden Computer einzeln setzen, sondern kann die Variable auf eine entsprechende Konfigurationsgruppe setzen und mittels „Zwangsvererbung“ jedem Computer zuweisen.
Hinweis: Setzen sie nicht den FQDN Namen in dem Eingabefeld „Domäne“ bzw. „Domain“ der Computereigenschaften! Dies hat auch Auswirkungen auf die Softwareverteilung, die dann nach der Betriebssystem-Installation nicht mehr funktionieren wird!

Wie finde ich den Grund für „mein“ Problem?

Wenn Sie gezielt ihr Problem lösen möchten, so schauen sie auf dem betreffenden Computer in die Datei „%WINDIR%\Debug\NetSetup.log“. Hier lässt sich das Problem für den nicht funktionierenden Domain-Join ergründen. Falls Sie Probleme beim Lesen und Interpretieren der Datei haben, so können sie gerne Kontakt mit mir aufnehmen.

Achtung beim nächsten Versuch …

War es nicht die Netzwerkkarte, so wird der Computer am Ende der Betriebssystem-Installation inventarisiert und überschreibt ihnen die angegebene Domäne mit der „Arbeitsgruppe“. Dies führt häufig zu Folgefehlern. Also aufgepasst beim weiteren Versuch nach einer durchgeführten Änderung.

Der Beitrag Domain-Join während der Betriebssystem-Installation funktioniert nicht erschien zuerst auf Workplace Management Blog.