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 a 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 these 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 to 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 links 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 subnet 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 product 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 & 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 chose 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.
You know, 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 & 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 checkbox
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 checkbox,
but in this case it's asking you if you want Orion
to check whether any of the nodes are VM hosts.
If you're 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'll 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 a 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 anymore 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 chose a credential from the dropdown list
if you've 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 of the ways
that Orion will monitor your objects.
First, you can determine if your preferred polling method
is WMI or SNMP.
If you're running a discovery
in which you have more Windows device 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'll 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 upfront in the Define Monitoring Settings,
and the results will be automatically imported
when the discovery's 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 settings where you want them,
click 'Next' to schedule your discovery job.
You'll notice in the frequency dropdown 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 chose what time of day
you want the job to run.
Or you can chose the advanced option
and add a custom frequency where you have
a tremendous amount of control over the scheduling.
Here you can also chose 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 chose 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 to run later,
or to have it run on whatever future schedule you've set.
Personally, any time 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 some in the database.
But I tend to like to see how the discovery job runs,
what's it 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 chose 'No', don't run now,
and click 'Schedule' to save the job for later.
Then we'll go back and launch the job manually.