Search the Community
Showing results for tags 'network probe'.
Found 4 results
Hello, Apologies if this has been asked before, I cannot find any good threads about it. We just started using Automate and have about 5k clients across the country and each client has anywhere from 3-30 machines we would like to deploy Automate on. 95% of these customers are not on a domain but do share the same local admin username and password and in turn have full access to each other's file systems. We were told by ConnectWise Support that Network Probe only works with machines on a domain. We're trying to find a good way to deploy the agent out to these machines by only installing the initial agent on one machine on their network. How have some of you come across this limitation of Network Probe? Have you found a way to do what we're trying to do?
I have created Automate Agent deployment scripts that run from Automate. • Uses discovered Computers & Network Devices found by the Probe and uses assigned Location Credentials (unless Override User/Pass is entered) to push Automate Agent. • Right-Click on Network Device to push Automate Agent to one computer • Scans entire subnet where the agent is located and uses assigned Location Credentials (unless Override User/Pass is entered) to push Automate Agent. • Query Active Directory for all computers that have logged-in in the past 30 days and uses assigned Location Credentials to push Automate Agent All of the scripts utilize GitHub for up-to-date Automate-Module.psm1 https://github.com/Braingears/PowerShell/blob/master/Automate-Module.psm1 It will Ping -> Attempt Deployment via WinRM -> Attempt Deployment via RPC/WMI Agent Deploy via Scan Local Subnet.xml Agent Deploy via Domain Controller.xml Agent Deploy to Network Device.xml Agent Deploy to All Network Devices.xml
Hey all, For those of you who dont know... I am the Product Manager for the newly introduced Network Probe Gen 2. After seeing many, and quite often the same, questions being asked since Network Probe Gen2 launched last week, I felt that now is a good time for me to create an FAQ for all things related to Gen2. This is not intended to replace, or even be an alternative to, the Official Docs (Click here to read those!), but more so something to supplement the information that is already out there. If, after reading this, you still have some questions - or would like further detail on any existing content, then PLEASE reach out to me on Slack (@martynkeigher), or just reply to this post. After I answer each new question - I'll move them into the FAQ, so they don't get lost. So... lets see how this goes.... __________________________________ Q1: I’ve just update to [Automate 12] Patch 10... am I on the latest and greatest now? Yes and No. While you are on the version that introduced Network Probe Gen 2, you must also ensure that the ‘ConnectWise Network Detection’ solution is kept up-to-date, via the Solution Center. Q2: I’ve just updated to [Automate 12] Patch 10, updated to Gen2, and I cannot see my ESX hosts (For Virtualization Manager)! Why is that? This was a known-issue during pilot and was fixed in v220.127.116.11 of LTNet.dll, within the ‘ConnectWise Network Detection’ solution. Please ensure you have (at least) that version, and then restart the remote (probe) agents to force the update of the new dependency. (See Q10 for more info on this.) Q3: Can I update all my probes to Gen2 with an ‘easy button’? No. There is currently no feature, or future-plan, to mass-update all your probes Gen2. Q4: So… with the new probe, I can upgrade as I go? It doesn't upgrade all my probes when I update to Patch 10, does it? Installing Patch 10 will not auto-upgrade your Gen1 probes to Gen2. You can upgrade your probes at your own pace. Q5: As soon as I enable a Gen2 probe, a discovery scan immediately starts. I’d rather configure some settings first, and then manually start the discovery scan. How would I do that? Network Probe defaults was also introduced in Patch 10. They can be found under System > Configuration > Network Probe. If you do not want you probes to immediately scan, adjust the default scan windows to something like… 10pm (start time) & 3am (end time), or alternatively, set the Scan Frequency to On-Demand. Q6: I’m in the middle of converting all my Gen2 probes… How can I keep track of my Gen1 and Gen2 probes? There is currently a data view in development for this. It will be added to the ‘ConnectWise Network Detection’ solution once available. Until then though, you could use this: (Disclaimer: I accept no responsibility if you 'get creative' with this SQL statement and, by doing so, you break stuff!) SELECT cl.Name AS 'Client', l.name AS 'Location', CONCAT (c.name,'(',c.computerid,')') AS 'Probe Agent (ID)', IF(c.LastContact < DATE_ADD(NOW(),INTERVAL 60 SECOND),'Online','Offline') AS 'Status', IF(c.locationid IN (SELECT locationid FROM probeconfiguration),'Generation 2','Generation 1') AS Gen FROM clients cl JOIN computers c USING (clientid) JOIN locations l USING (locationid) WHERE c.computerid IN (SELECT probeid FROM locations) ORDER BY cl.name,l.name Q7: I just built a bunch of new Detection/Collection templates. Are they still honored? Yes. They will still be honored. Q8: I don’t like Gen2 and all its new, cool awesomeness!! Can I roll back to (or re-install) a Gen 1 probe? No. Assuming you are on at least Patch 10, once you have promoted a Gen1 probe to Gen2, or just installed a Gen2 probe, there is no rolling back to Gen1. Q9: So… What’s this I hear about a new discovery method(s)? It’s been brought up, but never actually broken down & explained. Explain it for me? The Gen2 ‘Discovery Scan’ uses 3 methods to discover a device. After the initial ping-sweep of the subnet(s) is complete… The 1st check is NETBIOS. This checks to see if port 139 is open. This gives us a ‘Missing Device’ count. The 2nd check is a SNMP check against the device to determine its MAC address. The 3rd (and optional) check is the ARP Table scanning. This is not enabled out of the box but can be enabled via the Network Probe Setting, ‘Enable MAC Address Scanning’. NOTE: Just like with the old Gen1 probe… A MAC Address is required to uniquely identify the device - if the probe cannot determine a MAC address, then it will not create a Network Device. Q10: When you say “SNMP Check” … what do you mean? If we can communicate with a device using SNMP (community string) we walk the device’s MIB for 2 specific OIDs (Object Identifiers) to obtain the MAC. If this check does not return a MAC address, then we will not create a Network Device entry for it. OID Check Example Returns Check 1 18.104.22.168.22.214.171.124.1.2.<Device IP Address> 126.96.36.199.188.8.131.52.184.108.40.206.83.1 <InterfaceID> Check 2 220.127.116.11.18.104.22.168.1.6.<InterfaceID> 22.214.171.124.126.96.36.199.1.6.27 MAC Address I'll illustrate.... Check 1 (returns the Interface ID, in this case 27) Check 2 (returns my MAC address - and the one that will be used in the networkdevices database table). FYI: The VMware MIB stores these values in different OID's for ESX hosts: Check 1: InterfaceID: 188.8.131.52.184.108.40.206.220.127.116.11.<IPAddress> Check 2: MAC Address: 18.104.22.168.22.214.171.124.1.6.<InterfaceID> Q11: I heard something about the Network Probe being more focused around the location… Can you elaborate on that? During pilot, we re-worked how the probe is associated to the location, and now the location has more of a role to play for Network Probes. This was a huge undertaking, and ‘laid the groundwork’ for implementing many other enhancements already on the roadmap. A good use-case that this solves for today is when a probe agent stops functioning, and cannot be brought back online, e.g.: a BSOD. Should a probe agent become unrecoverable, then you can now elect a different agent to be a probe at the same location, as the settings are now tied to the location and not the agent itself, so the new probe will ‘pick up where the old one left off’. Q12: We haven't used the network probe much until this release and it's bringing up some questions now. So, should we be enabling SNMP on almost all networking devices? For best results with Gen2 you must have SNMP enabled on SNMP compatible devices. Doing that will set you up for success. No doubt about it!! From Automate’s perspective… You can’t really say you are ‘managing devices’ unless you have SNMP connectivity to them! Q13: The new network map is cool, but it doesn't show nearly everything the probe sees. Is that normal? Network Probe Gen2 places a heavy dependency on SNMP for device discovery. If we cannot get the MAC address of a device, then we cannot add it as a Network Device. Gen2 was designed to only ‘bring in’ devices that it can manage. Be sure that you have SNMP enabled, on your SNMP compatible devices, and can validate the MAC address (as referenced earlier). If you can, then please contact support, and be sure to have the following 'qualifiers': On Automate 12 Patch 10 (build 451), minimum. On at least v126.96.36.199 of LTNet, (distributed in 'ConnectWise Network Detection' via Solution Center). Communication to the device, via SNMP, is returning the MAC Address. Q14: SNMPv3… yes? no? SNMPv3 is still an option with the new Network Probe. You can configure that at a probe level. We recommend that you set that if all your devices, that are configured for SNMPv3, are using the same authentication/encryption passwords and methods. Q15: I'm seeing more devices in my network device list and my computers list then I am seeing on my network map. Any idea what I may be doing wrong? Only devices discovered via the Gen2 probe have the potential to be placed on a map. Devices discovered during Gen1 will not show. In addition to this, (due to how we still rely on the MAC address of a device to give it a DeviceID), you may also find that while you can see network devices in your list, they may not show on the map, as they are Gen1 discovered devices. (The MAC already existed in the DB table, so the device can’t be ‘re-added’). Extreme scenarios where this has been witnessed is where, after a discovery scan shows multiple devices yet only ONE device is on the map. This also leads into the next question… Q16: Thoughts/process on… ‘Nuking’ my current Gen1 probes and configs (never really got into it) to setup the new Gen2 stuff? Any ‘best practices’ around this? Given the feedback we received during pilot and the new probe being viewed as a time to ‘start-over’ and ‘re-do probes’ for most Automate admins, the best practice approach to this would be to disable the probe role from the agent and then re-enable the probe as a Gen2. The commands that proved to be most popular on existing probes (after adjusting Network Probe defaults) was: Purge Network Devices Disable Gen1 Probe Enable (Gen2) Probe Start Discovery Scan Q17: I disabled the network probe on this agent but now it's saying I can't retire it, because the network probe is enabled!? Why is that? The ‘Disable Probe’ command is a database focused command, so the Control Center may not acknowledge the change until you ‘Reload System Cache’ & then refresh the Computers view. __________________________________ Extra Info: Log files: C:\Windows\LTSVC\lt_LTNetAccess.log C:\Windows\LTSVC\lt_LTNetMap.log C:\Windows\LTSVC\lt_LTNetScan.log C:\Windows\LTSVC\MyNetwork.xml Support Tools: (attached to this post!) SNMP Walk Tool. Download here: SNMP Walk Tool v2.zip Database Tables: Gen1 probeconfig Gen2 probeconfiguration (& many other probe**** tables). networkswitchmap No point editing as table redraws after each Discovery scan SwithMac is the Parent (uplink) device DeviceMac is the child device HH-HH-HH-HH-HH-HH = Top level device GG-GG-GG-GG-GG-GG = Internet (WAN) connection Official Links: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/175 https://product.connectwise.com/communities/5-automate-enhancements/categories/16-network-devices-and-mapping/topics </END> SNMP Walk Tool.zip
Hey friends, We are curious if anyone else has any insight or has experienced the same issues as we are having. Back in October of 2017, we had an issue with servers/computers across our clients going into a repair loop. Upon further investigation, this was a result of a bunch of system files missing. We thoroughly reviewed and compared these computers in attempt to find any similarity as to why it was happening but unfortunately there was a wide range of operating systems, software, hardware, and environments with no commonalities except for our core software (LabTech, ScreenConnect, Webroot). After much racking of our brain, we identified one common thing. Each of the affected computers was a non-virtualized machine running LabTech/Automate's Network Probe. At this point we proceed to involve a third party as well as engage LabTech/Automate's support. After much time investigating they unfortunately weren't able to provide us with any real reason as to why this is happening. Out of paranoia and safety for our clients, we proceed not to deploy the Network Probe on anything but virtualized machines. And we had not had any problems until recently... Over the last three weeks, we started seeing the same behavior we experienced back in October of 2017 except now affecting machines which are virtualized. As before, these machines have little to no commonalities other than the Network Probe. Seemingly out of nowhere, a large number of files would go missing and upon next restart would fail to start with error stating "missing acpi.sys." We have scoured logs with no answer. This has caused much headache, frustration, and doubt with Automate's Network Probe. We have proceeded to remove the probe from all locations for the unforeseeable future and created a monitor to routinely check for acpi.sys. No issues since the removal of the probe. Additionally we have upgraded hardware and operating system of our Automate server (December 2017 for both - 100% meeting system recommendations), are current on patches/updates, and we have been using the "New" Network Probe. Loosing the network discovery of the probe and it's ability to also capture VMWare data is quite unfortunate but having machines completely fail is not worth the trade. If anyone has any insight or information, we would greatly appreciate it.