You searched for STRG - Workplace Management Blog https://www.wpm-blog.de/ ... ideas and solutions making workplace management easier Sun, 16 Nov 2025 18:11:39 +0000 de hourly 1 https://wordpress.org/?v=6.1.7 Empirum: Failed to copy a sufficient DeviceMapping.xml https://www.wpm-blog.de/empirum-failed-to-copy-a-sufficient-devicemapping-xml/ https://www.wpm-blog.de/empirum-failed-to-copy-a-sufficient-devicemapping-xml/#respond Sun, 16 Nov 2025 18:11:39 +0000 https://www.wpm-blog.de/?p=3067 Wenn die Empirum OS Installation per PXE oder USB Stick in einem frühen Stadium mit der Meldung: „Failed to copy a sufficient DeviceMapping.xml“ am Client fehlschlägt, sind viele erst einmal ratlos. Diese Meldung erscheint, wenn … Weiterlesen

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

]]>
Wenn die Empirum OS Installation per PXE oder USB Stick in einem frühen Stadium mit der Meldung: „Failed to copy a sufficient DeviceMapping.xml“ am Client fehlschlägt, sind viele erst einmal ratlos.

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.

]]>
https://www.wpm-blog.de/empirum-failed-to-copy-a-sufficient-devicemapping-xml/feed/ 0
Empirum WinPE – neues Computermodell https://www.wpm-blog.de/empirum-winpe-neues-computermodell/ https://www.wpm-blog.de/empirum-winpe-neues-computermodell/#comments Tue, 27 Oct 2020 21:10:53 +0000 https://www.wpm-blog.de/?p=2682 Wie man an anderen Beiträgen bestimmt schon gemerkt hat, habe ich Spaß am WinPE OS-Installer und möchte mein Wissen hierzu an Euch weitergeben. Es gibt ein paar „Probleme“ bzw. Fragen, die bei den Nutzern immer … Weiterlesen

Der Beitrag Empirum WinPE – neues Computermodell erschien zuerst auf Workplace Management Blog.

]]>
Wie man an anderen Beiträgen bestimmt schon gemerkt hat, habe ich Spaß am WinPE OS-Installer und möchte mein Wissen hierzu an Euch weitergeben. Es gibt ein paar „Probleme“ bzw. Fragen, die bei den Nutzern immer wieder auftreten. In diesem Artikel geht es vorwiegend darum, dass ihr eine Umgebung habt die funktioniert, jedoch könnt ihr auf einmal keinen Computer mehr oder einen neues Computermodel gar nicht installieren.

Empirum OS-Installer – die drei Phasen

Teilen wir die Probleme ein, in die drei Phasen der OS-Installation per Empirum WinPE.

  • PXE-Boot
  • WinPE
  • Windows

PXE Boot

A.) Der PXE Boot funktioniert nicht bzw. hat noch nie funktioniert.
Die Switche bzw. VLANs müssen den Broadcast an den PXE-Server (zusätzlich zum DHCP Server) weiterleiten, gerne wird hier der Begriff „IP Helper“ aus der Cisco Welt hergenommen.
Die Windows Firewall muss den eingehenden Netzwerkverkehr auf den PXE- und TFTP-Ports zulassen. Die freizugebenen Ports sind abhängig von PXE Einstellungen. Wer auf Nummer sich gehen will, gibt die UDP Ports: 67,68,69,4011,10042 frei.

Hinweis: Auch ich habe früher die PXE Weiterleitung über die DHCP Option ID 43, im Zusammenspiel mit der Option 60, durchgeführt. Heute bestehe ich gerne auf der Umsetzung der Weiterleitung der UDP Anfragen.

B.) Kein Computer führt mehr einen PXE-Boot durch, obschon dies vorher der Fall war.
In diesem Fall, schaut nach, ob Euer Empirum PXE-Dienst weiterhin läuft und erreichbar ist.

