Submit a ticketCall us

AnnouncementsSystem Monitoring for Dummies

Tired of monitoring failures disrupting the system, application, and service? Learn the key monitoring concepts needed to help you create sophisticated monitoring and alerting strategies that can help you save time and money. Read the eBook.

Get your free eBook.

Home > Success Center > Network Performance Monitor (NPM) > Network Performance Monitor (NPM) Training > Free SolarWinds Training Videos - NPM > Create a Manual Discovery Job - Video

Create a Manual Discovery Job - Video

Updated June 6th, 2016


This video (9:04) demonstrates how to add network objects to the database for monitoring using the Orion Platform Network Sonar Discovery wizard.





  • SolarWinds Products Running the Orion Platform 2016 and higher including Network Performance Monitor v12.0 and above and Server & Application Monitor v6.2.4 and above.

Video Transcription

The first step to using any of the Orion Platform 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 or your Active Directory environment, and automatically identify and import any nodes found from those scans.

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 main menu and then Network Discovery in the sub-menu. 

This will take you into the Network Sonar Wizard.  Click Start to begin.

The first step in building a discovery job is to outline your network by defining the IP addresses or range that you want to discover.

There are four Selection Methods to enter an 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.


The last selection is to Add an Active Directory Domain Controller and specify the desired Organizational Units or "OUs".  


Which selection method you’ll use probably will depend on which Orion platform products you’re using and how you’re using them. For instance, let’s say you’re using Network Performance Monitor but have a fairly small license count, so maybe all you’re monitoring is your network hardware. Or maybe you are a Server and Application Monitor 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 or define a group of Active Directory OUs 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 a manual discovery, you’re just looking to see what’s out there.

The agents tab is most relevant if you have Server and Application Monitor, or SAM. 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.

There are multiple ways of monitoring network objects in Orion, but SNMP is sort of the assumed default monitoring method. The SNMP 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.

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.

The monitoring settings tab gives you the opportunity to specify some the ways the Orion will monitor your objects.

First, you can determine if your preferred polling method is WMI or SNMP.  If you are running a discovery in which you have more Windows devices than non-Windows, then you may want to select WMI as the preferred polling method to help speed up the job.  But keep in mind that selecting WMI does not mean that it will not also poll using SNMP.  It simply means that it will try first with WMI and then second with SNMP if it doesn’t respond to WMI.

Next, you will tell Orion if you want to manually set up monitoring after discovery or automatically.  When you select manually then you will be able to review the results via the Network Sonar Results Wizard and select or exclude what you want to monitor before you import into Orion.

Choosing Automatically means that you will define what to monitor up-front in the Define Monitoring Settings and the results will be automatically imported when the discovery is complete.

For now, let’s just stick with Manual

Now we come to the Discovery Settings. 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.

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.  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. 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