Skip navigation

Product Blog

4 Posts authored by: cdoyle Support

Interested in upgrading to SAM 6.2.1? Here’s all the information you might need to upgrade, and the steps you’ll need to take to do it quickly and easily.

 

Prepare your Upgrade

1. Check the Release Notes for Orion SAM 6.2.1

2. Review the system requirements and ensure your server is up to spec.

3. Back Up your Database (Microsoft KB Links: 2005, 2008, 2008 R2, 2012)

4. Check your upgrade path

    • For a quick shortcut if you have only SAM installed, this is the standard upgrade path:  SAM 5.0 SAM 6.1 SAM 6.2
    • To confirm which version of SAM you’re currently running, check the footer of any page on your Orion SAM Web Console.
    • If you’re running NPM or any other modules with SAM, use the Product Upgrade Advisor tool to get an exact upgrade path to ensure you maintain compatibility while you upgrade.

5. Download the required versions from the customer portal

 

To download the current version, and any previous versions you require, you’ll need to log into the customer portal. Once you’ve logged in, use the License management menu to select ‘My Downloads’.

customer_portal.png

Next, select the product you want to download

mydownloads.png

And under the Server Downloads section, you’ll see the latest release selected by default. If you need an earlier version for your upgrade path, you can select it from the drop-down menu.

versiondownloads.png

 

 

Complete your Upgrade

  1. Log into your Orion SAM server using the Local Administrator account to perform the upgrade.
  2. Run the installations, in order, to upgrade your product - the upgrade can be installed 'on top' of your existing older version.
    1. If you’re unsure of what order to use for the upgrade use the Product Upgrade Advisor tool for guidance.
    2. You’ll find the upgrade instructions for Orion SAM here, and a wealth of documentation, including upgrade and installation guides for all our products here.
  3. Always complete the configuration wizard before moving on to the next step!
  4. Got additional polling engines? You'll need to upgrade each of them at each step in the upgrade path to ensure they maintain compatibility. Make sure you upgrade your main poller at each step first, then update the additional pollers to match, for that step of the upgrade. Again, always complete the configuration wizard before moving on to the next step or the next polling engine.

 

 

If you run into any trouble during your upgrade, call us in Support on our toll-free numbers or submit a ticket – we’re happy to help!

 

 

 

Got a question that wasn’t covered here? Try these resources for help:

Orion SAM Product Page

Orion SAM Product Training

Upgrading SolarWinds Orion when FailOver Engine is installed

Migrating SAM to another server

Manual License Registration

In my last post, I spoke about different ways to Alert in NPM, pairing multiple features together to create powerful ways to create granular alerts and to really reduce on alerting noise.

 

Well, that’s all well and good in a perfect world, where all of your devices are reporting the correct data – but what can you do if they aren’t? If your device is providing the wrong data for CPU and Memory for example, it’s no longer possible to alert accurately on that node. Or if we’re showing the vendor as ‘Unknown’ then it’s hard to use a qualifier like ‘Where Vendor = ABCDXYZ’ to define your alert scope.

 

We poll certain OIDs for different device types with our Native Pollers – OIDs that we’ve carefully chosen for certain vendors or models that work for the vast majority of those devices. But sometimes, those default OIDs aren’t a perfect fit. Sometimes, the device should support an OID, but it doesn’t. Other times, we might not have a Poller created for that particular device model yet. (When we say Poller, we mean gathering specific data from an OID or group of OIDs – for example, CPU & Memory, Hardware health sensors, Topology data and so on)

 

Luckily, there’s an easy and quick way to swap in new Pollers, or create your own ones, and start polling these devices accurately - Device Studio!

 

Never heard of it? Check out this video.

 

So, let’s talk specifics about Device Studio, and show you the exact steps you can take to fix a device that’s providing inaccurate information. On your Orion Settings page, look under Node & Group Management for the ‘Manage Pollers’ option:

pic1.png

