Submit a ticketCall us

AnnouncementsChange Is Inevitable

Get valuable help when it comes to tracking and monitoring changes. SolarWinds® Server Configuration Monitor (SCM) is designed to help you: detect, track, and receive alerts when changes occur, correlate system performance against configuration changes, compare server and application configuration against custom baselines, and verify application and system changes.

Learn more.

Home > Success Center > Network Performance Monitor (NPM) > Network Performance Monitor (NPM) Training > Free SolarWinds Training Videos - NPM > Introduction to Object Discovery - Video

Introduction to Object Discovery - Video

Updated November 3rd, 2017


This video (11:30) demonstrates the first step to using any of the Orion modules is to add objects (servers, virtual machines, interfaces, devices, etc.) to the database for monitoring.

The easiest way to do this is with the Network Sonar Discovery wizard. Network Sonar Discovery allows you to scan a range of IP addresses and automatically identify and import any nodes found within the IP address range. 


This video is available in the following languages: German, Simplified Chinese, Spanish and Portuguese. 



             Products in the Orion Platform version 2015.

Server & Application Monitor  v6.2.3

Network Performance Monitor v11.5

Virtualization Manager

Network Traffic Analyzer         

Storage Resource Monitor  

Network Configuration Manager 

Web Performance Monitor

IP Address Manager

User Device Tracker                                                        

VoIP & Network Quality Manager


Before you begin:

  • Enable the networking devices you want to monitor for SNMP
  • Enable Windows devices for WMI

The first time you discover your network, SolarWinds recommends adding a limited number of edge routers or switches, firewalls and load balancers (if you have them), and critical physical or virtual servers and hosts.



This setting ensures that any agents you deploy, including the one on your Orion server, are up-to-date. If there are no nodes using agents, you can leave this option unchecked.

Discovery can take anywhere from a few minutes to a few hours, depending on the number of network elements you are discovering.

  1. If the Discovery Wizard does not start automatically after configuration, click Settings > Network Sonar Discovery and click Add New Discovery.
  2. On the SNMP Credentials panel, if all devices on your network require only the default SNMPv1 and SNMPv2 public and private community strings, click Next and go to Step 5.
  3. If any device on your network uses a community string other than public or private, or if you want to use an SNMPv3 credential:
    1. Click Add New Credential.
    2. To add an SNMPv1 or SNMPv2c credential, type the SNMP Community String, and click Add.

      Community strings are case-sensitive.

    3. To add an SNMPv3 credential, provide the required information, and click Add.
    4. Repeat for each community string you want to add.
  4. If the Agents panel appears, you enabled the Quality of Experience (QoE) agent during installation. The QoE agent monitors packet-level traffic. If there are any nodes using agents, select the Check all existing nodes check box.
  5. To discover VMware vCenter or ESX hosts on your network:
    1. Check Poll for VMware, and click Add vCenter or ESX Credential.
    2. Select <New credential> and provide required information.

      If you do not add the host credentials, Orion still discovers the virtual machines (VMs) on the host. However, you will not be able to see the relationships mapped between the VMs and hosts.

  6. To discover WMI or RPC-enabled Windows devices:

    SolarWinds recommends that you monitor Windows devices with WMI instead of SNMP.

    1. Click Add New Credential.
    2. Select <New credential>, and provide the required information.
    3. Confirm the Password, click Add, and click Next.
  7. Click Specific Nodes, add a limited number of IP addresses, and click Next.

    If you use the IP Ranges option, and this is your first discovery, limit the range to 512 or fewer IP addresses.

  8. On the Discovery Settings panel, click Next.
  9. Accept the default frequency and run the discovery immediately.

Video Transcript

The first step to using any of the Orion modules is to add some network objects to the database for monitoring.

The easiest way to do this is with the Network Sonar Discovery wizard. Network Sonar Discovery allows you to scan a range of IP addresses and automatically identify and import any nodes found within the IP address range.

If this was a fresh install, there would be a Getting Started section on the Summary page with a link that says “Discover My Network.” This link would take you to the Network Sonar Discovery wizard. The more typical way of getting there is by clicking Settings in the upper right hand corner.


From the settings page, under the Getting Started section, you’ll find Network Sonar Discovery.


You’ll notice that I already have one Discovery job built. You can add as many discovery jobs as you’d like and then run them any time either manually or as a scheduled discovery job. So let’s build a discovery job. To get started, click on Add New Discovery. This will take you into the Network Sonar Wizard.


When you create a discovery job, you’ll specify a range of IP addresses to scan and add credentials for any nodes you expect to find. There are multiple ways of monitoring network objects in Orion, but SNMP is sort of the assumed default monitoring method. So the first tab in the new job is asking for your SNMP credentials. You can see the default Public and Private community strings have already been added, but you can add as many community strings as you’d like. To add a new community string, click Add New Credential. Then you can add either SNMP V1 and V2 community strings, or SNMP V3 credentials. Orion includes a credential library, so if I had added a V3 credential previously, you would see it in the dropdown list here. Since I don’t have any more credentials to add, I’m just going to cancel. When you’ve added all your SNMP credentials, click next.


The agents tab is a relatively new tab that was added to Orion. This is really more of a feature for Server and Application Monitor, or SAM, users. The SAM server agent software can be installed on an application server to enhance application monitoring capabilities. The agents tab includes a simple check box that asks if you want the discovery job to check the discovered nodes to see if that agent software has been installed on the node.


The Virtualization tab is similar to the agents tab in that it has a single check box, but in this case it’s asking if you want Orion to check whether any of the nodes are VM hosts. If you are scanning a virtualized environment, you’ll need to be sure to include your VM host credentials. Now technically you can skip this step. If you don’t scan for VM hosts or don’t have the right VM credentials, you will still be able to discover the VMs running on the host because the individual VMs will still respond to a ping. However if you don’t check for the VM host or don’t include the right VM host credentials, you won’t see all of the information about the VMs. For instance, interface information is associated with the VM host, not the VM. So without scanning for the VM host, you’ll be able to see the VM, but you won’t be able to automatically map the network topology of the VM. So to avoid possible confusion down the road, make sure you double check your VM host credentials.


Next is the Windows Credential tab for WMI monitoring. If you’re monitoring Windows servers, you’ll most likely want to use WMI. As with the SNMP tab, you can add as many credentials as you need. Click Add new credential and either enter new credential information or choose a credential from the dropdown list if you have added credentials previously. As I mentioned, Orion does include a credential library so you don’t have to reenter these credentials each time. And you can manage the WMI credential library separately by going to Settings, Windows Credentials, and clicking Manage Windows Credentials. We’re not going to look at that now, but trust me, it’s there.


Now that you’ve added your credentials and told the polling engine what to look for on the nodes, it’s time to specify the IP addresses to scan. There are three Selection Methods to enter IP range. The first is to just specify a start address and an end address. Or you can use the Subnets link to add a network address and mask. From this selection you can also add a Seed Router. In this case you simply add the router’s IP and let Orion poll the router for routing information. With both the IP Ranges and Subnets selection methods you can add multiple IP address ranges to a single scan, but you can only use one selection method. You can’t include an IP range and a subnet in the same scan.

The third selection method is to add just specific IPs. Which selection method you’ll use probably will depend on which Orion products you’re using and how you’re using them. For instance, let’s say you’re using NPM but have a fairly small license count, so maybe all you’re monitoring is your network hardware. Or maybe you are a SAM user and are just monitoring certain application servers. In those cases, you might just include those specific nodes. However, even in these cases I usually recommend scanning a network range rather than just specific nodes in your discovery. But even if you only choose to monitor certain nodes, by scanning a network range you can still see what’s out there in your environment and keep an eye on what shows up on your network. Now the natural question of course would be well how will that affect my licensing and performance. And that answer is, it won’t. The only thing that will affect either licensing or performance are the elements you’re actively monitoring. When you run an automated discovery, you’re just looking to see what’s out there. For instance, in my last scheduled discovery job you can see that 11 new nodes were found. We’ll look at the discovery results a little later, but at this point I can see what’s happening on my network, but then I can choose whether I want to start monitoring these devices or just ignore them. Either way, by scanning a network range instead of adding specific IPs, you can see that I’m going to be able to keep a better eye on the network.


Now we come to the Discovery Settings. First of all, notice here you can name your discovery job so that you can save your jobs to either run on a set schedule or to run manually. Naming your jobs is optional, since a default name is created for you based on the user who created the job and the time it was created. But if you have several discovery jobs built, it’s probably a good idea to give them a better name than this, and maybe add a description as well.

Below this, you can see all the thresholds for this discovery job. Now if this is the first time you’re running a discovery job, I’d probably recommend leaving the default timeouts and thresholds alone. That’s because they are set high enough that they should catch pretty much anything you’d encounter in a normal environment. But if you run the discovery job and find that you’re not finding nodes, then you can come back and adjust the thresholds. That would be most common in an environment where you’re dealing with high latency. But the reason that you don’t necessarily want to start out by adjusting the thresholds up is that doing so would slow down the discovery job. We’ll talk more about that when we talk about discovery performance.

Finally, if you have multiple polling engines, you’ll notice you’ll have a drop down box right here to choose which polling engine you’re assigning this job to. If you only have one polling engine, you just won’t have a dropdown box in this space. The polling engine you choose will run the discovery job obviously, but going forward that will also be the polling engine that will monitor any nodes found in the discovery. Be sure to pay attention to the polling engine you choose because if you don’t a couple things may happen. First, you’ll end up overloading one of your polling engines. But second, if you have multiple polling engines and a large environment where you may have significant differences in latency, you’ll probably want to position those polling engines to reduce latency between the polling engine and the devices they’ll monitor. If you choose the wrong polling engine, of course you’re not going to be taking advantage of that latency reduction and your performance and the reliability of your polling data is going to suffer. Now if you do choose the wrong polling engine, it’s not the end of the world. You can always come back and edit the discovery job and point it to the right polling engine. And it’s also very easy to reassign nodes to a different polling engine either individually or in bulk by just editing the node details, which we’ll look at later.


Once you’ve got your setting where you want them, click next to schedule your discovery job. You’ll notice in the Frequency drop down box I have four options. I can run the job once, and either run the job right now or just save the job to run later. I can schedule the job to run on hourly intervals, in which case you’ll notice the default interval is every six hours. You could run the job every hour if you wanted. But for me, in most environments that’s probably too often. I probably wouldn’t run the job that frequently unless you’re in a very dynamic or possibly very sensitive environment where you want to be able to see fairly quickly if there are any new devices that pop up on the network.

The most common scheduling interval is daily, which allows you to choose what time of day you want the job to run.

Or you can choose the Advanced option and add a custom frequency where you have a tremendous amount of control over the scheduling. Here you can also choose to run the job daily, but notice you have the additional option of running the jobs only during business days. You can run the jobs weekly on only certain days of the week. Or you can run the jobs as infrequently as once a month if you want to. For me, I don’t think that’s often enough though. Personally, in most environments I’d probably run the discovery jobs once a day. But that’s up to you. It will depend on how often you want to scan for network changes and on the size and performance of your deployment.

Once you’ve got the frequency set, depending on whether you choose to run the discovery job immediately, you’ll click on either Discover to launch the discovery job right now, or schedule to just save the job to run manually later or to have it run on whatever future schedule you have set. Personally, anytime I add a new discovery job, I tend to run it immediately, especially if you have a new Orion deployment because you won’t have anything to monitor until you run the discovery job and get something in the database. But I tend to like to see how the discovery job runs, what it’s going to find, and how long it will take. That way I can see if I need to make any adjustments to the job settings and maybe to my scheduling.

But for now I’m going to choose No, don’t run now, and click schedule to save the job for later. Then we’ll go back and launch the job manually.


Last modified