Diese Meldung erscheint, wenn kein passender Eintrag oder kein eindeutiger Eintrag in der DeviceMapping.xml gefunden werden kann. Die DeviceMapping.xml wird während der OS Installation hergenommen, um von den Hardwareeigenschaften (MAC oder UUID) auf den späteren Computernamen und Workgroup/Domain zu verweisen.

Die ersten Troubleshooting Schritte …

(1) Die Voraussetzung für einen Eintrag in der DeviceMapping.xml ist: Die Eigenschaft des Computerobjektes muss „PXE fähig“ markiert haben – er muss jedoch nicht unbedingt PXE aktiviert sein!

(2) Wo liegt die DeviceMapping.xml? Die Datei ist im folgenden Verzeichnis abgelegt: \\%EmpirumServer%\Configurator$\Empirum\Configurator\Values
Folgendes sollte geprüft werden: Ist die Datei aktuell bzw. so aktuell wie die letzte Änderung? Geschieht die OS Installation an einem SubDepot, so gilt dies für das SubDepot! Hier muss ggf. der DepotSync betrachtet werden, wenn die Datei am HauptServer anders bzw. vollständig ist. Ergo zuerst die Datei auf dem HauptServer und anschließend auf dem SubDepot prüfen.

(3) Ist die MAC-Adresse / UUID in der DeviceMapping.xml zu finden und nur einmal (1x) vorhanden? Dazu die Datei mittels eines Editors öffnen und darin nach den Werten (Computername, MAC, UUID) des Computerobjektes suchen.

(4) Falls der Computer, die MAC-Adresse oder die UUID nicht in der DeviceMapping.xml zu finden ist: „Empirum-Backend Task Queue Host (64 bit)“ Dienst prüfen, da er für die Erstellung der Datei zuständig ist. Ist der Dienst gestartet und läuft – funktioniert der Dienst einwandfrei? Die Log-Datei zum BTQH64 Dienst befindet sich hier: „C:\ProgramData\Matrix42\Logs\BackendTaskQueueHost64\BackendTaskQueueHost64.log“

Wird die MAC-Adresse oder UUID mehrfach gefunden, dann diese Informationen (Computernamen) nutzen und in der EMC an den Computerobjekten nachschauen.

Löschen doppelter UUIDs aus der Empirum Datenbank

Doppelte UUIDs aus der Empirum Datenbank können wie folgt gelöscht werden:
Empirum bzw. Matrix42 Management Console starten, Konfiguration, Boot Konfiguration – im Menü unter: Extras, Ungültige UUID’s
Suchen und Löschen der doppelten Einträge per Auswahl und Papierkorb Symbol. Bitte beachte die Hinweise, wenn ein Eintrag nicht gelöscht werden kann. Der Hinweis zeigt an, welche Computernamen die gleiche UUID eingetragen haben. Anhand der letzten Inventarisierung o.ä. kann man erörtern, welches das aktuelle Computerobjekt ist.

Wenn die zuvor genannten Hilfestellungen alle nicht geholfen haben …

Weitere Infos am Client (vor der Windows Installation)

Wenn die Meldung erscheint gelangt man direkt in das Log per Tastenkombination „STRG+L„. In der Log-Datei sucht man am besten nach „ComputerIdentification.ResolveComputername„. Nachfolgend ein beispielhafter Auszug:

[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Retries at copying DeviceMapping XML file: 10
[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Copying DeviceMapping XML file (retry 0/10): Values\DeviceMapping.xml
[INFO] [ComputerIdentification.ResolveComputerName] SMBIOS UUID: 4c4c4544-004a-5710-8038-c8c04f335831
[INFO] [ComputerIdentification.ResolveComputerName] Physical addresses: 90B11C147953
[INFO] [ComputerIdentification.MapDevice] Solved computer name 'LABPC001' in domain 'IMAGOVERUM' for SMBIOS UUID '4c4c4544-004a-5710-8038-c8c04f335831'
[INFO] [PeAgent.ResolveComputerName] Resolve computer name: LABPC001 in domain IMAGOVERUM
[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Finished copying DeviceMapping.xml from the Empirum Server.

Weitere Infos am Client (nach der Windows Installation) …

ALT-TAB zum Wechseln in den Hintergrund und anmelden als Admin.
Höchstwahrscheinlich muss dieser Vorgang 2x getätigt werden, da man beim ersten Versuch durch einen Neustart schnell wieder abgemeldet wird.
Nun findet man die entsprechende Log-Datei im %Programdata%\Matrix42\Logs\UAF Ordner.
Die Stelle, nach der man sucht, ist identisch zu den oben aufgeführten Meldungen.

UUID anstatt MAC Adressen bevorzugen

Die Eindeutigkeit ist mit der Nutzung von UUIDs anstatt MAC Adresse (siehe PXE Dienst im Empirum DBUtil) prinzipiell besser.
Wenn aus Gründen …

• nur die MAC Adresse bekannt bzw. einfacher zu pflegen ist
• nur die MAC Adresse eindeutig ist, weil es mehrere Hardware mit identischer UUID gibt
• die MAC Adresse genutzt wird, …

gelten trotzdem die gleichen Regeln – Eindeutigkeit bei den MAC Adressen am Computerobjekt!

Falls man mehrere Notebooks mit einem externen USB zu Ethernet Netzwerkanschluß installieren möchte, muss man bei Bedarf die Netzwerkadresse am bereits installierten Gerät anpassen, falls die MAC-Adresse das führende Merkmal für die PXE-Installation ist.

Der Beitrag Empirum: Failed to copy a sufficient DeviceMapping.xml erschien zuerst auf Workplace Management Blog.

Bei welcher Aktion wird mir diese Option angeboten?

Bei der Aktivierung einer kompletten Gruppe anstatt einem einzelnen Computerobjekt, wird einem im Aktivierungsassistenten beim zweiten Schritt der nachfolgende Dialog angeboten.

Welche Auswirkung hat die Option?

Durch das Setzen der Option „Für alle untergeordneten Elemente übernehmen“, die ich unten eingerahmt habe, überschreibt die angezeigte Verteilungsoption alle bereits vorhandenen Verteilungsoptionen der darunter liegenden Softwarepaketen. Dies hat zur Folge, dass gesetzte Optionen wie Zeitplaner, Deinstallieren etc. mit „Installieren, Erneuern“ überschrieben wird. Die Aktivierung einer Gruppe hat sowieso zur Folge, dass alle darunter befindlichen Computerobjekte aktiviert werden – eine „Übernahme für darunter befindliche Objekte“ ist nicht gesondert notwendig!

Was kann ich tun, wenn ich diese Option fälschlicherweise aktiviert habe?

Wenn Du diese Option ausgewählt hast, oder eben ein Kollege, und das „Problem“ bemerkst, solltest Du als nächstes zur Sicherheit die gesamte Struktur deaktivieren und falls DepotServer im Einsatz sind zur Sicherheit eine Synchronisation des Jobs „ESubdepot_MachineValues“ oder eben „ESubdepot_MachineValues_QuickSync_Night“ forcieren.

Im Nachgang musst Du dich vergewissern, welche Abweichungen welche Folgen haben.
Das Überschreiben eines Zeitplaners, oder der Option „Nicht Anzeigen“ ist zumeist nicht so kritisch. Das Überschreiben von „Deinstallieren“ mit „Installieren, Erneuern“ sorgt dagegen für zumeist ungewünschte Effekte. Für den ersten Fall, kann man sich überlegen, stückweise die Optionen wieder zu setzen und neu zu aktivieren.

Für das Wiederherstellen des Ursprungszustandes im zweiten Fall hilft meines Erachtens nur eine Rücksicherung der Datenbank. Dies hat natürlich den Verlust, der seit der Sicherung durchgeführten Änderungen, zur Folge. Neben neuen Softwarezuweisungen, sind dies auch Rückmeldungen der Softwareverteilung und Inventarisierungsstände.

Deswegen, bitte auch immer neue Kollegen proaktiv auf diese Option und ihre mögliche Auswirkungen hinweisen.

Weiterer Hinweis

Wenn man tatsächlich für alle neuen Verteilungen eine besondere Verteilungsoption („Ablehnen möglich: 5“ oder ähnlich) setzen möchte, so sollte man die Experte, Verteilungsoptionen… Funktion nutzen.

Der Beitrag Gefährliche Aktivierungsoption erschien zuerst auf Workplace Management Blog.

Der WinPE PXE-Boot bootet ein von Empirum modifiziertes bzw. ergänztes Windows PE. Das WinPE wurde im Bedarf um weitere Treiber ergänzt, aber auf jeden Fall um nützliche Libraries und den Matrix42 UAF Dienst. Letzterer führt die zugewiesenen PreOS-Packages (Powershell „Pakete“) aus und bedient sich der gesetzten Variablen. Diese zugewiesenen Pakete beschreiben die Art und Weise, wie z.B. die Betriebssystem-Installation stattfinden soll. Auf weitere Einzelheiten und Vergleiche mit dem EPE Boot werde ich an anderer Stelle eingehen.

So gliedert sich der WinPE PXE-Bootvorgang in:

• Laden und Ausführen der WinPE Umgebung
• Laden des Matrix42 UAF Dienstes
• Verarbeiten der PreOS-Packages

Nun zu möglichen Problemen und Maßnahmen/Hilfestellungen zur Bearbeitung.

Laden der Windows PE Umgebung

Schlägt bereits das Laden der WinPE Umgebung fehl, so könnte dies ggf. an der TFTP Blocksize liegen. Diese kann bis Empirum v19 global in der .config Datei des BTQH (Backend Task Queue Host Services) Dienstes eingestellt werden. Standardmäßig steht dieser Wert auf 4096. Mit größeren Werten kann man den Boot beschleunigen. Damit kann er jedoch unzuverlässiger werden. In einem Falle musste ich die Größe auf 1456 festsetzen, damit der Boot zuverlässig an allen Standorten funktioniert hat.

Windows PE ist gestartet

Sobald das Windows PE gestartet ist, kann mittels STRG+C auf die Kommandozeile und per STRG+L direkt auf die Log Datei des UAF Dienstes zugegriffen werden. Die Windows PE Umgebung befindet sich unter X:\. Der UAF Dienst liegt im Ordner X:\UAF. Das wpeinit.log unter X:\Windows\System32.

Herstellen einer Netzwerkverbindung

Damit der im WinPE implementierte UAF Dienst seine Aufträge abarbeiten kann, bedarf es einer grundlegenden Netzwerkverbindung. Diese Verbindung wird durch Laden und Starten des Netzwerk-Stacks durch die  X:\Windows\StartNet.cmd und nachvollziehbar durch die wpeinit.log  vorgenommen (QueryAdapterStatus ist hier das passende Suchwort). Kann das WinPE keine Netzwerkverbindung aufbauen, kann es notwendig sein, das WinPE mit Netzwerk- und/oder Speicherverwaltungs-Treibern (Storage) zu versorgen. Dies geht über die Bootkonfiguration und wird in einem anderen Beitrag erläutert.

DeviceMapping.xml

Die DeviceMapping.xml im \\%EmpirumServer%\Values$ Verzeichnis stellt die Verbindung MAC-Adresse bzw. UUID zum Computernamen her. Somit darf jede MAC Adresse bzw. UUID auch nur einmal in der DeviceMapping.xml vorhanden sein. Beim Einsatz von SubDepots muss zusätzlich beachtet werden, dass es für die DeviceMapping Datei einen separaten SyncJob (ESubdepot_DeviceMapping) gibt, der zugewiesenen werden muss.

UAF – Auftragsverarbeitung

Das Vorgehen des UAF Dienstes wird im Matrix42.Platform.Service.Host.log festgehalten. Wie zuvor beschrieben, kann dies per STRG+L geöffnet werden. Um Neuerungen mitzubekommen, muss man ggf. das Fenster schließen und erneut aufrufen. Nach einer UAF Sitzung wird das Log auf den EmpirumServer zurückgeschrieben. In Empirum v18 bzw. WinPE 1.4.14 ist das das Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\OS\Auto\<letzten8 Stellen der MAC-Adrese> bzw. <UUID>.

PXE-Image / WADK Version

Wenn man die neuen WinPE Versionen einsetzt, sollte man wie ein Blog-Leser zusätzlich darauf hingewiesen hat, sicherstellen, dass man die aktuelle WADK Version auf dem EmpirumServer installiert hat. Matrix42 empfiehlt den Einsatz der WADK Version 1903 (eine Version 1909 wird nicht von Microsoft bereitgestellt). Mit dem WADK 1903 habe ich bis dato keine schlechten Erfahrungen gemacht, ganz gleich ob Windows 10 Enterprise 2016 LTSB oder Windows 10 Build 1909 installiert wurde. Zusätzlich sollte man darauf achten, dass die PXE-Image Erstellung (unter Konfiguration\Boot-Konfiguration) erfolgreich ist. Die aktualisierten PreOS Pakete funktionieren auch nur zuverlässig mit einer zu der Version passenden Boot-Konfiguration bzw. aktualisierten PXE-Image.

Der Beitrag Empirum WinPE Boot Troubleshooting 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 (691 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

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

Dies kann mit den folgenden beiden Schritten behoben werden …

Schritt1: Sync-Job für Windows Server 2012R2 freigeben

Der nachfolgende Befehl ist auf die Standort Datenbank auszuführen:

Update Software Set OSSystems='101171616' Where Type='SYNC'

Schritt 2: Neuerstellung der SWDepot.dds

Anschließend muss die neue Erstellung der SwDepot.dds Datei durch das Speichern der Konfiguration bzw. einer Konfigurationsänderung in der Management Console unter Konfiguration, Software-Management, SoftwareDepot erzwungen werden.

Hinweis in eigener Sache

Dieses Vorgehen habe ich mit der Empirum V16.1 mehrmals erfolgreich durchgeführt. Teilweise waren selbst erstellte SYNC Jobs für alle Betriebssysteme freigegeben. Bei neueren Empirum Versionen ist zur Sicherheit zuvor zu prüfen, welchen OSSystems Wert andere SYNC Jobs haben:

select SoftwareName, OSSystems from Software where Type='SYNC'

Der Beitrag Empirum Sync-Job wird nicht auf Windows Server 2012R2 installiert erschien zuerst auf Workplace Management Blog.

Wo wird die Anpassung vorgenommen?

Die Anpassung dieser Anzeige geschieht über ein Custom EIS Skript. Alle Custom EIS Skripte, also die Empirum Installer Skripte die man als Kunde anpassen darf, liegen im Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\Scripts2\Custom. In diesem Falle ist die showosinfo.eis die passende Datei für die Anzeige von Informationen betreffend der Betriebssysteminstallation.

Inhalte

Im Anhang befindet sich die von mir angepasste Version. Hier kann auch jeder selbst für sich entscheiden, welche Informationen er gerne dabei hätte oder welche nicht. Der Aufbau und die Quelle der Informationen sollte leicht zu verstehen sein. Somit könnt Ihr die Informationen zusätzlich zur Anzeige bringen, die euch interessieren. Das müssen ja nicht alle Werte sein, die in der zum Download angebotenen Datei sind. Die Syntax und weiteres zur EIS Skript Anpassung findet ihr unter OS Installer EIS Dokumentation in der Empirum Hilfe.

Fertige Datei

Eine fertige showosinfo.eis findet ihr hier zum Download: showosinfo.eis (1440 Downloads )

Im ersten Schritt solltet ihr eine Sicherungskopie der vorhandenen Datei vornehmen! Im Anschluß daran die angepasste showosinfo.eis Datei in das oben genannte Verzeichnis ablegen bzw. den Inhalt ersetzen. Falls ihr SubDepots im Einsatz habt, so müsst ihr die Datei noch an alle Standorte synchronisieren. Dann sollte bei der nächsten OS Installation das PXE-Log ein paar Zeilen mehr haben – die mit euren Änderungen!

Viel Spaß und gutes Gelingen!
Jochen

Der Beitrag Empirum PXE Log Anzeige erschien zuerst auf Workplace Management Blog.

Dazu ist bereits eine Aufruf bei den externen Programmen eingerichtet.
Dieser Aufruf sieht wie folgt aus:

Sync Monitor.exe /host %Computername%

Möchte man einen definierten Sync-Job direkt per Kommandozeile anstossen, so ist dies wie folgt möglich:

Syntax: Sync Monitor.exe /host <EmpirumSyncHost> /exec <JobName> 
Beispiel: Sync Monitor.exe /host EmpSubFra01 /exec ESubdepot_Empinst

Zum Anhalten eines Jobs kann der Befehl /stop <TaskName> genutzt werden.

Hinweis: Es ist zu beachten, dass die Tasknamen „case sensitive“ sind. Es ist also auf die Groß-/Klein-Scheibung der Jobnamen zu achten.

Der Beitrag Empirum Sync Monitor „Geheimnisse“ erschien zuerst auf Workplace Management Blog.

Hintergrund

Im Standard der Empirum Paket Vorlagen werden diese detaillierten Log Dateien von extern aufgerufenen Setup Routinen wie MSI und Unattended im %WINDIR%\Temp Ordner abgelegt. Schlägt eine Installation fehl, werden diese Log Dateien mit den Fehlern vorgehalten (nicht gelöscht) damit das Problem näher erörtert werden kann. Wenn nun Computer ausgeschaltet sind oder der Zugriff auf den Computer nicht sichergestellt ist (Notebook Benutzer, Firewall, etc.) kann derzeit jedoch keine weiterführende bzw. zeitnahe Analyse bezüglich des Problems stattfinden.

Idee

Ich habe mir dazu ausgedacht, dass im Fehlerfalle diese Log Dateien zusätzlich in das Log Verzeichnis des Agenten kopiert werden und dieser überträgt die Dateien auf den zentralen EmpirumServer. Dieser ist immer erreichbar und der Zugriff kann zentral gesteuert werden. Die Synchronisierung der Log Dateien wird über den EmpirumAgenten sichergestellt, da diese in einem Unterverzeichnis von C:\EmpirumAgent\Log abgelegt werden.

Umsetzung

Die nachfolgenden Beispiele sind ggf. auf die eigene Umgebung und das Agenten-Verzeichnis anzupassen.

Notwendige Setup.inf Anpassung

Dazu wurde folgende Änderung bzw. zusätzlichen Zeilen in der Setup.inf erstellt:

[Environment]
MSILogFileName=MSI_%ProductName%.%Version%.%Revision%.log
MSILogFile=%Temp%\%MSILogFileName%
ErrorMsgSyncDir=C:\EmpirumAgent\Log\InstallErrors.CU\%Computername%

[AbortMSIInst]
CALLHIDDEN %COMSPEC% /C MD "%ErrorMsgSyncDir%"
COPY "%MSILogFile%" "%ErrorMsgSyncDir%\%MSILogFileName%"
ErrorLogMsg %ErrorLogMessage% ErrorLevel: %ErrorLevel%
Abort

[AbortMSIUnInst]
-Abort
-ErrorLogMsg %ErrorLogMessage% ErrorLevel: %ErrorLevel%
-COPY "%MSILogFile%" "%ErrorMsgSyncDir%\%MSILogFileName%"
-CALLHIDDEN %COMSPEC% /C MD "%ErrorMsgSyncDir%"

Anpassung in der Management Console

Der Zugriff auf das zentrale Log Verzeichnis eines Computers kann über einen „Rechtsklick“ auf den Computer geschehen. Die Konfiguration wird über die Management Console, Extras, Eigenschaften unter „Externe Programme“ vorgenommen.

• Zentrales Log Verzeichnis
• explorer \\%EmpirumServer%\configurator$\Log\InstallErrors.CU\%Computername%

Das gezeigte Beispiel nutzt die EmpirumServer Variable. Hier muss ggf. der zentrale EmpirumServer eingetragen werden und das Support-Personal zum Lesen berechtigt werden.

Bereinigung

Die zyklische Bereinigung des zentralen Log Verzeichnisses muss derzeit von Hand durchgeführt werden.

Der Beitrag Empirum: Einfacherer Zugriff auf detaillierte Fehler-Protokolle erschien zuerst auf Workplace Management Blog.

Empirum Inventory Konfiguration

Damit man die genaue Dateiversion hier angezeigt bekommt, muss man die Konfiguration der Inventarisierung anpassen. Dazu wechselt man in der Management Console unter Konfiguration, Inventory auf das Register Inventory-Konfiguration und öffnet über den „Datei, Öffnen“ Dialog die EmpInvScan_Windows.xml.

Anschließend wählt man in der rechten Baumansicht „Dateisuche“ aus. Nun fügen wir unter der Dateisuche Einträge hinzu (Link zur WebHilfe).Hierbei ist nur der Dateiname, Hersteller und Anwendungsname auszufüllen! Den Rest erledigt die Inventarisierung durch den Parameter /V2 für uns.

Die folgende Liste enthält Beispiele, die je nach Wunsch angepasst werden kann.
Hersteller, Anwendungsname, Dateiname
Matrix42, Empirum Inventory, %SYSTEM%\Empirum\EmpInventory.exe
Matrix42, Empirum Remote Installer Service, %SYSTEM%\Empirum\ERIS.exe
Matrix42, Empirum Personal Backup, %SYSTEM%\Empirum\PBackup.exe
Matrix42, PM3Client, %ProgramFiles%\Matrix42\PM3Client\PM3Client.exe

Hier auch Beispiel für eine nicht Matrix42 Komponente:
Microsoft, Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

Wenn die Einstellungen vorgenommen wurde, muss die Konfiguration gespeichert werden.
Für die letztendliche Nutzung muss die Konfiguration je nach Infrastruktur ggf. noch auf SubDepots synchronisiert und mittels des EmpirumAgenten auch noch auf die Clients synchronisiert werden. Ab diesem Zeitpunkt sollte dann das Inventory „auskunftsfreudiger“ sein. Hierzu finden sich dann genauere Versionsangaben unter „Inventory\Dateien“ und „Inventory\Software“ eines jeden Computers.

Diese Informationen können natürlich dann auch über Filter, etc. ausgewertet werden.

Der Beitrag Ermittlung installierter Programm-Versionen erschien zuerst auf Workplace Management Blog.

Wo werden die Aufrufe zu externen Programmen hinterlegt?

Im Bereich „Administration“, im Menü unter „Extras“, „Einstellungen …“ gibt es den Reiter „Externe Programme“. Mit einem Klick auf das „+“ Symbol wird ein neuer Eintrag vorbereitet.
Jeder externe Programmaufruf benötigt dann die Eingabe eines Namens und einer Angabe zum Programm das aufgerufen wird. Will man diesen Programmaufruf allen Benutzern der Management Console bereitstellen, so muss man zusätzlich die Option „Globales Programm (Für alle Benutzer)“ setzen. Wenn man mit der Eingabe des oder der weiteren externen Programmaufrufe fertig ist, sollte man den Dialog auch mit „OK“ verlassen, ansonsten werden die gemachten Änderungen nicht gespeichert!

Welche Variablen können genutzt werden?

Es stehen für die Aufrufe diverse Variablen zur Verfügung.

Die meist genutzten Variablen sind:

• %Computername%
• %IP%
• %Domain%

Darüberhinaus stehen jedoch auch:

• %INVENTORYID%
• %DOMAIN%
• %MACADDRESS%
• %MAC8%
• %CUSTOM01% bis %CUSTOM30%

zur Verfügung

Beispiele für Aufrufe

• Verteilaufträge – Computer
  notepad \\%EmpirumServer%\Values$\MachineValues\%Domain%\%Computername%.ddc
• Variablen – Computer
  notepad \\%EmpirumServer%\Values$\MachineValues\%Domain%\%Computername%.ini
• Explorer C$
  explorer \\%Computername%\C$
• Ping (3 Sekunden)
  ping -n 3 %Computername%
• Computerverwaltung
  Compmgmt.msc /Computer:%Computername%
• MAC8 Ordner
  explorer \\%EmpirumServer%\EmpInst$\Wizard\OS\Auto\%Mac8%
• WinPEStatus
  explorer \\%EmpirumServer%\EmpInst$\Wizard\OS\WinPEStatus\%Domain%_%Computername%

Fernsteuerung

Das gleiche Prinzip wie bei den externen Programmen gilt auch für die Fernsteuerung. Auch hier können weitere eigene Aufrufe zu eigenen Fernsteuerprogrammen hinterlegt werden. Eine, die die jeder nutzen kann ist …

• Microsoft RemoteDesktop
  mstsc /v:%Computername%

Ideen …

Weitere Programmaufrufe zum Durchführen eines Neustarts oder Shutdowns, sowie die Nutzung von PSEXEC lassen noch viele weitere spannende Aufrufe zu.

Viel Spaß beim Ausprobieren!

Der Beitrag Externe Programmaufrufe oder Fernsteuerung aus der EMC erschien zuerst auf Workplace Management Blog.