Let’s assume you have a problematic device, providing the wrong CPU & Memory details. Fixing this is a two-step process.

 

#1 – Find the right OIDs to poll to get accurate information


This one will need a little legwork! Check Thwack and the Content Exchange first (or click the Community tab to download directly from the Manage Pollers page) – after all, no point in re-inventing the wheel when the awesome folk on the forums have shared their successes! If that doesn’t work, you’ll often find all the information you need by plugging the device model, what you’re looking for and the word ‘OID’ into Google – chances are if you’re looking for this information, someone else was too. If that fails you, turn to the device documentation.

 

If you’re brave and curious, you can SNMP Walk the entire device to get a list of every single OID it supports. The best part? We ship an SNMP Walk tool with your Orion install – you can find it here:

[Install Drive]\Program Files(x86)\SolarWinds\Orion\SNMPWalk.exe

pic2.png

I’m an SNMP geek, so if I get into writing about how to read an SNMP Walk, you’ll never hear the end of it – so I’ll leave you with this handy guide on SNMP to get you started on reading the output and choosing the right OID from it to poll your device.

 

#2 – Using the OIDs, set up a new Poller, and assign it to your device

 

    1. In Device Studio, click ‘Create New Poller’

    2. Fill in the details about this new poller

pic4.png

    3. On the next page, you will see a list of all required information for this Poller. For example, to poll CPU & Memory, Orion needs to know where to get details of the current CPU load, Memory used and Free memory.

pic5.png

    4. For each of these details, you’ll need to define the data source – this means, you’ll need to define what OIDs Orion needs to poll to get accurate information from your device.

    5. You can browse the MIB tree itself, testing OIDs against your chosen device as you go.

pic6.png

Alternatively, if you already know the OID you want to poll, go ahead and enter it under ‘Manually Define OID’
pic7.png

    6. Once you’ve chosen the data source, you’ll be asked to confirm if that data is reasonable and accurate. You’ll have the option here to perform calculations on the polled result – for example, to get an average across CPU cores, or combine multiple pollers together – this is very useful for Memory, as often, the data is stored as the number of blocks used / free – which then must be multiplied by the block size to get an accurate result.
If you’re happy with what you see, click ‘Yes, the data source is reasonable’.

pic8.png

     7. Almost there! Once you complete the wizard, choose your shiny new Poller from the list and select the ‘Assign’ button.

Select the node or nodes you need to assign this poller to, and run a Scan against them – this confirms that they will definitely support those new OIDs. If they pass the test with a Match, you can Enable your new poller, replacing the Native poller.

pic9.png

     8. If you need to swap back again for any reason, just run a List Resources against the Node, and you can toggle back and forth between your pollers.

pic10.png

And there you have it!

 

But wait – I also mentioned that you can use the Device Studio to fix those pesky devices that show as ‘Unknown’. If you do have devices that show up with the Vendor as Unknown, we’d still like to hear about them so that we can match them natively – but if you’d like to fix this yourself without waiting for the next release, you can use Device Studio to do this, and you can even use these steps to correct any devices that respond as ‘NET-SNMP’ instead of the correct Vendor & MachineType.

 

Much of the steps will be the same as above – you’ll just be creating a ‘Node Details’ Poller instead.

 

When you define the Data Sources for Node Details pollers, you’ll notice a lot of these are optional – but one is absolutely required: the SysObjectID.

pic11.png


The SysObjectID returns an OID that references another part of the MIB database – usually the Vendor’s MIBs, and can be used to identify both the Vendor and the Model of the device. It’s quite rare that this one isn’t supported by a device, so try to let Orion poll the SysObjectID automatically if at all possible. If the device doesn’t support this OID, you can use a constant value instead, and manually define the OID that should have been returned by the device.

pic12.png

Now, with the required OIDs done and out of the way – you can move on to fixing that Vendor = Unknown problem – and that part is quick and simple. Set the Constant Value to the text string you want it to report for both the Vendor, and the MachineType.

