Wie können wir darauf in der Softwareverteilung bzw. der Paketierung darauf reagieren?
Wie kann ich das in der Matrix42 Empirum Setup.inf handhaben?

Die harte Methode

Wenn also ein geöffnetes Programm stört, dann beenden wir es halt vor der Installation. Nehmen wir für die nächsten Beispiele an, es geht um Microsoft Visio. Man kann das in Windows enthaltene Tool TaskKill.exe nutzen und damit den Prozess beenden. In der Empirum Setup.inf würde der Befehl grob wie folgt ausschauen:
Callhidden TaskKill.exe /IM visio.exe /F
Es gibt jedoch auch einen Setup.inf eigenen Befehl:
Killprocess visio.exe
Beide haben gemeinsam, sie beenden sofort den laufenden Prozess und gehen in der Installationsabfolge weiter. Was aber, wenn der Benutzer gerade die letzten Minuten oder Stunden Änderungen in seinem Visio-Diagramm vorgenommen hat? Diese Änderungen „darf“ der Benutzer höchstwahrscheinlich mit der neuen Visio Version erneut durchführen.

Sanftere Methoden

Die sanftere Methode ist, mit dem Benutzer zu interagieren. Dies geht in der Empirum Setup.inf über den Befehl AsKillProcesses und der dazugehörigen [Processes] Sektion. In der [Processes] Sektion wird konfiguriert, bei welchem Prozess, welcher Name in der GUI angezeigt wird und wie nach dem Ablauf des Timeouts (des AskKillProcesses  Befehls) verfahren werden soll. Während des TimeOut’s hat der Benutzer die Möglichkeit die Anwendung selbsttätig zu schließen. Die Installation wird direkt nach dem Schließen durch den Anwender fortgesetzt. Reagiert der Benutzer während der Timeout Zeit nicht auf den angezeigten Dialog zum Schließen der Anwendung, bestimmt der Parameter CONTINUE oder ABORT, ob das Paket „Abgebrochen“ wird, oder die Installation fortgesetzt wird. Bei einem Abbruch wird dies auch mit der entsprechenden Meldung in der Management Console signalisiert.

[Processes]
;---beenden des Processes visio.exe nach dem Timeout (hier 300) und mit der Installation voranschreiten
VisioProc=visio.exe, Microsoft Visio, KILLPROCESS CONTINUE
;---Alternativ: KEIN beenden des Processes visio.exe nach dem Timeout (hier 300) und Abbrechen der Installation
;VisioProc=visio.exe, Microsoft Visio, KILLPROCESS ABORT

[CheckOpenProcesses]
AskKillProcesses 300, VisioProc
-AskKillProcesses 300, VisioProc

[Product]
#CheckOpenProcesses, DONTDELETE
...
#CheckOpenProcesses, DELETE

Weitere Hilfe

Man kann auch auf einen Fenstertitel reagieren und anschließend das entsprechende Fenster schließen, etc. Dies ist in der Empirum Online Hilfe ausgiebig erläutert.

Der Beitrag Dialog zum Schließen von Programmen erschien zuerst auf Workplace Management Blog.

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

Welche Datei meine ich denn nun genau?

Es geht um die Unattended.inf im Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates Ordner. Diese wird bei der Auswahl „Unattended“ im Verlaufe des „Package Wizards“ herangezogen.

Erfolgsüberprüfung

Nach dem „silent“ Aufruf einer EXE Datei, wird eine, wie ich sie nenne, „Erfolgsüberprüfung“ durchgeführt. Denn jede Setup.inf, die nicht mit einem „Abort“ beendet wird, wird per se als Erfolg gewertet. Sprich, wir sollten nach dem Aufruf eines externen Programms (Setup.exe, Installer, etc.) überprüfen, ob eingetroffen ist, was wir erwarten würden. Andernfalls, kann ein Paket ein „Success“ zurückmelden und die Software ist nicht installiert.

ErrorLevel Abfrage in der Vorlage

Die oben angesprochene Setup.inf Vorlage prüft deswegen nach einem Aufruf einer Installation den ErrorLevel ab. Weit verbreitet ist ein ErrorLevel mit dem Wert 0 ein Erfolg. Deswegen enthält die Vorlage auch die nachfolgende Zeile:

