You searched for fehler code - Workplace Management Blog https://www.wpm-blog.de/ ... ideas and solutions making workplace management easier Sun, 02 Jul 2023 17:46:31 +0000 de hourly 1 https://wordpress.org/?v=6.1.7 Empirum Setup.inf – Reparatur Unattended Setup https://www.wpm-blog.de/empirum-setup-inf-reparatur-unattended-setup/ https://www.wpm-blog.de/empirum-setup-inf-reparatur-unattended-setup/#respond Sun, 02 Jul 2023 17:46:31 +0000 https://www.wpm-blog.de/?p=2877 Vor einiger Zeit hatte ich eine Serie begonnen, die unattended.inf Paketvorlage zu verbessern. Dazu hatte ich bereits zwei Blog Beiträge geschrieben. Leider hatte mich die mangelnde Zeit etwas vom Pfad abgebracht, diese Serie weiter zu … Weiterlesen

Der Beitrag Empirum Setup.inf – Reparatur Unattended Setup erschien zuerst auf Workplace Management Blog.

]]>
Vor einiger Zeit hatte ich eine Serie begonnen, die unattended.inf Paketvorlage zu verbessern. Dazu hatte ich bereits zwei Blog Beiträge geschrieben. Leider hatte mich die mangelnde Zeit etwas vom Pfad abgebracht, diese Serie weiter zu vervollständigen. Diesem will ich nun nachkommen. Wer diese Beiträge noch nicht gelesen hatte, dem stelle ich diese Beiträge hier nochmals vor:

  • https://www.wpm-blog.de/empirum-paket-deinstallation-ohne-quellen/
  • https://www.wpm-blog.de/empirum-errorlevel-abfrage-bei-unattended-installationen/

Reparatur Logik

Das Resultat wird, je nach Betrachtung, nicht das Optimum darstellen. Meines Erachtens ist dies jedoch schon ein gutes Stück weiter als das Original. Wir betreiben also etwas Tuning :). In diesem Beitrag soll es um die Reparatur gehen.
Das Reparatur-Handling hilft uns …

  • für die Reparatur einer Software durch Deinstallation und Neuinstallation
  • falls die Software zuvor anderweitig ggf. manuell installiert wurde, damit diese zuvor deinstalliert wird
  • falls die Software durch das Matrix42 Patch-Management vielleicht schon auf eine andere Version angehoben wurde

Grober Ablauf

Die Reparatur setzt grob auf folgenden Ablauf:
1) Erkennung, ob diese Software ggf. auch in einer anderen Version bereits installiert ist.
2) Falls ja, entfernen dieser Installation.
3) Anschließend wird mit dem „normalen Installationsablauf“ fortgefahren.

Anpassungen

Der nachfolgende Code-Schnipsel kann in die unattended.inf übernommen werden, oder ihr wartet noch die nächsten zwei Artikel ab und übernehmt dann eine gesamte unattended.inf. Was wird noch folgen? Erkennung und Abfangen von geöffneten Programmen, sowie „verstecken“ der originären Installation in der Systemsteuerung unter „Programme“.

Falls ihr diesen Schnipsel nutzt …

In der [Product] Sektion muss vor die Installation die
#CheckExistingInstallation, DONTDELETE
eingebaut werden.

Die Erkennung bzw. das Deinstallationsprogramm hinter der Variablen „VM_UnInstCMD“ muss angepasst werden.

Code-Schnipsel

[CheckExistingInstallation]
;---setzen der Variable mit dem Deinstallationsprogramm
Set VM_UnInstCMD=%ProgramFilesDirx86%\My Program\unins000.exe
;---falls das Deinstallationsprogramm vorhanden ist, dann springe in die Sektion zu Deinstallation
If DoesFileExist ("%VM_UnInstCMD%") == "1" Then "DoUninstallBeforeInstall" EndIf

[DoUninstallBeforeInstall]
;---führe die Deinstallation durch und warte zur Sicherheit 3 Sekunden
-Call "%VM_UnInstCMD%" /S
Sleep 3000
;---Wurde die Deinstallation erfolgreich durchgeführt und ist die Deinstallationsroutine entfernt worden? Falls nicht, melde einen Fehler.
If DoesFileExist ("%VM_UnInstCMD%") == "1" Then "ErrorOnUninstallBeforeInstall" EndIf

[ErrorOnUninstallBeforeInstall]
ErrorLogMsg %ErrorText% %ErrorLevel% %CallingText% %VM_UnInstCMD%
Abort

