Skip navigation

One of the most appealing things about Orion is the ability to drill-down from high-level info into details.  You see something green or red on the screen, you click on it, you go to a view that has more details about the thing you clicked on.  It’s powerful yet simple.  That simplicity of interaction comes from a sophisticated object model.  Users almost always start at a Summary view.  Summary views typically show everything across the managed network—e.g., all nodes, or all applications, or all network interfaces.  If you click on a node from a summary view, you go to Node Details view. That view will show lots of information about the node. 


In most cases, for most devices, you will go to exactly the same Node Details view.  It’ll show the same data in the same locations on the screen, just for the specific device you clicked.  But it doesn’t have to be that way.  You can, for many devices, create a distinct view.  For instance, by default, wireless controllers have a different node details page because these devices include data that makes sense only for this device type (e.g., a list of “thin” access points).


The Orion construct we used to build the wireless view (and also the VMware ESX view) is Views by Device Type. We have a list of many common network devices that allow custom views; however, when we ship a new Orion, most of those views are set to the default view.  You can use this same technique we used to build your own custom views for particular devices.




Here’s a default view:






Here’s a view for wireless controllers.






How do you set up views by device type?  First, you need to create a custom view for a type of device.  Go to Admin > Manage Views.  From here you can add a completely new view or you can copy the existing Node Details view and then modify it. 




There are lots of resources to choose from in building something custom.






Next, you go to Admin > Views by Device Type > Node, then click edit.   You’ll then click the drop-down box and select the name of the custom view you created.   You can repeat for each node type, if you  want to get into serious customization. 






Note that we have the same construct for different of network interfaces, so you can customize there, too.






Views by Device Type allows you to further customize your Orion web console.  You might show different stats for Windows and Linux servers.  Or you might use different Custom HTML or User Links resources for HP Switches vs.Cisco switches.  Throw in a few universal device pollers, and you have a bunch of device-specific “dashboards”.  It’s a powerful feature that isn’t used as often as it might be, so give it a spin. 








Did you know that NPM offers audible alerts? It sure does - and they are super easy to set up. You may find yourself wondering - now why in the world would I need that? Well, you might find yourself work, work, working away and be completely oblivious when an alert appears in another window - or on another monitor. But, if you had sound - a customizable sound - then that would definitely help grab your attention. (When you think customizable sound - think any .wav file you like.) You might also worry that adding sound to alerts would really make a lot of racket in your workplace - no worries - we've solved that too. 

Here's how you do it (from the admin guide): 


Configuring Audible Web Alerts

When browsing the Orion Web Console, audible alerts can be sounded whenever new alerts are generated. When enabled, you will receive an audible alert the first time, after login, that an alert is displayed on the page. This alert may come from either an alert resource or the Alerts view. You will not receive audible alerts if the Alerts view or the alert resource you are viewing is empty.

Following the initial alert sound, you will receive an audible alert every time an alert is encountered that was triggered later than the latest alert that has already been viewed. For example, a user logs in and sees a group of alerts with trigger times ranging from 9:01AM to 9:25AM, and the user receives an audible alert. If the user browses to a new page or allows the current page to auto-refresh, a new alert sounds if and only if an alert triggered later than 9:25AM is then displayed.

To enable audible web alerts:

1. Log in to the Orion Web Console as an administrator.

2. Click Admin in the Views toolbar, and then click Account Manager in the Accounts grouping of the Orion Website Administration page.

3. Select the account you want to configure.

4. Click Edit.

5. Select the sound file you want to play when new alerts arrive from the Alert Sound list.

Note: By default, sounds are stored in the Sounds directory, located at C:\Inetpub\SolarWinds\NetPerfMon\Sounds. Sounds in .wav format that are added to this directory become available as soon as the Edit User Account page refreshes.

6. Click Submit.

And there you go. Sound!

We believe that CBQoS and NetFlow go together like peanut butter and jelly, but several of you commented that it was frustrating that you had to enable NetFlow on the interface to drill down to see CBQoS data.   Who are we to dictate how you like your CBQoS?   Well, the good news is with Orion NTA 3.6 you can have it any way you like it.

If you’ve upgraded to NTA 3.6, you’ll notice there are now two LAST RECEIVED columns in the NetFlow Sources resource:



As long as one of the LAST RECEIVED columns has a date/time stamp, then drill down is enabled and you can navigate to the respective interface details views.   You’ll notice that in the screen shot, Cur-3725 is not receiving NetFlow, but it is being polled for CBQoS data.

What if you don’t want to store all that CBQoS data in your database? Also new in 3.6, you can disable CBQoS data storage on specific interfaces.  Navigate to NTA Settings and click Manually Manage NetFlow Sources. You’ll see a dialog like this where you can check the boxes for both NetFlow and CBQoS.


We’re busy What we're working on... to CBQoS polling, so stay tuned and keep the great feedback coming!



