Lansweeper deployment accidentally deployed

[Alexandru]

Hello,

Today, we had an incident where a deployment was accidentally deployed on a couple of servers, causing them to shutdown (among other things). Is there any way to deny deployments on servers while maintaining the ability to scan them?

[CyberCitizen]

We are not super big, but what we did was exclude our servers from Lansweeper for this very reason, we had someone push out a local admin password change which went to every machine but also the primary servers which changed the default password for the domain admin account which then had follow on effects with auth issues etc until we traced back what had happened.

After that I made the decision to exclude servers as we don't deploy to them, and all the stuff that Lansweeper can pull on them we can do manually when needed, which is not often as we use LS to manage the Desktop / Laptop fleet & Monitors.

I agree with the packaging options I think there should be a default step that checks OS etc.

[JacobH]

Honestly, the deployment is super-dangerous - especially the larger in scope you go (i.e. 40,000 machines for example).

It's very convenient, but not very fleshed out feature-wise.


What I ended up doing, was removing deployment access from everyone except a few senior people. If you want to have people make deployment packages, you need to have someone review them before deploying them (not only the package, but QC the report criteria).

There are many features in Lansweeper that are really geared for smaller businesses and scopes, but can be used on a massive scale - this is one of them.

[ghelpdesk]

+1 to OS checks in packages and @CharlesX, Lansweeper desperately needs more granular permissions for the deployment feature (ie: can run, but not make packages or manage package scheduling) and the option to disable deployments from web-viewed reports.

Another option (though not always ideal) is to deny Lansweeper active scanning access to the servers and have them push scan data via LSPush.exe as a scheduled task.

A "hacky" backup option that is applied directly on the asset that you want to prevent deployments (for when co-workers create packages without OS checks and run them)

1. Create (or delete and recreate if it exists already) the folder C:\Windows\LSDeployment
2. Change the permissions of C:\Windows\LSDeployment to deny write access to the credential that scans your Windows servers (and also then connects to the machine to initiate the deployment).

Deployments to that machine should now fail with the below error.

"Unexpected failure while connecting to Asset. Access to the path '\\...\C$\WINDOWS\LSDeployment\RemoteDeployment_x64.exe' is denied"

[Esben_D]

ghelpdesk wrote:
+1 to OS checks in packages and @CharlesX, Lansweeper desperately needs more granular permissions for the deployment feature (ie: can run, but not make packages or manage package scheduling) and the option to disable deployments from web-viewed reports.

We're quite aware of the issues with the lack of more granular permissions, it's been requested a lot. We are working on it but it will take some time as permissions go throughout the whole software and require a lot of development time.

[Alexandru]

Thanks mwrobo09 and Charles.X. It's not perfect but it does the job, thank you very much. Although, I would very much hope that such a feature would be added to Lansweeper, as this solution only applies to deployments made by myself.
P.S: The incident I had was the following: someone made a shutdown script, and accidentally deployed it to 64BIT Windows report instead of selection. Fortunately, it only shut down 2 servers (Unimportant file server and another non-critical server) before I forcefully power off the Lansweeper VM. It only got to computers and servers starting with the "a" letter, next on line would've been the domain controllers and a critical production server that would require a full restore from tape if shut down like this.

[Esben_D]

The options are either to target your deployments more precise with the use of reports or groups. Or as mwrobo09 mentioned, add conditions to the package so it only continues on machines you want.

[mwrobo09 · Accepted solution]

Alexandru,

I have had this concern for a while and asked for an added feature to disable deployments on certain machines. What I did is created conditions on my deployments to only look for desktop OSs and then fail if not one. Here is a link to the XML that you can import and use as a template for creating new deployments.

https://www.lansweeper.com/forum/yaf_postst16305_Client-OS-Deployment-Template.aspx#post54860

Unfortunately in order to not lose my history I had to manually add all the steps to each deployment manually. You can export your old deployment, then add the xml from the link to the top and adjust step numbers, and then reimport back in, but it will come up as a new deployment. It was a pain but worth it knowing no one will accidently push a deployment to a server.