C.) Andere Computer starten einen PXE-Boot, doch dieser eine Computer nicht. Dies hat zumeist die folgenden Ursachen:

  • Überprüft die beim Computer hinterlegte MAC/UUID mit den Werten die im BIOS angezeigt werden. Ausnahmen sind natürlich externe Docking-Stationen oder Netzwerkadapter.
  • Wird MAC Passthrough genutzt und welche Einstellungen dazu bietet das BIOS. MAC Passthrough ist auch sehr abhängig vom Windows Treiber.
  • Ist das Computerobjekt in den Eigenschaften als „PXE fähig“ markiert?
  • Wenn dies alles passt, so führt bitte über Matrix42 DBUtil das SQL Script: „OS_CleanupNonUniqueDhcpEntries.sql“ aus dem Verzeichnis Empirum\Empirum DBUtil\Scripts\SQLServer\Custom aus. Mit der Ausführung dieses Skripts könnt ihr nichts kaputt machen! Es kann auch mehrfach ausgeführt werden.

D.) Wenn Sie diesen Bildschirm sehen, dann haben sie die vorgenannten Probleme nicht, nicht mehr oder erfolgreich gemeistert.

WinPE

Hast Du es in die WinPE Phase „geschafft“, sieht Du einen grauen Hintergrund oder gar das Matrix42 Logo, und eine Fortschrittsanzeige, wie hier abgebildet.

Die letzten drei Schritte in der Anzeige (wie in diesem Screenshot) bekommst Du erst mit der WinPE Umgebung neuer als 1.8.3 aufgelistet. Schlägt der „Connect to server“ fehl, dann muss man sich zumeist um die Einbindung der passenden Treiber kümmern (siehe Einbinden der WinPE Treiber). Alternativ kann es auch zu Problemen mit der Anmeldung (Benutzername und Kennwort) kommen. In das Log kommt man mit STRG+L. Dies kann man zur genaueren Analyse auch auf einen USB-Stick kopieren.

War die Verbindung erfolgreich und es erscheint die vorherige Meldung, dann liegt es daran, dass kein eindeutiger Eintrag (kein oder doppelter) in der DeviceMapping.xml (Empirum\Configurator\Values) vorhanden ist. Dazu kann man die DeviceMapping.xml mit einem Editor starten und prüfen, ob der Computername gefunden werden kann. Falls ja, nutzt die dazugehörige MAC Adresse oder UUID und sucht danach in der Datei – wahrscheinlich findet ihr einen weiteren Computer mit identischen Werten. Dieses Problem muss behoben werden!

Unabhängig der genannten Probleme, kann es sein, dass der EmpirumAgent Benutzer keine Schreibberechtigungen auf den Empirum\EmpInst\Wizard\OS\WinPEStatus Ordner hat.

Sind all diese Hürden genommen und es kommt trotzdem zu Problemen, dann liegt das zumeist an der Ausführung eines der WinPE Pakete. In seltenen Fällen sollte man prüfen, ob das Paket tatsächlich auf dem EmpirumServer oder dem SubDepot vorhanden ist. Ansonsten sind es dann Probleme bei der Parametrisierung der Pakete. Da hilft Euch jedoch das Log in WinPEStatus Order weiter bzw. sogar häufig das SWDepotLog in der Management Console.

Einbinden der WinPE Treiber

Für die WinPE Phase müssen die Treiber (zumeist nur Netzwerkkartentreiber) über die Management Console, Konfiguration, Boot Konfiguration eingebunden werden.
Dazu die Erweiterten Eigenschaften aktivieren (oben rechts) und bei Zusätzliche Treiberverzeichnisse ein Ordner angeben, in dem die Treiber abgelegt sind oder werden.Ich empfehle ein Ordner unterhalb von Empirum\EmpInst\DRV anzulegen und dort die Treiber ggf. nach Modell sortiert abzulegen. Die Treiber werden auch aus den Unterverzeichnissen (rekursiv) hinzugefügt, so muss man nicht pro Treiber ein Ordner in der Oberfläche angeben. Hast Du diesen Ordner bereits, brauchst Du die Treiber nur in diesem Ordner zusätzlich abzulegen und die Boot Konfiguration neu zu speichern, über den „Speichern“ Button (unten rechts).