Der Beitrag Empirum Setup.inf – Reparatur Unattended Setup erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-setup-inf-reparatur-unattended-setup/feed/ 0
PreOS Paket: MoveComputerToEmpirumOU https://www.wpm-blog.de/movecomputertoempirumou/ https://www.wpm-blog.de/movecomputertoempirumou/#comments Mon, 22 Jul 2019 13:42:07 +0000 https://www.wpm-blog.de/?p=2245 Matrix42 hat mit der Version 1.4 des PreOS Paketes „DomainJoin“ die Funktion hinzugefügt, den Computer beim Domain-Join in eine entsprechende OU zu verschieben. Diese Funktion war in den Vorgängerversionen auch bereits enthalten, wenn das Computer-Objekt … Weiterlesen

Der Beitrag PreOS Paket: MoveComputerToEmpirumOU erschien zuerst auf Workplace Management Blog.

]]>
Matrix42 hat mit der Version 1.4 des PreOS Paketes „DomainJoin“ die Funktion hinzugefügt, den Computer beim Domain-Join in eine entsprechende OU zu verschieben. Diese Funktion war in den Vorgängerversionen auch bereits enthalten, wenn das Computer-Objekt noch nicht in der Domäne enthalten war. War das Computer-Konto bereits in der Domäne vorhanden, so wurde das Computer Konto erneuert und das Computer-Objekt in der OU belassen in der es war. Nun ist es abhängig von der Variable DomainJoin.DomainJoinAuthority. Ist die genannte Variable auf den Wert „AD“ gesetzt, so ist das Verhalten wie zuvor beschrieben. Ist die Variable jedoch auf „Empirum“ gesetzt, wird versucht das Computer-Objekt in die von Empirum per ORGANIZATIONAL_UNIT vorgegebene OU zu verschieben.

„Makel“ DomainJoin 1.4

Das vorhandene Matrix42 PreOS Paket DomainJoin 1.4 hat meiner Meinung jedoch diverse Makel, die das angehängte PreOS Paket besser machen soll.
In Zusammenarbeit mit einem Kollegen und einem Kunden ist somit das angehängte MoveComputerToEmpirumOU PreOS Paket entstanden. Die Makel aus unserer Sicht sind:

  • Für das Verschieben des Computer in eine OU werden die RSAT Tools benötigt bzw. versucht bei Bedarf nachzuladen, was bei den meisten Nutzern zu Problemen führt und einen „Add-WindowsCapability“ Fehler im PXE-Log anzeigt.
  • Wenn das Paket ausgeführt wurde und der Computer nicht verschoben wurde, wird trotzdem die Ziel OU angezeigt.

MoveComputerToEmpirumOU

Das MoveComputerToEmpirumOU ist ein AddOn zum DomainJoin Paket, da wir es als Zugabe sehen und Matrix42 vielleicht zukünftig das eigene Paket überarbeitet.
So ist MoveComputerToEmpirumOU zusätzlich und nach dem DomainJoin (getestet mit Version 1.4) auszuführen.

  • Es benötigt keine RSAT Tools und gibt die am Ende „aktive / resultierende“ OU aus.
  • Das Paket bedient sich den DomainJoin Variablen und kann somit auch bzgl. des „führenden“ Systems (Empirum oder AD) konfiguriert werden.
  • Eine eigene Variable „NotMandatory“ kann gesetzt werden, damit das Paket auch bei einem Fehler oder Misserfolg mit Erfolg beendet wird.

Weitere Informationen können der dem Download beiliegenden ReadMe.txt entnommen werden.

Feedback

Rückmeldung zum Paket ist ausdrücklich erwünscht, um die Funktion/Stabilität weiter zu verbessern. Angedacht ist zusätzlich eine Erweiterung, die Mobile Computer (Notebooks, Tablets,…) in eine noch zu definierende alternative OU verschieben kann.

Download

Empirum WinPE PreOS Paket: MoveComputerToEmpirumOU
MoveComputerToEmpirumOU (698 Downloads )
MD5 Hash der Downloaddatei: 885AD1614EFC476345A8BE1FA95F1A1A08C27AF3

Beispielsausgaben des PXE-Log

DomainJoin Authority: Empirum

[PEAgent] [Windows] Finished execution of wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Active OU: OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Moving the computer succeeded!
[PEAgent] [Windows] Try moving the computer to the defined OU ...
[PEAgent] [Windows] Empirum defined OU : OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Computers current OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] DomainJoin Authority: Empirum
[PEAgent] [Windows] Start to execute wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Finished execution of Matrix42\OsPackages\DomainJoin\1.4 package.
[PEAgent] [Windows] Domain join failed: Fehler bei Add-WindowsCapability". Fehlercode: 0x8024402c, Domain 'wpm-blog.de' and OU 'OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de'"
[PEAgent] [Windows] Start to execute Matrix42\OsPackages\DomainJoin\1.4 package.

