1 2 3 4 5 Previous Next

Product Blog

74 Posts authored by: bshopp Employee

In the spirit of getting folks more excited about the next version of NPM (10.2), which is currently in Beta, I wanted to do another blog post on one of the new features coming.  We have invited folks in a couple previous posts (you can sign up here), along with highlighting some other features Orion NPM vNext Sign Up for Beta 3 & tell us what you think of improved Juniper support and many other features and improvements and Orion NPM vNext Sign Up for Beta & – Tell us what you think on the feature Multi-CPU Polling.

Over the past several months there has been tons of press over the exhaustion of IPv4 addresses and the need to move to IPv6 as soon as possible.  With this, there is plenty of debate out there as to how much truth there is in terms of the severity of this problem and I am sure we all have our respective opinions, but at some point in the future IPv6 will find its way into most networks out there.  Where we see heavy adoption and usage today of IPv6 are with Service Providers, Federal Governments and in the Asia Pacific region of the world.  With this in mind, we have been working across our different products to ensure they are ready for when folks move to IPv6.  Today, SolarWinds NCM, IPAM and Engineers Toolset have some level of support for IPv6 and now we are adding SolarWinds NPM to this list of products.

Just as you manage IPv4 devices today, you will be able to do the same for IPv6 devices.  Whether you are running them in a dual stack setup (which is the most common we hear about), or pure IPv6 mode; NPM will be able to handle it. 

  • Within NPM you will be able to add IPv6 devices manually or using the bulk upload feature within Network Sonar. 
  • Once managed in NPM, it will be presented like any other node in Orion.  As illustrated in the first couple screenshots below, you can group by IP Version now to distinguish v4 vs. v6 devices.
  • As highlighted in this next screenshot, you as the user should see no different experience from a data collection or user flow standpoint.  Only noticeable differences are in the method we communicate to the devices.
  • This will be exposed in reporting, searching, Syslog, SNMP Traps and other native features existing in NPM today.  You can reference the third screenshot as an example of search with IPv6.
  • image

Let us know what you think.  Are you moving to IPv6 yet?  When do you plan to start the transition?

Title: Creating High Availability and Fault Tolerant Environments using SolarWinds Failover Engine


Date/Time: Thursday August 18th, 2011 @ 11:00 AM CDT      


GTW link: NA Only- https://www1.gotomeeting.com/register/367301032




Join us on August 18 when we discuss the SolarWinds Orion Failover Engine and how it can help you maintain 100% Orion IT management coverage through a variety of outage situations. During the session we will discuss:

  • Deployments for high availability and disaster recovery
  • Server and application protection capabilities
  • Best practices for protecting Orion services
  • Protecting Orion modules and additional pollers
  • Best practices for SQL redundancy

This 60 minute training session on Orion Network Performance Monitor (NPM) and SolarWinds Application Performance Monitor will cover optimizing hardware configurations for Orion, installation, discovery, and base configuration, configuring reports and alerts, and leveraging the information that Orion provides.


To register and view please visit the following -  http://www.solarwinds.com/resources/webcasts/npm-and-apm-level-1-customer-training.html

As we posted Orion NPM – So what’s up next? some time back, there are many great new features we are working on for the next version of NPM.  We are currently wrapping up a successful Beta1 with a set of customers and are just about to enter into Beta 2 in the coming weeks. 

First, I would like to invite and encourage any NPM customers with active maintenance to sign up to participate in Beta 2 and give us feedback.  The earlier we get feedback, the more tweaks and changes we can incorporate into the product, plus you get to play with the new stuff early :)  If you are interested in Beta 2, you can sign up here.

For those of you that don’t have the bandwidth to participate in the beta, I wanted to walk through one of the new features in this release and allow you to give us some feedback via the blog as well.

So first, what’s going to be available in Beta 2?

  • IPv6 Support – ability to poll and monitor IPv6 nodes just like you can today with IPv4
  • SNMPv3 Trap Support – ability for Orion to receive & send SNMPv3 traps
  • Multi-CPU Polling – the ability to poll and visualize multi-CPU machine in Orion (see below)
  • Windows Server Polling (non SNMP) – since SNMP is not on by default on Windows, this now gives users the option to discover and poll Windows machines using WMI
  • Improved Topology (more accurate ConnectNow) – we are removing the dependency that Network Sonar must be used to gather topology, it will now be a polling job.  Also we have greatly improved the accuracy of L2 topology and added in L3 support.
  • Network Atlas performance improvements – faster loading of maps in the web console
  • Procurve 420 support – more out of the box Wireless support

If you can’t participate in the Beta, no worries, we will have a Beta 3 as well, so maybe then.

I wanted to take the rest of this post to discuss and get feedback on one of the items listed above, multi-CPU polling.  This is one of the smaller features, but cool none the less. 

How it works today for multi-CPU machines is we gather all the values, but then average them and that is what you see displayed in reports, charts, gauges etc.

As of the next version, you will be able to report, alert and visualize these types of machines by CPU.  So we do not plan to take away any of the existing resources, reports etc.  You will still have the gauge that does the average and the Min, Max and Average CPU Utilization chart.  What we will be adding is two new resources, as illustrated below in the first image, that will break out each CPU’s usage over time in a chart, but also the current value in a table format. 

Also, on the node details resource, we will add a row, as highlighted in the second image, that lists out how many CPU’s that machine has.  This new feature will not only work for Windows, as shown in the screenshot, but also other server OS’s and network gear.





Date/Time: Thursday July 7, 2011 @ 11:00 AM CDT      


GTW link: https://www1.gotomeeting.com/register/567572777




Please join us for an exclusive training session on Orion Network Performance Monitor (NPM) and SolarWinds Application Performance Monitor.


During this 60 minute training session we’ll cover:

  • Optimizing hardware configurations for Orion
  • Installation, discovery, and base configuration
  • Configuring reports and alerts
  • Leveraging the information that Orion provides

This training is most beneficial to current new users of Network Performance Monitor and Application Performance Monitor and will be hosted by Andy McBride, Technical Support Specialist and Jason Ferree, Technical Support Representative.

Title: A Case Study in Best Practices for Network Management


Date/Time: Thursday June 23, 2011 @ 11:00 AM CDT


Sign-Up:  https://www1.gotomeeting.com/register/390327232




Discover how SolarWinds IT management solutions are helping state, local and education organizations maximize their dollars and do more with less. Join us as we discuss the solutions and practices deployed by Monroe City Schools, and how they can be applied to other environments within the education, state and federal government space.

Lately I have had a couple conversations with some of you, and it became clear that there is some confusion lately on standalone vs. module in Orion means.  Do I get less functionality if I deploy one way or the other?


First, let me set some context for those of you not familiar with what I am talking about.  Until recently, if you wanted to purchase our SolarWinds Application Performance Monitor (APM) or SolarWinds IP Address Manager (IPAM) product, then you had to own Orion Network Performance Monitor (NPM).  Now, with the most recent releases of both of these products, this is no longer true.  We also just recently released a new product, SolarWinds User Device Tracker (UDT), which can be installed either way as well.


So why do this?  It seems confusing.  There are two main reasons:

  1. Some folks came to look at SolarWinds whose need was just for Application Monitoring or IP Address Management, but they already owned an NMS and didn’t need or want to purchase our NPM product.
  3. In other cases, we had existing customers of NPM and other teams/groups within their organization saw it, learned that we had APM for apps and servers, and they wanted it; however, the two groups did not want to share the same database because they had different approaches to the product (or they just hated each other, or whatever). 

Question: Do I get different functionality by installing standalone vs. a module?  Meaning do I get functionality by installing one way that I do not get installing the other way? 


Answer: No, they are identical in functionality.  The only difference is that if you own NPM currently, then purchase APM and choose to deploy standalone and not as a module.  In that case, you would now have two web consoles, two database, etc. so you will lose the single pane of glass.  I have put together an image, below, to help illustrate this.




Question: If I want to deploy as a module, does NPM have to be the base or can any standalone product be the base/initial product. 


Answer: Any standalone product (with the exception of NCM) can be the base product and the other standalone products can be installed on top as modules.  The only products which have any relationship/dependency is IPSLA Manager and NTA, which both require NPM to be present, see the below image as an example.






The ultimate goal of this decision on our part was to give customers more flexibility in deploying our technology.


So which Orion-family products can now be deployed as either stand-alone or a module and which can only be deployed as a module for Orion?


Stand-alone or Module:

  • NPM
  • APM
  • IPAM
  • UDT

Module Only (requires NPM):

  • NTA
  • IPSLA Manager

Virtualization Manager (formerly Hyper9) and Storage Manager (formerly Storage Profiler) live on a different platform, and while we do have or will have integrations with these products, the standalone vs. module discussion doesn’t apply.


The Magic 8 Ball in Orion

Posted by bshopp Employee Apr 14, 2011

I walk into one of our Development Managers office on a weekly, if not daily basis, asking for a feature or bug fix and to mess with me he has a magic 8-ball on his desk he likes to shake up and make the decision.  I am sure almost everyone has either owned or played with one of these things where it gives you responses like “outlook does not look good”. 



I bet most of you have come across a situation where a manager or someone else comes up to you and ask questions like:

  • when is that disk drive going to run out of space?
  • how far out are we from maxing out the capacity in the link out to the Internet?
  • based on historical usage of the CPU on this box, when are we going to max it out?

It is a bit like pulling out the magic 8-ball and giving it an nice big shake.


Well not anymore.  There is a cool, little feature in Orion which many folks do not know about which allows you to do trending analysis, with much more accuracy than the good ole’ Magic 8-ball.


We use a method called “Least Square” to perform this analysis.  If you are interesting in reading all the geeky stuff on this algorithm, check it out here.


Let’s walk through how do do this in Orion using the disk drive example above.  Your manager comes in and is doing budget planning for the next year and need to know if this specific server is going to need a drive upgrade or not.  In the Orion web console you drill down to the server in question and select the drive and get a nice chart like you see directly below.  It looks boring and flat and only using 14gig of 39.9gig, plenty of room for the next year right? 




If you now select “Edit Chart” in the drop down you will get a new page, where under the Time Period heading, you can select custom.  Enter a date in the past and then a date in the future, say six months out and click refresh.




The result will be chart where based on the historical we have gathered and stored you can see you have plenty of room and overall is on a downward trend.






This feature work with Volumes, Interfaces, CPU, Memory, etc. 


Still keep the Magic 8-ball on your desk to mess with people, but now you can give you manager much more precise data for their budget capacity planning exercise.

It has been a busy week and a half in the browser world with both IE9 and FF4 being released to the world.  Like myself, many of our customers either have already upgraded or want to upgrade their browsers to the latest and greatest, but have called us to see if we support them yet.


The formal answer is no, not with the shipping products today.  We plan to support them in versions later on this year depending on the product you are asking about (Orion, Profiler or Hyper9).  For Orion, we plan to add support for these two product versions in the next release of size, including dropping support for IE6.  I blogged about this a few weeks back and you can read Announcement of end of support for Internet Explorer (IE) 6 in next Orion NPM version. Also, when I say release of size, this does not mean a Service Pack or a Service Release. 


If you choose to brave out on your own and use these browser versions, there are a couple issues we know about.  The largest one is with Firefox 4, in which if you currently try to go to the Orion web browser from your PC, you will get the mobile view of Orion instead.  Here is a manual workaround to this.


On the Orion server, open <drive_installed_on>:\Inetpub\SolarWinds\bin\web_browsers_patch.xml  
Add section within Devices section:   
<!--  FireFox4 -->   
        <device user_agent="Mozilla/5.0 (rv:2.0b10) Gecko/20100101 Firefox/4.0" fall_back="firefox" id="firefox_4_0">   
            <group id="product_info">   
                <capability name="model_name" value="4.0" />   


