/build/static/layout/Breadcrumb_cap_w.png

Task Chains: Agent trying to run next step while system is in the process of shutting down or starting up, causing script to fail?

Greetings,


I've ran into some issues with task chains which I'm hoping that I could find a more eloquent solution for then what I currently have implemented.


The issues are specifically when there is a restart as part of a task chain and occur during the shutdown or startup process.


Based upon suggestions from other threads, I've tried to add shutdown.exe -r -f -t 5 at the end of a task to reboot the system.

This will generally work without issue on very fast systems or images without many other services installed but, what I've found is that depending upon how long the system takes to shut down and stop all of the services, KACE may try to move to the next task in the chain as the system is shutting down. The result is the script failing.


The other issue is that the KACE agent will occasionally reset it's connection during system startup, especially if the system is configured to automatically login to a user account. This will cause any script that was started before the agent resets to fail.


What  I've had to do in order to workaround these is as follows.

- Have a script to reboot the system in the task chain.

Script will run shutdown.exe -r -f- t 15 and then ping localhost for 3 minutes as to hold the script open.

This will always generate a failure message in the Task Chain log.

- Have a task immediately after the reboot that pings localhost for 3 minutes.

This will occasionally fail if the agent resets it's connection.


In all of my tests the following script will run successfully as long as it's configured to run on next connection if offline.

These workarounds seem to work but add a lot of unnecessary steps to the task chain as well as false error messages that makes it harder to review the deployment progress.




0 Comments   [ + ] Show comments

Answers (1)

Posted by: Hobbsy 4 years ago
Red Belt
0

This seems to be way too much hard work to achieve what you are looking for and not what I would expect from task chain behaviour. I know that there are some dev and support issues for task chains being looked at, so I would suggest log these with support, so engineering can take a look and are fully aware

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