DomainJoin Authority: AD

[PEAgent] [Windows] Finished execution of wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Active OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Empirum defined OU : OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Computers current OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] DomainJoin Authority: AD
[PEAgent] [Windows] Start to execute wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Finished execution of Matrix42\OsPackages\DomainJoin\1.4 package.
[PEAgent] [Windows] Domain join (option 33) successful: Domain 'wpm-blog.de' and OU 'OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de'
[PEAgent] [Windows] Start to execute Matrix42\OsPackages\DomainJoin\1.4 package.

Der Beitrag PreOS Paket: MoveComputerToEmpirumOU erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/movecomputertoempirumou/feed/ 7
Empirum: Einfacherer Zugriff auf detaillierte Fehler-Protokolle https://www.wpm-blog.de/einfacherer-zugriff-auf-detaillierte-fehlerprotokolle/ https://www.wpm-blog.de/einfacherer-zugriff-auf-detaillierte-fehlerprotokolle/#comments Sun, 26 Oct 2014 14:54:09 +0000 https://www.wpm-blog.de/?p=1379 Schlägt eine Installation eines Empirum Paketes fehl, so wird dies in der Management Console mit dem Status „Failed“ im SWDepotLog und im Status versehen. Im erweiterten ErrorLog kann man ggf. noch den Fehlercode oder einen … Weiterlesen

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

]]>
Schlägt eine Installation eines Empirum Paketes fehl, so wird dies in der Management Console mit dem Status „Failed“ im SWDepotLog und im Status versehen. Im erweiterten ErrorLog kann man ggf. noch den Fehlercode oder einen kleinen Hinweis auf den möglichen Fehler bekommen. Doch häufig benötigt man den Zugriff auf die komplette Log Datei der Installation. Diese wiederum liegt lokal auf dem Computer. Warum?

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.

Hinweis: Es werden nur *.log Dateien vom EmpirumAgenten automatisch übertragen.

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 geschehenDie 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.

]]>
https://www.wpm-blog.de/einfacherer-zugriff-auf-detaillierte-fehlerprotokolle/feed/ 9
ErrorCodes – Windows Update https://www.wpm-blog.de/errorcodes-windows-update/ https://www.wpm-blog.de/errorcodes-windows-update/#respond Wed, 02 Jul 2014 19:23:30 +0000 https://www.wpm-blog.de/?p=1272 Bei der Installation von Windows Updates mittels Empirum Patch-Management, Microsoft WSUS oder per Paket kann es auch schon mal zu einem Fehler kommen. Die Rückmeldung, ob eine unbeaufsichtigte Installation erfolgreich oder nicht erfolgreich war, kann … Weiterlesen

Der Beitrag ErrorCodes – Windows Update erschien zuerst auf Workplace Management Blog.

]]>
Bei der Installation von Windows Updates mittels Empirum Patch-Management, Microsoft WSUS oder per Paket kann es auch schon mal zu einem Fehler kommen. Die Rückmeldung, ob eine unbeaufsichtigte Installation erfolgreich oder nicht erfolgreich war, kann man entweder über eine direkte Rückmeldung der ausführbaren Datei oder eine zu erstellende Log-Datei bekommen.

ErrorCodes

Die Rückmeldungen von ausführbaren Dateien haben unterschiedliche Bezeichnungen, wie z.B.: ReturnCode, ErrorCode, ErrorLevel, etc. Hier hatte ich bereits einige bekannte Fehler aus dem „DOS“ Umfeld aufgelistet. Jeder ErrorCode für einen vom Entwickler definierten Fehlergrund. Ist kein Fehler aufgetreten, so ist der ErrorCode = 0. Microsoft nutzt z.B. durchweg den ErrorLevel 3010, der bedeutet das diese Installation einen Neustart benötigt. Dieser ReturnCode wird von Microsoft auch bei weiteren Installationsroutinen genutzt. Nun gibt es jedoch noch eine große Liste an weiteren Rückmeldungen. Diese sind zumeist etwas schwieriger heraus zu bekommen.

Nachfolgend zwei Listen, die ich im Internet gefunden habe, mit Hinweisen bzw. Kurzerläuterungen zu diversen ErrorCodes im Windows Update Umfeld:

Der Beitrag ErrorCodes – Windows Update erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/errorcodes-windows-update/feed/ 0
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