Kaseya Community

Network Agent Deployment

This question has suggested answer(s)


I'm trying to push agents out from a clients DC server

The quick and deep scans picks ups some of the machines but when I attempt to deploy to those machines I get the following errors

Error 1

Could not connect to \\machinename.domain.local\ADMIN$ Connect to Admin$ failed Error 1203: No network provider accepted the given network path

Error 2

Copy binary failed Error 32. The process cannot access the files because it is being used by another process

Now the first 1 confuses me as username and password and domain I'm using does work when RDPing to the relevant machines and has allowed me to install an agent on one machine via the network scans and deployment. So if all machines are domained, and its not an incorrect Username and Password, Is there any other reason this error could be coming up?

Error 2 is most likely as the previous IT company have there kaseya agents still installed on all machines. Is there any advise you can pass on as to how to avoid this and install my agents along side another kaseya agent? Ill remove the other IT providers agents once I'm onsite and the client is confirmed to come onboard with our service

Thanks in advance

All Replies
  • Hi Rhysl,

    I believe this KB article might help troubleshoot further as to why the agent install package is not being deployed.


    In regards to the second error, as it's not mentioned in the KB at this time, this is mainly when another process (AV, Security software, etc.) locks up the agent install package. I would kindly advice to disable any software of this nature and try the deployment again.

    Also if you need more in depth assistance, feel free to create a support ticket and let me know the ticket number so we can assist you further.

  • Tim,

    Can you take a look at ticket CS163322 and confirm this behavior?  Is the discovery module unable to push out agents that are on a different subnet but quickscan is able to detect these machines?

  • Hi GDRBrian,

    I responded back to the ticket with further information. Please let me know if this helps. I will also post a summary of our findings here on the forums after the investigation is completed for future instances. Thank you.

  • To post on the summary, currently Discovery is unable to scan across multiple subnets within one scheduled LAN Watch. It is not recommended to run a LAN Watch across multiple subnets. Instead, we recommend to run one LAN Watch per subnet to find the devices correctly and deploy agents to them. It's the expected behavior of the  Quick scan (ICMP echo request)  to pick up machines; however, the Deep Scan (ARP request) does not and thus we prevent the device(s) from being shown due to a lack of complete information from the device(s).