Vendor.png

So, there you have it – a great way to clean up those ‘Unknown’ devices, and take care of the devices that respond with incorrect information, all in one place.

I’ve been with SolarWinds going on 8 years now, working with the Support Team, so it came as no surprise to me when I saw how many of you answered our poll last month that Alerts, specifically, filtering out the noise from the real issues, was your top priority problem to solve in the next 30 days.

 

So, with that in mind, I’ve put together three powerful tips that could help you to achieve this goal, and I’ll discuss some of the common alerting questions that we tend to get in Support along the way.

 

NPM has awesome alerting capability, and when coupled with some of the other Orion features, it’ll let you get really granular – so yes, you really can cut down on a lot of that noise!

 

Tip #1 – Use custom properties with alerts for a powerful combo

Custom properties allow you to define any property you like that doesn’t already exist in Orion. The possibilities are endless here, and you can use multiple custom properties together to provide a high level of granularity. Not heard of custom properties before? Check out a video tutorial on them here.

 

I’ll take three case studies as examples that we’re regularly asked about, which could go a long way to reducing that alerting noise.

 

Let’s start really simple, and assume you’ve got a handful of devices that you need to monitor, but that you don’t need alerts for them. Create a Boolean (Yes/No) custom property called DoNotAlertOnThis. By default, custom property Boolean values default to false – so all you need to do is set this to True for these ‘noisy’ devices.

 

Set up your alert like this:

pic1.png

 

Next, lets take a look at creating a single alert that can email a different contact for each node. When you’ve got a lot of departments, you don’t want all of your admin teams to be receiving alerts for devices that others are responsible for, right? Well, what if I told you that you could create a custom property on your nodes, and store the email address or distribution list address for the Primary Contact(s) within it?

 

And finally, do you ever find yourself wishing that you could define your alert thresholds per device, per interface, or per volume? Not all volumes are created equal - have you ever wished you could alert on some volumes when they reach 50%, but then others aren’t really a panic until they hit 95%? It’s not only possible, it’s quite easy to set up with custom properties.

 

Tip #2 – Using Dependencies to add intelligence to the Alerts

Dependencies are another awesome way to build alerting intelligence, and they cut down drastically on noise.

 

Let’s assume for example, that you’ve got a remote site with a few hundred devices – well using just the default ‘Node Down’ alert, you’re probably getting an email for every single one of those remote devices, if the link to that remote site goes down. It’s not that those devices are actually down, but as Orion can’t contact them, it has no choice but to mark them that way. Right? Thankfully – Wrong!

 

Using Groups and Dependencies, you can tell Orion that those devices are Unreachable when that link goes down – that way, you’ll only receive your interface down alert. Sound good?

 

Here’s how you do it.

 

First create a Group for your remote site. Let’s call it FieldOffice. Set a dependency for your FieldOffice group, with the interface of the network device in your HQ as the parent.

 

That’s it. It’s really that simple – Orion will do all the rest for you automatically.

 

If that interface goes down, Orion will set all the nodes in your Field Office as Unreachable – a specific status used for Dependencies. As these nodes are ‘Unreachable’ status, and not ‘Down’, the logic for ‘alert me when a nodes goes down’ does not apply.

 

Speaking of groups – this is a little off topic, but we do get asked about it from time to time. How do you set up an alert to tell you when a group member goes down (or tell you which of your group members caused the group to go down)? You can actually use the out-of-the-box ‘Alert me when a group goes down’ alert. By default this tells you about the group going down (as the status bubbles up to group level – but it doesn’t include the detail about what group member keeled over to cause that to happen). Add in the following variable to your trigger action to get that information:

Root Cause: ${GroupStatusRootCause}

 

Tip #3 - Check out the complex condition options in 11.5

With the complex conditions options in 11.5 the possibilities are endless, so rather than talk about specific case studies, let’s talk about some of the awesome logic options you can now apply to your alerts.

 