Hinweis: Das WinPE nutzt den ersten passenden Treiber. Das muss nicht der aktuellste Treiber sein, der ggf. für diese Hardware optimiert ist!

Du kannst dann an Deiner Boot Konfiguration verschiedene Zustände feststellen – Sanduhr, Zahnräder und am Ende einen grünen Haken. Sobald die Boot Konfiguration erfolgreich neu erstellt wurde, kannst Du den nächsten Boot-Versuch starten.

Hinweis 2: Schlägt die Erstellung des PXE-Images recht schnell nach dem Speichern fehl, so liegt das zumeist daran, dass das Matrix42 Zertifikat erneut auf dem EmpirumServer eingebunden werden muss. Dazu den nachfolgenden Befehl per powershell auf dem EmpirumServer ausführen:

Import-Certificate -FilePath "<EmpirumLaufwerk>:\Empirum\EmpInst\Sys\Images\WinPE\binaries\UAF\matrix42ag.Cer" -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

Möchtest Du nicht den Netzwerkartentreiber für die einzelnen Modelle raussuchen bzw. aus dem Windows 10 Treiberpaket entnehmen, so kannst Du auch ein komplettes WinPE Treiberpaket des jeweiligen Herstellers hinterlegen. Dazu jedoch immer erst das alte Verzeichnis löschen und anschließend das neue kopieren/ablegen.

Hier ein paar Beispiele:

Windows

Mit den vorherigen Tipps sollte sich das Windows automatisiert installieren lassen. Ein weiterer häufiger Knackpunkt kommt im Anschluss an die Windows-Installation.
In der Management Console kann man noch eine erfolgreiche Installation von PxeOffAndReboot verzeichnen, jedoch schreitet die Installation nicht weiter voran.

Am Client sieht man dann eine durchlaufende Fortschrittsanzeige vor dem ausgeblendeten Windows-Hintergrund und das System führt alle 5 Minuten einen Neustart durch.
Ein weiterer Indiz ist, dass im PXE-Log des Computers während des DriverIntegration Pakets kein Treiber für das Model kopiert wurde. In diesem Fall fehlt in den meisten Fällen mindestens der Netzwerkkartentreiber für Windows bzw. das komplette Treiberpaket. Diese integriert man mit Hilfe des WinPEDriverAssistant’s aus dem Empirum\AddOns\WinPEDriverAssistant Ordner.

Die Treiber, ganz gleich ob *.zip, *.cab oder ein Ordner werden dann unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt. Du kannst die Treiber auch direkt dort ablegen und nur den Namen in das Treiberfeld einfügen – und nicht über das Ordner Symbol für den Import daneben gehen.

Dazu benötigt man die Hersteller und Modellbezeichnung und die entsprechenden Treiber.
Die Hersteller und Modellbezeichnung könnt ihr mit dem HardwareInfo Paket auslesen, oder wie gerade schon beschrieben, schaut ihr in das PXE-Log des Computers. Die erste Meldung ist „Using OS specific driver assignment for vendor …“.

Die Treiber dazu bekommst du bei den Herstellern. Dazu hatte ich bereits beim Beitrag für EPE die Seiten der Hersteller zusammengefasst.
Hast Du die Windows 10 Treiber eingebunden und das DriverIntegration Paket kopiert die Treiber, wie im zu vorigen Screenshot zu erkennen („Using the drivers: …), dann sollte es auch keine Probleme nach der Windows Installation geben.
Wenn es trotz Windows 10 Treiber nach dem PxeOffAndReboot nicht „weitergeht“, dann solltest Du schauen, dass du in Empirum DBUtil die UUID anstatt der MAC als „führendes“ Merkmal nutzt.

