Stopping a Deployment that's gone awry

[BlackOut]

Am I blind or is there no way to cease a deployment? I had a deployment that got stuck because of a failed install and it locked up the executable. I was able to cancel that one but as soon as I did everything that was queued behind it went forward. The problem is...they kept going...over and over and over again. Rebooting some systems 4-5 times. I ultimately killed the deployment by deleting it from the schedule, the package share and the deployment itself. Needless to say there were some very unhappy people.

[Daniel_B]

We recommend testing your package on example machines before deploying them to larger groups of assets. After you confirmed the package to be deployed or deployment schedules initiated a package deployment, the first task will start running. Lansweeper will only stop a deployment after its max duration time has passed. From that moment on no further package steps will be started and you can deploy other packages to the same machine. A "cancel" function for already running deployments won't be reliable because many installers start more than only one process. We might add a cancel button at a later time, but this isn't planned for the near future.

[spamking]

I'd settle for being able to remotely stop the deployment or using some lansweeper action to kill the deployment on individual machines.

Deployments that seem to be perpetually hung up only recently became a problem.

[MakeBug]

How about a client side lister? This way the whole installation can stay on the client but the server is still able to send messages (and also receive).
However since the deployment queue is limited anyways (or isn't it?) even if the installation needs to be managed by the server it still should be able to handle it (I don't know what you use as lansweeper-server but I hope that it's not a toaster).

[Susan_A]

I haven't used PDQ Deploy personally, but I'm assuming it leaves the server in charge of the deployment throughout the entire deployment process. This gives you control, but also means that the strain on the server is a lot bigger. Lansweeper pushes scheduled tasks to your client machines and then lets go of the deployment, leaving the scheduled tasks to do their thing. This means that the client machines' own resources are used to complete the deployment, reducing the strain on the server.

[jprateragg]

As someone who just ran into a very similar issue with this--your product REALLY needs some work in this department. Rebooting a user's computer in Safe Mode IS NOT AN OPTION. You need to implement a way for us to be able to actually MANAGE a deployment. Restarting Lansweeper and rebooting workstations/servers aren't really options IMHO. We used to use a product called PDQ Deploy and it was able to do all of this--I don't see why your product can't. Please fix this ASAP please. Thanks.

[Daniel_B · Accepted solution]

After you confirmed that you would like to deploy a package, tasks will be generated and the deployer will start to work on target computers. Stopping a running deployment is not currently possible as this might cause severe issues on target computers.
The only possibility might be - if not all client computers already received the package - that you open services.msc on your Lansweeper server(s) and restart Lansweeper service. This will clear all current deployment data. Of course you should ensure that you remove unwanted schedules from Deployment\Schedules on the web console.

On the client computers which already received the package, there will be placed an executable under C:\Windows\LSDeployment and registry entries will be saved under HKEY_LOCAL_MACHINE\Software\lansweeper\Remote deployment. You might be able to start the computers in safe mode and remove these.