Technorati Tags: SolarWinds,Orion,NetFlow,CBQoS,NTA

As much as I wish I could take credit for this, I can’t.  ljenkins figured this out and posted it to Twitter (Tweeting Alerts) a few months back, which the inner geek in me thought was pretty dang cool, so I wanted to blog about it.


Orion can send you an email or page when a network event occurs, but what about using twitter as a medium to distribute your network alerts and events?  Obviously you would not want to expose this to the entire twitterverse (which according to urban dictionary is a real word), so you can set your privacy setting to only share tweets with those who you expressly give access to.  In twitter go to Settings and in here there is a checkbox to protect my tweets, see below.




Here are the step by step instructions to get this to work with Orion.




1. Log on to your Orion NPM server using an account with software installation privileges.     
2. Download and extract the version of the cURL utility that is appropriate for your Orion NPM server from the cURL website.      
Note: For the purposes of this procedure, the cURL package curl-7.19.5 is extracted to C:\cURL\.      
3. Click Start > All Programs > SolarWinds Orion > Alerting, Reporting, and Mapping > Advanced Alert Manager.      
4. Click Configure Alerts.      
5. If you want to use Twitter notification with a new alert, click New, and then create your new alert. For more information, see Creating and Managing Alerts in the SolarWinds Orion Network Performance Monitor Administrator Guide.      
6. If you want to add Twitter notification to an existing alert, click the alert with which you want to use Twitter, and then click Edit.      
7. Click the Trigger Actions tab.      
8. Click Add New Action.      
9. Click Execute an external program, and then click OK.      
10. On the Execute Program tab, click Browse (...) next to the Program to execute field.      
11. Locate and then select C:\cURL\curl.exe.      
12. Add the following parameters to the selected program path:      
-u username:password -d status="message"      
Note: The following is an example of a complete path with parameters and alert text specified:      
C:\cURL\curl.exe -u UserName:Password -d status="ALERT! ${Caption} is ${Status}."      
13. Click OK on the Edit Execute Program Action... window, and then click OK on the Edit Alert window.      
14. Click Done on the Manage Alerts window.

This is a very common question we get.  What’s going on behind the scenes when a node goes into warning status, or when it’s actually down?  Well, it all starts with a simple ping.  Orion pings its nodes at regular intervals to determine the status of those nodes.  When Orion gets a response, everything is cool and the node is green. 


What happens when Orion doesn’t get a response?  When that happens, we can’t immediately assume the node is down, as there are a number of other reasons why the node may not be responding other than it being down.  In other words, we want to be really sure the node is down before we mark it as such.  How do we do this? 


First, on the initial missed ping we are going to put the node into warning status by marking it yellow.  When the node goes into a warning status, Orion initiates what we call a fast polling cycle where it pings the node every 10 seconds to try and determine if it’s really down.  If Orion doesn’t receive any responses during this cycle, it determines the node is officially down and marks it red.


There is one other piece to this, which is how Orion calculates a node’s availability over time.  What’s the difference between status and availability?  To keep it very simple, a node’s status is an indicator of what the node is doing now; a node’s availability is a measurement of that node’s status over time.  Orion calculates availability in two possible ways: either by historical node status, or by packet loss percentage over time.  We give you the option of specifying which calculation to use.  This setting is under Admin>>Settings>>Polling Settings (screenshot below).


Availability Calculation Settings.




I won’t go into a great deal of detail about these two settings, as you can read about them in the Administration Guide here; however, there are a couple of worthwhile points to mention about them.  First, Node Status is the simpler calculation.  It’s very straightforward; it basically looks at up/down status over time and calculates availability based on that.  This leads me to my second point: use the Node Status setting unless you specifically need to know node availability based on packet loss.  The Percent Packet Loss calculation is more complicated; don’t bother with it unless you specifically know you need it.

If you’re an Orion customer, you’re probably also a geek, which means you spend a non-trivial amount of time thinking of ways to improve the world around you---even things (or people) you love.  Since Orion is part of your world, you see ways to improve it.  Never content to just innovate privately, you post to thwack to share your vision of what might be.  That’s where Product Managers (PMs) come in.  We read all of those posts and we try to respond.  Sometimes we can’t say more than that the feature is on the roadmap.  For us, it means that we’ve heard the request often enough that we fully intend to do the feature, but we may not have a particular release slotted in.  Other times, we are actively working on the feature, which means it should be in the next release.  In that case, we post it on thwack as “…what we’re working on…” .  It’s not a promise because things get worked on and dropped, but it’s a pretty good bet.

To be fully up front, the other option is that you’ve just suggested a feature we’ve never heard before so it’s not on any roadmap.  With those unique features, we may probe other customers to see if they’re also interested.  Sometimes, the feature is just what they didn’t know they wanted.  Other times, it’s like we just asked them if they might want a three-armed jacket:  “Uh, that might be useful if I had that extra arm, but having just the regulation two arms, I probably wouldn’t use it myself.”

