+2
Declined

Control Deployment Tool should handle VPN Network Scans and Multiple VLANs

Mike Brown 4 years ago updated by 3133 1211 2 years ago 5

When deploying the Control Support/Access client an organization may have multiple Vlans, the tool should be able to reach out to multiple Vlans.  The other issue is that you cannot deploy to clients using VPNs.

Yes! This is what I was just trying to explain to the CW support engineer. a feature similar to IP scanner apps - if we can define the subnet we want to deploy to, instead of ARP or local subnet would like life much easier.

Can we have some explanation why we can't just have a dialog box to enter the subnet to scan? It's not like this is a major code change since you are already detecting and processing the local subnet.

Yes, or a box where we can type in a computer name and search for it. Or even better yet, a button that scans the entire network and displays computer names along with the IPs, so we don't have to look up which computer each IP is. 


CW has so many great features, which is why we decided to choose it for our remote support software at my company, and that's why I'm truly surprised at how primitive/lacking this Client Network Deployer is.

Wow Connectwise, this is extremely short-sighted to just decline this outright. 

A lot of companies are moving to an Azure stack. This means the servers a support staff may control are in Azure, while we want to deploy to on-site devices. These will always exist on two different sides of a VPN tunnel between Azure and the local site. You could give yourself routing issues by having an extended LAN over the tunnel, but if it goes down for any reason, you'll have one side offline (namely the site)

We should have the ability to push to any subnet we want. Let us do the networking. The deployment tool should point where we want it to.