If "%ErrorLevel%" <> "0" Then "SET:InstallationError" EndIf

Doch was passiert, wenn die Installation z.B. einen Wert von 3010 zurückliefert? Ist dann ein Fehler aufgetreten? Nein. Der Wert 3010 bedeutet beispielsweise, die Installation war erfolgreich, doch es wird zusätzlich ein Neustart benötigt. Microsoft hat es mit den MSI Installern begonnen und einige haben diese Werte übernommen oder rufen in ihrer EXE Datei eine MSI Installation auf und geben den ErrorLevel der MSI Installation zurück.

Anpassung

Diese Anpassung setzt automatisch eine Neustart-Anforderung für dieses Paket und wertet den Rückgabewert von 3010 nicht als Fehler.

If "%ErrorLevel%" == "3010" Then "RebootRequired" EndIf
If "%ErrorLevel%" <> "0" & "%ErrorLevel%" <> "3010" Then "SET:InstallationError" EndIf

[RebootRequired]
SetReboot 1
-SetReboot 1

Wer noch weiter gehen möchte, für z.B. VCRedist Installationen oder Updates, der kann zusätzlich noch den Wert 1638 (Another version of this product is already installed) überprüfen.

ErrorLevel oder gibt es auch andere Methoden

Der ErrorLevel ist nicht die einzig wahre Methode. Natürlich kannst Du auch überprüfen, ob es einen bestimmten Registry Wert nach der Installation gibt, den es zuvor nicht gibt. Eine Überprüfung, ob die Software in Form ihrer ausführbaren Date vorhanden ist, kann genauso gut sein. Zu diesen Abfragen kommen wir dann bei den nächsten Tipps. Falls Du bereits Neugierig bist, so kannst Du in der Hilfe nach DoesRegKeyExist oder DoesFileExists suchen. Die DoesRegKeyExist Abfrage ist auch in der MSI.inf (Vorlage für MSI Installationen) enthalten ;-).

Der Beitrag ErrorLevel Abfrage bei Unattended Installationen erschien zuerst auf Workplace Management Blog.

MS14-049

Microsoft hat im Oktober 2014 einen Patch unter der Bulletin ID MS14-049 veröffentlicht. Dieser Patch schließt eine Lücke im Windows Installer Dienst: „Vulnerability in Windows Installer Service Could Allow Elevation of Privilege“. Damit einhergehend werden für MSI Installationen neue Hash Werte ermittelt bzw. erstellt. Dies führt bei einer Reinstallation einer bereits installierten MSI Installation zu Problemen.

Mögliche Abhilfen

Whitelisting der Installation

Microsoft hat direkt Methoden zur Erstellung von Whitelist Einträgen, pro getätigter MSI Installation die repariert werden soll, angeboten. Bei dem Einsatz einer Softwareverteilung und einer Fülle an getätigter Software Installationen bereitet das keinen Spaß.
Die Informationen dazu wurden hier veröffentlicht.

Patch zur Behebung des UAC Problems

Im November wiederum wurde dann ein Hotfix veröffentlicht, der mit Hilfe eines Registry Keys generell die UAC Meldungen bei einem nicht vorhandenen MSI Hash Wert unterbinden soll.
Dieser Hotfix samt Vorgehensweise ist hier veröffentlicht.

Die Vorgehensweise mit dem nachgelagerten Hotfix scheint eine sinnvolle Behebung bzw. Umgehung der Problematik zu sein. Doch auch diese Umgehung scheint nach Rückmeldungen nicht zu 100% zu funktionieren.

Deinstallation des MS14-049

Letztendlich bleibt einem bei allen oben getroffenen Maßnahmen und keinem Erfolg (UAC Meldung erscheint trotz aller Maßnahmen) nur noch die Deinstallation des Patches.
Dies wiederum kann auch per Empirum geschehen. Dazu habe ich unten eine beispielhafte Deinstallationsroutine angehängt.

Ich drücke Euch die Daumen!

[Product]
#CheckWUSA, DONTDELETE
#Set:Product, DONTDELETE