First, enable the “Complex Conditions” on the “Trigger Conditions” tab of your new alert:

pic2.png

First, let’s take a look at a really cool noise reducing option – only get an alert when a certain number of objects meet the alert criteria.

 

Yes, you heard that right – instead of receiving a separate alert for each separate interface with high utilization, you can choose to receive an alert only when a certain threshold of interfaces that match your alert requirements go over their thresholds. With the Complex Conditions enabled, this option will appear at the end of the Primary Section:

pic3.png

And finally, as my last but definitely not least tip of the day – let’s take a look and stringing conditions together. There’ll be times when you might only want to get an alert when two (or more) very distinct conditions occur at once, and when you’re fighting fires, it can be hard to correlate a bunch of emails together to see if that scenario actually happened or not.

 

The classic example of this would be to check the status of two separate applications on two separate servers – maybe you can hobble along with just one, but you might need a critical alert sent out if you lose both.

pic4.png

Using the standard alert conditions, you can create an alert to alert on just one of those applications. If you were to add ‘Node name is equal to ServerB’ in here, it could never trigger – as no server can be named both ‘ServerA’ and ‘ServerB’ at the same time.

 

This is where the complex condition is king. You can now alert as:

pic5.png

So now an application would have to fail on both Server A and also fail on Server B in order to generate this alert.

 

Here’s where it gets super interesting – the conditions don’t have to match. In fact, they don’t have to have anything to do with each other at all, other than both resolving to ‘true’ conditions in order for the alert to fire. And you can add as many of these additional conditions as you like to get truly granular and complex alerts.

 

So – over to you! What tips and tricks have you picked up on Alerts over the years? What excited you about the changes to alerts in 11.5?

 

Want to learn more about Orion Alerts? Take a look at these resources:

Introduction to Alerts

Level 2 Training – Service Groups, Alerts and Dependencies (53 mins)

Building Complex Alert Conditions

Information about Advanced SQL Alerts

Alert Variables

With the exciting release of Orion NPM 11.5 last week, you might be looking for all the information you might need to upgrade, and the steps to do it quickly and easily.

  1. Check the Release Notes for Orion NPM 11.5
  2. Review the system requirements and ensure your server is up to spec.
  3. Back Up your Database (Microsoft KB Links: 2005, 2008, 2008 R2, 2012)
  4. Check your upgrade path
    • If you have only Orion installed, and you’re running NPM version 10.7 or higher, you can go straight to 11.5.
    • If you’re running a version lower than 10.7, you’ll need to do a stepped upgrade. Here’s the overall upgrade path if you only have NPM installed:

               Orion NPM 7.8.5 8.5.1 9.1 9.5.1 10.1.3 10.3.1 10.7 11.5.X

    • If you’re running NPM in addition to other modules, make sure you check the Product Upgrade Advisor tool to get an exact upgrade path for both NPM and your other modules to ensure you maintain compatibility.

     5.   Download the required versions from the customer portal; skip this step if you've already downloaded the bits.


To download the current version, and any previous versions you require, you’ll need to log into the customer portal. Once you’ve logged in, use the License management menu to select ‘My Downloads’.

pic1.png

 

Next, select the product you want to download:

pic2.png


And under the Server Downloads section, you’ll see the latest release selected by default. If you need an earlier version for your upgrade path, you can select it from the drop-down           menu.

pic3.png

     6.   Run the installations, in order, to upgrade your product.  You’ll find the upgrade instructions for Orion NPM here, and a wealth of documentation, including upgrade and installation guides for all our products here.

 

If you run into any trouble during your upgrade, call us in Support on our toll-free numbers or submit a ticket – we’re happy to help!

 

Got a question that wasn’t covered here? Try these resources for help:

Product Upgrade Advisor

Orion NPM Product Page

Upgrading SolarWinds Orion when FailOver Engine is installed

Migrating Orion to another server

Migrating the Orion Database

Manual License Registration

Filter Blog

By date: By tag: