none
Task Sequenz bricht ab RRS feed

  • Frage

  • Hallo Zusammen,

    Meine Tasksequenz macht u.a. folgendes:

    1. MSI Paket installieren wenn kein User angemeldet ist
    2. Neustart der WS
    3. Weitere Abarbeitung

    Fährt ein Anwender nach Ausführung der TS (waiting for user condition) seinen Rechner runter oder führt einen Neustart durch, wird zwar Schritt 1 erledigt wenn die Condition zutrifft (z.B. vor dem Login), der Rest wird aber mit folgendem Loghinweis abgebrochen:

    Task sequence failed due to an external shutdown request received during the TS running
    
    Task Sequence Manager could not initialize Task Sequence Engine. code 80004005
    
    Task sequence execution failed with error code 80004005

    Eine Idee zu diesem Verhalten?

    Danke & Gruß

    Matthias

    Montag, 21. Juni 2010 14:10

Antworten

  • Um das Thema abzuschließen: Habe nun die TS so umgebaut dass der Anwender nun selbst die Installation startet und über den bevorstehenden Reboot per Popup benachrichtigt wird. Das funktioniert ganz gut.
    Einziger Nachteil ist nur dass man auf die Anwender angewiesen ist, die noch "Ja, ich will" klicken müssen ;-)

     

     

    • Als Antwort markiert M.Schwarzer Montag, 19. Juli 2010 11:16
    Montag, 19. Juli 2010 11:16