[CheckWUSA]
Set VM_WUSA=%HKLM,"SYSTEM\CurrentControlSet\Services\wuauserv","Start"%
If "%VM_WUSA%" == "4" Then "EnableWUSA" EndIf

[EnableWUSA]
CallHidden sc config "wuauserv" start= demand error= ignore

[Set:Product]
SET QFE=2918614
Addmeter -1
DEL "%TEMP%\qfe.txt"
Callhidden %comspec% /C ECHO %sysdate% %systime% - Searching for installed hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C wmic.exe qfe >"%TEMP%\qfe.txt"
If DoesTextInFileExist ("%QFE%", "%TEMP%\qfe.txt") == "1" Then "UninstallQFE" ELSE "QFEnotExist" EndIf

[UninstallQFE]
Callhidden %comspec% /C ECHO %sysdate% %systime% - Installed hotfix found: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C ECHO %sysdate% %systime% - Uninstall hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
CallHidden sc config "wuauserv" start= demand error= ignore
Callhidden wusa /uninstall /kb:%QFE% /quiet /norestart
Set WusaError=%ErrorLevel%
IF %wusaError% == "3010" Then "RebootRequired" EndIf
Callhidden %comspec% /C ECHO %sysdate% %systime% - ErrorLevel: %WusaError% >>"%WINDIR%\TEMP\qfe_uninstall.log"
Callhidden %comspec% /C wmic.exe qfe >"%TEMP%\qfe.txt"
If DoesTextInFileExist ("%QFE%", "%TEMP%\qfe.txt") == "1" Then "SET:InstallationError" EndIf
Callhidden %comspec% /C ECHO %sysdate% %systime% - Successfully uninstalled hotfix: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"
DEL "%TEMP%\qfe.txt"

[QFEnotExist]
Callhidden %comspec% /C ECHO %sysdate% %systime% - The following hotfix is not installed: %qfe% >>"%WINDIR%\TEMP\qfe_uninstall.log"

[RebootRequired]
SetReboot 1

[SET:InstallationError]
Callhidden %comspec% /C ECHO %sysdate% %systime% - Failed uninstall hotfix: %qfe% >>"%WINDIR%\TEM\qfe_uninstall.log"
ErrorLogMsg %ErrorText% %WusaError% %CallingText% wusa /uninstall /kb:%QFE% /quiet
Abort

Setup.inf Beispiel zur Hotfix Deinstallation als Datei: MSHotfix_Uninstall (955 Downloads )

Der Beitrag UAC Meldungen bei der Reinstallation von MSI Paketen 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.

• EXIT – das Skript wird vorzeitig verlassen und die Installation wird als Erfolg gewertet. Reboot Anforderungen werden verarbeitet.
• ABORT – das Skript wird vorzeitig verlassen und die Installation wird als Fehler gewertet. In der Management-Console ist der Status „FAILURE“ (Fehler aufgetreten). Das bedeutet, dass das Paket am Client immer wieder ausgeführt wird. Das wiederholte Ausführen wird ggf. durch die maximale Fehleranzahl, die der Agent (ab Empirum v15) zulässt, eingegrenzt. Wird ein Paket mit einem ABORT verlassen, werden Reboot (Reboot= bzw. SetReboot) Anforderungen des Skriptes an den Agenten verworfen!
• ABORTSILENT – das Skript wird vorzeitig verlassen und die Installation wird auf dem Client als Fehler gewertet. In der Management-Console ist der Status wiederum „SUCCESS“ (erfolgreich). Das bedeutet, dass das Paket am Client immer wieder ausgeführt wird. Das wiederholte Ausführen wird ggf. durch die maximale Fehleranzahl, die der Agent (ab Empirum v15) zulässt, eingegrenzt. Wird ein Paket mit einem ABORTSILENT verlassen, werden Reboot (Reboot= bzw. SetReboot) Anforderungen des Skriptes an den Agenten verworfen!
• ABORTREBOOT – das Skript wird vorzeitig verlassen und die Installation wird auf dem Client als Fehler gewertet. In der Management-Console ist der Status „Reboot Pending“ (Neustart ausstehend). Die Installation des Paketes wird nach dem durchgeführten Neustart erneut gestartet. Die Reboot Anweisungen werden somit nicht verworfen!

