Description
When trying to deploy a software in a post 9.6 SP1 environment, we get the message: Client has initiated asynchronous policy execution and the task stays Active
Image may be NSFW.
Clik here to view.
Please note that there is a document for 9.6 without any patch: “Client has initiated asynchronous policy execution” – Return Code 1354
Cause
This error is usually caused by a program running in background on the client machine that prevents the deployment from working.
The common processes are the following:
- SDCLIENT.EXE
- vulscan.exe
- MSIExec.exe
- sdistbat.exe
- cmd.exe
In my case, I created a BATCH file that runs a ping -t but never exits which leads SDCLIENT to interprete that the installation is still running. This results in SDCLIENT not being able to run another process.
Troubleshooting
This one might be tricky to troubleshoot as there are no logs where you can see that the task cannot be processed because of another one. For that reason, we will need to go for another source of information.
Basically, what happens when a task is scheduled is that the Server makes it available via APM and ask the client to check if it is entitled to get it.
The client then goes to the APM web service and gives its information to see if a task is available for him.
The task is then downloaded as an XML file on the client in C:\ProgramData\LANDesk\Policies
It then goes to C:\ProgramData\LANDesk\Policies\RunNow in order to be processed and usually disappears instantly when the task starts.
Before that, no logs are being generated for this task because it did not start. That means that you should be able to find in C:\ProgramData\LANDesk\Policies\RunNow the task(s) that are blocked with their Task IDN which will help you identify which task has generated the problem.
In our case here is what I can see in this folder:
Image may be NSFW.
Clik here to view.
I will then go to the Core and check which task is the 5054 (as it is the one that has been started first at 08:39), the best is to right click on the device and choose Scheduled tasks and diagnostics:
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Now that we have the faulty task, let’s check what it should do, trigger, etc. and where the problem might be, because it means that this task is not finished or blocked.
In my case, the script only does a ping -t but there is no exit which means I need to check on the client is one of the process is running, like the SDCLIENT, the sdist and/or the cmd.
Image may be NSFW.
Clik here to view.
I will then stop PING.EXE first, as it is the last one being triggered
- SDCLIENT.EXE
- sdist
- CMD.EXE
- PING.EXE
And I can see that CMD is being automatically closed, as SDCLIENT and sdist.
I can now go on the Core Server and see that the task failed, but also that the other task completed successfully:
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
On the client side, we can then check in C:\ProgramData\LANDesk\Policies\RunNow:
Image may be NSFW.
Clik here to view.
There you go, it is unblocked.
But there is still one thing, we need to change our ping -t script in order to have it not blocking the next distributions.
To do so, we need to understand that the task needs to finish at some point and report its status back to the Core. With a ping -t, it basically never ends until we close it. So I can simply change it to have a timeout of 10sc and an exit:
Image may be NSFW.
Clik here to view.
The task is now being processed, and after 10sc, the PING stops, and the script exits, letting other tasks being processed.