Alle Antworten

  • Hallo Zusammen,

    habe nun noch ziemlich viel rumprobiert, kriege die TS aber nicht zum laufen.

    Im Prinzip habe ich fast das selbe Problem wie Andre Heublein hier schildert: http://social.technet.microsoft.com/Forums/de-DE/systemcenterde/thread/d9a73030-305f-4355-bbde-34f2237e3bb8
    Auch die Logs sind beinahe identisch. Der Hauptunterschied ist jedoch dass der Neustart durch den Benutzer durchgeführt wird und nicht durch eine ungewollte Einstellung erzwungen wird, wie bei Andre.

    Im Detail sieht der Anfang meiner TS nun so aus:

    1.: Ausführen einer kleinen Batch Datei (Condition: wheter user logged on or not)
    2.: Deinstallation eines MSI Pakets (Condition: When no user logged on)
    3.: Neustart durch Paket
    4.: usw...

    Die TS startet normal an und führt Schritt 1 durch. Danach steht die TS auf "Waiting for Condition". Was auch korrekt ist, da unsere Anwender mit der Software, die in Schritt Zwei deinstalliert werden soll, arbeiten während sie angemeldet sind. Nun meldet sich der gewöhnliche Anwender ja nicht nach der Arbeit ab, sondern fährt brav seinen PC runter. Und schon haben wir das Problem, im TS log des Servers sieht man zunächst:

    - The task sequence execution engine performed a system reboot initiated by the action (Deinstallation MSI Paket) in the group ( ).

    - The task sequence manager could not successfully complete execution of the task sequence. A failure exit code of 16389 was returned. The operating system reported error 16389

    Ich bin ein bisschen am Verzweifeln, habe bereits alle möglichen Kombinationen der Condition Einstellungen durch, leider ohne Erfolg.

    Vielleicht mag sich jemand dem trotz der heißen Temparaturen annehmen.

    Danke & Viele Grüße

    Matthias

    Montag, 28. Juni 2010 08:02
  • TS log des Servers sieht man zunächst
    Die Ausführung einer TS auf einem Client wird aber nicht am Server protokolliert (im smsts.log), deshalb ist mir der Zusammenhang nicht klar. Im smsts.log auf dem Server siehst Du nur die TS, die für / auf dem Server ausgeführt worden sind.
    Montag, 28. Juni 2010 09:55
    Beantworter
  • TS log des Servers sieht man zunächst
    Die Ausführung einer TS auf einem Client wird aber nicht am Server protokolliert (im smsts.log), deshalb ist mir der Zusammenhang nicht klar. Im smsts.log auf dem Server siehst Du nur die TS, die für / auf dem Server ausgeführt worden sind.

    Sorry, ich meinte den Report über die TS Ankündigung (Status of a specific Ad.).
    Montag, 28. Juni 2010 11:00
  • Ich hab das genaue Szenario nicht nachgestellt, aber ich schätze, dass es so nicht klappen kann. Die TS startet, wird aber dann vom User durch den Reboot unterbrochen (anstatt durch einen TS-Schritt oder eine TS-variable initiiert).
    • Als Antwort markiert M.Schwarzer Dienstag, 29. Juni 2010 07:23
    • Tag als Antwort aufgehoben M.Schwarzer Dienstag, 29. Juni 2010 07:23
    Dienstag, 29. Juni 2010 06:41
    Beantworter
  • Ich hab das genaue Szenario nicht nachgestellt, aber ich schätze, dass es so nicht klappen kann. Die TS startet, wird aber dann vom User durch den Reboot unterbrochen (anstatt durch einen TS-Schritt oder eine TS-variable initiiert).


    Genauso sieht es aus.
    Bietet der SystemManager keine Möglichkeit so einen User Reebot abzufangen? Wahrscheinlich kann man sowas nur über ein voranstehendes Script lösen, oder? Oder halt durch ein festgelegtes Maintenace Window in dem der User automatisch abgemeldet wird. Sowas halte ich aber aus mehreren Gründen für schwierig durchsetzbar.
    Wie sieht denn zu o.g. Szenario die BestPractise aus? Schätze diese Problemstellung dürften viele Unternehmen haben?

    Vielen Dank im vorraus!

    Matthias

    Dienstag, 29. Juni 2010 07:29
  • Wake on LAN und Updates nachts verteilen. Oder die Logik in's msi legen und den Reboot unterdrücken oder am Ende eine Meldung ausgeben, dass ein Reboot erforderlich wird.
    Dienstag, 29. Juni 2010 21:29
    Beantworter
  • Kann dem nur zustimmen. Wenn Anwendungen über ConfigMgr verteilt werden, und ganz speziell, wenn sie in Task Sequenzen genutzt werden, dürfen diese einen Neustart nicht selbst initiieren. Also beim erstellen (oder ausführen) dafür sorgen, dass die installation alle Neustartversuche unterdrückt und maximal zurückmeldet dass ein Neustartfür den erfolgreichen Abschluss der Installation notwendig ist (z.b. Error Code 3010). Dann in den Einstellungen des Pakets entweder dem ConfigMgr erlauben, dass er einen Neustart durchführen soll wenn notwendig oder explizit in der TS einen Neustart schritt einbauen. (Nicht beides, sonst started er vermutlich zwei mal ;-) )

     

    viele Grüße

    Maik


    http://myitforum.com/cs2/blogs/maikkoster/

    Mittwoch, 30. Juni 2010 06:29
  • Kann dem nur zustimmen. Wenn Anwendungen über ConfigMgr verteilt werden, und ganz speziell, wenn sie in Task Sequenzen genutzt werden, dürfen diese einen Neustart nicht selbst initiieren. Also beim erstellen (oder ausführen) dafür sorgen, dass die installation alle Neustartversuche unterdrückt und maximal zurückmeldet dass ein Neustartfür den erfolgreichen Abschluss der Installation notwendig ist (z.b. Error Code 3010). Dann in den Einstellungen des Pakets entweder dem ConfigMgr erlauben, dass er einen Neustart durchführen soll wenn notwendig oder explizit in der TS einen Neustart schritt einbauen. (Nicht beides, sonst started er vermutlich zwei mal ;-) )

     

    viele Grüße

    Maik


    http://myitforum.com/cs2/blogs/maikkoster/

     


    Wie gesagt, es geht nicht darum dass die Anwendung einen Reboot fordert, das ist kein Problem. Es geht darum dass der Anwender einen Reboot/Shutdown durchführt während die TS läuft und diese dann aus dem Takt kommt.
    Mittwoch, 30. Juni 2010 11:20
  • 2.: Deinstallation eines MSI Pakets (Condition: When no user logged on)
    [...]

    Danach steht die TS auf "Waiting for Condition".

    Das ist der Grund dafür. Die TS wird "ausgebremst", weil sie auf "When no user logged on" wartet und der User vorher ziemlich sicher einen Reboot ausführt. Deshalb die Vorschläge von Maik und mir.
    Mittwoch, 30. Juni 2010 11:29
    Beantworter
  • 2.: Deinstallation eines MSI Pakets (Condition: When no user logged on)
    [...]

    Danach steht die TS auf "Waiting for Condition".

    Das ist der Grund dafür. Die TS wird "ausgebremst", weil sie auf "When no user logged on" wartet und der User vorher ziemlich sicher einen Reboot ausführt. Deshalb die Vorschläge von Maik und mir.


    Hallo Torsten,

    also eine wirkliche Kontrolle, bzw. besser gesagt "unterbindung" dieses Anwender - Reboots gibt es nicht? (Ausser vielleicht per Scripting).
    Trotzdem verstehe ich noch nicht warum die TS mit dem Reboot ein Problem hat, da ja noch kein msiexec, etc. läuft. Interessanterweise führt die TS ja sogar nach dem Reboot den nächsten Schritt auf, und bricht erst dann ab.

     

    Mittwoch, 30. Juni 2010 12:11
  • Interessanterweise führt die TS ja sogar nach dem Reboot den nächsten Schritt auf, und bricht erst dann ab.
    Hab ich nur etwas überlesen? Wo steht denn das bisher? Oben hast Du ja die Schritte 1, 2, 3, 4 usw aufgeführt. Wann wird der Rechner unplanmäßig gebootet und welcher Schritt wird mit welchem Ergebnis (smsts.log / execmgr.log) ausgeführt oder eben nicht mehr ausgeführt?
    Mittwoch, 30. Juni 2010 12:39
    Beantworter
  • Interessanterweise führt die TS ja sogar nach dem Reboot den nächsten Schritt auf, und bricht erst dann ab.
    Hab ich nur etwas überlesen? Wo steht denn das bisher? Oben hast Du ja die Schritte 1, 2, 3, 4 usw aufgeführt. Wann wird der Rechner unplanmäßig gebootet und welcher Schritt wird mit welchem Ergebnis (smsts.log / execmgr.log) ausgeführt oder eben nicht mehr ausgeführt?


    Gleich im ersten Beitrag:
    "Fährt ein Anwender nach Ausführung der TS (waiting for user condition) seinen Rechner runter oder führt einen Neustart durch, wird zwar Schritt 1 erledigt wenn die Condition zutrifft (z.B. vor dem Login), der Rest wird aber mit folgendem Loghinweis abgebrochen"

    D.h. der Rechner wird vom Anwender runtergefahren bevor die TS mit der Deinstallation des MSI Pakets beginnt, da diese darauf wartet dass kein User mehr angemeldet ist.

    Hier nochmal ein execmgr.log-Auszug aus einem Test von eben (startet ab dem Punkt wo das MSI/die TS auf die User Condition wartet und der Anwender seinen PC neu startet.:

    ___________________________________________

    - Succesfully raised SoftDistProgramWaitingForUserEnvironment event for program deinstallation
    
    - Execution Request for package XYZ program deinstallation state change from NotExist to WaitingEnvironment
    
    - The user has logged off.
    
    - CExecutionRequest::Overriding Service Windows as per policy.
    
    - Executing program msiexec.exe /x{GUID} /passive in Admin context
    
    - Execution Manager timer has been fired.
    
    - Execution Request for package XYZ program deinstallation state change from WaitingEnvironment to NotifyExecution
    
    - Executing program as a script
    
    - Successfully prepared command line "C:\WINDOWS\system32\msiexec.exe" /x{GUID} /passive
    
    - Command line = "C:\WINDOWS\system32\msiexec.exe" /x{GUID} /passive, Working Directory = C:\_SMSTaskSequence\Packages\XYZ\
    
    - Created Process for the passed command line
    
    - OnContentAvailable invalid request GUID handle
    
    - Program exit code 1603
    
    - Script for Package:XYZ, Program: deinstallation failed with exit code 1603
    
    - Execution is complete for program deinstallation. The exit code is 1603, the execution status is FailureNonRetry
    
    - Execution Request for package XYZ program deinstallation state change from Running to Completed

    ___________________________________________

    Nach näherer Betrachtung könnte es evtl. etwas mit dem "Execution Event Timer" zu tun haben? Das dieser schon ab dem Runtefahren läuft und so auf einen Timeout läuft? (Obwohl das Neustarten des Client BS ziemlich zügig von statten geht).

    Hier der Auszug der smsts.log:

    ___________________________________________

    - Installing software for PackageID='XYZ' ProgramID='deinstallation' AdvertID='XYZ' has started, jobID='{GUID}'
    
    - Waiting for installation job to complete..
    
    - ServiceCtrlHandler - STOP/SHUTDOWN control request received
    
    - System shutdown request is received during execution of the action (Programm_name)
    
    - Set a global environment variable _SMSTSLastActionRetCode=1115
    
    - Set a global environment variable _SMSTSLastActionSucceeded=false
    
    - Set a global environment variable _SMSTSExternalShutdownRequestReceived=true
    
    - A system reboot request was received when running the instruction (Programm_Name)
    
    - Failed to open to WMI namespace '\\.\ROOT\CIMV2' (80080008)
    
    - Failed to connect to WMI namespace \\.\ROOT\CIMV2 (Code 0x80080008)
    
    - Execution engine result code: 2 (Success=0, Failure=1, RebootInitiated=2)
    
    - Task Sequence Manager ServiceMain finished execution.
    
    - Task Sequence Manager execution terminated as system shutdown is in progress. Code 0x00000000
    .
    .
    .
    - Error getting system isolation info. Code 8027000C
    
    - Remediation failed. Code 8027000C
    
    - Remediation failed with error code 8027000C
    
    - Task sequence failed due to an external shutdown request received during the TS running
    
    - Task Sequence Manager could not initialize Task Sequence Engine. code 80004005
    
    - Task sequence execution failed with error code 80004005
    ___________________________________________
    Mittwoch, 30. Juni 2010 14:07
  • - Executing program as a script
    - Successfully prepared command line "C:\WINDOWS\system32\msiexec.exe" /x{GUID} /passive
    [...]
    - Program exit code 1603
    [...]
    
    - System shutdown request is received during execution of the action (Programm_name)
    - A system reboot request was received when running the instruction (Programm_Name)
    Der User fährt den Rechner runter => Abmeldung => "Condition: When no user logged on" ist erfüllt (direkt vor dem Shutdown), da ja vor dem Herunterfahren der Benutzer abgemeldet wird => Deinstallation startet => Rechner fährt herunter und bricht die (De-)Installation ab. In dem TS-Step ist vermutlich "Continue on error" nicht aktiviert. Wäre zu testen, ob er dann nach dem Reboot den Step nochmal probiert.
    Mittwoch, 30. Juni 2010 15:17
    Beantworter
  • Der User fährt den Rechner runter => Abmeldung => "Condition: When no user logged on" ist erfüllt (direkt vor dem Shutdown), da ja vor dem Herunterfahren der Benutzer abgemeldet wird => Deinstallation startet => Rechner fährt herunter und bricht die (De-)Installation ab. In dem TS-Step ist vermutlich "Continue on error" nicht aktiviert. Wäre zu testen, ob er dann nach dem Reboot den Step nochmal probiert.


    Hallo Torsten,

    Den "Continue on error" Haken habe ich bereits gesetzt und diverse Variationen probiert. Immer das selbe Ergebnis: siehe oben.

    Update: So habe die Schritte gerade nochmal untersucht:
    1. Das Batchfile wird erfolgreich von der TS ausgeführt.
    2. TS wartet auf User Condition zur deinstallation des MSI
    3. User Rebootet seinen PC
    4. MSI wird von der TS nach dem unerwartetem reboot deinstalliert. Im Report erscheint aber trotzdem:
    - The task sequence manager could not successfully complete execution of the task sequence. A failure exit code of 16389 was returned. The operating system reported error 16389:
    Anschließended erscheint im Report aber direkt:
    - Program completed successfully
    5. die nächsten Schritte der TS werden aber nicht mehr ausgeführt. Folgender abschließender Hinweis steht im Report:
    -  Program completed with success 

    Um die Antwort auf die nächste Frage vorwegzunehmen: Die nächsten Schritte der TS sind aktiviert.

     

    Donnerstag, 1. Juli 2010 08:05
  • Um das Thema abzuschließen: Habe nun die TS so umgebaut dass der Anwender nun selbst die Installation startet und über den bevorstehenden Reboot per Popup benachrichtigt wird. Das funktioniert ganz gut.
    Einziger Nachteil ist nur dass man auf die Anwender angewiesen ist, die noch "Ja, ich will" klicken müssen ;-)

     

     

    • Als Antwort markiert M.Schwarzer Montag, 19. Juli 2010 11:16
    Montag, 19. Juli 2010 11:16