Welchen Befehl nutzt man nun wann?
Der Abort wird gerne genutzt, wenn die Überprüfung einer extern aufgerufenen Installation (MSI, Unatteded) überprüft wird und die Überprüfung auf den erwarteten Erfolg nicht erfüllt ist.
Dies kann man sich in den Paketvorlagen MSI.inf und Unattended.inf ansehen.

Den EXIT Befehl kann man zum Beispiel nutzen, wenn man ein Paket vorzeitig beendet möchte, weil die Installation der Software ggf. bereits außerhalb von Empirum erfolgt ist.

Der AbortSilent wird genutzt, wenn ein Paket ggf. mehrmals aufgerufen werden muss, damit die eigentliche Installation der Software erfolgreich ist. Ein anderer Anwendungsfall ist zum Beispiel einen Benutzerteil o.ä. vorzeitig zu verlassen, weil die Voraussetzung (Programm noch nicht gestartet, …) noch nicht vorhanden ist.

Der AbortReboot wird ähnlich wie der AbortSilent eingesetzt, lässt jedoch auch zu das eine Reboot Anforderung nicht verworfen wird. Wenn zum Beispiel eine erfolgreiche Installation zuerst eine weitere Software Installation/Deinstallation und einen Neustart erfordert, muss man das Paket zwischenzeitlich mit einem AbortReboot verlassen. Nach dem Neustart wird dann das Paket nochmals ausgeführt und die ggf. zuvor fehlenden Voraussetzungen für eine erfolgreiche Installation sind nun erfüllt.

Der Beitrag Empirum Setup.inf Skript vorzeitig verlassen erschien zuerst auf Workplace Management Blog.

Aufruf und Ergebnis

Wie nutzt man nun das Tool während der Softwareverteilung? Dazu ruft man die GetPowerState.exe auf und prüft anschließend die Registry. Die GetPowerState.exe speichert das Ergebnis unter „HKLM\SOFTWARE\matrix42\ClientInfo\PowerState“. Hier werden die Eigenschaften „PowerState“ und „BatteryState“ gespeichert.

• PowerState kann die Werte „Battery“ (Batteriebetrieb) oder „AC“ (Netzbetrieb) annehmen.
• BatteryState enthält den prozentualen Ladezustand der Batterie.

Im Empirum Paket kann dies in der Setup.inf wie folgt abgeprüft werden:

CALLHIDDEN "%SRC%\GetPowerState.exe"
IF %HKLM,Software\Matrix42\ClientInfo\PowerState,PowerState% <> "AC" THEN "ErrorHandling" EndIf

[ErrorHandling]
ErrorLogMsg "Computer is on battery. Exiting Script! | Computer ist nicht am Stromnetz angeschlossen. Script wird beendet!" 
AbortSilent

GetPowerState.exe gibt es hier zum Download:
GetPowerState (1124 Downloads )
MD5 Hash der Downloaddatei: D74C4B71639872DABA45C844584F609D38CE427C

Der Beitrag HowTo: Akku oder Netzbetrieb unterscheiden erschien zuerst auf Workplace Management Blog.

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.

Die hier beschriebene Methode kann natürlich auch im Maschinenteil zur Anpassung von HKEY_LOCAL_MACHINE Einträgen genutzt werden. Dazu müssen jedoch Anpassungen vorgenommen werden.

[Set:Product]
#Set:User, CLIENT

[Set:User]
Set HKCURegTree = HKEY_CURRENT_USER\Software\Hersteller
Set HKCURegFile = "%TEMP%\hkcu.reg"
Set SearchString = "Alt"
Set ReplaceString = "Neu"
CALLHIDDEN regedit.exe /E %HKCURegFile% %HKCURegTree%
ReplaceTextFile (%HKCURegFile%, %SearchString%, %ReplaceString%, 0)
CALLHIDDEN regedit.exe /S %HKCURegFile%
If %ErrorLevel%<>0 Then Set:CUError EndIf
Del %HKCURegFile%

[Set:CUError]
ErrorLogMsg Error: %ErrorLevel% : Error changing Registry
Abort

Der Beitrag Suchen und Ersetzen in der Registry erschien zuerst auf Workplace Management Blog.