Mit diesen Tipps bin ich bester Dinge, dass Du eine erfolgreiche Windows Installation hinbekommst.

Als Grundlage solltest Du die anderen Blog Beiträge erfolgreich umgesetzt haben.
Zum Troubleshooting hatte ich bereits diesen Beitrag hier geschrieben.

 

Der Beitrag Empirum WinPE – neues Computermodell erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-winpe-neues-computermodell/feed/ 2
Empirum WinPE Boot Troubleshooting https://www.wpm-blog.de/empirum-winpe-boot-troubleshooting/ https://www.wpm-blog.de/empirum-winpe-boot-troubleshooting/#comments Sat, 06 Apr 2019 16:37:18 +0000 https://www.wpm-blog.de/?p=2164 Matrix42 bietet nun seit einer geraumen Zeit die Alternative WinPE als PXE-Bootmedium für die Windows 10 Installation an. In Kürze wird damit auch die automatisierte Installation von Windows 7 und der Windows Server Versionen möglich … Weiterlesen

Der Beitrag Empirum WinPE Boot Troubleshooting erschien zuerst auf Workplace Management Blog.

]]>
Matrix42 bietet nun seit einer geraumen Zeit die Alternative WinPE als PXE-Bootmedium für die Windows 10 Installation an. In Kürze wird damit auch die automatisierte Installation von Windows 7 und der Windows Server Versionen möglich sein. Damit werden weitere Grundlagen geschaffen, den herkömmlichen EPE PXE-Boot für Windows Installationen obsolet zu machen. Die Installation per WinPE ist in der Empirum Welt ein Bruch mit dem vorhandenen Vorgehen, dass ich jedoch nicht negativ werten möchte. Die Möglichkeiten sind vielfältiger, die Umsetzung dagegen noch jung und somit nicht so umfänglich wie der vorhandene EPE PXE-Boot.

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.

Update: In neueren WinPE Versionen werden die Log Dateien nach \\%EmpirumServer%\EmpInst$\Wizard\OS\WinPEStatus\%Domain%_%Computername% geschrieben .
Hinweis: Bis WinPE 1.4.14 (mindestens) werden die Log Dateien nicht überschrieben, wenn zwischenzeitlich ein Neustart stattgefunden hat.

 

Der Beitrag Empirum WinPE Boot Troubleshooting erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-winpe-boot-troubleshooting/feed/ 8
Fehler und ErrorLevel aus der Setup.inf https://www.wpm-blog.de/fehler-und-errorlevel-aus-der-setup-inf/ https://www.wpm-blog.de/fehler-und-errorlevel-aus-der-setup-inf/#comments Wed, 27 Mar 2013 08:58:18 +0000 https://www.wpm-blog.de/?p=891 Niemand und nahezu nichts ist komplett fehlerfrei – doch man kann sich Stück für Stück verbessern! Bei der Erstellung von Software-Paketen, beim Verteilen von Software-Paketen oder Patches mit dem Patch-Management treten schon auch mal Fehler … Weiterlesen

Der Beitrag Fehler und ErrorLevel aus der Setup.inf erschien zuerst auf Workplace Management Blog.

]]>
Niemand und nahezu nichts ist komplett fehlerfrei – doch man kann sich Stück für Stück verbessern! Bei der Erstellung von Software-Paketen, beim Verteilen von Software-Paketen oder Patches mit dem Patch-Management treten schon auch mal Fehler auf. Diese sollten natürlich in der Test und Pilotphase festgestellt und behoben werden. Die angezeigten Fehlermeldungen bzw. der ERRORLEVEL im SWDepot-Log der Management Console kann erste Aufschlüsse über den Fehler geben, und wie er behoben werden kann. Manche angezeigten „Fehler“ sind auch gar keine. Wie ist damit umzugehen?

Die angezeigten ERRORLEVEL haben ihren Ursprung zumeist im Kommando Interpreter oder in den Installern. Unten angefügt habe ich zwei Tabellen mit den häufigsten Fehlermeldung. Diese Tabellen erheben jedoch keinen Anspruch auf Vollständigkeit.

