Seite 1 von 1

Client Command Erstellung: Häufige Stolpersteine

Verfasst: Mo Apr 20, 2015 1:56 pm
von ngottschalk
Sie möchten ein Client Command erstellen und wissen genau, wie das Ergebnis aussehen soll, jedoch möchte das Ergebnis nicht so funktionieren, wie Sie es sich wünschen? Hier finden Sie die häufigsten Stolpersteine erklärt und wie Sie diese überwinden können.
  • "Mein Client Command funktioniert nicht und ich bekomme auch keine Ausführungsprotokolle"
    Dies ist eine Aussage, die häufig an unseren Support herangetragen wird, jedoch nicht selten dadurch hervorgerufen wird, dass die Ergebnisse lokaler Tests nicht genauer betrachtet wurden;
    In den meisten Fällen funktionieren die Client Commands korrekt, jedoch wird die Ausführung nie beendet. Da unser Agent ein Ausführungsprotokoll jedoch erst nach Ende der Client Command Ausführung an den Server schickt, wird hierfür auch kein entsprechender Eintrag in den Client Details erstellt.
    Erkennbar sind solche Situationen daran, dass das aufgerufene Programm (z.B. eine "Setup.exe", ein zusätzlicher "msiexec.exe"-Prozess im Falle von (eingebetteten) MSI-Dateien), auf dessen Beendigung für den weiteren Ablauf des Client Commands gewartet werden muss, im Taskmanager weiterhin aufgelistet wird.
    Hervorgerufen wird dieses Verhalten für gewöhnlich durch eine inkorrekte Parametrisierung des Aufrufs oder Inkompatibilitäten des Installers zu Verteilungsmechanismen, die im Systemkontext agieren (z.B. wie bei Microsoft's SCCM), sodass Fehlermeldungen oder andere Oberflächen zur Fortsetzung des Ablaufs auf Benutzereingaben warten.
    Um diesen Fehler zu beheben, muss zunächst die genaue Fehlerursache ermittelt werden; Hierfür sollte zu Beginn geprüft werden, ob tatsächlich eine Ausgabe stattfindet. Da der ACMP Agent Installationen für gewöhnlich im Kontext des lokalen Systemaccounts ausführt, werden solche Ausgaben jedoch standardmäßig nichtmehr an Benutzer weitergeleitet, wie es noch z.B. unter Windows XP der Fall war (Vgl. http://blogs.technet.com/b/askperf/arch ... ation.aspx), weshalb der Dienst "Erkennung interaktiver Dienste" ("UI0Detect") vor dem Test gestartet werden sollte; Mit diesem ist es möglich, auf den sog. "Secure Desktop" zu wechseln und Ausgaben des Systemkontos anzeigen zu lassen, eine entsprechende Meldung sieht z.B. wie folgt aus (in diesem Fall steht ein offenes CMD-Fenster auf dem System-Desktop):
    Bild
    Der Start dieses Dienstes scheitert in vielen Fällen jedoch ab Windows 8 mit der Fehlermeldung "Ungültiger Parameter" o.Ä.; In diesem Fall reicht es häufig bereits, den Registrierungswert "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\NoInteractiveServices" auf "0" zu setzen.
    Sollte diese Ausführung keine Oberfläche erzeugen, auf die gewartet wird, handelt es sich meistens um tiefgehendere Fehler des Installers, sodass als Nächstes Logdateien des Installers angefertig und ausgewertet werden müssen; Da sich das Vorgehen hierzu jedoch von Installer zu Installer unterscheidet, kann hierfür leider kein allgemeingültiger Weg dargelegt werden. ACMP bietet jedoch eine integrierte Erkennung der häufigsten Installer und kann bekannte Parameter (u.A. zum Schreiben von Logs) für diese auflisten:
    Bild
  • "Mein Client Command funktioniert, jedoch scheint Nichts installiert zu werden"
    Auch dieser Fall wird häufig an unseren Support getragen, vorrangig in Verbindung mit MSI- oder InstallShield-Installationen, die intern ein MSI installieren; Grund hierfür ist in den meisten Fällen, dass aufgrund der Ausführung im Systemkontext "Features" der Windows Installer Installation nicht ausgewählt werden oder an anderen Stellen installiert werden; Bei dieser Problemstellung sollte ein Log des Windows Installers angelegt werden, da dies die wichtigsten Informationen bereithält. Um dies zu erreichen, müssen Sie den Parameter "/l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <Protokolldatei>" an den "msiexec"-Prozess übergeben;
    Bild
    Das von ACMP verwendete Command "Install MSI package" bietet bereits entsprechende Optionen, um eine Logdatei anzulegen, für InstallShield-basierte Installer kann der Parameter "/v" verwendet werden, um nachfolgende Parameter an das eingebettete MSI weiterzugeben. Anhand dieser Logdatei ist es anschließend möglich, z.B. Unterschiede in der Ausführung als Benutzer und im Systemkontext zu erkennen, sodass Ursachen hierfür ggf. beseitigt werden können. Zusätzlich können Sie Tools wie "WiLogUtl" (s. https://msdn.microsoft.com/en-us/librar ... 85%29.aspx) bei der Auswertung von Windows Installer Logs unterstützen.
  • "Bei lokalen Tests funktioniert der Aufruf XYZ, jedoch nicht innerhalb eines Client Commands"
    Häufig gehen Anwender davon aus, dass ACMP nicht korrekt funktioniert, da lokal durchgeführte Tests ein korrektes Ergebnis liefern, bei einer Ausführung via AMCP jedoch Probleme auftreten oder unerwartete Ergebnisse zurückgeliefert werden; Hierfür kann es, neben dem bereits im Vorfeld dargelegten Ausführungskontext als System, einen weiteren Grund geben: Bei ACMP handelt es sich um einen 32bit-Prozess; Hierdurch stellt sich unter 64bit-Betriebssystemen die Umgebung eines Prozesses anders dar, als z.B. in einer lokal aufgerufenen Kommandozeile, da für die Ausführung "WOW64" ("Windows-On-Windows 64-bit", ein Subsystem zur Ausführung von 32bit-Prozessen unter 64bit-Umgebungen) genutzt wird, was gelegentlich zu Problemen führen kann. Anbei als Beispiel die Umgebung eines "normalen" Benutzers und die Standardumgebung von ACMP-Prozessen:

    "normaler" Benutzerkontext:

    Code: Alles auswählen

    ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\ngottschalk\AppData\Roaming CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=2-NGOTCLT-W7X64 ComSpec=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Users\ngottschalk LOCALAPPDATA=C:\Users\ngottschalk\AppData\Local LOGONSERVER=\\XXX NUMBER_OF_PROCESSORS=2 OS=Windows_NT Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\ PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=3a09 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=$P$G PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public SESSIONNAME=Console SystemDrive=C: SystemRoot=C:\Windows TEMP=C:\Users\NGOTTS~1\AppData\Local\Temp TMP=C:\Users\NGOTTS~1\AppData\Local\Temp USERDNSDOMAIN=QS.LOCAL USERDOMAIN=QS USERNAME=ngottschalk USERPROFILE=C:\Users\ngottschalk windir=C:\Windows windows_tracing_flags=3 windows_tracing_logfile=C:\BVTBin\Tests\installpackage\csilogfile.log
    ACMP-Kontext:

    Code: Alles auswählen

    ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Windows\system32\config\systemprofile\AppData\Roaming CommonProgramFiles=C:\Program Files (x86)\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=2-NGOTCLT-W7X64 ComSpec=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO LOCALAPPDATA=C:\Windows\system32\config\systemprofile\AppData\Local NUMBER_OF_PROCESSORS=2 OS=Windows_NT Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\; PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=x86 PROCESSOR_ARCHITEW6432=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=3a09 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files (x86) ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=$P$G PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public SystemDrive=C: SystemRoot=C:\Windows TEMP=C:\Windows\TEMP TMP=C:\Windows\TEMP USERDOMAIN=QS USERNAME=2-NGOTCLT-W7X64$ USERPROFILE=C:\Windows\system32\config\systemprofile windir=C:\Windows windows_tracing_flags=3 windows_tracing_logfile=C:\BVTBin\Tests\installpackage\csilogfile.log
    Man erkennt hierbei vorallem den Unterschied in der "Bittigkeit" der Umgebungen (Vgl. %ProgramFiles%) und des Kontexts (Vgl. %AppData%), was vorallem bei älteren Installationsroutinen zu Problemen führen kann (u.A. da "C:\Windows\system32\config\systemprofile\" durch die UAC anders behandelt wird als gewöhnliche Benutzerpfade).
  • "Wie behebe ich Probleme, die sich aufgrund der 32bit-Umgebung äußern?"
    Um Probleme zu umgehen, die mit einer Ausführung aus dem nicht nativen Kontext einhergehen, stellt Microsoft das "SysNative"-Alias auf 64bit-Systemen zur Verfügung (Vgl. https://msdn.microsoft.com/de-de/librar ... 84187.aspx), durch dessen Nutzung die Umleitung auf das 32bit-Subsystem umgangen und das native Pendant verwendet wird (z.B. würde ein Aufruf von "%WINDIR%SysNative\cmd.exe" via ACMP die "cmd.exe" aus "C:\Windows\System32" aufrufen, also den 64bit-Kommandozeileninterpreter).
    Bitte beachten Sie, dass unter 64bit-Systemen die nativen Binaries unter "System32" und die 32bit-Binaries unter "SysWOW64" aufzufinden sind.
  • "Wie umgehe ich Probleme, die sich aufgrund des Systemkontexts äußern?"
    Um solche Probleme zu umgehen, stellt ACMP 2 Möglichkeiten zur Verfügung:
    1. Die Ausführung als angemeldeter Benutzer:
    Bild
    Die Ausführung als Benutzer nutzt die aktuelle Benutzerumgebung zur Ausführung, womit jedoch auch Besonderheiten einhergehen:
    - Sollte kein Benutzer zum Zeitpunkt der Ausführung am System angemeldet sein, kann das Programm nicht aufgerufen werden
    - Der Aufruf verfügt über die gleichen Berechtigungen wie der angemeldete Benutzer
    - Ausgaben finden auf dem Benutzerdesktop statt

    2. Die Ausführung als spezifischer Benutzer:
    Bild
    Die Ausführung mit einem spezifischen Benutzeraccount stellt einen Mittelweg dar, da für diese kein Benutzer angemeldet sein muss, aber der Prozess nicht im Systemkontext gestartet wird (obwohl die Umgebung weiterhin mit der des Systemaccounts vergleichbar ist). Dies ist häufig hilfreich, sollte das Dienstkonto nicht über die entsprechenden Berechtigungen verfügen (z.B. "SeImpersonatePrivilege").
  • Wie kann ich vorgehen, um meine Aufrufe in einer ACMP-ähnlichen Umgebung zu testen?
    Um diese Besonderheiten bei einer Paketerstellung zu berücksichtigen bietet es sich an, ein entsprechendes Client Command zu nutzen, das die Umgebung des ACMP Agents simuliert. Nachfolgend können Sie ein Beispiel herunterladen, das die entsprechenden Schritte durchführt und unter Windows 7/8.1 funktionieren sollte. Bitte beachten Sie, dass es sich hierbei nur um ein Beispiel handelt und unser Support die Nutzung dessen nicht unterstützt.
    ACMP-Kommandozeile__{5EA0996F-A353-405E-821D-B5F486EEC790}.sim
    Command zum Wechsel in den ACMP Kontext
    (4.41 KiB) 78-mal heruntergeladen
  • Ich stoße weiterhin auf unerklärliche Probleme, welche Informationen benötigt der Support?
    Damit Ihnen unser Support möglichst schnell bei Problemen helfen kann, sollten möglichst neben Informationen zur Software (Name, Version) und Debug-Logs vom Agent (Vgl. https://www.aagon.de/handbuch/acmp/de/5 ... alyser.htm) vorallem als "*.alf" exportierte Client Command Protokolle bereitgestellt werden (Vgl. https://www.aagon.de/handbuch/acmp/de/5 ... viewer.htm), da Screenshots von Ausschnitten häufig nicht die für den Support wichtigen Informationen beinhalten.
Bitte haben Sie Verständnis, dass unser Support, obwohl er natürlich über entsprechende Resourcen verfügt, keinen Support für Installer fremder Hersteller übernehmen kann. Sollten Sie also auch mit Hilfe der zuvor genannten Möglichkeiten keine Lösung für Ihr Problem gefunden haben, wenden Sie sich bitte zunächst an den Hersteller des Setups, sofern der Aufruf durch ACMP erwartungsgemäß stattfindet. Für Probleme beim Versenden von Aufträgen an den ACMP Agent, Fehlverhalten innerhalb des Client Command Ablaufs etc. steht Ihnen unser Support jedoch natürlich gerne zur Verfügung.