That’s it, any questions, please feel free to let me know.


We added a feature back in Orion NPM 10, however, over time I have gotten this questions from folks and seen Parsing Trap Text For Alerting on thwack come up asking if you could do this in Orion and if so, how? 


Background on the problem people are trying to solve:


An SNMP Trap sent from a device is a general blob of data with some standard data followed by vendor defined information called variable bindings; see the example below for how this looks.


These traps have additional information sent with them called variable bindings. These extra variables contain information relating to the trap and ya’ll don’t want to have to visually parse each trap manually.  What you have asked for is some sort of variable notation allows the capability to format and display these variable bindings as needed.  


With this ability you can format an email notification with the separate variable bindings.  So instead of receiving an email with the block of text below in the example, you can get only the specific information you care about.


An example of of our community members posted on thwack was this.


What I want is the "apSvcTrapEventText" line with just "Service:test State:suspended" in the email.  How do I format the email text to get it?


When creating the email notification template in Orion, you can do something like this below, where ${vbdata3} equals the value associated with the third listed trap variable.




${Caption} - ${vbdata3}



03/08/2011 08:20 : ARROWPOINT-SVCEXT-MIB:apSvcTransitionTrap SNMP Trap  
Received Time:3/8/2011 8:20:32 AM  
Variable Bindings  
sysUpTime:= 2 days 13 hours 35 minutes 55.25 seconds (22175525)  
snmpTrapOID:= ARROWPOINT-SVCEXT-MIB:apSvcTransitionTrap (  
apSvcTrapEventText:= Service Transition - Service:test State:suspended  

Let’s walk through an example of this in the product.

  1. On the Orion server, open the SNMP Trap Viewer
  3. As you can see I have a specific trap, but I don’t want all the information included within it, I just want SysUpTime     
  5. Create a new trap rule in the SNMP Trap Viewer and define your filters to narrow down to the specific trap you are interested in.  In this example, I did it by IP Address.
  7. On the Alert Actions tab, select add a new alert action.  I chose log to a file, but this would work with the others as well, including email
  9. In the dialog “Message to Log File” I entered in three variable.     
    • Date/Time Stamp
    • Name of the first trap variable
    • Value of the first trap variable         
  11. In my text file I chose to log to, there is an entry for each trap I have received that matched this rule.  As you can see, instead of getting the entire trap message, I only get the value as defined by my variables in step #5 above.     

That’s it, pretty straight forward. 

When I talk with a customer and get the question, “how does Orion scale?” My answer is the customer can choose one of two ways to scale.

  1. By adding Orion Additional Pollers to scale horizontally
  2. By deploying multiple Orion instances and rolling up into the Enterprise Operations Console

In this post, we are going to discuss the Enterprise Operations Console or EOC for short.  EOC’s main functionality is to aggregate data from multiple Orion server installations and to display it in a similar fashion as the Orion Web Console.


Take the below first graphic, you have a worldwide network with teams responsible for managing their respective geographies, so an Orion installation resides in each North America, EMEA and APAC.  The global NOC and Management Team requires a single rollup of all servers into a single installation for status, alerting, reporting etc.

Orion EOC aggregates the current status of your Orion NPM servers and presents this data in the Orion EOC Web Console. Administrators can restrict what Orion NPM data each Orion EOC user is permitted to see. These restrictions can be set on an individual basis by customizing user settings and on a group basis by defining roles.



In the EOC web console, here is what you would see as illustrated in the second screenshot below.  One of the common misconceptions about EOC is that it pulls all the data from each of your Orion servers into the EOC database.  In actuality, EOC pulls high level information like current status, alerts, events, syslog and traps.  Any data beyond that, when you click on that item in the web console, you are seamless redirected behind the scenes to the Orion server that item resides on.  Let’s walk through an example.

  1. Looking at my EOC dashboard I see that under the “Global Nodes with Problems” resource, that Switch sales is down.
  2. I click on switch sales and am automatically redirected to the node details page for device Switch sales and logged into the Orion server Orion America as that is where that node resides for monitoring

I can now perform my investigation and go right back to my global EOC dashboard.


Now that we have gone through a high level of what EOC is an example use case, let’s get in deeper on how it works.  I have taken my first image from above, but broken it down to a “how it works” level.  EOC is comprised of 4 main components:

  1. Orion Poller
  2. Information Service
  3. Website
  4. Database.


EOC pulls the following type of data through the Orion Information Service:

  • Alerts, Events, Syslog, Traps (last 24 hours worth of data)
  • Node, Volume, and Interface data (no historical data)
  • APM data (no historical data)
  • NetFlow (no historical data)
  • IPSLA Manager (no historical data)
  • Wireless (no historical data)
  • NCM (no historical data)
  • UDT (no historical data)
  • IPAM (no historical data)
  • Support for displaying Orion Groups

The Information Service (IS) module will exist in both EOC and Orion products. The service will provide a single point of communication and a simple and efficient mechanism to query the servers.  All communication with the IS module is encrypted using SSL and is on port 17777.

The Communication module uses Windows Communication Foundation (WCF) as the basis of its communication mechanism which allows other applications, websites, scripts, and application modules to seamlessly communicate with it. WCF also provides secure, reliable, and several transport and encoding options. It will allow us to easily build several types of messaging protocols such as REST, SOAP, etc.

The IS module provides a simple query interface that allows the client to execute a read-only query written in SolarWinds Query Language (SWQL). SWQL is very similar to the commonly used SQL language with a few deviations.

When typically asked how does EOC scale or how many Orion server can EOC handle, as a typical rule of thumb I say a customer roll up 20-25 SLX’s into a single EOC instance.  With this being said, if they want to roll up more smaller installations, they can, as long as the total number of elements feeding into the EOC is not more than about 600k.

We also get frequently asked some rough ideas on how much traffic to anticipate between the Orion servers and EOC.  While this is very variable, the below chart can start to give you an idea of what to expect.


















625 KB









700 KB









822 KB









479 KB









1.183 MB






3 Apps, 37 Components

1 Source


1.277 MB

There you have it.  From high level what is is, down to how it works, hopefully this helps shed some light in one of the many different ways you can deploy the Orion family.

In two previous blog posts I have introduced the Failover Engine and walked through some common Q&A we received right after launching the Failover Engine last year.

In this blog I wanted to get down into the nuts and bolts of how the Failover Engine actually works under the covers.  When it comes to protecting an application, there is more to it than just watching the services. You need to watch and protect the entire Application stack.  On your Orion server, the following components exists:

  1. Services
  2. Registry Settings
  3. File System Structure
  4. Web Server (IIS)

We could just watch the Orion services and be done with it, but the problem with this is that you must then maintain your secondary failover server with the exact same configuration and settings manually.  If/when a failover condition occurs and your end users notice reports or setting changed or missing, then you are going to get a call.  Also, what if the problem is not with Orion itself, but something is going on with Microsoft IIS?  Since the Failover Engine is watching and protecting the four areas above, as also illustrated in the below image, you do not have to worry about these scenarios as they are covered.  




Let’s walk through each of these four areas in further detail.

  1. Services   
    As shown above the Heartbeat is checking periodically that all the services are up and running.  The Heartbeat portion of the application is responsible for the data replication, switchover and failover processes.  The protected service list is created dynamically by looking at a specific registry setting that we write to on product installs.  So as long as you have the appropriate license, if you install a new module then protection is automatically picked up. For the given services being monitored, within the Failover Management client you can specify behavior (you can define up to three steps per service), like which services are the most critical and when to initiate a failover. Example, SolarWinds Syslog Service:
    1. Service fails
    2. First attempt- restart the service
    3. Restart fails – second attempt restart the entire Orion application
    4. Syslog service still fails, then initiate a failover to the secondary server
  2. Registry Settings   
    As I discussed above, there are key critical registry settings the Failover Engine watches and replicates between the primary and secondary server (more details on replication below).  These include things like licensing info, SolarWinds directory locations and registered SolarWinds services.  This is the reason you don’t have to buy two copies of Orion.  Since only one copy Orion is running at any given time and the registry is in sync you don’t need two license keys.     
  3. File System Structure   
    With Orion most data is stored in the database, so why is this important?  There are files which are important to the use and operation of the product which need to be replicated across servers.  Examples include report template definitions as you may create a set of custom reports.  From a back end operational standpoint the service SolarWinds Job Engine has a small database we install that handles the job dispatching and processing, which is also very important to keep in sync.  Here are some key items to know about the replication portion of the Failover Engine
    • If for some reason the channel between the two servers is broken, the Failover Engine will queue up the replication changes .  When connection is re-established, we will restart replication to verify data sets are the same.
    • Near real-time byte level data replication is provided between the active and passive servers.  Byte level replication ensures that only file deltas are replicated and not whole files or transactions.
    • Near real-time byte level replication works within the Windows kernel to ensure that near real-time data changes are sent from the active to the passive (secondary) server and once the process is complete. Below is a basic overview of how this process works.
      1. Data change is requested
      2. Failover Engine Filter Driver intercepts the request at the I/O leve
      3. Failover Engine Filter Driver checks the replication settings to see if this change needs replicatin
      4. Failover Engine Filter Driver generates a unique sequence number for the replication reques
      5. Failover Engine Replicates the data and also sends the change on to the windows file syste
      6. Windows commits the data change and sends confirmation to the application laye
      7. Failover Engine Filter Driver intercepts the confirmation
      8. Failover Engine replicates the confirmation to the passive server if require
      9. Data change process is now complete
  4. Web Server (IIS)   
    Orion services can be up and running just fine, but users may be complaining that the web console does not come up or is slow.  Is IIS running?  Failover Engine watches IIS at a service level; you can also define checks & tests to ensure the website is up and responding within an acceptable period of time.

Let’s switch gears now to licensing/packaging. Since one of my previous Failover Engine posts, APM and IPAM have released new versions which can be deployed as a module (as you could always do), but now both can be installed standalone without requiring NPM as well.

We still license by what we call a “primary product” per server. Previously, what was classified as a primary product were Orion NPM, APM and NCM.  This is where the change comes in, prior to IPAM 2.0 you could only install IPAM as a module, we didn’t charge for protecting it.  If you still deploy it as a module, this remains true.  If you purchase IPAM and choose to deploy it standalone and desire Failover Engine protection, then you will need to purchase the Failover Engine for One Primary Product.  Now that we have release SolarWinds User Device Tracker or UDT, it also behaves the same way IPAM does here.

Let’s walk through two different examples.

  1. Orion NPM, IPAM and NTA – you will need Failover Engine for One Primary Product.  Since NPM is considered a primary product and IPAM is installed as a module, you get protection for IPAM for free.
  2. Orion IPAM only – you will need Failover Engine for One Primary Product.  Since you are deploying IPAM as a standalone you will need to purchase a license to protect it.

One last scenario with the release of UDT or User Device Tracker.  Since IPAM and UDT are not considered "primary products" as described above, what if I purchase UDT and IPAM and want to protect both of them with FoE, what do I need to buy?  The answer is you just need an FoE for One primary product in this scenario.

Any questions or comments, please post them.  As I have illustrated in this post and the two previous posts I referenced at the start of this post, the Failover Engine product is very feature rich and more than just High Availability/Disaster Recovery, but more about Application Availability.

A long, long time ago in the year 2010 if you wanted to run Orion APM and IPAM you had to own Orion NPM.  With the launches of APM 4.0 and IPAM 2.0 earlier this year you can run either product as a module or standalone – that is, without installing NPM first.  To enable this we had to remove the dependency of requiring NPM.  So over the past year we have been making this separation into what we call “Orion Core”.


Obvious next question is “What is Orion Core?”  Orion Core is the base set of infrastructural functionality or services needed for a product to run standalone.  Examples include user authentication, syslog, traps, reporting, website, database etc.


Our goal was to make the concept of Orion Core as seamless and transparent to you, the end user, as possible.  As an example of this, let’s say you purchase APM.  What you download APM from the Customer Portal, it is one set of bits as you can see in the below screenshot.  After you download and as part of the installation process, we automatically figure out if you are installing on top of some other Orion product as a module or if this is a standalone installation.




So at the footer of the Orion web console, you now see the below screenshot in the latest versions.  Most users should never need to worry about Orion Core.  For a few of you, however, understanding what Orion Core is would be helpful, and specifically, those are the folks with Additional Pollers and Additional Web Consoles.




As many of you know, we only charge customers for the initial instance of an additional poller or additional website per Orion installation.  Since in the past everything in the Orion family required NPM in order to be run, you saw Orion NPM 10.0 Additional Polling Engine or Orion NPM 10.0 Additional Web Server in the customer portal.


Example from the past:  I have Orion NPM & APM on a single server.  I have purchased an additional polling engine.  I download my Orion NPM 10.0 Additional Polling Engine and install it and since APM supports an additional poller as well, I can install the APM additional poller at no additional cost to me.


Even though customers can now purchase APM standalone, this scenario is still valid and true.


The new scenario is I purchase Orion NPM, APM and a single Orion Additional Poller.  As outlined in the below diagram, I am going to install Orion NPM and APM on different servers since different teams will be responsible for using and managing their installation.  Both server installations each need an additional poller for scale.  Can I use the single Orion Additional Poller purchased on both servers?  The answer is no, the user will need to purchase one more Orion Additional Poller.




Below is what you now see in the customer portal for Orion Additional Polling Engine and Additional Web Server.  Since this is specific to the Orion Core version I discussed earlier we can’t put a normal product version on it like NPM 10.1 or APM 4.0 since it could be used on either.




Key takeaway from this thread is the following:

  • If you don’t own Orion Additional Pollers or Additional Web Servers, don’t worry about Orion Core
  • If you do own an Orion Additional Poller or Additional Web Server, make sure what you download and install matches what is in the web console for the Core version (aka 2010.2 or 2011.1 etc.)

The internet browser market has been very busy in the last year in terms of new versions and adoption of new browser platforms. 

  • Internet Explorer 9 is currently in Release Candidate
  • Firefox 4.0 is currently in Beta

You can view usage statistics for last month, but also over time here - http://en.wikipedia.org/wiki/Comparison_of_web_browsers


With each release we evaluate usage statistics available on the web, but also looking at data from thwack.com and solarwinds.com.


As we are in planning stage for the next NPM release, when we release this version (meaning later this year), we will be formally dropping support for Internet Explorer 6.

The NPM team is busy at work on a number of highly requested enhancements:

  • Web performance improvements
    • General tweaks and enhancements to web console
  • Improve Orion product/module integration user flow
    • Enhance UI navigation linking together data between products and more intuitive layout of data on pages
  • Improved View Management/Graphical Reporting
    • Usability enhancements on creating new Views or Dashboards within the Orion web console and scheduling those to be delivered as reports to end users
  • User Audit Trail Tracking    
    • Ability to determine who did what and when in the Orion system. e.g. add node, delete node, add interface etc.
  • SNMPv3 traps
    • Ability to receive not only SNMPv1 or v2 traps, but also SNMPv3 traps.
    • IPv6 Support
      • Ability to add and poll device via IPv4 or IPv6
    • Internationalization
      • Stronger support for users installing and running NPM on non-English operating system

    PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

    Filter Blog

    By date: By tag:

    SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.