Hallo zusammen, ich bräuchte wieder Hilfe weil ich etwas nicht verstehe:
wir haben ein Paket gemacht, das bei DELL-Geräten die Treiber aktualisiert. Dazu wird das DELL Command Update genutzt (genauer die dcu.cli.exe).
Mein Problem ist das das Paket grds. schon richtig läuft aber in vielen Fällen keine Schlüssel in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\neoPackages{042048C1-C614-4BAB-88CD-xxxxxxxxxxx} schreibt.
Tests haben ergeben dass es wohl an der Fehlerbehandlung in dem Powershell-Skript „Deploy-Application.ps1“ liegt.
Immer wenn das Paket auf Fehler läuft werden die Reg-Schlüssel nicht erzeugt und das Empirum-Paket bricht mit der Fehlermeldung „Installation fehlgeschlagen. PowerShell möglicherweise über Unternehmens-Richtlinie blockiert.“ ab. So wie ich das lese geschieht das immer wenn die oben genannten Reg-Schlüssel nicht geschrieben werden, weil davon ausgegangen wird dass Powershell durch (z.B.) AppLocker unterbunden wird. Das ist aber nicht der Fall, weil wir das Powershell-Skript „Deploy-Application.ps1“ in der ISE laufen lassen und es mit dem Fehler 5 (es stehen keine Aufgaben an) abbricht.
Wir haben hier auch mal einen DOS-Befehl eingebaut der in jedem Fall ausgeführt wird. Sobald wir den Aufruf der dcu-cli.exe auskommentieiren und nur der DOS-Befehl läuft klappt alles einwandfrei. Wenn das Powershell-Skript „Deploy-Application.ps1“ abläuft und neue Treiber installiert geht auch alles, nur wenn es auf einen Fehler läuft, werden keine Reg-Schlüssel erzeugt.
Kennt das jemand und kann mir sagen, wie ich das Problem umschiffe? Ich brauche die Reg-Schlüssel um den Fehlercode abzufragen und in der Setup.inf weiter zu behandeln.
Das Verhalten ist so korrekt:
Fehler 5 des dcu-cli.exe bedeutet: Nach einem vorherigen Vorgang stand ein Neustart aus
D.h. das Script erwartet für ein erfolgreichen Abschluss des standardmässig eingetragenen InstFile immer einen Returncode 0 vom ausgeführten Installer. Das kann man korrigieren, in dem man in der neo42PackageConfig.json in AcceptedInstallRebootCodes die 5 mit hinterlegt.
danke für die Info, dann müsste ich ja im Empirum-Log den Fehler-Code sehen und nicht die Meldung „Installation fehlgeschlagen. PowerShell möglicherweise über Unternehmens-Richtlinie blockiert.“. Beim Debuggen im Matrix42 Package Editor kann ich nachvollziehen dass das Paket abbricht weil es in diese Prüfung läuft und dann stoppt:
If DoesRegKeyExist („%RegPackageKey%“) == „0“ & DoesRegKeyExist („%RegPackageKeyError%“) == „0“ Then „Set:ErrorPowerShellExecuteBlocked“ EndIf
Wir haben den Fehler-Code auch schon gefunden und auch bei den „AcceptedInstallRebootCodes“ eingetragen, wie übrigens auch den Fehler 500 (es stehen keine weiteren Vorgänge aus) bei den „AcceptedInstallExitCodes“
Leider ist das aber nicht alleine das Problem, auch z.B. beim Fehler 3 (Der aktuelle Systemhersteller ist nicht Dell) bricht das Paket ab und es werden die Reg-Schlüssel nicht erzeugt.
Für mich schaut es so aus als ob jeder Fehler dazu führt dass das Powershell-Skript den zwar anzeigt aber danach sofort abbricht. Ich verstehe das so dass dann die entsprechenden Reg-Schlüssel nicht gesetzt werden.
Ok, das Problem liegt an der Umsetzung des Paketes!
In der neo42PackageConfig.json ist als InstFile die dcu-cli.exe eingetragen und als Wert für IntallMethod ist Setup oder dergleichen hinterlegt? D.h. es wird der Paketstandardablauf wird hier ausgeführt … aber das Tool wird hier lediglich ausgeführt und es erfolgt dadurch ja keine Installation!
Hintergrund: Die Standard-Paketroutinen (außer ‚NONE‘) benötigen für die De-/Installationsprüfung immer zwingend einen hinterlegten Eintrag für UninstallKey, der in dem Fall aber nicht möglich wäre (außer man bereitet selbst etwas individuelles vor).
Die InstallMethod muss in dem Fall also auf None gestellt werden und die Ausführung des Tools muss per manuellem Aufruf im Code erfolgen!
… grundsätzlich soll ja nur eine Toolausführung mit der Paketausführung erfolgen, eine Deinstallationsaktion ist auch nicht erforderlich.
Die Ausführung des Tools legt man dann z.B. in die letzte ausgeführte Installations-CustomFunction „CustomInstallAndReinstallAndSoftMigrationEnd“ und hier kann im Nachgang auch eine entsprechende Fehlerbehandlung durchgeführt werden (z.B. zusätzliche Logging-Informationen für bestimmte Ergebnisse und/oder geordneter Ausstieg für bestimmte Fehler) - hier beispielhaft:
[int]$returnCode = (Execute-Process -Path "$dirFiles\dcu-client.exe" -Parameters "/S" -ExitOnProcessFailure $false -PassThru).ExitCode
switch ($returnCode) {
0 {
## on success
}
1 {
## all (other) error cases
Write-Log -Message "[Dell Command | Update] requires a reboot." -Severity 2 -Source $deployAppScriptFriendlyName
$global:PackageConfig.Reboot = 1
}
2 {
## reboot required
Exit-NxtscriptWithError -ErrorMessage "ERROR: An unknown application error has occurred. Abort!" -MainExitCode $returnCode
}
3 {
## wrong manufacturer
Exit-NxtscriptWithError -ErrorMessage "ERROR: The current system manufacturer is not Dell. Dell Command | Update can only be run on Dell systems. Abort!" -MainExitCode $returnCode
}
}
Eine Festlegung für AcceptedInstallExitCodes und/oder AcceptedInstallRebootCodes erübrigt sich damit ebenso (kann also leer bleiben)!
guten Morgen @RKH.neo42,
vielen Dank für den Hinweis, den Eintrag „ReinstallMode“ von „ReInstall“, auf „Install“, umzustellen war die Lösung, jetzt läuft alles.
. Ich arbeite das Paket um und teste es. Vorab schon mal ein schönes Wochenende.