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.
