Deployment Errors and Configuration

[rinks]

Hello,

I am back visiting a deployment solution using Lansweeper Classic. This was set on the back burner as we are having issues with remote computers checking in via LsAgent (1000 laptops showing up scanned between on-prem and remote, when we have roughly 1800 laptops in the environment).

Presently, I am just running a CMD line prompt to test the deployment connection by popping up a window on the target machine. Running testconnection.exe to the target machine, I can successfully ping, resolve DNS to an ipv4 address, ports 135 and 139 are open, 445 is closed (security won't allow this to be open for whatever reason). Running a check on the firewall, remote admin mode is enabled on the target machine.

I constantly get an error stating the file path for C$ is incorrect. Our Lansweeper installation is on a different install location (again, infrastructure and security wanted this to be different) so instead of C:\Program Files (x86)\Lansweeper, it's D:\Lansweeper. Opening C$ through CMD opens the Documents folder on the Lansweeper server. This has been shared and has our credential for "lansweeperdeployments" added with R/W permission. On the target computer, the same was performed.

Testconnection.exe is unable to access C$ due to the path error. Checked the credentials to be sure: using the wrong ones on purpose results in the test completely failing, so credentials are correct. Also checked to make sure remote registry and task scheduler are both running.

My questions are:

Is port 445 a hard requirement to allow deployments and could the port being closed be the reason why we can't deploy?
Is there a specific path we should be using for the C$ since we store deployment packages in D:\Lansweeper\Deployment and the share folder is C:\? (I'm assuming our naming convention should be correct in Lansweeper console. I've tried \\servername\C$ and \\servername\DefaultPackageShare$ as well as setting the lansweeper credential for the IP range I was testing.)

Could the reason for remote computers not checking in via LsAgent (a lot of these are not getting their LsAgent automatically updated either) be due to the SMB port being blocked? I was under the impression that as long as 135 and 139 were open, we would be good, but we progressively lost 800 laptops from scans over several weeks.

Been back and forth with support over the 2 years I've been assigned to get Lansweeper up and running as well as take advantage of all features it offers, but it has not been easy. Between always making sure the server is up-to-date, sending logs, and trying to work between 2 other departments who always say things are configured correctly on their end as far as firewall and antivirus, I'm at a loss. 

[FrankSc]

Hello Rinks,
The main test are done by testconnection.exe. As long as you get errors there, your deployment may fail.

The requirement for C$ is not on the Lansweeper server. This is on the target computer, because we put our deployment package in C:\Windows\LSDeployment. The task scheduler on the target computer will read the package from there to run it. This is unrelated to the share where you put your packages.
The full list of requirement are in the page below.
Deployment requirements - Lansweeper Community

For LsAgent, I don't see a relation. If you are using a direct connection, the client should be able to send its scan data to port 9524 on the server. Port 135 or 139 are not used for that. Maybe you won't like me saying this, but to get a clear view on the LsAgent issue we'd like to see typically logs to check what is wrong. If you were already talking to our Support team, please contact them again and reopen an existing case, or create a new one. I'll keep an eye on your case and handle it further.