Was sind die gängigen Fehler und wie lassen sie sich beseitigen?

Die ERRORLEVEL Meldungen rühren aus der Setup.inf des fehlerhaften Empirum Paketes.

Fehler 2 oder 3
In diesem Fall ist zumeist ein Befehl falsch geschrieben, die Setup.exe ist zu alt für den genutzten Befehl, ein aufzurufendes Programm wurde versucht als Befehl zu interpretieren.

Fehler 5
Kein Zugriff möglich oder auch Zugriff verweigert bedeutet zumeist, dass der Befehl aufgrund von nicht vorhandenen Berechtigungen fehlschlägt. In Empirum ist das zumeist, wenn in der Registry Änderungen durchgeführt werden sollen, zu der der Benutzer nicht berechtigt ist. Das können Änderungen im Bereich HKLM\SYSTEM, als auch HKCU\Software\Microsoft\Policies sein. Der Benutzer hat zwar Berechtigungen auf den HKCU Zweig, jedoch nicht im Bereich der Policies, denn diese soll er ja auch nicht „manipulieren“ können.

Fehler 1602
Dieser Fehler rührt vom Windows Installer und bedeutet, dass der Benutzer die „Abbrechen“ Schaltfläche des MSIEXEC Dialoges betätigt hat. Diese Schaltfläche kann mit dem „!“ entfernt werden, wie z.B. /qb-! oder /qr!. Nutzt man direkt /qn – so wird nichts angezeigt, auch nicht die „Abbrechen“ Schaltfläche.

Fehler 1603
Der „1603“ ist der beliebteste Fehler unter den Software-Paketieren, denn er bedeutet soviel wie „Es ist ein schwerwiegender Fehler aufgetreten…“. Das heißt soviel wie alles und nichts! Hier kann man dem Fehler nur durch Analyse des MSI Logs näher kommen. Das Log wird im Standard in den %TEMP% Ordner des jeweiligen Computers geschrieben und beginnt mit MSI_. Wenn die Installation mit dem Empirum Advanced Agent durchgeführt wird, so ist die Datei im Ordner %WinDir%\TEMP wiederzufinden. Häufig wird der Fehler am Ende des Logs angezeigt, das man sehr einfach mit STRG+ENDE anspringen kann.

Fehler 0
Warum ist der ERRORLEVEL 0 ein Fehler? Wieso wird das Paket als fehlerhaft in der Console angezeigt bzw. läuft immer wieder, obwohl alles „gut“ aussieht und das Programm auch funktioniert? Dies liegt häufig damit zusammen, dass in Empirum Software-Paketen in denen externe Installer (Hersteller-Setups) aufgerufen werden, auch anschließend eine „Erfolgsüberprüfung“ stattfindet. Da man nicht weiß, ob die Hersteller-Setuproutine das gemacht hat was man von ihr erwartet, prüft man im Anschluß den Erfolg durch die Überprüfung auf das Vorhandensein von Registry Einträgen, Dateien oder Texte in Dateien. Können die zu erwartenden Prüfpunkte nicht erfolgreich geprüft werden, so verzweigt die Installationsabfolge in der Setup.inf in eine Sektion, in der die Empirum Installation mit „Abort“ abgebrochen wird. Der Fehler 0 tritt sehr gerne in MSI Paketen auf.

Folgendes ist zu prüfen bzw. anzupassen:

  • Ist der UninstallString in der Registry unterhalb der GUID vorhanden? (Änderung auf InstallDate hilft häufig.)
  • Ist es überhaupt die richtige GUID die abgeprüft wird?
  • Wird die ReInstSuccessMessageXXXX in dem MSILogFile richtig geprüft? Die aktuellen MSI Vorlagen prüfen 4 ReInstSuccessMessages, da sich die Meldungen mit der Aktualisierung der MSIExec Version geändert haben. Dieser Fehler tritt auch gerne beim Testen der Windows XP Pakete unter Windows 7 auf. Abhilfe schafft hier die Übernahme der 4 ReInstSuccessMessages und das Anpassen der Überprüfung (IF …) in der RepairMSI Sektion. Die Vorlage liefert die aktuelle MSI.inf.

Liste von Fehlermeldungen bzw. ERRORLEVEL Werten

Fehler – Beschreibung
0 – Fehlerfrei
2 – Datei nicht vorhanden
3 – Pfad nicht gefunden
5 – Kein Zugriff möglich
6 – Ungültiger Zugriff/ungültiges Handle
8 – Zu wenig Speicher
10 – Ungültiger Bereich/ungültige Environment Variablen
11 – Ungültiges (Befehls-)Format

MsiExec.exe und InstMsi.exe Fehlermeldungen
Hier geht es zur Microsoft Seite mit der vollständigen Liste der „MsiExec.exe and InstMsi.exe Error Messages (Windows)“

Wert – Fehler-Code – Beschreibung
0 – ERROR_SUCCESS – Die Installation war erfolgreich.
1602 – ERROR_INSTALL_USEREXIT – Der Benutzer hat die Installation abgebrochen.
1603 – ERROR_INSTALL_FAILURE – Es ist ein schwerwiegender Fehler während der Installation aufgetreten.
1642 – ERROR_PATCH_TARGET_NOT_FOUND Der Patch kann nicht installiert werden, weil die zu aktualisierende Software nicht installiert ist.
3010 – ERROR_SUCCESS_REBOOT_REQUIRED Die Installation war erfolgreich, benötigt jedoch einen Neustart!

Der Beitrag Fehler und ErrorLevel aus der Setup.inf erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/fehler-und-errorlevel-aus-der-setup-inf/feed/ 13
Empirum Paket – Registry ändern https://www.wpm-blog.de/empirum-paket-registry-aendern/ https://www.wpm-blog.de/empirum-paket-registry-aendern/#comments Mon, 28 Jan 2013 18:01:59 +0000 https://www.wpm-blog.de/?p=770 Möchte man mittels eines Empirum Paketes Änderungen in der Registry vornehmen, so ist dazu die vorhandene [Reg:Product] Sektion in der Setup.inf vorgesehen. Änderungen in der Windows Registrierung können auch über andere bzw. weitere Sektionen vorgenommen … Weiterlesen

Der Beitrag Empirum Paket – Registry ändern erschien zuerst auf Workplace Management Blog.

]]>
Möchte man mittels eines Empirum Paketes Änderungen in der Registry vornehmen, so ist dazu die vorhandene [Reg:Product] Sektion in der Setup.inf vorgesehen. Änderungen in der Windows Registrierung können auch über andere bzw. weitere Sektionen vorgenommen werden – sie müssen jedoch mit Reg: beginnen.

In einer Sektion die mit Reg: beginnt, dürfen jedoch auch nur Registry Veränderungen enthalten sein, da mittels dieser Sektion die Registry API angesprochen wird.

Wie erstellt man nun einen Registry Eintrag oder wie so häufig genannt – Reg Key?

  • Aufzeichnung per Differenzanalyseverfahren (Diff)
  • Erstellen der Einträge mittels des Package Editors
  • Import von Reg Dateien mittels des Package Editors
  • Erstellen der Registry Einträge von Hand
  • Erstellen eines „Standard“eintrag
  • Weitere Erläuterungen
  • Benutzerteil

Aufzeichnung per Differenzanalyseverfahren (Diff)

Wenn man ein Paket per „Diff“ aufzeichnet, hat man die erstellten Registry Einträge auch direkt in der REG:Product und ggf. auch der Reg:OnUninstallProduct vorliegen. Hat man ein Paket mit dem MSI oder Unattended Verfahren erstellt, so kann man anschließend die weiteren Anpassungen per Diff festhalten.

Dazu startet man das installierte Programm, wechselt zu dem Menü oder ähnlich, wo man seine Änderung (z.B.: Automatische Updates, Speicherort der Einstellungen, etc.) vornehmen möchte, startet den PackageWizard, wählt die Option „Differenzanalyseverfahren“ und führt den „PreScan“ durch. Ist der „PreScan“ abgeschlossen, führt man die Veränderung, wie die Programmeinstellung durch. Hat man die Einstellungen im Programm abgeschlossen, folgt man den Schritten des PackageWizard Assistenten bis zum Ende. Falls sich die Programmeinstellungen in Registry Änderungen „niederschlagen“, so kann man die Zeilen aus der [REG:Product] Sektion der gerade erstellten Setup.inf in das vorhandene Paket zur Programminstallation übernehmen.

Erstellen der Einträge mittels des Package Editors

Der Empirum Package Editor unterstützt den Benutzer bei der Erstellung von Registry Einträgen in der „Normalen“ und in der „Erweiterten Ansicht“ auf seine Weise. In beiden Fällen muss man zuvor in „Alle Abschnitte“ die Sektion „Reg:Product“ unter „Options“ auswählen.

In der „Normalen Ansicht“ „klickt“ man sich den Eintrag zusammen, in der „Erweiterten Ansicht“ kann man die Unterstützung mittels der Tastenkombination STRG-Leertaste nutzen.

Import von Reg Dateien mittels des Package Editors

Liegt einem bereits eine *.reg Datei vor, so kann man diese mittels des Empirum Package Editors importieren. Wie das geht ist in der Empirum Hilfe beschrieben.

Erstellen der Registry Einträge von Hand

Die Syntax der Registry Änderungen in der Setup.inf sieht auf den ersten Blick „unerlernbar“ aus. Das ist es aber auf keinen Fall! Der Pfad trennt die Wurzel (HKLM, HKCU, etc.) nicht mit einem „\“ (Backslash), sondern mit einem „,“ (Komma). Die meisten Änderungen betreffen Registry Werte vom Typ REG_SZ oder REG_DWORD.

In der Setup.inf steht nicht der Typ in Form von REG_SZ oder REG_DWORD, sondern 0x00000000 bzw. 0x00010001. Hier eine kleine „Eselsbrücke“, wie ich die wichtigsten Änderungen von Hand vornehme.

REG_SZ entspricht 0x00000000 = „NULL X 8 mal die NULL
REG_DWORD entspricht 0x00010001 = „NULL X, 3 mal NULL, EINS, 3 mal NULL, EINS

[Reg:Product]
HKLM,"Software\Hersteller\Produkt","Eigenschaft",0x00000000,"Zeichenkette"
HKLM,"Software\Hersteller\Produkt","AutoUpdate",0x00010001,"0"

Hier geht es zur vollständigen Beschreibung.

Erstellen eines „Standard“eintrag

In der Registry gibt es auch die sogenannten (Standard) bzw. (Default) Werte. Diese werden wie folgt erstellt:

[Reg:Product]
HKCR,"Software\Adobe\Acrobat\Exe",,0x00000000,'"%ProgramFiles%\Adobe\Reader 9.0\Reader\AcroRd32.exe"'

Weitere Erläuterungen

Wird die Reg: Sektion auch bei der Deinstallation aufgerufen, so wird die aufgeführte Änderung rückgängig gemacht, was zumeist bedeutet, dass der Eintrag gelöscht wird. Soll ein Eintrag bei der Deinstallation wieder auf den Wert vor der Installation „zurückgesetzt“ werden, so ist in der Setup.inf unter Reg:OnUninstallProduct der „vor der Installations Registry Wert“ einzutragen.

Soll ein Eintrag oder Baum auch bei der Installation gelöscht werden, so ist der Zeile ein „-“ voranzustellen. Hier ein Beispiel:

[Reg:Product]
-HKLM,"Software\Hersteller\Produkt"

So kann man auch bei der Deinstallation die Registry bereinigen, indem man in  der Reg:OnUninstallProduct Sektion ein „löschen“ mittels „-HKLM,…“  durchführt. Doch hier sollte man mit Vorsicht vorgehen, nicht „zuviel“ zu bereinigen!

Benutzerteil

Hat man eine Setup.inf mit „HKCU,…“ Einträgen, so besitzt dieses Paket einen sogenannten Benutzerteil. Damit der Benutzerteil ordnungsgemäß ausgeführt wird, muss die „Command Line Options =“ ein /AW aufweisen. Viel wichtiger ist jedoch, dass das /AW auch im SoftwareDepot, wo das Paket in die Empirum Management Console eingebunden ist unter den Paketeigenschaften, auf dem Register „Prüfung“, der „Befehl“ um ein „/AW“ erweitert wird. Näheres dazu ist wiederum hier zu finden.

 

Der Beitrag Empirum Paket – Registry ändern erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-paket-registry-aendern/feed/ 3
Tastaturkombinationen in der Management Console https://www.wpm-blog.de/tastaturkombinationen-in-der-management-console/ https://www.wpm-blog.de/tastaturkombinationen-in-der-management-console/#respond Tue, 20 Nov 2012 20:07:50 +0000 https://www.wpm-blog.de/?p=495 Beim letzten Empirum Partnertreffen wurde unter anderem angesprochen, ob man diverse Tastaturkombinationen in der Empirum Management Console kennt. Obwohl ich selbst sehr gerne die Tastatur nutze, um schneller an mein Ziel zu kommen, war die Kombination „STRG … Weiterlesen

Der Beitrag Tastaturkombinationen in der Management Console erschien zuerst auf Workplace Management Blog.

]]>
Beim letzten Empirum Partnertreffen wurde unter anderem angesprochen, ob man diverse Tastaturkombinationen in der Empirum Management Console kennt. Obwohl ich selbst sehr gerne die Tastatur nutze, um schneller an mein Ziel zu kommen, war die Kombination „STRG + R“ mir nicht geläufig. Wissen Sie was es macht?
Es war zumindest für der Anlass diese Kombination und weitere die ich bereits kannte hier aufzuführen. Zusätzlich habe ich die Online Hilfe genutzt und nachgesehen welche es zusätzlich noch gibt. Die Liste ist hat keinen Anspruch auf Vollständigkeit und wird gerne auf Hinweis erweitert …

Konfigurationsgruppen

  • „STRG + R“ startet den Aktivierungsdialog
  • „STRG + A“ selektiert alle Computer
  • „F2“ Umbennen von Konfigurationsgruppen
  • „F3“ startet die Suche
  • „F5“ aktualisiert die Anzeige

Software (Baum rechts)

  • „F3“ startet die Suche
  • „F5“ aktualisiert die Anzeige

Software-Depot

  • „STRG + Pfeil nach oben / nach unten“ verschiebt eine Software nach oben oder nach unten

Shortcuts zum Wechseln der Navigationsleiste (lt. Matrix42 Hilfe)

  • „ALT+M“ Management
  • „ALT+K“ und „ALT+C“ Konfiguration (Configurator)
  • „ALT+S“ und „ALT+L“ Standorte (Locations)
  • „ALT+T“ zum nächsten Tab (Bsp.: Von Management -> Konfiguration)
  • „ALT+SHIFT+T“ zum vorherigen Tab (Bsp.: Von Konfiguration -> Management)
  • Zusätzlich ist es möglich, zur letzten Ansicht zu springen.
  • „ALT + ->“ (letzter Tab) rur ein Sprung möglich
  • „ALT + <-“ (nächster Tab, wenn vorher zurück gesprungen wurde)
  • „STRG + A“ wählt alle Objekte des gleichen Typs in der Gruppe oder im Filter aus.
  • „STRG + R“ startet das Aktivierungsfenster.

Der Beitrag Tastaturkombinationen in der Management Console erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/tastaturkombinationen-in-der-management-console/feed/ 0