Now, once you’ve been told that a feature is on the roadmap or that we’re actively working on it, your inevitable next question is “Great!  When do we get it?”  That’s where the problems start.  We mostly can’t tell you, and even in a few cases where we might be able to tell you, we won’t.  Let me explain.  Sometimes, we really can’t.  In some cases, sharing information about a future date for a specific feature can impact how SolarWinds’ reports its revenue (because of a set of boring complicated accounting rules), which is a big deal for a publicly-traded company.  Consequently, we have to be extremely conservative about what we say date-wise.  Some customers point out that other companies do it, and maybe they do, but they’re probably not handling their earnings exactly the same way, and they’re bigger or have been public longer.  In any case, we are following the advice of our financial auditors.  I can tell you that we have spent quite a bit of time trying to achieve the maximum amount of transparency without crossing the line with our auditors.

Other times, we won’t reveal dates because it’s just a bad idea.  We could tell you that your feature is planned, say, for two releases from now.  We could even create a slide deck that showed your feature on a timeline.  But we won’t do it.  Every PM on our team has worked in traditional enterprise software companies.  We have all created a set of roadmap slides and flown out to see a large customers and showed them a 2- or 3-year roadmap.  We’ve made (or at least implied) promises about the future and how bright it will be when we deliver the features that the customer wants.  We’ve also eaten those promises.  Choked on them, really.  We didn’t plan to be liars, but things happened.  Things that are outside of PM’s control.  And sometimes changing the roadmap is just the right thing to do.  The reality is that software is a fast-moving and fluid business and that long-term promises always have a whiff of fiction about them.

In light of the slippery nature of software creation, we’ve had to decide how to communicate with our customers.  One of the important values inside SolarWinds is our relationship with our customers.  Consequently, we don’t want to lie to you.  I wouldn’t like to promise a friend that I can definitely go to lunch on a particular Thursday a year from now because there’s just too many ways that I might be prevented from showing up.  Next week, sure, but not next year.  We won’t make promises we don’t know we can keep.

That’s why when you ask for a date, we evade or just refuse to provide one.  Occasionally, a customer gets annoyed or frustrated.  We know it’s unsatisfying, and we regret it, but we’d rather you be annoyed at us not giving you a date now than having you furious because we had to change plans. In the end, we want to be completely honest and as transparent as we possibly can be.  Don’t let this post stop you from asking for dates.  By all means, ask.  If we can say “weeks, not months”, we’ll say something like that.  Ask for what you want to know, and we promise we’ll tell you as much as we can.

One of life's small frustrations now has an easy fix.

I exchanged emails with a customer who mentioned that it can be frustrating to page through pages and pages in the inventory report. If the view showed just a few more would be so much nicer as you could see much more on one screen.... but alas.... there's no setting for that.

Well, actually there is, but it's a bit roundabout.  You can change this: 


to this:

And... it's easy. 


NCM Standalone: 

Just go to  your c:/inetpub/solarwindsncm directory and find the web.config file. Find the line <add key="InventoryPageSize" value="20" /> and change it to something bigger – say 200 (or whatever you desire). Save it and voila – you’ll have a lot longer page view.


NCM Integration Module:

Go to the Orion web.config file and add the line:

<add key="InventoryPageSize" value="100" />


In the AppSettings section in Orions web.config file



    <add key="SWOISv2.RemoteEndpoint" value="net.tcp://{0}:17777/SolarWinds/InformationService/Orion/ssl" />

    <add key="SWOIS.LocalEndpoint" value="net.pipe://localhost/SW/InformationService/Orion" />

    <add key="SWOIS.RemoteEndpoint" value="net.tcp://{0}:17777/SW/InformationService/Orion/ssl" />

    <add key="DisableBreadcrumbs" value="false" />

    <add key="InventoryPageSize" value="100" />


Save it and you are done. Feel free to experiment with the line length until you get the report view just right. 


So I am sitting here in our European office trying to decide what to write on.  I was catching up on my thwack posts since I was in Barcelona last week for Cisco Live (aka Networkers) and have seen some discussions on thwack recently from some of you and I keep hearing about the Weather Map like we have on the online demo.   Hmmm seems like a great idea for a post!!


I am going to describe this setup using 9.5 and above. 


1. Using Network Atlas, create a new map and click on Linked Background in the top ribbon bar and you will receive a dialog to specify the URL to the weather map image you wish to use. 


2. Enter the url and click validate to ensure we can retrieve the image ok from the Orion server and once the validation is successful, click ok.  In this case below I specified Europe since this is where I am currently at, as you can see, it is freaking cold here.




3. Drag onto the map your nodes or other maps you want to have on this image and save the map.


4. You can edit your map resource on the Summary Home page to show this map.




Now your map on you Network Summary home page will always show the current weather based on when the page refreshed.

Filter Blog

By date: By tag: